From the course: Complete Guide to the AWS Well-Architected Framework

Security pillar overview - Amazon Web Services (AWS) Tutorial

From the course: Complete Guide to the AWS Well-Architected Framework

Start my 1-month free trial Buy for my team

Security pillar overview

“

- [Instructor] The security pillar of the well-architected framework is going to provide you with details of proper design principles for security, the best practices to consider following, and a lot of questions that you can ask yourself and discuss amongst your team to design the best security pillar for your application that you can possibly design. We want to protect the information contained in our application stack, all that information that is pertinent to your company that you have to keep secure. We also need to secure the systems that hold onto that information or that are computing and running your application stack and all of the associated assets. So there's a lot of moving parts in the security pillar. We also have to monitor everything that's running. You can see the integration between the security pillar and the previous operational excellence pillar, where we still need to monitor to find out what's going on. Perhaps you could argue it's a little more pertinent in the security of your application to know whether or not there's potential problems in your application, be alerted to the problems, and be able to solve those issues. You'll probably also have an auditor that wants to have a certain level of auditing going on to actually alert everybody when there's a potential problem or change in your environment. And we want to learn how to design using the principle of least privilege. I'm only giving you what you need, nothing more. Fairly standard design for security in the cloud is what's called a defense-in-depth approach. You have a two-tier or three-tier stack and many different managed services all working together. We want security controls at all layers. In fact, when you order a service at AWS, Amazon will actually put controls on what that service is allowed to do. So we have control for every component at every level in our application stack. This is what we're trying to achieve. Now, in order to achieve this, we want to use some of the tools at Amazon or replace them with equivalent third-party tools. First up, identity and access management, which allows us to control access to anything in our account. Who are you? I'll identify you first. Now that I've identified you, I'll either deny you access or give you a certain amount of access and prescribe how long you can actually carry out that task. One of the big questions that's asked in the security pillar is how do you control human access to your application stack from the administrative point of view, to the end user point of view? We have to set requirements to reduce the risk and reduce any unauthorized access. Detective controls is a term invented by Amazon to describe a number of services that can actually act like detectives and monitor what's going on in your application stack and give you information as to what's going on. For example, CloudTrail collects all of the API calls that happen within your AWS account. It also tracks anybody that authenticates to your account. Config can be defined to control the level of compliance that's acceptable in your account, complete with rules. For example, you could define I'm creating an S3 bucket, but it has to be encrypted, and if somebody created an S3 bucket and didn't encrypt the bucket, you could be alerted. There's also a lot of infrastructure protection to consider. I've got EC2 instances, my virtual servers, I must place them nowadays in a virtual private cloud, a private network. Best practice, put everything on private subnets. Make it as safe as possible. For data, we should encrypt whether the data's at rest or in transit. In fact, I can encrypt any data records at AWS. I can turn on encryption for any service that's operating data storage. Finally, what happens when there's a breach? How do you respond to that incident? Is it manual, or as you would expect, best practice, we'd like to automate that. So some best practices to consider for the security pillar of the well-architected framework.

Contents