Gerenciamento de dados da Automação do Azure

  • Artigo

Este artigo contém vários tópicos explicando como os dados são protegidos em um ambiente da 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, incentivamos fortemente que você configure o uso do protocolo TLS. Veja a seguir uma lista de métodos ou clientes que se comunicam por HTTPS com o serviço de automação:

  • Chamadas de webhook

  • Hybrid runbook Workers, que incluem computadores gerenciados por Gerenciamento de Atualizações e Controle de Alterações e Inventário.

  • Nós DSC

Constatou-se que versões mais antigas do protocolo TLS/protocolo SSL eram vulneráveis e embora elas ainda funcionem no momento para permitir a compatibilidade com versões anteriores, elas não são recomendadas. Não é recomendável definir explicitamente o agente para usar somente o TLS 1.2, a menos que necessário, pois ele pode separar os recursos de segurança em nível de plataforma que permitem que você detecte e use os protocolos mais seguros e mais recentes assim que estiverem automaticamente disponíveis como o protocolo TLS 1.3.

Para obter mais informações sobre o suporte ao protocolo com o agente do Log Analytics para Windows e Linux, que é uma dependência para a função Hybrid Runbook Worker, confira Visão geral do agente do Log Analytics — TLS.

Atualizar o protocolo TLS para chamadas de Hybrid Workers e Webhook

A partir de 31 de outubro de 2024, todos os User Hybrid Runbook Workers, Webhooks e nós DSC baseados em agentes e em extensões que utilizam os protocolos TLS 1.0 e 1.1 não poderão se conectar à Automação do Azure. Todos os trabalhos em execução ou agendados em Hybrid Workers usando os protocolos TLS 1.0 e 1.1 irão falhar.

Certifique-se de que as chamadas do Webhook que disparam runbooks navegam usando o TLS 1.2 ou superior. Certifique-se de fazer alterações no registro para que os trabalhos baseados em Agente e Extensão negociem apenas em protocolos TLS 1.2 e superiores. Saiba como desabilitar protocolos TLS 1.0/1.1 no Windows Hybrid Worker e habilitar o TLS 1.2 ou superior no computador Windows.

Para os Hybrid Workers do Linux, execute o script Python a seguir 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.")

Diretrizes específicas da plataforma

Plataforma/linguagem Suporte Mais informações
Linux Distribuições do Linux tendem a depender do OpenSSL para suporte a TLS 1.2. Verifique as OpenSSL Changelog para confirmar a sua versão do OpenSSL é suportada.
Windows 8.0 - 10 Suporte e habilitado por padrão. Para confirmar que você ainda está usando o as configurações padrão.
Windows Server 2012 - 2016 Suporte e habilitado por padrão. Para confirmar que você ainda está usando o as configurações padrão
Windows Server 7 SP1 e Windows Server 2008 R2 SP1 Com suporte, mas não habilitado por padrão. Consulte a página configurações do registro de segurança de camada de transporte (TLS) para obter detalhes sobre como habilitar.

Retenção de dados

Quando você exclui um recurso na Automação do Azure, ele é mantido por vários dias para fins de auditoria antes da remoção permanente. Você não pode ver nem usar o recurso durante esse período. Essa política também se aplica aos recursos que pertencem a uma conta da Automação excluída. A política de retenção se aplica a todos os usuários e atualmente não pode ser personalizada. No entanto, se você precisar manter os dados por um longo período, poderá encaminhar os dados do trabalho de 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 depois que um usuário a exclui.
Ativos Um ativo é removido permanentemente 30 dias depois que é excluído por um usuário, ou 30 dias depois que a conta que o contém é excluída por um usuário. 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 o cancelamento do registro de uma conta da Automação usando o portal do Azure ou o cmdlet Unregister-AzAutomationDscNode no Windows PowerShell. Um nó também é removido permanentemente 30 dias após um usuário excluir a conta que o contém.
Trabalhos 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 é excluído por um usuário, ou 30 dias depois que a conta que o contém é excluída por um usuário.
Arquivos de configurações/MOF de nó Uma configuração de nó antigo é removida permanentemente 30 dias depois que uma nova configuração de nó é gerada.
Relatórios de Nó Um relatório de nó é removido de forma permanente 90 dias depois que um novo relatório é gerado para esse nó.
Runbooks Um runbook é removido permanentemente 30 dias depois que é excluído por um usuário ou 30 dias depois que a conta que contém o recurso 1 é excluída por um usuário.

1 O runbook pode ser recuperado dentro do período de 30 dias, criando um incidente do Suporte do Azure com o Suporte do Microsoft Azure. Acesse o site do Suporte do Azure e selecione Enviar uma solicitação de suporte.

Backup de dados

Quando você exclui uma conta da Automação no Azure, todos os objetos na conta são excluídos. Os objetos incluem runbooks, módulos, configurações, definiçõ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 da Automação, conforme discutido em Gerenciar runbooks na Automação do Azure.

Módulos de integração

Você não pode exportar módulos de integração da Automação do Azure, eles precisam ser disponibilizados fora da conta de automação.

Ativos

Você não pode exportar ativos da Automação do Azure: certificados, conexões, credenciais, agendamentos e variáveis. Em vez disso, você pode usar o portal do Azure e os cmdlets do Azure para observar os detalhes desses ativos. Em seguida, use esses detalhes para criar quaisquer ativos usados pelos runbooks importados para outra conta da Automação.

Não é possível recuperar os valores de variáveis criptografadas, nem 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, confira Recursos variáveis na Automação do Azure. Para saber mais sobre como recuperar valores de credenciais, confira Recursos de credenciais na Automação do Azure.

Configurações DSC

Você pode exportar suas configurações 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 da Automação.

Residência de dadosResidência de dados

Especifique uma região durante a criação de uma conta de Automação do Azure. 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 área geográfica. 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 do local. Somente para a região Sul do Brasil (Estado de São Paulo) da geografia do Brasil, região do Sudeste Asiático (Singapura) e Região Leste da Ásia (Hong Kong) da geografia do Pacífico Asiático, 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óximas etapas