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 SCPs 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 Organizational Units (OUs) and Service Control Policies (SCPs) can help isolate accounts, using SCPs with a deny action based on resource tags can be problematic. SCPs are applied at the account level and cannot enforce tag-based restrictions effectively across different accounts. Hence, this option does not prevent one unit from affecting resources of another unit effectively.
This option leverages AWS STS session tags passed during SAML federation to enforce a deny policy based on theDevelopmentUnittag. By updating the IAM policy with a condition that checks the tag against the resource, it ensures that developers can only manage resources that belong to their unit, thereby preventing accidental termination of instances belonging to other units.
This option suggests creating an SCP with an allow action and a condition based on theDevelopmentUnittag. However, SCPs do not control access at the resource level in the manner described. SCPs can only allow or deny permissions at the account or organizational unit level, and the approach of matching session tags in SCPs does not effectively limit access based on specific resource tags.
This option suggests creating separate IAM policies for each development unit that include a condition based on theDevelopmentUnittag. However, during SAML federation, assigning IAM policies based on tags does not inherently restrict access to resources, and the approach described does not enforce a clear separation between the units, as IAM policies do not prevent actions from affecting resources owned by other units directly.
I outline 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.
I think 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.