Switching to Microservices? Plan to exploit its Security Benefits!
There is no doubt that Microservices architecture has generated an overwhelming enthusiasm for architects and technologists. Developers, application groups, and business units are excited also about the potential for faster functionality roll-outs, more frequent updates, and the ability for different development groups to work and release independently.
But there is a general concern that many new technologies are adopted without thinking about security requirements. Almost every new software platform comes with its own set of security issues, most of which are discounted in the hurried rush to adoption. Moreover, security personnel struggle to understand how to translate existing practices into ones appropriate for the new platform.
In the case of Microservices, however, security professionals should recognize that this architecture holds the potential for simplifying their job and making the organization’s applications more secure, not less. The partitioned functionality and distributed executable architecture of Microservices make assessing security easier and shield critical resources better than traditional application architectures.
While it is important that security practices need to change in the accelerated application life-cycles that many IT organizations are aiming for, Microservices can actually improve an organization’s security framework significantly. There are four key security benefits that Microservices can bring in, and security professionals should start to recognize how this architecture addresses traditional security challenges very well.
- Accelerated deployment of critical security patches
There’s no denying that lagging patch distribution is a widespread issue—so much so that there are products that allow security patches to be enabled with virtual patching until the patches can be applied to running systems. In effect, this approach gives up on putting patches where they should go and places them in a front-end system. While this approach addresses patch distribution, it naturally comes at a cost to system performance.
Fortunately, Microservices can make patch deployment easier and quicker. Because most organizations marry a DevOps frequent-release cycle with the move to Microservices, instead of releases occurring once or twice a year, they can happen once or twice a week—or multiple times a day. That means important security updates can start protecting systems much, much faster than in the past. Which is a good thing, and a reason for security groups to embrace Microservice.
2. Minuscule surface expose for attacks
A key element of microservices is that each service provides a restricted set of functionality (a bounded context). Some people characterize it as a “do one thing and do it well,” UNIX-like approach. Consequently, each service exposes a well-restricted interface. After all, if the service does only one thing, the only interface required is what’s needed to support that one thing.
The net effect of this is that each service has a smaller attack surface: the sum of the points at which a piece of software may be attacked. The smaller attack surface also makes it simpler for security personnel to know where to distribute security patches. A monolithic application executable may end up with many different functions and software components inside of it, making it difficult for security professionals to know exactly where the software that needs to be patched is running.
3. Clean/Transparent code structures
Another challenge with monolithic applications that contain multiple groups’ code is that it’s difficult for anyone to know exactly what’s in the software executable. When security vulnerabilities aren’t merely the result of deferred patches, but of poorly partitioned code or unexpected interactions between code, it’s a nightmare. Trying to track down the root cause of a security problem when different groups have their fingers in the pie is challenging, to say the least.
Microservices help with this problem because code is partitioned into separate executables. In microservices-using organizations, it’s common for one development group to maintain full responsibility for all the code running in an individual service. As a result, it’s much easier to enable peer collaboration among a small group that works on a common codebase than it is to enable collaboration among multiple teams in a huge, monolithic codebase. Coding a fix that addresses a small set of functionality is simpler, too. And since microservice-based applications deploy frequently, getting the fix into production is faster as well.
4. Functionality safeguard
One security benefit of microservices that is less appreciated is how it enables a defense-in-depth strategy. Instead of having all functionality deployed in a “front-line” service (i.e., a service that provides web access), microservices spread out the functionality. Other application functionality resides in other services that are only accessed by other application executables. This shields application functionality from the outside world and makes it more difficult for external parties to gain access to non-user-accessible functionality.
Clearly, this microservices benefit does not mean that internal services do not need to pay attention to security concerns. It does mean that those services can focus on the security issues relevant to their specific functionality without worrying about issues outside their domain. Also, critical resources such as databases are less likely to be subject to external attacks, since their access is restricted to peer services, making the overall system much more secure.
