Compartilhar via

Azure Disk Encryption em uma rede isolada

Importante

O Azure Disk Encryption está programado para ser desativado em 15 de setembro de 2028. Até essa data, você pode continuar a usar o Azure Disk Encryption sem interrupções. Em 15 de setembro de 2028, as cargas de trabalho habilitadas para ADE continuarão a ser executadas, mas os discos criptografados não serão desbloqueados após reinicializações da VM, resultando em interrupção do serviço.

Utilize criptografia no host para novas VMs. Todas as VMs habilitadas para ADE (incluindo backups) devem migrar para a criptografia no host antes da data de desativação para evitar a interrupção do serviço. Consulte Migrar do Azure Disk Encryption para criptografia no host para obter detalhes.

Cuidado

Este artigo faz referência ao CentOS, uma distribuição Linux que está em status de fim do serviço (EOL). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.

Aplica-se a: ✔️ VMs do Linux ✔️ Conjuntos de dimensionamento flexíveis.

Quando a conectividade estiver restrita por requisitos de proxy, firewall ou NSG (grupo de segurança de rede), a capacidade da extensão para executar as tarefas necessárias poderá ser interrompida. Essa interrupção pode resultar em mensagens de status como "Status da extensão não disponível na VM".

Gerenciamento de pacotes

O Azure Disk Encryption depende de muitos componentes, que são normalmente instalados como parte da habilitação do ADE, se ainda não estiverem presentes. Quando estiver atrás de um firewall ou isolado da Internet, esses pacotes devem ser pré-instalados ou disponíveis localmente.

Aqui estão os pacotes necessários para cada distribuição. Para obter uma lista completa dos tipos de volume e distribuições com suporte, consulte VMs e sistemas operacionais com suporte.

  • Ubuntu 14.04, 16.04, 18.04: lsscsi, psmisc, at, cryptsetup-bin, Python-in, Python-seis, procps, grub-pc-bin
  • CentOS 7.2 – 7.9, 8.1, 8.2: lsscsi, psmisc, lvm2, uuid, at, patch, cryptsetup, cryptsetup-reencrypt, pyparted, procps-ng, util-linux
  • CentOS 6.8: lsscsi, psmisc, lvm2, uuid, at, cryptsetup-reencrypt, parted, python-six
  • RedHat 7.2 – 7.9, 8.1, 8.2: lsscsi, psmisc, lvm2, uuid, at, patch, cryptsetup, cryptsetup-reencrypt, procps-ng, util-linux
  • RedHat 6.8: lsscsi, psmisc, lvm2, UUID, at, patch, cryptsetup – recriptografar
  • openSUSE 42,3, SLES 12-SP4, 12-SP3: lsscsi, cryptsetup

No Red Hat, quando um proxy é necessário, é preciso garantir que o gerenciador de assinaturas e o yum sejam configurados corretamente. Para saber mais, confira How to troubleshoot subscription-manager and yum problems (Como solucionar problemas do gerenciador de assinaturas e do yum).

Quando os pacotes são instalados manualmente, eles também devem ser atualizados manualmente conforme novas versões são lançadas.

Grupos de segurança de rede

Todas as configurações de grupo de segurança de rede aplicadas ainda devem permitir que o ponto de extremidade atenda aos pré-requisitos de configuração de rede documentados para criptografia de disco. Consulte Azure Disk Encryption: requisitos de rede

Azure Disk Encryption com Microsoft Entra ID (versão anterior)

Se estiver usando o Azure Disk Encryption com a ID do Microsoft Entra (versão anterior), a Biblioteca de Autenticação da Microsoft deverá ser instalada manualmente para todas as distribuições (além dos pacotes apropriados para a distribuição).

Quando a criptografia é habilitada com as credenciais do Microsoft Entra, a VM de destino deve permitir conectividade com pontos de extremidade do Microsoft Entra e pontos de extremidade do Key Vault. Os pontos de extremidade atuais de autenticação do Microsoft Entra são mantidos nas seções 56 e 59 da documentação de URLs e intervalos de endereços IP do Microsoft 365. As instruções do Key Vault são fornecidas na documentação sobre como Acessar o Azure Key Vault por trás de um firewall.

Serviço de metadados de instância do Azure

A máquina virtual precisa conseguir acessar o ponto de extremidade do Serviço de Metadados de Instância do Azure, que usa um endereço IP não roteável conhecido (169.254.169.254) que pode ser acessado somente na VM. Não há suporte para as configurações de proxy que alteram o tráfego HTTP local para esse endereço (por exemplo, a adição de um cabeçalho X-Forwarded-For).

Próximas etapas

  • Last updated on