
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
06-30-2025 04:25 PM - edited 06-30-2025 04:26 PM
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.
- Disallow target cloning [New in Security Center 1.3].
- KB0819431 Clone request is stuck in Requested State!
- KB0681148 Unable to request clone due to error message “Destination returned error status = 500”
- Uma Linha de Defesa Silenciosa: Compreendendo a Propriedade glide.db.clone.allow_clone_target no Ser....
- https://www.youtube.com/@servicenowbr/
- https://www.facebook.com/groups/servicenowbrasil
- https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board
- https://www.linkedin.com/groups/5134493/
- https://www.servicenow.com/community/user/viewprofilepage/user-id/73505
- https://github.com/Tiagomacul/
- https://www.tiktok.com/@servicenowbr
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
- 173 Views