Perguntas frequentes sobre máquinas virtuais confidenciais do Azure

VMs confidenciais são VMs IaaS para locatários com requisitos de segurança e confidencialidade especialmente altos. As VMs confidenciais oferecem acesso às seguintes tecnologias e benefícios:

• Criptografia para "dados em uso", incluindo o estado do processador e a memória da máquina virtual. As chaves são geradas pelo processador e são permanentes.
• Atestado de host para verificar a conformidade e a saúde completa do servidor antes de inicializar uma VM confidencial.
• Criptografia de "dados inativos". Um HSM (Módulo de Segurança de Hardware) pode ser usado para manter as chaves, que o locatário possui exclusivamente.
• Nova arquitetura de inicialização UEFI que aceita o sistema operacional convidado para funcionalidades e configurações de segurança aprimoradas.
• Uma instância virtual dedicada de um Trusted Platform Module (TPM). Certifica a saúde da VM e fornece funções de gerenciamento de chaves. Dá suporte a casos de uso como o BitLocker.

As VMs confidenciais abordam as preocupações dos clientes sobre como mover cargas de trabalho confidenciais para fora do local para a nuvem. As VMs confidenciais fornecem proteções significativamente elevadas para dados do cliente dos operadores de nuvem e infraestrutura subjacentes. Ao contrário de outras abordagens e soluções, você não precisa adaptar suas cargas de trabalho existentes para se ajustar às necessidades técnicas da plataforma.

A tecnologia AMD SEV-SNP (Virtualização Criptografada Segura – Paginação Aninhada Segura) oferece várias proteções. Por exemplo, criptografia de memória, chaves de CPU exclusivas, criptografia para o estado de registro do processador, proteção de integridade forte, prevenção de reversões de firmware, proteção de canal lateral e restrições sobre o comportamento de interrupção e exceções. Coletivamente, as tecnologias AMD SEV protegem as proteções de convidado para negar acesso de código de gerenciamento de host e hipervisor à memória e ao estado da VM. As VMs confidenciais combinam AMD SEV-SNP com tecnologias do Azure, como criptografia de disco completo e HSM Gerenciado Azure Key Vault. Você pode criptografar dados em uso, em trânsito e inativos com as chaves que você controla. Com funcionalidades internas deAtestado do Azure, você pode estabelecer de maneira independente a confiança na saúde de segurança e na infraestrutura subjacente de suas VMs confidenciais.

O Intel TDX (Intel Trust Domain Extensions) oferece várias proteções. O Intel TDX usa extensões de hardware para gerenciar e criptografar memória e protege a confidencialidade e a integridade do estado da CPU do TD. Além disso, o Intel TDX ajuda a proteger o ambiente virtualizado, negando ao hipervisor, a outros códigos de gerenciamento de host e aos administradores acesso à memória e ao estado da VM. As VMs confidenciais combinam tecnologias Intel TDX com tecnologias do Azure, como criptografia de disco completo e HSM Gerenciado Azure Key Vault. Você pode criptografar dados em uso, em trânsito e inativos com as chaves que você controla.

As VMs do Azure já oferecem segurança e proteção líderes do setor contra outros locatários e intrusos mal-intencionados. As VMs confidenciais do Azure aumentam essas proteções usando TEEs (Ambientes de Execução Confiável) baseados em hardware, que aproveitam o SEV-SNP da AMD e o Intel TDX para isolar e proteger criptograficamente a confidencialidade e integridade de dados, mesmo quando estão em uso. Isso significa que nem os administradores de host tampouco os serviços (incluindo o hipervisor do Azure) podem exibir ou modificar diretamente a memória ou o estado da CPU da VM. Além disso, com capacidade de atestado completa, criptografia de disco do sistema operacional completa e Módulos de Plataforma Confiável virtuais protegidos por hardeware, o estado persistente da VM confidencial é protegido de modo que nem as chaves privadas nem o conteúdo da memória são expostos ao ambiente de hospedagem em nenhum momento.

Os discos do sistema operacional para VMs confidenciais podem ser criptografados e protegidos atualmente. Para maior segurança, você pode habilitar a criptografia de nível de convidado (como BitLocker ou dm-crypt) para todas as unidades de dados.

Sim, mas somente se o pagefile.sys estiver localizado no disco do sistema operacional criptografado. Em VMs confidenciais com um disco temporário, o arquivo pagefile.sys pode ser movido para o sistema operacional criptografado Dicas para mover o pagefile.sys para a unidade c:\.

Aqui estão algumas maneiras de implantar uma VM confidencial:

• Implantar por meio do portal do Azure
• Implantar da CLI (Interface de Linha de Comando) do Azure
• Implantar usando um modelo do ARM

As VMs confidenciais do Azure em AMD SEV-SNP são submetidas ao atestado durante a fase de inicialização. Esse processo é invisível para o usuário e é executado no sistema operacional de nuvem em conjunto com os serviços Atestado do Microsoft Azure e Azure Key Vault. As VMs confidenciais também permitem que os usuários executem um atestado independente para as VMs confidenciais. Esse atestado ocorre usando novas ferramentas chamadas de Atestado Convidado de VM confidencial do Azure. O atestado convidado permite que os clientes atestem que as VMs confidenciais estão em execução nos processadores AMD com o SEV-SNP habilitado.

As VMs confidenciais do Azure no Intel TDX têm a opção de incluir o atestado como parte da fase de inicialização. Esse processo é invisível para o usuário e é executado no sistema operacional de nuvem em conjunto com os serviços Atestado do Microsoft Azure e Azure Key Vault. O suporte para atestado no convidado estará disponível por meio do vTPM. Você pode usar isso para validar toda a pilha da plataforma de hardware para a camada de aplicativo convidado. A funcionalidade existe no AMD SEV-SNP atualmente e será lançada em breve para Intel TDX. Atualmente, somente o atestado de plataforma no convidado está disponível para o Intel TDX. Isso permite a você verificar se a VM está em execução no hardware do Intel TDX. Para acessar essa versão prévia do recurso, visite nosso branch de versão prévia. Além disso, damos suporte à Intel® Trust Authority para empresas que buscam atestado independente de operador.

Para serem executadas em uma VM confidencial, as imagens do sistema operacional devem atender a determinados requisitos de segurança e compatibilidade. Isso permite que as VMs sejam montadas com segurança, atestadas e isoladas da infraestrutura de nuvem subjacente. No futuro, planejamos fornecer diretrizes de como fazer um build personalizado do Linux e aplicar um conjunto de patches de código aberto para qualificá-lo como uma imagem de VM confidencial.

Sim. Você pode usar Galeria de Computação do Azure para modificar uma imagem de VM confidencial, como instalação de aplicativos. Em seguida, você pode implantar VMs confidenciais com base em sua imagem modificada.

O esquema opcional de criptografia de disco completo é o mais seguro do Azure e atende aos princípios de Computação Confidencial. No entanto, você também pode usar outros esquemas de criptografia de disco ao mesmo tempo ou em vez de criptografia de disco completo. Se você usar vários esquemas de criptografia de disco, a criptografia dupla poderá prejudicar o desempenho.

Cada VM confidencial do Azure tem seu próprio TPM virtual, em que os clientes podem selar os segredos/chaves. É recomendável que os clientes verifiquem o status do vTPM (usando o TPM.msc para VMs do Windows). Se o status não estiver pronto para uso, recomendamos que você reinicialize as VMs, antes de selar os segredos/chaves no vTPM.

Não. Depois de criar uma VM confidencial, você não poderá desativar ou reativar a criptografia de disco completo. Em vez disso, crie uma nova VM confidencial.

Os desenvolvedores que buscam mais "separação de funções" para serviços TCB do provedor de serviços de nuvem devem usar o tipo de segurança "NonPersistedTPM".

• Essa experiência só está disponível como parte da versão prévia pública do Intel TDX. Ele tem avisos de isenção de responsabilidade, as organizações que o usam ou fornecem serviços com ele estão no controle do TCB e das responsabilidades que o acompanham.
• Essa experiência ignora os serviços nativos do Azure, permitindo que você traga sua criptografia de disco, gerenciamento de chaves e solução de atestado.
• Cada VM ainda tem um vTPM, que deve ser usado para recuperar evidências de hardware, no entanto, o estado do vTPM não é mantido por meio de reinicializações, o que significa que essa solução é excelente para cargas de trabalho efêmeras e organizações que buscam mais dissociação do provedor de serviços de nuvem.

Não. Por motivos de segurança, você deve criar uma VM confidencial como tal desde o início.

Sim, a conversão de uma VM confidencial em outra VM confidencial é permitida em DCasv5/ECasv5 e DCesv5/ECesv5 nas regiões que eles compartilham. Se você estiver usando uma imagem do Windows, verifique se você tem todas as atualizações mais recentes. Se você estiver usando uma imagem do Ubuntu Linux, verifique se está usando a imagem confidencial Ubuntu 22.04 LTS com a versão mínima do kernel 6.2.0-1011-azure.

Verifique se você selecionou uma região disponível para VMs confidenciais. Além disso, certifique-se de selecionar limpar todos os filtros no seletor de tamanho.

Não. As VMs confidenciais não são compatíveis com a Rede Acelerada. Você não pode habilitar a Rede Acelerada para nenhuma implantação de VM confidencial ou qualquer implantação Serviço de Kubernetes do Azure cluster que é executado na Computação Confidencial.

Você pode receber o erro Não foi possível concluir a operação, pois ela excede a cota de núcleos de família de DCasV5/ECasv5 padrão aprovada. Esse modelo do Azure Resource Manager (modelo ARM) significa que a implantação falhou devido à falta de núcleos de computação do Azure. As assinaturas de avaliação gratuita do Azure não têm uma cota de núcleo grande o suficiente para VMs confidenciais. Crie uma solicitação de suporte para aumentar a cota.

As séries ECasv5 e ECesv5 são tamanhos de VM com otimização de memória, que oferecem uma taxa mais alta de memória para CPU. Esses tamanhos são especialmente adequados para servidores de banco de dados relacionais, caches médios a grandes e análise na memória.

Não. Neste momento, essas VMs só estão disponíveis em regiões selecionadas. Para ver uma lista atual das regiões disponíveis, confira Produtos de VM por região.

O Azure não tem procedimentos operacionais para conceder acesso de VM confidencial a seus funcionários, mesmo que um cliente autorize o acesso. Como resultado, vários cenários de recuperação e suporte não estão disponíveis para VMs confidenciais.

Não, as VMs confidenciais atualmente não têm suporte para virtualização aninhada, como a capacidade de executar um hipervisor dentro de uma VM.

A cobrança por VMs confidenciais depende do uso, do armazenamento, do tamanho e da região da VM. As VMs confidenciais usam um pequeno disco VMGS (estado de convidado de máquina virtual) criptografado de vários megabytes. O VMGS encapsula o estado de segurança da VM de componentes como o carregador de inicialização de vTPM e UEFI. Esse disco pode resultar em um valor de armazenamento mensal. Além disso, se você optar por habilitar a criptografia de disco completo opcional, os discos do sistema operacional criptografados vão gerar custos mais altos. Para obter mais informações sobre valores de armazenamento, consulte o guia de preços para discos gerenciados. Por fim, para algumas configurações de alta segurança e privacidade, você pode optar por criar recursos vinculados, como um Pool de HSM Gerenciado. O Azure cobra esses recursos separadamente dos custos confidenciais da VM.

Raramente, algumas VMs da série DCesv5/ECesv5 podem ter uma pequena diferença de tempo em relação ao UTC. Uma correção de longo prazo estará disponível para isso em breve. Enquanto isso, aqui estão as soluções alternativas para VMs do Windows e do Ubuntu Linux:

sc config vmictimesync start=disabled
sc stop vmictimesync

Para imagens do Ubuntu Linux, execute o seguinte script:

#!/bin/bash

# Backup the original chrony.conf file
cp /etc/chrony/chrony.conf /etc/chrony/chrony.conf.bak

# check chronyd.service status
status=$(systemctl is-active chronyd.service)

# check chronyd.service status is "active" or not
if [ "$status" == "active" ]; then
  echo "chronyd.service is active."
else
  echo "chronyd.service is not active. Exiting script."
  exit 1
fi

# Comment out the line with 'refclock PHC /dev/ptp_hyperv'
sed -i '/refclock PHC \/dev\/ptp_hyperv/ s/^/#/' /etc/chrony/chrony.conf

# Uncomment the lines with 'pool ntp.ubuntu.com' and other pool entries
sed -i '/#pool ntp.ubuntu.com/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 0.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 1.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 2.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf

echo "Changes applied to /etc/chrony/chrony.conf. Backup created at /etc/chrony/chrony.conf.bak."

echo "Restart chronyd service"
systemctl restart chronyd.service


echo "Check chronyd status"
systemctl status chronyd.service