AWS Secrets Manager vs Azure Key Vault vs GCP Secret Manager: Análisis Profundo 2026

Elegir la solución correcta de gestión de secretos en la nube en 2026 implica más que listas de verificación de características. Se trata de implicaciones de costos directos, sobrecarga operativa, profundidad de integración dentro de un ecosistema de nube específico y posturas de cumplimiento. Este análisis va más allá del marketing para detallar AWS Secrets Manager (incluido Parameter Store para casos de uso específicos), Azure Key Vault (cubriendo los niveles Standard, Premium y Managed HSM) y Google Secret Manager (con interoperabilidad con Cloud KMS). Nos enfocamos en la diferenciación técnica y la adecuación estratégica para casos de uso empresariales.

Capacidades Centrales y Paradigmas de Diseño

AWS Secrets Manager (ASM) prioriza la automatización y la integración amplia. Su función principal es almacenar, recuperar y rotar secretos. Los secretos pueden ser desde credenciales de bases de datos hasta claves de API. ASM se integra directamente con RDS, Redshift y DocumentDB para la rotación nativa. Si bien KMS cifra los secretos en reposo, ASM maneja su ciclo de vida. AWS Parameter Store, a menudo pasado por alto para secretos, puede almacenar secretos más pequeños y menos sensibles (hasta 10KB) a un costo menor, actuando como un almacén de configuración jerárquico con cifrado KMS opcional. La distinción es crítica: Parameter Store es para configuración, Secrets Manager para credenciales.

Azure Key Vault (AKV) es un servicio unificado para secretos, claves y certificados. Esta consolidación reduce la sobrecarga de gestión para entornos con gran cantidad de PKI o que necesitan almacenamiento de claves respaldado por hardware. AKV ofrece los niveles Standard (claves respaldadas por software) y Premium (claves respaldadas por HSM validadas FIPS 104-2 Nivel 2). Azure Managed HSM es un servicio HSM dedicado, de un solo inquilino, validado FIPS 140-2 Nivel 3, que proporciona un nivel de garantía más alto para operaciones criptográficas críticas, incluidas las claves importables. La elección arquitectónica entre estos niveles impacta directamente la postura de seguridad y el costo.

Google Secret Manager (GSM) está diseñado para la simplicidad y la accesibilidad global desde el principio. Los secretos son recursos globales, versionados automáticamente y se integran estrechamente con Cloud IAM. El cifrado principal de GSM es manejado por Cloud KMS, que admite claves de cifrado gestionadas por el cliente (CMEK) y claves de cifrado proporcionadas por el cliente (CSEK). Se distingue por el control de acceso por secreto y un fuerte énfasis en el versionado de secretos, que es un aspecto fundamental de su operación. A diferencia de AKV, GSM no gestiona inherentemente certificados, sino que se centra puramente en el almacenamiento de secretos y claves.

Características de Seguridad: HSM, Cifrado y Zero Trust

Los tres servicios proporcionan cifrado en reposo y en tránsito (TLS 1.2/1.3). El diferenciador es el respaldo para las operaciones criptográficas y la procedencia de las claves. AWS Secrets Manager se basa en AWS KMS, que utiliza módulos de seguridad de hardware validados FIPS 140-2 Nivel 2. Los secretos en ASM se cifran utilizando una clave de datos derivada de una clave maestra de cliente (CMK) de KMS. Explícitamente, ASM no ofrece una oferta directa FIPS 140-2 Nivel 3 dentro del plano de gestión de secretos, aunque KMS en sí mismo puede ser aprovisionado con ese nivel de garantía.

Azure Key Vault Premium utiliza HSM de nCipher (ahora Entrust) para claves, proporcionando validación FIPS 140-2 Nivel 2. Azure Managed HSM, una oferta de servicio gestionado dentro de AKV, entrega HSM de red Thales Luna dedicados que proporcionan validación FIPS 140-2 Nivel 3. Esta es una ventaja significativa para industrias altamente reguladas que requieren un fuerte aislamiento criptográfico y prueba de la génesis de claves respaldada por hardware. Como referencia, una instancia de Managed HSM de un solo inquilino comienza en aproximadamente $5000/mes más costos de transacción.

Google Secret Manager utiliza Cloud KMS para todas las operaciones criptográficas. Cloud KMS en sí mismo ofrece validación FIPS 140-2 Nivel 1 para claves respaldadas por software y FIPS 140-2 Nivel 2 para claves respaldadas por hardware, disponibles a través de configuraciones específicas de Key Ring. Los secretos de GSM se cifran con un esquema de cifrado de sobre donde una clave de cifrado de datos (DEK) cifra el secreto, y una clave de cifrado de claves (KEK) de Cloud KMS cifra la DEK. Para los clientes que necesitan FIPS 140-2 Nivel 3, la opción explícita no está directamente dentro de GSM, sino que depende de ofertas separadas relacionadas con HSM dedicados o sistemas de gestión de claves personalizados integrados con Google Cloud, lo que agrega complejidad.

Granularidad de IAM y Auditabilidad

Identity and Access Management (IAM) es crítico. AWS Secrets Manager se integra con las políticas de AWS IAM a nivel de secreto. Puede definir permisos granulares (por ejemplo, secretsmanager:GetSecretValue, secretsmanager:RotateSecret) para principales o roles específicos en secretos individuales a través de políticas basadas en recursos o políticas basadas en identidad. CloudTrail captura todas las llamadas API, proporcionando un registro de auditoría completo del acceso y la modificación de secretos. Este control granular es un punto fuerte para AWS, permitiendo implementaciones de Zero Trust finamente ajustadas.

Azure Key Vault utiliza Azure Role-Based Access Control (RBAC) a nivel de Vault y también un modelo de política de acceso heredado (aunque RBAC es preferido). RBAC permite asignaciones de roles en varios alcances (grupo de gestión, suscripción, grupo de recursos, Vault individual) con roles predefinidos (por ejemplo, Key Vault Reader, Key Vault Secrets Officer) o roles personalizados. Para el acceso a secretos individuales, RBAC se puede aplicar directamente a un secreto. Azure Monitor Logs (a través de Diagnostic Settings) captura todas las operaciones de Key Vault, incluido el acceso a secretos, lo que permite la integración con Azure Sentinel para SIEM. El paso a RBAC ha simplificado la gestión de IAM para AKV.

Google Secret Manager aprovecha ampliamente Google Cloud IAM. Los permisos se definen a nivel de proyecto, carpeta o secreto individual utilizando roles primitivos (por ejemplo, roles/secretmanager.secretAccessor, roles/secretmanager.secretVersionManager) o roles personalizados. Esta capacidad de versionado por secreto, combinada con IAM, significa un control preciso sobre qué principales pueden acceder a una versión específica de un secreto. Cloud Audit Logs (Admin Activity, Data Access) capturan todas las operaciones de gestión de secretos, proporcionando registros detallados e inmutables para cumplimiento y análisis forense. La capacidad de condición de IAM de Google permite un ajuste aún más fino basado en atributos como la IP de origen o la hora del día.

Rotación de Secretos y Ecosistema de Integración

AWS Secrets Manager ofrece rotación incorporada para RDS, Redshift, DocumentDB y otros servicios a través de funciones Lambda. Esta es posiblemente su característica práctica más fuerte. Las rotaciones personalizadas para otros servicios se pueden lograr con funciones Python Lambda. Para Kubernetes, el AWS Secrets & Configuration Provider para el controlador CSI permite montar secretos directamente en Pods. Las herramientas de IaC como Terraform admiten ASM para la creación, recuperación y configuración de rotación de secretos. Los secretos dinámicos para bases de datos que requieren diferentes credenciales por conexión se implementan comúnmente aprovechando los hooks de rotación de ASM o funciones Lambda personalizadas.

Azure Key Vault tiene capacidades de rotación para certificados, pero no rotación automática nativa de secretos para credenciales arbitrarias. Para las contraseñas de bases de datos, esto generalmente requiere Azure Functions personalizadas o la integración con pipelines de CI/CD para actualizar los secretos periódicamente. AKV se integra con el controlador CSI de Azure Kubernetes Service (AKS) para montar secretos. Terraform tiene un amplio soporte para gestionar Vaults, claves y secretos de AKV. La generación dinámica de secretos es menos explícita dentro de las capacidades nativas de AKV; generalmente es manejada por la aplicación consumidora o un servicio de intermediación de credenciales externo.

Google Secret Manager admite la configuración de un cronograma de rotación para los secretos, lo que activa un mensaje de Pub/Sub. Este mensaje puede invocar una Cloud Function para realizar la actualización real de las credenciales y la rotación de la versión del secreto. Este diseño es flexible, pero requiere código personalizado para la mayoría de los backends. Para Kubernetes, el controlador CSI de Google Secret Manager permite que los secretos se expongan como archivos en Pods. Terraform gestiona los secretos de GSM de manera efectiva, y su integración con Cloud KMS ofrece sólidas opciones de control de claves. Los secretos dinámicos son posibles, pero nuevamente dependen de Cloud Functions activadas por eventos de rotación.

Comparación de Precios (Precios de Lista Aproximados 2026)

Los modelos de precios son cruciales y a menudo complejos, e involucran el almacenamiento por secreto y por llamada API. Estas cifras son ilustrativas y están sujetas a variaciones regionales y descuentos empresariales.

Característica	AWS Secrets Manager	Azure Key Vault (Premium)	GCP Secret Manager
Almacenamiento por secreto/mes (primeros 10k)	$0.40	$3.00 (claves, secretos, certificados)	$0.06
Llamadas API por 10k operaciones	$0.05	$0.03 (secretos y claves)	$0.03
Cargo obligatorio por rotación	$0.05/secreto/mes (si está habilitado)	N/A (necesita personalización)	N/A (Pub/Sub + Cloud Function agrega costo)
Managed HSM (opcional)	N/A directamente	~$5000/mes instancia HSM dedicada + operaciones	N/A directamente
Ejemplo: 1000 secretos, 1M llamadas API/mes	$400 (almacenamiento) + $500 (API) = $900 (+ hasta $50 por rotación)	$3000 (almacenamiento) + $300 (API) = $3300	$60 (almacenamiento) + $300 (API) = $360
Ejemplo: 100 secretos, 100k llamadas API/mes	$40 (almacenamiento) + $5 (API) = $45	$300 (almacenamiento) + $3 (API) = $303	$6 (almacenamiento) + $3 (API) = $9

Observe la marcada diferencia en los costos de almacenamiento. El nivel Premium de Azure Key Vault, aunque ofrece superioridad en HSM, es significativamente más caro por secreto almacenado. GCP Secret Manager claramente tiene el costo de almacenamiento más bajo, lo que lo hace atractivo para un gran número de secretos con tráfico API moderado. AWS se vuelve competitivo con altos volúmenes de llamadas API debido a su precio por llamada relativamente más bajo en comparación con el almacenamiento.

Consideraciones de Recuperación ante Desastres y Multi-Región

AWS Secrets Manager es un servicio regional. Para la recuperación ante desastres o despliegues multi-región, los secretos deben replicarse entre regiones. Puede automatizar esta replicación utilizando funciones Lambda activadas por CloudWatch Events en cambios de secretos, o definiendo secretos individuales en cada región. Esto requiere planificación arquitectónica para garantizar la coherencia y prevenir escenarios de split-brain durante la conmutación por error.

Azure Key Vault también es un servicio regional. Si bien los secretos se replican geográficamente dentro de la misma región para mayor durabilidad, la replicación entre regiones aún requiere el despliegue manual o mediante scripts de Vaults y secretos en múltiples regiones. Esto puede implicar plantillas de Azure Resource Manager (ARM), Terraform o scripts de Azure CLI para garantizar que los secretos estén sincronizados. Los Managed HSM se implementan en una región específica y no ofrecen replicación automática entre regiones a nivel global, lo que requiere configuración manual para la recuperación ante desastres.

Google Secret Manager ofrece secretos como recursos globales. Cuando se crea un secreto, es globalmente accesible y sus versiones se almacenan en múltiples regiones de Google Cloud. Esto simplifica significativamente la recuperación ante desastres entre regiones desde una perspectiva de gestión de secretos. El plano de datos está globalmente disponible y es consistente, lo que elimina gran parte de la carga de planificación de recuperación ante desastres para el acceso a secretos, aunque las políticas de acceso permanecen específicas de la región en algunos casos.

Fragmentos de Configuración y Mejores Prácticas de IaC

El uso de Infrastructure as Code (IaC) es fundamental para la gestión de secretos. Aquí hay un ejemplo de Terraform para crear un secreto en cada plataforma:

# Secreto de AWS Secrets Manager
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"
  })
}

# Secreto de Azure Key Vault
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"
}

# Secreto de GCP Secret Manager
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"
}

Es crucial cifrar valores sensibles como secret_string o value en los archivos de estado de su IaC si no se utiliza un backend de secretos como HashiCorp Vault. En este ejemplo, super_secret_pw está codificado directamente por brevedad, pero en la práctica, debería pasarse de forma segura, por ejemplo, a través de variables de entorno o una herramienta de gestión de secretos separada que los inyecte en el momento del despliegue, o aprovechando el propio almacenamiento de secretos del proveedor de la nube para la siembra inicial.

Veredicto: Escenarios para Elegir

Elija AWS Secrets Manager cuando: esté fuertemente invertido en AWS, particularmente usando RDS, Redshift o DocumentDB, y valore la rotación automática nativa. El precio se escala bien con las llamadas API una vez que se absorben los costos de almacenamiento. Si necesita una solución integral e integrada para credenciales y configuración (con Parameter Store), AWS proporciona un ecosistema sólido. Considere esto para aplicaciones nativas de la nube de AWS donde la automatización basada en Lambda es una estrategia central.

Elija Azure Key Vault cuando: su organización tenga fuertes requisitos de cumplimiento (por ejemplo, FIPS 140-2 Nivel 3 con Managed HSM), una huella significativa de PKI o necesite un almacén unificado para claves, secretos y certificados. Las organizaciones centradas en Azure que aprovechan en gran medida Azure Active Directory (ahora Entra ID) y los servicios de Azure encontrarán la integración de AKV cohesiva. AKV es la opción para escenarios híbridos donde las claves pueden originarse en HSM locales e importarse de forma segura a Azure.

Elija Google Secret Manager cuando: la rentabilidad para un gran número de secretos sea primordial, o priorice un sistema de gestión de secretos simple, distribuido globalmente y con versionado automático. GSM es ideal para arquitecturas de microservicios en GKE (Google Kubernetes Engine) y funciones serverless (Cloud Functions, Cloud Run) dentro del ecosistema de GCP. Su costo de almacenamiento bajo y de tarifa plana lo hace atractivo para secretos de gran volumen y bajo acceso.

En última instancia, la mejor opción se alinea con su estrategia de nube existente, los requisitos regulatorios, el modelo operativo y las limitaciones presupuestarias específicas. Evite la optimización prematura; comience con la oferta nativa de su proveedor de nube y escale las necesidades solo cuando sea necesario.

Lectura relacionada

• FortiGate 7.6 Diseño de NGFW: Más allá de lo Básico
• Palo Alto Networks Prisma Cloud CNAPP Informe 2026
• Optimizaciones de WAF en AWS CloudFront para Aplicaciones de Alto Tráfico 2026
• Azure Sentinel SIEM: Mejores Prácticas de Integración
• GCP Zero Trust: Estrategias de Implementación de BeyondCorp