Which solution will address the Security team’s concerns and allow the Developers to try new services?
Implement a strong identity and access management model that includes users, groups, and roles in various AWS accounts. Ensure that centralized AWS CloudTrail logging is enabled to detect anomalies. Build automation with AWS Lambda to tear down unapproved AWS resources for governance.
Build a multi-account strategy based on business units, environments, and specific regulatory requirements. Implement SAML-based federation across all AWS accounts with an on-premises identity store. Use AWS Organizations and build organizational units (OUs) structure based on regulations and service governance. Implement service control policies across OUs.
Implement a multi-account strategy based on business units, environments, and specific regulatory requirements. Ensure that only PCI-compliant services are approved for use in the accounts. Build IAM policies to give access to only PCI-compliant services for governance.
Build one AWS account for the company for strong security controls. Ensure that all the service limits are raised to meet company scalability requirements. Implement SAML federation with an on-premises identity store, and ensure that only approved services are used in the account.
Explanations:
While implementing a strong IAM model and enabling CloudTrail are important for governance, this option lacks a comprehensive multi-account strategy that addresses different compliance needs across various business units. Simply tearing down unapproved resources does not provide a proactive governance framework.
This option provides a robust multi-account strategy that separates workloads by business units and regulatory requirements. Using SAML-based federation and AWS Organizations allows for fine-grained control over access. Service control policies (SCPs) ensure that compliance requirements are met across different organizational units, making this the most suitable choice.
Although this option implements a multi-account strategy and focuses on PCI compliance, it does not leverage organizational units or service control policies to enforce governance effectively. Limiting access only to PCI-compliant services does not address the broader compliance and access management needs across multiple business units.
Building a single AWS account undermines the need for compliance segregation required for different business units and regulatory requirements. While SAML federation is beneficial, having one account increases risk and complexity in managing compliance for diverse workloads, especially in a regulated environment like PCI.
I outline that the answer is:
Build a multi-account strategy based on business units, environments, and specific regulatory requirements. Implement SAML-based federation across all AWS accounts with an on-premises identity store. Use AWS Organizations and build organizational units (OUs) structure based on regulations and service governance. Implement service control policies across OUs.
To the best of my knowledge, the answer is:
Build a multi-account strategy based on business units, environments, and specific regulatory requirements. Implement SAML-based federation across all AWS accounts with an on-premises identity store. Use AWS Organizations and build organizational units (OUs) structure based on regulations and service governance. Implement service control policies across OUs.