tiero - Fotolia
Online accounts that secure access with only a username and password provide about as much protection as a locked...
screen door. In reality, businesses need to do a lot more to protect data and workloads.
Multi-factor authentication (MFA) offers a simple -- but significant -- improvement to online security, combining a password with a temporary access token, usually on a device. AWS supports stronger account protection through MFA. Since 2014, AWS has strongly recommended that users protect their root accounts with MFA using either a virtual token, with software like Google Authenticator, or a hardware MFA device. Now, AWS Identity and Access Management (IAM) best practices advise IT admins to enable AWS MFA for all privileged users.
AWS has also added support for the feature on other services, making it easier to get started with virtual tokens for admin accounts. Savvy users, however, should explore other creative ways to use MFA to strengthen cloud security and accountability.
AWS MFA features and supported services
The basics of AWS MFA -- combining a username-password with a one-time token -- remain consistent across the cloud. But AWS supports several different authentication methods.
For example, it incorporates hardware devices, such as a key fob or credit card-sized unit, to deliver time-based, six-digit tokens. AWS GovCloud certified a Gemalto key fob for its FedRAMP-compliant region for U.S. government agencies. Unfortunately, AWS doesn't support the Fast IDentity Online (FIDO) standard and compliant Universal 2nd Factor devices, like the popular YubiKey or the FIDO Universal Authentication Framework protocol, which integrates mobile biometrics into an MFA back end.
With MFA, IT teams can use virtual devices that support the Internet Engineering Task Force's time-based, one-time password standard, including Google Authenticator and Authy apps for iOS and Android. An IT admin also can send SMS messages with an MFA code to a device; this feature, however, is still in preview.
Branching out from the root account
AWS MFA was initially created to secure root accounts, but it has since been expanded to other accounts, services and applications. IT teams can apply MFA to the following resources:
- AWS sign-in credentials: Account authentication through MFA works the same as it does on many other online sites. When logging into AWS, the site asks users for a username and password. If they match an existing account, while AWS MFA is enabled, it prompts the user for a time-sensitive, six-digit code. Only a hardware device, mobile app or text message can supply the code.
- MFA can secure any user account, but each account can have only one token. Normally, this isn't an issue, as it's easy to add AWS accounts. But it poses a problem for organizations that want to share root account access among several administrators. The root account shouldn't be used this way; perform privileged actions from separate accounts with admin permissions. A workaround is to capture and store the unique QR code created when a virtual token generates.
- API calls: Adding an MFA requirement to IAM policies will also protect API access. IAM works with AWS Security Token Service (STS) to generate a temporary access key for the protected API. Configure STS tokens to be valid from a few minutes to several hours, after which new API calls require another round of MFA.
- Data versioning: MFA also controls access to various versions of Amazon Simple Storage Service (S3) data objects. Disabled by default, developers can configure S3 buckets to keep multiple versions of the same object and enable recovery of old data copies. The feature can overwrite or delete objects, so it's prudent to put tighter security controls around its use, such as MFA.
AWS MFA uses
Although IT teams can apply MFA to any account, it is an AWS best practice to use it for any with access to administrative services, not just the root account. MFA not only strengthens security; it also provides greater accountability of administrative actions, which AWS CloudTrail can log. MFA also protects sensitive APIs and data.
Configure API access control in IAM to include a requirement for MFA. For example, a user could make an API call to terminate an instance in a particular group of Elastic Compute Cloud VMs running critical applications. Requiring an application to verify the action with MFA to receive a time-limited token protects against this. Validate the MFA itself through temporary security credentials, which could require a user to reauthenticate after being logged in for more than 10 minutes if they want to use a protected API. The time limits associated with temporary credentials make them suited to grant access to any sensitive resource, particularly for external users, because you don't need to embed keys in an application or worry about key rotation.
Test your knowledge of AWS security, including multi-factor authentication
Test your knowledge of AWS security best practices with this 10-question security quiz.
MFA and object versioning can provide added protection for sensitive data in S3 buckets. Object versioning protects against accidental data loss -- a call to delete a single object in a version-controlled bucket doesn't erase the data but marks the version as deleted. To actually delete the version, specify both the object and version ID.
In a bucket that the MFA Delete feature protects, users must provide both their IAM access key and a valid six-digit MFA code in an API or command-line interface (CLI) call to delete an object. Note: The MFA Delete feature only applies to API or CLI interactions, not deletions done via the AWS Management Console. Additionally, an admin must enable MFA Delete with the bucket owner, which is the root account. MFA Delete applies to the entire bucket, so you might need to reconsider your storage place if you don't want to version objects in a bucket like temporary files or staged code.
Although it exploits using MFA for IAM policies, admins can pair MFA account security with source code management to guard against accidental or malicious poisoning of sensitive source code repositories, which could automatically trigger a continuous integration or continuous delivery deployment process. MFA and STS can grant temporary secure credentials before a Git user can submit code to an AWS CodeCommit repository.
The National Institute of Standards and Technology and the vast majority of security professionals agree that MFA should be used whenever possible.
Add a layer of protection with AWS multi-factor authentication
Catch up to the pack with these authentication methods
Trust the security experts and follow this AWS advice