Soberania, disponibilidade, desempenho e escalabilidade de chave no HSM gerenciado
As chaves criptográficas são a raiz da confiança para proteger sistemas de computador modernos, sejam eles na nuvem ou no local. Dessa forma, controlar quem tem autoridade sobre essas chaves é fundamental para criar aplicativos seguros e compatíveis.
No Azure, nossa visão de como o gerenciamento de chaves deve ser feito na nuvem é a soberania de chave. A soberania de chave significa que a organização do cliente tem controle total e exclusivo sobre quem pode acessar chaves e alterar políticas de gerenciamento de chaves e sobre quais serviços do Azure consomem essas chaves. Depois que essas decisões são tomadas pelo cliente, a equipe da Microsoft é impedida de alterar essas decisões , por meio técnicos. O código do serviço de gerenciamento de chaves executa as decisões do cliente até que o cliente o diga para fazer o contrário, e o pessoal da Microsoft não pode intervir.
Ao mesmo tempo, acreditamos que todos os serviços na nuvem devem ser totalmente gerenciados. O serviço deve fornecer as promessas fundamentais de disponibilidade, resiliência, segurança e nuvem necessárias, apoiadas por SLAs (contratos de nível de serviço). Para fornecer um serviço gerenciado, a Microsoft precisa corrigir servidores de gerenciamento de chaves, atualizar o firmware do HSM (módulo de segurança de hardware), curar hardware com falha, executar failovers e fazer outras operações de alto privilégio. Como a maioria dos profissionais de segurança sabe, negar acesso a alguém com alto privilégio ou acesso físico a um sistema aos dados dentro desse sistema é um problema difícil.
Esse artigo explica como resolvemos esse problema no serviço de HSM Gerenciado do Azure Key Vault (fornecendo aos clientes soberania total e SLAs de serviço totalmente gerenciados) por meio de tecnologia de computação confidencial emparelhada com HSMs.
Ambiente de hardware do HSM Gerenciado
O pool de HSM gerenciado de um cliente em qualquer região do Azure está em um datacenter seguro do Azure. Três instâncias são distribuídas em vários servidores. Cada instância é implantada em um rack diferente para garantir a redundância. Cada servidor tem um Adaptador Marvell LiquidSecurity HSM validado pelo FIPS 140-2 Nível 3 com vários núcleos criptográficos. Os núcleos são usados para criar partições HSM totalmente isoladas, incluindo credenciais totalmente isoladas, armazenamento de dados e controle de acesso.
A separação física das instâncias dentro do datacenter é essencial para garantir que a perda de um único componente (por exemplo, comutador superior do rack, unidade de gerenciamento de energia em um rack) não possa afetar todas as instâncias de um pool. Esses servidores são dedicados à equipe do HSM de Segurança do Azure. Os servidores não são compartilhados com outras equipes do Azure e nenhuma carga de trabalho do cliente é implantada nesses servidores. Controles de acesso físico, incluindo racks bloqueados, são usados para impedir o acesso não autorizado aos servidores. Esses controles atendem ao FedRAMP-High, PCI, SOC 1/2/3, ISO 270x e outros padrões de segurança e privacidade e são verificados regularmente independentemente como parte do programa de conformidade do Azure. Os HSMs aprimoraram a segurança física, validadas para atender aos requisitos do FIPS 140-2 Nível 3. Todo o serviço HSM Gerenciado é criado com base na plataforma segura padrão do Azure, incluindo o Início Confiável, que protege contra ameaças persistentes avançadas (APTs).
Os adaptadores HSM podem dar suporte a dezenas de partições HSM isoladas. A execução em cada servidor é um processo de controle chamado Serviço de Nó. O Serviço de Nó assume a propriedade de cada adaptador e instala as credenciais para o proprietário do adaptador, nesse caso, a Microsoft. O HSM foi projetado para que a propriedade do adaptador não forneça à Microsoft acesso aos dados armazenados em partições do cliente. Ele permite que apenas a Microsoft crie, redimensione e exclua partições do cliente. Ele suporta fazer backups cegos de qualquer partição para o cliente. Um backup cego é encapsulado por uma chave fornecida pelo cliente que pode ser restaurada pelo código de serviço somente dentro de uma instância de HSM gerenciado pertencente ao cliente e cujo conteúdo não é legível pela Microsoft.
Arquitetura de um pool de HSM gerenciado
A Figura 1 mostra a arquitetura de um pool de HSM, que consiste em três VMs Linux, cada uma em execução em um servidor HSM em seu próprio rack de datacenter para dar suporte à disponibilidade. Os componentes importantes são:
- O controlador de malha HSM (HFC) é o painel de controle do serviço. O HFC conduz a aplicação de patches e reparos automatizados para o pool.
- Um limite criptográfico exclusivo para cada cliente composto por três enclaves confidenciais do Intel Secure Guard Extensions (Intel SGX) conectados a três instâncias de HSM compatíveis com FIPS 140-2 Nível 3. As chaves raiz para esse limite são geradas e armazenadas nos três HSMs. Como descrevemos posteriormente nesse artigo, nenhuma pessoa associada à Microsoft tem acesso aos dados que estão dentro desse limite. Só o código de serviço sendo executado poelo enclave Intel do SGX (incluindo o agente de Serviço de Nó), agindo em nome do cliente, tem acesso.
Ambiente de execução confiável (TEE)
Um pool de HSM gerenciado consiste em três instâncias de serviço. Cada instância de serviço é implementada como um TEE (ambiente de execução confiável) que usa recursos do Intel SGX e o SDK do Open Enclave. A execução em um TEE garante que ninguém na máquina virtual (VM) que hospeda o serviço ou o servidor host da VM tenha acesso a segredos do cliente, dados ou à partição HSM. Cada TEE é dedicado a um cliente específico e executa o gerenciamento de TLS, o tratamento de solicitações e o controle de acesso à partição HSM. Não existem credenciais ou chaves de criptografia de dados específicas do cliente no texto de limpeza fora desse TEE, exceto como parte do pacote domínio de segurança. Esse pacote é criptografado para uma chave fornecida pelo cliente e baixa quando o pool é criado pela primeira vez.
Os TEEs se comunicam entre si usando TLS atestado. O TLS atestado combina as funcionalidade do atestado remoto da plataforma do Intel SGX com o TLS 1.2. Isso permite que o código do HSM gerenciado no TEE limite sua comunicação a apenas outros códigos assinados pela mesma chave de assinatura de código de serviço MHSM gerenciado, para impedir ataques do tipo man-in-the-middle. A chave de assinatura de código do serviço do HSM gerenciado é armazenada no Serviço de Segurança e Lançamento de Produtos da Microsoft (que também é usado para armazenar, por exemplo, a chave de assinatura de código do Windows). A chave é controlada pela equipe de HSM gerenciada. Como parte de nossas obrigações regulatórias e de conformidade para o gerenciamento de alterações, essa chave não pode ser usada por nenhuma outra equipe da Microsoft para assinar seu código.
Os certificados TLS usados para comunicação TEE-to-TEE são emitidos automaticamente pelo código de serviço dentro do TEE. Os certificados contêm um relatório de plataforma gerado pelo enclave do Intel SGX no servidor. O relatório de plataforma é assinado com chaves derivadas de chaves fundidas pela Intel na CPU quando ele é fabricado. O relatório identifica o código carregado no enclave do Intel SGX por sua chave de assinatura de código e hash binário. Com esse relatório de plataforma, as instâncias de serviço podem determinar que um par também é assinado pela chave de assinatura de código do serviço do HSM gerenciado e, com algum emaranhamento de criptografia por meio do relatório de plataforma, também podem determinar que a chave de assinatura de certificado autoemitida também deve ter sido gerada dentro do TEE, para impedir a representação externa.
Oferecer SLAs de disponibilidade com controle de chave gerenciado pelo cliente completo
Para garantir a alta disponibilidade, o serviço HFC cria três instâncias de HSM na região do Azure selecionada pelo cliente.
Criação de pool de HSM gerenciado
As propriedades de alta disponibilidade dos pools de HSM Gerenciado vêm das instâncias HSM com redundância tripla gerenciadas automaticamente que são sempre mantidas em sincronia (ou se você estiver usando a replicação de várias regiões, de manter todas as seis instâncias sincronizadas). A criação do pool é gerenciada pelo serviço HFC que aloca pools entre o hardware disponível na região do Azure escolhida pelo cliente.
Quando um novo pool é solicitado, o HFC seleciona três servidores em vários racks que tem espaço disponível em seus adaptadores HSM e começa a criar o pool:
O HFC instrui os agentes do Serviço de Nó em cada um dos três TEEs a iniciar uma nova instância do código de serviço usando um conjunto de parâmetros. Os parâmetros identificam o locatário do Microsoft Entra do cliente, os endereços IP da rede virtual interna das três instâncias e algumas outras configurações de serviço. Uma partição é atribuída aleatoriamente como Primária.
As três instâncias são iniciadas. Cada instância se conecta a uma partição em seu adaptador HSM local e, em seguida, zera e inicializa a partição usando nomes de usuário e credenciais gerados aleatoriamente (para garantir que a partição não possa ser acessada por um operador humano ou por outra instância TEE).
A instância primária cria um certificado raiz do proprietário da partição usando a chave privada gerada no HSM. Ele estabelece a propriedade do pool assinando um certificado no nível de partição para a partição HSM usando esse certificado raiz. A primária também gera uma chave de criptografia de dados, que é usada para proteger todos os dados inativos do cliente dentro do serviço. Para material de chave, um encapsulamento duplo é usado porque o HSM também protege o próprio material de chave.
Em seguida, esses dados de propriedade são sincronizados com as duas instâncias secundárias. Cada secundária entra em contato com a primária por meio do TLS atestado. A primária compartilha o certificado raiz do proprietário da partição com a chave privada e a chave de criptografia de dados. As secundárias agora usam o certificado raiz da partição para emitir um certificado de partição para suas próprias partições de HSM. Depois que isso for feito, você tem partições de HSM em três servidores separados pertencentes ao mesmo certificado raiz de partição.
Sobre o link TLS atestado, a partição de HSM do primário compartilha com os secundários sua chave de encapsulamento de dados gerada (usada para criptografar mensagens entre os três HSMs), por meio de uma API segura fornecida pelo fornecedor de HSM. Durante essa troca, os HSMs confirmam que têm o mesmo certificado de proprietário da partição e usam um esquema de Diffie-Hellman para criptografar as mensagens de modo que o código de serviço da Microsoft não possa lê-las. Tudo o que o código de serviço pode fazer é transportar blobs opacos entre os HSMs.
Neste ponto, todas as três instâncias estão prontas para serem expostas como um pool na rede virtual do cliente. Elas compartilham o mesmo certificado de partição do servidor e chave privada, a mesma chave de criptografia de dados e uma chave de agrupamento de dados comum. No entanto, cada instância tem credenciais exclusivas para suas partições de HSM. Agora, as etapas finais foram concluídas.
Cada instância gera um par de chaves RSA e uma solicitação de assinatura de certificado (CSR) para seu certificado TLS voltado para o público. A CSR é assinada pelo sistema infraestrutura de chave pública (PKI) da Microsoft usando uma raiz pública da Microsoft e o certificado TLS resultante é retornado para a instância.
Todas as três instâncias obtêm sua própria chave de vedação Intel SGX de sua CPU local. A chave é gerada usando a própria chave exclusiva da CPU e a chave de assinatura de código do TEE.
O pool deriva uma chave de pool exclusiva das chaves de vedação do Intel SGX, criptografa todos os segredos com essa chave de pool e grava os blobs criptografados no disco. Esses blobs só podem ser descriptografados por código assinado pela mesma chave de vedação SGX, em execução na mesma CPU física. Os segredos estão vinculados a essa instância específica.
O processo de inicialização segura agora está concluído. Esse processo permitiu a criação de um pool de HSM com redundância tripla e a criação de uma garantia criptográfica da soberania dos dados do cliente.
Como manter SLAs de disponibilidade em runtime usando a recuperação de serviço confidencial
O texto de criação do pool descrito nesse artigo pode explicar como o serviço HSM Gerenciado é capaz de fornecer seus SLAs de alta disponibilidade gerenciando com segurança os servidores subjacentes ao serviço. Imagine que um servidor ou um adaptador HSM ou até mesmo a fonte de alimentação para o rack falhe. O objetivo do serviço HSM gerenciado é, sem qualquer intervenção do cliente ou a possibilidade de segredos serem expostos em texto não criptografado fora do TEE, corrigir o pool de volta para três instâncias íntegras. Isso é feito por meio da recuperação de serviço confidencial.
Tudo começa com o HFC descobrindo quais pools tinham instâncias no servidor com falha. O HFC localiza novos servidores íntegros dentro da região do pool para implantar as instâncias de substituição. Ele inicia novas instâncias, que são tratadas exatamente como uma secundária durante a etapa de provisionamento inicial: inicializar o HSM, localizar seus segredos primários e trocar com segurança por TLS atestado, assinar o HSM na hierarquia de propriedade e, em seguida, selar seus dados de serviço para sua nova CPU. O serviço agora está reparado, totalmente automatizado e confidencial.
Como se recuperando de um desastre usando o domínio de segurança
O domínio de segurança é um blob seguro que contém todas as credenciais necessárias para recompilar a partição HSM do zero: a chave de proprietário da partição, as credenciais de partição, a chave de encapsulamento de dados, além de um backup inicial do HSM. Antes que o serviço fique ativo, o cliente deve baixar o domínio de segurança fornecendo um conjunto de chaves de criptografia RSA para protegê-lo. Os dados do domínio de segurança se originam nos TEEs e são protegidos por uma chave simétrica gerada e uma implementação do algoritmo de Compartilhamento Secreto do Shamir que divide os compartilhamentos de chave entre as chaves públicas RSA fornecidas pelo cliente de acordo com os parâmetros de quorum selecionados pelo cliente. Durante esse processo, nenhuma das chaves de serviço ou credenciais são expostas em texto não criptografado fora do código de serviço que está executando essas chaves. Somente o cliente, apresentando um quorum de suas chaves RSA para o TEE, pode descriptografar o domínio de segurança durante um cenário de recuperação.
O domínio de segurança é necessário apenas quando, devido a alguma catástrofe, toda uma região do Azure é perdida e a Microsoft perde todas as três instâncias do pool simultaneamente. Se apenas uma ou até duas instâncias forem perdidas, o serviço confidencial será recuperado silenciosamente em três instâncias íntegras sem intervenção do cliente. Como as chaves de vedação do Intel SGX são exclusivas para cada CPU, se toda a região for perdida, a Microsoft não tem como recuperar as credenciais de HSM e as chaves de proprietário da partição. Elas existem somente dentro do contexto das instâncias.
No caso extremamente improvável dessa catástrofe acontecer, o cliente pode recuperar o estado e os dados do pool anterior criando um novo pool em branco e injetando-os no domínio de segurança e, em seguida, apresentando seu quorum de chave RSA para provar a propriedade do domínio de segurança. Se um cliente habilitou a replicação de várias regiões, a catástrofe ainda mais improvável de ambas as regiões que enfrentam uma falha simultânea e completa teria que acontecer antes que a intervenção do cliente fosse necessária para recuperar o pool do domínio de segurança.
Como controlar o acesso ao serviço
Como descrevemos, nosso código de serviço no TEE é a única entidade com acesso ao HSM em si, pois as credenciais necessárias não são fornecidas ao cliente ou a qualquer outra pessoa. Em vez disso, o pool do cliente está associado à instância do Microsoft Entra e isso é usado para autenticação e autorização. No provisionamento inicial, o cliente pode escolher um conjunto inicial de funcionários para atribuir a função de Administrador para o pool. Esses indivíduos e os funcionários na função de Administrador Global do locatário do Microsoft Entra do cliente, podem definir políticas de controle de acesso dentro do pool. Todas as políticas de controle de acesso são armazenadas pelo serviço no mesmo banco de dados que as chaves mascaradas, que também são criptografadas. Somente o código de serviço no TEE tem acesso a essas políticas de controle de acesso.
Resumo
O HSM gerenciado elimina a necessidade de os clientes fazerem compensações entre disponibilidade e controle sobre chaves criptográficas por meio de tecnologia de enclave confidencial com suporte de hardware de ponta. Conforme discutido nesse artigo, nessa implementação, nenhum pessoal da Microsoft ou representante pode acessar o material da chave gerenciada pelo cliente ou segredos relacionados, mesmo com acesso físico aos HSMs e computadores host HSM gerenciados. Essa segurança permitiu que nossos clientes nos serviços financeiros, manufatura, setor público, defesa e outras verticais acelerassem sua migração para a nuvem com total confiança.