New requirements for Securing Microservices Vs. Monolithic Apps
Enterprises are migrating from monolithic applications to microservices, hoping to accelerate software deployment and improve scalability. Security is sometimes glossed over in these transitions.
Simple best practices like authenticating users and using SSL are still important to follow. But teams need to think through important differences between the two architectures to ensure new risks are not inadvertently introduced.
As you begin Ā migrating from a monolith to microservices, some of these issues may seem relatively trivial. But left unaddressed they can create substantial security vulnerabilities, reduce performance, and result in technical debt.
Some of the most important differences to consider include the number and size of attack surfaces, and how and where teams manage business logic security. Teams also need to think through the additional complexity of increased communication between microservices running in separate containers or machines. New issues also need to be addressed when application state is stored externally.
1. One Larger Versus Many Smaller Attack Surfaces
The biggest difference relates to the size and number of attack surfaces. A monolithic application is by definition a single application with a single attack surface. In contrast, a microservice architecture spreads the same functionality across multiple, independently running microservice applications, each with their own attack surface.
The attack surface on the single monolithic app is also larger than on each microservice because the application has far more responsibilities to control. Ā In contrast, the attack surface of each microservice is much smaller because they are limited in what they can do. In traditional web application security, a web application firewall can protect the entire application in aggregate. With microservice security, however, teams need Ā to think about securing the connections to each microservice using a more adaptable firewall.
2. Managing Business Logic Security
Web application firewalls provide a front line of security to track what clients are requesting data and ensuring they have the appropriate credentials. Monolithic applications often add an additional layer of business logic security using a servlet. This performs logical filtering within the app itself to ensure requests are reasonable before passing them to the appropriate component.
As a result, monolithic app components can operate on the assumption that the request has been validated at the application programming interface (API) level by the servlet. The servlet can keep track of who is making calls into the application and block requests that fall outside the bounds of normal behavior. A microservice rarely if ever has any idea about what has been done between other microservices. They are typically designed to operate independently from the details of everything around them, which means that business logic-level attacks are easier to perpetuate.
3. Service-To-Service Complexity
In a traditional monolith, messages are passed between functions within the application. In a microservice architecture, this traffic passes between multiple services that may reside behind a common firewall or separate firewalls.
Developers may mistakenly believe these communications are safe when the messages are passed between services that exist behind a common firewall. But because of the dynamic nature of microservices, sometimes these communications are passed over wider networks. There can be security issues when data is passed between applications in plain text.
Teams should consider encrypting data in transit as it is passed between microservices, and then encrypting data at rest when it is stored. Ā This encryption requires teams to think about creating an encryption process that runs in conjunction with provisioning and managing microservices. Each service needs to be provisioned with a public certificate and private key. There also needs to be a method for revoking Ā certificates and issue new ones when services are decommissioned or compromised.
4. Authentication Latency
Microservices can also increase the number of authentication steps required to execute a transaction. In traditional application security, an API security service only needs to secure one link between client and server. Ā With microservice security, additional consideration needs to be given to securing the connection from a client to each microservice and to the calls between them. This increases the number of security steps required for requesting and processing security tokens. Unless this process is efficiently engineered, each request can add latency and degrade performance.
Some organizations may skip some of these steps, under the assumption that these services are communicating on a secure virtual private network. However, this can increase app vulnerabilities if the network is compromised. Another approach lies in implementing a better strategy for API security.
5. Immutability
Monolithic applications manage data as part of their operations. In contrast, microservices are architected so all data is stored external to the microservice, which is called immutability because the service does not change state. This makes it easier to spin up new instances or kill running ones without affecting the application as a whole. But because the microservice itself does not change, an external process needs to maintain a list of which microservices are allowed to talk to others. These need to be managed centrally and then either pushed out or pulled in to each microservice automatically.
Another challenge is data integrity. In a traditional application, the state of a transaction can be monitored internally; if a step cannot be completed the entire transaction can be rolled back. In a microservice architecture this kind of state management needs to be managed externally.
6. More Services To Monitor
Traditional infrastructure-based monitoring was designed for providing endpoint and server security. Microservices generate more traffic between services at a finer level of granularity, Ā which can make it harder to automatically enable application observability through metrics, logs, and tracing. This is difficult enough just for measuring operational health, and even harder for tracking security posture.
Another challenge confronting security designers lies in ensuring consistency for application observability data generated across microservices. At the least, security requires good logging and integration into incident response systems to alert security analysts to the possibility of subtle and slow-moving security breaches. More sophisticated approaches can combine these richer data sets with machine learning to help detect and block attacks without burdening teams with false positives.
Planning for a New Security Posture
None of these security concerns should be deal breakers for transitioning to a microservices architecture. But as enterprises begin to scale up their microservices implementation, these issues will grow in complexity. A little planning upfront could reduce the need for significant rework down the line.
Security tools such asĀ Traceable’s Defense AIĀ are emerging to address these challenges in a more automated way. The key lies in balancing the appropriate set of rich observability data and machine learning, with a deep understanding of the rapidly evolving API threat landscape.
