Securing Cloud Networks – SY0-601 CompTIA Security+ : 3.6

The cloud introduces new security challenges to our connectivity and networking. In this video, you’ll learn about virtual networks, public and private subnets, segmentation, and API inspection.


If we have applications that are running in the cloud and we’re storing data in the cloud, then we need some type of network to be able to send and receive data from that cloud-based system. Our application may be a public one, which means anyone on the internet from anywhere in the world would be able to access that application. Or maybe it’s a private cloud. And you’ll have to have a VPN connection in order to gain access to that private subnet.

And most application instances have many different services running simultaneously. And there needs to be some way for all of these different services to communicate with each other. This may be within the same data center using east-west traffic. Or there may be communication outside of the data center to information that’s stored in a completely different location. And that would be referred to as north-south communication.

And, of course, it’s very common to have the ability in the cloud to be able to create and tear down instances of servers of databases and of other systems. We can do exactly the same thing with our networking.

We can have virtual switches, virtual routers, and build an entire virtual infrastructure with different IP addressing, different routing configurations all within a cloud-based system. From the perspective of the network administrator, these virtual systems look and feel exactly the same way as the physical systems.

So configuring a virtual switch is exactly the same process in front-end as configuring a physical switch. But unlike our physical devices, our cloud-based networking systems can be created virtually at any time. We can use our on-demand functionality to go to a single console, configure as many different switches as we would like. And instantly, we now have a new network infrastructure created.

We can combine this with rapid elasticity so our applications can automatically create new instances. And with those new instances would be virtual switches and virtual routers along with all of the other cloud-based systems.

It’s not uncommon to create cloud-based systems that may be located at a global provider like Amazon or Microsoft. But there’s no public access to any of those resources. This would be virtual private clouds that have all internal or private IP addressing. And the only way that you’d be able to connect to those systems is using some type of virtual private network.

This allows you to have all the advantages of a cloud-based system but also have all of the privacy since no one on the internet has direct access to your data. Of course, you might be building out an application that you would want everyone in the world to be able to access. And in that case, you would use a private cloud.

This would use external IP addresses so that no matter where you are in the world, everyone would be able to connect to your service. And it’s not unusual to find situations where you might have a public-facing part of your application that users connect to. But the internals of your application may only be communicating with each other over private networks.

This allows you to determine exactly what part of your cloud-based services can be accessed by folks on the internet and what parts of that cloud-based service are only private for people who are part of your organization. We would use these public and private subnets to be able to create segmentation of your application and of the data.

This application instance might be running separate virtual private clouds. It might have different containers and separate microservices for the applications that you’re running. This means that there is certainly going to be opportunities to provide segmentation of the data. And now we can start to manage how we want that data to flow between all of those different segments.

For example, we might have an application front-end that users are able to access. But there may be communication to a backend database that is all on a private network. And the users can’t directly access the database server. Only your application server has access to your database server.

This adds additional security between the different components of your application instance and allows you to maintain a level of privacy that is naturally built into your infrastructure. We might also want to supplement this segmentation with additional security controls. For example, we might have a Web Application Firewall, or a WAF, which is examining all of the communication inbound and outbound for that application and making sure that there’s no malicious data going into or out of your application instance.

If you want to segment the network even further, you might want to use a next-generation firewall. This allows you to set different subnets to be able to route between those subnets. And you can do this all in a virtual environment. Many next-generation firewalls also include intrusion prevention so they can identify any known malicious code that might be traversing your network.

Many of our applications use the microservice architecture where there is an API gateway that is simply accessing microservices of the application and using application programming interface or API calls to be able to request and receive data from that microservice. Although this provides efficiency and redundancy for the application, it also introduces a number of security concerns.

For example, we may have situations where instead of the client making requests to an API gateway, someone attacking this application could circumvent the client and send their own request directly to the API gateway. So we may want to examine those calls to see if they’re coming directly from the client or if someone may be circumventing the client and sending their own customized calls to our API gateway.

To be able to manage this, you’ll want to perform some API monitoring where you can view specific API queries that are coming from the API gateway. And you can monitor exactly what type of data is incoming to your database and what information is being sent back to the client.