Security: Segmentation — What Is It and How Does It Work?
In this blog post, we’re explaining segmentation as an operational pattern and how it can be applied to a service landscape that is controlled by a cloud traffic controller like Glasnostic.
What is Segmentation?
At the most fundamental level, segmentation is about separating certain classes of traffic from each other, either based on network properties, protocols, or more generally, on arbitrary labels. While traditionally a rather blunt tool, segmentation can, if based on arbitrary labels, help enforce security policies even in dynamic environments like an organic architecture.
Because segmentation has its roots in network security, and because enterprise development teams rarely know where their services will ultimately run or how they will interact with other deployments, segmentation is typically taken as an operational concern that is left to operations to address.
However, the desire for segmentation is not always driven by security concerns alone. Because today’s agile enterprises organize themselves increasingly around self-managing, parallel teams in order to adapt to ever faster-evolving business needs, they also look to segmentation as a means of isolating their respective deployments from each other. As a result, development teams are able to add deployments to the service landscape faster and with less risk.
For operators, addressing security and insulation concerns typically involves two steps. The first step is to logically partition the service landscape into segments of services. With segments in place, operators can then institute traffic policies between them as needed. The default traffic policy is to allow zero traffic between segments, regardless of the class it belongs to. However, it is also possible to whitelist specific classes of traffic as necessary. One motivation to do so is that a specific traffic class is essential for running the application.
Segmenting with Glasnostic
As a cloud traffic controller that manages traffic in general, Glasnostic is ideally suited to segment traffic between arbitrary sets of service endpoints.
To illustrate this point, consider the example of one of our customers who hosts a distributed video conferencing system. In this system, conference “rooms” consist of separate audio, video, screensharing and chat relay services. Audio is automatically transcribed by a transcription service and all three non-video streams, audio, audio transcription and chat are recorded by a recording service and ultimately stored for record-keeping and compliance reasons. Each conference room is instantiated separately, on demand and secured by a session controller against an entitlement service.
The diagram below shows a simplified view of the architecture.
However, because misconfigurations, software errors and security breaches do occur, Glasnostic is used to further ensure that no data will be exchanged between conference rooms.
Conference participants connect to their conference room via an API Gateway.
The operator’s goal is to segment each conference room assembly to prevent malicious or accidental communication between the service instances of different rooms, even if a room is compromised. Conference rooms need to be segmented as a matter of operational policy.
Applying segmentation via traditional firewalling falls short here because conference rooms are continually spun up and torn down because the service addresses are dynamic and continuously reallocated.
The highly dynamic nature of this service landscape requires a service registry to provide labels on which the segmentation can be based. In our example, a prefix identifying the conference room can be prepended to each service name. A video relay service for room A would be then called A_video-relay and one for room B, B_video-relay.
By relying on such labels, the operator can define a security policy that prevents traffic, e.g., from one video relay to another video relay service. To implement such a policy in Glasnostic, an operator would first create a new channel. She would then specify the pattern *_video-relay* for both, the client and service side to capture traffic between all video relay services, past, present and future, and across all conference rooms. Finally, she would specify a limit of zero requests to prevent any traffic between conference rooms.
Of course, such a channel only captures traffic between video relay services. A video conference room consists of more than just video relays, however. To control traffic between all components of a conference room, the operator could either create more such channels or simply broaden the channel definition. For instance, the operator could use multiple wildcards (e.g. *_*relay) or a regular expression such as *_(transcription|recording)-service.
Other Uses for Segmentation
Aside from our video conference use case, segmentation occurs of course in many other scenarios. In all cases, however, it is an operational concern that is imposed on applications by the operations team.
Additional use cases include:
- Systems may be considered important enough to warrant comprehensive segmentation around them, in effect making them “off-limits” to all clients. For instance, given the potential for catastrophic monetary loss, a financial services company may decide to completely prohibit access to their investment banking systems.
- Development work in parallel teams may progress along independent branches that require segmentation between most of their respective deployments.
- Data privacy or other legal concerns may require a company to run various parts of its service landscape in separate and insulated environments. For instance, a HealthTech company may be required to enforce segmentation in the cloud (e.g. via AWS VPC) and on-premises and to tightly control the types of traffic that may be exchanged between them.
Segmentation is a fundamental operational concern and addresses both the security and insulation needs in the enterprise. Segmentation was traditionally implemented by changing network topologies, changing routing tables or using firewalls. These techniques are unsuitable for the fast-moving and dynamic world of the cloud and containers, however. In such environments, a cloud traffic controller such as Glasnostic is the perfect solution to enforce security and insulation policies while reaping the benefits of elasticity that the cloud provides.
Originally published at glasnostic.com.
