*AWS account required
Use Case:
Before we get started…Security is important to earn the trust of your clients and providers. Security is mandatory to protect your client’s resources and assets. Each one of these activities can be completed over a few days.
Setting up a multi-account strategy
It is AWS’s best practice to have your master root account as your billing account and recommend that you not provision any resources under the root account. So what we will do is create a user with admin privileges under each of our master accounts in our organization.
Under the master account, you will create an IAM user.
Click Add user
Click Manage console access here (normally I would click both but for this example only Mgt. Console)
Click Next all the way through until you see the link where you can sign in as this user. Bring the link up in a new tab but do not sign in yet. We have a few more steps before signing in.
Next, we will invite another master account as a member of our organization.
Navigate to AWS Organizations
Click Add account then on the next screen invite account. You will see above I have already completed this step and added another account. You will receive an email in your primary (with the star) email account about the member account being added.
You will then sign in as your member account and accept the invite.
In your secondary or member account, you will also create a user (with a different name so we don’t get confused) with admin permissions.
(NOTE: IF you have created access keys, record them down in a safe and secure place following AWS best practices. Also using MFA — multi-factor authentication. To make this lab quicker I will not be generating either but I encourage you to do so)
This next step can get confusing for beginners so I will provide the AWS documentation below for your reference:
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html
Next, we will create an IAM role under our member account (witcherinvestments) that will allow us to attach that role to our member account. Enter in the account ID the incoming account number (bmwitcher). Click next (AWS best practice is to enable MFA or greater)
Then click create role.
Give admin access.
Now copy the link for future use as we will be signing out and back in under our master account, under the user securityadmin.
Click on switch role under the username on the top right of your screen.
Using the incoming account id (witcherinvestments) Now click switch role.
*We have now done the first step on our quest for account security.
As you create roles for your users make sure 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 if assigned improperly.
Next, 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 accessing this account will have read-only access.
,,
Creating a Data Bunker: Using S3 & Cloudtrail
First, ensure that you still have the set up in the aforementioned section with cross-account roles. In this example, bmwitcher is the (master account) where you will see the adminuser account and witcherinvestments is the secondary account with “assume role” permissions that will serve as our security role.
Now we will navigate to the S3 bucket and click “create bucket”
Next, we will name our bucket copy it to your clipboard for future use.
Click Next all the way through until you return the main S3 console, ensuring that public access is blocked.
Press the bucket we just create and navigate to the Properties tab
Even though we are tearing this lab down immediately upon completion, Under Object Lock, enable compliance mode and set a retention period. The length of the retention period will depend on your organizational requirements. If you are enabling this just for baseline security start with 31 days to keep one month of logs. Note: You will NOT be able to delete files within this window or the bucket if objects still exist in it
Since I am deleting this lab upon completion yours will read 31 days whereas mine says 1 if you are keeping this lab for use in the workplace.
Under the Permissions tab, replace the Bucket Policy with the following, replacing [bucket] and [organization id — you can find this by navigating to the AWS Organization service]. Press Save
*Note copy and paste the below policy and remove the bracket where you see [bucket] & [organization id]
{
“Version”: “2012–10–17”,
“Statement”: [
{
“Sid”: “AWSCloudTrailAclCheck20150319”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudtrail.amazonaws.com”
},
“Action”: “s3:GetBucketAcl”,
“Resource”: “arn:aws:s3:::[bucket]”
},
{
“Sid”: “AWSCloudTrailWrite20150319”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudtrail.amazonaws.com”
},
“Action”: “s3:PutObject”,
“Resource”: “arn:aws:s3:::[bucket]/AWSLogs/*”,
“Condition”: {
“StringEquals”: {
“s3:x-amz-acl”: “bucket-owner-full-control”
}
}
},
{
“Sid”: “AWSCloudTrailWrite20150319”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudtrail.amazonaws.com”
},
“Action”: “s3:PutObject”,
“Resource”: “arn:aws:s3:::[bucket]/AWSLogs/[organization id]/*”,
“Condition”: {
“StringEquals”: {
“s3:x-amz-acl”: “bucket-owner-full-control”
}
}
}
]
}
Next we will add a life cycle policy to clean up old logs. Navigate to Management
Add a life cycle rule named Delete old logs, press Next
Add a transition rule for both the current and previous versions to move to Glacier after 32 days. Press Next
Select the current and previous versions and set them to delete after 365 days
Click Next and Save.
*NOTE: I will be skipping the step below because I do not have AWS GuardDuty or SecurityHub enabled. However, switching back to the root account of the organization you should ensure that your security team only has ReadOnly Access (IAM) so that no changes can be made to the data bunker. Human Access should only occur in an emergency.
Next we will navigate to CloudTrail from the Root Account
Then press “Create Trail”
Enter in the trail name “OrganizationTrail”
And make sure “Apply trail to my organization” is checked “Yes”
You can Verify the logs by:
- Switch back to the Security account (witcherinvestments)
- Navigate to the S3 bucket previously created (securitybunker0627)
- You can start to explore the CloudTrail logs
While there are many other steps you can take to ensure high levels of security the below steps will end this quest by using AWS Organizations to use SCPs (service control policies) to prevent an organization member/account from disabling CloudTrail.
Service Control Policies
AWS Organization 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.
Walkthrough for a non-control tower environment
If you are not leveraging Control Tower it is strongly recommended that you implement the below service control policy to prevent AWS CloudTrail from being disabled.
- 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
{
“Version”: “2012–10–17”,
“Statement”: [
{
“Effect”: “Deny”,
“Action”: “cloudtrail:StopLogging”,
“Resource”: “*”
}
]
}
- 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
Note: AWS Control Tower already includes a mandatory guard rail preventing this but we did not use it in this example.
