Fabrikam Games permite a su grupo de DevOps crear roles de IAM para cargas de trabajo de EC2. Seguridad debe asegurar que cualquier rol que creen no pueda exceder un conjunto definido de permisos (solo lectura a la tabla de DynamoDB Scores y publicación en CloudWatch Logs), independientemente de las políticas que DevOps adjunte posteriormente. ¿Cuál es el enfoque MÁS efectivo?

La opción correcta es la más efectiva porque utiliza un permissions boundary para establecer los permisos máximos que un rol puede tener, incluso si se adjuntan políticas más permisivas. Al exigir que los roles creados por DevOps incluyan un permissions boundary específico mediante una condición en la política de IAM (iam:PermissionsBoundary), se garantiza que estos roles nunca excederán los permisos definidos (solo lectura de DynamoDB Scores y publicación en CloudWatch Logs), sin importar las políticas que DevOps intente adjuntar. Las otras opciones son incorrectas: Adjuntar un permissions boundary a cada usuario de DevOps no restringe los roles que crean, solo las acciones que los usuarios pueden realizar directamente. Un SCP (Service Control Policy) en la OU de DevOps limitaría las acciones que las cuentas dentro de la OU pueden realizar, pero no restringe los permisos de los roles de IAM creados dentro de esas cuentas de la misma manera granular y específica para roles. Una política de recursos en la tabla de DynamoDB solo controla el acceso a esa tabla y no restringe las acciones generales que un rol puede realizar en otros servicios o recursos.