Gestão dos dados da Automatização do Azure
Este artigo contém vários tópicos que explicam como os dados são protegidos e protegidos em um ambiente de Automação do Azure.
TLS para Automação do Azure
Para garantir a segurança dos dados em trânsito para a Automação do Azure, recomendamos que você configure o uso do TLS (Transport Layer Security). A seguir está uma lista de métodos ou clientes que se comunicam por HTTPS para o serviço de automação:
Chamadas Webhook
User Hybrid Runbook Workers (baseado em extensão e agente)
Máquinas geridas pela Automação do Azure Gestão de atualizações e Automação do Azure Controlo de alterações & inventário
Nós DSC da Automação do Azure
Versões mais antigas do TLS/Secure Sockets Layer (SSL) foram consideradas vulneráveis e, embora ainda funcionem atualmente para permitir compatibilidade com versões anteriores, não são recomendadas. Não recomendamos configurar explicitamente seu agente para usar apenas o TLS 1.2, a menos que seja necessário, pois ele pode quebrar os recursos de segurança no nível da plataforma que permitem detetar automaticamente e aproveitar os protocolos mais recentes e mais seguros à medida que se tornam disponíveis, como o TLS 1.3.
Para obter informações sobre o suporte a TLS com o agente do Log Analytics para Windows e Linux, que é uma dependência para a função Hybrid Runbook Worker, consulte Visão geral do agente do Log Analytics - TLS.
Atualizar o protocolo TLS para Trabalhadores Híbridos e chamadas Webhook
A partir de 31 de outubro de 2024, todos os Runbook Workers híbridos de usuário baseados em agente e extensão, Webhooks, nós DSC e máquinas gerenciadas de gerenciamento de atualizações de automação do Azure e controle de alterações, usando protocolos TLS (Transport Layer Security) 1.0 e 1.1, não poderão mais se conectar à Automação do Azure. Todos os trabalhos em execução ou agendados em Trabalhadores Híbridos usando protocolos TLS 1.0 e 1.1 falharão.
Certifique-se de que as chamadas Webhook que acionam runbooks naveguem no TLS 1.2 ou superior. Saiba como desativar os protocolos TLS 1.0/1.1 no Windows Hybrid Worker e habilitar o TLS 1.2 ou superior na máquina Windows.
Para Linux Hybrid Workers, execute o seguinte script Python para atualizar para o protocolo TLS mais recente.
import os
# Path to the OpenSSL configuration file as per Linux distro
openssl_conf_path = "/etc/ssl/openssl.cnf"
# Open the configuration file for reading
with open(openssl_conf_path, "r") as f:
openssl_conf = f.read()
# Check if a default TLS version is already defined
if "DEFAULT@SECLEVEL" in openssl_conf:
# Update the default TLS version to TLS 1.2
openssl_conf = openssl_conf.replace("CipherString = DEFAULT@SECLEVEL", "CipherString = DEFAULT@SECLEVEL:TLSv1.2")
# Open the configuration file for writing and write the updated version
with open(openssl_conf_path, "w") as f:
f.write(openssl_conf)
# Restart any services that use OpenSSL to ensure that the new settings are applied
os.system("systemctl restart apache2")
print("Default TLS version has been updated to TLS 1.2.")
else:
# Add the default TLS version to the configuration file
openssl_conf += """
Options = PrioritizeChaCha,EnableMiddleboxCompat
CipherString = DEFAULT@SECLEVEL:TLSv1.2
MinProtocol = TLSv1.2
"""
# Open the configuration file for writing and write the updated version
with open(openssl_conf_path, "w") as f:
f.write(openssl_conf)
# Restart any services that use OpenSSL to ensure that the new settings are applied
os.system("systemctl restart apache2")
print("Default TLS version has been added as TLS 1.2.")
Orientações específicas da plataforma
Plataforma/Idioma | Suporte | Mais Informações |
---|---|---|
Linux | As distribuições Linux tendem a depender do OpenSSL para suporte a TLS 1.2. | Verifique o OpenSSL Changelog para confirmar se a sua versão do OpenSSL é suportada. |
Janelas 8.0 - 10 | Suportado e ativado por padrão. | Para confirmar que você ainda está usando as configurações padrão. |
Windows Server 2012 - 2016 | Suportado e ativado por padrão. | Para confirmar que você ainda está usando as configurações padrão |
Windows 7 SP1 e Windows Server 2008 R2 SP1 | Suportado, mas não ativado por padrão. | Consulte a página de configurações do Registro Transport Layer Security (TLS) para obter detalhes sobre como habilitar. |
Retenção de dados
Quando você exclui um recurso na Automação do Azure, ele é retido por muitos dias para fins de auditoria antes da remoção permanente. Não é possível ver ou usar o recurso durante esse período. Esta política também se aplica a recursos que pertencem a uma conta de automação excluída. A política de retenção aplica-se a todos os utilizadores e, atualmente, não pode ser personalizada. No entanto, se você precisar manter os dados por um período mais longo, poderá encaminhar os dados do trabalho da Automação do Azure para os logs do Azure Monitor.
A tabela a seguir resume a política de retenção para diferentes recursos.
Dados | Política |
---|---|
Contas | Uma conta é removida permanentemente 30 dias após a exclusão de um usuário. |
Ativos | Um ativo é removido permanentemente 30 dias após um usuário excluí-lo ou 30 dias depois que um usuário exclui uma conta que detém o ativo. Os ativos incluem variáveis, agendas, credenciais, certificados, pacotes Python 2 e conexões. |
Nós DSC | Um nó DSC é removido permanentemente 30 dias após ser cancelado de uma conta de Automação usando o portal do Azure ou o cmdlet Unregister-AzAutomationDscNode no Windows PowerShell. Um nó também é removido permanentemente 30 dias depois que um usuário exclui a conta que contém o nó. |
Tarefas | Um trabalho é excluído e removido permanentemente 30 dias após a modificação, por exemplo, depois que o trabalho é concluído, interrompido ou suspenso. |
Módulos | Um módulo é removido permanentemente 30 dias depois que um usuário o exclui, ou 30 dias depois que um usuário exclui a conta que contém o módulo. |
Configurações de nó/arquivos MOF | Uma configuração de nó antiga é removida permanentemente 30 dias após a geração de uma nova configuração de nó. |
Relatórios de nós | Um relatório de nó é removido permanentemente 90 dias após a geração de um novo relatório para esse nó. |
Runbooks | Um runbook é removido permanentemente 30 dias depois que um usuário exclui o recurso ou 30 dias depois que um usuário exclui a conta que contém o recurso1. |
1 O runbook pode ser recuperado dentro da janela de 30 dias registrando um incidente de suporte do Azure com o Suporte do Microsoft Azure. Vá para o site de suporte do Azure e selecione Enviar uma solicitação de suporte.
Backup de dados
Quando você exclui uma conta de Automação no Azure, todos os objetos na conta são excluídos. Os objetos incluem runbooks, módulos, configurações, configurações, trabalhos e ativos. Você pode recuperar uma conta de automação excluída dentro de 30 dias. Você também pode usar as seguintes informações para fazer backup do conteúdo da sua conta de automação antes de excluí-la:
Runbooks
Você pode exportar seus runbooks para arquivos de script usando o portal do Azure ou o cmdlet Get-AzureAutomationRunbookDefinition no Windows PowerShell. Você pode importar esses arquivos de script para outra conta de Automação, conforme discutido em Gerenciar runbooks na Automação do Azure.
Módulos de integração
Não é possível exportar módulos de integração da Automação do Azure, eles precisam ser disponibilizados fora da conta de Automação.
Ativos
Não é possível exportar ativos da Automação do Azure: certificados, conexões, credenciais, agendas e variáveis. Em vez disso, você pode usar o portal do Azure e os cmdlets do Azure para anotar os detalhes desses ativos. Em seguida, use esses detalhes para criar quaisquer ativos que são usados por runbooks que você importa para outra conta de automação.
Não é possível recuperar os valores de variáveis criptografadas ou os campos de senha de credenciais usando cmdlets. Se você não souber esses valores, poderá recuperá-los em um runbook. Para recuperar valores de variáveis, consulte Ativos variáveis na Automação do Azure. Para saber mais sobre como recuperar valores de credenciais, consulte Ativos de credenciais na Automação do Azure.
Configurações DSC
Você pode exportar suas configurações de DSC para arquivos de script usando o portal do Azure ou o cmdlet Export-AzAutomationDscConfiguration no Windows PowerShell. Você pode importar e usar essas configurações em outra conta de automação.
Residência de dados
Você especifica uma região durante a criação de uma conta de Automação do Azure. Os dados de serviço, como ativos, configuração, logs, são armazenados nessa região e podem transitar ou ser processados em outras regiões dentro da mesma geografia. Esses pontos de extremidade globais são necessários para fornecer aos usuários finais uma experiência de alto desempenho e baixa latência, independentemente da localização. Somente para a região Sul do Brasil (Estado de São Paulo) da geografia do Brasil, região do Sudeste Asiático (Cingapura) e região do Leste Asiático (Hong Kong) da geografia Ásia-Pacífico, armazenamos dados da Automação do Azure na mesma região para acomodar os requisitos de residência de dados para essas regiões.
Próximos passos
- Para saber mais sobre as diretrizes de segurança, consulte Práticas recomendadas de segurança na Automação do Azure.
- Para saber mais sobre ativos seguros na Automação do Azure, consulte Criptografia de ativos seguros na Automação do Azure.
- Para saber mais sobre a replicação geográfica, consulte Criando e usando a replicação geográfica ativa.