Las contraseñas, por sí solas, no bastan para proteger algo tan valioso como tu cuenta de AWS. En este subcapítulo veremos dos mecanismos que elevan enormemente la seguridad: la autenticación multifactor (MFA) y las credenciales temporales (STS). Son la diferencia entre una cuenta vulnerable y una bien protegida.

MFA significa Multi-Factor Authentication (Autenticación Multifactor). La idea: para entrar, no basta con saber algo (la contraseña); también hay que tener algo (un código que cambia cada pocos segundos en tu móvil).

Los «factores» de autenticación son de tres tipos:

• Algo que sabes: una contraseña.
• Algo que tienes: tu móvil con una app de códigos, o una llave física.
• Algo que eres: tu huella, tu cara (biometría).

MFA combina al menos dos de estos factores. Lo más común es contraseña (sabes) + código del móvil (tienes).

Analogía: Es como un cajero automático. Para sacar dinero necesitas la tarjeta (algo que tienes) y el PIN (algo que sabes). Con solo una de las dos cosas, no puedes. Si alguien te roba la tarjeta pero no sabe el PIN, no puede sacar dinero.

La gran ventaja: aunque un atacante robe tu contraseña, no puede entrar sin el segundo factor, que está físicamente en tu móvil.

Ejemplo real: Un atacante consigue tu contraseña de AWS mediante un correo de phishing. Intenta entrar… pero AWS le pide el código MFA, que solo aparece en tu móvil. El atacante se queda fuera. La contraseña robada, por sí sola, no le sirve de nada.

Según estudios de seguridad, activar MFA bloquea la gran mayoría de los ataques automatizados de robo de cuentas. Es una de las medidas de seguridad más efectivas y baratas que existen.

• Puedes usar una app de autenticación (Google Authenticator, Authy, Microsoft Authenticator…) que genera códigos de 6 dígitos que cambian cada 30 segundos.
• O una llave física de seguridad (como una YubiKey) para máxima protección.

Regla de oro absoluta: Activa MFA en el usuario root SIEMPRE, sin excepción. El root tiene poder total sobre tu cuenta; protegerlo con MFA es lo primero que debes hacer al crear una cuenta. Y actívalo también en todos los usuarios con permisos importantes. Lo repasaremos en el subcapítulo 7.5.

Antes de hablar de STS, entendamos el problema que resuelve.

Un usuario IAM puede tener claves de acceso permanentes (access keys) para programar contra AWS. El problema: esas claves no caducan. Si se filtran (subidas a GitHub por error, robadas de un portátil…), un atacante puede usarlas indefinidamente hasta que alguien se dé cuenta y las desactive.

Las credenciales permanentes son como una llave que nunca caduca: cómoda, pero peligrosa si se pierde.

STS significa Security Token Service. Su función: generar credenciales temporales que caducan automáticamente tras un tiempo (desde unos minutos hasta unas horas).

Analogía: Las credenciales de STS son como la tarjeta de un hotel. Te dan acceso a tu habitación, pero deja de funcionar el día que te vas. No tienes que devolverla ni preocuparte: caduca sola. Si la pierdes, el daño es limitado porque pronto dejará de servir.

El hecho de que caduquen solas reduce drásticamente el riesgo: una credencial robada que deja de funcionar en una hora es mucho menos peligrosa que una que dura para siempre.

¿Recuerdas los roles del subcapítulo 7.1? Aquí está la magia: cuando alguien (o algo) "asume un rol", STS le entrega credenciales temporales con los permisos de ese rol.

Esto es exactamente lo que ocurre cuando:

• Una instancia EC2 asume un rol para leer S3 (STS le da credenciales temporales por detrás).
• Una función Lambda accede a una base de datos (mismo mecanismo).
• Un usuario de otra cuenta asume un rol para acceder a tus recursos (cross-account).

Por qué esto es enorme para la seguridad: Con roles + STS, no hay claves permanentes guardadas en ningún sitio. La instancia EC2 no tiene un fichero con claves que alguien pueda robar; obtiene credenciales temporales que se renuevan y caducan automáticamente. Por eso la buena práctica del subcapítulo 7.1 («usa roles, no claves en el servidor») es tan importante.

La forma profesional y segura de trabajar:

1. Personas: entran con usuario + contraseña + MFA. Para tareas avanzadas, asumen roles (credenciales temporales).
2. Servicios y aplicaciones (EC2, Lambda…): usan roles, nunca claves permanentes incrustadas.
3. Claves de acceso permanentes: se evitan en lo posible. Si se usan, se rotan con frecuencia.

Herramientas modernas como AWS IAM Identity Center (antes AWS SSO) facilitan dar a las personas acceso con credenciales temporales y MFA de forma centralizada, sin claves permanentes.

• MFA añade un segundo factor (un código en tu móvil) además de la contraseña: aunque roben tu contraseña, no entran. Actívalo siempre en el root y en usuarios importantes.
• Las credenciales permanentes (access keys) son peligrosas porque no caducan: si se filtran, sirven indefinidamente.
• STS genera credenciales temporales que caducan solas, reduciendo mucho el riesgo (como la tarjeta de un hotel).
• Al asumir un rol, STS entrega esas credenciales temporales. Por eso roles + STS permiten que servicios como EC2 o Lambda accedan a recursos sin guardar claves permanentes.
• Buena práctica: personas con MFA, servicios con roles, evita claves permanentes.

En el último subcapítulo de IAM reuniremos todo en una lista de buenas prácticas de seguridad que deberías aplicar siempre.