Control de acceso granular de AWS IAM - El principio de mínimo privilegio logrado por el diseño basado en políticas
Explicamos la filosofía de diseño del control de acceso basado en políticas de AWS IAM y comparamos concretamente las diferencias de granularidad con Azure RBAC y GCP IAM.
La filosofía fundamental del diseño basado en políticas
La mayor característica de AWS IAM es el diseño donde el control de acceso se describe como documentos de política en JSON. Las políticas se componen de 4 elementos: Effect (Allow/Deny), Action (operación), Resource (recurso objetivo) y Condition (condición), y la combinación de estos permite un control de granularidad extremadamente fina. Por ejemplo, se puede expresar en un solo statement de política: permitir GetObject solo desde una dirección IP específica para objetos con un prefijo específico dentro de un bucket S3 específico. Esta filosofía de diseño ha sido consistente desde los primeros días de AWS, y a medida que los servicios han superado los 200, la expresividad de las políticas se ha expandido proporcionalmente.
Control dependiente del contexto mediante claves de condición
Lo que eleva decisivamente la granularidad de AWS IAM es el elemento Condition. Combinando claves de condición globales y específicas de servicio, se logra un control de acceso dependiente del contexto que va más allá del simple control a nivel de recurso. Por ejemplo, aws:SourceIp restringe la IP de origen, aws:RequestedRegion limita las regiones operables, y aws:PrincipalTag aplica control de acceso basado en etiquetas (ABAC). ABAC es particularmente poderoso en organizaciones grandes. Si se crea una política que solo permite acceso a recursos cuya etiqueta de proyecto coincide, cuando se añade un nuevo proyecto solo es necesario etiquetar los recursos sin modificar las políticas.
Diferencias de granularidad con Azure RBAC
El control de acceso de Azure se basa en RBAC (Role-Based Access Control). En Azure RBAC, las definiciones de rol se asignan a un ámbito (grupo de gestión, suscripción, grupo de recursos, recurso), y los roles definen listas de acciones con Actions y NotActions. La mayor diferencia con AWS IAM es la flexibilidad del control basado en condiciones. Azure también lanzó la asignación de roles condicional (ABAC) como GA en 2022, pero los tipos de recursos soportados están limitados a algunos como Storage Blob y Key Vault. AWS IAM soporta claves de condición para prácticamente todos los servicios, con una diferencia significativa en la amplitud de aplicación de ABAC.
Diferencias en el enfoque de diseño con GCP IAM
GCP IAM adopta control de acceso basado en roles, con 3 tipos: roles predefinidos, roles personalizados y roles básicos. Los roles predefinidos de GCP están preparados de forma granular para cada servicio, pero no alcanzan la flexibilidad de combinar condiciones arbitrarias en documentos de política como AWS. Las expresiones de condición de GCP IAM se escriben en CEL (Common Expression Language), pero los atributos soportados son limitados, y el ABAC basado en etiquetas de recursos se introdujo apenas como preview en 2023. Un mecanismo característico de GCP son las políticas IAM Deny, que permiten prohibir explícitamente operaciones específicas en niveles superiores de la jerarquía organizacional.
Enfoque práctico para lograr el mínimo privilegio
Para llevar el principio de mínimo privilegio de la teoría a la implementación, la clave es aprovechar las herramientas que proporciona AWS. IAM Access Analyzer analiza los logs de CloudTrail y genera automáticamente políticas que contienen solo las acciones realmente utilizadas. El método de comenzar la operación con permisos excesivos y luego reducir a una política basada en el uso real con Access Analyzer después de un período es un camino realista hacia el mínimo privilegio. IAM Policy Simulator permite probar previamente los resultados de evaluación de políticas, verificando que no haya denegaciones de acceso no intencionadas antes de aplicar en producción. Los SCP de Organizations establecen límites de permisos a nivel de cuenta.
Resumen
El diseño basado en políticas de AWS IAM permite un control de acceso de granularidad difícil de lograr en otras plataformas de nube mediante la combinación de Action, Resource y Condition. Azure RBAC tiene fortalezas en la claridad del modelo de asignación de roles, pero el alcance del control basado en condiciones es limitado. GCP IAM tiene un modelo de herencia de jerarquía de recursos simple, pero queda rezagado respecto a AWS en madurez de ABAC. Para lograr el principio de mínimo privilegio en la práctica, se combina la generación automática de políticas con Access Analyzer, la configuración de límites a nivel organizacional con SCP y las restricciones a nivel de rol con Permission Boundaries.