Identidad humana y análisis de accesos
Acceso humano federado y temporal con IAM Identity Center, y cómo IAM Access Analyzer encuentra accesos externos, accesos no usados y genera políticas mínimas.
Las dos notas anteriores van de permisos: cómo se evalúan y cómo se acotan. Esta va de personas: cómo entran los humanos a tus cuentas y cómo compruebas, de forma continua, que nadie tiene más acceso del que debería. Son las dos caras de operar IAM a escala: dar acceso humano bien desde el principio, y auditar lo que ya existe sin tener que leer cada política a mano.
Por qué el acceso humano debe ser federado y temporal#
El patrón que quieres evitar es el usuario IAM con access keys de larga duración: una pareja de claves que no caduca, que acaba en un ~/.aws/credentials, en un gestor de contraseñas o pegada en un script, y que nadie rota. Es credencial robable, difícil de atribuir a una persona concreta y la causa de incidentes una y otra vez.
El patrón que quieres es el contrario, y encaja con zero trustZero trustModelo de seguridad sin confianza implícita por ubicación de red; cada petición se autentica y autoriza con señales de identidad, dispositivo y contexto.:
- Federado: las personas se autentican contra tu proveedor de identidad (IdP) corporativo —Entra ID, Okta, Google Workspace— donde ya viven el MFA, el offboarding y las políticas de acceso condicional.
- Temporal: en lugar de claves permanentes reciben credenciales de sesión de STS que caducan en minutos u horas. Una credencial filtrada deja de servir muy pronto.
- Cero usuarios IAM con llaves: las personas no tienen usuario IAM propio; los usuarios IAM quedan, como mucho, para casos muy concretos y vigilados.
IAM Identity Center#
IAM Identity CenterIAM Identity CenterServicio de AWS para acceso humano federado y temporal a varias cuentas mediante permission sets, sin usuarios IAM con llaves de larga duración. (antes AWS SSO) es la pieza que materializa ese patrón para toda la organización. Conecta tu IdP una vez y da a las personas un portal desde el que entran a las cuentas a las que tienen acceso, siempre con credenciales temporales.
El modelo de permisos gira en torno a los permission sets: plantillas de permisos (políticas gestionadas de AWS, políticas inline y una permission boundary opcional) que asignas combinando quién (un grupo del IdP) con dónde (una cuenta). Identity Center los materializa como roles asumibles vía STS en cada cuenta.
-
Conecta el IdP a Identity Center (SAML/SCIM): los usuarios y grupos se sincronizan solos.
-
Define permission sets por función:
ReadOnly,Operador,AdminRomperCristal… cada uno con sus políticas. -
Asigna grupo × cuenta × permission set. Por ejemplo, el grupo
soporte-citasobtieneReadOnlyen la cuenta de producción. -
La persona entra por el portal, elige cuenta y rol, y recibe credenciales temporales. Nada de access keys.
IAM Access Analyzer#
Dar bien los accesos no basta: con el tiempo se acumulan permisos, aparecen recursos compartidos sin querer y quedan roles que nadie usa. IAM Access AnalyzerIAM Access AnalyzerServicio de AWS que detecta accesos externos y no usados, valida políticas y genera políticas de permisos mínimos a partir de la actividad de CloudTrail. es el servicio que audita todo eso de forma continua, razonando sobre tus políticas en lugar de obligarte a leerlas.
Paso 1 de 5Dos fuentes
Access Analyzer es un detector central que lee las políticas basadas en recurso de tu organización y la actividad registrada en CloudTrail. Con eso razona sobre quién puede acceder a qué.
Hace cuatro cosas que conviene distinguir:
Acceso externo#
Analiza las políticas basadas en recurso (buckets, roles, claves KMS, colas, funciones…) y genera un hallazgo por cada recurso accesible desde fuera de tu zona de confianza: otra cuenta, una organización ajena o internet. Es la forma de descubrir el bucket que alguien abrió «un momento» y se quedó así.
Accesos no usados#
Marca roles, permisos y credenciales sin actividad reciente: el rol que nadie asume desde hace meses, la access key que no se usa, los permisos concedidos y nunca ejercidos. Todo eso solo amplía el radio de impactoRadio de impactoAlcance máximo del daño si un componente, credencial o identidad concreta se ve comprometida. sin aportar nada, y son candidatos directos a eliminar.
Validación de políticas#
Antes de desplegar una política, la valida contra más de cien comprobaciones de seguridad y buenas prácticas, señalando errores de sintaxis, permisos demasiado amplios o condiciones mal escritas. Encaja de maravilla en un pipeline:
# Valida una política en CI antes de aplicarlaaws accessanalyzer validate-policy \ --policy-type IDENTITY_POLICY \ --policy-document file://citas-api-task.jsonGeneración de políticas desde CloudTrail#
La joya para el mínimo privilegioMínimo privilegioCada identidad (persona, servicio o máquina) tiene solo los permisos imprescindibles para su tarea, durante el tiempo imprescindible.: a partir de la actividad real que CloudTrail registró para una identidad durante un periodo, Access Analyzer genera una política con exactamente los servicios y acciones que de verdad usó. En vez de adivinar la lista de permisos, partes de los datos.
Tu turno
Pon a prueba tu acceso humano y tus accesos sobrantes
En tu cuenta o tu lab:
- ¿Cómo entran hoy las personas? Si hay usuarios IAM con access keys, cuéntalos y plantea cómo migrarlos a Identity Center o a federación.
- Activa (o revisa) Access Analyzer con un analizador de acceso externo y otro de acceso no usado. ¿Cuántos hallazgos salen? Elige los tres más graves.
- Toma un rol con permisos amplios y genera una política a partir de su actividad de CloudTrail. Compara lo que usa con lo que tiene.
- Define un permission set y una regla just-in-time para el acceso de administrador, en lugar de dejarlo asignado siempre.
Reto
¿Por qué un rol temporal de Identity Center es más seguro que un usuario IAM con la misma política?
▸Mostrar solución
Porque cambia la credencial, no los permisos. El usuario IAM lleva access keys de larga duración: robadas, sirven indefinidamente y cuesta atribuirlas a una persona. El rol de Identity Center entrega credenciales de STS que caducan y están ligadas a una autenticación federada con MFA y offboarding en tu IdP. Mismo permiso, muchísimo menos tiempo de exposición y mejor trazabilidad.
Reto
Access Analyzer dice que un rol no se ha usado en 120 días. ¿Lo borro sin más?
▸Mostrar solución
Antes de borrar, comprueba que no sea un rol de uso estacional (cierres de trimestre, DR, un job anual) ni un rol asumido por un servicio con baja frecuencia. Revisa su actividad en CloudTrail y, si de verdad no aporta, elimínalo o retírale permisos. El hallazgo es una señal muy fiable, pero el contexto lo pones tú.
En resumen#
- El acceso humano debe ser federado (vía tu IdP) y temporal (credenciales STS que caducan), nunca usuarios IAM con access keys de larga duración.
- IAM Identity Center lo materializa con permission sets (quién × dónde × permisos) y se apoya en flujos just-in-time para el acceso elevado.
- IAM Access Analyzer audita de forma continua: acceso externo, accesos no usados, validación de políticas y generación de políticas mínimas desde CloudTrail.
- Juntos cierran el ciclo: dar acceso bien desde el principio y recortar sin descanso lo que sobra.