Welcome to your VPC. You can think of it as a hardened fortress where nothing goes in or out without explicit permission. You have a gateway on the VPC that only permits traffic in or out of the VPC. But that only covers perimeter. And that's only one part of network security that you should be focusing on as part of your IT strategy. aws has a wide range of tools that cover every layer of security, network hardening application security, user identity, authentication and authorization. Distributed denial of service or DDoS prevention, data integrity, encryption, much more. We going to talk about a few of these key pieces. If you really want to know more about security, please follow the links on this page to be directed to more information. And additional training on how to lock your infrastructure down tighter than aunt Robin secret lemon pie recipe. And nobody getting that recipe. Today, I want to talk about a few aspects of network hardening, looking at what happens inside the VPC. Now the only technical reason to use Subnets in a VPC, is to control access to the Gateways. The Public Subnets have access to the Internet Gateway, the Private Subnets do not. But subnets can also control traffic permissions. Packets are messages from the internet, and every packet that crosses the subnet boundaries, gets checked against something called a network access control list or Network ACL. This check is to see if the packet has permissions to either leave or enter the subnet, based on who it was sent from and how it's trying to communicate. You can think of network ACLs as passport control officers. If you're on the approved list, you get through, if you're not on the list, or if you're explicitly on the do-not-enter list, then you get blocked. Network ACL's check traffic going into and leaving a subnet, just like passport control. The list gets checked on your way into a country and on the way out. And just because you are let in, doesn't necessarily mean they going to let you out. Approved traffic can be sent on its way, and potentially harmful traffic attempts to gain control of the system through administrative requests. They get blocked before they ever touch their target. You can't hack what you can't touch. Now, this sounds like great security. But it doesn't answer all of the network control issues. Because a Network ACL only gets to evaluate a packet if it crosses a subnet boundary, in or out. It doesn't evaluate if a packet can reach a specific EC2 Instance or not. Sometimes you'll have multiple EC2 Instances in the same subnet. But they might have different rules around who can send the messages, what port those messages are allowed to be sent to. So, you need instance level network security as well. To solve instance level access questions, we introduce Security Groups. Every EC2 Instance, when it's launched automatically comes the Security Group. By default, the Security Group does not allow any traffic into the instance at all. All ports are blocked, all IP addresses sending packets are blocked. That's very secure but perhaps not very useful, if you want an instance to actually accept traffic from the outside say, a message from a friend and instance or a message from the internet. So, obviously, you can modify the Security Group to accept a specific type of traffic. In the case of a website, you want web based traffic or HTTPS to be accepted. But not other types of traffic say, an operating system or administration requests. If Narcos are passport control, a security group is like the doorman at your building, the building being the EC2 Instance in this case. The doorman will check a list to ensure that someone is allowed to enter the building, but won't bother to check the list on the way out. With Security Groups, you allow specific traffic in, and by default, all traffic is allowed out. Now, wait a minute Blaine, you just described two different engines each doing the exact same job. Let good packets in, keep bad packets out. The key difference between a Security Group and a Network ACL is that the Security Group is stateful. Meaning as we talked about, it has some kind of a memory when it comes to who to allow in or out. And the Network ACL is stateless, which remembers nothing. And checks every single packet that crosses its border, regardless of any circumstances. This metaphor is important to understand. So I want to illustrate the round trip of a packet as it goes from one instance to another instance in a different subnet. Now this traffic management, it doesn't care about the contents of the packet itself. In fact, it doesn't even open the envelope, it can't. All it can do, is check to see if the sender is on the approved list. All right, let's start with Instance A, we want to send a packet from Instance A to Instance B in a different subnet, same VPC, different subnets. So instance A sends a packet. Now the first thing that happens, is that packet meets the boundary of the Security Group of Instance A. By default, all outbound traffic is allowed from a Security Group, so you can walk right by the doorman and leave. Cool, right, the packet made it past the Security Group of Instance A. Now it has to leave the subnet boundary. At the boundary, the passport must now make it through passport control, the Network ACL. The Network ACL doesn't care about what the security group allowed. It has its own list of who can pass and who can't. If the target address is allowed, you can keep going on your journey, which it is. So, now we have exited the original subnet, and now the packet goes to the target subnet were Instance B leaves. Now at this target subnet, once again, we have passport control. Just because the packet was allowed out of its home country, does not mean that it can enter the destination country or subnet in this case. They both have unique passport officers with their own checklists. You have to be approved on both lists, or you could get turned away at the border. Well, turns out the packet is on the approved list for this subnet, so it's allowed to enter through the Network ACL into the subnet. Almost there, now we're approaching the target instance, Instance B. Every EC2 Instance has their own Security Group. You want to enter this instance, the doorman will need to check to see if you're allowed in, and we're on the list. The packet has reached the target instance. Once the transaction is complete, now it's just time to come home. It's the returned traffic pattern. It's the most interesting, because this is where the stateful versus stateless nature of the different engines come into play, because the packet still has to be evaluated at each checkpoint. Security Groups by default, allow all return traffic. So they don't have to check a list to see if they're allowed out. Instead, they automatically allow the return traffic to pass by no matter what. Passport control here at the subnet boundary, these Network ACL do not remember state. They don't care that the packet came in here. It might be on a you can't leave list. Every ingress and egress is checked with the appropriate list. The packet return address has to be on their approved list to make it across the border, made it to the border of the origin subnet. But we have to negotiate passport Network ACL control here as well. Stateless controls means it always checks its list. The packet passed the Network ACL at the subnet level, which means the packets now made it back to Instance A, but the security group, the doorman is still in charge here. The key difference though is the Security Groups are stateful. The Security Group recognizes the packet from before, so it doesn't need to check to see if it's allowed in. Come on home. Now this may seem like we spent a lot of effort just getting a packet from one instance to another and back. You might be concerned about all the network overhead this might generate. The reality is, all of these exchanges happen instantly as part of how AWS Networking actually works. If you want to know the technology that makes all that possible, well then you need to sign up for a completely different set of trainings. Good network security will take advantage of both Network ACLs and Security Groups because security and depth is critical for modern architectures.
