Network Segmentation in the Zero Trust Era
There is still a need for network segmentation in the zero trust era, but it needs to be software-defined. Otherwise, traditional network segmentation will be over-whelmed by the growing number of access and component interactions today’s applications require. Late last year, we reviewed a financial services customer’s Segmentation Program, which had taken traditional network segmentation to its point of diminishing returns. Developers were protesting ever-stricter access restrictions intended to more fully separate development from production functions.
What should customers like this with strong assurance needs but the same pressures for cost savings and agility as everyone else do? A balance must be struck. The architecture has to evolve from relying only on traditional network segmentation – think firewall rules referencing IP address and ports – to modern models using software-defined perimeters and microsegmentation.
During the next 6 weeks, we dug deep into modern network segmentation models. These models combine network, identity, and contextual filtering across a hybrid cloud environment. We generated many findings I’ll be able to use for multiple posts. Today’s deals with just one of the client’s questions:
What are the best practices for extending logical security zones across premise-based and cloud environments?
Depending on risk and compliance concerns, organizations may or may not extend choose to extend a network security zone as shown in the figure. There are many potential combinations of requirements for different companies, even within the same vertical industry. We have distilled the following good practices for zone extension from research and client interactions.
Network Interconnect Considerations
When it comes to interconnecting data centers and public cloud infrastructure-as-a-service (IaaS) environments, clients should generally treat cloud interconnect similar to data center interconnect. We don’t recommend network layer 2 extension. Use WAN path isolation over a private link to segregate the traffic. Line encryption to the cloud is also desirable.
Our zone interconnect pattern just depicts a “network interconnect” arrow between a premise-based environment and a public cloud IaaS such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform. That network interconnect could – but need not – run through a dedicated network firewall.
Why firewall on the interconnect? Take a look inside the premise-based and IaaS areas of the “general compute zone” in the figure. Notice the “microsegmentation” shown in each area. Microsegmentation separates the microservices or workload “systems” into even smaller subzones if necessary. Microsegmentation is usually implemented by cloud-native controls like AWS security groups. On premises, it may be implemented by VMware’s virtual firewalls and/or container security solutions. Assuming that there are other zones besides the General Compute Zone, security architects could choose to trust the microsegmentation to sort which systems can “see” each other across the environments, or to put a firewall with centrally-controlled policies between the major cloud interconnects.
Software-Defined Perimeters, Identity, and Access
Like microsegmentation, “identity perimeters” and “zero trust architecture” (as described in the book “Zero Trust Networks” by Evan Gilman and Doug Barth) are recipes for software-defined perimeters. If you are going to extend a zone, policy enforcement and decisions require consistent identity information and access policies across it. Our zone interconnect figure depicts an authorization control plane that makes the access decisions based on identity, access, and location context.
Using Gilman and Barth’s zero trust terminology I’ve shown “policy engine” and “trust engine” as the main moving parts in the authorization control plane. Security gateways such as VPNs or API gateways can query the policy engine or other authorization and directory services in real time. Workloads, microservices, applications or anything else in the general compute zone can also reference the policy engine.
Multiple cloud-based identity or policy repositories can synchronize to an enterprise directory, such as Active Directory (AD). Alternatively, AWS Managed Microsoft AD and Azure AD Domain Services provide the familiar Active Directory Domain Services to get that single source of truth into the cloud; this can be handy for “lift and shift” Windows application migrations.
In the medium- to long-term the best practice is to take advantage of federation and modern identity protocols (SAML, OIDC, OAuth 2.0, and SCIM). A loosely-coupled federated architecture will make it easier to extend zones once these standards are fully deployed in all major cloud providers.
Just this month, we successfully completed our client’s Segmentation Program review. The project proved challenging because it involved multiple moving parts including cloud infrastructure, network infrastructure, security, and identity management. Our strategy recommendations will now point them in the right direction. If your network segmentation, security zones, or identity models are starting to feel a bit long in the tooth, please contact us and we’d be happy to answer your questions through a complimentary dialogue.