Identidad cloud: roles de IAM y cuentas de servicio

En los entornos de nube, la identidad es el nuevo perímetro. Cada acción —iniciar una VM, leer una base de datos o llamar a una API— se autoriza según la identidad que la solicita. Los sistemas de IAM (Identity and Access Management) de la nube definen quién puede hacer qué en qué recursos. A diferencia de los entornos locales, donde la ubicación de red proporcionaba confianza implícita, el IAM de la nube trata cada solicitud como una petición que requiere autorización explícita, independientemente de su origen.

AWS IAM tiene tres tipos principales de identidad. Los IAM Users representan a personas o aplicaciones individuales con credenciales de larga duración (clave de acceso + clave secreta). Los IAM Groups agrupan usuarios y asignan permisos compartidos. Los IAM Roles son identidades con credenciales temporales que pueden asumir usuarios, servicios de AWS (EC2, Lambda) u otras cuentas. Se prefieren los roles a las claves de acceso de larga duración porque sus credenciales caducan automáticamente, lo que reduce el riesgo de exposición de credenciales.

Las políticas de IAM definen qué acciones puede realizar una identidad y sobre qué recursos. El principio de privilegio mínimo exige que las políticas concedan únicamente las acciones específicas necesarias para la tarea. Entre las infracciones habituales se incluyen: utilizar comodines * para las acciones (concede todas las acciones de un servicio), utilizar * para los recursos (concede acceso a todos los recursos) y asociar políticas administradas demasiado amplias, como AdministratorAccess, a cuentas de servicio. Todo comodín debe estar justificado y revisarse periódicamente.

En Google Cloud Platform (GCP), las cargas de trabajo no humanas se autentican mediante cuentas de servicio: entidades de identidad administradas con archivos de claves JSON o Workload Identity Federation. Cada cuenta de servicio debe seguir el principio de mínimo privilegio: asígnele únicamente acceso a los servicios de GCP que necesite utilizar. Las claves de las cuentas de servicio (archivos JSON descargados desde la consola) son credenciales de larga duración que deben tratarse como contraseñas: rótelas periódicamente y nunca las incluya en el código fuente ni las cargue en repositorios públicos.

Las identidades administradas de Azure (anteriormente MSI) son el equivalente en Azure de los roles de AWS IAM para servicios: permiten que los recursos de Azure (VM, App Services y Functions) se autentiquen en las API de Azure sin almacenar credenciales. Hay dos tipos: las identidades administradas asignadas por el sistema están vinculadas a un recurso específico y se eliminan cuando se elimina dicho recurso. Las identidades administradas asignadas por el usuario son objetos independientes que se pueden compartir entre varios recursos. Las identidades administradas eliminan la necesidad de almacenar claves o secretos.

Las credenciales de larga duración —claves de acceso estáticas, tokens de API y archivos de claves de cuentas de servicio que nunca caducan— son uno de los elementos de mayor riesgo en los entornos de nube. Si se filtran (a través de GitHub, un bucket de S3, los registros o el portátil de un desarrollador comprometido), conceden acceso inmediato hasta que se revoquen manualmente. Las organizaciones deben auditar todas las credenciales de larga duración, rotarlas según un calendario, priorizar el acceso basado en roles o federado que genere tokens de corta duración y generar una alerta inmediata cuando aparezcan credenciales en repositorios públicos.

La escalada de privilegios de IAM ocurre cuando una identidad utiliza una combinación de permisos para concederse permisos adicionales. Entre las rutas clásicas de escalada se incluyen: asociar una política más permisiva al propio usuario, crear un usuario nuevo de IAM con permisos elevados, pasar un rol (iam:PassRole) a un servicio y actualizar el rol de ejecución de una función de Lambda. AWS's IAM Access Analyzer puede detectar estos patrones, y los límites de permisos de IAM pueden restringir estrictamente los permisos máximos que se pueden conceder a cualquier identidad.

Las organizaciones de nube suelen utilizar varias cuentas (desarrollo, preparación, producción y seguridad) como límites del radio de impacto. La asunción de roles entre cuentas permite que las identidades de una cuenta asuman roles en otra, lo que permite que las herramientas centralizadas operen en varias cuentas. Entre los controles de seguridad se incluyen: exigir un External ID en la política de confianza para evitar ataques de deputy confundido, restringir qué cuentas pueden asumir un rol mediante el ARN de Principal y registrar todas las asunciones entre cuentas en CloudTrail con fines de auditoría.

Las instancias EC2 de AWS pueden recuperar las credenciales de su rol de IAM desde el Instance Metadata Service (IMDS) en http://169.254.169.254. La clase de vulnerabilidades SSRF es especialmente peligrosa en este caso: si una aplicación es vulnerable a SSRF, un atacante puede extraer las credenciales del rol IAM de la instancia haciendo que el servidor solicite contenido a la URL de IMDS. IMDSv2 (que requiere un token de sesión) mitiga el robo de credenciales basado en SSRF y debe aplicarse en todas las instancias EC2.

IAM Access Analyzer (AWS) identifica automáticamente los recursos compartidos con entidades principales externas y las políticas de IAM que conceden más permisos de los previstos. Analiza las políticas de buckets, las políticas de confianza de roles y las políticas de claves de KMS para señalar accesos externos que no se hayan previsto explícitamente. Las revisiones periódicas de las políticas de IAM, de forma manual o con herramientas como Cloudsplaining, PMapper o Permissions Boundary Analyzer, son esenciales para identificar las rutas de escalada de privilegios antes de que las encuentren los atacantes.

Workload Identity Federation permite que las cargas de trabajo externas (GitHub Actions, sistemas locales y otros proveedores de nube) se autentiquen en IAM de la nube mediante tokens OIDC de corta duración, en lugar de claves de cuentas de servicio de larga duración. Un flujo de trabajo de GitHub Actions puede asumir un rol de AWS IAM utilizando su token OIDC durante la ejecución del trabajo; después, el token caduca. Este enfoque elimina por completo la posibilidad de filtración de credenciales de larga duración en las canalizaciones de CI/CD.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) de esta lección.

En esta lección ha aprendido que: los roles de IAM proporcionan credenciales temporales y son preferibles a las claves de acceso de larga duración para las cargas de trabajo en la nube, las políticas de mínimo privilegio deben evitar los comodines y conceder únicamente acciones específicas sobre recursos específicos y IMDSv2, los límites de permisos y la federación de identidades de cargas de trabajo eliminan rutas habituales de exposición de credenciales. A continuación, exploraremos Cloud Security Posture Management (CSPM).