Perguntas frequentes sobre máquinas virtuais confidenciais do Azure

As VMs confidenciais são uma solução IaaS para locatários com altos requisitos de 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.
• O atestado de host ajuda a verificar a integridade total e a conformidade do servidor antes do início do processamento de dados.
• O Módulo de Segurança de Hardware (HSM) pode ser anexado para proteger as chaves de discos VM confidenciais, que o locatário possui exclusivamente.
• Nova arquitetura de inicialização UEFI que suporta o SO convidado para configurações e recursos de segurança aprimorados.
• Um TPM (Trusted Platform Module) virtual dedicado certifica a integridade da VM, fornece gerenciamento de chaves protegido e dá suporte a casos de uso como o BitLocker.

As VMs confidenciais atendem às preocupações dos clientes sobre a movimentação de cargas de trabalho confidenciais fora do local para a nuvem. As VMs confidenciais fornecem proteções elevadas para os dados dos clientes da infraestrutura subjacente e dos operadores de nuvem. Ao contrário de outras abordagens e soluções, você não precisa adaptar suas cargas de trabalho existentes para atender às necessidades técnicas da plataforma.

SEV-SNP significa Secure Encrypted Virtualization-Secure Nested Paging. É 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 de reversão de firmware, proteção de canal lateral e restrições no comportamento de interrupção e exceções. Coletivamente, as tecnologias AMD SEV fortalecem as proteções dos convidados para negar ao hipervisor e a outros códigos de gerenciamento de host acesso à memória e ao estado da VM. As VMs confidenciais aproveitam o AMD SEV-SNP com tecnologias do Azure, como criptografia de disco completo e HSM gerenciado do Azure Key Vault. Você pode criptografar dados em uso, em trânsito e em repouso com chaves que você controla. Com recursos internos de Atestado do Azure, você pode estabelecer confiança de forma independente na segurança, integridade e infraestrutura subjacente de suas VMs confidenciais.

Intel TDX significa Intel Trust Domain Extensions (Intel TDX) É uma tecnologia Trusted Execution Environment (TEE) fornecida pela Intel e oferece várias proteções: Intel TDX usa extensões de hardware para gerenciar e criptografar a memória e protege a confidencialidade e integridade do estado da CPU. Além disso, o Intel TDX ajuda a proteger o ambiente virtualizado, negando o acesso do hipervisor, de outro código de gerenciamento de host e dos administradores à memória e ao estado da VM. As VMs confidenciais combinam o Intel TDX com tecnologias do Azure, como criptografia de disco completo e HSM gerenciado do Azure Key Vault. Você pode criptografar dados em uso, em trânsito e em repouso com 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 baseadas em hardware, como AMD SEV-SNP e Intel TDX, para isolar e proteger criptograficamente a confidencialidade e integridade de seus dados. Nenhum administrador de host ou serviço de host (incluindo o hipervisor do Azure) pode exibir ou modificar diretamente a memória ou o estado da CPU de sua VM confidencial. Além disso, com capacidade total de atestado, criptografia de disco total do sistema operacional e Trusted Platform Modules virtuais protegidos por hardware, o estado persistente é protegido de modo que suas chaves privadas e o conteúdo de sua memória não sejam expostos ao ambiente de hospedagem sem criptografia.

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

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

Não, esse recurso não existe para VMs confidenciais.

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

• Implantar a partir do portal do Azure
• Implantar a partir da Interface de Linha de Comando do Azure (CLI do Azure)
• Implantar usando um modelo ARM
• Implantar usando VMSS e criptografia de disco confidencial

As VMs confidenciais do Azure no AMD SEV-SNP passam por atestado como parte de sua fase de inicialização. Esse processo é opaco para o usuário e ocorre no sistema operacional de nuvem com os serviços Microsoft Azure Attestation e Azure Key Vault. As VMs confidenciais também permitem que os usuários executem atestados independentes para suas VMs confidenciais. Esse atestado acontece usando novas ferramentas chamadas Atestado de Convidado de VM confidencial do Azure. O atestado de convidado permite que os clientes atestem que suas VMs confidenciais estão sendo executadas em processadores AMD com 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 é opaco para o usuário e ocorre usando o Atestado do Microsoft Azure e o Cofre da Chave do Azure. Se você gostaria de ir mais longe para realizar verificações pós-inicialização, o atestado de plataforma no convidado está disponível. Isso permite que você verifique se sua VM está sendo executada no Intel TDX original. Para acessar o recurso, visite nossa ramificação de visualização. Além disso, oferecemos suporte à Intel® Trust Authority para empresas que procuram atestado independente do operador. O suporte para atestado completo no hóspede, semelhante ao AMD SEV-SNP, será disponibilizado em breve. Isso permite que as organizações se aprofundem e validem outros aspetos, até mesmo a camada de aplicativo 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 VMs confidenciais sejam montadas, atestadas e isoladas com segurança da infraestrutura de nuvem subjacente. No futuro, planejamos fornecer orientação sobre como usar uma compilação Linux personalizada e aplicar um conjunto de patches de código aberto para qualificá-la como uma imagem confidencial da VM.

Sim. Você pode usar a Galeria de Computação do Azure para modificar uma imagem confidencial da VM, por exemplo, instalando aplicativos. Em seguida, você pode implantar VMs confidenciais com base na 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 junto com ou em vez de criptografia de disco completo. Se você usar vários esquemas de criptografia de disco, a criptografia dupla pode afetar negativamente o desempenho.

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

N.º Depois de criar uma VM confidencial, não é possível desativar ou reativar a criptografia de disco completo. Em vez disso, crie uma nova VM confidencial.

Os programadores que pretendam uma maior "separação de funções" para os serviços TCB do fornecedor de serviços em nuvem devem utilizar o tipo de segurança "NonPersistedTPM".

• Essa experiência só está disponível como parte da visualização pública do Intel TDX. As organizações que o utilizam, ou prestam serviços com ele, estão no controle do TCB e das responsabilidades que vêm junto com ele.
• Essa experiência ignora os serviços nativos do Azure, permitindo que você traga sua própria solução de criptografia de disco, gerenciamento de chaves e atestado.
• Cada VM ainda tem um vTPM, que deve ser usado para recuperar evidências de hardware, no entanto, o estado 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 desejam dissociar do provedor de serviços de nuvem.

N.º 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 DCasv5/ECasv5 e DCesv5/ECesv5 nas regiões que eles compartilham. Se estiver a utilizar uma imagem do Windows, certifique-se de que tem todas as atualizações mais recentes. Se você estiver usando uma imagem do Ubuntu Linux, certifique-se de estar usando a imagem confidencial do Ubuntu 22.04 LTS com a versão 6.2.0-1011-azuremínima do kernel.

Certifique-se de que selecionou uma região disponível para VMs confidenciais. Certifique-se também de selecionar limpar todos os filtros no seletor de tamanho.

N.º As VMs confidenciais não suportam Rede Acelerada. Não é possível habilitar a Rede Acelerada para qualquer implantação de VM confidencial ou qualquer implantação de cluster do Serviço Kubernetes do Azure que seja executada em Computação Confidencial.

Você pode receber o erro A operação não pôde ser concluída, pois resulta em exceder a cota de núcleos da família DCasv5/ECasv5 padrão aprovado. Este erro de 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 principal grande o suficiente para VMs confidenciais. Crie um pedido de suporte para aumentar a sua quota.

As séries ECasv5 e ECesv5 são tamanhos de VM otimizados para memória, que oferecem uma maior relação memória/CPU. Esses tamanhos são especialmente adequados para servidores de banco de dados relacionais, caches médios a grandes e análises na memória.

N.º No momento, essas VMs estão disponíveis apenas em regiões selecionadas. Para obter uma lista atual de regiões disponíveis, consulte Produtos VM por região.

O Azure não tem procedimentos operacionais para conceder acesso confidencial à VM aos 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 oferecem suporte à virtualização aninhada, como a capacidade de executar um hipervisor dentro de uma VM.

A cobrança de VMs confidenciais depende do seu uso e armazenamento, bem como do tamanho e da região da VM. As VMs confidenciais usam um pequeno disco VMGS (estado convidado da 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 vTPM e UEFI. Esse disco pode resultar em uma taxa de armazenamento mensal. Além disso, se optar por ativar a encriptação total do disco opcional, os discos encriptados do SO incorrem em custos mais elevados. Para obter mais informações sobre taxas 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 apresentar uma pequena diferença de tempo em relação ao UTC. Uma correção de longo prazo está disponível para isso em breve. Enquanto isso, aqui estão as soluções alternativas para Windows e Ubuntu Linux VMs:

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