Auditing your Substrate-managed AWS organization
One of the very first things Substrate does is to configure AWS CloudTrail with a single trail that covers all organization accounts in all regions. To access this wealth of data, assume the
Auditorrole in your audit account.
On the command line:
substrate assume-role -special audit
Or you can assume the role in the AWS Console via your Intranet's Accounts page.
In either case, the data you seek is in the
<prefix>-cloudtrail(substituting your chosen prefix as stored in
substrate.prefix) S3 bucket. You can download it to analyze locally or query it with Amazon Athena. The most straightforward way to proceed is by creating Athena tables for each AWS account; partition projection to cover the entire organization is unsolved.
Many tools have grown the ability to assume an IAM role in your AWS account to perform some auditing or monitoring feature on your behalf. To allow these into your AWS organization, create an assume role policy in
substrate.Auditor.assume-role-policy.jsonwith contents like this:
You can include as many principals as you'd like in the innermost list.
Every time you update this file, you'll need to re-run whichever of
substrate create-admin-account(for each of your admin accounts), and/or
substrate create-account(for each of your service accounts) are relevant to your situation.
This will authorize third-party principals to
sts:AssumeRoleusing the ARN of one of your Auditor roles and operate as you would there.
Note, too, that this pattern can be applied to the Administrator role using the
substrate.Administrator.assume-role-policy.jsonfile per adding administrators to your AWS organization.