Gestionar la 2FA de una cuenta de AWS compartida

Nadie debería conectarse a AWS con un identificador compartido. El acceso diario corresponde a identidades por persona mediante IAM Identity Center, y la automatización corresponde a roles y no a nada que un humano escriba.

Queda el usuario raíz, que sí es un identificador único por cuenta. Lo útil de saber es que tampoco tienes que compartir su segundo factor: AWS permite registrar varios dispositivos MFA en el usuario raíz, así que dos o tres administradores pueden inscribir cada uno el suyo. Copiar un secreto TOTP es una solución de repliegue para los casos en que eso no es posible, no la opción por defecto.

Tres identificadores distintos

«Nuestra cuenta de AWS» suele significar una de estas tres cosas, y tienen respuestas diferentes.

El usuario raíz. Uno por cuenta, identificado por una dirección de correo, capaz de hacerlo todo, incluido cerrar la cuenta y cambiar la facturación. No está hecho para el trabajo diario.

Las identidades por persona. Usuarios de IAM Identity Center, o usuarios IAM en las configuraciones más antiguas. Ahí es donde se hace el trabajo de verdad, y donde cada uno tiene su propio segundo factor.

Las claves de acceso. Credenciales de larga duración para el acceso programático. No es una conexión, no está protegido por la MFA como la gente supone, y es lo que más a menudo se encuentra en un repositorio viejo.

La mayoría de las preguntas sobre la «2FA de AWS compartida» tratan en realidad del primero, y surgen porque los otros dos nunca se pusieron en marcha.

Trabajo diario: identidades por persona

IAM Identity Center da a cada persona su propia conexión, su propia MFA, y credenciales de duración limitada en las cuentas y roles a los que tiene derecho. El acceso se concede por asignación en vez de entregando nada, y retirar a alguien es una acción en un solo sitio, sean cuantas sean las cuentas de AWS que explotas.

Si aún estás con usuarios IAM, el mínimo es un usuario por persona, cada uno con su dispositivo MFA, y ningún usuario compartido para el equipo. Un usuario IAM compartido tiene todos los problemas de un usuario raíz compartido sin ninguna de sus razones de ser.

Para una agencia que trabaja en la cuenta de un cliente, el equivalente de «invítame» es un rol entre cuentas: el cliente conserva la propiedad y puede revocarlo en un solo sitio, y nadie envía credenciales por correo.

Automatización: roles, no conexiones

Todo lo que se ejecute sin vigilancia debería asumir un rol en lugar de conectarse. En el propio AWS, eso significa perfiles de instancia, roles de tarea o una federación OIDC desde tu proveedor de CI. Son credenciales de duración limitada, sin secreto que guardar y sin nada que un humano tenga que escribir.

Si un script le pide un código de seis cifras a alguien, es que está usando la identidad de un humano, y se romperá el día en que ese humano se vaya.

Las claves de acceso de larga duración son la otra mitad del asunto. Son revocables y renovables individualmente, lo que es una ventaja real sobre un secreto TOTP, pero también son las credenciales que se filtran en los commits. Ten pocas y rótalas con un calendario que respetes de verdad.

El usuario raíz: la verdadera cuenta compartida

La raíz existe, varias personas deben poder alcanzarla, y no debe depender del teléfono de una sola persona.

Registra más de un dispositivo MFA

Es la respuesta propia de AWS, y elimina por completo la cuestión de compartir. Inscribe la aplicación o la llave física de cada administrador que deba poder actuar como raíz. Cada dispositivo guarda su propio secreto, y ningún secreto se copia nunca. Una salida es dar de baja un dispositivo, no restablecer la 2FA de la cuenta y reinscribir a todo el mundo.

Donde una llave física sea viable, aquí es donde vale su precio: el segundo factor no se puede capturar en imagen, ni transferir, ni sincronizar.

Apunta el correo raíz a un buzón que dos personas puedan leer

La recuperación de la raíz pasa por esa dirección. El buzón personal de un fundador vuelve la cuenta irrecuperable el día en que él ya no está: usa una lista de distribución o un buzón compartido, y asegúrate de que quienes pueden leerlo son gente a la que confiarías la recuperación de la cuenta, porque funcionalmente es lo que esa dirección concede.

Elimina las claves de acceso raíz

No debería haber ninguna. Si existen, son credenciales compartidas sin ninguna MFA delante, lo que es peor que todo lo demás de este artículo.

Vigila las conexiones raíz

CloudTrail las registra, y una alarma sobre el uso de la raíz es práctica común. En una cuenta sana, las conexiones raíz son raras y explicables, lo que las hace baratas de vigilar y valiosas de ver.

Cuando un secreto TOTP compartido sigue siendo la respuesta

Los dispositivos MFA múltiples cubren la mayoría de los casos. Unos pocos se resisten:

• La cuenta de un cliente que no administras, donde te entregan credenciales sin que puedas reestructurar nada.
• Consolas antiguas o de terceros alrededor de AWS (un portal de facturación, un panel de revendedor, un proveedor de supervisión) que aceptan exactamente una inscripción TOTP.
• Un identificador de emergencia que tu procedimiento exige que varias personas puedan usar rápido, allí donde los dispositivos individuales no son viables.

Para esos, las exigencias son las de cualquier cuenta compartida: una custodia única del secreto, un acceso a los códigos concedido por persona, un registro de quién leyó un código, y códigos de recuperación guardados fuera de la cuenta que recuperan. El razonamiento está en cómo compartir códigos 2FA en equipo con seguridad, y la comparación de mecanismos en las mejores formas de gestionar la 2FA de una cuenta compartida. El mismo razonamiento aplicado a un proveedor de pago está en gestionar la 2FA de una cuenta de Stripe compartida.

Un procedimiento de emergencia que merece escribirse

Para la raíz, y para todo lo que solo sirve en caso de urgencia:

1. Quién puede usarlo, con nombres, y qué lo desencadena.
2. Dónde viven el identificador y su segundo factor, y cuántas personas pueden alcanzar cada uno.
3. Dónde están los códigos de recuperación, fuera de la cuenta que recuperan.
4. Qué dispara una alerta al usarlo, es decir, la alarma de CloudTrail de arriba.
5. Qué pasa después: a quién se avisa, qué se revisa, qué se renueva eventualmente.
6. Cuándo se probó por última vez. Un procedimiento nunca ensayado se descubrirá la noche en que alguien lo necesite.

Cuando alguien se va de una cuenta de AWS

1. Retira sus asignaciones de Identity Center o elimina su usuario IAM.
2. Desactiva y elimina sus claves de acceso, incluidas las que usaban sus herramientas.
3. Da de baja su dispositivo MFA raíz, si tenía uno.
4. Si alguna vez guardó un secreto TOTP compartido, restablece esa 2FA y cambia la contraseña asociada. El secreto no sale de su teléfono por sí solo.
5. Comprueba si aún puede leer la dirección de correo raíz.
6. Relee CloudTrail alrededor de su salida, en busca de lo inesperado.

El paso 5 es el que se olvida. Acceder al buzón raíz es acceder a la cuenta raíz, por mucho que hayas revocado por otro lado.

Dónde se sitúa Share Auth

De forma estrecha, y deliberadamente. Para las cuentas de la sección anterior, es decir, la consola de un cliente, un panel de terceros que solo acepta una inscripción, o un identificador de emergencia: el secreto se introduce una vez y se cifra en reposo, las personas que necesitan los códigos ven el código y su cuenta atrás en vez del secreto, los permisos son por miembro, y cada consulta queda registrada.

Para un usuario raíz de AWS que administras tú, registrar un segundo dispositivo MFA vale más que todo lo que una caja fuerte pueda hacer, la nuestra incluida. Haz eso primero.