Tema 4
En cloud, la identidad es una de las superficies de ataque más importantes. Una credencial con permisos excesivos puede modificar infraestructura, acceder a datos, desactivar controles y desplegar recursos sin tocar físicamente ningún servidor.
La gestión de identidades y accesos define quién puede hacer qué dentro de una plataforma cloud. No se trata solo de crear usuarios: implica administrar permisos humanos, permisos de aplicaciones, cuentas de servicio, roles temporales, políticas, autenticación fuerte y auditoría.
En entornos cloud, muchas operaciones críticas se realizan mediante APIs. Crear una máquina virtual, leer un secreto, modificar una política de red o borrar un bucket puede depender de una llamada autenticada. Por eso una credencial comprometida puede tener un impacto inmediato y amplio.
El objetivo de IAM es permitir el trabajo necesario sin otorgar más poder del imprescindible. Esta disciplina es la base de una arquitectura segura.
IAM significa Identity and Access Management. Es el conjunto de mecanismos para identificar actores, autenticar su identidad, autorizar acciones y registrar actividad.
En una plataforma cloud, IAM suele administrar:
No todas las identidades son iguales. Una persona necesita autenticarse, recibir permisos según su función y dejar trazabilidad. Una aplicación o pipeline necesita permisos específicos para operar sin intervención humana.
| Tipo de identidad | Ejemplos | Control principal |
|---|---|---|
| Humana | Administradores, desarrolladores, operadores, auditores | SSO, MFA, roles temporales y trazabilidad individual |
| Aplicación | Backend que lee una base, servicio que accede a una cola | Cuentas de servicio con permisos mínimos |
| Pipeline | CI/CD que construye imágenes o despliega infraestructura | Roles por entorno, aprobaciones y credenciales efímeras |
| Workload | Pod de Kubernetes, función serverless, job batch | Identidad asociada al workload, no claves embebidas |
| Tercero | Proveedor, integración SaaS, herramienta de monitoreo | Scopes limitados, expiración, auditoría y revisión contractual |
La autenticación confirma que un actor es quien dice ser. En cloud, las cuentas privilegiadas deben usar MFA de forma obligatoria. Una contraseña sola es insuficiente para proteger acceso administrativo.
Buenas prácticas:
MFA reduce el impacto del robo de contraseñas, pero no corrige permisos excesivos. Debe combinarse con roles bien diseñados.
La autorización define qué acciones puede ejecutar una identidad. En cloud, esa autorización se expresa mediante políticas asociadas a usuarios, grupos, roles o recursos.
Una política suele responder a cuatro elementos:
| Elemento | Ejemplo | Riesgo si es amplio |
|---|---|---|
| Principal | Rol de despliegue de una aplicación | Muchas identidades pueden asumir el mismo poder |
| Acción | Leer objetos de almacenamiento | Permitir escritura o borrado sin necesidad |
| Recurso | Un bucket específico de la aplicación | Acceso a todos los buckets del entorno |
| Condición | Solo desde una red, cuenta o etiqueta determinada | Uso válido desde cualquier contexto |
El mínimo privilegio indica que una identidad debe tener solo los permisos necesarios para cumplir su función, durante el tiempo necesario y en el contexto adecuado.
Aplicarlo exige trabajo concreto:
* en acciones o recursos.Las credenciales permanentes son difíciles de controlar. Pueden quedar en laptops, scripts, repositorios, variables de entorno o herramientas de terceros. Por eso las arquitecturas cloud modernas prefieren roles temporales y tokens de corta duración.
Ventajas de las credenciales efímeras:
Las aplicaciones también necesitan identidad. Un servicio puede requerir leer una cola, escribir logs, consultar un secreto o acceder a una base de datos. Esos permisos deben pertenecer al workload específico, no a una clave genérica compartida.
Buenas prácticas:
Los pipelines suelen necesitar permisos sensibles: construir artefactos, publicar imágenes, modificar infraestructura o desplegar en ambientes. Si esos permisos no se acotan, el pipeline se convierte en una ruta privilegiada hacia producción.
Controles recomendados:
Las condiciones agregan contexto a una decisión de acceso. Permiten que una acción no dependa solo de identidad y recurso, sino también de señales como origen, hora, etiqueta, autenticación fuerte o entorno.
| Condición | Uso típico | Beneficio |
|---|---|---|
| MFA presente | Permitir acciones administrativas solo con segundo factor | Reduce abuso de contraseñas robadas |
| Red de origen | Restringir administración a VPN o red corporativa | Limita accesos desde ubicaciones no esperadas |
| Etiqueta del recurso | Permitir gestión solo de recursos del equipo correspondiente | Reduce permisos cruzados entre aplicaciones |
| Ambiente | Separar permisos de desarrollo y producción | Evita cambios accidentales en sistemas críticos |
| Tiempo de sesión | Limitar duración de permisos elevados | Reduce ventana de exposición |
IAM no termina cuando se asigna un rol. Los permisos cambian con el tiempo, los equipos evolucionan y las excepciones temporales tienden a volverse permanentes. Por eso la revisión continua es obligatoria.
Una revisión de accesos debe responder:
Una gestión de identidades sólida reduce el impacto de errores y credenciales comprometidas. Los roles, políticas, condiciones, MFA y revisiones periódicas permiten operar cloud con control, trazabilidad y menor superficie de ataque.
En el próximo tema estudiaremos la seguridad de redes cloud: VPC, subredes, security groups, firewalls y conectividad privada.