BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Many companies jump at the opportunity to migrate to microservices due to its many advantages, such as faster deployment...
speeds and increased independence of services. However, the migration from a monolithic architecture to a microservices architecture changes aspects of application architecture management significantly, and one of those critical aspects is security.
Why microservices requires a different mentality
Microservices largely does away with many traditional or monolithic-based security challenges and presents a new range of difficulties. The fundamental nature of microservices is based upon breaking down and isolating an app into separate components. In a monolithic application, all components operate and communicate internally. Components in a microservices application operate and communicate in both internal and external environments, which can make monitoring and security a bigger challenge.
New architectural security challenges
In a monolithic architecture, there can often be a single point of failure that could bring down an entire operation. In a microservices architecture, application components operate in isolation from one another, which means a security breach will not immediately affect the entire stack. Despite this architectural trait, you can still expect to face several complex security challenges.
One challenge is that there is simply more attack surface to target. It's hard to keep an eye on everything within your stack when your application is made up of dozens of different microservices. A microservices-based app could use 10 containers, which translates to 10 times the number of instances to monitor. This challenge multiplies if those containers are regularly shut down and resurrected.
The second issue involves the blurred perimeter of a microservices architecture. Unlike the clear-cut security perimeter that a firewall provides a monolithic app, there is no such definitive boundary with cloud-based microservices apps.
The third challenge involves authentication and access control. It's harder to set clear user access limits in microservices apps because the perimeter is difficult to define. Also, users may not need access to every single app component, so access must become much more granular.
Ideally, you should establish security in microservices as a primary concern before you adopt the architecture. If you take security concerns into account beforehand, you can properly evaluate your security needs and make the necessary preparations.
This is where the idea of DevSecOps comes into play. A microservices architecture thrives in a DevOps environment, but it is even better off in a DevSecOps environment, in which every team member takes responsibility for security concerns. Adopting a DevSecOps culture holds everyone in your organization accountable for security. If your organization doesn't resemble a DevSecOps culture, it would be best to promote awareness of security concerns and practices among your development and operations teams.
Defend with multiple barriers
In a cloud atmosphere, providers like AWS take firewall security into their own hands. However, organizations shouldn't rely solely on a cloud provider's security measures. You should adopt a defense-in-depth strategy that creates multiple layers of security to deter attacks.
The first layer of defense is to secure your internal environment from any external connections. If any components of your application connect to a public network, this can present a major weak spot. For example, containers based on images from a public repository are susceptible to an attack and should be secured properly.
The next security layer is detection. Teams should schedule routine monitoring and create event logs that track any potential threats to the application. Docker Security Scanning and CoreOS Clair are examples of tools that can help.
Access control acts as another barrier to protect your application. Although they may be a burden to implement, strict access control permissions and proper networking ensure that only the correct users gain access to the appropriate segments within your stack.
If it seems like security in microservices may require more manpower than your company has, automation is an option. There are several different levels of security automation, and there are a number of microservices and container-specific security automation services available.
Even if you take all the necessary precautions to ensure you have a secure microservices-based application, you must work to maintain that security.
Application updates are one of the most common ways in which apps become vulnerable. It is important to not rush out updates for short-term gratification. Long-term protection -- and, ultimately, the success of the application -- relies on diligent application update processes.
Threat modeling presents security teams with a great method to evaluate an app's current state and make sure it is up to standards. It enables you to gain perspective on your app's defense, and it's also a great way to get a glimpse into the different types of threats and how they could affect vulnerabilities in your system.
It may require a radical culture shift, but a DevSecOps approach and a defense-in-depth strategy should form the foundation of security in microservices. By enacting these changes to your organization, you will be prepared to react to the threats that a microservices architecture can throw at you.