AWS Organizations, accounts, and IAM guardrails - AWS Prescriptive Guidance

AWS Organizations, accounts, and IAM guardrails

AWS security services, their controls, and interactions are employed on a foundation of AWS account strategy and identity and access management guardrails. These set the foundation for your implementation of least privilege, separation of duties, and privacy, and provide the support for decisions about what types of controls are needed, where each security service is managed, and how they may share data in the AWS SRA.

An AWS account provides security, access, and billing boundaries for your AWS resources and enables you to achieve resource independence and isolation. Use of multiple AWS accounts plays an important role in how you meet your security requirements, as discussed in the Benefits of using multiple AWS accounts section of the Organizing Your AWS Environment Using Multiple Accounts whitepaper. For example, you should organize your workloads in separate accounts and group accounts based on function, compliance requirements, or a common set of controls instead of mirroring your enterprise’s reporting structure. Keep security and infrastructure in mind to enable your enterprise to set common guardrails as your workloads grow. This approach provides boundaries and controls between workloads. Account-level separation is used to isolate production environments from development and test environments, or to provide a strong logical boundary between workloads that process data of different classifications such as Payment Card Industry Data Security Standard (PCI DSS) or Health Insurance Portability and Accountability Act (HIPAA). Although you might begin your AWS journey with a single account, AWS recommends that you set up multiple accounts, as your workloads grow in size and complexity.

Permissions let you specify access to AWS resources. Permissions are granted to IAM entities known as principals (users, groups, and roles). By default, principals start with no permissions. IAM principals can do nothing in AWS until you grant them permissions, and you can set up guardrails that apply as broadly as your entire AWS organization or as fine-grained as an individual combination of principal, action, resource, and conditions.