# SRA building blocks – AWS Organizations, accounts, and guardrails
| |
| --- |
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). |
AWS security services, their controls, and interactions are best employed on a foundation of AWS[ multi-account strategy](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) and identity and access management guardrails. These guardrails set the ability 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 and permissions 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](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) section of the *Organizing your AWS environment using multiple accounts* whitepaper. For example, you can organize your workloads in separate accounts and group accounts within an organizational unit (OU) 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 robust boundaries and controls between workloads. Account-level separation, in combination with AWS Organizations, 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.
# Using AWS Organizations for security
| |
| --- |
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). |
[AWS Organizations](https://aws.amazon.com/organizations/) helps you centrally manage and govern your environment as you grow and scale your AWS resources. By using AWS Organizations, you can programmatically create new AWS accounts, allocate resources, group accounts to organize your workloads, and apply policies to accounts or groups of accounts for governance. An AWS organization consolidates your AWS accounts so that you can administer them as a single unit. It has one management account along with zero or more member accounts. Most of your workloads reside in member accounts, except for some centrally managed processes that must reside in either the management account or in accounts assigned as delegated administrators for specific AWS services. You can provide tools and access from a central location for your security team to manage security needs on behalf of an AWS organization. You can reduce resource duplication by sharing critical resources within your AWS organization. [You can group accounts into AWS organizational units (OUs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html), which can represent different environments based on the workload's requirements and purpose. AWS Organizations also provides several policies that enable you to centrally apply additional security controls to all the member accounts in your organizations. This section focuses on service control policies (SCPs), resource control policies (RCPs), and declarative policies.
With AWS Organizations, you can use [SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) and [RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) to apply permission guardrails at the AWS organization, OU, or account level. SCPs are guardrails that apply to principals within an organization's account, with the exception of the management account (which is one reason not to run workloads in this account). When you attach an SCP to an OU, the SCP is inherited by the child OUs and accounts under that OU. SCPs do not grant any permissions. Instead, they specify the maximum permissions available for your principals in an AWS organization, OU, or account. You still need to attach [identity-based or resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to principals or resources in your AWS accounts to actually grant permissions to them. For example, if an SCP denies access to all of Amazon S3, a principal affected by the SCP will not have access to Amazon S3 even if they are explicitly** **granted access through an IAM policy. For more information about how IAM policies are evaluated, the role of SCPs, and how access is ultimately granted or denied, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the IAM documentation.
RCPs are guardrails that apply to resources within an organization's accounts, regardless of whether the resources belong to the same organization. Like SCPs, RCPs don't affect the resources in the management account and do not grant any permissions. When you attach an RCP to an OU, the RCP is inherited by the child OUs and accounts under the OU. RCPs provide central control over the maximum available permissions for resources in your organization and currently support a subset of AWS services. When you design SCPs for your OUs, we recommend that you evaluate changes by using the [IAM policy simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html). You should also review the [service last accessed data in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) and use [AWS CloudTrail to log service usage at the API level](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html) to understand the potential impact of SCP changes.
SCPs and RCPs are independent controls. You can choose to enable only SCPs or RCPs, or use both policy types together based on the access controls that you want to enforce. For example, if you want to prevent your organization's principals from accessing resources outside your organization, you enforce this control by using SCPs. If you want to restrict or prevent external identities from accessing your resources, you enforce this control by using RCPs. For more information and use cases for RCPs and SCPs, see [Using SCPs and RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html#when-to-use-scps-and-rcps) in the AWS Organizations documentation.
You can use AWS Organizations declarative policies to centrally declare and enforce your desired configuration for a given AWS service at scale across an organization. For example, you can block public internet access to Amazon VPC resources across your organization. Unlike authorization policies such as SCPs and RCPs, declarative policies are enforced in an AWS service's control plane. Authorization policies regulate access to APIs, whereas declarative policies are applied directly at the service level to enforce durable intent. These policies help ensure that the baseline configuration for an AWS service is always maintained, even when the service introduces new features or APIs. The baseline configuration is also maintained when new accounts are added to an organization or when new principals and resources are created. Declarative policies can be applied to an entire organization or to specific OUs or accounts.
Every AWS account has a single [root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) that has full permissions to all AWS resources by default. As a security best practice, we recommend that you don't use the root user except for a [few tasks](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) that explicitly require a root user. If you manage multiple AWS accounts through AWS Organizations, you can centrally disable root sign-in and then perform root privileged actions on behalf of all member accounts. After you [centrally manage root access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) for member accounts, you can delete the root user password, access keys, and signing certificates, and deactivate multi-factor authentication (MFA) for member accounts. New accounts that are created under centrally managed root access have no root user credentials by default. Member accounts can't sign in with their root user or perform password recovery for their root user.
[AWS Control Tower](https://aws.amazon.com/controltower/) offers a simplified way to set up and govern multiple accounts. It automates the setup of accounts in your AWS organization, automates provisioning, applies [controls](https://docs.aws.amazon.com/controltower/latest/controlreference/controls-reference.html) (which include preventive and detective controls), and provides you with a dashboard for visibility. An additional IAM management policy, a [permissions boundary](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), is attached to specific IAM principals (users or roles) and sets the maximum permissions that an identity-based policy can grant to an IAM principal.
AWS Organizations helps you configure [AWS services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) that apply to all your accounts. For example, you can configure central logging of all actions performed across your AWS organization by using [CloudTrail,](https://aws.amazon.com/cloudtrail/) and prevent member accounts from disabling logging. You can also centrally aggregate data for rules that you've defined by using [AWS Config](https://aws.amazon.com/config/), so you can audit your workloads for compliance and react quickly to changes. You can use [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) to centrally manage CloudFormation stacks across accounts and OUs in your AWS organization, so you can automatically provision a new account to meet your security requirements.
The default configuration of AWS Organizations supports using SCPs as *deny lists*. By using a deny list strategy, member account administrators can delegate all services and actions until you create and attach an SCP that denies a specific service or set of actions. Deny statements require less maintenance than an allow list, because you don't have to update them when AWS adds new services. Deny statements are usually shorter in character length, so it's easier to stay within the maximum size for SCPs. In a statement where the `Effect` element has a value of `Deny`, you can also restrict access to specific resources, or define conditions for when SCPs are in effect. By contrast, an `Allow` statement in an SCP applies to all resources (`"*"`) and cannot be restricted by conditions. For more information and examples, see [Strategies for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html) in the AWS Organizations documentation.
**Design considerations**
Alternatively, to use SCPs as an *allow list*, you must replace the AWS managed `FullAWSAccess` SCP with an SCP that explicitly permits only those services and actions that you want to allow. For a permission to be enabled for a specified account, every SCP (from the root through each OU in the direct path to the account and even attached to the account itself) must allow that permission. This model is more restrictive in nature and might be a fit for highly regulated and sensitive workloads. This approach requires you to explicitly allow every IAM service or action in the path from the AWS account to the OU.
Ideally, you would use a combination of deny list and allow list strategies. Use the allow list to define the list of allowed AWS services approved to be used within an AWS organization and attach this SCP at the root of your AWS organization. If you have a different set of services allowed per your development environment, you will attach the respective SCPs at each OU. You can then use the deny list to define enterprise guardrails by explicitly denying specific IAM actions.
RCPs apply to resources for a subset of AWS services. For more information, see [List of AWS services that support RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#rcp-supported-services) in the AWS Organizations documentation. The default configuration of AWS Organizations supports using RCPs as deny lists. When you enable RCPs in your organization, an AWS managed policy called `RCPFullAWSAccess` is automatically attached to the organization root, every OU, and every account in your organization. You cannot detach this policy. This default RCP allows all principals and actions access to pass through RCP evaluation. This means that until you start creating and attaching RCPs, all your existing IAM permissions continue to operate as they did. This AWS managed policy does not grant access. You can then author new RCPs as a list of deny statements to block access to resources in your organization.
# The management account, trusted access, and delegated administrators
| |
| --- |
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). |
The management account (also called the AWS Organization Management account or Org Management account) is unique and differentiated from every other account in AWS Organizations. It is the account that creates the AWS organization. From this account, you can create AWS accounts in the AWS organization, invite other existing accounts to the AWS organization (both types are considered *member accounts*), remove accounts from the AWS organization, and apply IAM policies to the root, OUs, or accounts within the AWS organization.
The management account deploys universal security guardrails through SCPs, RCPs, and service deployments (such as CloudTrail) that will affect all member accounts in the AWS organization. To further restrict permissions in the management account, those permissions can be delegated to another appropriate account, such as a security account, where possible.
The management account has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts. You cannot switch an AWS organization's management account. An AWS account can be a member of only one AWS organization at a time.
Because of the functionality and scope of influence the management account holds, we recommend that you limit access to this account and grant permissions only to roles that need them. Two features that help you do this are [trusted access](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) and [delegated administrator](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrated-services-list.html). You can use trusted access to enable an AWS service that you specify, called the *trusted service*, to perform tasks in your AWS organization and its accounts on your behalf. This involves granting permissions to the trusted service but does not otherwise affect the permissions for IAM users or roles. You can use trusted access to specify settings and configuration details that you would like the trusted service to maintain in your AWS organization's accounts on your behalf. For example, the [Org Management account](org-management.md) section of the AWS SRA explains how to grant the CloudTrail service trusted access to create a CloudTrail organization trail in all accounts in your AWS organization.
Some AWS services support the delegated administrator feature in AWS Organizations. With this feature*, *compatible services can register an AWSmember account in the AWS organization as an administrator for the AWS organization's accounts in that service. This capability provides flexibility for different teams within your enterprise to use separate accounts, as appropriate for their responsibilities, to manage AWS services across the environment. The AWS security services in the AWS SRA that currently support delegated administrator include IAM Identity Center, AWS Config, AWS Firewall Manager, Amazon GuardDuty, IAM Access Analyzer, Amazon Macie, AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM), Amazon Detective, AWS Audit Manager, Amazon Inspector, and AWS Systems Manager. Use of the delegated administrator feature is emphasized in the AWS SRA as a best practice, and we delegate administration of security-related services to the Security Tooling account.
# Dedicated accounts structure
| |
| --- |
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). |
An AWS account provides security, access, and billing boundaries for your AWS resources, and enables you to achieve resource independence and isolation. By default, no access is allowed between accounts.
When designing your OU and account structure, start with security and infrastructure in mind. We recommend creating a set of foundational OUs for these specific functions, split into Infrastructure and Security OUs. These OU and account recommendations capture a subset of our broader, more comprehensive guidelines for AWS Organizations and multi-account structure design. For a full set of recommendations, see [Organizing your AWS environment using multiple accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) in the AWS documentation and the blog post [Best practices for organizational units with AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/).
The AWS SRA utilizes the following accounts to achieve effective security operations on AWS. These dedicated accounts help ensure separation of duties, support different governance and access policies for different sensitives of applications and data, and help mitigate the impact of a security event. In the discussions that follow, we are focused on production (*prod*) accounts and their associated workloads. Software development lifecycle (SDLC) accounts (often called *dev* and *test* accounts) are intended for staging deliverables and can operate under a different security policy set from that of production accounts.
|
|
| **Account** | **OU** | **Security role** |
| --- |--- |--- |
| Management | — | Central governance and management of all AWS Regions and accounts. The AWS account that hosts the root of the AWS organization. |
| Security Tooling | Security | Dedicated AWS accounts for operating broadly applicable security services (such as GuardDuty, Security Hub CSPM, Audit Manager, Detective, Amazon Inspector, and AWS Config), monitoring AWS accounts, and automating security alerting and response. (In AWS Control Tower, the default name for the account under the Security OU is *Audit account*.) |
| Log Archive | Security | Dedicated AWS accounts for ingesting and archiving all logging and backups for all AWS Regions and AWS accounts. This should be designed as immutable storage. |
| Network | Infrastructure | The gateway between your application and the broader internet. The Network account isolates the broader networking services, configuration, and operation from the individual application workloads, security, and other infrastructure. |
| Shared Services | Infrastructure | This account supports the services that multiple applications and teams use to deliver their outcomes. Examples include Identity Center directory services (Active Directory), messaging services, and metadata services. |
| Application | Workloads | AWS accounts that host the AWS organization's applications and perform the workloads. (These are sometimes called *Workload accounts*.) Application accounts should be created to isolate software services instead of being mapped to your teams. This makes the deployed application more resilient to organizational change. |
# AWS organization and account structure of the AWS SRA
| |
| --- |
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). |
The following diagram captures the high-level structure of the AWS SRA without displaying specific services. It reflects the dedicated accounts structure discussed in the previous section, and we include the diagram here to orient the discussion around the primary components of the architecture:
+ All accounts that are shown in the diagram are part of a single AWS organization.
+ At the upper left of the diagram is the Org Management account, which is used to create the AWS organization.
+ Below the Org Management account is the Security OU with two specific accounts: one for Security Tooling and the other for Log Archive.
+ Along the right side is the Infrastructure OU with the Network account and Shared Services account.
+ At the bottom of the diagram is the Workloads OU, which is associated with an Application account that houses the enterprise application.
For this guidance, all accounts are considered production (prod) accounts that operate in a single AWS Region. Most AWS services (except for [global services](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/global-services.html)) are regionally scoped, which means that the control and data planes for the service exist independently in each AWS Region. For this reason, you must replicate this architecture across all AWS Regions that you plan to use, to ensure coverage for your entire AWS landscape. If you don't have any workloads in a specific AWS Region, you should disable the Region by using [SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region) or by using logging and monitoring mechanisms. You can use Security Hub CSPM to aggregate findings and security scores from multiple AWS Regions to a single aggregation Region for centralized visibility.
When hosting an AWS organization with a large set of accounts, it's beneficial to have an orchestration layer that facilitates account deployment and account governance. AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment. The AWS SRA code samples in the [GitHub repository](https://github.com/aws-samples/aws-security-reference-architecture-examples) demonstrate how you can use the [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) solution to deploy AWS SRA recommended structures.
![\[High-level structure of the AWS SRA (without services).\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/consolidated.png)
# Apply security services across your AWS organization
| |
| --- |
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a [short survey](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua). |
As described in a [previous section](value.md), customers are looking for an additional way to think about and strategically organize the full set of AWS security services. The most common organizational approach today is to group security services by primary function―according to what each service *does*. The security perspective of the AWS CAF lists nine functional capabilities, including identity and access management, infrastructure protection, data protection, and threat detection. Matching AWS services with these functional capabilities is a practical way to make implementation decisions in each area. For example, when looking at identity and access management, IAM and IAM Identity Center are services to consider. When architecting your threat detection approach, GuardDuty might be your first consideration.
As a complement to this functional view, you can also view your security with a cross-cutting, structural view. That is, in addition to asking, "Which AWS services should I use to control and protect my identities, logical access, or threat detection mechanisms?", you can also ask, "Which AWS services should I apply across my entire AWS organization? What are the layers of defense I should put in place to protect the Amazon EC2 instances at the core of my application?" In this view, you map AWS services and features to layers in your AWS environment. Some services and features are a great fit for implementing controls across your full AWS organization. For example, blocking public access to Amazon S3 buckets is a specific control at this layer. It should preferably be done at the root organization instead of being part of the individual account setup. Other services and features are best used to help protect individual resources within an AWS account. Implementing a subordinate certificate authority (CA) within an account that requires private TLS certificates is an example of this category. Another equally important grouping consists of services that have an effect on the virtual network layer of your AWS infrastructure. The following diagram shows six layers in a typical AWS environment: AWS organization, organizational unit (OU), account, network infrastructure, principals, and resources.
![\[Six layers in an AWS environment.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/six-layers.png)
Understanding the services in this structural context, including the controls and protections at each layer, helps you plan and implement a defense-in-depth strategy across your AWS environment. With this perspective, you can answer questions both from the top down (for example, "Which services am I using to implement security controls across my entire AWS organization?") and from the bottom up (for example, "Which services manage controls on this EC2 instance?"). In this section, we walk through the elements of an AWS environment and identify associated security services and features. Of course, some AWS services have broad feature sets and support multiple security objectives. These services might support multiple elements of your AWS environment.
For clarity, we provide brief descriptions of how some of the services fit the stated objectives. The [next section](architecture.md) provides further discussion of the individual services within each AWS account.
## Organization-wide or multiple accounts
At the top level, there are AWS services and features that are designed to apply governance and control capabilities or guardrails across multiple accounts in an AWS organization (including the entire organization or specific OUs). Service control policies (SCPs) and resource control policies (RCPs) are good examples of IAM features that provide preventative, AWS organization-wide guardrails. AWS Organizations also provides a declarative policy that centrally defines and enforces the baseline configuration for AWS services at scale. Another example is CloudTrail, which provides monitoring through an *organization trail* that logs all events for all AWS accounts in that AWS organization. This comprehensive trail is distinct from individual trails that might be created in each account. A third example is AWS Firewall Manager, which you can use to configure, apply, and manage multiple resources across all accounts in your AWS organization: AWS WAF rules, AWS WAF Classic rules, AWS Shield Advanced protections, Amazon Virtual Private Cloud (Amazon VPC) security groups, AWS Network Firewall policies, and Amazon Route 53 Resolver DNS Firewall policies.
The services marked with an asterisk (\$1) in the following diagram operate with a dual scope: organization-wide and account-focused. These services fundamentally monitor or help control security within an individual account. However, they also support the ability to aggregate their results from multiple accounts into an organization-wide account for centralized visibility and management. For clarity, consider SCPs that apply across an entire OU, AWS account, or AWS organization. In contrast, you can configure and manage GuardDuty both at the account level (where individual findings are generated) and at the AWS organization level (by using the delegated administrator feature) where findings can be viewed and managed in aggregate.
![\[Organization-wide and account-focused security services.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/org-multi-account.png)
## AWS accounts
Within OUs, there are services that help protect multiple types of elements within an AWS account. For example, AWS Secrets Manager is often typically managed from a specific account and protects resources (such as database credentials or authentication information), applications, and AWS services in that account. IAM Access Analyzer can be configured to generate findings when specified resources are accessible by principals outside the AWS account. As mentioned in the previous section, many of these services can also be configured and administered within AWS Organizations, so they can be managed across multiple accounts. These services are marked with an asterisk (\$1) in the diagram. They also make it easier to aggregate results from multiple accounts and deliver those to a single account. This gives individual application teams the flexibility and visibility to manage security needs that are specific to their workload while also allowing governance and visibility to centralized security teams. GuardDuty is an example of such a service. GuardDuty monitors resources and activity associated with a single account, and GuardDuty findings from multiple member accounts (such as all accounts in an AWS organization) can be collected, viewed, and managed from a delegated administrator account.
![\[Security services that protect multiple types of elements within an AWS account.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/aws-account.png)
## Virtual network, compute, and content delivery
Because network access is so critical in security, and compute infrastructure is a fundamental component of many AWS workloads, there are many AWS security services and features that are dedicated to these resources. For example, Amazon Inspector is a vulnerability management service that continuously scans your AWS workloads for vulnerabilities. These scans include network reachability checks that indicate that there are allowed network paths to Amazon EC2 instances in your environment. Amazon VPC lets you define a virtual network into which you can launch AWS resources. This virtual network closely resembles a traditional network and includes a variety of features and benefits. VPC endpoints enable you to privately connect your VPC to supported AWS services and to the endpoint services powered by AWS PrivateLink without requiring a path to the internet. The following diagram illustrates security services that focus on network, compute, and content delivery infrastructure.
![\[Security services that focus on network, compute, or content delivery infrastructure\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/virtual-network.png)
## Principals and resources
AWS principals and AWS resources (along with IAM policies) are the fundamental elements in identity and access management on AWS. An authenticated principal in AWS can perform actions and access AWS resources. A principal can be authenticated as an AWS account root user and IAM user, or by assuming a role.
**Note**
Do not create persistent API keys associated with the AWS root user account. Access to the root user account should be limited only to the [tasks that require a root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root), and then only through a rigorous exception and approval process. For best practices to protect your account's root user, see the [IAM documentation](https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html).
An AWS resource is an object that exists within an AWS service that you can work with. Examples include an EC2 instance, a CloudFormation stack, an Amazon Simple Notification Service (Amazon SNS) topic, and an S3 bucket. IAM policies are objects that define permissions when they are associated with an IAM principal (user, group, or role) or AWS resource. [Identity-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)** **are policy documents that you attach to a principal (roles, users, and groups of users) to control which actions a principal can perform, on which resources, and under which conditions. [Resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)** **are policy documents that you attach to a resource such as an S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and define the conditions for that permission. Resource-based policies are in-line policies. The [IAM resources](iam-resources.md) section dives deeper into the types of IAM policies and how they are used.
To keep things simple in this discussion, we list AWS security services and features for IAM principals that have a primary purpose of operating on, or applying to, account principals. We keep that simplicity while acknowledging the flexibility and breadth of effects of IAM permission policies. A single statement in a policy can have effects on multiple types of AWS entities. For example, although an IAM identity-based policy is associated with an IAM principal and defines permissions (allow, deny) for that principal, the policy also implicitly defines permissions for the actions, resources, and conditions specified. In this way, an identity-based policy can be a critical element in defining permissions for a resource.
The following diagram illustrates AWS security services and features for AWS principals. Identity-based policies are attached to an IAM user, group, or role. These policies let you specify what that identity can do (its permissions). An IAM session policy is an [inline permissions policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) that users pass in the session when they assume the role. You can pass the policy yourself, or you can configure your identity broker to insert the policy when your [identities federate in to AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html). This enables your administrators to reduce the number of roles they have to create, because multiple users can assume the same role yet have unique session permissions. The IAM Identity Center service is integrated with AWS Organizations and AWS API operations, and helps you manage SSO access and user permissions across your AWS accounts in AWS Organizations.
![\[AWS security services and features for account principals.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/principals.png)
The following diagram illustrates services and features for account resources. Resource-based policies are attached to a resource. For example, you can attach resource-based policies to S3 buckets, Amazon Simple Queue Service (Amazon SQS) queues, VPC endpoints, and AWS KMS encryption keys. You can use resource-based policies to specify who has access to the resource and what actions they can perform on it. S3 bucket policies, AWS KMS key policies, and VPC endpoint policies are types of resource-based policies. IAM Access Analyzer helps you identify the resources in your organization and accounts, such as S3 buckets or IAM roles, that are shared with an external entity. This lets you identify unintended access to your resources and data, which is a security risk. AWS Config enables you to assess, audit, and evaluate the configurations of supported AWS resources in your AWS accounts. AWS Config continuously monitors and records AWS resource configurations, and automatically evaluates recorded configurations against desired configurations.
![\[AWS security services and features for account resources.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/images/resources.png)