Blog
Cloud Network Segmentation
Which option best fits your requirements?
With the possibility of integrating Platform as a Service (PaaS) services into a virtual network, the importance of a secure, scalable and efficiently operable network design also increases. With this blog, we show variants of how Cloud Network Segmentation can look like in the enterprise environment.
Cloud Network Segmentation Principles
A hub-and-spoke network architecture has established itself as best practice in the cloud and is now used in most companies in the enterprise sector. Here, overarching network services such as firewall, connectivity or routing are controlled centrally in a hub network. Peerings are used to connect workload networks (spokes) to the hub, which controls all traffic between different spokes in the hub.
While the path to micro segmentation is very complex on premise, this concept is already used as standard in the cloud. A zero trust approach is increasingly being pursued, which enables much stricter isolation of individual applications. This is also reflected in controls from various best practice security frameworks such as the Microsoft Cloud Security Benchmark (NS-1/NS-2), CIS Controls (3.12, 13.4, 4.4), NIST SP 800-53 (AC-4, SC-2, SC-7) or PCI-DSS (1.1, 1.2, 1.3).
Blog
For supplemental information on Zero Trust, see our dedicated blog post:
Implementation of a Zero Trust Architecture
In the cloud, there are five basic tools that contribute to a functioning network segmentation:
- Virtual networks
VNets (Azure) or VPCs (AWS and Google) can be used to isolate resources, since free communication is only possible within a virtual network by default. However, they can be connected to each other by means of peerings to the hub.
- Subnets
Additional segmentation by subnets is possible within a virtual network. This allows individual application components (e.g. frontends, key vaults or databases) to be isolated from each other and controlled by the firewall via the specific subnet ranges.
- Firewalls
Firewalls can be used to control and inspect traffic that is routed to the hub via peerings. This is done on defined IP addresses or address ranges (L3), but can also be implemented on an elevated layer (L7) using FQDN rules.
- Network Security Groups / Network Access Control Lists / VPC Firewall Rules
Network Security Groups (NSGs, Azure), Network Access Control Lists (ACLs, AWS) or VPC Firewall Rules (GCP) are simplified firewalls that control traffic within a virtual network. These NSGs or ACLs are attached to individual subnets and define the incoming and outgoing traffic based on source/destination, protocol and port.
- Route Tables
By default, outgoing Internet traffic is routed directly from the respective subnet to the Internet. To change this and to inspect or control the traffic in a firewall first, route tables and user defined routes (UDRs) can be used and linked to subnets.
However, the question now arises as to how the aforementioned tools can be combined in the best possible way in order to achieve the goal of efficient, secure and scalable segmentation.
For better readability, Microsoft Azure terminology is used in the following sections, but the principle applies equally to AWS and GCP.
Variant 1 - Segmentation of virtual networks
This variant follows the principle that each application or service is hosted in a dedicated virtual network. The result is that a virtual shell is created around the application by default and communication within it is handled via subnets and network security groups.
The advantage of this variant lies primarily in the low complexity and the continuous isolation of applications, since the application boundaries are enforced directly by means of virtual networks. However, it should be noted that due to the limited number of peerings (currently 500 per hub in Azure), the maximum number of applications is limited accordingly. This limitation is even more significant if separate environments (dev, test, prod) are required for each application.
Another factor to consider in this variant is cost. The number of VNets is not a direct cost factor, but all cross-VNet traffic is charged. One consideration may therefore be that applications that exchange a lot of data frequently are clustered in the same VNet.
Variant 2 - Segmentation by means of subnets
Instead of application-specific virtual networks, this variant uses larger, shared networks (e.g. per environment). The separation of applications within these virtual networks takes place (if at all desired) via subnets and network security groups. This means that open communication within an environment or zone is possible by default.
This variant has the advantage of being easy to use, provided that open, cross-application traffic is desired. If this is not the case, the increasing number of applications leads to a confusing landscape of subnets and network security groups. Above all, the fact that there is currently no overarching view for managing subnets or NSGs makes it difficult to manage rules for additional applications.
Variant 3 - Segmentation by means of route tables and firewall
This variant achieves a mix between the first two variants by placing applications in a large, shared network, but always routing traffic to the central firewall in the hub and controlling it there. This is made possible with multiple user-defined routes (UDRs) that override the default routes within the virtual network.
Although this variant could give the impression that the advantages of the previously mentioned variants can be combined, handling also becomes complex here as the application volume increases. The reason for this is that the default routes can only be overridden by UDRs if they are equally specific or more specific. A default route (0.0.0.0/0) does not have the desired effect for internal traffic in this case; instead, an additional route would also have to be created for each subnet (max. 400 per Route Table).
Conclusion / Recommendation
In order to comply with the zero trust approach, we recommend variant 1 and thus strict network separation of applications with the aid of dedicated virtual networks. Microsoft has also indirectly anchored this approach in its cloud adoption framework and stipulates that applications are to be placed in dedicated subscriptions as a matter of principle (subscription democratization), which consequently also leads to dedicated virtual networks.
The reason for this recommendation lies mainly in the scalability required in the medium term. Although a shared virtual network may seem sensible at the beginning with a manageable cloud portfolio, the operating effort and complexity increase exponentially as the number of applications increases. Although an architecture change is also possible retrospectively, it means redeploying all components within the virtual network.
Basically, we recommend not to underestimate the network design in a cloud project and to deal with it already at the beginning. After all, the network, together with identity management and governance mechanisms (policies, RBAC, etc.), is one of the cornerstones on which the applications are built.
