Apply security services across your AWS organization
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey |
As described in a previous section, 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, Amazon 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.
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 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) are a good example of an IAM feature that provides a preventative AWS organization-wide guardrail. Another example is AWS 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 * 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 Amazon 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.
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. AWS 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 (*) 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. Amazon 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.
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 Virtual Private Cloud
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, or IAM user, or by assuming a role.
Note
Do not create persistent API keys associated with the AWS root user. Access to the root user should be limited only to the tasks that require a root user, and then only through a rigorous exception and approval process. For best practices to protect your account's root user, see the AWS documentation.
An AWS resource is an object that exists within an AWS service that you can work with. Examples include an EC2 instance, an AWS 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 identity (user, group, or role) or AWS resource. Identity-based policies 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 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 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 entities 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 entity and defines permissions (allow, deny) for that entity, 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 IAM resource objects that are used for identification and grouping, such as users, groups, and roles. These policies let you specify what that identity can do (its permissions). An IAM session policy is an inline permissions policy 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. 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.
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. AWS 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.
