Tag: Access keys
We continually review your input submitted via the Feedback link on the AWS Identity and Access Management (IAM) console. Based on our recent review of that feedback, one of the features most frequently requested by you is the ability to search for an IAM user with their associated access key ID. To address this request in particular and the search feature in general within the IAM console, we asked ourselves a simple question: “How can we help AWS customers find things more easily in the IAM console?” The answer to that question is the new IAM console search.
In this blog post, I will walk you through the new IAM console search that allows you to search for your IAM entities (users, groups, and roles), policies by name, identity provider, tasks, and—most importantly—access keys. (more…)
As security professionals, it is our job to be sure that our decisions adhere to best practices. Best practices, though, tend to be time consuming, which means we either don’t get around to following best practices, or we spend too much time on tedious, manual tasks. This blog post includes two examples where AWS services can help achieve adherence to security best practices, minus the inordinate time investment.
One AWS Identity and Access Management (IAM) best practice is to delete or regularly rotate access keys. However, knowing which AWS access keys are in use has usually involved poring over AWS CloudTrail logs. In my May 30 webinar, I highlighted the then recently launched access key last used feature that makes access key rotation easier. By knowing the date and IP address of the last usage, you can much more easily identify which keys are in use and where. You can also identify those keys that haven’t been used in a long time; this helps to maintain good security posture by retiring and deleting old, unused access keys.
If you have a Windows environment on AWS and need to join each Amazon EC2 instance to the Windows domain, the best practice is to either do it manually, or embed credentials in the Amazon Machine Image (AMI). In this Auto Scaling Lifecycle Policies for Security Practitioners video,I show you how you can use Auto Scaling lifecycle policies to, among other things, join a server to a Windows domain without sharing credentials across instances.
These are just two examples of how using AWS services helps you adhere to best practices, reduce risk, and spend less time on manual tasks. If you have questions or comments, either post them below or go to the IAM forum.
Rotate access keys regularly and remove inactive users. You’ve probably heard us mention these as two AWS Identity and Access Management (IAM) security best practices. But how do you know when access keys (for an IAM user or the root account) are no longer in use and safe to delete? To help you answer this question, IAM now reports the time stamp when access keys were last used along with the region and the AWS service that was accessed. These details complement password last used data to provide a more thorough picture of when an IAM user or root account was last active, which enable you to rotate old keys and remove inactive users with greater confidence. You can view access key last used data interactively in the IAM console, programmatically via the API/CLI/SDK, or in the contents of an IAM credential report.
This blog post will show you how to determine when an IAM user’s or root account’s access keys were last used and how to download a snapshot of access key last used information for your entire account. (more…)
Last month, the AWS Security Blog encouraged you to adhere to AWS Identity and Access Management (IAM) best practices. One of these best practices is to lock away your AWS account (root) access keys and password, and not use them for day-to-day interaction with AWS. In fact, when it comes to your root account access keys, we recommend that you delete them. How, though, do you determine if your root account even has access keys?
In the past, the easiest way to determine if your root account had access keys was to sign in to the AWS Management Console using your root account password, which is something we recommend against doing regularly. Instead, you should enable multi-factor authentication (MFA) on your root account, and then you should only sign in with your root account when absolutely necessary. Furthermore, if you wanted to determine programmatically whether your root account had an access key, the only way to do it was to use the root account access key, which is an obvious dilemma. Now, though, it’s possible by using the AWS Command Line Interface (CLI) or the AWS SDKs to use the credentials of an IAM user to determine whether your root account has access keys. For the rest of this post, I’ll show you how you can use the AWS CLI to check if your root account has access keys. (more…)
One of the advantages of using the AWS SDKs for programmatic access to AWS is that the SDKs handle the task of signing requests. All you have to do is provide AWS credentials (access key id and secret access key), and when you invoke a method that makes a call to AWS, the SDK translates the method call into a signed request to AWS.
The AWS SDK team has recently made some changes that make it more convenient, more consistent, and easier to specify credentials for the SDKs in a more secure way. In this post, we’ll review the changes. (more…)
Some customers have asked how they should be using AWS Identity and Access Management (IAM) to help limit their exposure to problems like those that have recently been in the news. In general, AWS recommends that you enable multi-factor authentication (MFA) for your AWS account and for IAM users who are allowed to perform sensitive operations in your account. We also recommend that you use constrained, role-based access whenever practical, and that you do not use root credentials for everyday access to your account.
The list below provides links to best practices and how-to guides that show you how to help safeguard against the types of problems that people have asked about, and against many more.
- IAM Best Practices. A list of recommendations in the IAM documentation for managing your AWS access keys and passwords, using IAM users and groups, using roles and delegation, and turning on logging.
- Securing access to AWS Using MFA (Part 2, Part 3). A multi-part series that shows you how to use MFA to add security to your account. For a quick video, try Improve the security of your AWS account in less than 5 minutes.
- A safer way to distribute AWS credentials to EC2. A post that walks you through the process of making access keys available in a secure and convenient way to applications that are running on EC2 instances.
If you have any questions about these recommendations, or about how to help secure your AWS account, please post them to the AWS Forum.
The AWS SDK team recently added and documented some security-related features that we think you shouldn’t miss. Check these out!
Updates for managing access keys in the .NET and Java SDKs. In Referencing Credentials using Profiles, blogger Norm Johanson describes how you can now put a credentials file in your user folder. This great security enhancement makes it easier to keep access keys in a safe and secure location when you use the SDKs, as we recommend in our best practices for managing access keys. You can also keep multiple configuration profiles (as you can for the AWS CLI), which makes it very easy to test code using the credentials for different users. These features are available in both the .NET SDK and the Java SDK.
Encryption features for Amazon S3. In Using AmazonS3EncryptionClient to Send Secure Data Between Two Parties, blogger Hanson Char describes a little-known feature—how to securely share proprietary data on S3 using a public/private key pair. This feature is available in the .NET, Java, and Ruby SDKs. And in Amazon S3 Client-Side Authenticated Encryption, Hanson alerts us to a new feature of the Java SDK that enables you not only to keep S3 data encrypted at rest, but to enhance the security of the data with a new feature that adds an integrity check for both the data and the envelope key.
To keep up with the fast-moving AWS SDK team, be sure to subscribe to their blogs—you can find their blogs under AWS Blogs on the side of this page.
Keeping your AWS keys secure is one of the most important things you can do. This week Will Kruse, Security Engineer on the AWS Identity and Access Management (IAM) team, explains the steps to safeguard your account in the event you inadvertently expose your AWS access key.
Your AWS credentials (access key ID and secret access key) can be the literal keys to your account. If somebody has a copy of those credentials, she can perform any action in your account permitted by the policies associated with those credentials, such as launching an Amazon EC2 instance and storing objects in Amazon S3. Therefore, just like you’d never hand over the keys to your home to a complete stranger, you should never share your AWS credentials. (more…)
As part of our ongoing efforts to help keep your resources secure, on April 21, 2014, AWS removed the ability to retrieve existing secret access keys for your AWS (root) account. See the updated blog post Where’s My Secret Access Key? for more information about access keys and secret access keys.