Una clave de acceso de AWS son dos cadenas que, juntas, permiten que un programa actúe como un usuario de IAM: el ID de clave de acceso, que identifica la clave, y la clave de acceso secreta, que demuestra que la tienes. La gente las busca con tres nombres (access key y secret key, secret access key o simplemente AWS secret key), y todos se refieren al mismo par. Ese par aparece en configuraciones de la CLI, en pipelines de CI y, con demasiada frecuencia, en un mensaje de Slack.
Esta guía explica qué son las dos mitades, cómo crearlas y configurarlas, cómo rotarlas sin interrumpir el servicio, qué hacer cuando una se filtra y la pregunta que surge cada vez que se incorpora un desarrollador o empieza un contratista: cómo entregar una clave secreta a una persona sin ponerla en un correo.
ID de clave de acceso frente a clave de acceso secreta
| ID de clave de acceso | Clave de acceso secreta | |
|---|---|---|
| Aspecto | AKIAIOSFODNN7EXAMPLE (20 caracteres) | 40 caracteres entre mayúsculas, minúsculas y símbolos |
| Función | Identifica qué clave firma la solicitud | Firma la solicitud y demuestra que la tienes |
| ¿Es secreto? | No, trátalo como un nombre de usuario | Sí, trátala como una contraseña |
| ¿Se puede ver después? | Sí, en la consola de IAM | Nunca después de crearla |
Las claves de larga duración empiezan por AKIA. Las credenciales temporales de STS, que además llevan un token de sesión, empiezan por ASIA y expiran solas. Si ves una clave ASIA en un archivo de configuración, dejará de funcionar en unas horas, y está pensado así.
Ninguna de las dos mitades concede permisos. La clave se autentica como un usuario de IAM, y las políticas asociadas a ese usuario deciden qué puede hacer esa identidad. Una clave filtrada de un usuario de solo lectura es un problema. Una clave filtrada de un administrador es un incidente.
Cuándo necesitas de verdad una clave de larga duración
La respuesta sincera: menos a menudo de lo que se cree.
- Las cargas de trabajo en AWS (EC2, Lambda, ECS, EKS) deben usar roles de IAM. El SDK obtiene credenciales de corta duración automáticamente y no hay nada que rotar ni que se pueda filtrar.
- Las personas deben iniciar sesión con IAM Identity Center o con inicio de sesión único federado y obtener credenciales temporales con
aws sso login. - Los sistemas de CI, como GitHub Actions, pueden asumir un rol mediante OIDC sin guardar ninguna clave.
- Las claves de larga duración quedan para los casos que no pueden usar nada de lo anterior: una herramienta en un portátil que no admite SSO, un servicio de terceros que solo acepta claves estáticas o un proceso heredado que todavía no has migrado.
Si necesitas una, créala en un usuario de IAM dedicado con la política más restrictiva que permita hacer el trabajo, y nunca en la cuenta de administrador de una persona.
Crear y configurar una clave
En la consola de IAM, abre el usuario, elige «Security credentials» y después «Create access key». Elige el caso de uso que pregunta AWS, lee la alternativa que propone y continúa. La clave secreta se muestra una sola vez. Guárdala directamente en tu almacén de secretos o en tu gestor de contraseñas, o descarga el CSV y elimínalo después de importarlo. Cada usuario de IAM puede tener como máximo dos claves a la vez, y eso es lo que hace posible la rotación.
En una máquina, configura un perfil con nombre en lugar del perfil por defecto:
aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1
Esto escribe ~/.aws/credentials y ~/.aws/config. Restringe el archivo a tu usuario con chmod 600. En contenedores y en CI, inyecta AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY como secretos desde el almacén de la plataforma, no como variables normales en un archivo YAML, y nunca las pases en la línea de comandos, donde acaban en el historial de la shell.
Rotar sin romper nada
La rotación se hace en cuatro pasos, y es posible gracias al límite de dos claves.
- Crea la segunda clave en el mismo usuario.
- Actualiza todo lo que la usa con la clave nueva: configuraciones, secretos de CI, la entrada del gestor de secretos. La consola de IAM muestra cuándo se usó cada clave por última vez, y así sabes si se te ha escapado alguno.
- Desactiva la clave antigua. Espera un día o un ciclo de despliegue. Si algo falla, reactívala, corrige lo que la usaba y vuelve a intentarlo.
- Elimina la clave antigua cuando compruebes que ya nada la usa.
Rota con regularidad las claves que tienen que existir, y todas ellas cuando ocurra algo: una baja, un cambio de proveedor, un portátil perdido, una sospecha de filtración. AWS Config e IAM Access Analyzer pueden señalar las claves más antiguas de lo que permite tu política.
Cuando una clave queda expuesta
Considera comprometida cualquier clave que haya aparecido en un repositorio, un registro, un ticket o un chat, aunque se borrara un minuto después. Los escáneres encuentran los secretos publicados en segundos.
- Desactiva la clave en IAM ya. No esperes a crear antes la sustituta, salvo que la interrupción sea peor que la exposición.
- Crea una clave sustituta y actualiza todo lo que usaba la anterior.
- Revisa CloudTrail en busca de cada acción hecha con ese ID de clave de acceso desde la exposición. Busca usuarios o claves de IAM nuevos, instancias nuevas, políticas de bucket modificadas y regiones que no te suenen.
- Revisa la factura y Cost Explorer en busca de picos típicos de la minería de criptomonedas.
- Quita el secreto del código, los registros y el historial de git. Cuando detecta una filtración pública, AWS puede asociar por su cuenta la política
AWSCompromisedKeyQuarantineal usuario; déjala puesta hasta terminar la limpieza. - Elimina la clave antigua y después averigua cómo llegó hasta allí y cierra esa vía.
Cómo compartir una clave secreta de AWS con una persona
A veces la clave tiene que llegar a una persona: un contratista que la necesita para una herramienta de despliegue, un desarrollador que se incorpora a un proyecto antes de que esté configurado el SSO o la integración de un proveedor que pide pegarla en su panel. El correo, Slack y los tickets guardan copias, y un secreto de 40 caracteres en cualquiera de ellos se puede leer durante años.
El procedimiento seguro lleva un minuto:
- Crea una clave para esa persona en un usuario de IAM dedicado, con la política que necesita su tarea y nada más. No compartas una clave que use cualquier otra cosa.
- Pega solo la clave de acceso secreta en un enlace secreto de un solo uso. Se cifra en tu navegador antes de guardarse, la copia almacenada se destruye la primera vez que se abre el enlace y el enlace expira al cabo de una hora, un día o una semana si nadie lo abre.
- Envía el enlace con una línea de contexto. Envía el ID de clave de acceso, la región y el nombre del perfil en otro mensaje; ninguno de esos datos es secreto por sí solo.
- Añade una frase de contraseña con una cuenta Pro para cualquier clave que no sea de solo lectura, y comunícala por SMS o en una llamada.
- Confirma que lo ha abierto. Si el enlace indica que ya se vio y la persona no lo abrió, desactiva la clave y empieza de nuevo.
- Desactiva la clave cuando termine el encargo, y elimínala después.
La guía de claves de API aplica el mismo patrón a otros proveedores, y compartir enlaces de forma segura para desarrolladores explica cómo automatizar la entrega con scripts al incorporar a alguien.