This quest is for you to improve your security posture. Every stakeholder involved in your organization and product or service is entitled to make use of a secure platform. Security is important to earn the trust with your customers and your providers. A secure environment also helps to protect your intellectual property. Each set of activities can be done in one day or split over a week in your lunch break. By the end of the quest we will have a set of accounts with security best practices applied, ready to develop your product in knowing that when you launch your workload you have secure foundations in place.
Implementing multiple accounts for our workload improves our security by limiting the blast radius of any potential breaches and separating our workload into discrete accounts.
Leverage AWS Organisations to create separate AWS accounts for a sandbox, your workload, a secure “data bunker” for audit logs and backups, and a shared services account for common tools. If you currently only have one account, create a new AWS account for your organisations master AWS account and invite your existing account to join as your sandbox AWS account.
By the end of this step you will have a separate AWS account for:
- Organisations root account – used only for identity and billing
- Shared services – for common tools such as deployment tooling
- Workload accounts – customers who have a single product will have a separate AWS account for each environment. If you have multiple workloads, or you rely on account separation for separation of customer data you will want to set up further accounts to reflect your structure
- Define your multi-account strategy. A suggested structure is shown below. If you do not current have AWS Organizations setup it is recommended that you use your existing account as a sandbox
- (If required) Sign up a new root account
- Create an AWS Organisations in the root account
- Invite any existing accounts
- For each AWS account required
- Create a new account in organisations. Make note of the organisations account access role.
- Create a new IAM role in the root account that has permission to assume that role to access the new AWS account
Every user must leverage unique credentials so we can trace actions within our accounts. Setup your identity structure in the master account and use cross account access to access the child accounts. As you create roles for your users ensure that you are implementing least privilege access by ensuring that users only have access to perform actions required for their role. Be careful who you give IAM permissions to as they can create their own permissions.
- Perform a credentials audit, add multi factor authentication to root and ensure that details are up to date
- Federate Identity leveraging a SAML provider
- Use cross account access roles to access the accounts that we setup in part 1.
Now we will create a data bunker account to store secure read only security logs and backups. In this step we will send our logs from CloudTrail to that account. The role for accessing this account will have read only access. Only ensure that this role can be accessed by those with a security role in your organisation.
AWS Organizations policies allow you to apply additional controls to accounts. In the examples given below these are attached to the root which will affect all accounts within the organization. You can also create specific service control policies for separate organizational units within your organization.
- Navigate to AWS Organization and select the Policies tab
- Click Create policy
- Enter a policy name for your policy and paste the policy JSON below into the policy editor
- Click Create policy
- Select the policy you have just created and in the right-hand panel select *roots
- Press Attach to attach the policy to your organizations root
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "cloudtrail:StopLogging",
"Resource": "*"
}
]
}This policy specifically enables only us-east-1 and us-west-1. Replace with the list of region codes you wish to allow access to.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws:RequestedRegion": [
"us-east-1",
"us-west-1"
]
}
}
}
]
}Amazon Simple Storage Service (S3) allows you to upload objects to a "bucket" which are then accessible depending on the access control list implemented. It is important to consider how you make data public. By blocking public access your team will have to be deliberate when it exposes data.
Note: The steps below apply at an individual account level. It is important to consider turning this on as you create additional accounts for your organization. At a minimum you should apply this to any account which hosts production data.
- For each account that you want to block public access to data stored in S3 - use a cross-account access role to block S3 public access
- Repeat the walkthrough in part 4 to apply the policy below. Instead of applying this policy to shit to the root, apply this specifically to the accounts where you have blocked public access.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"s3:PutBucketPublicAccessBlock",
"s3:PutAccountPublicAccessBlock"
],
"Resource": "*"
}
]
}Lastly, we will setup our foundations for monitoring the security status of our AWS environment and look at how we can build some basic alerting to security incidents. AWS Security Hub gives you a comprehensive view of the security of your account including compliance checks against best practices such as the Centre for Information Security AWS Foundational Benchmark. We will also enable Amazon GuardDuty - a threat detection service which leverages machine learning to detect anomalies across our AWS CloudTrail, Amazon VPC Flow Logs, and DNS logs.
- Find further information on the AWS website around AWS Cloud Security and in particular what your responsibilities are under the shared security model
- Read more on how permission boundaries and service control policies allow you to delegate access across your organization
- Understand the Well Architected Framework and how applying it can improve your security posture
Licensed under the Apache 2.0 and MITnoAttr License.
Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"). You may not use this file except in compliance with the License. A copy of the License is located at
http://aws.amazon.com/apache2.0/
or in the "license" file accompanying this file. This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.