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.
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