Amazon offers users multiple options to sign on to Amazon Web Services. While these options provide flexibility,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
new users are often confused when choosing among the various options. This tip introduces the various authentication options and discusses best practices for using them both effectively and securely.
The first credential type users are likely to encounter is the root account. A root account credential is the email address and password used to sign up for a new Amazon Web Services (AWS) account. It is the same credential used to sign on to an Amazon.com account. In other words, the same credentials used to buy a book on Amazon.com can be used to buy Amazon Web Services.
There is only one root credential for each AWS account, and it has full control over the entire account. As a result, the root credential should not be used for day-to-day administration. Users should only use the root account credentials for three purposes: first, to set up a new account; second, to update billing information (e.g., to change a credit card expiration date); third, as a last resort if all administrators lose access to the account (e.g., if an IAM policy change accidentally blocks all users from signing in to the account).
Since these credentials have full control over the account and are seldom used, it makes sense to protect the account with strong security measures. Users should assign a strong, random password and enable Multi-Factor Authentication (MFA) on the root account from the AWS Identity and Access Management (IAM) dashboard.
With the root account credential safely locked away, let's move on to IAM users. IAM user credentials are used to sign on to the AWS Management Console for day-to-day administration. Each AWS account can have up to 5,000 IAM users. With so many users, it can be difficult to enforce password policy. Let's examine a few a ways we can protect IAM user accounts.
Rather than trust these users to choose strong passwords, it is better to enforce a strict password policy. The IAM console supports policies that include minimum length and complexity requirements. In addition, the policy can enforce an expiration period and prevent the reuse of passwords over time.
With a password policy in place, next enforce separation of duty. Separation of duty is the practice of distributing responsibility among multiple people so that no one person has full control of everything. IAM users should only have access to the services and features required to do their job. AWS supports role-based security using IAM groups. For example, an administrator might define a group for network administrators who have access to Virtual Private Cloud (VPC) and another for server administrators who have access to the Elastic Compute Cloud (EC2). Each IAM user can then be added to as many as 10 IAM groups based on the services needed to do his or her job.
IAM user accounts support MFA just like the root account does. Since managing MFA for hundreds, or thousands, of users can be very time-consuming, it may make sense to only enable MFA for highly privileged users. For example, require MFA for users who can manage other IAM users, but don't require MFA for users managing EC2 server instances.
IAM access keys
IAM access keys are not really another type of account. Access keys are just another way to sign on as an IAM user. Each IAM user can have a username and password, and a set of access keys. Either one can be used to sign on as that user and access AWS.
In general, a username and password are used to sign on to the AWS management console, and access keys are used to sign on to the API. There are two common use cases for access keys. First, power users may request access keys for use with their favorite scripting language. For example, an administrator may write a PowerShell script to help manage servers and will need his or her access keys to do this. The best way to keep these keys secure is to rotate them often. AWS allows each user to have two sets of keys to make key rotation easy.
The second common use of access keys is with third-party tools. For example, cloud management platforms -- such as RightScale -- require access keys to manage AWS resources. Always create a new IAM user for each third-party tool and use IAM policies to only grant the tool the permissions it needs. In addition, accounts created for tools never need access to the AWS Management Console, and therefore, should not have passwords assigned.
Eventually, as AWS adoption grows, managing IAM users may become a full time job. If users have more than 25 IAM accounts, consider Security Assertion Markup Language (SAML) federation to enable single sign-on. SAML federation allows users to sign on using the same credentials they use to access other applications at their company. Often this is Microsoft Active Directory.
AWS support integration with Active Directory Federation Services and other identity providers. With federation in place, users can sign on without first creating an IAM user. The user is granted permissions based on the groups he or she is a member of in Microsoft Active Directory. This greatly reduces the overhead of managing access to AWS.
AWS offers multiple ways to authenticate users. Understanding these authentication options and how to secure each will ensure users get the most out of AWS.
About the author:
Brian Beach is an enterprise architect with more than 15 years of experience in software engineering and information technology management. Brian is an Amazon Certified Solution Architect, Microsoft Certified Solution Developer (MCSD) and Certified Information Systems Security Professional (CISSP). He holds a BS in Computer Engineering from NYU Poly, an MBA from Rutgers Business School and is a member of American Mensa. Brian is an advocate for cloud computing on the AWS platform and currently manages a team of cloud engineers at a Big Four accounting firm. He can be contacted through his blog at http://blog.brianbeach.com or LinkedIn at http://www.linkedin.com/in/brianjbeach.