Identity federation enables your enterprise users (such as Active Directory users) to access the AWS Management Console via single sign-on (SSO) by using their existing credentials. In Security Assertion Markup Language (SAML) 2.0, RelayState is an optional parameter that identifies a specified destination URL your users will access after signing in with SSO. When using SAML-based identity federation in AWS, you can use RelayState to redirect your signed-in, authenticated users to any AWS console page, such as the Amazon EC2 console in Tokyo or a specific Amazon S3 bucket page.
In this blog post, I will show you how to create a deep link for federated users via the SAML 2.0 RelayState parameter in Active Directory Federation Services (AD FS). By using a deep link, your users will go directly to the specified console page without additional navigation.
Note: If you are not using AD FS as your identity provider (IdP), check to see if your IdP supports the RelayState parameter. If it does, you can follow similar steps with your IdP to achieve the equivalent of my AD FS configuration. (more…)
In December, AWS Identity and Access Management (IAM) released service last accessed data, which shows the time when an IAM entity (a user, group, or role) last accessed an AWS service. This provided a powerful tool to help you grant least privilege permissions. Starting today, it’s easier to identify where you can reduce permissions based on additional service last accessed data.
With this release, you have access to the following for IAM entities and policies:
- Last accessed data for all IAM users and roles associated with a managed policy or group.
- All policies contributing service permissions to an IAM user, role, or group.
These additional details can improve your understanding of access patterns and policy configurations. As a result, you can make better-informed permissions-management decisions.
In this blog post, I will walk through these new, more-detailed service last accessed capabilities and explain how you can use them to manage permissions more effectively. (more…)
AWS Config recently added the ability to record changes to the configuration of your AWS Identity and Access Management (IAM) users, groups, and roles (collectively referred to as IAM entities) and the policies associated with them. Using this feature, you can record configuration details for these IAM entities, including details about which policies are associated with them. AWS Config automatically records changes to any of these resources, and gives you a full history of the previous configurations for these resources. With this information, you can determine, for example, if an IAM user has used policies that gave him access to certain resources or if certain actions were permitted at any point in the past. The AWS Config console includes a timeline view of this information.
AWS Config also recently launched AWS Config Rules in the US East (N. Virginia) region. Config Rules enable you to set up rules that check the validity of changes made to resources being tracked by AWS Config. These rules can be set up to evaluate each change to the configuration of a resource or to evaluate changes at a set frequency, and you can author your own rules in any language supported by AWS Lambda.
Using Config Rules on IAM resources, you can codify your best practices for using IAM and assess the compliance state of these rules regularly. In this blog post, I will show how to start recording the configuration of IAM resources, and author an example rule that checks whether all IAM users in the account are using a sample managed policy, MyIAMUserPolicy. I will also describe examples of other rules customers have authored to assess their organizations’ compliance with their own standards. (more…)
Deleting unused resources can help to improve the security of your AWS account and make your account easier to manage. However, if you have ever been unsure of whether an AWS Identity and Access Management (IAM) user or role was being used actively, you probably erred on the side of caution and kept it.
Starting today, the IAM console shows service last accessed data as part of the process of deleting an IAM user or role. Now you have additional data that shows you when a resource was last active so that you can make a more informed decision about whether or not to delete it.
The following screenshot shows the new confirmation dialog box, which now displays the last activity date of the item selected for deletion. You can click last activity to see which services the resource used and when.
You don’t need to do anything to get started with this new experience: it is now available to all AWS customers in the IAM console.
The IAM team would like to hear your thoughts about this feature. If you have comments about this release, leave a comment below or on the IAM forum.
As another new year begins, we encourage you to review our recommended AWS Identity and Access Management (IAM) best practices. Following these best practices can help you maintain the security of your AWS resources. You can learn more by watching the IAM Best Practices to Live By presentation that Anders Samuelsson gave at AWS re:Invent 2015, or you can click the following links that will take you to IAM documentation, blog posts, and videos.
- Create and use IAM users instead of your root account
Do not use your AWS root account to access AWS. Instead, create individual IAM users for access to your AWS account. This allows you to give each IAM user a unique set of security credentials and grant different permissions to each user. Related: Documentation, blog posts, video.
- Grant least privilege
Apply fine-grained permissions to ensure that IAM users have least privilege to perform only the tasks they need to perform. Start with a minimum set of permissions and grant additional permissions as necessary. Related: Documentation, blog posts. (more…)
AWS supports Security Assertion Markup Language (SAML) 2.0, an open standard for identity federation used by many identity providers (IdPs). SAML enables federated single sign-on (SSO), which enables your users to sign in to the AWS Management Console or to make programmatic calls to AWS APIs by using assertions from a SAML-compliant IdP. Many of you maintain multiple AWS accounts (for example, production, development, and test accounts), and have asked how to use SAML to enable identity federation to those accounts. Therefore, in this blog post I will demonstrate how you can enable federated users to access the AWS Management Console with multiple AWS accounts and SAML.
If you use Microsoft Active Directory for corporate directories, you may already be familiar with how Active Directory and AD FS work together to enable federation, as described in the AWS Security Blog post, Enabling Federation to AWS Using Windows Active Directory, AD FS, and SAML 2.0. As a result, I decided to use Active Directory with AD FS as the example IdP in this post.
To automate both the installation and configuration of AD FS and Active Directory, I will use Windows PowerShell in this post. By leveraging Windows PowerShell, you eliminate the manual installation and configuration steps, and allow yourself to focus on the high-level process.
If you want to manage access to all your AWS accounts with Active Directory and AD FS, you’ve come to the right place! (more…)
My previous blog post on November 11, 2015, reported that we were preparing to activate AWS Security Token Service (STS) by default in all AWS regions. As of today, AWS STS is active by default in all AWS regions, for all customers. This means that your applications and services can immediately take advantage of reduced latency and multiregional resiliency by using the STS endpoint geographically closest to you. You can see the complete list of STS endpoints for all regions on the Regions and Endpoints page.
If you prefer to deactivate certain regional AWS STS endpoints in your account, you can visit the Account Settings page in the AWS Identity and Access Management (IAM) console. From the Account Settings page, you can see the regions in which AWS STS is currently active and deactivate AWS STS in specific regions. Only an account administrator (a user with at least iam:* permissions) can activate or deactivate AWS STS regions. Note that AWS STS endpoints in the US East (N. Virginia), AWS GovCloud (US), and China (Beijing) regions cannot be deactivated.
If you have any questions or suggestions, submit a comment below or on the IAM forum.
Today, AWS Identity and Access Management (IAM) made it easier to help you verify your permissions by adding support for resource-based policies in the IAM policy simulator. This extends the capabilities of the IAM policy simulator console and APIs to help you understand, test, and validate how your resource-based policies and IAM policies work together to grant or deny access to AWS resources.
In this blog post, I will walk through an example that uses an Amazon S3 bucket policy and an IAM managed policy. In this example, IAM users Jesse and Casey need read access to all S3 buckets, but only Casey should be able to access the production-data-iam bucket because it contains sensitive data. To grant read access to all S3 buckets in the account, you can attach the AWS managed policy AmazonS3ReadOnlyAccess to both Jesse and Casey. To restrict access to production-data-iam to only Casey, attach the following policy directly to the production-data-iam bucket. To learn more about the following policy, go to How to Create a Policy That Whitelists Access to Sensitive Amazon S3 Buckets. (Replace the placeholder account information with your account information.) (more…)
As I said last week, the breakout sessions for the Security & Compliance track have been announced and are shown in the re:Invent 2015 session catalog. If you are going to re:Invent 2015, you can add these sessions to your schedule now.
Today, I will highlight the AWS Identity and Access Management (IAM) sessions that will be presented as part of the Security & Compliance track.
In this session, AWS Principal Technical Program Manager Anders Samuelsson will cover IAM best practices, which can help improve your security posture. Anders will cover how to manage users and their security credentials. He’ll also explain why you should delete your root access keys—or at the very least, rotate them regularly. Using common use cases, Anders will demonstrate when to choose between using IAM users and IAM roles, and explain how to set permissions to grant least privilege access control in one or more of your AWS accounts. (more…)
AWS Identity and Access Management (IAM) has added two new APIs that enable you to automate validation and auditing of permissions for your IAM users, groups, and roles. Using these two APIs, you can call the IAM policy simulator using the AWS CLI or any of the AWS SDKs. Use the new iam:SimulatePrincipalPolicy API to programmatically test your existing IAM policies, which allows you to verify that your policies have the intended effect and to identify which specific statement in a policy grants or denies access to a particular resource or action. You can test the effects of new or updated policies that are not yet attached to a user, group, or role by calling the iam:SimulateCustomPolicy API. (more…)