5 Things You Should Be Doing in IAM Right Now | ScaleSec

Modernizing Security: AWS Series - 5 Things You Should Be Doing in IAM Right Now

5 Things You Should Be Doing in IAM Right Now

Identity and Access Management (IAM) is critical to get right, and one of the easiest things to get wrong. Identity is one of the first layers of defense against unauthorized parties looking to do harm. Thanks to how AWS users and services can leverage IAM this is also an opportunity to restrict, control, and manage access at many points throughout your architecture. Through appropriate separation of access, you can do more with less risk.

Embracing your data to gain a thorough understanding of your environment will lay the foundation to follow tried and true security best practices throughout your cloud Identity Management strategy. Identity management will become an enabler, instead of a roadblock.

These steps are on the path to achieving least privilege in a way that allows your developers to innovate and build. Along your journey, here are 5 things you should be doing right now:

1) Prevent humans from using machine roles

Custom applications, third party tools, and AWS services need to interact with the AWS platform. Human users need to use the AWS platform, too. But the functions and tasks humans need to perform are not the same. As when following the AWS Well-Architected Framework, consider the question: “How do you control human access?” ¹ Developers, security and reliability engineers have different access requirements based on job function and responsibilities. These permissions should not be mixed with the access that was provided to a company’s flagship revenue generating application, or the app the intern built last summer.

Since human users and machine users do not interact with roles the same way, having both:

• Increases the attack surface and opportunity to mis-use a role.
• Increases the scope of permissions to fit the need of both users, no longer following least privilege.

Prevent humans from using machine roles

What can I do?

• Grant access to your human users through federation. ²
• Disable console access for your machine roles. ³
• Use Temporary Security Credentials for your machine roles, so that they only have access for the time that they need it. ⁴
• Continuously monitor activity. Keeping human and machine usage separate will simplify analysis of user activity data.

2) Eliminate unused services and resources from IAM Policies

When crafting permissions for a role, consider the full scope of AWS service actions and resources to which those permissions grant access. Does your application need every one to operate? Broad permissions such as "Actions": "s3:*" (for all actions possible within the AWS S3 Service), or "Resource": "*" (for all Data stored on S3, within an Account) bring with them a high risk of data exposure, should be temporary, and at best avoided entirely. A key part of moving an application following this use case to production is downscoping those services and resources to the minimum required by that application in pursuit of least privilege access.

When that reduction fails to happen, it creates a broad opportunity for exposure and ultimately the risk of data theft. These extraneous permissions are the culprits that increase your attack surface and can make misuse of, or theft of, data devastating.

Eliminate unused services and resources from IAM Policies

What can I do?

• Limit IAM Policies to necessary AWS Services.
• Eliminate the presence of "Resource": "*" where possible.
• Use past activity markers with services like AWS CloudTrail down-scope to necessary permissions. ^{5 6}
• Use access levels to review IAM Permissions. ⁷

3) Create IAM Roles with guardrails

Flexibility and speed to build, deploy, and interact with AWS resources is front and center to the AWS Platform’s strength. That power is rooted in having the access you need, when you need it. However, unfettered ability to create IAM permissions can result in broad, overly permissive roles. These broad permissions increase the attack surface and risk of data exposure on an otherwise well architected application. Organizations often choose to pursue more restrictive models in their responsibility to manage this risk.

Managing risk through guardrails and controls can be done in a way that allows engineers to get what they need with the core flexibility that embodies the Cloud. IAM Permission Boundaries are a vehicle for restriction to maximum possible permissions an IAM Policy can have. Only the actions allowed fall within the overlap of what is specified within a given IAM policy, and also what is defined within a Permission Boundary. For behaviors that need to be managed at scale, AWS Organizations Service Control Policies (SCP) can be used to set permissions restrictions at an Organizational Unit (OU) level within AWS Orgs.

Create IAM Roles with guardrails

What can I do?

• Use Permission Boundaries to provide guardrails for IAM Policy permissions. ⁸
• Use AWS Organizations Service Control Policies (SCPs) to control IAM permission behavior at scale. ⁹
• Use infrastructure as code to create IAM policies with monitoring.

4) Short lived IAM Keys, if at all

IAM key credential pairs provide access to AWS services and resources similarly to an IAM User or Role. IAM Keys can be handled and passed programmatically to interact with the AWS platform. No one wants their IAM keys and associated access to fall into the wrong hands of an unauthorized party. Some common pitfalls which increase the likelihood of realizing risk:

• Writing IAM key information directly into application source code.
• Storing IAM keys locally for programmatic access and use.
• Sharing IAM keys with multiple sources who require the same programmatic access.

These pitfalls present a de-centralized key management approach, where keys are not protected from unintended viewing, and when keys must be rotated it becomes a manual and labor intensive effort.

IAM Roles can usually replace IAM Access Keys, eliminating the time and resources invested in managing and rotating your keys. Ultimately, the most secure way to handle Access Keys is to not use them at all. If keys are necessary, ensure they are rotated and managed responsibly. ¹⁰

Short lived IAM Keys, if at all

What can I do?

• Delegate access instead of sharing IAM Keys credentials. ¹¹
• Use IAM Roles instead of IAM Keys. ¹²
• Use AWS STS for temporary access. ¹³
• Rotate IAM keys regularly. ¹⁴
• Separate key handling from an application’s source code.

5) Continuously monitor IAM activity

As teams continue to deploy and grow their cloud presence, having an understanding of who is doing what within AWS will help you stay ahead of security issues. AWS has multiple services which provide valuable identity enriched event data. AWS CloudTrail provides detailed information about every action taken against the AWS API, with detailed identity information. AWS Config provides historical configuration data about all of your resources, including all of your IAM entities (users, roles, policies).¹⁵ In addition to providing state data, Config also has the capability to write rules based on configuration changes of interest.

Embracing identity enriched data is the first step towards continuous monitoring. Once issues have been found and addressed, continuous monitoring combined with governance controls is what is needed to manage cloud security risks permanently.

This continuous state data of your AWS environment gives the additional advantage of monitoring improvements. Are security issues increasing? Are they decreasing? Continuous monitoring over time will inform the effectiveness of a Cloud Security program.

Continuously monitor IAM activity

What can I do?

• Use AWS Config to monitor IAM roles usage. ¹⁶
• Investigate unexpected behavior with AWS CloudTrail. ¹⁷
• Know who is accessing your data with AWS S3 Object logging. ¹⁸

Conclusion

These tips are stepping stones on a journey to embrace a mature Cloud Security Program. The first 4 things to do with IAM as discussed in this article also set you up for more success with Continuous Monitoring:

• After separating human and machine user activity: Is a known machine user accessing the AWS console?
• Have IAM Permissions or specific IAM Roles not been used in over 90 days?
• Have engineers created broadly permissioned IAM policies in their effort to deliver at speed?
• Are there long-lived IAM Keys which could make their way into the wrong hands over time?

Knowing is half the battle. Winning the last half requires a lot of work, engagement, and coordination across any single organization. It’s important to acknowledge the complexity that comes with driving change uniquely in a given organization. Whether faced with long standing applications that are now moving to the cloud, or bootstrapped organizations which have to do more with less, every change in the right direction is addressing a risk, bringing you one step closer to a modern and well secured cloud ecosystem.

Read more about leveraging IAM as an essential component of good security posture by applying the Principle of Least Privilege.

1. https://wa.aws.amazon.com/wat.question.SEC_2.en.html ↩︎

2. https://wa.aws.amazon.com/wat.question.SEC_2.en.html ↩︎

3. https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_management_console_access.html#console_disable ↩︎

4. https://wa.aws.amazon.com/wat.pillar.security.en.html#sec.iaam ↩︎

5. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log ↩︎

6. https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/ ↩︎

7. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-access-levels-to-review-permissions ↩︎

8. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html ↩︎

9. https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/ ↩︎

10. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html ↩︎

11. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html?ref=wellarchitected#delegate-using-roles ↩︎

12. https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html ↩︎

13. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html ↩︎

14. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials ↩︎

15. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log ↩︎

16. https://aws.amazon.com/blogs/security/continuously-monitor-unused-iam-roles-aws-config/ ↩︎

17. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log ↩︎

18. https://docs.aws.amazon.com/AmazonS3/latest/dev/using-s3-access-logs-to-identify-requests.html ↩︎