It is critical to prevent root user access from getting into the wrong hands and to be aware whenever root user activity occurs in your AWS account. Here are some of the key recommendations include:
- Avoid using Root account.
- All IAM users including Root account must be enabled multi factor authentication (MFA)
- Abnormal activities (many failed sign-in attempts, ...) must be detected and notified
However, there are certain actions that can only be performed by the root user. To be certain that all root user activity is authorized and expected, it is important to monitor root API calls to a given AWS account and to notify when this type of activity is detected. This notification gives you the ability to take any necessary steps when an illegitimate root API activity is detected or it can simply be used as a record for any future auditing needs
In order to to comply best practices above, this post I walk through a solution that tracks and notifies on root user activities and abnormal sign-in activities for an AWS account.
- Tracking all sign-in and related activities
- Be notified/alerted whenever Root account sign-in
- Be notified/alerted whenever an IAM user sign-in without MFA
- Be notified/alerted if the number of failed sign-in of an IAM user greater than 3 in the last hour
- Create and enable a multi-region AWS CloudTrail trail for all AWS regions
The picture below shows a high-level architecture of the solution
- IAM users and/or Root account sign-in to either Web Console or Mobile Console
- That sign-in activity is captured and tracked by Cloud Trail
- A Cloud Trail event is sent to Event Bridge automatically
- Event Bridge triggers a state machine in Step Function
- The state machine process the event and send a message SNS topic if needed
- SNS with a Lambda function subscribed to the topic will send appropriate notifications Slack
Here are details of the state machine - the main part of the solution
At the first step in the above state machine, the activity is stored in a DynamoDB table. The reason for storing is that we will need historical data of a user for other purposes such as security audits in the future, investigating security issues, etc. We also need it for a later step in the state machine (
Count failed sign-in attempt) to determine an alert should be sent or not.
The DynamoDB table is designed (hash key, partition key, indexes, etc.) to store not only sign-in activities but also other kinds of activities. This will help us easily to extend the solution in the future.
At the last steps of the state machine, send alert steps, SNS publish tasks are used instead of Lambda tasks is because we don't want to duplicate sending alert code. A centralized Lambda function that is subscribed to SNS topic will do sending messages to Slack via an incoming webhook.
1. Root sign-in
2. Sign-in successful but no MFA used
3. Sign-in failed but not more than 2 attempts
4. More than 2 failed sign-in attempts
5. Sign-in successful and MFA used
6. Not sign-in activity
Top comments (1)
Deploy the solution by CDK: github.com/devsecops-studio/aws-ac...