Atrás 
Introduction
Best practices for securing an AWS environment have been well-documented and generally accepted, such as AWS’s guidance. However, organizations may still find it challenging on how to begin applying this guidance to their specific environments.
- Which controls should be applied out-of-the-box vs. customized?
- What pitfalls exist in implementing the various controls or checks?
- How do you prioritize remediation of the “sea of red” violations?
In this blog series, we’ll analyze anonymized data from Netskope customers that include security settings of 650,000 entities from 1,143 AWS accounts across several hundred organizations. We’ll look at the configuration from the perspective of the best practices, see what’s commonly occurring in the real world, and:
- Discuss specific risk areas that should be prioritized
- Identify underlying root causes and potential pitfalls
- Focus on practical guidance for applying the Benchmark to your specific environment
This blog post focuses on IAM security controls related to IAM Policies. Based on the Netskope dataset analyzed, we will highlight four opportunities to improve security by making simple IAM changes:
- IAM Policies are over-privileged with 4% of the policies in use having full administrative privileges and more than 60% of these using the AWS AdministratorAccess role, which increases the potential impact from compromised credentials and increases the assets at risk.
- 1,401 (11.2%) of 12,478 IAM Users have inline policies, which leads to errors in policies because they are difficult to manage and maintain in a consistent manner.
- 5,886 (47%) of IAM Users have policies directly attached to the user, which also are difficult to manage and maintain.
- 769 (67.3%) accounts do not have the AWSSupportAccess policy attached to a role or user for incident response, which could slow down response if an incident occurs.
IAM Policy: overall, over-privileged, all over
“Power corrupts. Absolute power is kind of neat.”
— John F. Lehman, Jr.
The following five best practices related to IAM Policy were analyzed in this dataset, which contained 35,950 IAM Policies across all accounts:
| # | Best Practice | # Violations | % |
|---|---|---|---|
| 1 | Ensure IAM policies that allow full "*:*" administrative privileges are not attached | 1,411 | 4.2 |
| 2 | Ensure IAM Users Receive Permissions Only Through Groups (no inline) | 12,401 | 11.2 |
| 3 | Ensure IAM Users Receive Permissions Only Through Groups (no direct attach) | 5,886 | 47.2 |
| 4 | Ensure IAM instance roles are used for AWS resource access from instances | 34 | .03 |
| 5 | Ensure a support role has been created to manage incidents with AWS Support | 769 | 67.3 |
1. Full Administrator Privileges
Background: Minimal privileges are a key security practice to prevent unauthorized access and to make escalation of privileges and lateral movement harder for malicious actors. Policies with overly broad privileges should not be created. In this case, overly broad is defined as all actions (*) for all resources (*) being allowed in a policy.
Data: 1,511 (4%) out of 35,950 policies have full administrative privileges with any action on any resource i.e. Action=*, Resource=*.
Analysis: 926 (61%) of the 1,511 have full admin privileges due to the direct use of the AWS AdministratorAccess policy.
Controls:
- Detection/Audit
- Overly broad administrator roles can be detected with the AWS Config Rule: iam-policy-no-statements-with-admin-access.
- Prevention/Mitigation
- The recommendation is to create more granular and limited least-privilege policies and roles. Do not use the AWS AdministratorAccess policy, instead use more limited Administrator policies.
2. No Inline Policies and 3. No Direct Attachment of Policies to Users
Background: Policies should be attached to groups or roles, not directly to users. Similarly, inline policies should not be used. Both of these practices make the management of policies and permissions more error-prone and less repeatable. Inline policies are hard-coded policies that exist for only that IAM User and are difficult to track and update. Direct attachment of policies is hard to maintain across multiple users who require the same privileges.
Data:
- 1,401 (11.2%) of 12,478 IAM Users have inline policies.
- 5,886 (47%) of IAM Users have policies directly attached to the user.
Analysis: 47% or almost half of IAM Users have policies directly attached, rather than through groups or roles. Over 11% of IAM Users have inline policies. Both of these practices are quite common but should be avoided. If inline policies are duplicated among users and need to be updated, then mistakes can occur during this process, leading to inconsistent policies. Similarly, for policies directly attached to users, if multiple users require the same policy updates, errors can occur since all of the specified users need to be modified. However, if the policies were attached to a group or role, only one modification would be needed at the group or role level.
Controls:
- Detection/Audit
- Inline policies can be detected with the AWS Config Rule: iam-no-inline-policy-check. Alternatively, auditing of IAM Users and their
- Prevention/Mitigation
- To remediate the situation, it is recommended to remove any directly attached policies or inline policies and replace them with managed policies attached to groups or roles, not users. Policies are more manageable and maintainable, reducing errors.
4. EC2 Instances Profiles
Background: EC2 instances can run with a specified profile and role, rather than the privileges of the user or service account used to launch the EC2 instance. The impact can be several-fold: users can accidentally run EC2 instances with broader privileges (the user’s privileges) increasing the risk should the EC2 instance be compromised, and it a