The value of the AWS SRA
| Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey |
AWS has a large (and growing) set of
security and security-related services
-
Customers want more information and recommended patterns for how they can deploy, configure, and operate the AWS security services holistically. In which accounts and toward which security objectives should the services be deployed and managed? Is there one security account where all or most services should operate? How does the choice of location (organizational unit or AWS account) inform security objectives? Which trade-offs (design considerations) should customers be aware of?
-
Customers are interested in seeing different perspectives for logically organizing the many AWS security services. Beyond the primary function of each service (for example, identity services or logging services), these alternate viewpoints help customers plan, design, and implement their security architecture. An example shared later in this guide groups the services based on the layers of protection aligned to the recommended structure of your AWS environment.
-
Customers are looking for guidance and examples to integrate security services in the most effective way. For example, how should they best align and connect AWS Config with other services to do the heavy lifting in automated audit and monitoring pipelines? Customers are asking for guidance on how each AWS security service relies on, or supports, other security services.
We address each of these in the AWS SRA. The first priority in the list (where things go) is the focus of the main architecture diagram and the accompanying discussions in this document. We provide a recommended AWS Organizations architecture and an account-by-account description of which services go where. To get started with the second priority in the list (how to think about the full set of security services), read the section, Apply security services across your AWS organization. This section describes a way to group security services according to the structure of the elements in your AWS organization. In addition, those same ideas are reflected in the discussion of the Application account, which highlights how security services can be operated to focus on certain layers of the account: Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Virtual Private Cloud (Amazon VPC) networks, and the broader account. Finally, the third priority (service integration) is reflected throughout the guidance—particularly in the discussion of individual services in the account deep-dives sections of this documentation and the code in the AWS SRA code repository.
How to use the AWS SRA
There are different ways to use the AWS SRA depending on where you are in your cloud adoption journey. Here is a list of ways to gain the most insight from the AWS SRA assets (architecture diagram, written guidance, and code samples).
-
Define the target state for your own security architecture.
Whether you are just starting your AWS Cloud journey—setting up your first set of accounts—or planning to enhance an established AWS environment, the AWS SRA is the place to start building your security architecture. Begin with a comprehensive foundation of account structure and security services, and then adjust based on your particular technology stack, skills, security objectives, and compliance requirements. If you know you will be building and launching more workloads, you can take your customized version of the AWS SRA and use it as the basis for your organization's security reference architecture. To find out how you can achieve the target state described by the AWS SRA, see the section Building your security architecture – A phased approach.
-
Review (and revise) the designs and capabilities that you have already implemented.
If you already have a security design and implementation, it is worth taking some time to compare what you have to the AWS SRA. The AWS SRA is designed to be comprehensive and provides a diagnostic baseline for reviewing your own security. Where your security designs align to the AWS SRA, you can feel more confident that you are following best practices when using AWS services. If your security designs diverge or even disagree with the guidance in the AWS SRA, this isn't necessarily a sign that you're doing something wrong. Instead, this observation provides you with the opportunity to review your decision process. There are legitimate business and technology reasons why you might deviate from the AWS SRA best practices. Perhaps your particular compliance, regulatory, or organization security requirements necessitate specific service configurations. Or, instead of using AWS services, you might have a feature preference for a product from the AWS Partner Network or a custom application that you built and manage. Sometimes, during this review, you might discover that your previous decisions were made based on older technology, AWS features, or business constraints that no longer apply. This is a good opportunity to review, prioritize any updates, and add them to the appropriate place of your engineering backlog. Whatever you discover as you assess your security architecture in light of the AWS SRA, you will find it valuable to document that analysis. Having that historical record of decisions and their justifications can help inform and prioritize future decisions.
-
Bootstrap the implementation of your own security architecture.
The AWS SRA infrastructure as code (IaC) modules provide a fast, reliable way to start
building and implementing your security architecture. These modules are described more deeply
in the code repository section and in the public
GitHub repository
-
Learn more about AWS security services and capabilities.
The guidance and discussions in the AWS SRA include important features as well as deployment and management considerations for individual AWS security and security-related services. One feature of the AWS SRA is that it provides a high-level introduction to the breadth of the AWS security services and how they work together in a multi-account environment. This complements the deep dive into the features and configuration for each service found in other sources. One example of this is the discussion of how AWS Security Hub ingests security findings from a variety of AWS services, AWS Partner products, and even your own applications.
-
Drive a discussion of organizational governance and responsibilities for security.
An important element of designing and implementing any security architecture or strategy is understanding who in your organization has which security-related responsibilities. For example, the question of where to aggregate and monitor security findings is tied to the question of which team will be responsible for that activity. Are all findings across the organization monitored by a central team that needs access to a dedicated Security Tooling account? Or are individual application teams (or business units) responsible for certain monitoring activities and therefore need access to certain alerting and monitoring tools? As another example, if your organization has a group that manages all encryption keys centrally, that will influence who has permission to create AWS Key Management Service (AWS KMS) keys and which accounts those keys will be managed in. Understanding the characteristics of your organization—the various teams and responsibilities—will help you tailor the AWS SRA to best fit your needs. Conversely, sometimes the discussion of the security architecture becomes the impetus for discussing the existing organizational responsibilities and considering potential changes. AWS recommends a decentralized decision-making process where workload teams are responsible for defining the security controls based on their workload functions and requirements. The goal of centralized security and governance team is to build a system that allows the workload owners to make informed decisions and for all parties to get visibility of configuration, findings, and events. The AWS SRA can be a vehicle for identifying and informing these discussions.
Key implementation guidelines of the AWS SRA
Here are eight key takeaways from the AWS SRA to keep in mind as you design and implement your security.
-
AWS Organizations and an appropriate multi-account strategy are necessary elements of your security architecture. Properly separating workloads, teams, and functions provides the foundations for separation of duties and defense-in-depth strategies. The guide covers this further in a later section.
-
Defense-in-depth is an important design consideration for selecting security controls for your organization. It helps you inject the appropriate security controls at different layers of the AWS Organizations structure, which helps minimize the impact of an issue: If there is an issue with one layer, there are controls in place that isolate other valuable IT resources. The AWS SRA demonstrates how different AWS services function at different layers of the AWS technology stack, and how using those services in combination helps you achieve defense-in-depth. This defense-in-depth concept on AWS is further discussed in a later section with design examples shown under Application account.
-
Use the wide variety of security building blocks across multiple AWS services and features to build a robust and resilient cloud infrastructure. When tailoring the AWS SRA to your particular needs, consider not only the primary function of AWS services and features (for example, authentication, encryption, monitoring, permission policy) but also how they fit into the structure of your architecture. A later section in the guide describes how some services operate across your entire AWS organization. Other services operate best within a single account, and some are designed to grant or deny permission to individual principals. Considering both of these perspectives helps you build a more flexible, layered security approach.
-
Where possible (as detailed in later sections), make use of AWS services that can be deployed in every account (distributed instead of centralized) and build a consistent set of shared guardrails that can help protect your workloads from misuse and help reduce the impact of security events. The AWS SRA uses AWS Security Hub (centralized finding monitoring and compliance checks), Amazon GuardDuty (threat detection and anomaly detection), AWS Config (resource monitoring and change detection), IAM Access Analyzer (resource access monitoring, AWS CloudTrail (logging service API activity across your environment) and Amazon Macie (data classification) as a base set of AWS services to be deployed across every AWS account.
-
Make use of the delegated administration feature of AWS Organizations, where it is supported, as explained later in the delegated administration section of the guide. This enables you to register an AWS member account as an administrator for supported services. Delegated administration provides flexibility for different teams within your enterprise to use separate accounts, as appropriate for their responsibilities, to manage AWS services across the environment. In addition, using a delegated administrator helps you limit access to, and manage the permissions overhead of, the AWS Organizations management account.
-
Implement centralized monitoring, management, and governance across your AWS organizations. By using AWS services that support multi-account (and sometimes multi-Region) aggregation, along with delegated administration features, you empower your central security, network, and cloud engineering teams to have broad visibility and control over appropriate security configuration and data collection. Additionally, the data can be provided back to workload teams to empower them to make effective security decisions earlier in the software development lifecycle (SDLC).
-
Use AWS Control Tower to set up and govern your multi-account AWS environment with the implementation of pre-built security controls to bootstrap your security reference architecture build. AWS Control Tower provides a blueprint to provide identity management, federated access to accounts, centralized logging, and defined workflows for provisioning additional accounts. You can then use the Customizations for AWS Control Tower (CfCT)
solution to baseline the accounts managed by AWS Control Tower with additional security controls, service configurations, and governance, as demonstrated by the AWS SRA code repository. The account factory feature automatically provisions new accounts with configurable templates based on approved account configuration to standardize accounts within your AWS Organizations. You can also extend the governance to an individual existing AWS account by enrolling it into an organizational unit (OU) that is already governed by AWS Control Tower. -
The AWS SRA code examples demonstrate how you can automate the implementation of patterns within the AWS SRA guide by using infrastructure as code (IaC). By codifying the patterns, you can treat IaC like other applications in your organization, and automate testing before you deploy code. IaC also helps ensure consistency and repeatability by deploying guardrails across multiple (for example, SDLC or Region-specific) environments. The SRA code examples can be deployed in an AWS Organizations multi-account environment with or without AWS Control Tower. The solutions in this repository that require AWS Control Tower have been deployed and tested in an AWS Control Tower environment by using AWS CloudFormation and Customizations for AWS Control Tower (CfCT)
. Solutions that don’t require AWS Control Tower have been tested in an AWS Organizations environment by using AWS CloudFormation. If you do not use AWS Control Tower, you can use the AWS Organizations-based deployment solution.
