- [Rudy] You're probably producing lots of honey by this time and want to ensure that everything is operating smoothly in your colony. This means auditing who's doing what, what is being done, and are there ways to improve security and compliance across the board. Essentially, you're inspecting your infrastructure and service usage to make sure that nobody is winging it in your system. The first AWS service that we will explore is called AWS CloudTrail. It enables you to see who is doing what in your AWS infrastructure. You can track user usage of the console API calls, AWS SDKs, command line tools, and other AWS services themselves, so that you know who's interacting with your infrastructure. The best part is that it's enabled by default and you can view account activity for the past 90 days right in the CloudTrail console. How cool is that? This allows you to see who's interacting with specific components in your system and can therefore help you trace an errant change or maybe find out who's been taking data out of your S3 bucket without permission. You can even go further and direct CloudTrail events to Amazon S3, Amazon CloudWatch Events logs, and events. This allows you to perform analysis, archive events, and even remediate on an unexpected change. As a best practice, we recommend looking into this service early on in your AWS journey, as you can build in safeguards and auditing, so that if you ever need to produce the data, you'll have it ready for auditors. Next up is AWS Config, which is an auditor's dream for configuration management. This fully managed service records your AWS configuration, changes to that configuration, or a history, if you want to think about it, and even change notifications, so you're notified proactively. Say you've configured all your AWS resources, but since you've got a whole team of busy bees, you might not know who's been configuring what across the team. Fire up Config, and it will discover these existing AWS resources and generate a full inventory, along with all the actual configuration details, for you. You can then determine how a resource was configured at any point in time. You can even tie this into the aforementioned AWS CloudTrail, so that you gain full visibility into who made the actual change at that point in time and what the change was. For example, say we configured a custom rule to check if an S3 bucket should have non-public access. We can then trigger that rule whenever a change is made, i.e., change-triggered, or we can run it in a periodic fashion, like say, every 1 or 6 hours. If that rule picks up that public access has been enabled, we can execute a Lambda function to go in and correct access to non-public. The next service we recommend is called Amazon Inspector. This Inspector "gadget" helps to improve security and compliance of your AWS deployed applications by running an automated security assessment. This way, you can avoid a "penny for your thoughts" and instead, use the brain built into Inspector itself to check on deviations of security best practices, exposure of EC2 instances, even vulnerabilities. The service consists of three parts - a network configuration reachability piece; an Amazon agent, which can be installed on EC2 instances; and a security assessment service that brings them all together. It works by running an assessment based on your specific configuration choices and then outputting a list of findings for potential security issues. The resulting findings are displayed in the Amazon Inspector console, and they are presented with a detailed description of the security issue and a recommendation on how to fix it. Additionally, you can retrieve findings through an API, so as to go towards the best practice of automating your remediation processes. I mean, wowser, that's pretty cool. This means you get all the info in a ready-to-consume fashion in both avenues. Kind of a way to go-go Inspector gadget. The last service we'll touch on in this video is called Trusted Advisor. This service assists you in provisioning your AWS resources using best practices. It then produces a report under five different categories - cost optimization, performance, security, fault tolerance, and even service limits. Once you run Trusted Advisor, you will be presented with a report that you can then drill-down into. Each category will produce traffic light-based recommendations. These go in increasing severity, where green means no action recommended, orange for investigation needed, and red for action recommended. Since we're diving into security in this course, I want to highlight some of the best practices that are scanned and reported on in the Security section, itself. Some of these include S3 bucket permissions, so whether you can actually access a bucket publicly or privately; security groups, whether your ports are unrestricted, so you can go in and configure rules to close those actual loops; IAM use, so usage of users, roles, policies, and so forth. This is sometimes a mind-bender to figure out, kind of the correct way to provision your IAM resources, but stay the course, and you'll be guided by this report if you're lost. We've also got MFA on root account, so that's whether you're using a multi-factor authentication tool on your root account itself; exposed access keys, make sure your access keys are not hard-coded somewhere; and IAM password policies - rotation of passwords is pretty important, so make sure that you do not let your credentials become stale. It should also be noted that some of these checks are free and some incur a cost. So, for a complete list of checks, check out our Resources section. And again, thank you for watching, and see you soon.
