Perguntas frequentes sobre máquinas virtuais confidenciais do Azure

VMs confidenciais são uma solução IaaS para locatários com alto nível de exigência com relação à segurança e a confidencialidade. Oferta de VMs confidenciais:

• 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 nunca saem dele.
• O atestado de host ajuda você a verificar a total integridade e conformidade do servidor antes que o processamento de dados tenha início.
• O Módulo de Segurança de Hardware (HSM) pode ser anexado para proteger as chaves de discos de VM confidenciais que o locatário possui com exclusividade.
• Nova arquitetura de inicialização UEFI que aceita o sistema operacional convidado para funcionalidades e configurações de segurança aprimoradas.
• Um Módulo de Plataforma Confiável (TPM) virtual dedicado certifica a integridade da VM, fornece um gerenciamento de chaves com segurança reforçada e dá suporte a casos de uso como o do 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 de nível elevado para dados do cliente dos operadores subjacentes de nuvem e de infraestrutura. 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.

SEV-SNP significa Virtualização Criptografada Segura-Paginação Aninhada Segura. Trata-se de uma tecnologia de Ambiente de Execução Confiável (TEE) fornecida pela AMD e 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, prevenção contra reversão de firmware, reforço da segurança do canal lateral e restrições do 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 capitalizam a SEV-SNP da AMD com tecnologias do Azure como a criptografia de disco total e o HSM do Azure Key Vault Gerenciado. Você pode criptografar dados em uso, em trânsito e inativos com as chaves que você controla. Com as funcionalidades integradas doAtestado do Azure, você pode estabelecer de maneira independente a confiança na segurança, na integridade e na infraestrutura subjacente de suas VMs confidenciais.

Intel TDX significa Extensões de Domínio Confiável da Intel (Intel TDX), uma tecnologia de Ambiente de Execução Confiável (TEE) fornecida pela Intel que oferece várias proteções: o Intel TDX usa extensões de hardware para gerenciar e criptografar a memória e protege tanto a confidencialidade quanto a integridade do estado da CPU. Além disso, o Intel TDX ajuda a reforçar a segurança do ambiente virtualizado negando o acesso à memória e ao estado da VM ao hipervisor, a outros códigos de gerenciamento de host e aos administradores. 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 baseados em hardware, como a SEV-SNP da AMD e o Intel TDX, para isolar e proteger criptograficamente a confidencialidade e integridade de seus dados. Isso significa que os administradores de host ou serviços de host (incluindo o hipervisor do Azure) não podem ver nem modificar diretamente a memória ou o estado da CPU da sua VM confidencial. Além disso, com a funcionalidade de atestado completo, a criptografia total do disco do sistema operacional e os Módulos de Plataforma Confiável virtuais protegidos por hardware, o estado persistente é protegido de modo que nem as chaves privadas nem o conteúdo da sua memória são expostos sem criptografia ao ambiente de hospedagem.

Os discos do sistema operacional para VMs confidenciais podem ser criptografados e protegidos atualmente. Para uma segurança ainda maior, você pode habilitar a criptografia no nível de convidado (como o BitLocker ou o 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:\.

Não, essa funcionalidade não existe para VMs confidenciais.

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
• Implantar usando VMSS e Criptografia de Disco Confidencial

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 com os serviços do Atestado do Microsoft Azure e do 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 que usam o Intel TDX podem ser atestadas de forma transparente como parte do fluxo de inicialização para garantir que a plataforma esteja em conformidade e atualizada. O processo é invisível para o usuário e ocorre usando o Atestado do Microsoft Azure e o Azure Key Vault. Se você quiser ir mais longe e executar verificações após a inicialização, o atestado de plataforma no convidado está disponível. Isso permite que você verifique se sua VM está em execução em um Intel TDX genuíno. Para acessar o recurso, acesse nosso branch de pré-visualização. Além disso, damos suporte à Intel® Trust Authority para empresas que buscam atestado independente de operador. O suporte ao atestado completo no convidado, semelhante à SEV-SNP da AMD, estará disponível em breve. Isso permite que as organizações se aprofundem ainda mais e validem outros aspectos, chegando até mesmo à camada de aplicativo do convidado.

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 sobre como aplicar um conjunto de patches de código aberto a um build personalizado do Linux 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 (por meio do TPM.msc para VMs do Windows). Se o status não for pronto para uso, recomendamos que você reinicialize suas VMs, antes de vedar 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. As organizações que usam o recurso ou fornecem serviços com ele estão no controle da TCB e das responsabilidades que a acompanham.
• Essa experiência ignora os serviços nativos do Azure, permitindo que você traga sua própria criptografia de disco, gerenciamento de chaves e solução de atestado.
• Cada VM continua tendo um vTPM, que deve ser usado para recuperar evidências de hardware. No entanto, o estado do vTPM não é persistido por meio de reinicializações, o que significa que essa solução é excelente para cargas de trabalho efêmeras e organizações que querem se dissociar 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 estiver usando uma imagem do Windows, certifique-se de que você tenha todas as atualizações mais recentes. Se estiver usando uma imagem do Ubuntu Linux, certifique-se de que você esteja usando a imagem confidencial do Ubuntu 22.04 LTS com no mínimo uma versão 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 incorrerão em 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