Compreendendo a Propriedade glide.db.clone.allow_clone_target no ServiceNow

tiagomacul — Mon, 30 Jun 2025 23:26:35 GMT

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

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.

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.
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".
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.

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

post Compreendendo a Propriedade glide.db.clone.allow_clone_target no ServiceNow in Brazil SNUG

Compreendendo a Propriedade glide.db.clone.allow_clone_target no ServiceNow