Secretos y clasificación de datos
Secrets Manager con rotación automática desde Fargate, certificados con ACM y Private CA, y descubrimiento de PII con Amazon Macie.
Los secretos y los datos sensibles comparten un problema: proliferan en sitios donde no deberían. Una contraseña de base de datos acaba en un .env commiteado; un certificado caduca un domingo por la noche; un bucket de pruebas termina lleno de PII real que nadie recuerda haber copiado. Esta nota cubre las tres piezas que AWS ofrece para tenerlos bajo control en Citas: Secrets Manager para las credenciales, ACM / Private CA para los certificados y Macie para descubrir dónde están los datos sensibles.
Secrets Manager: credenciales que rotan solas#
El patrón correcto es simple de enunciar: la aplicación no debe conocer sus secretos de antemano. Los pide en tiempo de ejecución a Secrets ManagerAWS Secrets ManagerServicio gestionado de AWS para guardar, cifrar con KMS, recuperar y rotar automáticamente secretos como credenciales de base de datos y claves de API., que los guarda cifrados con KMSAWS KMSServicio gestionado de AWS que crea y controla claves de cifrado; las claves nunca salen en claro y cada una lleva su propia key policy. y controla el acceso con IAM más la key policy de la llave. Cada recuperación queda registrada en CloudTrail.
Referenciar el secreto desde la tarea Fargate#
En ECS hay dos formas de dar un secreto a un contenedor, y la diferencia importa:
La app llama a Secrets Manager con el SDK al arrancar (o bajo demanda) y cachea el valor. Como siempre pide AWSCURRENT, cuando el secreto rota recoge la versión nueva sin redeploy. Es el único modo que aprovecha de verdad la rotación sin downtime.
import boto3, json_sm = boto3.client("secretsmanager")
def get_db_credentials(): resp = _sm.get_secret_value(SecretId="citas/rds-cred") # AWSCURRENT return json.loads(resp["SecretString"])La task definition referencia el secreto por ARN en secrets (no en environment). ECS lo resuelve en el arranque y lo inyecta como variable de entorno. Mejor que texto plano, pero el valor se fija al iniciar el contenedor: tras una rotación necesitas reiniciar la tarea para recogerlo.
"secrets": [ { "name": "DB_CRED", "valueFrom": "arn:aws:secretsmanager:eu-west-1:111122223333:secret:citas/rds-cred" }]"environment": [ { "name": "DB_PASSWORD", "value": "p@ssw0rd-en-claro" }]El secreto queda visible en la task definition, en la consola y para cualquiera con ecs:DescribeTaskDefinition.
Cómo rota sin downtime#
La rotación automática usa una función Lambda que AWS invoca en cuatro pasos. La clave son las etiquetas de versión (AWSCURRENT, AWSPENDING, AWSPREVIOUS): la app siempre pide AWSCURRENT, y la rotación solo mueve esa etiqueta cuando la credencial nueva ya funciona.
Paso 1 de 5La app lee el secreto
La API de Citas no lleva la contraseña en variables de entorno: la pide a Secrets Manager (AWSCURRENT = v1) en tiempo de ejecución y conecta a RDS.
createSecret— la Lambda genera una contraseña nueva y la guarda como versión nueva, etiquetadaAWSPENDING.setSecret— cambia la contraseña en RDS a la de la versiónAWSPENDING.testSecret— comprueba que la credencial nueva realmente conecta.finishSecret— mueveAWSCURRENTa la versión nueva; la antigua pasa aAWSPREVIOUS.
Como el cambio solo se consolida tras testSecret, no hay ventana en la que la etiqueta AWSCURRENT apunte a una credencial que no sirve. Y como la contraseña vieja se cambia en el motor, una AWSPREVIOUS filtrada deja de autenticar.
Certificados: ACM y AWS Private CA#
Los secretos no son solo contraseñas: los certificados y sus claves privadas también lo son, y caducan. AWS Certificate Manager (ACM) emite y renueva automáticamente certificados públicos (validados por DNS) para tus endpoints públicos —el CloudFront y el ALB de Citas— sin que tengas que tocar nada. La clave privada nunca sale de AWS y se integra directamente con esos servicios.
Para certificados internos —TLS entre microservicios, mTLS, dispositivos— usas AWS Private CA: tu propia autoridad de certificación gestionada, cuya raíz confían solo tus sistemas. Así puedes cifrar el tráfico este-oeste dentro de la VPC y autenticar servicios con certificados de corta duración que rotan solos, en lugar de secretos compartidos.
Clasificación de datos: descubrir PII con Macie#
No puedes proteger lo que no sabes que tienes. Después de meses de desarrollo, ¿estás seguro de que citas-adjuntos solo contiene adjuntos, y no un volcado de la base de datos que alguien dejó “temporalmente”? ¿De que ese bucket de pruebas no tiene PII real? Amazon Macie responde a esa pregunta: descubre y clasifica datos sensibles en S3.
Macie mantiene un inventario de tus buckets y aplica managed data identifiers —criterios integrados que detectan tarjetas de crédito, claves de acceso de AWS, números de pasaporte, y muchos tipos de PII— además de identificadores personalizados por regex para lo tuyo (un formato de número de historia clínica, por ejemplo). Trabaja de dos formas:
- Automated sensitive data discovery: evalúa a diario el inventario y muestrea objetos para dar visibilidad amplia de dónde podría haber datos sensibles, con poco coste.
- Sensitive data discovery jobs: análisis dirigidos y repetibles sobre los buckets que elijas, para auditorías o cumplimiento.
Genera findings con un esquema estándar que puedes enrutar a Security Hub o a EventBridge para automatizar una respuesta (avisar, cuarentenar el bucket, abrir un ticket).
Tu turno
Pon a prueba tus secretos y tus datos
Sobre un sistema de tu trabajo o tu lab:
- Busca secretos hardcodeados: pasa
gitleaksotrufflehogpor el repositorio y el historial. ¿Aparece algo? - Para un secreto de base de datos, ¿está en Secrets Manager? ¿Tiene rotación activada? ¿La app lo lee en runtime o va en una variable de entorno plana?
- ¿Quién renueva tus certificados? ¿Hay alguno que se renueve a mano?
- Lanza un sensitive data discovery job de Macie (o revisa la discovery automática) sobre un bucket y mira si encuentra PII donde no la esperabas.
- Elige una acción: migra un secreto a Secrets Manager con rotación, o cuarentena un bucket con un finding de Macie.
Reto
Inyectas el secreto en el contenedor con la clave `secrets` de ECS. ¿Recoge la app la nueva credencial cuando el secreto rota?
▸Mostrar solución
No automáticamente. ECS resuelve el secreto en el arranque y lo inyecta como variable de entorno; ese valor no cambia mientras la tarea vive. Tras una rotación necesitas reiniciar la tarea, o que la app lea el secreto con el SDK en runtime y refresque su caché. La inyección de ECS es mejor que el texto plano, pero no aprovecha la rotación sin reinicio.
Reto
Macie no encuentra PII en un bucket que sabes que la tiene. ¿Qué miras primero?
▸Mostrar solución
Lo más probable: los objetos están cifrados con una KMS key cuya key policy no permite al rol de Macie usarla, así que Macie no puede leer el contenido. Revisa también que el formato y la clase de almacenamiento estén soportados y que la bucket policy no esté bloqueando a Macie. No es que no haya PII: es que Macie no pudo mirar.
En resumen#
- La app no conoce sus secretos: los pide a Secrets Manager en runtime; nunca van en claro en el código ni en la task definition.
- La rotación automática mueve
AWSCURRENTsolo tras probar la credencial nueva (createSecret → setSecret → testSecret → finishSecret): la app recoge la nueva sin downtime y la vieja deja de servir. - ACM renueva solo los certificados públicos; Private CA emite los internos de vida corta.
- Macie descubre PII en S3 con managed data identifiers; necesita permiso en la key policy para leer objetos cifrados.
- Enruta los findings a Security Hub / EventBridge para responder de forma automática.