Guest blog by Johna Johnson, CEO and founder, Nemertes Research
How complex should security be? In the inverse of the quote often attributed to Einstein: As complex as necessary, but no more so. (The actual quote is “As simple as possible, but no simpler”).
The issue of complexity in security is highlighted by the resurgence of services-oriented architecture (SOA) in the form of microservices. A microservices-oriented architecture (MSOA) breaks monolithic applications into constellations of smaller, interacting applications. And it does so at a finer grain than in the first round of SOA a decade back. That is, instead of the handful of components typical in a SOA, an MSOA comprises dozens, even scores, of services.
MSOA architectures are the key to developing scale-out, resilient solutions. Each piece of the puzzle can be provided by multiple instances of the same stateless component (increasingly in the form of an application container). The system overall—including the application the user experiences—can survive the failure of any given instance of any given service, even of multiple scattered instances. In fact, failure is expected.
With services’ component applications getting smaller, far more numerous, more broadly dispersed, and more movable, the number of possible interactions in an MSOA gets staggeringly large pretty quickly. And that’s where the issue of security complexity comes in: The challenge of securing interactions among components, as well as between components and the outside world, is enormous for a traditional choke-point firewall.
In fact, it’s virtually an overwhelming challenge. A centralized firewall would have to be scaled to handle east-west as well as north-south traffic, and has to do so without introducing unacceptable levels of latency. It would also have to be able to handle a complex and fluid universe of interactions, and the fact that different services need to interact with different subsets of the rest of the services.
Keep in mind that an entire microservices-based architecture may require thousands or tens of thousands of firewall rules. If these rules need to be tested and retested every time a microservice changes, testing would become prohibitively complex. And since the ability to make multiple incremental changes—as many as a dozen or more code changes per day—is one reason for deploying a microservices architecture in the first place, security would become the bottleneck.
The solution? Adding security around the microservices themselves, rather than in some artificially created chokepoint. By dispersing enforcement, architects can devise an infrastructure that can far more easily deal with dynamic scale. Spreading the load means no single security enforcement point has to be able to handle the cumulative throughput of all the services.
And a distributed architecture means that more enforcement points can easily be deployed to match a growing number of service nodes. For example, when a service monitor spots congestion on one of the component services, it may deploy additional instances of that service to cope; it could trigger deployment of additional enforcement instances as well. Enforcement points can likewise be dropped when they are no longer needed, just as unused service nodes can be when demand for a service drops.
Scale-out security means that setting and testing rules can be simpler: each policy enforcement point only has to know policies that apply to the services it protects. That means infosec personnel can evaluate the consistency and completeness of these rules more easily. So even though the cumulative set of rules may be as large as ever, the problem of creating and testing rules is distributed and manageable because rulesets only get tested when they get modified in response to changes in the part of the environment they protect, not in response to every change anywhere in the environment.
There’s no way to escape the complexity of securing a dynamic microservices architecture, but there’s no need to make it any worse than it has to be. A service-centric, distributed security architecture is key to keeping it, if not simple, then at least as simple as possible.