Cross-account logging is a configuration in Amazon Web Services that allows users
to pipe CloudTrail log data from one account to another account's S3 bucket
There are many reasons why you'd want to set up centralized logging in your environment
From an information security perspective, you may want to limit access
to the logs from the users who created them. In this walk-through you'll set up
cross-account logging between two AWS accounts and create a cross-account role
In this example, the name of the account thats sending the logs will be called source
and the account that's receiving the CloudTrail logs into its S3 bucket will be called target.
At this point in the configuration it's assumed that the
CloudTrail and the S3 bucket on the target account are already enabled
Let's first configure the AWS target account. For this, start two different browsers.
This is required because AWS sessions cannot overlap.
So you cannot navigate between two AWS accounts in the same browser even on multiple tabs
Here we are using Chrome for the target account and Firefox for the source account
In browser one, open the AWS management console for the target account, the one that receives Cloud trail logs
In browser two, open the AWS management console for the source account
This is the account that sends its cloud trail logs to the target account
Let's start with the target account
This account is configured first because the policy on the S3 bucket must be modified to allow
the source account to write to it. When you create the CloudTrail in a source
account, you'll have to name the S3 bucket. Unless the policy has been
modified the Cloud trail creation process in the source account will not
recognize this S3 bucket in the target account and will therefore fail
The target account's S3 bucket will need to have a policy statement to allow the
source account CloudTrail service to put its log data into it
From Services in the target account navigate to Storage and select S3
When you select the bucket navigate to Permissions
and then Bucket Policy.
Here you'll see the policy. Make a copy of this existing
policy in case you need to revert to a working copy of the policy later
Look for the policy statement in the action of s3:PutObject. Below that you'll see a
resource statement with the target accounts account number.
You'll need to add an additional resource statement to include the source account number
Save it and if there are any syntax errors AWS will state that the policy contains invalid JSON
If this happens, try and find the error
or cancel your changes and restart or revert to the original policy you copied earlier
For every other AWS account, you'll repeat this process of copying
and pasting additional ARN statements and updating the account number
Save after each one to ensure that no syntax errors exist
Now that the target accounts S3 bucket has the correct policy statement to allow the source
account to send the CloudTrail logs, a cross-account role needs to be created
for the target account. Oracle CASB Cloud Service relies on each AWS account
to be able to read its own CloudTrail logs. To do this each source account must
assume the cross-account role to receive the correct entitlements to read the S3 bucket
Navigate back to Services and under Security Identity and Compliance select IAM.
From Roles create a new role and select Another AWS Account
This allows IAM users or roles you own to assume this cross-account role
Assuming the cross-account role grants the appropriate entitlements to the IAM user or role
in order to read the S3 bucket. Enter the source accounts account number
Then navigate to the next screen from where you can assign the permissions
Select the s3 read-only access policy
Give the role a name and then create it
Select the role you just created in Roles. Open the Trust Relationship screen.
This is the control that AWS uses to ensure only recognized source account
users and roles can assume this role on the target account.
Now edit the trust relationship
You can see that the principal is set for the source account
and the access is root. To adhear to the information security policy of
least privileged access, you'll want to change this to the ARN of the IAM role in the
source account that will be used to monitor the source AWS account
Edit it in the same way as you did for the policy on the S3 bucket for the source account
Instead of adding a resource statement which is what you're accessing
you'll need to add a principal statement which is who is accessing the resource
For each source account you will need to add a line. Remember to use square brackets and commas appropriately.
Then update the trust policy
Now the target account configuration is complete it's time to configure the source account
Login to your source AWS console to enable CloudTrail
Navigate to Services and under Management Tools select CloudTrail
Give the CloudTrail a name. Notice by default it's enabled for all regions and
is capturing all events.
Select No for create a new S3 bucket.
In the S3 bucket field enter the name of the target accounts S3 bucket and select the name of the bucket
S3 bucket names are globally unique and it is important to be exact
If AWS throws the error 'bucket doesn't exist', choose a different bucket
This means the policy on the targets S3 bucket is incorrect
So you would need to go back to the target S3 buckets policy to ensure it is configured correctly
If you used a log file prefix to change the
default location of the CloudTrail logs, make sure the policy ARN has the right
path in the target accounts S3 bucket policy. Create the CloudTrail.
This will take you to the CloudTrail service. You will see the CloudTrail you just created
and the name of the S3 bucket its piping is logs to.
Choosing the CloudTrail name will take you into the configurations page where you can
validate the settings of the CloudTrail. Here you can edit the configurations,
disable the cloud trail or delete it altogether.
Congratulations! You've configured cross account logging.
Thank you for watching.