IAM-IDENTITYANDACCESSINTHEAWSCLOUD

*When creating a secure environment in AWS, IAM is a critical part of the security provided in the solution. It’s used for controlling how users, compute resources and other services interact with each other, however it can also be the critical hole if you don’t properly secure your policies.

For users (and sometimes administrators), security is hard. It can slow you down with authentication and provide roadblocks when you are denied access to the resources you need. Many customer environments have experienced this and create dangerous holes for users. This can be an overzealous firewall rule, a shared credential or excessive privilages to perform the actions they need to do. It’s worth considering what the risks are when a business creates these shortcuts, as more and more companies are having big public security failures that crush reputations.*

HOW IAM POLICIES ARE EVALUATED *For developers that are new to working with IAM, the logic can be confusing at first, especially since the Amazon documentation is massive. Here’s how I explain to others how IAM policy rules are applied:

1. If a permission isn’t mentioned, it’s not given

2. If a permission is given, that action is allowed UNLESS any other policy explicitely denies that permission

With the way rules are evaluated, the order of how the rules are applied does not matter.*

OPEN IAM ROLES *Let’s looks at an Amazon-provided role, ReadOnlyAccess.

This role gives the ability for a user to have read-only access to all resources within an AWS account, which is a privilege often given to users in order for them to view the resources within an AWS account. Though they have no access to perform any modifications directly, the scope of this role can unintentionally reveal information (unless explicitely denied elsewhere).

For example, this role grants permission to download all objects in every bucket in the account. Often, S3 objects may contain configuration information or even credentials that the developer may have thought secure. The role can also allow users to intercept SQS messages, get EC2 console output or get items from Kinesis or DynamoDB.

If you’re looking for a role which further restricts users’ access to the above resource, the ViewOnlyAccess role can alternatively be used, though you may find this to be too restrictive in some environments.*

CONDITIONAL IAM POLICIES One of the more powerful features of IAM policies is its ability to conditionally provide access to resources. This can help teams seperate themselves from other workloads or prevent unwanted actions. Here’s some examples:

TAG-BASED ACCESS The below policy grants access to perform all actions, so long as it has the “Department” tag set to “Finance”. This is an easy way to segregate different parts of the business within the same account. Remember, not all services support tagging and account-wide limits still apply to everyone.

TIMEFRAME RESTRICTION The below policy grants access to perform all actions only within the timeframe shown. This is useful when users are only permitted to have access during certain periods, such as contractors.

IP-BASED RESTRICTION The below policy grants access to perform all actions only when the request is made from the IP addresses specified. This can help restrict calls to only occur from within a corporate network, as an extra layer of security. Note that calls made by AWS services, such as CloudFormation when it creates resources, cannot be restricted in this way - however the call to create the stack could be.

SUMMARY IAM Roles and Policies are an important piece of every AWS environments security and when done correctly, can be a very powerful tool. However, these policies can very easily get out of control and can have unexpected consequences. If you are having trouble managing IAM, get in touch with usto find out how we can help you master your AWS environment security.