Automatización y Gobernanza a escala de Permissions Boundaries para entidades de IAM

Por Rayco Martínez, Responsable de Cloud en Moeve y Pablo Monteagudo, Arquitecto Senior de Soluciones en AWS.

Moeve, anteriormente conocida como Cepsa, es una compañía energética global con más de 90 años de experiencia y más de 11.000 empleados. Moeve está comprometida con liderar la transición energética en Europa y acelerar los esfuerzos de descarbonización. La empresa ha adoptado la transformación digital para mejorar la eficiencia energética, la seguridad y la sostenibilidad, enfocándose en inversiones en hidrógeno verde, biocombustibles de segunda generación e infraestructura de carga ultrarrápida para vehículos eléctricos.

La nube AWS es un pilar fundamental de la transformación digital señalada. Recientemente, Moeve ha diseñado una solución para adoptar el uso de Permissions Boundaries para entidades de IAM (PBs) en todas las cuentas AWS de sus organizaciones. Con ello, Moeve ha logrado que su entorno cumpla con políticas de autorización que otorgan los mínimos privilegios de acceso necesarios para ejecutar las funciones asignadas a sus usuarios. En este blog explicamos dicha solución.

Equilibrio en agilidad y control para la gestión de Identidades

Moeve ha optado por una estrategia distribuida para la administración de AWS Identity and Access Management (IAM) para sus entornos AWS con múltiples cuentas. Sus equipos de desarrollo necesitan permisos para gestionar sus propios recursos IAM, debido a las exigencias de entregas rápidas. La delegación de dicha gestión desde el equipo central del Cloud Center of Excellence (CCoE) hacia los desarrolladores debe mantener los estándares de seguridad y cumplimiento normativo de la compañía. El CCoE ha establecido para ello límites claros en dicha delegación, a saber:

• Usuarios programáticos de IAM (con claves de acceso).

Debido a su criticidad y riesgo, su creación está estrictamente controlada por el equipo de seguridad.

• Permission sets de AWS IAM Identity Center (antes AWS SSO).

Estos gobiernan el acceso a nivel empresarial y deben permanecer bajo custodia de equipos centrales como el CCoE o Seguridad Corporativa.

• Creación y actualización de roles dentro de cuentas individuales.

Estas tareas sí son susceptibles de delegación. Los desarrolladores necesitan autonomía para crear y modificar roles IAM adaptados a las necesidades de sus aplicaciones, sin depender de los equipos centrales para cada solicitud. Esta autonomía proporciona agilidad y previene bloqueos o atascos en los procesos.

Gestión Segura de Roles de IAM mediante Permissions Boundaries

Los Permission Boundaries de IAM son la solución que Moeve ha implementado para abordar el principal desafío de seguridad por delegar la gestión de permisos IAM a los equipos de desarrollo dentro de sus cuentas individuales. Los Permissions Boundaries actúan como límites máximos de permisos, de forma que ningún rol pueda exceder los privilegios establecidos por el equipo de Ciberseguridad, incluso si un desarrollador intentara asignar políticas más permisivas. Así, los desarrolladores pueden crear y modificar roles autónomamente, siempre que adjunten el PB corporativo establecido por el CCoE. De esta forma, Moeve se protege de escenarios no deseados como son una escalada de priviligios o una desviación respecto a las políticas corporativas.

Marco normativo de delegación en Moeve

El marco de trabajo se basa en una clara separación de funciones. Ciertos aspectos sensibles permanecen centralizados, mientras que otros se delegan bajo estrictos límites.

1. Identity Center no se delega

AWS IAM Identity Center es la fuente de la verdad para identidades federadas y Permission Sets empresariales. Su administración está reservada exclusivamente para el CCoE y para el equipo de seguridad corporativa. Moeve consigue este objetivo con dos mecanismos:

• Restringiendo el acceso a la cuenta de gestión donde está configurado AWS IAM Identity Center.

• Asegurando que ningún otro administrador en la organización pueda modificar los PBs.

Como resultado, los desarrolladores no pueden alterar asignaciones de acceso globales, protegiendo la integridad del SSO empresarial.

2. Bloqueo de usuarios programáticos de IAM con Service Control Policies

La creación de usuarios IAM con claves de acceso está explícitamente bloqueada a nivel organizacional mediante Service Control Policies (SCPs). Así, Moeve consigue que todas las aplicaciones usen identidades federadas o roles IAM en lugar de credenciales estáticas de larga duración. A continuación, se muestra la SCP que deniega la creación de usuarios.

{
"Sid": "DenyUserandGroupActions",
"Effect": "Deny",
"Action": [
    "iam:CreateUser",
    "iam:DeleteUser",
    "iam:DeleteAccessKey",
    "iam:UpdateAccessKey",
    "iam:CreateAccessKey",
    "iam:CreateGroup",
    "iam:DeleteGroup",
    "iam:UpdateGroup",
    "iam:CreateSAMLProvider",
    "iam:RemoveUserFromGroup",
    "iam:AttachGroupPolicy",
    "iam:DetachGroupPolicy",
    "iam:DeleteGroupPolicy",
    "iam:UpdateSAMLProvider",
    "iam:DeleteSAMLProvider",
    "iam:PutGroupPolicy",

],
"Resource": [
    "*"
],
"Condition": {
    "StringNotLike": {
        "aws:PrincipalArn": [
            "arn:aws:iam::*:role/aws-reserved/*/*/Security_Team_*",
            "arn:aws:iam::*:role/aws-reserved/*/*/CoE_Team_*"
            
        ]
    }
}
}

Como excepción, en aquellos casos en que se necesita usar credenciales programáticas, estas credenciales deben ser autorizadas por el CCoE o equipos de seguridad corporativa, como responsables de crear este usuario y generar las credenciales.

3. Aplicación de PBs con SCPs.

Moeve permite la creación de roles IAM, con la condición de adjuntar un PB autorizado. Este requisito se refuerza mediante SCPs que deniegan la creación o actualización de roles a menos que el PB aprobado esté presente.

La SCP de ejemplo que se muestra a continuación: 1) impide la actualización de políticas a usuarios y roles sin PBs (salvo por parte de Security_Team o CCoE_Team), 2) impide la eliminación de PBs (salvo por parte de Security_Team o CCoE_Team) 3) fuerza el uso de un PB específico (“custom-main-boundary”, salvo por parte de Security_Team o CCoE_Team)

Con ello, Moeve logra que los desarrolladores mantengan autonomía, pero siempre bajo los límites definidos y aprobados por el CCoE.

{
    "Id": "p-q8ch1aas",
    "Name": "Account_IAM_PB",
    "Description": "",
    "Content": {
        "Version": "2012-10-17",
        "Statement": [
            {
               "Sid": "DenyUpdateWithoutPB", 
"Effect": "Deny",
                "Action": [
                    "iam:AttachUserPolicy",
                    "iam:DetachUserPolicy",
                    "iam:PutUserPolicy",
                    "iam:DetachRolePolicy",
                    "iam:AttachRolePolicy",
                    "iam:PutRolePolicy"
                ],
                "Resource": "*",
                "Condition": {
                    "Null": {
                        "iam:PermissionsBoundary": "true"
                    },
                    "StringNotLike": {
                        "aws:PrincipalArn": [
                            "arn:aws:iam::*:role/aws-reserved/*/*/Security_Team_*",
"arn:aws:iam::*:role/aws-reserved/*/*/CCoE_Team_*"
 ]
}
           }
      },

            {
"Sid": "DenyDeleteBoundary",                
"Effect": "Deny",
                "Action": [
                    "iam:DeleteRolePermissionsBoundary",
                    "iam:DeleteUserPermissionsBoundary"
                ],
                "Resource": "*",
                "Condition": {
                    "StringNotLike": {
                        "aws:PrincipalArn": [
                            "arn:aws:iam::*:role/aws-reserved/*/*/Security_Team_*",
"arn:aws:iam::*:role/aws-reserved/*/*/CCoE_Team_*"
                        ]
                    }
                }
            },
            {
"Sid": "UseExplicitBoundary",                
                "Effect": "Deny",
                "Action": [
                    "iam:UpdateUser",
                    "iam:CreateRole",
                    "iam:PutRolePermissionsBoundary",
                    "iam:PutUserPermissionsBoundary"
                ],
                "Resource": "*",
                "Condition": {
                    "StringNotLike": {
                        "aws:PrincipalArn": [
                            "arn:aws:iam::*:role/aws-reserved/*/*/Security_Team_*",
"arn:aws:iam::*:role/aws-reserved/*/*/CCoE_Team_*"
                        ],
                        "iam:PermissionsBoundary": "arn:aws:iam::*:policy/custom-main-boundary"
                    }
                }
            }
        ]
    }
}

Configuración inicial de los Permision Boundaries

En el entorno altamente automatizado que opera Moeve es necesario que la creación y aplicación de los PBs sea también automatizada. Para ello, Moeve ha seguido tres principios de diseño:

• Onboarding automatizado. Cuando se crea una nueva cuenta en AWS Organizations, se despliega automáticamente una PB inicial. Esta puede parametrizarse, por ejemplo, según etiquetas de la cuenta, tipo de carga de trabajo o requisitos de cumplimiento.

• Gobernanza por el CCoE. El CCoE, como responsable de la Organización, aprueba la definición de PBs. Los desarrolladores no pueden crear nuevos PBs, pero pueden usar los ya provisionados.

• Ciclo de vida gestionado por GitOps: Los PBs se almacenan en un bucket S3 sincronizado con un repositorio Git. Los desarrolladores pueden proponer cambios mediante pull requests, que son revisados por el CCoE. Una vez aprobados, los cambios se despliegan automáticamente en las cuentas correspondientes.

Este modelo refuerza el cumplimiento mientras permite un autoservicio controlado para los desarrolladores. Moeve ha conseguido automatizar el despliegue de PBs en las distintas cuentas con la arquitectura de la Figura 1 mostrada a continuación.

 Figura 1. Automatización del despliegue de Permission Boundary

El flujo de automatización consiste en los siguientes pasos:

1. Creación de una nueva cuenta

La nueva cuenta se provisiona con AWS Control Tower Account Factory.

La provisión emite un evento que es detectado con Amazon EventBridge, mediante la siguiente regla:

{
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "serviceEventDetails": {
      "createManagedAccountStatus": {
        "state": ["SUCCEEDED"]
      }
    },
    "eventName": ["CreateManagedAccount"]
  },
  "source": ["aws.controltower"]
}

2. Enriquecimiento con metadatos organizacionales.

A continuación, se invoca una función AWS Lambda, que consulta AWS Organizations para obtener metadatos de la nueva cuenta. Estos metadatos incluyen etiquetas para detectar el propósito de la cuenta, como por ejemplo, datalake, apps, infra y otros. El PB adecuado se determina en base a estos metadatos.

3. Almacenamiento de la definición del boundary.

Según el propósito de la cuenta, la función AWS Lambda genera un PB y lo almacena como archivo YAML en un bucket de Amazon S3, usando el Account ID de la cuenta como identificador. Por ejemplo, una cuenta de infraestructura suele tener límites más estrictos que una cuenta de aplicaciones, lo que limita su capacidad para interactuar con servicios de la capa de aplicación.

4. Despliegue orquestado.

La subida del archivo YAML al bucket S3 genera una notificación de evento de S3, que provoca la invocación de una función AWS Lambda responsable de la orquestación del despliegue.

5. Creación o actualización de StackSet de despliegue

La función AWS Lambda invocada en el paso anterior crea o actualiza un AWS CloudFormation StackSet (StackSet) que contiene el PB, asegurando el despliegue consistente en la nueva cuenta.

6. Despliegue en la cuenta objetivo.

El StackSet aprovisiona automáticamente un stack de AWS CloudFormation dentro de la cuenta hija, creando el PB según la definición YAML. Como resultado, tan pronto como la cuenta está operativa, ya dispone de un boundary personalizado disponible para los desarrolladores.

Todo el proceso anterior tiene lugar antes de entregar la cuenta al usuario. Dicha entrega se produce una vez terminado el paso 6.

Gobernanza como código. Gestión de PBs con Git y automatización

Como se ha visto, el onboarding automatizado permite que cada nueva cuenta reciba un PB desde el momento de creación. Además, se necesita una forma sostenible de gobernar y evolucionar esos PBs en el tiempo, pues los requisitos de negocio cambian, los marcos de cumplimiento evolucionan y aparecen nuevos servicios de AWS.

Para gestionar estos cambios a escala de forma automatizada, Moeve adopta un modelo GitOps, donde los PBs se tratan como código y los cambios se implementan con los mismos mecanismos de revisión y automatización que los despliegues de aplicaciones.

El flujo de cambios en Moeve funciona del siguiente modo:

• Git como fuente de la verdad. Todas las definiciones de boundaries se almacenan en un repositorio GitHub, como archivos YAML organizados por cuenta o tipo de carga de trabajo, como por ejemplo, “boundaries/datalake/account-123456789.yml.”
• Propuestas de cambio vía pull request. Los desarrolladores o equipos de aplicaciones que necesiten ajustar un PB envían un pull request. El CCoE revisa la propuesta para ver que se adecua a los estándares de seguridad.
• Pipeline CI/CD con GitHub Actions. Una vez aprobado y fusionado el cambio, un workflow de GitHub Actions actualiza el archivo YAML correspondiente en el bucket Amazon S3 central.
• Despliegue basado en eventos. La actualización del objeto en el bucket de Amazon S3 dispara una notificación de evento, que lanza una función AWS Lambda. Esta función AWS Lambda se encarga de que el AWS CloudFormation StackSet correspondiente se cree o actualice con la nueva definición de permisos.
• Propagación a cuentas hijas. El StackSet despliega o actualiza el stack de CloudFormation en las cuentas objetivo, aplicando el PB revisado.

Este modelo brinda a Moeve los siguientes beneficios:

• Gobernanza centralizada. El CCoE mantiene la autoridad de aprobación y visibilidad total de los cambios.
• Transparencia y auditabilidad. Cada modificación es versionada, revisada y registrada en Git.
• Consistencia a escala. La automatización permite que los PBs se desplieguen uniformemente en todas las cuentas, sin intervención manual.

En la práctica y gracias al pipeline de automatización, actualizar un PB se reduce a editar un archivo YAML en Git.

Observabilidad. Detección y alertas basadas en eventos para cambios críticos en IAM

Además de los estrictos límites preventivos que hemos visto, Moeve necesita disponer de mecanismos de visibilidad rápida y accionable sobre cambios que puedan debilitar los controles o permitir un mal uso. Moeve utiliza reglas de Amazon EventBridge en cada cuenta para escuchar eventos de gestión de AWS CloudTrail sobre un conjunto especifico de acciones críticas de IAM. En caso de detección, las reglas envían notificaciones consecuentes por email a los equipos de Seguridad y CCoE.

Los eventos que Moeve monitoriza son:

• Claves de acceso programáticas (usuarios IAM): CreateAccessKey, UpdateAccessKey, DeleteAccessKey
• Ciclo de vida de usuarios IAM: CreateUser, DeleteUser
• Cambios en Permissions Boundaries: DeleteUserPermissionsBoundary, DeleteRolePermissionsBoundary

 El flujo de monitorización consiste en los siguientes elementos:

• AWS CloudTrail como fuente de eventos. Cada cuenta tiene eventos de gestión de CloudTrail habilitados por defecto con Control Tower. CloudTrail registra y almacena los eventos de llamadas a la API de IAM.
• Reglas locales de Amazon EventBridge. En cada cuenta hija se crean reglas de Amazon EventBridge que filtran las acciones IAM relevantes.
• Enrutamiento a notificación. Los eventos coincidentes según las reglas se envían a un topic de Amazon Simple Notification Service (Amazon SNS) centralizado con suscripciones por email para los equipos de Seguridad y CCoE.
• Notificaciones por email. Los suscriptores reciben un email casi en tiempo real con los campos clave: ID y alias de la cuenta, principal, acción, objetivo (usuario/rol/política), parámetros de la solicitud y un enlace de búsqueda en CloudTrail.

Fruto de la experiencia de Moeve en la gestión de notificaciones, se siguen las siguientes prácticas:

• Precisión antes que volumen. Se comienza con el conjunto mínimo de acciones realmente importantes, ajustando los filtros para evitar fatiga de alertas.
• Supresión basada en etiquetas. Si el actor es un rol de automatización aprobado (por ejemplo, el rol de ejecución de StackSet), se baja la severidad o se agrupan notificaciones.
• Lista blanca de PBs. Se mantiene una lista de ARNs de PBs aprobados y se alerta ante cualquier intento de crear o establecer versiones no incluidas en la lista.
• Pruebas y simulacros. Se simula periódicamente cada evento en un sandbox para verificar notificaciones, runbooks y responsables.
• Principio de mínimo privilegio. Los roles de Amazon EventBridge y AWS Lambda quedan restringidos a publicar solo en el topic de SNS previsto y leer solo los metadatos necesarios.

Con esta capa de observabilidad basada en eventos, Moeve complementa los controles preventivos (SCPs, PBs) con controles detectivos y respuestas consecuentes. El resultado es una detección más rápida de cambios con potencial riesgo, mayor responsabilidad y una trazabilidad auditable. Así, la gobernanza de Moeve no solo está bien diseñada, sino también bien operada.

Limitaciones y compensaciones

Existen algunas precauciones y limitaciones que deben tenerse en cuenta a la hora de implementar una práctica como la explicada en este blog:

• Las cuotas de SCPs son limitadas. Las organizaciones tienen un cupo de SCPs. El uso excesivo puede consumir esta capacidad.
• Complejidad de troubleshooting. Con múltiples capas de políticas (identidad, PBs, SCPs), identificar la causa de una denegación puede ser más complicado.
• Límites de políticas IAM. IAM impone límites en el número máximo de políticas gestionadas por rol y usuario. Añadir PBs puede llegar a comprometer estos límites en cuentas grandes.
• Scoping dinámico vs. controles generales: Adaptar PBs dinámicamente por cuenta (mediante el uso de etiquetas) aumenta la flexibilidad, pero añade cierta complejidad operativa.
• Separación con Identity Center: La solución aquí descrita aplica a la gestión de roles IAM dentro de cuentas, no cubre los Permission Sets de Identity Center, que siguen siendo gestionados centralmente.
• Velocidad vs. Seguridad: Requerir PBs refuerza la seguridad, pero puede ralentizar a los desarrolladores si faltan guías y plantillas. La adopción exitosa requiere inversión en habilitación: documentación clara, plantillas y feedback.

En resumen, este modelo presenta un marco sólido de agilidad y gobernanza, pero debe adaptarse al contexto, restricciones y modelo de responsabilidades de cada organización.

Conclusiones.

Moeve ha conseguido la gestión a escala de identidades en AWS sin tener que elegir entre control y agilidad, sino dotando a la organización de ambos pilares. Con PBs, SCPs y pipelines de automatización, Moeve concede a sus desarrolladores la posibilidad de crear y gestionar roles, sin salir de los límites marcados por el CCoE. Cada cuenta AWS nueva recibe un PB desde su creación, las actualizaciones de las PBs se gestionan por Git como código, y con reglas de Amazon EventBridge se vigilan los cambios críticos.

Mediante la automatización de la seguridad y su inclusión en el flujo de desarrollo, Moeve ha conseguido que la seguridad no sea un obstáculo, sino un habilitador de la innovación segura a escala.

Autores 

Rayco Martínez, Responsable de Cloud en Moeve, donde se encarga de construir entornos en la nube seguros, conformes y eficientes. Es licenciado en Informática y actualmente cursa un máster en Ciberseguridad. Apasionado por la estrategia y la gobernanza en la nube, Rayco se centra en adoptar AWS con confianza y control. Cuando no está trabajando en iniciativas Cloud, disfruta explorando nuevas tecnologías y pasando tiempo al aire libre en las Islas Canarias.

Pablo Monteagudo, Arquitecto Senior de Soluciones en AWS Industries, apasionado en ayudar a las empresas a innovar y a entregar nuevos servicios con agillidad sobre AWS.