Building your security architecture – A phased approach - AWS Prescriptive Guidance

Building your security architecture – A phased approach

Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey.

The multi-account security architecture recommended by the AWS SRA is a baseline architecture to help you inject security early into your design process. Each organization’s cloud journey is unique. To successfully evolve your cloud security architecture, you need to envision your desired target state, understand your current cloud readiness, and adopt an agile approach to close any gaps. The AWS SRA provides a reference target state for your security architecture. Transforming incrementally enables you to demonstrate value quickly while minimizing the need to make far-reaching predictions.

The AWS Cloud Adoption Framework (AWS CAF) recommends four iterative and incremental cloud transformation phases: Envision, Align, Launch, and Scale. As you enter the Launch phase and focus on delivering pilot initiatives in production, you should focus on building a strong security architecture as a foundation for the Scale phase so that you have the technical ability to migrate and operate your most business-critical workloads with confidence. This phased approach is applicable if you are a startup, a small or medium company that wants to expand their business, or an enterprise that’s acquiring new business units or undergoing mergers and acquisitions. The AWS SRA helps you achieve that security baseline architecture so that you can apply security controls uniformly across your expanding organization in AWS Organizations. The baseline architecture consists of multiple AWS accounts and services. Planning and implementation should be a multi-phase process so that you can iterate over smaller milestones to reach the bigger goal of setting up your baseline security architecture. This section describes the typical phases of your cloud journey based on a structured approach. These phases align with the AWS Well-Architected Framework security design principles.

Phase 1: Build your OU and account structure

A prerequisite to a strong security foundation is a well-designed AWS organization and account structure. As explained previously in the SRA building blocks section of this guide, having multiple AWS accounts helps you isolate different business and security functions by design. This might seem like unnecessary work in the beginning, but it’s an investment to help you scale quickly and securely. That section also explains how you can use AWS Organizations to manage multiple AWS accounts, and how to use trusted access and delegated administrator features to centrally manage AWS services across these multiple accounts.

You can use AWS Control Tower as outlined earlier in this guide to orchestrate your landing zone. If you are currently using a single AWS account, see the Transitioning to multiple AWS accounts guide to migrate to multiple accounts as early as you can. For example, if your startup company is currently ideating and prototyping your product in a single AWS account, you should think about adopting a multi-account strategy before you launch your product in the market. Similarly, small, medium, and enterprise organizations should start to build their multi-account strategy as soon as they plan their initial production workloads. Start with your foundation OUs and AWS accounts, and then add your workload-related OUs and accounts.

For AWS account and OU structure recommendations beyond what’s provided in the AWS SRA, see the Multi-account strategy for small and medium businesses blog post. As you’re finalizing your OU and account structure, consider the high-level, organization-wide security controls that you would want to enforce by using service control policies (SCPs).

Design consideration
  • Do not replicate your company’s reporting structure when you design your OU and account structure. Your OUs should be based on workload functions and a common set of security controls that apply to the workloads. Don’t try to design your complete account structure from the beginning. Focus on the foundational OUs, and then add workload OUs as you need them. You can move accounts between OUs to experiment with alternative approaches during the early stages of your design. However, this might result in some overhead around managing logical permissions, depending on SCPs and IAM conditions that are based on OU and account paths.

Implementation example

The AWS SRA code library provides a sample implementation of Account Alternate Contacts. This solution sets the billing, operations, and security alternate contacts for all accounts within an organization.

Phase 2: Implement a strong identity foundation

As soon as you have created multiple AWS accounts, you should give your teams access to the AWS resources within those accounts. There are two general categories of identity management: workforce identity and access management and customer identity and access management (CIAM). Workforce IAM is for organizations where employees and automated workloads need to log into AWS to do their jobs. CIAM is used when an organization needs a way to authenticate users to provide access to the organization’s applications. You need a workforce IAM strategy first, so your teams can build and migrate applications. You should always use IAM roles instead of IAM users to provide access to human or machine users. Follow the AWS SRA guidance on how to use AWS IAM Identity Center within the Org Management and Shared Services accounts to centrally manage single sign-on (SSO) access to your AWS accounts. The guidance also provides design considerations for using IAM federation when you cannot use IAM Identity Center.

As you work with IAM roles to provide user access to AWS resources, you should use AWS IAM Access Analyzer and IAM access advisor as outlined in the Security Tooling and Org Management sections of this guide. These services help you achieve least privilege, which is an important preventive control that helps you build a good security posture.

Design consideration
  • To achieve least privilege, design processes to regularly review and understand the relationships between your identities and the permissions they require to function properly. As you learn, fine-tune those permissions and gradually trim them down to the least permissions possible. For scalability, this should be a shared responsibility between your central security and application teams. Use features such as resource-based policies, permission boundaries, attribute-based access controls, and session policies to help application owners define fine-grained access control.

Implementation examples

The AWS SRA code library provides two sample implementations that apply to this phase:

  • IAM Password Policy sets the account password policy for users to align with common compliance standards.

  • Access Analyzer configures an organization-level analyzer within a delegated administrator account and an account-level analyzer within each account.

Phase 3: Maintain traceability

When your users have access to AWS and start building, you will want to know who is doing what, when, and from where. You will also want visibility into potential security misconfigurations, threats, or unexpected behaviors. A better understanding of security threats enables you to prioritize the appropriate security controls. To monitor AWS activity, follow the AWS SRA recommendations for setting up an organization trail by using AWS CloudTrail and centralizing your logs within the Log Archive account. For security event monitoring, use AWS Security Hub, Amazon GuardDuty, AWS Config, and AWS Security Lake as outlined in the Security Tooling account section.

Design consideration
  • As you start using new AWS services, make sure to enable service-specific logs for the service and store them as part of your central log repository.

Implementation examples

The AWS SRA code library provides the following sample implementations that apply to this phase:

  • Organization CloudTrail creates an organization trail and sets defaults to configure data events (for example, in Amazon S3 and AWS Lambda) to reduce duplicating the CloudTrail that’s configured by AWS Control Tower. This solution provides options for configuring management events.

  • AWS Config Control Tower Management Account enables AWS Config in the Management account to monitor resource compliance.

  • Conformance Pack Organization Rules deploys a conformance pack to the accounts and specified Regions within an organization.

  • AWS Config Aggregator deploys an aggregator by delegating administration to a member account other than the Audit account.

  • Security Hub Organization configures Security Hub within a delegated administrator account for the accounts and governed Regions within the organization.

  • GuardDuty Organization configures GuardDuty within a delegated administrator account for the accounts within an organization.

Phase 4: Apply security at all layers

At this point, you should have:

  • The appropriate security controls for your AWS accounts.

  • A well-defined account and OU structure with preventive controls defined through SCPs and least privilege IAM roles and policies.

  • The ability to log AWS activities by using AWS CloudTrail; to detect security events by using AWS Security Hub, Amazon GuardDuty, and AWS Config; and to perform advanced analytics on a purpose-built data lake for security by using Amazon Security Lake.

In this phase, plan to apply security at other layers of your AWS organization, as described in the section, Apply security services across your AWS organization. You can build security controls for your networking layer by using services such as AWS WAF, AWS Shield, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM), Amazon CloudFront, Amazon Route 53, and Amazon VPC, as outlined in the Network account section. As you move down your technology stack, apply security controls that are specific to your workload or application stack. Use VPC endpoints, Amazon Inspector, Amazon Systems Manager, AWS Secrets Manager, and Amazon Cognito as outlined in the Application account section.

Design consideration
  • As you design your defense in depth (DiD) security controls, consider scaling factors. Your central security team won’t have the bandwidth or full understanding of how every application behaves in your environment. Empower your application teams to be responsible and accountable for identifying and designing the right security controls for their applications. The central security team should focus on providing the right tools and consultation to enable the application teams. To understand the scaling mechanisms that AWS uses to adopt a more shift-left approach to security, see the blog post How AWS built the Security Guardians program, a mechanism to distribute security ownership.

Implementation examples

The AWS SRA code library provides the following sample implementations that apply to this phase:

  • EC2 Default EBS Encryption configures the default Amazon Elastic Block Store (Amazon EBS) encryption in Amazon EC2 to use the default AWS KMS key within the provided AWS Regions.

  • S3 Block Account Public Access configures the account-level Block Public Access (BPA) settings in Amazon S3 for accounts within the organization.

  • Firewall Manager demonstrates how to configure a security group policy and AWS WAF policies for accounts within an organization.

  • Inspector Organization configures Amazon Inspector within a delegated administrator account for accounts and governed Regions within the organization.

Phase 5: Protect data in transit and at rest

Your business and customer data are valuable assets that you need to protect. AWS provides various security services and features to protect data in motion and at rest. Use AWS CloudFront with AWS Certificate Manager, as outlined in the Network account section, to protect data in motion that’s collected over the internet. For data in motion within internal networks, use an Application Load Balancer with AWS Private Certificate Authority, as explained in the Application account section. AWS KMS and AWS CloudHSM help you provide cryptographic key management to protect data at rest.

Phase 6: Prepare for security events

As you operate your IT environment you will encounter security events, which are changes in the everyday operation of your IT environment that indicate a possible security policy violation or a failure of security control. Proper traceability is critical so that you are aware of a security event as quickly as possible. It is equally important to be prepared to triage and respond to such security events so that you can take proper action before the security event escalates. Preparation helps you triage a security event quickly to understand its potential impact.

The AWS SRA, through the design of the Security Tooling account and the deployment of common security services within all AWS accounts, provides you with the ability to detect security events across your AWS organization. AWS Detective within the Security Tooling account helps you triage a security event and identify the root cause. During a security investigation, you have to be able to review relevant logs to record and understand the full scope and timeline of the incident. Logs are also required for alert generation when specific actions of interest happen.

The AWS SRA recommends a central Log Archive account for immutable storage of all security and operational logs. You can query logs by using CloudWatch Logs Insights for data that’s stored in CloudWatch log groups, and Amazon Athena and Amazon OpenSearch Service for data that’s stored in Amazon S3. Use Amazon Security Lake to automatically centralize security data from the AWS environment, software as a service (SaaS) providers, on premises, and other cloud providers. Set up subscribers in the Security Tooling account or any dedicated account, as outlined by the AWS SRA, to query those logs for investigation.

Design considerations
  • You should start preparing to detect and respond to security events from the very beginning of your cloud journey. To better utilize limited resources, assign data and business criticality to your AWS resources so that when you detect a security event you can prioritize the triage and response based on the criticality of the resources involved.

  • The phases for building your cloud security architecture, as discussed in this section, are sequential in nature. However, you don’t have to wait for the full completion of one phase before you start the next phase. We recommend that you adopt an iterative approach, where you start working on multiple phases in parallel and evolve each phase as you evolve your cloud security posture. As you go through the different phases, your design will evolve. Consider tailoring the suggested sequence shown in the following diagram to your particular needs.


        Sequential and iterative phases in building a cloud security
          architecture
Implementation example

The AWS SRA code library provides a sample implementation of Detective Organization, which automatically enables Detective by delegating administration to an account (for example, Audit or Security Tooling) and configures Detective for existing and future AWS Organizations accounts.