Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Secure Key Release (SKR) é uma funcionalidade do Azure Key Vault (AKV) Managed HSM and Premium offering. A liberação segura de chaves permite a liberação de uma chave protegida por HSM do AKV para um Ambiente de Execução Confiável (TEE) atestado, como um enclave seguro, TEEs baseados em VM, etc. O SKR adiciona outra camada de proteção de acesso às suas chaves de descriptografia/criptografia de dados, onde você pode direcionar um aplicativo + ambiente de tempo de execução TEE com configuração conhecida obter acesso ao material da chave. As políticas de SKR definidas no momento da criação da chave exportável regem o acesso a essas chaves.
Suporte para SKR com soluções de AKV
Fluxo geral seguro de liberação de chaves com TEE
A SKR só pode liberar chaves com base nas declarações geradas pelo Microsoft Azure Attestation (MAA). Há uma integração estreita na definição da política SKR com reivindicações MAA.
Os passos abaixo são para AKV Premium.
Etapa 1: Criar um Vault de Chaves Premium com suporte HSM
Siga os detalhes aqui para a criação de AKV baseada em Az CLI
Certifique-se de definir o valor de [--sku] como "premium".
Etapa 2: Criar uma política de liberação de chave segura
Uma Política de Liberação de Chave Segura é uma política de liberação de formato json, conforme definido aqui , que especifica um conjunto de declarações necessárias, além da autorização para liberar a chave. As alegações aqui são baseadas em MAA, conforme referido aqui para SGX e aqui para AMD SEV-SNP CVM.
Visite a página de exemplos específicos de TEE para obter mais detalhes. Para obter mais informações sobre a gramática da política SKR, consulte Gramática da política de liberação segura de chaves do Azure Key Vault.
Antes de definir uma política SKR, certifique-se de executar seu aplicativo TEE por meio do fluxo de atestado remoto. O atestado remoto não é abordado como parte deste tutorial.
Exemplo
{
"version": "1.0.0",
"anyOf": [ // Always starts with "anyOf", meaning you can multiple, even varying rules, per authority.
{
"authority": "https://sharedweu.weu.attest.azure.net",
"allOf": [ // can be replaced by "anyOf", though you cannot nest or combine "anyOf" and "allOf" yet.
{
"claim": "x-ms-isolation-tee.x-ms-attestation-type", // These are the MAA claims.
"equals": "sevsnpvm"
},
{
"claim": "x-ms-isolation-tee.x-ms-compliance-status",
"equals": "azure-compliant-cvm"
}
]
}
]
}
Etapa 3: Criar uma chave exportável no AKV com a política SKR anexada
Detalhes exatos do tipo de chave e outros atributos associados podem ser encontrados aqui.
az keyvault key create --exportable true --vault-name "vault name from step 1" --kty RSA-HSM --name "keyname" --policy "jsonpolicyfromstep3 -can be a path to JSON"
Etapa 4: Aplicativo em execução dentro de um TEE fazendo um atestado remoto
Esta etapa pode ser específica para o tipo de TEE a executar o seu aplicativo; os Intel SGX Enclaves; ou as Máquinas Virtuais Confidenciais (CVM) baseadas em AMD SEV-SNP; ou os Contêineres Confidenciais executados em Enclaves CVM com AMD SEV-SNP, etc.
Siga estes exemplos de referências para várias ofertas de tipos de TEE com o Azure:
- Aplicação dentro da arquitetura AMD EV-SNP em CVM's que realiza Liberação Segura de Chaves
- Contentores confidenciais com Instâncias de Contentor do Azure (ACI) com contentores auxiliares SKR
- Aplicativos baseados em Intel SGX que executam Secure Key Release - Solução de código aberto Mystikos Implementation
Perguntas Frequentes (FAQ)
Posso realizar SKR com ofertas de computação não confidencial?
Sim. A Libertação Segura de Chaves é uma funcionalidade do Azure Key Vault Premium e do HSM Gerido. A operação de disponibilização valida um token Microsoft Azure Attestation (MAA) assinado em relação com a política de disponibilização da chave, independentemente do tipo de computação. As ofertas de computação confidencial (VMs confidenciais, containers confidenciais) são a fonte mais comum destes tokens porque transportam reivindicações TEE baseadas em hardware, mas não são obrigatórias. As VMs de Lançamento Confiável também produzem tokens de atestação MAA — por exemplo, a secureboot reivindicação e as reivindicações PCR medidas x-ms-azurevm-attested-pcr-values por vTPM — e uma política de lançamento pode bloquear a libertação da chave nessas reivindicações. Para os requisitos de tokens e a estrutura das reivindicações, consulte a gramática da política de libertação de chaves seguras do Azure Key Vault. A computação confidencial protege adicionalmente, contra o anfitrião, o material de chave exposto na memória; utilize uma solução de computação confidencial quando essa proteção for necessária.
Posso trazer meu próprio provedor de atestado ou serviço e usar essas reivindicações para AKV validar e liberar?
O Microsoft Azure Attestation é o serviço de atestação integrado nativamente. Uma política de lançamento também pode validar tokens de outra autoridade de atestado, desde que o token esteja em conformidade com a estrutura esperada, suporte OpenID Connect, contenha as reivindicações esperadas e seja assinado por um certificado que se liga a uma CA pública em que a Key Vault confia — atualmente DigiCert. Para mais informações, consulte a gramática da política de libertação de chaves seguras do Azure Key Vault.
Posso usar SDKs AKV para executar a liberação de chave?
Sim. SDK mais recente integrado com a chave de suporte da API AKV 7.3 RELEASE.
Você pode compartilhar alguns exemplos das principais políticas de lançamento?
Sim, exemplos detalhados por tipo de TEE estão listados aqui.
Posso associar uma política do tipo SKR a certificados e chaves?
Não. Neste momento, não.
Referências
CVM em aplicações AMD SEV-SNP com exemplo de liberação de chave segura
API REST do AKV com detalhes SKR
Gramática da política de liberação segura de chaves do Azure Key Vault
Proteja a propriedade intelectual em VMs do Azure com o Secure Key Release controlado por atestação