Uno de los errores mas comunes en AWS es "Access Denied". IAM (Identity and Access Management) es el servicio de seguridad central de AWS que decide "quien puede hacer que en que recursos". Esta guia explica IAM desde los conceptos basicos hasta los avanzados de una manera amigable para principiantes.
Componentes basicos de IAM
Imagina el sistema de control de acceso de una empresa. Los empleados tienen sus propias tarjetas de identificacion (usuarios). Diferentes departamentos pueden acceder a diferentes areas. IAM sigue la misma estructura.
Un Usuario es una persona individual o aplicacion que accede a AWS. Cada usuario tiene credenciales unicas: una contrasena para acceso a la consola o una clave de acceso para acceso programatico.
Un Grupo es una coleccion de usuarios que comparten los mismos permisos. Crea un grupo "equipo de desarrollo" y todos los desarrolladores en el obtienen automaticamente los mismos permisos. Cuando llega un nuevo desarrollador, simplemente lo agregas al grupo. Importante: los grupos no pueden contener otros grupos.
Un Role (rol) otorga permisos temporales a servicios AWS o usuarios externos, no credenciales a largo plazo. Cuando una instancia EC2 necesita acceder a un bucket S3, adjuntas un rol a la instancia en lugar de incrustar claves de acceso. El rol emite credenciales temporales que expiran automaticamente.
Una Politica es un documento JSON que dice "permitir o denegar estas acciones especificas en estos recursos especificos para este servicio especifico".
Tipos de politicas
IAM tiene varios tipos de politicas, cada una con un proposito diferente.
Las Politicas basadas en identidad se adjuntan a usuarios, grupos o roles. Definen lo que la identidad puede hacer. Existen en dos formas: AWS Managed Policies (creadas y mantenidas por AWS) y Customer Managed Policies (creadas por ti).
Las Politicas basadas en recursos se adjuntan directamente a recursos como buckets S3, colas SQS y claves KMS. Definen quien puede acceder al recurso. A diferencia de las politicas basadas en identidad, requieren un Principal (quien recibe el acceso). Esto es especialmente util para otorgar acceso a usuarios de otras cuentas.
Los Permission Boundaries establecen los permisos maximos que un usuario o rol puede tener. Piensalo como una valla que dice "solo puedes otorgar permisos dentro de este limite". Por ejemplo, le das al lider de equipo permiso para crear usuarios IAM, pero agregas un Permission Boundary para que no pueda crear usuarios con mas permisos de los que el tiene.
Los SCPs son las restricciones a nivel organizacion cubiertas en el articulo anterior.
| Tipo de politica | Se aplica a | Caracteristica clave | |-----------------|------------|---------------------| | Identity-based | Usuarios, grupos, roles | Define que puede hacer la identidad | | Resource-based | S3, SQS, KMS etc. | Requiere Principal, habilita cuentas cruzadas | | Permission Boundary | Usuarios, roles | Techo de permisos maximos | | SCP | OUs, cuentas | Restriccion a nivel organizacion, no aplica a cuenta de administracion |
Logica de evaluacion de politicas — Como AWS decide permitir o denegar
Esta es la parte mas dificil e importante de IAM. Cuando llega una solicitud, AWS examina multiples politicas para determinar si permitirla.
La regla central tiene tres pasos. Primero, si hay un Deny explicito en cualquier lugar, la solicitud se deniega incondicionalmente. Ninguna otra politica Allow puede anular un Deny. Segundo, si hay un Allow explicito y no hay Deny, la solicitud se permite. Tercero, si no hay ninguno, el resultado es un Deny implicito. En AWS, todo se deniega de forma predeterminada a menos que se permita explicitamente.
Regla de la misma cuenta: si la politica basada en identidad o la politica basada en recursos permite la accion, el acceso esta permitido (union).
Regla de cuentas cruzadas: tanto la politica basada en identidad en la cuenta solicitante como la politica basada en recursos en el recurso objetivo deben permitir la accion. Un solo Allow en solo uno de ellos no es suficiente (interseccion).
Un escenario real: el desarrollador A tiene una politica Allow para leer un bucket S3, pero el acceso se deniega. Las posibles causas incluyen: un SCP que bloquea el servicio S3 para esa cuenta, un Permission Boundary en el usuario que excluye S3, un Deny explicito en la politica basada en recursos del bucket S3, o una politica de endpoint VPC que bloquea la solicitud.
Punto de examen: "Existe una politica Allow pero el acceso sigue siendo denegado" — la respuesta es verificar si hay un Deny explicito en algun lugar (SCP, Permission Boundary, politica basada en recursos).
MFA — Proteger cuentas con autenticacion de dos factores
Proteger una cuenta solo con contrasena no es suficiente. Si la contrasena es robada, la cuenta queda comprometida inmediatamente. MFA (Multi-Factor Authentication) requiere una segunda forma de verificacion ademas de la contrasena, como un cajero automatico que requiere tanto tu tarjeta como tu PIN.
Hay tres tipos de MFA. Los dispositivos MFA virtuales son aplicaciones de smartphone como Google Authenticator o Authy que generan un codigo de seis digitos que cambia cada treinta segundos. Los dispositivos MFA de hardware son tokens fisicos como YubiKey. Las claves de seguridad U2F son claves de seguridad estandar FIDO basadas en USB.
Puedes forzar MFA a traves de condiciones de politicas IAM. Usando la clave de condicion aws:MultiFactorAuthPresent, puedes crear una politica que deniegue acciones especificas a menos que se haya usado MFA para autenticarse. Por ejemplo: "denegar la terminacion de instancias EC2 a menos que el usuario se haya autenticado con MFA".
La cuenta root debe tener MFA habilitado sin excepcion. La cuenta root tiene poder ilimitado sobre toda la cuenta AWS y debe protegerse al nivel mas alto.
Punto de examen: "Bloquear llamadas API de usuarios que no se han autenticado con MFA" — la respuesta es agregar la condicion aws:MultiFactorAuthPresent a la politica IAM.
Federacion — Iniciar sesion en AWS con cuentas externas
Los empleados de tu empresa ya tienen cuentas de Active Directory. Quieres que accedan a AWS usando esas mismas cuentas corporativas sin crear cuentas IAM de AWS separadas para cada persona. Eso es la federacion.
La Federacion SAML 2.0 es la mas comun en entornos empresariales. Conecta el Active Directory o ADFS (Active Directory Federation Services) de tu empresa con AWS. Los empleados inician sesion en el portal SSO de la empresa, y a traves de STS AssumeRoleWithSAML reciben credenciales temporales de AWS y acceden a la consola.
La Federacion OIDC se usa en aplicaciones moviles o web. Los usuarios inician sesion con cuentas de Google, Facebook o Apple y acceden a recursos AWS a traves de esa identidad. Amazon Cognito simplifica esta integracion.
AWS IAM Identity Center (antes AWS SSO) proporciona SSO centralizado en multiples cuentas AWS. Un solo inicio de sesion da acceso a la consola de cualquier cuenta para la que tengas permisos. Se integra con Organizations y gestiona los permisos por cuenta a traves de Permission Sets. Este es el enfoque recomendado para entornos multi-cuenta.
Punto de examen: "Usuarios del Active Directory corporativo necesitan acceder a la consola de AWS" — la respuesta es federacion SAML 2.0 o IAM Identity Center.
IAM Access Analyzer — Encontrar recursos expuestos externamente
Un dia descubres que un bucket S3 es accesible publicamente para cualquiera en el mundo. Necesitas saber cuando ocurrio eso y si otros recursos tambien estan expuestos. IAM Access Analyzer encuentra estas situaciones automaticamente.
IAM Access Analyzer identifica automaticamente los recursos que son accesibles desde fuera de tu cuenta, ya sea desde otras cuentas AWS o desde internet publico. Es como una inspeccion de seguridad que encuentra puertas sin llave.
Los recursos analizados incluyen: politicas de bucket S3, Trust Policies de roles IAM, politicas de claves KMS, politicas de colas SQS, politicas de funciones Lambda y politicas de secretos de Secrets Manager.
Cuando se encuentran recursos accesibles externamente, Access Analyzer crea un "Finding". Revisas cada Finding: si el acceso externo es intencional, marcalo como "Archive". Si es exposicion no intencionada, corrige la politica para eliminar el acceso.
Access Analyzer tiene dos capacidades adicionales importantes. La funcion de generacion de politicas analiza tus registros de CloudTrail y genera automaticamente una politica de minimo privilegio basada en las acciones que realmente se usaron. La funcion de validacion de politicas verifica la sintaxis de politicas IAM y senala violaciones de mejores practicas.
Punto de examen: "Detectar automaticamente si un bucket S3 es accesible publicamente" — la respuesta es IAM Access Analyzer.
Roles vinculados a servicios
Estos son roles IAM especiales que los servicios AWS crean automaticamente para gestionar otros recursos AWS en tu nombre. Auto Scaling necesita permisos para crear y terminar instancias EC2: un rol vinculado al servicio proporciona esos permisos automaticamente.
Los usuarios no pueden modificar ni eliminar facilmente los roles vinculados a servicios, y solo el servicio especifico que los creo puede usarlos. Auto Scaling, ElastiCache, RDS, CloudFormation y muchos otros servicios dependen de roles vinculados a servicios.
Gestion de claves de acceso
Cuando un programa llama a APIs de AWS directamente, a traves de AWS CLI, un SDK o codigo del lado del servidor, usa claves de acceso (Access Key ID mas Secret Access Key) en lugar de una contrasena.
Mejores practicas para la gestion de claves de acceso: cada usuario puede tener un maximo de dos claves de acceso activas (util durante la rotacion de claves para permitir la superposicion). Rotar las claves regularmente. Nunca crear claves de acceso para la cuenta root, o eliminarlas inmediat