First of all we have to define some terms: what is an overprivileged user and what are the problems for an organization with overprivileged users? A privilege can be defined as the ability to execute or control elements of your (IT) infrastructure or a special (IT) system. The owner of a privilege can use this for the daily work with the system. The owner may be a real person or an application. As an example think of a classical database application: there are at least three different groups of users with different roles:
- Database Administrators (DBA): they install, configure and administrate the database itself
- Application User: the applications on the server run with role
- Personal User: they query the database
In many IT systems the number of privileges decreases from DBA to application user to personal user. But do you know exactly which role in your IT system has which privileges and which user has which role? Especially in large cloud environments like AWS it is difficult to answer this question, as there are also a lot of permissions for containers, VMs and other infrastructure elements.
Principle of least privileges
If you are planning a (new) AWS environment, you may think of one of the following ways to grant your permissions:
- Give each user exactly the privileges he or she needs for the daily work. The problem here is, that you often do not know exactly, what permissions are needed at the time of setting up your environment. If new permissions are added over time or if previously not considered permissions must be added, this will lead to additional work during the lifecycle of your application.
- Give each user more privileges than actually needed.
The second way can be dangerous, as a user with overprivileged permissions may intentionally or unintentionally execute operations he or she should not be allowed to. Results may be data loss or serious harm of the infrastructure due to actions that should not actually be carried out. Sometimes the reason for overprivileged users is the hierarchical structure of a company. Managers may demand access to everything (“I am the boss, so I must be allowed to see and do everything”), even if they do not know what they are doing. Another reason for an accumulation of privileges may be the fact, that in small companies there are employees with a large number of tasks and responsibilities.
We at A&B recommend the “Principle of least privileges”, which says, that every (personal or system) user should only be able to access the information and resources, that are necessary for his legitimate purpose. So, what is the best way to find overprivileged users, that means users with permissions they have been granted but they do not need? In complex AWS environments, it is theoretically possible to search for and check overprivileged users manually, but this is hardly manageable in terms of time. To search for overprivileged users systematically, clients will need tool support for this task. CloudTracker is a tool, which helps clients find these users and roles by comparing CloudTrail logs with current IAM policies.
CloudTrail is an AWS service that helps clients monitor the activities in the accounts of AWS environments. It provides logging information concerning actions via console, SDKs, command line tools and other services. The CloudTrail logs thus provide the basic information when you are looking for users who have more permissions than necessary.
CloudTracker is an open-source tool, which was published 2018 by Duo Security. CloudTrail logs are the data source of CloudTracker, that means CloudTracker checks CloudTrail logs to find API calls initiated by an actor and compares these calls with the privileges that the actor has been granted. As a result, CloudTracker identifies overprivileged users and recommends revoking privileges based on their usage. The removal itself needs to be done manually afterwards.
Be aware of some limitations using CloudTracker. CloudTrail will not record all AWS API calls, for example data level actions are not recorded. As CloudTracker is based on CloudTrail, you must have this limitation in mind. Another aspect is the use of ElasticSearch or AWS Athena in CloudTracker: when CloudTracker was released in 2018, the CloudTrail logs had to be loaded into ElasticSearch. Although this is still possible using AWS Athena is an alternative for companies, who want to skip this additional step of copying large amount of log-data to ElasticSearch. AWS Athena is an interactive query service for analyzing data in Amazon S3 using standard SQL.
A detailed description of the setup of a CloudTracker installation can be found on GitHub. There are also some examples available in Github, which show the usage of the command-line-tool.
Let’s have a look at the initial example:
$ cloudtracker --account demo --list users --start 2018-01-01 alice - bob charlie
You have to specify the account and the starting date for the search in CloudTrail logs. “—list users” specifies, that a list of users is requested. Note the prefix “-“ of user “bob” in the output. This indicates, that the user bob was not found in the logs starting at 2018-01-01, so that the recommendation is to remove this user.
It is also possible to request roles instead of users by “—list roles”:
cloudtracker --account demo --list roles --start 2018-01-01 admin
While these initial examples only list users or roles, a more detailed analysis can be done for a special user or role:
cloudtracker --account demo --user alice ... cloudwatch:describealarmhistory cloudwatch:describealarms - cloudwatch:describealarmsformetric - cloudwatch:getdashboard ? cloudwatch:getmetricdata ... + s3:createbucket ...
This call lists all actions, that user alice can execute due to her privileges. Note that the output shown above is only a snippet. Most of the possible actions are not used. You can filter the output with “—show-used” to see only the used actions.
A key feature of CloudTracker is the ability to show the difference between the privileges granted and the privileges used. The prefix of each output line shows the diff-result:
- No prefix means: privilege was granted and used
- Prefix “-“ means: privilege was granted, but not used
- Prefix “?” means: privilege was granted, but it is unknown whether it was used, as the action is not recorded in CloudTrail (see the above mentioned limitations of the use of CloudTrail as data source)
- Prefix “+” means: the privilege was used, although it is not granted at the moment. This means, the privilege was granted when the action was performed and must have been removed in the meantime. You should think of granting this privilege again, if it was removed accidentally
Just get in touch with us and we will help you integrating CloudTracker in your security tools for monitoring your AWS environment.