Internet & Redes · Azure · Segurança · Criptografia · Compliance

✎ Duarte Spinola  |  2026-07-15

Gestão de Chaves Externas no Azure Managed HSM: BYOK e Integração com PKI On-Premise

O Azure Managed HSM é um serviço de HSM (Hardware Security Module) totalmente gerido pela Microsoft, validado FIPS 140-2 Level 3, que armazena e processa chaves criptográficas em hardware dedicado. Até agora, as chaves tinham de residir dentro do HSM gerido pela Microsoft. Com a funcionalidade de External Key Management (actualmente em public preview, anunciada em 7 de Julho de 2026 no blog do Azure), as organizações podem manter as chaves criptográficas na sua própria infraestrutura — um HSM on-premise, um módulo de segurança externo ou um KMS dedicado — e o Managed HSM delega as operações criptográficas nesse hardware remoto.

Isto resolve um problema fundamental para PME sujeitas a requisitos regulamentares rigorosos (RGPD, NIS2, normas do sector financeiro ou saúde): a chave mestra que cifra discos, bases de dados e comunicações nunca sai da infraestrutura da organização. A Microsoft processa a cifragem/descifragem mas não tem acesso ao material criptográfico. Este artigo explica o conceito BYOK neste contexto, a integração com PKI on-premise e os passos de configuração prática.

O que é o Azure Managed HSM

O Azure Managed HSM é um serviço cloud que fornece instâncias de HSM dedicadas e totalmente geridas, baseadas em hardware validado FIPS 140-2 Level 3. Ao contrário do Azure Key Vault Standard (que armazena chaves em software protegido por HSM Level 2), o Managed HSM oferece um domínio de segurança isolado — a Microsoft não consegue aceder às chaves nem aos comandos de HSM administrativos. O cliente controla integralmente o ciclo de vida das chaves, as políticas de acesso e a auditoria (Microsoft Learn — Managed HSM Overview).

As principais características são:

• HSM dedicado de inquilino único — cada instância é exclusiva ao cliente, sem partilha de hardware entre organizações.
• Validação FIPS 140-2 Level 3 — resistência física a tampering e extracção de chaves.
• RBAC local do Azure — controlo de acesso granular baseado em papéis (Microsoft Learn — Managed HSM Access Control).
• Domínio de segurança — um ficheiro cifrado que funciona como backup criptográfico da instância; sem ele, a recuperação é impossível.
• Suporte para chaves RSA, EC e AES com operações de cifragem, assinatura, verificação, wrap/unwrap.
• Integração nativa com Azure Storage, SQL Database, Disk Encryption e Cosmos DB para Customer-Managed Keys (Microsoft Learn — Quickstart CLI).

O serviço foi concebido para cenários onde o Key Vault Standard não é suficiente: sectores regulados (banca, saúde, governo), requisitos de soberania de dados e casos em que uma chave comprometida tem consequências catastróficas (Microsoft Learn — Key Vault Security Features).

BYOK: O que significa na prática

BYOK (Bring Your Own Key) é o conceito de o cliente gerar e possuir as suas próprias chaves criptográficas, em vez de as gerar dentro do serviço cloud. No contexto tradicional do Azure Key Vault, BYOK significava importar uma chave protegida por HSM para o Key Vault — a chave residia no HSM da Microsoft mas era originada pelo cliente.

Com o External Key Management no Managed HSM, o BYOK dá um passo em frente: a chave não é importada para a Microsoft — permanece no hardware do cliente. O fluxo é o seguinte:

O HSM on-premise executa a operação criptográfica e envia apenas o resultado (texto cifrado ou texto limpo) de volta ao Managed HSM. A chave em si nunca atravessa a rede em texto claro. Isto é diferente do modelo de import (BYOK clássico) onde a chave é empacotada e enviada para o HSM cloud uma vez, ficando lá armazenada (Microsoft Learn — Key Vault Keys).

External Key Management: Benefícios

A funcionalidade foi anunciada em public preview a 7 de Julho de 2026 (Azure Blog — External Key Management for Managed HSM). Os benefícios tênicos e de negócio são:

Compliance, RGPD e Cenários Regulamentares

O RGPD (Regulamento Geral de Protecção de Dados) não especifica directamente o tipo de cifragem a usar, mas o Artigo 32 exige “medidas técnicas e organizacionais adequadas” para proteger dados pessoais. A cifragem é explicitamente nomeada como exemplo de medida adequada. Para dados pessoais sensíveis (Artigo 9 — dados de saúde, biométricos, genéticos), a prática de segurança é cifragem com chaves geridas pelo responsável pelo tratamento — não pelo fornecedor de cloud (Microsoft Learn — Compliance).

A tabela seguinte resume os cenários regulamentares mais comuns onde o External Key Management é relevante:

A integração com o Azure Policy permite impor que determinados recursos (bases de dados, contas de armazenamento) tenham de usar chaves geridas pelo HSM com external key management, bloqueando implementações que usem chaves geridas pela Microsoft (Microsoft Learn — Azure Policy).

Integração com PKI On-Premise

A integração entre o Azure Managed HSM e uma PKI (Public Key Infrastructure) on-premise funciona através de um secure channel estabelecido entre o HSM cloud e o KMS local. A arquitetura típica envolve os seguintes componentes:

• HSM on-premise — hardware físico (ex.: Thales Luna, Utimaco SecurityServer, Entrust nShield) que armazena a chave mestra.
• Adaptador de ligação — software que faz a ponte entre o KMS local e o Managed HSM, tipicamente exposto via API REST sobre mTLS (mutual TLS).
• Managed HSM — recebe pedidos dos serviços de dados do Azure e encaminha operações criptográficas para o KMS externo.
• Serviços de dados — Azure SQL, Storage, Disk Encryption que precisam de cifragem com chaves geridas pelo cliente.

O protocolo de comunicação usa certificados mútuos: o HSM cloud autentica-se perante o KMS local e vice-versa. A ligação é persistente (mantida aberta) e cada operação criptográfica é registada em ambos os lados. Se a ligação for interrompida, o Managed HSM entra em modo degradado: aceita pedidos mas não consegue executar operações que dependam da chave externa até que a conectividade seja restaurada (Microsoft Learn — Managed HSM Logging).

No contexto de uma PKI on-premise que já emite certificados para Active Directory, IIS, VPNs e outros serviços internos, o External Key Management permite que a mesma chave raiz usada para assinar certificados internos seja também usada para cifrar dados em repouso no Azure — sem a duplicar nem a exportar para a cloud.

Configuração Passo a Passo

Os passos seguintes descrevem o fluxo de configuração do External Key Management com um HSM on-premise. Os comandos da CLI do Azure são baseados na documentação oficial (Microsoft Learn — Managed HSM CLI Quickstart). Esta secção segue os comandos documentados; os passos de ligação ao KMS externo referem-se à pré-visualização pública e devem ser validados em ambiente de teste antes de produção.

Passo 1 — Criar uma instância de Managed HSM

Antes de criar o HSM, registe o provider de recursos e defina as variáveis de ambiente:

Sintaxe documentada em Microsoft Learn — Quickstart CLI. Testado contra a referência da CLI do Azure v2.60+, 2026-07-15.

Passo 2 — Configurar o domínio de segurança

Após a criação, o HSM fica num estado não activo. É necessário inicializar o domínio de segurança, que funciona como backup criptográfico:

Passo 3 — Configurar o External Key Provider

A configuração do external key management envolve registar o KMS on-premise como um provider externo. Esta funcionalidade usa a API de extensão do Managed HSM e requer a pré-visualização activa na subscrição:

O parâmetro --external-key-endpoint aponta para o adaptador do KMS local. O certificado (--external-key-cert-path) é usado para autenticação mTLS. A sintaxe exata pode variar consoante a versão da preview; consultar a documentação oficial mais recente (Microsoft Learn — Managed HSM).

Passo 4 — Criar uma chave referenciada ao KMS externo

Passo 5 — Configurar RBAC para acesso ao HSM

O Managed HSM usa RBAC local do Azure (não herda as access policies do Key Vault Standard). Atribua o papel apropriado ao service principal da aplicação:

Sintaxe documentada em Microsoft Learn — Managed HSM Role Management.

Passo 6 — Associar a chave a um serviço de dados

Para usar a chave externa na cifragem de um Azure SQL Database, por exemplo:

Passo 7 — Activar logging e auditoria

Preços e Modelos de Licenciamento

O preço do Azure Managed HSM é baseado em preço por hora de instância activa, independentemente do número de chaves ou operações. Os valores abaixo são indicativos para a região West Europe (Azure Pricing — Key Vault):

Cenários Práticos para PME

Para uma PME portuguesa típica (50–250 funcionários), o External Key Management pode parecer um investimento excessivo, mas existem cenários onde faz sentido:

A regra geral éo seguinte: se a organização já tem um HSM on-premise (tipicamente para AD CS, VPN ou assinatura digital de documentos), o External Key Management permite estender esse investimento ao Azure sem duplicar chaves. Se não tem HSM on-premise, o Managed HSM sem external key (BYOK clássico) é mais simples e económico (Microsoft Learn — Azure Security Fundamentals).

Erros Comuns e Soluções

Checklist Rápido de Verificação

• ✓ Provider Microsoft.KeyVault registado na subscrição
• ✓ Feature preview “ManagedHSMExternalKeyManagement” activada e propagada
• ✓ Domínio de segurança exportado e guardado em múltiplas cópias offline
• ✓ KMS on-premise acessível a partir do Azure via mTLS (ExpressRoute ou VPN site-to-site)
• ✓ Certificados mútuos gerados com validade > 1 ano e processo de renovação definido
• ✓ Papéis RBAC atribuídos ao service principal (Crypto Officer + Crypto User)
• ✓ Diagnostic settings activados para auditoria (Log Analytics Workspace)
• ✓ Azure Policy configurado para impor CMK em recursos críticos
• ✓ Plano de contingência para indisponibilidade do KMS on-premise testado
• ✓ Monitorização de latência das operações externas com alertas

Artigos Relacionados

• Internet & Redes — Todos os artigos
• Segurança IT — Artigos de cibersegurança