Introducción a AWS Secrets Manager

AWS Secrets Manager es un servicio administrado que almacena, rota y audita secretos como contraseñas de bases de datos, claves de API y tokens OAuth a lo largo de su ciclo de vida. Esto es importante porque las credenciales codificadas directamente en el código de la aplicación son una de las causas más comunes de filtraciones de datos e incumplimientos normativos. La acción recomendada es migrar todos los secretos de la aplicación a Secrets Manager, configurar una clave KMS administrada por el cliente para el cifrado, habilitar la rotación automática y activar el registro de acceso a datos de CloudTrail para todos los eventos de recuperación de secretos.

Respuesta rápida: ¿Qué hace AWS Secrets Manager?

AWS Secrets Manager es un almacén centralizado de secretos que elimina la necesidad de incluir credenciales directamente en el código de la aplicación. Cifra cada secreto en reposo mediante AWS KMS (cifrado de sobre AES-256-GCM), transmite secretos únicamente a través de TLS, proporciona rotación automática de credenciales mediante AWS Lambda para bases de datos compatibles y destinos personalizados, controla el acceso mediante políticas basadas en recursos de IAM y registra cada acceso a secretos en CloudTrail. Se integra de forma nativa con Amazon RDS, Amazon DocumentDB, Amazon Redshift y más de 100 servicios de AWS. Secrets Manager se diferencia de AWS KMS: KMS gestiona las claves de cifrado; Secrets Manager gestiona los secretos que protegen esas claves. Para obtener más información sobre la capa de cifrado de KMS, consulte nuestra guía "¿ Qué tan seguros son los Servicios de administración de claves de Amazon (AWS KMS)?".

Puntos Clave

• Secrets Manager elimina las credenciales codificadas manualmente: Cada secreto se almacena en un servicio centralizado gestionado y se recupera mediante una llamada a la API, eliminando así las credenciales del código fuente, los archivos de configuración y las canalizaciones de CI/CD, donde suelen quedar expuestas en el control de versiones y los registros.
• El cifrado utiliza el cifrado de sobre KMS con AES-256-GCM: El valor secreto se cifra con una clave de datos generada por AWS KMS. La clave de datos en texto plano se descarta inmediatamente después de su uso. Por defecto, se utiliza la clave administrada por AWS (aws/secretsmanager). Las claves administradas por el cliente proporcionan un registro de auditoría independiente y la capacidad de revocación para las cargas de trabajo de cumplimiento normativo.
• La rotación automática es la capacidad que nos diferencia de los servicios de la competencia: Secrets Manager ofrece rotación integrada basada en Lambda para Amazon RDS, DocumentDB y Redshift. Las funciones Lambda personalizadas admiten la rotación para cualquier otro tipo de secreto, incluidas claves de API de terceros, bases de datos locales y tokens OAuth.
• Las políticas basadas en recursos de IAM son el principal mecanismo de control de acceso: Cada secreto tiene una política de recursos que controla qué entidades principales pueden recuperarlo, rotarlo o eliminarlo. Esto proporciona un control preciso a nivel de secreto, independiente de las políticas de identidad IAM a nivel de cuenta.
• La integración con CloudTrail proporciona el registro de auditoría de cumplimiento: Cada llamada a la API de Secrets Manager (GetSecretValue, CreateSecret, RotateSecret, DeleteSecret) se registra en CloudTrail con la identidad solicitante, el ARN del secreto y la marca de tiempo. Al habilitar el registro de acceso a datos de KMS, se capturan adicionalmente todos los eventos de descifrado relacionados con la recuperación del secreto.

¿Qué es AWS Secrets Manager?

AWS Secrets Manager es un servicio de administración de secretos totalmente gestionado que se encarga del almacenamiento, la recuperación, la rotación y la auditoría de los secretos de las aplicaciones a lo largo de su ciclo de vida. En este contexto, un secreto es cualquier dato confidencial que una aplicación o servicio utiliza para autenticarse en otro recurso: nombres de usuario y contraseñas de bases de datos, claves de API, tokens de acceso OAuth, claves privadas TLS, credenciales SSH y contraseñas de cuentas de servicio.

Sin un gestor de secretos centralizado, las credenciales suelen estar integradas en el código de la aplicación, archivos de configuración, variables de entorno, definiciones de canalizaciones de CI/CD o scripts. Cualquiera de estas ubicaciones puede exponer inadvertidamente las credenciales a través de sistemas de control de versiones, agregación de registros, artefactos de compilación o capas de imágenes de contenedores. AWS Secrets Manager reemplaza todos estos patrones con una única llamada a la API que recupera el valor del secreto actual bajo demanda, a través de un canal cifrado, a un usuario autenticado.

AWS Secrets Manager es un servicio independiente de AWS Key Management Service (AWS KMS). KMS gestiona las claves criptográficas que protegen los secretos; Secrets Manager gestiona los secretos en sí. Ambos servicios trabajan conjuntamente: cada secreto almacenado en Secrets Manager se cifra con una clave de datos de AWS KMS antes de escribirse en el almacenamiento persistente de Secrets Manager. Comprender esta distinción es importante para la asignación de cumplimiento y para decidir qué tipo de clave KMS utilizar. Para obtener información completa sobre la capa de cifrado de KMS, consulte nuestra guía sobre AWS KMS Deep Dive.

Cómo cifra los secretos AWS Secrets Manager

Cada valor secreto almacenado en AWS Secrets Manager se cifra en reposo mediante cifrado de sobre a través de AWS KMS. El proceso funciona de la siguiente manera:

1. Cuando almacenas un secreto, Secrets Manager llama a AWS KMS. GenerateDataKey operación, especificando la clave KMS configurada para ese secreto.
2. AWS KMS devuelve una clave de datos AES-256 en texto plano y una copia cifrada de la misma clave de datos (encapsulada por la clave KMS).
3. Secrets Manager utiliza la clave de datos en texto plano para cifrar el valor secreto mediante AES-256-GCM (cifrado autenticado con datos asociados).
4. Secrets Manager almacena el valor secreto cifrado y la clave de datos cifrada juntos en su almacenamiento persistente.
5. La clave de datos en texto plano se descarta inmediatamente de la memoria. Nunca se almacena en ningún lugar.
6. Cuando se recupera un secreto, Secrets Manager envía la clave de datos cifrada a AWS KMS para su descifrado. KMS devuelve la clave de datos en texto plano.
7. Secrets Manager utiliza la clave de datos en texto plano para descifrar el valor secreto y devuelve el secreto en texto plano al emisor a través de una conexión cifrada con TLS.
8. La clave de datos en texto plano se descarta de nuevo de la memoria después de su uso.

Secrets Manager nunca almacena valores secretos en texto plano en ninguna capa de almacenamiento persistente. La clave de datos cifrada almacenada junto con el secreto es inútil sin acceso a la clave KMS que lo encapsula, lo que significa que comprometer únicamente el almacenamiento de Secrets Manager no es suficiente para recuperar secretos en texto plano.

Clave KMS nativa frente a clave KMS gestionada por el cliente: ¿Cuál utilizar?

De forma predeterminada, Secrets Manager utiliza una clave KMS administrada por AWS con el alias aws/secretsmanagerEsta clave se crea automáticamente en su cuenta la primera vez que crea un secreto sin especificar una clave KMS. Cambiar a una clave KMS administrada por el cliente (CMK) es la configuración que cumple con los estándares de cumplimiento para cargas de trabajo reguladas.

Propiedad	Clave administrada por AWS (aws/secretsmanager)	Clave KMS gestionada por el cliente (CMK)
Clave generada por	AWS automáticamente	Usted, en su consola de AWS KMS o a través de la API
Control de políticas clave	Ninguno (AWS lo gestiona completamente)	Completo (usted define quién puede usar y administrar la clave)
Registro de auditoría de CloudTrail por operación	No (solo eventos limitados)	Sí (cada operación de cifrado y descifrado está vinculada a la recuperación de secretos).
Desactivar/revocar clave independiente	No	Sí (desactive CMK para bloquear inmediatamente la recuperación de todos los secretos).
Rotación automática de la llave	Sí (programación controlada por AWS)	Sí (configurable de 90 días a 7 años)
Soporte BYOK	No	Sí (importa tu propio material clave a través de KMS Import Jobs)
Opción FIPS 140-2 Nivel 3	No	Sí (con el almacén de claves personalizado de CloudHSM)
Costo adicional	Ninguna	De 0.06 a 2.50 dólares por versión de clave al mes + 0.03 dólares por cada 10 operaciones de KMS
Ideal para	Desarrollo, cargas de trabajo no reguladas	Cargas de trabajo reguladas: PCI DSS, HIPAA, FedRAMP, GDPR

Para cargas de trabajo donde AWS debe tener acceso cero a la clave de cifrado secreta (requisitos HYOK/Hold Your Own Key), el enfoque adecuado consiste en cifrar el valor secreto en el lado del cliente antes de pasarlo a Secrets Manager, utilizando una clave almacenada completamente fuera de AWS. Secrets Manager almacenaría entonces el valor ya cifrado. Esto añade complejidad operativa y elimina la posibilidad de usar la rotación nativa, pero excluye por completo a AWS de la cadena de confianza de claves. El HSM como servicio de Encryption Consulting proporciona la infraestructura de gestión de claves externa FIPS 140-2 Nivel 3 para implementaciones HYOK.

Cómo funciona la rotación automática de secretos

La rotación automática es la capacidad que más distingue a AWS Secrets Manager de los almacenes de parámetros más simples. Cuando se activa la rotación, Secrets Manager ejecuta una función AWS Lambda que sigue un ciclo de vida de cuatro pasos:

1. CrearSecreto: La función Lambda genera un nuevo valor de credencial y crea una nueva versión del secreto en Secrets Manager con la etiqueta staging. AWSPENDING. La versión anterior conserva la AWSCURRENT Utilice la etiqueta correspondiente durante todo este paso, para que las conexiones existentes sigan utilizando las credenciales actuales.
2. Establecer secreto: La función Lambda actualiza la credencial en el servicio de destino (la base de datos, API u otro servicio) con el nuevo valor. El servicio de destino ahora acepta tanto la credencial antigua (todavía en AWSCURRENT) y el nuevo.
3. TestSecret: La función Lambda prueba la nueva credencial con el servicio de destino para confirmar que funciona antes de que la anterior quede obsoleta. Si la prueba falla, la rotación se detiene y la credencial anterior permanece activa.
4. FinishSecret: La función Lambda mueve el AWSCURRENT etiqueta a la nueva versión y movimientos AWSPREVIOUS a la versión anterior. La nueva credencial ya está vigente. La versión anterior de la credencial se conserva brevemente para que las conexiones en curso que la utilicen puedan completarse.

Para Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Amazon DocumentDB y Amazon Redshift, AWS proporciona funciones Lambda de rotación administradas que gestionan automáticamente los cuatro pasos. Estas son las implementaciones de rotación más sencillas y se pueden configurar a través de la consola de Secrets Manager o mediante AWS CloudFormation. Para cualquier otro tipo de secreto, se implementa una función Lambda personalizada que sigue el mismo patrón de cuatro pasos. Esto permite la rotación de bases de datos locales, servicios API de terceros, claves SSH, tokens OAuth y cualquier credencial con un mecanismo de actualización programable.

La rotación se puede configurar para que se ejecute según un cronograma (el intervalo mínimo es de 1 día) o para que se active inmediatamente bajo demanda. Para cargas de trabajo de cumplimiento bajo el requisito 8.3.9 de PCI DSS (rotación periódica de credenciales de autenticación), la rotación automática con un cronograma de 90 días o menos cumple con el requisito sin intervención manual.

Modelo de acceso IAM: Controlar quién puede recuperar información confidencial

El acceso a los secretos en AWS Secrets Manager se controla mediante dos capas: políticas de identidad de IAM y políticas basadas en recursos secretos. Ambas deben autorizar a una entidad principal antes de conceder el acceso.

Política secreta basada en recursos (control primario): Cada secreto tiene una política de recursos que define explícitamente qué entidades principales de AWS (roles de IAM, usuarios de IAM, cuentas de AWS o servicios de AWS) pueden realizar qué operaciones en ese secreto específico. Las operaciones clave que se deben controlar son: secretsmanager:GetSecretValue (recuperar el secreto), secretsmanager:RotateSecret (rotación del gatillo), secretsmanager:DeleteSecret (eliminación programada) y secretsmanager:PutSecretValue (escribir un nuevo valor secreto). La política de recursos proporciona granularidad a nivel de secreto: a la cuenta de servicio de una aplicación se le puede otorgar el permiso GetSecretValue solo para sus secretos específicos, sin acceso a ningún otro secreto en la cuenta.

Política de identidad de IAM (capa secundaria): Las políticas de IAM asociadas a roles, usuarios o grupos pueden otorgar permisos de Secrets Manager. Para que el acceso sea exitoso, tanto la política de identidad como la política de recursos deben permitir la operación. Este modelo de doble capa permite usar políticas de identidad para otorgar un acceso amplio a Secrets Manager y luego restringirlo a nivel de secreto con políticas de recursos, o viceversa.

Acceso entre cuentas: Secrets Manager admite el acceso a secretos entre cuentas agregando la entidad principal de la cuenta externa a la política de recursos del secreto y otorgando el uso de la clave KMS del secreto a la cuenta externa. Este patrón es útil para cuentas de servicios compartidos que administran secretos para varias cuentas de aplicación, o para centralizar la administración de secretos en una cuenta dedicada.

Control de acceso basado en etiquetas: Secrets Manager admite etiquetas de recursos de AWS. Puede utilizar condiciones de política de IAM basadas en etiquetas secretas (por ejemplo, aws:ResourceTag/Environment: Production) para restringir el acceso a los secretos de producción a roles específicos, mientras que los roles de desarrollo solo pueden acceder a los secretos etiquetados como de desarrollo. Esto resulta útil en entornos grandes donde gestionar los ARN de secretos individuales en las políticas es poco práctico.

Políticas de control de servicio (SCP): si sus cuentas se encuentran en una organización de AWS, las SCP pueden imponer medidas de seguridad a nivel de toda la organización: exigir que todos los secretos utilicen claves KMS administradas por el cliente, denegar la eliminación de secretos etiquetados como de producción o exigir que se utilice el punto final de VPC de Secrets Manager para todas las recuperaciones de secretos dentro de una unidad organizativa específica.

Registro de auditoría de CloudTrail para Secrets Manager

AWS Secrets Manager está totalmente integrado con AWS CloudTrail. Cada llamada a la API de Secrets Manager genera un evento de CloudTrail que registra el nombre de la operación, el ARN del secreto, la identidad de IAM solicitante, la dirección IP de origen, la región de AWS y la marca de tiempo. Este registro de auditoría es la principal fuente de evidencia para las revisiones de cumplimiento relacionadas con el acceso a secretos.

Los eventos de administración (CreateSecret, DeleteSecret, RotateSecret, PutResourcePolicy, TagResource) se registran automáticamente en CloudTrail y no se pueden desactivar. Estos eventos capturan el ciclo de vida administrativo de cada secreto.

Los eventos de datos (GetSecretValue) deben habilitarse por separado en CloudTrail. Al habilitar los eventos de datos para Secrets Manager, se crea una entrada de registro para cada recuperación de secreto, que muestra exactamente qué aplicación o usuario recuperó cada secreto y cuándo. Para cumplir con el requisito 10 de PCI DSS, los requisitos de control de auditoría de HIPAA y los controles de FedRAMP AU, los eventos de datos deben estar habilitados. Sin el registro de eventos de datos, se puede demostrar que un secreto se creó y rotó, pero no se puede demostrar quién lo recuperó ni cuándo.

Los registros de acceso a datos de KMS añaden una segunda capa: cada llamada de descifrado de KMS activada por una solicitud GetSecretValue de Secrets Manager genera un evento de CloudTrail que muestra el ARN de la clave KMS utilizada, el servicio de Secrets Manager que realizó la solicitud y la marca de tiempo. Este registro constituye la evidencia criptográfica de que un secreto específico se descifró en un momento determinado.

Las alertas clave que se deben configurar a partir de los eventos de CloudTrail Secrets Manager son: alertar inmediatamente sobre DeleteSecret para cualquier secreto de producción; alertar sobre llamadas GetSecretValue de entidades principales de IAM que no estén en la lista de roles de aplicación aprobados; alertar sobre llamadas GetSecretValue de alta frecuencia que puedan indicar la recolección automatizada de credenciales; y alertar sobre cambios en PutResourcePolicy en cualquier secreto de producción que puedan ampliar el acceso.

Características principales de AWS Secrets Manager

Integración con AWS KMS: Cada secreto se cifra en reposo mediante el cifrado de sobre de AWS KMS. Secrets Manager admite tanto claves administradas por AWS (aws/secretsmanager) como claves KMS administradas por el cliente. Cuando se configura una clave maestra de cliente (CMK), cada recuperación de un secreto genera un evento de descifrado de CloudTrail KMS, que proporciona un registro de auditoría por operación vinculado a la clave de cifrado del secreto. Deshabilitar la CMK impide inmediatamente cualquier recuperación posterior de ese secreto sin eliminarlo.

Almacenamiento secreto multiversión: Secrets Manager mantiene varias versiones de cada secreto simultáneamente mediante etiquetas de preparación. La etiqueta AWSCURRENT marca la versión en uso activo. Durante la rotación, la versión entrante se etiqueta AWSPENDING hasta que se complete la rotación, momento en el que se convierte en AWSCURRENT y la versión anterior se convierte en AWSPREVIOUSLas aplicaciones pueden recuperar una versión específica mediante su etiqueta o ID de versión, lo que permite la rotación sin tiempo de inactividad y sin necesidad de reiniciar las aplicaciones de forma coordinada.

Integración nativa con servicios de base de datos: Secrets Manager ofrece soporte integrado para la rotación nativa de credenciales en Amazon RDS (todos los motores de base de datos compatibles), Amazon DocumentDB, Amazon Redshift y Amazon ElastiCache. Para estos servicios, basta con habilitar la rotación desde la consola de Secrets Manager, seleccionar un calendario de rotación y Secrets Manager se encarga de todo el proceso sin necesidad de escribir ni implementar funciones Lambda manualmente.

Replicación de secretos entre regiones: Secrets Manager admite la replicación de secretos en varias regiones de AWS. Cuando un secreto se actualiza o rota en la región principal, la actualización se propaga automáticamente a las regiones de réplica. La replicación entre regiones es útil para aplicaciones multirregión donde los servicios de cada región necesitan acceder a las mismas credenciales sin realizar llamadas a la API entre regiones, y para configuraciones de recuperación ante desastres donde la región secundaria debe poder autenticarse en las bases de datos sin depender de la región principal.

Punto de conexión privado de VPC: De forma predeterminada, las llamadas a la API de Secrets Manager se realizan a través de internet (mediante HTTPS). Para cargas de trabajo en las que todo el tráfico debe permanecer dentro de los límites de la red de AWS (requisitos de cumplimiento, políticas de seguridad de red o requisitos de latencia), puede configurar un punto de conexión de VPC de Secrets Manager mediante AWS PrivateLink. Este punto de conexión crea una conexión privada desde su VPC al punto de conexión del servicio Secrets Manager, lo que garantiza que las solicitudes de recuperación de secretos nunca se realicen a través de internet.

Protección contra la eliminación y recuperación: Secrets Manager no elimina los secretos inmediatamente. Cuando elimina un secreto, se programa su eliminación después de un período de recuperación mínimo de 7 días (configurable hasta 30 días). Durante este período, puede restaurar el secreto y todas sus versiones. Una vez transcurrido este período, el secreto y todas sus versiones se destruyen permanentemente. Para eliminar un secreto inmediatamente (omitiendo el período de recuperación), utilice la CLI de AWS con el --force-delete-without-recovery Bandera. Esta opción de eliminación inmediata no está disponible en la consola.

Casos de uso principales de AWS Secrets Manager

Eliminar las credenciales de base de datos codificadas: El caso de uso más común. El código de la aplicación recupera las credenciales de conexión a la base de datos desde Secrets Manager en tiempo de ejecución mediante la API GetSecretValue, en lugar de leerlas desde variables de entorno, archivos de configuración o código fuente. El secreto se almacena en caché en el grupo de conexiones de la aplicación y se actualiza cuando se produce un evento de rotación. Esto elimina el riesgo de que las credenciales queden expuestas en el historial de control de versiones, los registros de compilación, las capas de la imagen del contenedor o los artefactos de implementación.

Rotación automatizada de credenciales de base de datos: Para bases de datos Amazon RDS, Secrets Manager puede rotar la contraseña del usuario de la base de datos según un cronograma (por ejemplo, cada 30 o 90 días) sin interrupciones. La función Lambda de rotación crea una nueva contraseña en RDS, la prueba y luego actualiza el secreto en Secrets Manager. Las aplicaciones que utilizan el SDK de Secrets Manager con almacenamiento en caché obtienen automáticamente la nueva contraseña sin necesidad de reiniciar.

Gestión del ciclo de vida de claves API y tokens OAuth: Las claves API de terceros, las credenciales de cliente OAuth y los tokens de cuenta de servicio se pueden almacenar en Secrets Manager y rotar mediante funciones Lambda personalizadas. Cuando el proveedor de API admite la rotación programática de credenciales, la función Lambda llama a la API de rotación del proveedor para generar una nueva clave, probarla y actualizar el secreto en Secrets Manager. Esto elimina los procesos manuales de rotación de credenciales, que son propensos a errores y a menudo se pasan por alto.

Gestión centralizada de secretos para entornos AWS con varias cuentas: En entornos AWS Organizations con varias cuentas (desarrollo, pruebas, producción, servicios compartidos), Secrets Manager, con políticas de recursos entre cuentas y replicación entre regiones, proporciona un modelo de gobernanza de secretos centralizado. Los secretos se crean y gestionan en una cuenta de secretos dedicada, las aplicaciones de otras cuentas acceden a ellos mediante políticas de IAM entre cuentas y se auditan de forma centralizada a través de CloudTrail en la cuenta de auditoría.

Administración de credenciales para cargas de trabajo locales e híbridas: Las aplicaciones que se ejecutan en entornos locales o fuera de AWS pueden recuperar secretos de Secrets Manager a través del punto final de la API pública o mediante un punto final privado conectado a una VPC. Esto permite que las arquitecturas de nube híbrida centralicen la administración de secretos en AWS, incluso para cargas de trabajo que no se hayan migrado completamente a la nube.

AWS Secrets Manager frente a SSM Parameter Store

AWS Systems Manager Parameter Store (SSM Parameter Store) es la otra opción nativa de AWS para almacenar secretos y configuraciones. Ambos servicios pueden almacenar valores cifrados mediante KMS, pero se adaptan a diferentes casos de uso principales.

Dimensión	Director de secretos de AWS	Almacén de parámetros SSM
Propósito primario	Gestión del ciclo de vida de los secretos (rotación, auditoría, replicación)	Almacenamiento de configuración y parámetros de la aplicación
Costo	$0.40/secreto/mes + $0.05/10 000 llamadas a la API	Gratis para parámetros estándar; 0.05 $/10 000 llamadas a la API para parámetros cifrados avanzados.
Rotación automática	Sí (nativo para RDS/DocumentDB/Redshift; Lambda personalizada para otros)	No (debe compilarse externamente)
Versionado secreto	Sí (etiquetas AWSCURRENT, AWSPENDING, AWSPREVIOUS)	Sí (números de versión)
Acceso entre cuentas	Sí (a través de la política de recursos)	Limitado (configuración más compleja)
Replicación entre regiones	Sí (incorporado)	No (debe compilarse externamente)
Punto de enlace de VPC	Sí (AWS PrivateLink)	Sí (a través del punto final VPC de SSM)
Cifrado KMS	Siempre activo (gestionado por AWS o CMK)	Opcional (el tipo SecureString utiliza KMS)
Tamaño secreto máximo	65 KB	4 KB (estándar) / 8 KB (avanzado)
Ideal para	Credenciales de base de datos, claves API, tokens que requieren rotación	Configuración de la aplicación, indicadores de características, parámetros no rotados

La regla de decisión es sencilla: si el secreto requiere rotación automática o acceso entre cuentas o regiones, utilice Secrets Manager. Si se trata de un parámetro de configuración o una credencial que no rota, SSM Parameter Store es suficiente y considerablemente más económico.

Costo y optimización de AWS Secrets Manager

El precio de AWS Secrets Manager se compone de dos elementos: un cargo por almacenamiento de secreto y un cargo por llamada a la API. El precio actual es de $0.40 por secreto al mes y $0.05 por cada 10 000 llamadas a la API. Los nuevos usuarios de Secrets Manager pueden disfrutar de una prueba gratuita de 30 días.

Para una aplicación típica que recupera un único secreto de base de datos un millón de veces al mes (mediante recuperación en caché al crear el grupo de conexiones, no en cada consulta), el coste mensual sería de aproximadamente 0.40 $ por el secreto más 0.05 $ por las llamadas a la API, lo que suma menos de 1 $ al mes. El coste aumenta linealmente con el número de secretos y el volumen de llamadas a la API.

La principal técnica de optimización de costos para Secrets Manager es el almacenamiento en caché del lado del cliente. El SDK de AWS Secrets Manager incluye un cliente de almacenamiento en caché integrado para Java, Python, .NET, Go y JavaScript. Este cliente recupera el secreto una sola vez, lo almacena en memoria y atiende las solicitudes posteriores desde la caché durante un tiempo de vida útil (TTL) configurable (1 hora por defecto). La caché se actualiza automáticamente cuando se produce un evento de rotación. El almacenamiento en caché reduce el volumen de llamadas a la API considerablemente para aplicaciones de alta frecuencia.

Si se configura una clave KMS administrada por el cliente para el secreto, se aplican costos adicionales por cada llamada a la API de KMS: $0.03 por cada 10 000 operaciones criptográficas de KMS. Cada llamada a GetSecretValue activa una llamada a KMS Decrypt. Para aplicaciones de alto volumen, la combinación del SDK de almacenamiento en caché de Secrets Manager con una clave CMK configurada para el secreto es el método estándar para controlar simultáneamente los costos de Secrets Manager y KMS.

Arquitectura de gestión de secretos híbrida y multi-nube

AWS Secrets Manager es un servicio nativo de AWS y no gestiona de forma nativa los secretos para las cargas de trabajo de Azure o GCP. Las organizaciones que operan en entornos multinube o híbridos necesitan una estrategia explícita para la gestión de secretos en todos los proveedores de nube. Tres patrones abordan esta cuestión:

• Administrador de secretos nativo por nube: Utilice AWS Secrets Manager para cargas de trabajo de AWS, Azure Key Vault para cargas de trabajo de Azure y GCP Secrets Manager para cargas de trabajo de GCP. Las aplicaciones de cada nube utilizan su servicio nativo. Una plataforma centralizada de gestión de secretos agrega los registros de auditoría y la aplicación de políticas en los tres proveedores, lo que proporciona visibilidad entre nubes sin generar latencia en la recuperación de secretos.
• Gestor de secretos centralizado con entrega por nube: Un gestor de secretos de terceros o autogestionado (que se ejecuta fuera de todos los proveedores de nube o en una nube autorizada) almacena la copia maestra de todos los secretos. Los agentes o mecanismos de sincronización de cada nube envían los secretos al servicio nativo de cada nube (AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager) según sea necesario. La copia maestra es la fuente de información fidedigna para la rotación, la auditoría y la política de acceso.
• Acceso directo a la API entre nubes: Las cargas de trabajo de AWS solo acceden a AWS Secrets Manager; las cargas de trabajo de Azure y GCP solo acceden a sus respectivos servicios nativos. Los secretos compartidos (como una clave API de terceros utilizada por servicios en las tres nubes) se almacenan en el servicio de secretos nativo de cada nube de forma independiente, con rotación sincronizada en las tres cuando cambia la credencial. CBOM seguro Ayuda a descubrir e inventariar todos los secretos y claves en entornos multinube para identificar deficiencias en la cobertura de rotación y la coherencia de las políticas de acceso.

Cumplimiento normativo: PCI DSS, HIPAA, FedRAMP y GDPR

PCI DSS v4.0.1 (obligatorio desde el 31 de marzo de 2025): Secrets Manager aborda directamente varios requisitos de PCI DSS. El requisito 8.6.2 prohíbe codificar las credenciales en scripts, código o archivos de configuración; el modelo de recuperación basado en API de Secrets Manager cumple este requisito por diseño. El requisito 8.3.9 requiere la rotación periódica de las credenciales de autenticación; la rotación automática programada cumple este requisito para las credenciales de la base de datos y las cuentas de servicio. El requisito 3.5.1 (proteger los datos de la cuenta almacenados mediante criptografía robusta) se cumple cuando se utiliza una clave KMS administrada por el cliente con respaldo de CloudHSM. El registro de eventos de datos de CloudTrail de las llamadas a GetSecretValue cumple el requisito 10 (registro de auditoría del acceso al entorno de datos del titular de la tarjeta).

HIPAA: AWS Secrets Manager está cubierto por el Acuerdo de Asociado Comercial (BAA) de AWS. Para sistemas adyacentes a la información médica electrónica protegida (ePHI), es decir, aplicaciones que se autentican en bases de datos o servicios que almacenan ePHI, Secrets Manager evita la exposición de credenciales en el código (medida de control de acceso, 45 CFR 164.312(a)(1)). El registro de CloudTrail de las llamadas a GetSecretValue cumple con el estándar de Control de Auditoría (45 CFR 164.312(b)) para el acceso a las credenciales que desbloquean los sistemas de ePHI.

FedRAMP: AWS Secrets Manager está incluido en el paquete de autorización FedRAMP High de AWS. Para cargas de trabajo FedRAMP High que requieren protección de clave FIPS 140-2 Nivel 3 para la clave KMS utilizada para cifrar secretos, configure una clave KMS administrada por el cliente respaldada por un almacén de claves personalizado de CloudHSM. Esto cumple con SC-12 (Administración de claves criptográficas) y SC-28 (Protección de la información en reposo) en el nivel de referencia High. Consulte nuestra guía sobre seguridad de AWS KMS para obtener detalles sobre la configuración de CloudHSM.

RGPD: El artículo 32 del RGPD exige medidas técnicas adecuadas para la protección de datos personales. El uso de Secrets Manager para evitar que las credenciales de la base de datos, codificadas directamente en el código fuente, los registros y los artefactos de compilación, constituye una medida técnica que reduce la superficie de ataque para el acceso no autorizado a sistemas que contienen datos personales. La rotación automática reduce el tiempo de exposición en caso de que una credencial se vea comprometida. El registro de CloudTrail proporciona el historial de auditoría para demostrar los controles de acceso a las autoridades de supervisión.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada y seguridad en la nube con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a diseñar, implementar y auditar implementaciones de AWS Secrets Manager, desde la arquitectura inicial hasta la generación continua de evidencia de cumplimiento.

• Arquitectura y migración de Secrets Manager: Evaluamos su postura actual de gestión de credenciales (identificando credenciales codificadas en el código, la configuración, las variables de entorno y las canalizaciones de CI/CD), diseñamos la arquitectura objetivo de Secrets Manager (jerarquía de secretos, configuración de claves KMS, modelo de política de recursos, programa de rotación por tipo de secreto) e implementamos el plan de migración. Consulte nuestra servicios de consultoría en la nube.
• Configuración de claves KMS gestionadas por el cliente para secretos: Configuramos claves KMS gestionadas por el cliente para los secretos de Secrets Manager, diseñamos la política de claves que separa a los administradores de claves de los usuarios de claves, habilitamos el registro de acceso a datos de CloudTrail tanto para Secrets Manager como para KMS para proporcionar el registro de auditoría por recuperación requerido por PCI DSS y HIPAA, y configuramos alertas de CloudWatch para patrones de acceso anómalos. Para los requisitos de FIPS 140-2 Nivel 3, configuramos almacenes de claves personalizados respaldados por CloudHSM. Consulte nuestra HSM como servicio.
• Implementación de rotación automática: Implementamos y probamos funciones Lambda de rotación automática para los servicios de bases de datos de AWS compatibles y para tipos de secretos personalizados (bases de datos locales, claves API de terceros, tokens OAuth). Configuramos calendarios de rotación que se ajustan a sus requisitos de cumplimiento (rotación de 90 días según PCI DSS, rotación definida por la política HIPAA) y probamos los eventos de rotación para garantizar un funcionamiento sin interrupciones en entornos de producción.
• CBOM Seguro para el Descubrimiento de Secretos: Los entornos de AWS que han crecido orgánicamente a menudo tienen secretos dispersos en variables de entorno, codificados directamente en el código, almacenados en SSM Parameter Store sin cifrado o duplicados en varias cuentas. CBOM seguro Descubre e inventaría todas las ubicaciones de almacenamiento de secretos en sus cuentas de AWS, identifica los secretos no cifrados o mal gestionados y genera una lista de materiales criptográficos (CBOM) en formato CycloneDX que cumple con la documentación del requisito 12.3.3 de PCI DSS v4.0.1.
• Aviso sobre el cumplimiento de PCI DSS y HIPAA: Mapeamos la configuración de su Administrador de secretos a los requisitos específicos de PCI DSS v4.0.1, HIPAA, FedRAMP High y GDPR. Identificamos brechas de control, generamos el paquete de evidencia de cumplimiento y ayudamos con las consultas de QSA y auditores sobre la gestión de secretos. Consulte nuestra Servicios de asesoramiento sobre cumplimiento.

Para hablar sobre su arquitectura de gestión de secretos o sus requisitos de cumplimiento, póngase en contacto con Encryption Consulting.

Conclusión

AWS Secrets Manager aborda una de las vulnerabilidades más persistentes y explotadas en la seguridad de las aplicaciones en la nube: las credenciales en el código. Al proporcionar un almacén de secretos centralizado basado en API con cifrado KMS en reposo, rotación automática, acceso controlado por IAM y registro de auditoría de CloudTrail, Secrets Manager elimina la necesidad de que existan credenciales en texto plano fuera de un HSM o una respuesta de API autenticada.

Las decisiones de configuración más importantes son: usar una clave KMS administrada por el cliente en lugar de la clave predeterminada administrada por AWS (para el registro de auditoría por operación y la capacidad de revocación independiente), habilitar los eventos de datos de CloudTrail para GetSecretValue (para que pueda demostrar quién recuperó qué y cuándo), habilitar la rotación automática según un cronograma que cumpla con las normas y usar el cliente de almacenamiento en caché del SDK para controlar los costos de las llamadas a la API a gran escala.

Para las organizaciones con implementaciones de AWS KMS existentes, Secrets Manager se integra en la misma infraestructura de gestión de claves y auditoría sin complejidad arquitectónica adicional. Para las organizaciones que comienzan desde cero, Secrets Manager, combinado con una clave KMS administrada por el cliente y los eventos de datos de CloudTrail, es la vía más rápida para lograr una gestión de secretos segura y auditable. Para obtener más información sobre la capa de gestión de claves de cifrado que sustenta Secrets Manager, consulte nuestro análisis en profundidad de AWS Key Management Service.

Preguntas frecuentes

¿Qué es AWS Secrets Manager?

AWS Secrets Manager es un servicio administrado que almacena, recupera, rota y audita secretos como credenciales de bases de datos, claves de API, tokens OAuth y claves SSH. Todos los secretos se cifran en reposo mediante el cifrado de sobre de AWS KMS (AES-256-GCM). Los secretos nunca se almacenan en texto plano. Las aplicaciones recuperan los secretos mediante llamadas a la API en lugar de leerlos desde variables de entorno o código fijo, lo que elimina la exposición de credenciales en el código fuente y los artefactos de compilación.

¿Cómo cifra AWS Secrets Manager los secretos?

Secrets Manager utiliza el cifrado de sobre de AWS KMS. Al almacenar un secreto, Secrets Manager llama a KMS GenerateDataKey para obtener una clave de datos AES-256, cifra el valor del secreto con ella (AES-256-GCM) y almacena el secreto cifrado junto con la clave de datos cifrada. La clave de datos en texto plano se descarta inmediatamente. Al recuperarla, Secrets Manager llama a KMS Decrypt para recuperar la clave de datos, descifra el secreto y devuelve el valor en texto plano mediante TLS. La clave predeterminada es la clave aws/secretsmanager administrada por AWS; las claves KMS administradas por el cliente proporcionan un registro de auditoría y revocación independiente para cargas de trabajo de cumplimiento.

¿Cómo rota automáticamente los secretos AWS Secrets Manager?

La rotación utiliza una función AWS Lambda que consta de cuatro pasos: CreateSecret (genera una nueva versión), SetSecret (actualiza la credencial en el servicio de destino), TestSecret (verifica que la nueva credencial funcione) y FinishSecret (marca la nueva versión como AWSCURRENT). Para Amazon RDS, DocumentDB y Redshift, AWS proporciona funciones Lambda de rotación administradas. Para cualquier otro servicio, se implementa una función Lambda personalizada que sigue los mismos cuatro pasos. La rotación se ejecuta según una programación configurable (mínimo 1 día) o bajo demanda.

¿Cuál es la diferencia entre AWS Secrets Manager y AWS Systems Manager Parameter Store?

Secrets Manager cuesta 0.40 $/secreto/mes e incluye rotación automática, acceso entre cuentas, replicación entre regiones y un tamaño de secreto de hasta 65 KB. SSM Parameter Store es gratuito para parámetros estándar (hasta 10 000) y es ideal para la configuración de aplicaciones y credenciales que no requieren rotación. Elija Secrets Manager cuando necesite rotación automática o acceso entre cuentas/regiones. Elija SSM Parameter Store para parámetros de configuración generales y cargas de trabajo sensibles al coste que no requieren rotación.

¿AWS Secrets Manager cumple con los requisitos de PCI DSS y HIPAA?

Sí, cuando está configurado correctamente. Secrets Manager cumple con los requisitos 8.6.2 (sin credenciales codificadas), 8.3.9 (rotación periódica) y 10 (registro de auditoría mediante eventos de datos de CloudTrail) de PCI DSS v4.0.1. Una clave KMS administrada por el cliente con respaldo de CloudHSM cumple con los requisitos 3.5.1 y 3.7.1. Para HIPAA, Secrets Manager está cubierto por el BAA de AWS y evita la exposición de credenciales en el código (protección de control de acceso, 45 CFR 164.312(a)(1)). El registro de CloudTrail cumple con el estándar de control de auditoría (164.312(b)).

¿Cómo puedo acceder a los secretos de AWS Secrets Manager desde una aplicación?

Llama a la API GetSecretValue con el nombre o ARN del secreto. La identidad que realiza la llamada (rol o usuario de IAM) debe tener el permiso secretsmanager:GetSecretValue sobre ese ARN de secreto específico, otorgado tanto en la política de identidad de IAM como en la política de recursos del secreto. Usa el cliente de almacenamiento en caché del SDK de AWS Secrets Manager para almacenar el secreto en memoria y reducir la frecuencia de las llamadas a la API. Para cargas de trabajo que no deben realizar llamadas a Internet, configura un punto de conexión de VPC de Secrets Manager (AWS PrivateLink) para enrutar el tráfico de recuperación de secretos dentro de tu VPC.