Design principles - Amazon Web Services (AWS) Tutorial

- [Instructor] Following the Well Architected Framework's security pillar is to follow a set of design principles that, over time, have been proven to enforce a very strong identity foundation. Identity is the key word here. Who are you? Oh, you're that person? You're that service? You're that computer system? Okay, you can carry out these tasks. Other ones you can't. So first up when, we're defining our security, we have to consider ensuring that we're following the principle of least privilege. You only have the permissions that you need to get the job done. We want to separate the duties, and once we've separated those duties as to what you're going to do at AWS, when you need access, you've got to be authorized to get that access. One way we can make security very strong at AWS is using something called a role. A role is temporary access. So if I assign you a role to, say, access storage, you only have temporary access. So when you need access to the storage, the role will provide temporary access to that storage entity, but not full-time access. In this way, we're removing the reliance on a long-term credential, and we'll talk about the security in more detail as we go through the class. We want to monitor, well, we know that, but we want to monitor at every stack level of our design. We want to respond to any changes in our environment in as real time as possible. So we have to monitor everything, including authentications and rejections. And in a sense, Amazon is helping us out, because we have CloudTrail, which holds onto all API calls in our AWS accounts and all authentications, so we can use that service to actually achieve this task. Therefore, if I know that something is wrong, somebody tried to get in to my account and they were rejected, I'd probably want to be alerted when that change occurred, and I probably want automatic actions to ensure that the problem is solved short-term and potentially long-term. I don't want any manual processes. We also want to secure every layer of my stack. The application stack, the database stack, the external networks, for example, that are connecting to AWS. So if I'm connecting to AWS with an external connection, maybe it's a VPN connection. Maybe it's a fiber connection connecting my data center into Amazon. Maybe that connection goes through a co-location. I have to make sure it's secure at every step. If I'm looking in Amazon, I will definitely have a virtual private cloud. That virtual private cloud is a connection of subnets. I can secure the sub-net using something called a NACL, a network access control list, controlling what gets in and what gets out. My EC2 instances can be controlled by a security group. Now, the NACL and the security group, they're firewalls, so I can control what gets to that instance, which is where my application is hosted. When users are accessing an application, it's running, as we know, on an instance, the instance hosted on a subnet, but the instance won't be exposed to the outside public world. I'll have a load balancer in front of that application to ensure that I've got some protection, more security at that layer. Finally, if the user is authenticating to Amazon, I can ensure that they're using a single sign on connection. This is a level of federation that is also very secure. We also want to, as mentioned, automate as many of the security best practices as possible. The controls at AWS are designed and managed as code, i.e., scripts, processes, so these controls can be automated. There really isn't anything that Amazon is offering that's going to be a manual process. If I'm using a role, remember, roles are for temporary access, the roles are processed and approved and denied by a service called the security token service. There's no manual processes here, everything's done in the background automatically. One of the most important things you can do, as I've said a few times in this class, is to monitor. CloudWatch is the monitoring solution embedded at AWS, and these servers that are used at AWS has metrics. I can design those metrics that, if I've got a certain level of performance or lack of performance that's being monitored by, say, a network metric, or a CPU metric, or maybe a queue metric, I can alarm, saying, here's a problem, and notify somebody. What I want to do, of course, is notify an automatic process. And one of the ways I can use CloudWatch is to set up alerts. The alerts are following the rules. When this happens, I need you to notify somebody. A common entity to notify for automation is Lambda, where I can have custom functions uploaded into Amazon that can carry out any task I want at AWS. And don't worry, they're secure, and they have to authenticate as well before they can carry out their tasks. There also might be a third party solution. For every service that we talk about at AWS, you might say, that's great, Mark, but I have a third party solution that I liked better. Fair enough. Just make sure you have the appropriate security controls. We also want to protect our data in transit and at rest, so we want to classify our data. What is data I'm not too worried about? What is data I'm very worried about? I should use encryption on all data records and all forms of communication. These are services offered by AWS. I also want to try to protect direct access to data records by setting up access controls. So maybe you can read the records, but you can't modify, or you can't copy them. And remember, all AWS data services support levels of encryption. Another best practice is to keep people from direct data access. So, as mentioned, I should set up as much read only access as possible. If I archive records, I can set policies such as WORM policies, write once, read many times. If I need access to data, maybe I can send you a report rather than giving you full data access. And of course, I can secure anything at AWS using IAM, identity and access management.