If you would like to read the other parts in this article series please go to:
- Secure services and resources with AWS Identity and Access Management (Part 1)
- Secure services and resources with AWS Identity and Access Management (Part 2)
- Secure services and resources with AWS Identity and Access Management (Part 3)
- Secure services and resources with AWS Identity and Access Management (Part 5)
Introduction
In this multi-part article, we’re discussing how to use AWS Identity and Access Management (IAM) to create and manage users and groups and assign permissions to them so as to granularly control how they can access your AWS resources. In Part 1, we talked about IAM basics: how it works, users and groups, authentication and credentials. We then introduced the concept of IAM policies. In Part 2, we delved more deeply into the subject of IAM policies, permissions, and roles, as well as how to integrate IAM into a federated environment. In Part 3, we continued the discussion of policies with some specifics about how you work with managed policies using the AWS Management Console and the AWS command line interface.
Introduction to CloudTrail
You might not be familiar with Amazon CloudTrail, since it is one of the many, many services that AWS offers. CloudTrail is important to AWS users who need to keep track of changes and perform security analyses, which is almost all of us in this highly regulated IT world that we live in today. If your organization is subject to governmental or industry compliance mandates, CloudTrail can assist you in providing the information that will inevitably be requested for compliance audits.
Even if you’re lucky enough to be operating in a company that isn’t legally or contractually required to document and prove that you’ve implemented specific levels of security, it’s smart business practice to maintain a high degree of visibility into what your users are doing. After all, deliberate or unintentional compromises by users constitute a large percentage of the causes of security breaches today.
CloudTrail works by recording the API calls for your account and recording this information in logs that it then provides for you. This means a good deal of useful information about the user making the call and the call itself: user’s identity, source IP address from which the call came, the time that the call was made, the parameters of the request and the response that was returned by the AWS service being used. This includes calls made through the Management Console, command line utilities, SDK and higher-level services.
CloudTrail supports a long list of AWS services, including EC2, EBS, CloudFront and Glacier, RDS, Redshift, and other databases, Amazon Virtual Private Cloud, the Simple Que Service and Simple Notification Service, AWS Directory Service and a whole slew of others – including, most relevant to this discussion, AWS IAM.
CloudTrail Feature Set
What does this mean to you as an AWS admin? It means you have much more information and control over what is happening with your AWS services. You can determine what user performed a certain action, or detect patterns of behavior of specific users. You can find out which users are accessing specific services and when. You can also see which actions users may have tried to perform and were unable to do so because they didn’t have the proper permissions, which can give insight into attempts by insiders to circumvent your restrictions.
The log files are delivered to you quickly, which can be important in the case of actions that might result in security breaches and you can set CloudTrail up to send you a notification when a log file is delivered. You can also configure it to send SNS notifications if a particular activity is performed. With CloudWatch, you can set up monitoring of CloudTrail events and have email notifications sent to you when the specified events occur. Amazon provides editable CloudFormation templates to make it easy to predefine CloudWatch metric filters and alarms for this purpose.
The log files are stored in the S3 storage service and if you have a large number of files, you can even set it up so that the old log files get archived automatically to Amazon Glacier long-term storage, which will cost you less (but will take longer to retrieve). You can aggregate log files across accounts and regions to the same S3 bucket, to make it easier to find and access them.
Speaking of cost, the good news is that CloudTrail is free. Well, sort of. There’s no extra charge to use the logging service. The bad news is that you do have to pay for the use of Amazon S3 storage space that the logs use, and also for the use of the Simple Notification Service if you want to be notified – although typically the amount of resources that would be utilized by CloudTrail is small and the additional charges would add up to a negligible amount (Amazon says it’s well under ten dollars per month for the majority of customers). Of course, your mileage may vary – hey, Verizon says their typical customer will never need more than 2 GB per month of mobile data but my husband and I find that we are somewhat atypical. CloudTrail also integrates with CloudWatch, and the standard pricing for CloudWatch Logs and other charges will apply when you use CloudTrail together with it.
How to use CloudTrail
The CloudTrail service is there, as an option in your AWS account, but it’s turned off by default so you’ll need to first enable it in order to start using it. You can easily turn it on by using the AWS Management Console, and it only takes a couple of clicks.
When you enable CloudTrail, you do it for a particular region, so if you are using more than one region for AWS, you will need to enable it for each region separately. As mentioned before, you can aggregate all the logs from the different regions into just one S3 bucket, but you don’t have to. You can have separate buckets for each region if you prefer. Be aware, though, that not all regions support CloudTrail. At the time of this writing, it’s supported by the following regions in the United States, Europe, Asian Pacific and South America:
- US East
- US West
- US GovCloud
- EU (Ireland)
- EU (Frankfurt)
- AP Northeast
- AP Southeast
- SA East
Security
Of course, with any kind of cloud service, security is always a concern. How often have we heard the stories about software and services that were designed to help with security compliance that ended up posing security risks of their own? All that information that’s collected by CloudTrail regarding your user activities could be used against you by a cybercriminal, so it makes sense to be concerned and want to know exactly how secure that data is.
The log files that are generated by CloudTrail are encrypted by default before being moved into your Amazon S3 storage bucket(s). You can use S3 multi-factor authentication (MFA), which we discussed in a previous article, to increase the security level on the log files. Specifically, the feature in S3 is MFA Delete, which will not let anyone permanently delete an object version or change the versioning state of the bucket unless they provide two forms of authentication.
The two forms of authentication that are required for MFA Delete consist of your normal security credentials (user name and password) and a second factor that is a number created from combining a valid serial number and the six digit code that is displayed on the approved authentication device, separated by a space. The authentication device can be a virtual device created in software running on a smart phone or tablet, or it can be one of two types of hardware authentication devices: a key fob device or a display card device. The hardware devices can be purchased from Amazon for under twenty dollars each. The virtual device is free and can be used with any TOTP (Time-based One Time Password) application.
Note:
Keep in mind that only the owner of the Amazon S3 bucket is allowed to enable MFA Delete on a bucket.
In addition to this protective mechanisms, you can also apply IAM or S3 bucket policies to the data in the buckets.
What gets logged
You might be wondering exactly what IAM data gets logged by CloudTrail. Following are some examples:
- Sign-in events: when users or the AWS account sign into AWS services, both failed and successful sign-in events are recorded in the log. Some information from failed sign-ins is not logged when that information could potentially result in a security breach (example: a user accidentally types his/her password into the user name field).
- API requests to the IAM and AWS Security Token Service: authenticated API requests are all logged with one exception (DecodeAuthorizationMessage). Requests that are not authenticated are not logged.
- API requests to other AWS services: User information is logged when a user signs into another supported Amazon service such as EC2 or EBS.
Summary
In this, Part 4 of our series on AWS Identity and Access Management, we introduced and discussed the CloudTrail logging service and how it works with IAM to make it easier for you to track user activities and events both for your own security and control and as part of a compliance audit trail. Next time, in Part 5, we’re going to wrap up the series with some tips regarding how to troubleshoot common problems with IAM.
If you would like to read the other parts in this article series please go to:
- Secure services and resources with AWS Identity and Access Management (Part 1)
- Secure services and resources with AWS Identity and Access Management (Part 2)
- Secure services and resources with AWS Identity and Access Management (Part 3)
- Secure services and resources with AWS Identity and Access Management (Part 5)
