Category: Announcements

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.

-Kai

Here on the AWS Security Blog we’ve published several posts that recommend IAM best practices. We’re pleased to find that third-party bloggers are adding their own voices.  Codeship, a company that provides a continuous code deployment and testing service, just published a great post about how to secure your AWS account using Identity and Access Management (IAM) features.  Some of the recommendations include using IAM users, MFA, and roles for EC2. There’s plenty more in the blog post—check it out!

– Ben

Today AWS announced support for adding multi-factor authentication (MFA) for cross-account access. In this blog post, I will walk you through a common use case, including a code sample, which demonstrates how to create policies that enforce MFA when IAM users from one AWS account make programmatic requests for resources in a different account.

Many of you maintain multiple AWS accounts, so I am frequently asked how to simplify access management across those accounts. IAM roles provide a secure and controllable mechanism to enable cross-account access. Roles allow you to accomplish cross-account access without any credential sharing and without the need to create duplicate IAM users. With today’s announcement, you can add another layer of protection for cross-account access by requiring the users to authenticate using an MFA device before assuming a role.

Imagine your company maintains multiple AWS accounts: Development, Staging, and Production. Let’s assume you want to centralize the access management of all these “child” accounts using a single “parent” account that contains your IAM users. (more…)

The newly released Security at Scale: Logging in AWS whitepaper is designed to illustrate how AWS CloudTrail can help you meet compliance and security requirements through the logging of API calls.  The API call history can be used to track changes to resources, perform security analysis, operational troubleshooting and as an aid in meeting compliance requirements. (more…)

(more…)

We established the Security Blog in April 2013 to provide you with guidance, best practices, and technical walk-throughs to help increase the security of your AWS account and better achieve compliance. Hopefully you have been able to read all of the posts published in 2013, but in case you’ve missed a few, here is an index of our in-depth posts:

IAM

We posted a mixture of prescriptive guidance and detailed explanations about released Identity and Access Management features and best practices geared towards practitioners.

• Where’s my secret access key?
• A safer way to distribute AWS credentials to EC2
• IAM policies and Bucket Policies and ACLs! Oh My! (Controlling Access to S3 Resources)
• Guidelines for when to use Accounts, Users, and Groups
• How to rotate access keys for IAM users
• Improve the security of your AWS account in less than 5 minutes
• Securing access to AWS using MFA – Part I
• Securing access to AWS using MFA – Part 2
• Securing access to AWS using MFA – Part 3

(more…)

Make a New Year Resolution for 2014 to adhere to best practices put forth by AWS Security and Identity.  There are two great pieces of work published in 2013 that are filled with guidance and are highly actionable.  AWS published the Security Best Practices whitepaper, providing a landscape of various security oriented technologies, including IAM, encryption, and compliance reporting.  The Security Blog post that outlined the whitepaper was the second most popular post of the year (behind  Writing IAM Policies: How to grant access to an Amazon S3 bucket), illustrating the importance and interest of cloud security topics.

The other piece of work to reference is IAM’s Top Ten Best Practices session at re:Invent.  I encourage you to view the recorded session, but here’s a quick rundown to get you started:

1. Lock away your AWS account access keys
2. Create individual IAM users
3. Use groups to assign permissions to IAM users
4. Grant least privilege
5. Configure a strong password policy for your users
6. Enable MFA for privileged users
7. Use roles for applications that run on Amazon EC2 instances
8. Delegate by using roles instead of by sharing credentials
9. Rotate credentials regularly
10. Use policy conditions for extra security

Use these security best practices to help make your AWS account as secure as possible.  Not only will you find more peace of mind but hopefully even greater control as you expand your use of AWS.

– Jim

The .NET Developers Blog recently published two easy-to-read posts about access key management for .NET applications.  The first one goes through some of the background of access key management, as well as the use of IAM roles for EC2.  The second post goes deeper into creating and using IAM users and groups instead of using root access.  The next post will discuss rotating credentials.  In the meantime, if you would like a detailed description of rotating access keys, the Security Blog published a post in early October.

– Ben

David Murray  published a great post about best practices for IAM credentials earlier today (December 9th).  He gives a high level description of IAM, followed by methods for using IAM roles for EC2.  To learn more go to the Java Developers Blog.

– Ben

We are pleased to announce that AWS OpsWorks now supports resource-level permissions. AWS OpsWorks is an application management service that lets you provision resources, deploy and update software, automate common operational tasks, and monitor the state of your environment. You can optionally use the popular Chef automation platform to extend OpsWorks using your own custom recipes.

With resource-level permissions you can now:

• Grant users access to specific stacks, making management of multi-user environments easier. For example, you can give a user access to the staging and production stacks but not the secret stack.
• Set user-specific permissions for actions on each stack, allowing you to decide who can deploy new application versions or create new resources on a per-stack basis for example.
• Delegate management of each OpsWorks stack to a specific user or set of users.
• Control user-level SSH access to Amazon EC2 instances, allowing you to instantly grant or remove access to instances for individual users.

(more…)