Allan A. B. Thomsen - February 2021
Privileged Identity Management (PIM) is a security principle allowing users great flexibility and the security team, insight and control. When centrally managing enterprise cloud accounts with many different departments, PIM introduces the possibility to give the consumers the access needed AND still maintain security control and enforce corporate policies. PIM provides the ability to:
Provide just-in-time privileged access
Assign time-bound access to resources using start and end dates
Require approval to activate privileged roles
Enforce multi-factor authentication to activate any role
Use justification to understand why users activate
Get notifications when privileged roles are activated
Conduct access reviews to ensure users still need roles
Download audit history for internal or external audit
This is one of the areas where AWS does not have a managed offering as yet.
As security is at the top of Cloud Architects mind when designing modern and secure cloud architecture, this is a topic where a solution is needed. While working with enterprise customers and striking the balance between custom builds and managed services or easy to use and tightly locked down infrastructure. At CloudRemote.io, we feel the importance of giving the consumers of the cloud platform an agile, consumer-centric experience while at the same time ensuring traceability, security and enforcement of corporate polices. The solution described below ensures just that.
This gives the users just-in-time privileged access and the SOC (Security Operations Centre) team the ability to get notifications when privileged roles are activated, an option to do access reviews to ensure users still need roles, and audit history for internal or external audit.
Using AWS's Single Sign-On (SSO) service gives the IAM (Identity and Access Management) team the ability to control access to the AWS environments, handing out the roles needed for different teams to do their daily chores, using the least privilege principle. For emergency and “break glass” situations, IAM can, up front, hand out roles with more privileges than normally required, to enable the teams to firefight and fix issues swiftly, but SOC will also need to be notified, when it happens, to be able to verify that no malicious usage is taking place.
In AWS CloudTrail it is easy to find the usage of roles chosen, when users are logging in to the console. The event to look for is Federate from sso.amazonaws.com. It contains the name of the role chosen and the identity of the user requesting it.
This is a Federate event:
{
"eventVersion": "1.08",
"userIdentity": {
"type": "Unknown",
"principalId": "93670561d5-af3c1d08-6f6e-411c-8ffe-000000000000",
"accountId": "000000000000",
"userName": "allan@CloudRemote.io"
},
"eventTime": "2021-02-08T05:26:06Z",
"eventSource": "sso.amazonaws.com",
"eventName": "Federate",
"awsRegion": "eu-west-1",
"sourceIPAddress": "99.163.123.99",
"userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36",
"requestParameters": null,
"responseElements": null,
"requestID": "e7328f21-9538-45e0-84da-000000000000",
"eventID": "4c2242fc-f4dd-4748-8785-000000000000",
"readOnly": false,
"eventType": "AwsServiceEvent",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "000000000000",
"serviceEventDetails": {
"role_name": "AdministratorAccess",
"account_id": "000000000000"
}
}
To capture it you can either use a CloudWatch (CW) Rule, or a CW Metric filter, and connect it to an SNS Topic with an email subscription.
This is how the rule pattern looks if you choose a CW Rule:
This is how the metric filter looks if that is the approach you take:
The CW rules reacts quickly as the event passes through the CW event engine, while the metric filter has to wait for it to be logged and scanned (15-20 minutes)
For CLI access, the task is harder but not impossible. The challenge here is that the event, holding the role identification needed to spot CLI usage of a privileged role, is contained in a GetRoleCredentials call. Get, Describe and List calls are not passed through the CW event engine and thus not accessible for CW rules and thus immediate alerts. Fortunately CW metric filters can still be used to capture it, and combined with CW alarms we can get the same information, even though it comes with a slight delay.
The event to capture is:
{
"eventVersion": "1.08",
"userIdentity": {
"type": "Unknown",
"principalId": "93670561d5-af3c1d08-6f6e-411c-8ffe-000000000000",
"accountId": "000000000000",
"userName": "allan@CloudRemote.io"
},
"eventTime": "2021-02-08T10:33:07Z",
"eventSource": "sso.amazonaws.com",
"eventName": "GetRoleCredentials",
"awsRegion": "eu-west-1",
"sourceIPAddress": "99.163.123.99",
"userAgent": "aws-cli/2.0.62 Python/3.7.3 Linux/5.4.0-65-generic exe/x86_64.ubuntu.20 command/s3.ls",
"requestParameters": null,
"responseElements": null,
"requestID": "8f7a7c70-957c-4725-8491-000000000000",
"eventID": "60e4871c-22e7-4e2a-ae93-000000000000",
"readOnly": true,
"eventType": "AwsServiceEvent",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "000000000000",
"serviceEventDetails": {
"role_name": "AdministratorAccess",
"account_id": "111111111111"
}
}
You can create a matching filter pattern
Metric filters are best applied using Infrastructure as Code (IaC) to allow for automatic application of the filters and alarms. This CloudFormation template snippet shows you how it can be applied:
This approach makes it possible to monitor the usage of privileged roles, should you choose to make them available to users, for exceptional usage. It is a better alternative to using high privilege roles always.
Handing out relevant roles for daily tasks and a high privilege role for exceptional and monitored use, is a good balance between security and speed, for at least non production environments. For production it might be enough, but that will your risk assessment be able to determine.
If your require assistance with setting it up, applying it through code or any other guidance, please don’t hesitate to reach out to us: security@CloudRemote.io