As your organization grows, more and more people are going to need access to your cloud resources. The ability to create and assign granular permissions is crucial to ensure the safety of your data and to avoid unauthorized access to reserved information.
Identity and Access Management (IAM) is the AWS tool that gives you centralized control over your AWS resources. It allows you to create fine-grained policies using JSON syntax to grant unique privileges to each and every available resource. This course will tell you everything you need to know to get started hardening your infrastructure.
Who should take this course
As a beginner to intermediate course, you'll require no previous experience, nevertheless some knowledge of AWS and its main services (like EC2 and S3) would really help you better understanding the concepts you'll encounter. You may therefore want to check out other AWS courses before tackling this tutorial.
Do you have questions on this course? Contact our cloud experts in our community forum.
In this video, we'll explore monitoring user activity on your AWS account through CloudTrail logs. You really can't ever assume that everything on your account is happily chugging along by itself. Services can fail, devices can fall over, and hackers can infiltrate your instances. One excellent approach to dealing with the uncertainty is to enable and most importantly, to monitor event logs. Once an S3 bucket is set up through CloudTrail, and we'll show you how to do that soon IAM events like API calls and also AWS sign in events will automatically be collected.
Watching this information will show you all the successful or failed requests that were attempted against AWS services, along with important related details, like who generated the request and when it happened, what the results were, etc.
CloudTrail will log all API requests to IAM and AWS security token services, like create user, delete role, list groups.
It'll also log API requests to other AWS services. For instance, list requests against Amazon EC2 instances, and it'll include the requesting user ID or the service. And of course, perhaps most importantly, CloudTrail will log AWS sign in events, both successful and failed.
Let's go to CloudTrail, and we already have an S3 bucket set up. We're not going to create a new one because we have data that's already been collecting in this one, which we'd like to show you. However, let's edit or at least pretend to edit and click on advanced, to take a look at what you'll need in order to create your own bucket. Number one, you'll have to give it a unique name. This is a name that can't be replicated in any S3 bucket anywhere in the whole Amazon Cloud. You will have the option of including global services. You most definitely want to include global services, because IM does not restrict itself to any particular region, and is considered a global service. SNS notification for every log file delivery, you might want to enable that, just so you won't have to constantly come back to the S3 bucket yourself. There's always the risk that you'll just forget about it and never take a look. Let's cancel though, for now. And let's go take a look at our S3 bucket. Let's go back to the name, AWS-4, and click on S3. The bucket we created was of course called trail bucket 98987. We can click on this directory called AWS logs. And we're going to go down quite deep actually. CloudTrail tells us that these logs were generated by CloudTrail. These logs in particular came from instances in the US-east-1. They are from 2014. They're from October. And either October 28th or 29th. Let's look at the ones from the 28th, and let's select any one of those and click on actions. And then, open to view in a pop-up window, the data. This is kind of hard to read.
Therefore, let's take a look at a properly JSON formatted example, taken from AWS's documentation. It's a lot easier to read.
From this output, we can see that it relates to an account owned by Alice, which happens to be the same name, although it's entirely coincidental as one of the fictional users we created in our own account. The event occurred in 2014 07 08, which is probably July 8th, although could also be August 7th. I can never really remember which way you're supposed to read these things. At 17:35, that would be 5:35 in the afternoon. And it was a console login event. That is, Alice was trying to login, but it failed. She was sent an error message, failed authentication, and the console login was a failure. If, for instance, you had just recently removed Alice from your system, then you might like to be aware that she's still trying to break in. If on the other hand, you see a few of these, one after the other, and Alice is welcome in your account, then you may have to contact her about perhaps updating her password or to see if there's some other problem that she's encountering. Either way though, you'll want to be aware if there are unusual or failed events happening, one after the other, that might indicate either again, some attack or perhaps some user having unnecessary trouble. This hopefully gives you an idea of the scope of information that CloudTrail logs can make available to you, and how that can help protect and enhance the working of your Amazon account.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.