AWS Secrets Manager vs Azure Key Vault vs GCP Secret Manager: Análise Detalhada 2026

Escolher a solução certa para gerenciamento de secrets na nuvem em 2026 envolve mais do que listas de recursos. Trata-se de implicações diretas de custo, overhead operacional, profundidade de integração dentro de um ecossistema de nuvem específico e posturas de compliance. Esta análise vai além do marketing para detalhar AWS Secrets Manager (incluindo Parameter Store para casos de uso específicos), Azure Key Vault (abrangendo os tiers Standard, Premium e Managed HSM) e Google Secret Manager (com interoperabilidade Cloud KMS). Nosso foco está na diferenciação técnica e no ajuste estratégico para casos de uso corporativos.

Capacidades Essenciais e Paradigmas de Design

AWS Secrets Manager (ASM) prioriza a automação e ampla integração. Sua função principal é armazenar, recuperar e rotacionar secrets. Secrets podem ser desde credenciais de banco de dados até chaves de API. O ASM se integra diretamente com RDS, Redshift e DocumentDB para rotação nativa. Enquanto o KMS criptografa os secrets em repouso, o ASM gerencia o ciclo de vida. O AWS Parameter Store, frequentemente negligenciado para secrets, pode armazenar secrets menores e menos sensíveis (até 10KB) a um custo menor, atuando como um armazenamento de configuração hierárquico com criptografia KMS opcional. A distinção é crítica: Parameter Store é para configuração, Secrets Manager para credenciais.

Azure Key Vault (AKV) é um serviço unificado para secrets, chaves e certificados. Essa consolidação reduz o overhead de gerenciamento para ambientes com grande uso de PKI ou que precisam de armazenamento de chaves com suporte de hardware. AKV oferece Standard (chaves com suporte de software) e Premium (chaves com suporte de HSM FIPS 104-2 Level 2 validado). Azure Managed HSM é um serviço de HSM dedicado, single-tenant, FIPS 140-2 Level 3 validado, fornecendo um nível mais alto de garantia para operações criptográficas críticas, incluindo chaves importáveis. A escolha arquitetural entre esses tiers impacta diretamente a postura de segurança e o custo.

Google Secret Manager (GSM) é projetado para simplicidade e acessibilidade global desde o início. Secrets são recursos globais, versionados automaticamente e se integram fortemente com o Cloud IAM. A criptografia primária do GSM é tratada pelo Cloud KMS, suportando customer-managed encryption keys (CMEK) e customer-supplied encryption keys (CSEK). Ele se distingue pelo controle de acesso por secret e uma forte ênfase no versionamento de secrets, que é um aspecto fundamental de sua operação. Ao contrário do AKV, o GSM não gerencia certificados inerentemente, mas se concentra puramente no armazenamento de secrets e chaves.

Recursos de Segurança: HSM, Criptografia e Zero Trust

Todos os três serviços fornecem criptografia em repouso e em trânsito (TLS 1.2/1.3). O diferenciador é o suporte para operações criptográficas e a proveniência da chave. O AWS Secrets Manager depende do AWS KMS, que usa módulos de segurança de hardware validados FIPS 140-2 Level 2. Secrets no ASM são criptografados usando uma data key derivada de uma customer master key (CMK) do KMS. Explicitamente, o ASM não fornece uma oferta direta FIPS 140-2 Level 3 dentro do plano de gerenciamento de secrets, embora o próprio KMS possa ser provisionado com esse nível de garantia.

O Azure Key Vault Premium usa HSMs nCipher (agora Entrust) para chaves, fornecendo validação FIPS 140-2 Level 2. O Azure Managed HSM, uma oferta de serviço gerenciado dentro do AKV, entrega HSMs de rede Thales Luna dedicados, fornecendo validação FIPS 140-2 Level 3. Esta é uma vantagem significativa para indústrias altamente regulamentadas que exigem forte isolamento criptográfico e prova de gênese de chaves com suporte de hardware. Para referência, uma instância Managed HSM single-tenant começa em aproximadamente US$ 5000/mês mais custos de transação.

O Google Secret Manager usa o Cloud KMS para todas as operações criptográficas. O próprio Cloud KMS oferece validação FIPS 140-2 Level 1 para chaves com suporte de software e FIPS 140-2 Level 2 para chaves com suporte de hardware, disponíveis por meio de configurações específicas de keyring. Secrets do GSM são criptografados com um esquema de envelope encryption onde uma data encryption key (DEK) criptografa o secret, e uma key encryption key (KEK) do Cloud KMS criptografa a DEK. Para clientes que precisam de FIPS 140-2 Level 3, a opção explícita não está diretamente dentro do GSM, mas depende de ofertas separadas relacionadas a HSMs dedicados ou sistemas de gerenciamento de chaves personalizados integrados ao Google Cloud, o que adiciona complexidade.

Granularidade IAM e Auditabilidade

Identity and Access Management (IAM) é crítico. O AWS Secrets Manager se integra com as políticas do AWS IAM no nível do secret. Você pode definir permissões granulares (ex: secretsmanager:GetSecretValue, secretsmanager:RotateSecret) para principals ou roles específicos em secrets individuais via políticas baseadas em recursos ou políticas baseadas em identidade. O CloudTrail captura todas as chamadas de API, fornecendo uma trilha de auditoria completa de acesso e modificação de secrets. Esse controle granular é um ponto forte para a AWS, permitindo implementações finas de Zero Trust.

O Azure Key Vault usa Azure Role-Based Access Control (RBAC) no nível do vault e também um modelo de política de acesso legado (embora o RBAC seja preferível). O RBAC permite atribuições de role em vários escopos (management group, subscription, resource group, vault individual) com roles predefinidas (ex: Key Vault Reader, Key Vault Secrets Officer) ou roles personalizadas. Para acesso a secrets individuais, o RBAC pode ser aplicado diretamente a um secret. Os Azure Monitor Logs (via Diagnostic Settings) capturam todas as operações do key vault, incluindo acesso a secrets, suportando integração com o Azure Sentinel para SIEM. A mudança para o RBAC simplificou o gerenciamento de IAM para o AKV.

O Google Secret Manager aproveita extensivamente o Google Cloud IAM. As permissões são definidas no nível do projeto, pasta ou secret individual usando roles primitivas (ex: roles/secretmanager.secretAccessor, roles/secretmanager.secretVersionManager) ou roles personalizadas. Essa capacidade de versionamento por secret, combinada com o IAM, significa controle preciso sobre quais principals podem acessar uma versão específica de um secret. Os Cloud Audit Logs (Admin Activity, Data Access) capturam todas as operações de gerenciamento de secrets, fornecendo logs detalhados e imutáveis para compliance e forense. A capacidade de condição do IAM do Google permite um refinamento ainda maior com base em atributos como IP de origem ou horário do dia.

Rotação de Secrets e Ecossistema de Integração

O AWS Secrets Manager oferece rotação integrada para RDS, Redshift, DocumentDB e outros serviços via funções Lambda. Este é, sem dúvida, seu recurso prático mais forte. Rotações personalizadas para outros serviços são alcançáveis com funções Lambda em Python. Para Kubernetes, o AWS Secrets & Configuration Provider para o driver CSI permite montar secrets diretamente em Pods. Ferramentas de IaC como Terraform suportam ASM para criação, recuperação e configuração de rotação de secrets. Secrets dinâmicos para bancos de dados que exigem diferentes credenciais por conexão são comumente implementados aproveitando os hooks de rotação do ASM ou funções Lambda personalizadas.

O Azure Key Vault tem capacidades de rotação para certificados, mas não rotação automatizada nativa de secrets para credenciais arbitrárias. Para senhas de banco de dados, isso geralmente requer Azure Functions personalizadas ou integração com pipelines de CI/CD para atualizar secrets periodicamente. O AKV se integra com o driver CSI do Azure Kubernetes Service (AKS) para montar secrets. O Terraform tem suporte extensivo para gerenciar vaults, chaves e secrets do AKV. A geração de secrets dinâmicos é menos explícita nas capacidades nativas do AKV; geralmente é tratada pela aplicação consumidora ou por um serviço externo de intermediação de credenciais.

O Google Secret Manager suporta a configuração de um cronograma de rotação para secrets, o que dispara uma mensagem Pub/Sub. Esta mensagem pode então invocar uma Cloud Function para realizar a atualização real da credencial e a rotação da versão do secret. Este design é flexível, mas requer código personalizado para a maioria dos backends. Para Kubernetes, o driver CSI do Google Secret Manager permite que os secrets sejam expostos como arquivos em Pods. O Terraform gerencia efetivamente os secrets do GSM, e sua integração com o Cloud KMS oferece fortes opções de controle de chaves. Secrets dinâmicos são possíveis, mas novamente dependem de Cloud Functions disparadas por eventos de rotação.

Comparação de Preços (Preços de Tabela Aproximados 2026)

Os modelos de precificação são cruciais e frequentemente complexos, envolvendo armazenamento por secret e por chamada de API. Essas cifras são ilustrativas e sujeitas a variações regionais e descontos empresariais.

Recurso	AWS Secrets Manager	Azure Key Vault (Premium)	GCP Secret Manager
Armazenamento por secret/mês (primeiros 10k)	$0.40	$3.00 (chaves, secrets, certs)	$0.06
Chamadas de API por 10k operações	$0.05	$0.03 (secrets & chaves)	$0.03
Custo de rotação obrigatória	$0.05/secret/mês (se habilitado)	N/A (necessária customização)	N/A (Pub/Sub + Cloud Function adiciona custo)
Managed HSM (opcional)	N/A diretamente	~$5000/mês instância HSM dedicada + operações	N/A diretamente
Exemplo: 1000 secrets, 1 milhão de chamadas API/mês	$400 (armazenamento) + $500 (API) = $900 (+ até $50 para rotação)	$3000 (armazenamento) + $300 (API) = $3300	$60 (armazenamento) + $300 (API) = $360
Exemplo: 100 secrets, 100k chamadas API/mês	$40 (armazenamento) + $5 (API) = $45	$300 (armazenamento) + $3 (API) = $303	$6 (armazenamento) + $3 (API) = $9

Note a diferença marcante nos custos de armazenamento. O nível Premium do Azure Key Vault, embora ofereça superioridade de HSM, é significativamente mais caro por secret armazenado. O GCP Secret Manager claramente tem o menor custo de armazenamento, tornando-o atraente para um grande número de secrets com tráfego de API moderado. A AWS se torna competitiva em altos volumes de chamadas de API devido ao seu preço por chamada relativamente menor em comparação ao armazenamento.

Considerações de Multi-Região e Disaster Recovery

AWS Secrets Manager é um serviço regional. Para disaster recovery ou implantações multi-região, os secrets devem ser replicados entre regiões. Você pode automatizar essa replicação usando funções Lambda acionadas por CloudWatch Events em alterações de secret, ou definindo secrets individuais em cada região. Isso requer planejamento arquitetural para garantir consistência e prevenir cenários de split-brain durante o failover.

Azure Key Vault também é um serviço regional. Embora os secrets sejam geo-replicados dentro da mesma região para durabilidade, a replicação entre regiões ainda exige implantação manual ou via script de vaults e secrets em várias regiões. Isso pode envolver templates do Azure Resource Manager (ARM), Terraform ou scripts da Azure CLI para garantir que os secrets sejam sincronizados. Os Managed HSMs são implantados em uma região específica e não oferecem replicação automática entre regiões globalmente, necessitando de configuração manual para DR.

Google Secret Manager oferece secrets como recursos globais. Quando você cria um secret, ele é globalmente acessível, e suas versões são armazenadas em várias regiões do Google Cloud. Isso simplifica significativamente o disaster recovery entre regiões do ponto de vista do gerenciamento de secrets. O data plane é globalmente disponível e consistente, o que elimina grande parte do ônus do planejamento de DR para acesso a secrets, embora as políticas de acesso permaneçam específicas da região em alguns casos.

Snippets de Configuração e Melhores Práticas de IaC

Usar Infrastructure as Code (IaC) é crítico para gerenciar secrets. Aqui está um exemplo de Terraform para criar um secret em cada plataforma:

# AWS Secrets Manager Secret
resource "aws_secretsmanager_secret" "db_credentials" {
  name                    = "production/app/db_credentials"
  description             = "Database credentials for the main application."
  recovery_window_in_days = 7
  rotation_lambda_arn     = aws_lambda_function.db_rotation_function.arn
  rotation_rules {
    automatically_after_days = 90
  }
}

resource "aws_secretsmanager_secret_version" "db_credentials_version" {
  secret_id     = aws_secretsmanager_secret.db_credentials.id
  secret_string = jsonencode({
    username = "admin"
    password = "super_secret_pw"
  })
}

# Azure Key Vault Secret
resource "azurerm_key_vault" "main" {
  name                          = "mykv-2026-prod"
  location                      = "eastus"
  resource_group_name           = azurerm_resource_group.main.name
  sku_name                      = "premium"
  tenant_id                     = data.azurerm_client_config.current.tenant_id
  enabled_for_disk_encryption   = true
  purge_protection_enabled      = true
  soft_delete_retention_days    = 90
}

resource "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  value        = "super_secret_pw_az"
  key_vault_id = azurerm_key_vault.main.id
  content_type = "application/text"
}

# GCP Secret Manager Secret
resource "google_secret_manager_secret" "api_key_prod" {
  secret_id = "api-key-prod"
  project   = var.gcp_project_id
  replication {
    automatic = true
  }
  rotation {
    rotation_period = "2592000s" # 30 days
  }
}

resource "google_secret_manager_secret_version" "api_key_prod_version" {
  secret      = google_secret_manager_secret.api_key_prod.id
  secret_data = "gcp_super_secret_key"
}

É crucial criptografar valores sensíveis como secret_string ou value em seus arquivos de estado IaC se não estiver usando um backend de secrets como o HashiCorp Vault. Neste exemplo, super_secret_pw é hardcoded para brevidade, mas na prática, deve ser passado de forma segura, por exemplo, via variáveis de ambiente ou uma ferramenta separada de gerenciamento de secrets que os injeta no momento da implantação, ou alavancando o próprio armazenamento de secrets do provedor de nuvem para seed inicial.

Veredito: Cenários para Escolha

Escolha AWS Secrets Manager quando: Você está fortemente investido na AWS, particularmente usando RDS, Redshift ou DocumentDB, e valoriza a rotação automática nativa. O preço se ajusta bem com chamadas de API uma vez que os custos de armazenamento são absorvidos. Se você precisa de uma solução abrangente e integrada para credenciais e configuração (com Parameter Store), a AWS fornece um ecossistema forte. Considere isso para aplicações nativas da AWS onde a automação baseada em Lambda é uma estratégia central.

Escolha Azure Key Vault quando: Sua organização tem fortes requisitos de compliance (ex: FIPS 140-2 Level 3 com Managed HSM), uma pegada significativa de PKI, ou precisa de um armazenamento unificado para chaves, secrets e certificados. Organizações centradas no Azure que utilizam intensamente o Azure Active Directory (agora Entra ID) e serviços do Azure encontrarão a integração do AKV coesa. AKV é a escolha para cenários híbridos onde as chaves podem se originar de HSMs on-premises e ser importadas com segurança para o Azure.

Escolha Google Secret Manager quando: A eficiência de custo para um grande número de secrets é primordial, ou você prioriza um sistema de gerenciamento de secrets simples, globalmente distribuído e com versionamento automático. O GSM é ideal para arquiteturas de microsserviços no GKE (Google Kubernetes Engine) e funções serverless (Cloud Functions, Cloud Run) dentro do ecossistema GCP. Seu custo de armazenamento baixo e de taxa fixa o torna atraente para secrets de alto volume e baixo acesso.

Em última análise, a melhor escolha se alinha com sua estratégia de nuvem existente, requisitos regulatórios, modelo operacional e restrições orçamentárias específicas. Evite a otimização prematura; comece com a oferta nativa do seu provedor de nuvem e aumente os requisitos apenas quando necessário.

Leitura Relacionada

• FortiGate 7.6 NGFW Design: Além do Básico
• Palo Alto Networks Prisma Cloud CNAPP Report 2026
• Otimizações AWS CloudFront WAF para Aplicações de Alto Tráfego 2026
• Melhores Práticas de Integração do Azure Sentinel SIEM
• GCP Zero Trust: Estratégias de Implementação do BeyondCorp