There are scenarios where it makes sense to centrally manage your security deployments. Whether you just don't want to manage deployments across all of your AWS accounts or you want to follow an AWS Landing Zone or an AWS Control Tower best practice implementation, the necessity to scan multiple accounts may be one of your requirements.
Cross account scanning is achieved by linking "remote accounts" (non-deployment accounts) through the console and then deploying a cross-account role within each remote account. This is a very simple process which will allow the console to see all of the buckets for the linked account as it would for the deployment account ("primary"). All aspects of management and protection and feedback are the same after these steps have been completed. Both event-based and retro-scanning fully work with linked accounts so you can scan both your go-forward data as well as any existing data. You can link as many accounts as desired.
Accounts can be linked and then added in stages as you want to roll them out. So feel free to link all of your remote accounts and then activate them singularly or in groups. And you can always deactivate / reactivate accounts later on as needed.
The Manage Accounts page can look as follows. The deployment account is labeled as
Primary by default. Like any account though, that is a nickname and can be replaced if you see fit to be more meaninggful.
You can link another account by clicking the
Link Another Account button and filling in the
Account Number, the
Nickname and specifying which group the account will belong to. Then click the
Link Account button. If you'd like to link more at this same time, click the
Link Another Account button within the popup and repeat the process of entering the account number, nickname and group.
You may not be using Groups to organize your accounts. There is always one group created by default, the Primary group. In this situation you would specify Primary as the group value.
Deploying the Cross Account Role¶
After you click the
Link Account button, the fields will be replaced with a link to directly launch the CloudFormation Template to create the cross-account role. If you do not wish to launch the stack at this time, you can do so later, but will need the 3 values presented.
You will now see the newly added account listed in the account list. Note the Primary account reflects a bucket count and ProdAcct shows N/A. Once you run the cross-account CloudFormation Template you can mark the account as active. The Console will attempt to assume the role and you will either get a message indicating the role might still need to be created or the account will be marked as active and a bucket count will be reflected. You will know it worked when you see that number populated.
If the role cannot be assumed during activation, you will see the following message:
All actions are taken on individual accounts via the actions menu ellipses. You can launch the stack, change groups, activate the account and delete the account.
Launch Stack you will be directed to the AWS Console and right into the Stack creation wizard. If you are not already logged into the AWS Console, you will be prompted to login. Provide the credentials to the remote account you are linking. Then, just tick the box and click create.
Once the role is created head back to the Antivirus for Amazon S3 console and mark the account active from the action ellipses button. If you see the bucket count update you can feel confident the role is working appropriately. When you select to activate an account, you will see the button turn into a "spinner" while it is working.
Once complete the account will be shown as active and a bucket count provided.
At this time, the Bucket Protection page will reflect the new buckets found and distinguish them from the primary account by nickname.
All active accounts will be reflected throughout the rest of the console. All buckets from all accounts and all scan statuses will be shown. If you later deactivate a remote account (or even the primary) those buckets will not be reflected in the
Bucket Protection page, but the data scanned is still counted in metrics and any "problem files" found will be reflected on the
Problem Files page. Deactivating will also remove all event configuration from each bucket in the remote account.
Deleting an account will remove the account from the
Linked Accounts pages. All data scanned within that account will still be reflected in the metrics and billing.
Group functionality can also impact what you see from the linked accounts throughout the console.
If the role is deleted or changed in such a way in the linked account that the console can no longer assume it, the scanning agents will not be able to retrieve the objects and those objects will be reflected as
Error files in the
Problem Files page. The linked account buckets will still show on the
Bucket Protection page and the events will continue to be pushed to the queue, but we will continue to error out in processing those files until the role is fixed.