Legacy applications are monolithic in nature, which means that all of the code they need to function lives within a single, interdependent system. One of the reasons we’ve seen businesses migrate to a microservice-based architecture is the freedom and flexibility it offers, allowing businesses to take a more deliberate and gradual approach to their evolution rather than investing heavily in a new monolith every few years. More than a third of businesses worldwide already adopt a microservice-based approach to their development, and that figure is growing rapidly. But is the security keeping up?
With traditional, monolithic applications, an API security service only needs to secure a single link between client and server. Microservices, however, which are independent and interconnected, require a more nuanced approach. Microservice security requires that each connection from a client to each individual microservice, and all of the connections between those services, be carefully considered.
Naturally, this will increase the security workload when it comes to requesting and processing security tokens, which can slow things down unless efficiently deployed. That’s if adequate security measures are deployed at all. With the potential number of vulnerabilities increasing as the technology evolves, there’s a very real risk that your microservice security solutions might not be able to keep pace as you scale your business.
Microservices are no doubt the future of digital business, but as with all new development technologies, security should be at the very top of your priority list. In this article, we’ll explore some of the key vulnerabilities that are likely to emerge as your business leans further into microservice architecture, as well as best practices that you can employ to keep your business as secure as possible.
Key vulnerabilities of a microservice-based architecture
One of the most obvious yet frequently overlooked vulnerabilities when it comes to microservice security relates to its inherent modular nature. If a monolithic system was a single block of cement, easy to guard and defend, a microservice architecture would be a carefully constructed wall made up of different size bricks that vary in importance. Each of these bricks is independent of one another, with different permissions and connections that require tailored security controls.
The more bricks you lay, the greater the security challenge comes. From a cybercriminal's perspective, we think of this as a broader attack surface area. Instead of a single target with a few entry points, your business is essentially broken up into multiple potential targets. This is why a more nuanced approach to API security is essential.
Beyond local security, microservices are often distributed over several data centers, cloud providers, and host machines. Microservices are best leveraged when they are cloud-native, meaning when they are born in the cloud and leverage it to its fullest potential. And so your security solution ought to be cloud-native too. Cloud-native security will give your business greater visibility and more robust monitoring capabilities at every data touchpoint.
Microservice architecture is also an important precursor to so-called composable commerce. Composable commerce allows your business to take a best-of-breed approach to development, drawing on the strength of third-party specialists in order to make your business the strongest it can be in all areas, and this should include security.
The benefits of composable commerce are becoming increasingly obvious, but it inevitably results in a growing third-party software supply chain that, by association, can make your business vulnerable. Take the Log4Shell exploit that was recently uncovered, for instance, making any microservice container cluster running a Java workload potentially vulnerable to attack. To mitigate this risk, your business will need to have a close security relationship with any third parties it partners with.
In working with best-of-breed software specialists that provide solutions to cater to the various needs of your site, making sure that you are happy with, and are aligned with all of their security policies and uses of data must be a prerequisite. At the same time, there are also specialist vendors that can provide a security solution to watch over the entire platform, in particular how the various microservices interact with each other.
Evolving API security
The idea of decoupling applications so they work independently of one another is what makes microservices such an attractive proposition for businesses that want to stay nimble in an increasingly competitive marketplace. But that decoupling does come with inherent risks when it comes to cross-service communication via APIs. Loosely coupled APIs are used to bridge the gap between microservices, allowing them to function as a whole for the benefit of your business.
As we touched on briefly at the beginning, monolithic businesses only have tightly coupled APIs bridging the gap between client and server to worry about; microservice-based businesses, however, have multiple loosely coupled APIs that all bridge together. If the former was comparable to securing a few straightforward A to B connections, the latter would be more like securing a complex neural network and all of its touchpoints.
Last year, Gartner published a report that said, “by 2022, API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications.” Well, here we are in 2022, and with businesses taking an increasingly microservice-based, API-first approach to the development of their services, APIs now warrant their own dedicated security focus. This might involve creating simplified API gateways for microservices in order to filter access requests, new access controls such as ‘OpenID’ or consent management, as well as content validation such as signature-based threat detection.
Most businesses are now familiar with the principle of ‘least privilege’, sometimes referred to as ‘zero trust’, whereby access controls are tiered to ensure that people are granted access to data on a strictly need-to-know basis. The principle of least privilege says that users should only have access to what they need in order to effectively perform their roles, instead of giving blanket admin access to everyone that ‘might’ need it. The same principle should be applied to your API security, with microservices only sharing as much as necessary via APIs in order for the whole to function effectively.
Whatever your plans for growth in 2022 and beyond, microservices are likely to play a key role. That means you’ll need an in-house team with the right kind of expertise to secure your APIs and help you take full advantage of microservice architecture, or you’ll need to find a trusted partner that puts security first as a core part of their offering. To learn more about microservice architecture, API security, and how to prepare to scale up securely, get in touch today.
