Which strategy will meet these requirements?
Create separate OUs in AWS Organizations for each development unit. Assign the created OUs to the company AWS accounts. Create separate SCP with a deny action and a StringNotEquals condition for the DevelopmentUnit resource tag that matches the development unit name. Assign the SCP to the corresponding OU.
Pass an attribute for DevelopmentUnit as an AWS Security Token Service (AWS STS) session tag during SAML federation. Update the IAM policy for the developers’ assumed IAM role with a deny action and a StringNotEquals condition for the DevelopmentUnit resource tag and aws:PrincipalTag/DevelopmentUnit.
Pass an attribute for DevelopmentUnit as an AWS Security Token Service (AWS STS) session tag during SAML federation. Create an SCP with an allow action and a StringEquals condition for the DevelopmentUnit resource tag and aws:PrincipalTag/DevelopmentUnit. Assign the SCP to the root OU.
Create separate IAM policies for each development unit. For every IAM policy, add an allow action and a StringEquals condition for the DevelopmentUnit resource tag and the development unit name. During SAML federation, use AWS Security Token Service (AWS STS) to assign the IAM policy and match the development unit name to the assumed IAM role.
Explanations:
While creating separate OUs and using Service Control Policies (SCPs) to enforce tagging could provide isolation, it would not prevent users from managing resources across units. Deny actions based on resource tags alone do not ensure that developers can manage their instances effectively.
This option correctly leverages AWS STS session tags to pass the DevelopmentUnit attribute, allowing for fine-grained permissions management. The IAM policy can restrict access to only the instances tagged with the developer’s unit, preventing cross-unit resource management.
Although passing the DevelopmentUnit as an STS session tag is a good approach, creating an SCP with an allow action at the root OU level would grant broader permissions than intended, potentially allowing access to all development units’ resources. This contradicts the requirement of preventing unauthorized access.
Creating separate IAM policies for each unit with allow actions could lead to complexity and potential misconfiguration. While this method attempts to isolate permissions, it does not use SCPs effectively and relies solely on IAM policies, which can be more difficult to manage at scale across multiple accounts.
I sort that the answer is:
Pass an attribute for DevelopmentUnit as an AWS Security Token Service (AWS STS) session tag during SAML federation. Update the IAM policy for the developers’ assumed IAM role with a deny action and a StringNotEquals condition for the DevelopmentUnit resource tag and aws:PrincipalTag/DevelopmentUnit.