Taking ownership of an Amazon Web Services account can be a daunting task. In this course, Auditing AWS for Security and Best Practices, you'll learn how to audit your AWS services, including command-line tools and scripts to help automate your effort. First, you will learn how to look for security vulnerabilities. Next, you'll learn how to take an inventory of your resources. Finally, you'll learn about best practices for these services and how to apply them. When you're finished with this course, you will have learned the basics needed to implement security and architectural best practices in five of the most popular AWS offerings: IAM, VPC, EC2, EBS, and S3. Software required: AWS CLI
Course Overview Hi everyone. My name is Chad Smith, and welcome to my course, Auditing AWS for Security and Best Practices. I am a Linux admin, an AWS systems architect, and certified trainer. The Amazon Web Services Cloud is the most widely used in the world. This course is a primer on how to audit your AWS services and resources, and prior experience with the Amazon Cloud is recommended. Some of the major topics that we will cover include auditing services for security, creating inventory of AWS resources, and auditing architecture for best practices. By the end of the course you'll have a foundation for starting your own audit of an AWS account, including command line tools and scripts to help with inventory and operations. I hope you'll join me on this journey to learn AWS with the Auditing AWS for Security and Best Practices course at Pluralsight.
Auditing EC2 We have completed the user and network access portion of the audit. In module one we looked at the IAM objects and their usage. Once we had a handle on the authentication and authorization in module two we moved onto the network infrastructure. In the VPC we audited the configuration, as well as the ingress and egress points. Now it's time to start looking at the resources that we can launch into the VPC. Of these EC2 is the most common, and we'll focus on that in our next module. EC2 stands for Elastic Compute Cloud, and is comprised of virtual machines running Windows or Linux that you launch into AWS provided hardware and virtualization. We'll break this up into two sections, and cover security features in the first, then inventory and best practices in the second. To understand how to audit EC2 we need to take a step back. We'll cover a critical concept regarding security in AWS called the Shared Responsibility Security Model. That sets the table, so that we can discuss how the hypervisor fits into that model. Then we can move on to keypairs, and security groups, then finish up the section with a demo on a visual way of auditing security groups using AWS Config.
Auditing EBS In our last module we covered the compute resources of EC2 that you can launch into your VPC, but we didn't discuss the volume objects that can be attached to your instances. Any audit of AWS will require a full accounting of the storage resources, as this can be a significant part of the monthly bill. We'll start with some basics on the EBS volumes, then discuss security and encryption, spend some time on how you can inventory these volumes, and finish up with some best practices. It's very important to understand that EBS, which stands for Elastic Block Storage, consists of network attached volumes. Each volume is presented as a raw block device to the instance, and can be formatted with any file system. The scope of this service is AZ, which means it can be used as a building block for highly available architectures, but isn't natively very highly available or fault tolerant. AWS is very clear in the documentation, an SLA for EBS, that the average volume failure rate will decrease as you take more frequent snapshots. This is a critical recommendation in that your rate of return on snapshots is as good or better than using software raid for increasing data durability.
Auditing S3 In the previous modules we discussed services that rely on the customer for the majority of the implementation. For our audit we have covered access to the resources, the network, the computer infrastructure, and block storage. In our final module we will cover object storage in S3, which can be considered the sticky glue that holds together many AWS workflows that require a storage repository. Our audit will require an accounting of the resources we have stored in S3, and we need to understand how this service works, as well as how to secure it before we can take our inventory. We'll start with the basics, then cover security, a few examples of inventorying our S3 buckets, and finish up with the discussion of best practices. S3 stands for simple storage service. It is an object store, which is not to be considered anything like a file system. There's no concept of editing objects inline. The only way to change an object is to upload the updated copy to the object store where it will override the previous version. Objects are available online natively. Each object can be referred to by a unique URL, and the default permissions make the object available only to the account owner. The service is fully managed, meaning that you have no access to the underlying infrastructure, hypervisors, operating systems or software. AWS calls S3 and other services like it abstracted services. Services that fall into this designation actually leave the least amount of work to the customer from a security perspective. You're only given an endpoint to work with the service. All you need to do is place your data, then configure access and encryption. There aren't many other levers to pull.