1 00:00:00,000 --> 00:00:01,770 In this lesson, we're going to discuss 2 00:00:01,770 --> 00:00:04,560 cloud security and its various components. 3 00:00:04,560 --> 00:00:07,260 Cloud security is comprised of several different components 4 00:00:07,260 --> 00:00:09,390 within a virtual private cloud. 5 00:00:09,390 --> 00:00:11,370 By understanding the different cloud security features 6 00:00:11,370 --> 00:00:13,860 that are available and how to use them effectively, 7 00:00:13,860 --> 00:00:15,990 you can help to protect your cloud-based resources 8 00:00:15,990 --> 00:00:18,390 from unauthorized access and attack. 9 00:00:18,390 --> 00:00:21,930 A virtual private cloud is commonly referred to as a VPC, 10 00:00:21,930 --> 00:00:24,390 and it's used to provision a logically isolated section 11 00:00:24,390 --> 00:00:26,220 of a cloud provider's infrastructure 12 00:00:26,220 --> 00:00:28,200 where you can launch various resources inside 13 00:00:28,200 --> 00:00:32,009 of a virtual network that you as the consumer have defined. 14 00:00:32,009 --> 00:00:34,710 By using a VPC, we can use software to create 15 00:00:34,710 --> 00:00:37,470 a virtual network environment that is much more flexible 16 00:00:37,470 --> 00:00:38,970 and scalable than a traditional 17 00:00:38,970 --> 00:00:41,100 hardware-based networking would allow. 18 00:00:41,100 --> 00:00:43,800 Virtual private clouds are an integral part of the larger 19 00:00:43,800 --> 00:00:47,490 concept known as infrastructure as code, or IAC. 20 00:00:47,490 --> 00:00:49,080 Infrastructure as code includes 21 00:00:49,080 --> 00:00:51,120 the provisioning of architectures, where the deployment 22 00:00:51,120 --> 00:00:53,010 of resources is going to be performed 23 00:00:53,010 --> 00:00:55,620 by scripted automations and orchestration. 24 00:00:55,620 --> 00:00:57,330 While infrastructure as code can be applied 25 00:00:57,330 --> 00:00:59,730 to various aspects of your cloud-based infrastructure, 26 00:00:59,730 --> 00:01:02,610 including servers and databases, your VPC 27 00:01:02,610 --> 00:01:04,440 is going to be used to specifically focus 28 00:01:04,440 --> 00:01:07,320 on the networking aspects of your cloud-based infrastructure 29 00:01:07,320 --> 00:01:09,630 when using infrastructure as code. 30 00:01:09,630 --> 00:01:11,370 Now, the virtual private cloud provides us 31 00:01:11,370 --> 00:01:13,770 with a lot of different features and core components 32 00:01:13,770 --> 00:01:16,230 that you should be aware of, including subnets, 33 00:01:16,230 --> 00:01:18,300 route tables, internet gateways, 34 00:01:18,300 --> 00:01:20,220 network address translation gateways, 35 00:01:20,220 --> 00:01:22,770 network access control lists, security groups, 36 00:01:22,770 --> 00:01:26,970 VPC peering, VPC endpoints, and VPN connections. 37 00:01:26,970 --> 00:01:28,800 First, we have subnets. 38 00:01:28,800 --> 00:01:31,380 A subnet is arranged within your virtual private cloud 39 00:01:31,380 --> 00:01:33,000 that you can allocate to the instances 40 00:01:33,000 --> 00:01:34,470 that you are going to be launching. 41 00:01:34,470 --> 00:01:36,180 You can have public subnets that are accessible 42 00:01:36,180 --> 00:01:38,310 from the internet, or private subnets 43 00:01:38,310 --> 00:01:40,470 that are not accessible from the internet. 44 00:01:40,470 --> 00:01:42,630 Second, we have route tables. 45 00:01:42,630 --> 00:01:45,480 Now, a route table contains a set of rules, called routes, 46 00:01:45,480 --> 00:01:47,760 that determine where network traffic is going to be directed 47 00:01:47,760 --> 00:01:49,110 by your switches and routers 48 00:01:49,110 --> 00:01:51,150 within your virtual private cloud. 49 00:01:51,150 --> 00:01:53,760 Each subnet in your VPC has to be associated 50 00:01:53,760 --> 00:01:57,000 with a given route table, otherwise it's going to be isolated 51 00:01:57,000 --> 00:01:58,110 and not able to communicate 52 00:01:58,110 --> 00:02:00,840 with other resources in different subnets. 53 00:02:00,840 --> 00:02:03,210 Third, we have internet gateways. 54 00:02:03,210 --> 00:02:05,700 Now, an internet gateway is a horizontally scalable, 55 00:02:05,700 --> 00:02:07,290 redundant, and highly available 56 00:02:07,290 --> 00:02:09,300 virtual private cloud component that allows 57 00:02:09,300 --> 00:02:11,160 communication between your instances, 58 00:02:11,160 --> 00:02:13,920 in your virtual private cloud, and the internet. 59 00:02:13,920 --> 00:02:16,320 Essentially, an internet gateway provides a connection 60 00:02:16,320 --> 00:02:18,780 between the resources in your virtual private cloud 61 00:02:18,780 --> 00:02:20,340 and the publicly available internet 62 00:02:20,340 --> 00:02:23,400 that lies outside of your virtual private cloud. 63 00:02:23,400 --> 00:02:25,650 Fourth, we have NAT gateways. 64 00:02:25,650 --> 00:02:28,860 Now, a NAT gateway, or network address translation gateway, 65 00:02:28,860 --> 00:02:31,560 is used to enable the instances in a private subnet 66 00:02:31,560 --> 00:02:32,640 to connect to the internet, 67 00:02:32,640 --> 00:02:35,460 or other cloud service provider resources or services. 68 00:02:35,460 --> 00:02:37,650 But they also are used to prevent the internet 69 00:02:37,650 --> 00:02:40,020 from initiating a connection with those instances 70 00:02:40,020 --> 00:02:42,480 inside of your virtual private cloud. 71 00:02:42,480 --> 00:02:44,910 Simply put, a NAT gateway acts as a broker 72 00:02:44,910 --> 00:02:47,760 between your private subnets and the public internet. 73 00:02:47,760 --> 00:02:49,470 Whenever an instance in your private subnet 74 00:02:49,470 --> 00:02:51,450 needs to connect to the internet, it's going to send 75 00:02:51,450 --> 00:02:53,970 its traffic to your NAT gateway, and then the NAT gateway 76 00:02:53,970 --> 00:02:56,520 will translate the instance's private IP address 77 00:02:56,520 --> 00:02:58,650 to a public IP address in order to forward 78 00:02:58,650 --> 00:03:00,390 its traffic the internet. 79 00:03:00,390 --> 00:03:01,950 Fifth, we have network access 80 00:03:01,950 --> 00:03:03,990 control lists and security groups. 81 00:03:03,990 --> 00:03:05,550 Now, network access control lists, 82 00:03:05,550 --> 00:03:08,550 also known as network ACLs, are similar to our traditional 83 00:03:08,550 --> 00:03:11,070 network firewalls and they operate at the subnet level 84 00:03:11,070 --> 00:03:13,080 within your virtual private cloud. 85 00:03:13,080 --> 00:03:16,410 Each network ACL is comprised of a number of different rules 86 00:03:16,410 --> 00:03:18,270 that your cloud service provider will process, 87 00:03:18,270 --> 00:03:20,940 in an ascending order, to determine whether or not to allow 88 00:03:20,940 --> 00:03:23,460 or deny network traffic that attempts to enter or leave 89 00:03:23,460 --> 00:03:26,520 your subnets inside of your virtual private clouds. 90 00:03:26,520 --> 00:03:28,560 Now, each of these rules can be customized to suit 91 00:03:28,560 --> 00:03:31,650 your specific network traffic control requirements as well. 92 00:03:31,650 --> 00:03:33,960 Now, our network ACLs are going to be used to create 93 00:03:33,960 --> 00:03:36,210 two sets of rules, one for inbound 94 00:03:36,210 --> 00:03:38,610 and another for outbound traffic requests. 95 00:03:38,610 --> 00:03:40,650 Inbound rules will control the traffic that's allowed 96 00:03:40,650 --> 00:03:43,350 to enter into your subnets, while the outbound rules 97 00:03:43,350 --> 00:03:46,050 govern the traffic that's allowed to leave your subnets. 98 00:03:46,050 --> 00:03:47,970 It's important to remember that network ACLs 99 00:03:47,970 --> 00:03:49,950 operate like a stateless firewall. 100 00:03:49,950 --> 00:03:52,680 This means that each rule for inbound or outbound traffic 101 00:03:52,680 --> 00:03:54,657 is going to be evaluated independently, 102 00:03:54,657 --> 00:03:57,330 and it does not consider anything that came before it, 103 00:03:57,330 --> 00:03:59,430 or anything that comes after it. 104 00:03:59,430 --> 00:04:01,740 For example, if an inbound rule will allow traffic 105 00:04:01,740 --> 00:04:04,350 from a specific IP address to go into your subnet, 106 00:04:04,350 --> 00:04:06,870 the corresponding return traffic also has to be explicitly 107 00:04:06,870 --> 00:04:10,530 allowed by an outbound rule, otherwise it will get blocked. 108 00:04:10,530 --> 00:04:12,600 Now, it's important to note that both security groups 109 00:04:12,600 --> 00:04:14,970 and network access control lists, or ACLs, 110 00:04:14,970 --> 00:04:17,160 are two different types of firewalls essentially 111 00:04:17,160 --> 00:04:18,990 that control inbound and outbound traffic 112 00:04:18,990 --> 00:04:21,149 for your instances and your subnets. 113 00:04:21,149 --> 00:04:23,460 Security groups are really the preferred way to control 114 00:04:23,460 --> 00:04:25,950 inbound and outbound traffic for your instances though, 115 00:04:25,950 --> 00:04:28,650 because they are more granular than your network ACLs, 116 00:04:28,650 --> 00:04:30,030 and they can be used to control traffic 117 00:04:30,030 --> 00:04:33,000 on a per port or per protocol basis. 118 00:04:33,000 --> 00:04:35,070 Security groups, unlike network ACLs, 119 00:04:35,070 --> 00:04:37,260 are going to be designed to function at the instance level 120 00:04:37,260 --> 00:04:39,300 within your virtual private cloud. 121 00:04:39,300 --> 00:04:41,130 Basically, a security group will serve 122 00:04:41,130 --> 00:04:44,310 as a virtual host base firewall for a specific instance, 123 00:04:44,310 --> 00:04:46,170 and then it can be used to control both the inbound 124 00:04:46,170 --> 00:04:48,720 and outbound traffic for that instance. 125 00:04:48,720 --> 00:04:51,750 Now, unlike a network ACL, security groups are considered 126 00:04:51,750 --> 00:04:53,790 to act like a stateful firewall. 127 00:04:53,790 --> 00:04:55,320 This means that if an outbound request 128 00:04:55,320 --> 00:04:57,960 is made from your instance, the inbound response traffic 129 00:04:57,960 --> 00:05:00,030 will automatically be allowed in. 130 00:05:00,030 --> 00:05:02,250 Similarly, if a request is made and approved 131 00:05:02,250 --> 00:05:05,220 by an inbound rule, then it may open up an outbound port 132 00:05:05,220 --> 00:05:06,630 to respond to that request 133 00:05:06,630 --> 00:05:09,210 without being explicitly asked to do so. 134 00:05:09,210 --> 00:05:11,640 Each of our security groups is comprised of a set of rules 135 00:05:11,640 --> 00:05:14,430 that define the allowed inbound and outbound traffic. 136 00:05:14,430 --> 00:05:16,020 When you create a new security group, 137 00:05:16,020 --> 00:05:17,880 it has no inbound rules by default. 138 00:05:17,880 --> 00:05:19,620 And therefore, no inbound traffic 139 00:05:19,620 --> 00:05:21,750 is going to be allowed into the instance. 140 00:05:21,750 --> 00:05:23,850 Similarly, when you create a new security group 141 00:05:23,850 --> 00:05:26,490 for an instance, it's going to allow all the outbound traffic 142 00:05:26,490 --> 00:05:29,190 to go out due to the default allow outbound rule 143 00:05:29,190 --> 00:05:31,980 that's configured by default by your cloud service provider 144 00:05:31,980 --> 00:05:34,320 when a new security group is created. 145 00:05:34,320 --> 00:05:37,080 Network ACLs, on the other hand, can be used to supplement 146 00:05:37,080 --> 00:05:39,150 our security groups, but they should not be used 147 00:05:39,150 --> 00:05:41,430 as a replacement for security groups. 148 00:05:41,430 --> 00:05:43,920 For this reason, the use of both network ACLs 149 00:05:43,920 --> 00:05:45,570 and security groups will offer us 150 00:05:45,570 --> 00:05:47,700 a lot of different security advantages. 151 00:05:47,700 --> 00:05:49,770 By using these tools, we're going to be able to provide 152 00:05:49,770 --> 00:05:51,870 granular control over our network traffic, 153 00:05:51,870 --> 00:05:53,400 and this allows us to tailor our security 154 00:05:53,400 --> 00:05:55,290 to our own unique requirements. 155 00:05:55,290 --> 00:05:57,150 By properly configuring these components, 156 00:05:57,150 --> 00:05:58,710 we're also able to create a more robust 157 00:05:58,710 --> 00:06:02,100 and multi-layer defense for our virtual private clouds. 158 00:06:02,100 --> 00:06:03,690 Network ACLs and security groups 159 00:06:03,690 --> 00:06:05,340 do have some challenges though. 160 00:06:05,340 --> 00:06:07,650 For example, if you incorrectly configure the rules 161 00:06:07,650 --> 00:06:09,690 within these tools, you're going to inadvertently 162 00:06:09,690 --> 00:06:12,420 block legitimate traffic, or you could potentially allow 163 00:06:12,420 --> 00:06:14,850 harmful traffic to pass through to your resources 164 00:06:14,850 --> 00:06:16,320 instead of blocking it. 165 00:06:16,320 --> 00:06:18,300 For this reason, it is really important 166 00:06:18,300 --> 00:06:20,370 that your network ACLs and security groups 167 00:06:20,370 --> 00:06:22,230 are correctly configured for security. 168 00:06:22,230 --> 00:06:23,820 And that you audit your rules regularly 169 00:06:23,820 --> 00:06:25,410 to ensure that you're still providing the level 170 00:06:25,410 --> 00:06:28,320 of organizational security that you want. 171 00:06:28,320 --> 00:06:30,540 Sixth, we have VPC peering. 172 00:06:30,540 --> 00:06:33,090 Now, virtual private cloud peering is a network connection 173 00:06:33,090 --> 00:06:35,010 between two virtual private clouds 174 00:06:35,010 --> 00:06:37,950 that enables you to route traffic between them privately. 175 00:06:37,950 --> 00:06:40,650 VPC peering is a great way to connect two VPCs 176 00:06:40,650 --> 00:06:42,600 that are located in the same region as well, 177 00:06:42,600 --> 00:06:44,130 because this makes sure that the traffic 178 00:06:44,130 --> 00:06:45,840 doesn't go through the public internet. 179 00:06:45,840 --> 00:06:48,330 And instead, it will improve the security and performance 180 00:06:48,330 --> 00:06:50,970 of your resources by keeping those two VPCs peered 181 00:06:50,970 --> 00:06:53,400 in a local area network configuration. 182 00:06:53,400 --> 00:06:55,890 Seventh, we have VPC endpoints. 183 00:06:55,890 --> 00:06:58,830 Now, VPC endpoints allow private connectivity to services 184 00:06:58,830 --> 00:07:01,020 hosted inside of a cloud service provider, 185 00:07:01,020 --> 00:07:03,600 like AWS, from within your VPC 186 00:07:03,600 --> 00:07:06,060 without using an internet gateway, a VPN, 187 00:07:06,060 --> 00:07:08,700 or AWS's Direct Connect service. 188 00:07:08,700 --> 00:07:10,830 VPC endpoints can be a great way to connect 189 00:07:10,830 --> 00:07:13,770 other cloud-based services that are not publicly accessible. 190 00:07:13,770 --> 00:07:16,260 And again, this can improve performance and security, 191 00:07:16,260 --> 00:07:17,880 because a large amount of this traffic 192 00:07:17,880 --> 00:07:19,920 will not need to go through an internet gateway, 193 00:07:19,920 --> 00:07:21,420 and instead, it can be handled locally 194 00:07:21,420 --> 00:07:24,060 inside the cloud service provider's network. 195 00:07:24,060 --> 00:07:26,370 Eighth, we have VPN connections. 196 00:07:26,370 --> 00:07:29,310 Now, VPN connections can be created between your VPCs 197 00:07:29,310 --> 00:07:32,640 and your remote network, or between two VPCs. 198 00:07:32,640 --> 00:07:34,470 This can be used to connect your on-premise network 199 00:07:34,470 --> 00:07:36,330 into your cloud service provider's network, 200 00:07:36,330 --> 00:07:39,360 or to connect two VPCs that are located in different regions 201 00:07:39,360 --> 00:07:41,550 of your cloud service provider's network. 202 00:07:41,550 --> 00:07:44,040 Now, in a traditional network, these functions might occur 203 00:07:44,040 --> 00:07:47,160 with various physical devices, like routers, firewalls, 204 00:07:47,160 --> 00:07:49,680 unified threat management systems, and switches. 205 00:07:49,680 --> 00:07:52,230 However, by using these virtual private clouds, 206 00:07:52,230 --> 00:07:54,540 all these functions can be virtualized instead 207 00:07:54,540 --> 00:07:56,400 so that we have more flexibility and control 208 00:07:56,400 --> 00:07:57,960 over the functions themself. 209 00:07:57,960 --> 00:08:00,180 And they've been abstracted from the hardware level 210 00:08:00,180 --> 00:08:03,360 to the software level inside of our cloud-based designs. 211 00:08:03,360 --> 00:08:05,670 A VPC does provide us with numerous advantages 212 00:08:05,670 --> 00:08:06,990 over traditional networks, 213 00:08:06,990 --> 00:08:09,300 by allowing us to mix products from different vendors, 214 00:08:09,300 --> 00:08:11,160 to increase the speed of our network development, 215 00:08:11,160 --> 00:08:14,100 and add layers of automation and policy management. 216 00:08:14,100 --> 00:08:16,980 Virtual private clouds can also enable us to fully automate 217 00:08:16,980 --> 00:08:19,320 our deployments within the cloud, which makes VPCs 218 00:08:19,320 --> 00:08:21,300 a critical tool for high velocity 219 00:08:21,300 --> 00:08:24,780 or high availability architectures and disaster recovery. 220 00:08:24,780 --> 00:08:27,480 Now, despite the benefits of using a virtual private cloud, 221 00:08:27,480 --> 00:08:30,000 there are also some challenges you need to be aware of. 222 00:08:30,000 --> 00:08:32,970 For example, if connectivity to the VPC is lost, 223 00:08:32,970 --> 00:08:35,429 your entire network could end up going down. 224 00:08:35,429 --> 00:08:37,710 Also, the centralized nature of the VPC 225 00:08:37,710 --> 00:08:39,720 makes it a potential target for attackers, 226 00:08:39,720 --> 00:08:42,750 so it's crucial that you ensure the VPC is properly secured 227 00:08:42,750 --> 00:08:45,750 before you use it inside of your production environments. 228 00:08:45,750 --> 00:08:48,690 So remember, the virtual private cloud, or VPC, 229 00:08:48,690 --> 00:08:50,340 is a logically isolated section 230 00:08:50,340 --> 00:08:52,320 of your cloud service provider's infrastructure 231 00:08:52,320 --> 00:08:54,240 that you can use to launch their resources 232 00:08:54,240 --> 00:08:56,130 for your organization's use. 233 00:08:56,130 --> 00:08:58,470 VPCs are more flexible and scalable than traditional 234 00:08:58,470 --> 00:09:00,000 hardware-based networks as well. 235 00:09:00,000 --> 00:09:02,910 And VPCs are considered to be a part of a larger concept 236 00:09:02,910 --> 00:09:05,880 known as IAC, or infrastructure as code, 237 00:09:05,880 --> 00:09:07,530 where the provisioning of architecture, 238 00:09:07,530 --> 00:09:09,660 and the deployment of resources is going to be performed 239 00:09:09,660 --> 00:09:12,180 by scripted automation and orchestration. 240 00:09:12,180 --> 00:09:15,000 The key components of VPCs are things like subnets, 241 00:09:15,000 --> 00:09:17,130 route tables, internet gateways, 242 00:09:17,130 --> 00:09:20,640 network access translation gateways, network ACLs, 243 00:09:20,640 --> 00:09:22,830 security groups, VPC peering, 244 00:09:22,830 --> 00:09:25,710 VPC endpoints, and VPN connections. 245 00:09:25,710 --> 00:09:27,990 Virtual private clouds can provide a number of advantages 246 00:09:27,990 --> 00:09:29,400 over our traditional networks, 247 00:09:29,400 --> 00:09:32,970 including increased flexibility, scalability, and security. 248 00:09:32,970 --> 00:09:36,030 However, there are some challenges associated with VPCs, 249 00:09:36,030 --> 00:09:38,220 such as the risk of being a single point of failure, 250 00:09:38,220 --> 00:09:39,840 and the need for properly securing them 251 00:09:39,840 --> 00:09:42,540 before using them inside your production environments.