Building your security architecture – A phased approach

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).

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.

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.

Phase 4: Apply security at all layers

At this point, you should have:

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.

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.