O Azure Database for PostgreSQL – Flexible Server agora suporta, em preview pública, o uso de chaves gerenciadas pelo cliente (CMK) que residem em um Azure Key Vault de outro tenant do Microsoft Entra ID (anteriormente Azure Active Directory). Isso significa que você pode criptografar dados em repouso com uma chave que não está no mesmo tenant do banco de dados.
TL;DR: A funcionalidade permite que empresas brasileiras usem uma chave de criptografia localizada em um tenant diferente do Microsoft Entra ID para proteger dados no PostgreSQL Flexible Server. Na prática, isso resolve cenários comuns em fusões, aquisições ou estruturas de compliance onde a chave precisa ficar isolada em um tenant separado. Contudo, a preview traz limitações de SLA, latência e custos de egress que exigem atenção antes de levar para produção.
Por que isso importa para quem opera bancos de dados críticos no Brasil?
Empresas brasileiras que lidam com dados sensíveis (LGPD, setor financeiro, saúde) frequentemente precisam isolar chaves de criptografia em ambientes separados por questões de governança. Até agora, se você quisesse usar CMK no Azure Database for PostgreSQL – Flexible Server, a chave precisava estar no mesmo tenant do banco. Isso forçava arquiteturas complexas: replicar chaves entre tenants, usar soluções de terceiros ou até manter dados fora do Azure.
Com o cross-tenant CMK, você pode, por exemplo:
- Cenário de fusão ou aquisição: Empresa A (tenant A) adquire Empresa B (tenant B). Os bancos da Empresa B podem continuar usando as chaves do tenant A sem migrar dados ou chaves.
- Compliance com regulamentações setoriais: Uma fintech brasileira precisa que a chave de criptografia esteja em um tenant controlado por um conselho independente (ex: um trust), enquanto o banco de dados opera em outro tenant operacional.
- Separação de responsabilidades: O time de segurança gerencia o Key Vault em um tenant dedicado, enquanto a engenharia de dados opera os bancos em outro, sem acesso direto às chaves.
Como funciona na prática?
A funcionalidade utiliza a autenticação entre tenants do Microsoft Entra ID. Você configura o Key Vault no tenant A, concede permissões ao tenant B (onde está o PostgreSQL Flexible Server) via RBAC ou políticas de acesso, e então habilita a CMK no banco apontando para a chave remota. A criptografia e descriptografia são feitas pelo Azure, que acessa a chave no Key Vault do outro tenant.
Pontos de atenção:
- Preview sem SLA: Não há garantias de disponibilidade ou performance. Teste em não produção.
- Latência: Acesso a chave entre tenants adiciona latência – pode impactar operações de write intensivo ou rotação de chaves.
- Custos de egress: Tráfego entre o Key Vault e o banco pode gerar custos, dependendo da distância entre regiões e do volume de operações.
- Rotação de chaves: A rotação automática ainda não é suportada entre tenants; será necessário reatribuir a chave manualmente.
- Dependência de conectividade: Se a rede entre tenants falhar, o banco pode ficar inacessível – planeje failover.
Ilustração da arquitetura: o PostgreSQL Flexible Server no Tenant B criptografa dados usando uma chave no Key Vault do Tenant A, com autenticação via Microsoft Entra ID.
Comparação com outras abordagens de criptografia
| Abordagem | Onde a chave reside | Complexidade | Custo | Ideal para |
|---|---|---|---|---|
| Chave gerenciada pelo Azure (padrão) | No próprio Azure, no mesmo tenant | Baixa | Gratuito | Cenários sem requisitos especiais de compliance |
| CMK no mesmo tenant | Key Vault no mesmo tenant que o banco | Média | Custo do Key Vault + chave | Maioria das empresas que precisam de controle de chave |
| Cross-tenant CMK (nova) | Key Vault em tenant diferente | Alta (configuração de RBAC multi-tenant) | Custo do Key Vault + egress + possíveis taxas de preview | Fusões, aquisições, trust separado, compliance rigoroso |
| Chave armazenada em HSM externo | Fora do Azure (ex: AWS CloudHSM) | Muito alta | Alto (egress, HW) | Cenários multi-cloud ou regulamentações específicas |
O que isso significa para FinOps e SecOps?
Para times de FinOps, o custo adicional de egress entre tenants deve ser incluído no TCO (Total Cost of Ownership). Se o volume de operações de criptografia for alto, o custo pode superar o benefício de isolamento. Já para SecOps, a separação de tenants reduz a superfície de ataque: um comprometimento do banco não dá acesso direto à chave. Porém, a dependência de conectividade entre tenants cria um novo ponto de falha que precisa ser monitorado com observability.
Quando vale a pena usar?
A funcionalidade é mais útil quando você já tem uma razão forte para manter chaves em outro tenant — por exemplo, compliance com a LGPD (artigo 46: segurança e sigilo), instruções normativas do Banco Central, ou contratos com clientes que exigem isolamento de chaves. Se você não tem essa necessidade, o CMK no mesmo tenant é mais simples e barato.
Perguntas Frequentes
-
O que é cross-tenant CMK e por que isso é relevante para o Brasil?
Cross-tenant CMK permite que você criptografe dados no Azure Database for PostgreSQL – Flexible Server usando uma chave armazenada em um Azure Key Vault de outro tenant do Microsoft Entra ID. Para empresas brasileiras com subsidiárias, fusões recentes ou exigências de compliance (como LGPD), isso evita a replicação de chaves entre tenants, simplificando a gestão de segurança sem migrar dados. -
Quais são os principais riscos ao adotar essa preview?
Como está em preview pública, não há SLA formal. A rotação de chaves entre tenants pode ter latência adicional, e falhas de rede ou de autorização entre tenants podem bloquear o acesso ao banco. Além disso, custos de egress entre tenants e o Key Vault devem ser considerados. Recomenda-se testar em ambientes não críticos primeiro. -
Como isso afeta estratégias de multi-cloud ou híbrido?
Para empresas que usam Azure e outros provedores (como AWS ou GCP), essa funcionalidade não resolve criptografia cross-cloud diretamente. Mas, dentro do ecossistema Azure, facilita cenários onde um tenant gerencia identidades e outro armazena dados, comum em organizações com BUs separadas ou após aquisições. Ainda é necessário manter chaves em cada nuvem para dados fora do Azure. -
Quais são os pré-requisitos técnicos para implementar?
É necessário ter um Azure Key Vault com uma chave RSA (tamanho 2048, 3072 ou 4096) habilitada para soft delete e purge protection, além de configurar permissões de RBAC entre os tenants. O PostgreSQL Flexible Server precisa estar na região suportada e com a opção de CMK habilitada. A rotação automática de chaves ainda não é suportada entre tenants – apenas manual.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
