Getting Started with AWS (Part 13)

If you would like to read the other parts in this article series please go to:


We’re almost at the end of this short series of articles on how you can get started using Amazon Web Services (AWS) using their Free Tier offering. It may be helpful therefore if we summarize what we’ve already covered in the previous articles of this series, and that’s what the table below is designed to do:

Article Topic
Part 1 AWS Free Tier
Part 2 AWS management tools
Part 3 Securing your AWS account
Part 4 Identity and Access Management (IAM)
Part 5 IAM console
Part 6 Creating users
Part 7 Multi-factor authentication (MFA)
Part 8 Permissions
Part 9 Policies
Part 10 Custom policies
Part 11 Custom policies continued
Part 12 Roles and delegation

Table 1

As you can see from the above table, a large part of this series has focused on how you can use the Identity and Access Management (IAM) web service to centrally manage the users, groups, roles, permissions and credentials of your AWS environment. Because most organizations who use AWS for commercial purposes will do so using a team approach that includes application developers, testers, and administrators, it’s important to be able to understand how multi-user AWS environments can be properly secured and administered. And that’s basically what IAM is for, which is why we’ve spent so much time examining it in detail.

Any system for authentication and access control however is only as secure as it can be effectively audited. That’s because problems, both unintentional (accidental) and intentional (malicious) simply will happen from time to time, so it’s important to be able to have a record of what occurred so you can examine and analyze it afterwards. This article briefly examines the topic of auditing your IAM environment within your larger AWS environment. As we’ll see, there are several ways you can do this depending on what kind of information you may need in your situation.

Credential reports

Back in Part 5 of this series we mentioned that IAM included an option called Credential Report that lets you download a report that lists all your account’s users and the status of their various credentials. To download a Credential Report, start by selecting the Credential Report menu item on the left side of the IAM Console as shown here:

Figure 1: How to download a credential report using the IAM console.

When you click the Download Report button, a credential report is created and is downloaded from via your web browser to your administrator workstation. This report is in comma-separated values (CSV) format. The filename of the report includes the date and time (in GMT) for example status_reports_2015-06-10T19-53-53+00-00.csv. You can then open the report in Microsoft Excel. At the time of writing, the columns (properties) included in a credential report are as follows:

  • user
  • arn
  • user_creation_time
  • password_enabled
  • password_last_used
  • password_last_changed
  • password_next_rotation
  • mfa_active
  • access_key_1_active
  • access_key_1_last_rotated
  • access_key_1_last_used_date
  • access_key_1_last_used_region
  • access_key_1_last_used_service
  • access_key_2_active
  • access_key_2_last_rotated
  • access_key_2_last_used_date
  • access_key_2_last_used_region
  • access_key_2_last_used_service
  • cert_1_active
  • cert_1_last_rotated
  • cert_2_active
  • cert_2_last_rotated

One useful property is the one named password_last_used which allows you to see when a user’s credentials were last authenticated by IAM. For example, when I view this property for users Bob_Smith and Mary_Jones in my AWS environment, the report shows that Bob was authenticated quite recently but Mary hasn’t been using AWS for a couple of months:

  • Bob_Smith – 2015-06-10T19:20:09+00:00
  • Mary_Jones – 2015-04-03T00:48:37+00:00

Of course manual auditing like this is tedious but it can be useful in smaller AWS environments. But there are some other options available and we’ll briefly examine these now.

IAM event logging

Another method of auditing your environment involves using an AWS service called CloudTrail. CloudTrail logs sign-in events and authenticated API calls for AWS services and records the information in log files that are stored in Amazon Simple Storage Service (Amazon S3) buckets (scalable object storage containers). As an administrator of your AWS environment you can then examine these log files to answer questions like:

  • Who accessed a particular AWS service?
  • When was the service accessed by the user or application?
  • What API requests were made to the service?

CloudTrail logs authenticated requests such as using IAM to create a new user, display a list of groups, delete a particular role, and so on. CloudTrail does not log unauthenticated requests where no user credentials have been used for making the request.

CloudTrail also logs sign-in events, for example when a user signs on to the AWS Marketplace or logs on to the AWS Management Console to perform some administrative task. And while CloudTrail does log sign-in failures, it doesn’t record the text the user entered into the username field of the AWS sign-in dialog. The reason for this is to avoid situations where a user accidentally types their password into the username field instead of the password field. If this happened and the text the user typed was recorded, someone examining the log would be able to know the user’s password.

To learn how to enable CloudTrail in your environment and use it for IAM event logging, see the AWS CloudTrail User Guide.

Exporting IAM settings

Another thing you can do if you want to audit the security of your AWS environment is to export your IAM settings. Exporting IAM settings basically creates a snapshot of the users, groups, and roles you’ve created in IAM. By doing this periodically you can compare snapshots and look for changes that might indicate problems with the security of your environment. Exporting your IAM settings also indicates which access control policies are attached to the users, groups, and roles in your environment.

Exporting your IAM settings can be done by using the AWS command line to run the get-account-authorization command. The output from this command is formatted in JavaScript Object Notation (JSON). (JSON syntax was briefly described in Part 9 of this series.) You can find out more about exporting IAM settings in this post on the Amazon AWS Security Blog.

Guidelines for AWS auditing

If you’re going to be auditing the security of your AWS environment then it’s good to have a plan. As with auditing any IT environment, the key is to audit what you need but not to audit too much, otherwise the “noise” you collect may make it difficult for you to find the information you need to know about your environment. In this regard Amazon has a helpful collection of guidelines for auditing the AWS security, and at a minimum you should carefully review these guidelines before you implement any auditing plan of your own.

Third-party solutions

Finally, there are a number of third party solutions available for auditing and monitoring various aspects of your AWS environment. The following short list is meant to be representative of what is currently available but is by no means exhaustive of the possibilities around:

  • Scout2 is an open source tool that helps assessing the security posture of AWS environments
  • Tenable has a Nessus plugin that enables you to audit your AWS infrastructure
  • Security Monkey is a solution for monitoring and analyzing the security of our Amazon Web Services configurations

There are also solutions available like Xsuite that provide not just auditing but also a full identity management solution for your AWS environment.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top