Perguntas frequentes sobre máquinas virtuais confidenciais do Azure

VMs confidenciais são uma solução IaaS para clientes com alto nível de exigência com relação à segurança e à confidencialidade. As VMs confidenciais oferecem:

• 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.
• A atestação 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 com suporte ao 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 atendem às preocupações dos clientes sobre como mover cargas de trabalho confidenciais do ambiente local para a nuvem. As VMs confidenciais fornecem proteções de nível elevado para os dados do cliente contra a infraestrutura subjacente e os operadores de nuvem. 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 Secure Encrypted Virtualization-Secure Nested Paging. 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 reforçam as proteções do convidado para negar ao hipervisor e a outros códigos de gerenciamento do host o acesso à memória e ao estado da VM. As VMs confidenciais utilizam a SEV-SNP da AMD com tecnologias do Azure, como a criptografia de disco total e o HSM Gerenciado do Azure Key Vault. Você pode criptografar dados em uso, em trânsito e em repouso com as chaves que você controla. Com as funcionalidades integradas do Atestado do Azure, você pode estabelecer de maneira independente a confiança na segurança, no estado de funcionamento 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 Azure Key Vault Managed HSM. Você pode criptografar dados em uso, em trânsito e em repouso 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 capacidade de atestação completa, a criptografia total do disco do sistema operacional e os Módulos de Plataforma Confiável (TPM) 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 a unidade do SO 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 usando a Interface de Linha de Comando do Azure (CLI 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 à atestação 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 Microsoft Atestado do Azure e do Azure Key Vault. As VMs confidenciais também permitem que os usuários executem uma atestação independente para as VMs confidenciais. Essa atestação ocorre usando novas ferramentas chamadas Azure confidential VM Guest Attestation. A atestação de 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, a atestação de plataforma no sistema convidado está disponível. Isso permite que você verifique se sua VM está em execução em 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 atestação independente de operador. O suporte à atestação completa 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 da aplicação guest.

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.

Não, a opção de gerenciamento de chaves (gerenciada pela plataforma ou gerenciada pelo cliente) só está disponível durante a criação da VM e não pode ser alterada posteriormente.

Não, se uma VM Confidencial for criada sem criptografia de disco completo do disco do sistema operacional, uma chave gerenciada pelo cliente não poderá ser usada. Nesse caso, o disco VMGS, que é sempre criptografado, será criptografado usando uma PMK (chave gerenciada pela plataforma).

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 contorna os serviços nativos do Azure, permitindo que você traga sua própria criptografia de disco, gerenciamento de chaves e solução de atestação.
• 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 para outra VM confidencial é permitida em ambas, DCasv5/ECasv5 e DCesv5/ECesv5, nas regiões em comum. 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 o Accelerated Networking. 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. Este erro do 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álises em memória.

Nº 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 confidencial à VM 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 uma taxa mensal de armazenamento. 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 da VM confidencial.

Raramente, algumas VMs do Ubuntu Linux da série DCesv6/ECesv6 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 imagens do Ubuntu Linux, execute as seguintes etapas:

1. Execute este comando para atualizar o arquivo chronyd para desabilitar o uso do serviço de Sincronização de Tempo do IC.

sed -i '/^refclock PHC \/dev\/ptp_hyperv poll 3 dpoll -2 offset 0/s/^/#/' /etc/chrony/chrony.conf

2. Habilite a VM do Linux para usar o Protocolo de Tempo de Rede (NTP) em vez disso.

sed -i '/^#pool.*ntp/s/^#//' /etc/chrony/chrony.conf

3. Reinicie o serviço cronyd para sincronizar com a hora atual.

systemctl restart chronyd.service

Nº. As métricas da plataforma Azure Available Memory Percentage e Available Memory Bytes reportam zero para instâncias confidenciais de VM. Esse comportamento é uma limitação esperada da plataforma, então essas métricas não podem ser usadas como sinais de Autoscale para tipos de nós de VM confidenciais. Use regras de dimensionamento automático baseadas em CPU.