This content is part of the Essential Guide: AWS re:Invent 2015: A guide to Amazon's sold-out event

Group user access with Amazon IAM

While it is not a fit for every scenario, cloud administrators can save time by establishing access groups for users using AWS Identity and Access Management.

Limiting access to resources is a necessity in establishing a secure cloud. Amazon Web Services allows administrators to firmly establish roles for cloud users using Identity and Access Management. But administrators can save time and frustration by setting up access groups.

Groups are merely a set of users with the same Amazon Web Services (AWS) access requirements. They represent a handy shortcut for assigning and changing permissions for large subsets of an AWS user population and make it simple to reassign a user's set of permissions when someone's job responsibilities change.

Groups should be based on business function and job requirements. Indeed, it's best to define permissions and groups as a unit and assign users as necessary. Start by defining the needs of each constituency using AWS and then map those to a set of AWS permissions. Use the default set of AWS access policies as templates and double check your Identity and Access Management (IAM) configuration using the AWS Trusted Advisor.

Amazon IAM permissions can also have a set of conditions that allow granular control over certain actions and logically take the form of "if-then-else" statements. The goal of conditional permissions is to allow legitimate work while minimizing accidents, particularly with restricted, administrative activities. For example, a conditional permission could require access to a certain resource or the admin console from a certain IP address range, and only when using AWS Multi-Factor Authentication. Conditional-policy logic gets complicated and can easily lead to unintended consequences, thus it's wise to use the AWS Policy Simulator to test the effects of policy changes before deployment.

Security groups can be especially granular, controlling access to specific EC2 instances. This is overkill, and only adds administrative overhead. A better option is to create groups for user access to specific applications -- or better yet, application tiers, such as access to front ends and elastic load balancers, app logic and database layers. However, when defining permissions for service requests, such as an EC2 instance calling other Amazon services, it's best to use roles, not groups. Because an Amazon IAM role has no credentials, it cannot make a direct request to AWS.

Group policies can also apply to AWS virtual private cloud network security to control access to specific subnets, server ports and API access. In this context, groups serve the same function as in network firewall policies and access control lists.

Maintain identity integrity via password policies

It's wise to enforce a stringent password policy. This policy should include strength, expiration and reuse requirements, and access credentials should be rotated regularly.

AWS admins should use credential reports to identify the use of access keys, flag those that are dormant and remove unused keys. Key rotation requires a few steps to avoid accidentally disabling application access:

  • Create a second access key in addition to the one in use.
  • Update all applications to use the new access key and validate that the applications are working.
  • Change the state of the previous access key to inactive.
  • Validate that your applications are still working as expected.
  • Delete the inactive access key.

Admins might also consider using AWS CloudTrail. By logging user activity, including API calls and logins, this tool provides deeper insight into your AWS environment. The more you know about what's already taken place, the better able you'll be to prevent something unwanted from happening in the future.

Next Steps

Data security in AWS: Creating a strategy that works

AWS IAM centralizes policy management

Best practices for protecting AWS access keys

Improve SQS access control with Amazon IAM

Dig Deeper on AWS security