Varios equipos de desarrollo implementan cargas de trabajo de producción en una cuenta de AWS de producción compartida. Recientemente, miembros de un equipo de desarrollo terminaron una instancia EC2 perteneciente a otro equipo. Los desarrolladores utilizan la federación SAML a través de AWS Organizations para asumir roles. Debe evitar que los desarrolladores administren instancias pertenecientes a otros equipos, al mismo tiempo que les permite administrar sus propias instancias. ¿Qué estrategia cumple con estos requisitos?

La opción correcta utiliza etiquetas de sesión de AWS STS y políticas de IAM basadas en atributos para aplicar permisos granulares. Al pasar un atributo DevelopmentUnit como etiqueta de sesión durante la federación SAML, se asocia la unidad de desarrollo del usuario con su sesión. Luego, una política de IAM adjunta al rol asumido puede usar una condición StringNotEquals en aws:PrincipalTag/DevelopmentUnit y la etiqueta de recurso DevelopmentUnit para denegar acciones en recursos que no pertenecen a la unidad del desarrollador. Esto asegura que los desarrolladores solo puedan administrar sus propios recursos etiquetados. Las opciones incorrectas fallan porque: Crear OUs separadas y SCPs con StringNotEquals no es ideal para una cuenta compartida, ya que los SCPs se aplican a toda la OU, no solo a los recursos específicos. Un SCP con una acción de permiso y StringEquals en la OU raíz no denegaría explícitamente el acceso a recursos de otros equipos, solo permitiría el acceso a los propios. Crear políticas de IAM separadas para cada unidad de desarrollo y asignarlas dinámicamente es menos escalable y más complejo que usar etiquetas de sesión y una única política basada en atributos.