Build a secure AWS foundation in under 60 minutes: A guide for public sector organizations

Innovators choose Amazon Web Services (AWS) to quickly build prototypes and solutions that turn into fully-fledged products utilized by thousands—or, in some cases, millions—of users in the US and around the world. As a solutions architect working with public sector technology startups and independent software vendors (ISVs) in the government technology space, I noticed that no matter the size of a company, activities of first order are typically focused on application development and minimizing time-to-market. With that, multi-account strategy and foundational best practices can often be overlooked.

In this blog, I will guide you through the process of setting up a secure multi-account AWS environment using AWS Control Tower, AWS IAM Identity Center, and AWS Organizations and will show you how to secure your environment using AWS Config, AWS Security Hub, and Amazon GuardDuty. By spending a little bit of time upfront to build a strong foundation you can save significant time down the road and prevent potential security risks.

You might wonder: how long does it take to deploy a secure AWS foundation? My answer—it can be done in under 60 minutes! If you follow the steps that I outlined below, you will end up having a secure environment that is easily accessible by authorized users—with centrally managed multi-account organization and policies—that allow you to grow your organization without increasing management complexity. After implementation, you will sleep better at night, knowing you have a secure, scalable, and cost-effective governance strategy in place. So, let’s get started!

Prerequisites

If you are brand new to AWS, start by creating AWS account. When you create a new account you have to provide an email address for the root user. Follow the root user best practices and take note of these important points:

• Use an email alias for root users—so that you can re-direct to a person or a group of people that will take the ultimate control of your environment.
• Secure your root account by enabling multi-factor authentication (MFA) for root user access.
• Use the root user only for management tasks that require root user access.
• Create an AWS Identity and Access Management (IAM) user with administrative privileges to manage your environment and perform daily administration tasks.
• Do not deploy any solutions or run any workloads in your root account.
• Do not create AWS access keys that could be used for API calls.

If you have been working with AWS for a while, you may already have workloads running in your root account. If you are one of the customers that happen to have development, testing, or production workloads running in your root account, then the best path forward is to create a new root account and setup a new organization using that account. Once the new organization is deployed, you can migrate your old root account as a member account to your new organization. To make your foundation more secure, I would also recommend to further separate development, test, and production workloads into distinct accounts and group them under the appropriate organizational unit (OU), as described in the best practices for multi-account strategy.

If you already have an existing organization that you manage with AWS Organizations, you can still deploy a landing zone using AWS Control Tower from your organization’s management account following steps outlined in this blog post, just consider the effects of extending governance to your existing organization.

Set up a landing zone with AWS Control Tower deployment

There are many benefits that multi-account strategy provides, such as an isolation boundary for your workloads, independent service quota management per account, ability to centrally manage security and account access, ability to manage budgets, savings plans, and billing from a management account— just to name a few. You can read more on AWS multi-account strategy later, but now let’s focus on building a multi-account secure environment, as outlined in the Security pillar of the AWS Well-Architected Framework.

We will start by deploying a landing zone using AWS Control Tower. A landing zone is a multi-account AWS environment that is scalable and secure, with an organization that is managed from a management account in AWS Organizations. A fully deployed landing zone is shown in the following diagram.

Figure 1. Diagram that shows the structure of a deployed landing zone provisioned by AWS Control Tower

As you see in the preceding diagram, AWS Organizations will be used to build a hierarchy of OUs. An OU is a logical grouping of accounts in an organization that helps organize accounts into a desired hierarchy and apply management controls. AWS Control Tower will also deploy IAM Identity Center, which enables users to access multiple accounts easily from a central web portal page. If you are a using third-party identify provider, IAM Identity Center can also provide Single-Sign-On (SSO) federation to external Identity Providers.

Planning phase for the AWS Control Tower deployment

There are a few critical elements that you need to decide on prior to starting AWS Control Tower deployment:

1. Choose your home AWS Region for the deployment. For that I recommend selecting the Region that will have majority of your data or will host your applications.
2. Prepare two additional email addresses—one for a Log Archive account and second for an Audit account. For both of these emails use alias emails that can be forwarded to a responsible party in your organization who will handle security and audit aspects.
3. Decide if you want to allow AWS Control Tower to set up an organization-level CloudTrail trail and manage it for you. If you want to enable it “Opt in” during deployment.
4. Decide on your log retention policy. By default, the logs will be stored for one year, but you can adjust that duration during the setup.
5. Decide if you want to encrypt your resources. If you choose to encrypt, specify an encryption key that will be used for encryption.

AWS Control Tower deployment process

Now that you have planned for AWS Control Tower deployment, sign in to your new root account as a user with administrative permissions using AWS Management Console, search for AWS Control Tower service, and start the deployment of AWS Control Tower. Provide the required information for AWS Control Tower deployment that you prepared above, click start, and then sit back and relax.

AWS Control Tower deployment screen will notify you that it will take approximately 60 minutes to set up your landing zone. In reality, it takes about half of that time to deploy a landing zone into a new root account. Deployment time, however, can vary for different environments—as it depends on the number of deployed resources.

Deployment result

During the setup, AWS Control Tower creates an organization with two OUs: Sandbox OU and Security OU. The Sandbox OU is intended for hosting your development and experimental accounts. The Security OU contains two shared accounts: Log Archive and Audit accounts.

The Log Archive account will act as a consolidation point for log data that is gathered from all the accounts in the organization and will be primarily used by security, operations, audit, and compliance teams. This account contains a centralized storage location for copies of AWS Config and CloudTrail logs, as well as application and operating system logs.

The Audit account, also known as the security tooling account, is used to provide centralized delegated admin access to AWS security tooling and consoles, as well as provide view-only access for investigative purposes into all accounts in the organization.

Once the landing zone deployment is completed, you will see a confirmation screen.

Figure 2. AWS Control Tower deployment confirmation screen

Quick note on the Audit account: it should be restricted to authorized security and compliance personnel only. This account is an aggregation point for AWS security services, including AWS Security Hub, Amazon GuardDuty, Amazon Macie, AWS Config,  AWS Firewall Manager, Amazon Detective, Amazon Inspector, and IAM Access Analyzer.

Manage your organizational structure

Once the landing zone is deployed you can create your final organizational structure in accordance with best practices for managing organizational units with AWS Organizations. It’s recommended to add additional OUs for external-facing applications, such as the Workloads OU. You are also encouraged to create Software Development Life Cycle (SDLC) OUs to separate your development, test, and production environments. At the end of the day, your final organizational structure should be based on your security and operational needs and not necessarily mirror your org chart.

The following diagram shows an organizational structure in AWS Organizations with management account, OUs, member accounts, and policies.

Figure 3. Diagram of an organizational structure in AWS Organizations

Adding new OUs

It is recommended that you have a clean separation between production and non-production accounts. To achieve this, you can create a new OU called Production for grouping accounts that host production workloads. Many public sector ISVs tend to separate their production workloads by putting workloads into separate accounts, when dealing with customers that require clear delineation of resources. These production accounts can be grouped together in a Production OU or customer-specific Production OUs. In a similar fashion, consider grouping your testing and development accounts, by creating Testing and Development OUs to separate these accounts in your organization.

Adding new accounts

If you need to create a new account in your landing zone, you can use AWS Control Tower Account Factory. To create a new account, provide an account email, user name, and user email associated with the new account and an OU that account will belong to—as shown in the following screenshot.

Figure 4. AWS Management Console screenshot that shows the creation of a new account

You can then easily manage, update, and close accounts that you created from AWS Control Tower’s Account factory.

Manage your organization using policies and controls

There are multiple policies in AWS Organizations that can be used to manage your organization. These polices can broadly be grouped into two categories: Authorization and Management policies. Authorization policies help you to centrally manage the security of AWS accounts across an organization. Management policies help you centrally configure and manage AWS services and their features across an organization.

AWS Control Tower also implements preventive, detective, and proactive controls that help you govern your resources and monitor compliance across groups of AWS accounts. By default, AWS Control Tower enables Preventive and Detective controls for the new organization. A control is a high-level rule for ongoing governance of your overall AWS environment, which is expressed in plain language.

Managing user permissions with a Service Control Policy (SCP)

In this section, I will show how you can manage users’ permissions at scale with service control polices (SCPs). SCPs are part of the Authorization policies that can be enabled on the OU level. SCPs can provide significant time savings when you use them to manage multiple accounts and users within your organization.

One best practice is to restrict access to AWS services in all Regions where you don’t anticipate running your workloads. That’s where you can implement SCPs to limit user permissions or actions for particular services and Regions. For example, in your Development OU accounts, you can allow developers to spin up Amazon Elastic Compute Cloud (Amazon EC2) instances of a particular size and in certain Regions, while prohibiting spinning high-cost EC2 instances in other Regions.

The following code example shows such an SCP:

{

    "Version": "2012-10-17",

    "Statement": [

        {

           "Sid": "AllowSpecificEC2InstanceTypesInSpecificRegions",

            "Effect": "Deny",

            "Action": "ec2:RunInstances",

            "Resource": "arn:aws:ec2:*:*:instance/*",

            "Condition": {

                "StringNotEquals": {

                    "ec2:InstanceType": [

                        "t3.micro",

                        "t3.small",

                "t3.medium"

                    ]

                }

            }

        },

        {

            "Sid": "DenyEC2OutsideAllowedRegions",

            "Effect": "Deny",

            "Action": "ec2:*",

            "Resource": "*",

           "Condition": {

                "StringNotIn": {

                    "aws:RequestedRegion": [

                        "us-east-1",

                        "eu-west-1"

                    ]

                }

            }

        },

        {

            "Sid": "AllowAllOtherActions",

            "Effect": "Allow",

            "Action": "*",

            "Resource": "*"

        }

    ]

}

In this SCP, we restricted EC2 instance types to only t3.micro, t3.small, and t3.medium and limited EC2 operations to US East (N. Virginia) us-east-1 and Europe (Ireland) eu-west-1 Regions, allowing all other AWS actions. Having this SCP can help reduce costs associated with EC2 instances and, in the event of a malicious user, will prevent spinning high-cost EC2 instances that could be used for crypto-mining.

Please note that AWS strongly recommends that you don’t attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. So go ahead and test SCPs first on a test account before applying them to an OU or the whole organization.

Set up user access with IAM Identity Center

As part of AWS Control Tower deployment, IAM Identity Center is deployed. IAM Identity Center uses a built-in directory for storing users’ information, but you can also incorporate your current identity provider (for example, Okta, Microsoft Entra Id, or Ping Federate) and enable single sign-on capabilities to sign users in to AWS accounts and third-party SaaS applications that appear in the portal.

IAM Identity Center provides an access portal link for the users to sign in with a user name and password. Once logged in, a user will be taken to a personalized web user portal that shows AWS accounts that the user can access and user’s assigned roles for each account.

With IAM Identity Center, users no longer need to keep track of multiple account credentials to AWS accounts and applications that they need to access. To configure user access, an administrator will configure permissions sets that define permissions (IAM policies to perform specific job functions), and assign them to individual users or groups that are mapped to specific accounts that users need to access.

Figure 5. AWS access portal that shows accounts within organization that a user has access to. The user can login to dev-account with AWSAdministratorAccess permissions, but only has AWSReadOnlyAccess permissions for the Audit and Log Archive accounts

Follow best practices recommendations by enabling MFA for IAM Identity Center users. Optionally, you can add SCPs to require MFA for operations initiated by users via API, terminal, and console.

Implementing security and compliance with AWS Security Hub

To further strengthen the security posture of your environment, activate AWS Security Hub and enable relevant security standards, such as AWS Foundational Security Best Practices (FSBP), Center for Internet Security (CIS) Foundations Benchmark, and National Institute Of Standards and Technology (NIST) SP 800-53. The standards will be used by AWS Config to monitor resources and evaluate their compliance across your organization. AWS Security Hub will notify you when resources are not in compliance with the enabled best security practices and standards.

AWS Security Hub is a central hub for displaying security findings for all accounts in your organization. AWS Security Hub provides a single pane of glass into your compliance and calculates a security score for your overall security posture and compliance across your organization. You can also check the security score for each account and print out or download a security report.

Figure 6. AWS Security Hub Security score

One of the main best practices for AWS Security Hub is to designate your Audit account as your delegated AWS Security Hub administrator. That account will be used to manage AWS Security Hub and findings across all AWS Organizations member accounts. Check these recommended standards as the default selections when enabling AWS Security Hub.

Improving security with Amazon GuardDuty

Amazon GuardDuty is a threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs in your AWS environment. GuardDuty uses threat intelligence feeds, such as lists of malicious IP addresses and domains, file hashes, and machine learning (ML) models to identify suspicious and potentially malicious activity in your AWS environment.

To bolster the security of your AWS environment and provide protection against malware, I recommend enabling Amazon GuardDuty using the Audit account that was created during AWS Control Tower deployment.

Figure 7. AWS GuardDuty summary of security findings

GuardDuty protects Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Simple Storage Service (Amazon S3), Amazon EC2, Amazon Relational Database Service (Amazon RDS), and AWS Lambda and sends findings to AWS Security Hub—where you can check security findings and act on them. The findings can include detections of compromised and exfiltrated AWS credentials, data exfiltration, unusual patterns of login events in the supported engine versions of Amazon Aurora and Amazon RDS databases, unauthorized crypto-mining activity and the presence of malware, operating system-level, networking, and file events that indicate unauthorized behavior on EC2 instances and container workloads.

Now we should be done, and hopefully we stayed under 60 minutes! Remember that you can always go back to your AWS Security Hub and Amazon GuardDuty services and tweak your settings later.

A quick recap of activities

Let’s do a quick recap of activities that we have accomplished so far:

1. We deployed AWS Control Tower, which created a landing zone, with an organization in AWS Organizations with Sandbox and Security OUs, and two shared accounts: a Log Archive to keep records of logs and an Audit account to manage security tools.
2. We deployed IAM Identity Center, which provides access to a portal where users can switch between accounts based on their access permissions.
3. We enforced MFA for all users that sign in to AWS accounts.
4. We enabled SCPs to control EC2 instance types and Regions that can be used.
5. We deployed AWS Security Hub to use as a single pane of glass into your security posture.
6. We enabled compliance checks with security best practices and benchmarks (FSBP, CIS, NIST).
7. We deployed AWS GuardDuty to protect resources from malware and malicious activity.

Conclusion

In this blog post, I introduced you to the best practices for building a secure AWS foundation. By following the practical steps outlined in this post, you will be able to deploy AWS Landing Zone with a multi-account structure using AWS Control Tower in approximately 60 minutes. AWS Organizations will provide control and centralized management capabilities for creating new accounts and managing existing accounts while enabling centralized management using SCPs and control libraries.

Users of your AWS accounts will have a central login page, which will allow for a fast contextual switching between different accounts. Deployment of Amazon GuardDuty will further improve your security posture and protect your workloads against malware and security threats, and AWS Security Hub will provide a single pane of glass into your overall security and compliance with the best security practices.

As your organization matures and grows, you can further strengthen the security of your AWS environment by running security assessments and automating security response and remediation. But to get started today, follow the steps and best practices outlined in this post, and you will be in a much better place with a solid and secure multi-account foundation that you can scale in the future.