Gestão dos dados da Automatização do Azure

  • Artigo

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

  • Runbook Workers híbridos, que incluem máquinas gerenciadas pelo Gerenciamento de Atualizações e Controle de Alterações e Inventário.

  • Nós DSC

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, Webhooks e nós DSC híbridos baseados em agente e extensão que usam 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. Certifique-se de fazer alterações no Registro para que os trabalhadores baseados em Agente e Extensão negociem somente em protocolos TLS 1.2 e superiores. 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