Andrea Danti - Fotolia
Amazon Web Services security is built upon a powerful Identity and Access Management service with a rich set of features befitting an enterprise-class platform. Yet the management console for the Identity and Access Management controls, nestled within an elaborate AWS dashboard, is deceptively simple, belying the complexity of the myriad account, credentials and security policy options within AWS.
Identity and Access Management (IAM) shares many features -- users, groups, passwords and permissions -- from server operating systems. But it adds others, such as conditions, roles, access keys and credential rotations that are less common.
Further complicating the picture, Amazon Web Services (AWS) uses identities and groups for several purposes: access to management features via the Web console or command line interface (CLI), programmatic access to AWS utilities via APIs and network access and traffic policy when using a private network on a virtual private cloud.
AWS hews to established identity management practices. This is where security policy starts at the most atomic layer: individual user identities with unique credentials that are mapped to a set of usage permissions. As the number of users and associated sets of permissions grows, however, minimizing management complexity requires making molecules out of those atoms.
Central to efficient IAM usage is the ability to define a common set of permissions for particular tasks and job requirements by placing users with similar needs into a single pool with a consistent set of policies for everyone in the group. Indeed, users and groups form the foundation of an effective and secure AWS access policy framework.
User management basics
AWS access control starts with user identity, where the prime directive is that every individual should have a unique user ID and credentials. These identities map to a set of permissions that by default should have no permissions. In other words, creating a new AWS user is relatively meaningless.
In AWS, user IDs have up to four types of security credentials:
Password: Used for Web access to the AWS management console.
Access keys (public and private): Used for CLI or API access to AWS services.
Multifactor authentication (MFA): Associate with a physical (USB token) or software (Google Authenticator) generating one-time passwords for extra security.
Secure Shell key pairs: Used to secure code management software for traffic between private repositories hosted on AWS CodeCommit and local Git clients.
AWS is designed around the security strategy of granting the least privilege, since by default users can do nothing -- even if they have their own access keys. Administrators should build user permissions from the bottom up: only those required to do the job should be added. This means, for example, that users who never need to access the management console, such as developers, shouldn't have passwords for that. The principle here is that it's always easier and more secure to add permissions when necessary than to take them away when misused.
IAM permissions restrict access to AWS resources, and those limits can apply to individual users or overall resources. For example, a user might have permission to access an Amazon S3 bucket, but no ability to add, delete or change its contents. A separate S3 bucket used for test and development might have resource permissions that allow any users coming from a specific range of IP addresses or from EC2 instances in a certain zone to have full access. Individual IAM permissions can be aggregated into a policy.
IAM policies in AWS are a set of logical statements using JSON syntax. They describe an arbitrarily complex set of permissions. For example, a policy could allow users from a business partner (defined using groups) to drop files only in a specific portion of a larger corporate file-sharing bucket; a user might need full access to EC2 reports, but simple read-only access to AWS account usage.
AWS policies can be arbitrarily complex, but most situations are covered by policy templates built into IAM. Be aware, though: Permissions don't apply to the root user, i.e., the identity used to establish an AWS account. Like the super-user in Linux, AWS root has unfettered access to everything, which is the reason the IAM setup wizard nags administrators to delete -- or not create in the first place -- root access keys and to secure the root password with MFA.
AWS IAM centralizes policy management
Best practices for using AWS IAM groups and roles
Stay one step ahead of AWS cloud security issues
Use AWS IAM to achieve better SQS access control