The CreatorCon Call for Content is officially open! Get started here.

tiagomacul
Giga Sage

Uma Linha de Defesa Silenciosa: Compreendendo a Propriedade glide.db.clone.allow_clone_target no ServiceNow

 

Destination does not allow clone requests (Typically used by live production instances, a property was set that prevents the instance from being cloned over).

 

Para o leitor, que assim como eu, se preocupa profundamente com a integridade e a segurança dos nossos ambientes ServiceNow, especialmente os de produção, entender cada detalhe do processo de clonagem é fundamental. Recentemente, me aprofundei em uma propriedade que, embora pareça simples, carrega um peso enorme na nossa estratégia de segurança: a glide.db.clone.allow_clone_target.

Como autor deste artigo, e alguém que busca as melhores práticas para proteger nossos dados, convido você a desvendar essa propriedade, especialmente a nuance entre seu valor padrão e o que é realmente recomendado para nossos ambientes mais críticos.

glide.db.clone.allow_clone_target: A Guardiã dos Nossos Alvos de Clone

De forma bem direta, a propriedade glide.db.clone.allow_clone_target controla se uma instância do ServiceNow pode ou não ser o DESTINO de uma operação de clonagem de banco de dados.

  • Se o valor é true: A instância está liberada para receber um clone. Isso significa que outra instância pode clonar seus dados para cá, sobrescrevendo tudo o que existe. (use em instâncias não produtivas como instâncias de DEV, QA, etc..)
  • Se o valor é false: A instância está protegida e não pode ser o destino de um clone. Qualquer tentativa de iniciar um clone para esta instância será barrada, resultando em uma mensagem de erro como "Destination does not allow clone requests...".
  • ALTAMENTE Recomendado para instâncias Produtivas.
https://<instance>.service-now.com/now/nav/ui/classic/params/target/sys_properties_list.do%3Fsysparm_query%3DnameSTARTSWITHglide.db.clone.allow_clone_target%26sysparm_first_row%3D1%26sysparm_view%3D

 

tiagomacul_0-1751325636443.png

 

Essa propriedade existe como uma barreira de segurança vital. O processo de clonagem é, por natureza, destrutivo para a instância de destino, pois todos os seus dados e configurações são completamente apagados e substituídos pelos da origem.

A Grande Revelação: Padrão vs. Recomendado para Produção

Foi aqui que tive um “aha!” momento, e algo que considero crucial compartilhar:

  • Valor Padrão (Default value😞 true
  • Sim, por padrão, as instâncias vêm configuradas para permitir que sejam alvos de clonagem.
  • Valor Recomendado (Recommended value😞 false (Especialmente para Produção)
  • Esta é a parte essencial! A documentação da ServiceNow e as melhores práticas de segurança sugerem fortemente que, para nossa instância de produção e talvez para outros ambientes de não-produção extremamente sensíveis (como um ambiente de treinamento “GOLD” ou de conformidade que não pode ser tocado), o valor seja definido como false.

Por Que false é o Nosso Amigo na Produção?

Para mim, a razão é simples: segurança máxima.

  1. A Última Linha de Defesa: Embora nossos processos de Change Management, controle de acesso e a necessidade de envolver o suporte da ServiceNow já protejam a produção de clonagens acidentais, a propriedade false adiciona uma barreira técnica inquebrável no nível da plataforma. Mesmo que alguma falha de processo ou erro humano ocorra, a instância de produção estará tecnicamente bloqueada para receber um clone.
  2. Produção como Origem, Não Alvo: Nossa instância de produção é quase que exclusivamente a origem dos clones (clonamos dela para Dev/Test/QA). Ela raramente, ou nunca, deveria ser o alvo de um clone, a menos que seja um cenário de recuperação de desastre gravíssimo e altamente controlado. O valor false garante que ela cumpra esse papel de "origem" sem o risco de ser "sobrescrita".
  3. Prevenção de Perda de Dados: A consequência de uma clonagem indesejada na produção é a perda completa dos dados de negócio. Definir essa propriedade como false é uma medida proativa para mitigar esse risco catastrófico.

 

Quando Alterar (e com Cuidado Cirúrgico):

Se, por uma razão extremamente rara e validada (como uma recuperação de desastres que exige restaurar a produção de um backup ou de uma instância DR específica, sempre com a orientação e aprovação do Suporte ServiceNow), for absolutamente necessário clonar para a produção, essa propriedade teria que ser temporariamente alterada para true e imediatamente revertida para false após a conclusão da operação. Isso deve ser tratado como um procedimento de alta criticidade.

 

Minha Perspectiva: Segurança Ativa é Essencial

Para mim, a propriedade glide.db.clone.allow_clone_target encapsula a filosofia de segurança ativa. Não basta ter senhas fortes e processos; precisamos de camadas de proteção técnicas que atuem como redes de segurança. Definir essa propriedade como false em nossa produção é uma pequena configuração que oferece uma grande paz de espírito, garantindo que a integridade dos nossos dados mais valiosos esteja protegida por uma camada fundamental da própria plataforma.

É um lembrete importante de que, mesmo em detalhes técnicos, a atenção às melhores práticas e recomendações oficiais da ServiceNow faz toda a diferença na robustez do nosso ambiente.

Lembre-se um clone terá toda informação sobreescrita.

tiagomacul_1-1751325636333.png

 

tiagomacul_2-1751325636310.jpeg

 

tiagomacul_3-1751325636308.jpeg

 

 

obs: Antes de consultar AI, consulte a documentação.
Sim, responderam diversas vezes o inverso mesmo eu mostrando o que acontecia de fato, apenas se convenceu com o documento Disallow target cloning [New in Security Center 1.3].

Recommended Valur: FALSE

tiagomacul_4-1751325749518.png

 

Version history
Last update:
‎06-30-2025 04:26 PM
Updated by:
Contributors