AWS Partner Network (APN) Blog
How to Minimize Unintended Access and Achieve Least Privilege with Ermetic and AWS
By Lior Zatlavi, Sr. Cloud Security Architect – Ermetic
 |
| Ermetic |
 |
Proper entitlement management is a significant security layer for an Amazon Web Services (AWS) environment.
If you implement the principle of least privilege by reducing the effective permissions held by both humans and services, you can dramatically minimize both the incident surface of your environment and the blast radius of unintended access.
Imagine an identity having unintended access to a workload while it has access to an AWS Identity and Access Management (IAM) role with AWSS3FullAccess attached to it. Now imagine having the same situation when that IAM role has a right-sized IAM policy that only allows access to the specific buckets and actions required to perform its business functions.
The difference in this scenario can be massive in its implications for business continuity, data privacy, and regulatory sanctions—or all of the above. Unfortunately, just figuring out the effective permissions of each identity in your environment can be overwhelming.
For this reason, Ermetic has developed a permissions analysis engine which performs this task automatically, to a fine-grained level of granularity, and for all of the identities in your environment—humans and workloads alike. The engine even takes federated users from identity providers into account as well.
This post walks you through the real-world challenges the Ermetic platform can help you address, how to set up the platform in your environment, and how to get maximum value out of the platform.
Ermetic is an AWS Security Competency Partner and comprehensive identity-centric cloud security platform for easily reducing risk at scale.
Challenge: Determine Effective Permissions
If you were tasked with taking an identity in your AWS environment and determining exactly what resources it has access to and what actions it can perform on each of them, it may be more of a challenge than you originally expected.
The obvious thing to do is review the IAM policies attached to the identity to determine what each grants. That in and of itself may not be simple, however, because an IAM policy may include wildcards on both the “Resource” and “Action” fields, making permission statements apply to a wide set of resources and/or actions.
On top of that, permissions may also be granted from the configuration of the resource itself using a resource-based policy, and there’s no easy way to find out which resources the identity can access in this way. You can use the AWS APIs to try and automatically review the various resource policies in the environment, but remember that permission statements may apply to principals through conditions, which are not that easy to analyze.
Even if you figure out both the IAM and resource-based policies, you have to consider the important fact that once a principal such as an IAM user or IAM role has permission to assume an IAM role, it effectively has access to its permissions as well.
Additionally, if federation is enabled, multiple identities may be able to use the same IAM role in order to access resources in your environment. These identities are usually controlled by an identity provider (IdP), which may be controlled by someone other than the individual managing the AWS environment.
Finally, in order to complete an accurate assessment of the effective permission set for each principal/identity, you would need to consider guardrails such as permission boundaries and service control policies, which may limit the actual permissions the identity can use.
All of these policies and configurations make figuring out what just one identity is able to do a complicated task. Imagine you have to do this for each and every identity in your environment, and keep track of this state all the time in order to make sure it doesn’t change.
This analysis is hard to do but can be very useful for understanding where you may have over-privileged permissions configured in your environment. Let’s look at two scenarios in which this information can be valuable.
Scenario 1: The (Extremely) Privileged Workload
Workloads such as Amazon Elastic Compute Cloud (Amazon EC2) instances and AWS Lambda functions often need access to resources within the AWS account as well.
Often, when starting work on a project, it’s hard even for the development team to determine exactly what resources the workload will have to access; sometimes it’s objectively impossible as those resources have not been created.
For this reason, it may be legitimate to start by assigning the IAM role that the workload will use an extremely permissive IAM policy—possibly even an AWS managed policy which allows access to all the instances of a certain resource type. Later on, and hopefully before moving to production, you can do a right-sizing process and replace the over-permissive policy with one that adheres to the principle of least privilege.
However, it’s not uncommon for “later on” to never arrive. Or, when it does, the organization faces the prospect of replacing a policy that currently works with a more limited one that could break something in production. This can lead even security professionals to procrastinate indefinitely and focus on tasks that are less risky.
This scenario usually leaves over-permissive permissions granted to workloads in production, with access to sensitive information and mission-critical resources. If such a workload is compromised, the fallout could be more damaging than it should have been.
Scenario 2: Federated Users
It’s a common best practice to federate users from IdPs to your AWS environment. Doing so enables central management of users and offers an easy way to provide access to one or more AWS accounts through the use of IAM roles.
It’s best to avoid providing these users with permanent permissions to production environments—and only provide them with access on a just-in-time basis per approval and specific need. However, some AWS customers have power users and/or system admins with long-standing permissions; these users may present a risk if their permissions are not properly vetted.
The AWS account administrator might run into two issues when trying to configure federated identities according to the principle of least privilege.
- The first (and probably more important) issue is political—it’s usually not a pressing goal for the users, such as developers or DevOps professionals, to limit themselves by restricting their access permissions. Unfortunately, they’re probably the most qualified people to know exactly what they actually need. Without getting them on board for this process, it’s difficult to determine the precise services they use.
- The second issue is that since the range of services in AWS is so wide, security professionals often don’t have the expertise required to determine with confidence exactly what resources and specific actions power users actually require.
The combination of these two factors can lead security teams to allow a wider range of permissions than required, acknowledging they should “choose their battles” in a more effective way and insist on finer granularity where they have more knowledge and/or technical ability.
Benefits of the Ermetic Platform
Ermetic enables you to handle these scenarios with ease, by providing insights based on a deep and fine-grained analysis of the configuration of both the AWS environment and AWS CloudTrail logs.
Ermetic shows you precisely (among other things):
- Which resources each principal is allowed to access and what actions it’s allowed to perform on them.
- Which permissions each principal actually needs based on actual behavior over a lengthy period of time.
- Differences between the two, and exactly how to close the gap.
These insights, if used consistently and at scale, can limit both the potential incident surface derived from excessive permissions and the blast radius from potential unintended access.
Let’s see how you can easily set up Ermetic to integrate with your AWS accounts and how it can help with the scenarios described above.
Setting Up Ermetic in an AWS Account
Ermetic is a software-as-a-service (SaaS) platform that doesn’t require installation of software or deploying any new computing resources in your environment.
Ermetic uses role delegation to access your environment. For each account you want to monitor, create a role within AWS IAM, grant the role permissions, and then supply your CloudTrail information in the Ermetic platform.
A complete list of permissions required by the role is available in the onboarding wizard. These permissions are strictly read-only, but it’s possible to provide Ermetic with management permissions as well. This allows you to remediate findings straight from the Ermetic console.
Ermetic collects inventory and configuration data via the AWS API, and activity data from CloudTrail logs.
After a quick setup process, Ermetic starts collecting account configurations and CloudTrail logs. It takes a few hours of initial data processing, and then you’ll see the effective permissions of identities in the environment and the risks based on actual activity from the CloudTrail logs.
It should be noted that if CloudTrail logs are already available in your environment (and they usually are), you get these results right away, with no need for an additional “learning” period.
Least Privilege with Little Effort
Let’s assume there’s a workload that needs to access resources in your environment. In this example, it’s an EC2 instance that needs access to a few Amazon Simple Storage Service (Amazon S3) buckets to read certain configurations from one bucket and to write logs to another bucket, but it’s unclear which exactly (since they may not even have been created yet).
You attach a permissive policy on the IAM role the EC2 uses in the testing environment. You can have Ermetic monitor the environment to see exactly what the workload does and automatically generate a right-sized policy. You can use this instead of the over-permissive one in both the staging environment and the production environment, where it really counts.
It would be better to design right-sized policies from the start, but doing so is not always feasible as application requirements may be very dynamic. Therefore, for many organizations, right-sizing in testing is a good solution.
Let’s look at a case where we attach AmazonS3FullAccess to the IAM role in the testing environment, and run Ermetic to monitor the account.
Figure 1 – Filtered permissions graph showing permissions granted by AmazonS3FullAccess.
In the diagram above, we see the permissions graph of the workload (permission it has access to by assuming an IAM role) filtered to display only the over-permissive policy. Through the color of the arrows, Ermetic indicates whether a permission is completely excessive (not used at all) in red, or partially excessive (used, but not to the extent it’s granted) in yellow.
Now, Ermetic can confidently generate a policy that would replace the excessive permissions. By reviewing the CloudTrail logs, Ermetic determines the permissions required for the workload to perform its job. It generates a right-sized policy you can either manually replace or apply using automatically-generated infrastructure as code (IaC) snippets or directly through the Ermetic console.
You can have Ermetic generate a least privilege policy on demand after a predetermined testing period. To generate a policy on demand, you simply go to the relevant IAM role page in Ermetic (in this example, the IAM role used by the workload in the testing environment) and trigger its creation.
Figure 2 – Triggering the generation of a least privilege policy on demand.
After doing so, a new least privilege policy will be generated based on the activity of the IAM role during the time period selected (in the figure, the selection is for the last 31 days; alternatively, you can specify a custom time period). You can then view the policy, as shown below.
Figure 3 – Ermetic-generated least privilege policy based on past activity.
You can adjust the policy or use it as-is, and apply it to the production environment in place of the existing, over-privileged policy.
This simple process can make a crucial difference to the security of your production environment. If there were unintended access in production, the difference in the scope of permissions the workload has would have a significant impact on the fallout.
On top of doing this on specific workloads, Ermetic automatically and continuously performs this same actual-use analysis at scale for all your AWS workloads and users. If it detects that a workload is over-privileged based on its past activity, Ermetic alerts you to this finding.
Figure 4 – Ermetic alerting upon detecting an over-privileged IAM role.
When you open the Findings page, you get a recommendation for a least privilege policy to replace the over-permissive one, with a side-by-side comparison showing precisely where the difference lies.
Figure 5 – Ermetic generates a right-sized policy for an IAM role it detects as over-privileged, and displays it with the differences highlighted.
Power Over Power Users
In a similar fashion, Ermetic can help you keep track of user identities—whether they are IAM users or users federated to your environment from an identity provider.
For example, if you use Okta to manage your users and then provide them with federated access to your AWS environment, you can integrate Okta with Ermetic using Okta’s API. Ermetic collects information from Okta about the users and groups they belong to and combines this information with the information from your AWS environment. This shows you a clear picture as to what they are allowed to do and which permissions they actually use.
The figure below shows a permissions graph for Okta user John Robertson who uses federated access with the OktaDevelopers IAM role.
Figure 6 – Permissions graph for a user federated from Okta.
As shown before with the workload, you can clearly see which permissions in each of the policies it uses are completely or partially excessive. You can also filter the diagram to only show the used permissions or, if you prefer, view this information in textual form.
Figure 7 – Filtered permissions shows permissions used by federated identities in graph (top) and textual (bottom) form.
This provides security teams with high resolution visibility into actions performed by developers. This, in turn, can be used as a solid and data-oriented foundation for collaboration with development teams to achieve effective least privilege without compromising their ability to perform their jobs.
With Ermetic, you get an easily consumable aggregation of what permissions users actually need, so the dialog with development teams on reducing their permissions to specific services, actions, or even resources is based on data and not merely on opinion or personal wishes.
In addition, using Ermetic you can spot unnecessary permissions which are usually hard to find. If a developer is granted cross-account access to a production account because of a permission they have been granted in a development account due to a misconfigured resource in the production account, this will be easily visible when filtering for cross-account access on the permission graph.
Figure 8 – Filtered graph shows cross-account access for the federated user.
Conclusion
Managing permissions properly for both workloads and human identities is a significant and important challenge when hosting resources in AWS accounts.
By achieving least privilege in your environment, you can reduce the attack surface and the blast radius from unintended access. Along with best practices, guardrails, and native tools, employing a third-party automated analysis platform such as Ermetic can be an effective way to meet this challenge.
In this post, I have shown how to configure right-sized policies for workloads and reduce the permissions granted to power users. If you want to learn more and see Ermetic in action in your AWS accounts, contact Ermetic for a demo.
The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.
.
.
Ermetic – AWS Partner Spotlight
Ermetic is an AWS Security Competency Partner and comprehensive identity-centric cloud security platform for easily reducing risk at scale.