Amazon Macie Configuration
Amazon Macie was launched in the summer of 2017, much to the delight of cloud security engineers. Amazon Macie is a powerful security and compliance service that provides an automatic method to detect, identify, and classify data within your AWS account. Macie currently supports Amazon S3 storage, however additional support for other storage systems will be developed and added over time. Backed by machine learning, Macie can actively review your data as different actions are taken within your AWS account. Machine learning spots access patterns and analyzes user behaviour using CloudTrail event data to alert against any unusual or irregular activity. Any findings are presented within a dashboard which can trigger alerts allowing you to quickly resolve any potential threat of exposure or compromise to your data.
This course will dive into all elements of the service, discussing its many different features and customizable elements allowing you to gain the maximum potential of its ability.
By the end of this course you will be able to:
- Provide an understanding and awareness of what Amazon Macie is and what it’s used for
- Provide an explanation of each configurable component of the service to allow you to gain maximum benefit from Macie’s capabilities
- Understand how the service can provide a customizable approach to maintaining compliance
- Understand how through automation and machine learning Amazon Mazie detects and categorizes S3 content to detect potential security threats and exposures
The content of this course is centered around security and compliance. As a result, this course is beneficial to those who are in the roles or their equivalent of:
- Cloud Security Architects
- Compliance Managers
- Cloud Administrators
- Cloud Support & Operations
As a prerequisite of this course you should have an understanding and awareness of:
- Amazon S3
- AWS CloudTrail
Hello and welcome to this lecture covering users. I want to define how Amazon Macie classifies users and the different user types available that I briefly mentioned in the previous lecture when looking at the CloudTrail User identity types within the dashboard. Let me first start out by talking about the users section within the console. You may recognize the platinum, gold, silver, and bronze categories which are always present on the dashboard. But this users screen provides additional information surrounding this metric. This screen essentially shows the different users that have been identified via CloudTrail data when linking to API calls. Depending on the history of those users will dictate how Amazon Macie classifies them between these four category ratings which ultimately reflect the level of perceived risk that those users pose. Let me define the differences between these categories a bit further.
Platinum. A user or role placed within this category is considered to make regular high risk API calls such as DeleteFlowLogs or UpdateTrail. These can often be contributed to users with administrative privileges, such as the root account. Due to the amount of control and elevated permissions these users pose, you should monitor their activity for any signs of compromise.
Gold. Users or roles categorized as gold will have been identified through their use of calling and making API requests relating to infrastructure changes, such as CreateRouteTable or RequestSpotinstances. Again, due to the permission level of these power users, they should also be monitored to ensure that they are not compromised in any way.
Silver. As we progress down the track, users or roles in the silver category are identified as performing medium level risk API calls. Remember, these risk levels are managed by Amazon Macie and automatically assigned these risk levels to the API calls. As an example, a medium level risk API could be DescribeRouteTables or ListObjects.
Bronze. Users or roles in this category provide the lowest level of risk due to history of their API call usage, which may include API calls such as DescribeSubnets and DescribeHosts.
These categories give you a very quick visualization as to how many users are operating with potentially over-elevated permissions. This allows you to drill down into these users further to ascertain exactly what tasks they are performing. On the main page of the user screen, you'll see a list of users that Amazon Macie has identified. These users are categorized under the DLP, data loss prevention value column. It also provides a high level overview of the most recent activity, total events, errors, and unique IP addresses that have been attributed to that particular user. However, should you wish to investigate a particular user and gain further insight into events surrounding them, then you can click on their name within the user column. This will then provide you with a condensed version of the dashboard discussed in the previous lecture, with metrics and data that only relate to that user in question.
In this example, you may recognize the dashboard icons at the top where we have views relating to high-risk CloudTrail events, high-risk CloudTrail errors, activity location, CloudTrail events, activity ISPs, and CloudTrail user identity types. Again, these metrics in each view will only relate to events and data associated with that specific user. The last point I want to discuss in this lecture is how Amazon Macie defines user identity types, which is used in the main dashboard and the condensed dashboard for each specific user.
Amazon Macie identifies user identity types from the CloudTrail logs that it monitors and analyzes. Specifically using the user identity element from the events in the logs. The different user types are defined as follows.
- Root. This means that the request was initiated by the root account of your AWS account.
- IAM user. Here the request was made by an IAM user.
- Assumed role. This identity type defines that the request was made by credentials that were temporarily assumed having been obtained by calling the assumed role API for the security token service.
- Federated user. Here the request, again, was made with temporary credentials but this time from calling the AWS STS GetFederationToken API.
- AWS account. This simply defines that the request of the API was made by a different AWS account.
- AWS service. Here the request was made by an AWS service rather than a particular user.
That now brings me to the end of this lecture. Coming up next I will be discussing the research functionality of Amazon Macie.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.