In the world of software development, microservices is a variant of service-oriented architecture (SOA). It is an architectural style in which software applications that are typically built as monoliths and run in a single process are decomposed into smaller parts. Each of these parts is called a microservice, running independently with its own process.

Creating a mental picture of monolith versus microservices is relatively easy:

Microservices is a great way to redefine large-scale software projects because it is more flexible and allows for on-demand scalability and much shorter release cycles. As a result, forward-thinking organizations have been increasingly moving to the microservices development style. With this architecture’s fine-grained services and lightweight protocols, it can help teams increase product modularity, making applications easier to develop, test, deploy, modify and maintain over time.

Microservices is also good for scalability. If teams want to scale up one component, they can do that without having to scale the entire project. Scaling up can therefore be a lot faster and less costly.

It might sound like microservices is a cure-all for software development woes. But like any other domain, it has its disadvantages; moving to microservices adds complexity and security implications. Regardless of how an application is designed, major gaps could potentially be introduced on the platform level. In microservices, security concerns can get exacerbated due to the various network connections and application programming interfaces (APIs) used to forge communication channels between the components of the microservice architecture. Another issue is that, if not properly designed, the standardized replicable nature of containers could spread out any vulnerability manyfold.

From managing user access to the code all the way to implementing a distributed firewall, one thing is clear: Ditching monolith for microservices may be right for your organization, but the relevant security considerations must be addressed early in the process.

The Microservices Trinity: Cloud, Containers and DevOps

Microservices are containerized and accessed on scale via cloud infrastructures. To make microservices flow effectively, organizations must adopt a DevOps culture where small, multidisciplinary teams work autonomously, applying Agile methodologies and including operations in their scope of responsibility.

This combination of factors can increase overall security risk for the organization in general and, more specifically, through the phases of a microservice-based application project: planning, development and post-deployment operations in cloud-hosted architectures.

Key Concerns: Knowing Where to Look First

In general, organizations nowadays are aware of their overall risk appetite and know that new projects always introduce new risk considerations. With a move to microservices, we are looking at a gradual process that breaks one large, monolithic project into smaller parts, each of which needs to be managed as its own project. Below are a few key concerns to look out for when operating a microservices architecture.

Isolation

Isolation is at the core of the microservices concept. To be an autonomous piece of the overall application puzzle, a microservice needs to be its own island in a sense — architected, created, deployed, maintained, modified, scaled and, eventually, retired without affecting any of the other microservices around it.

One area where isolation is much-needed is on the database level. Monolithic applications where every part of the application can access any part of the databases can, over time, impact performance due to deadlocks, row locks and errors. Microservices, in contrast, can avoid that if isolation is applied — for example, if it is decided that only one microservice will access one data store and integration with the entire database is eliminated. In a security sense, that means more microservices and more data stores to secure. But if done correctly, one microservice will not be able to access the data of another and, if compromised, it will not give way to an attacker moving laterally.

Another area that requires isolation is deployment. The goal is to ensure that each microservice is deployed without impacting others around it and, should it fail, that the effect would not bring down other microservices as well. The biggest challenge typically applies to multitenant applications, which require isolation on both the microservices and data levels, such as in software-as-a-service (SaaS) scenarios.

A Preference for Hybrid Clouds

Developing at scale usually takes place in the cloud, and most organizations have been doing it for years now. That can also mean that any given organization operates different parts of its infrastructure of different clouds with different vendors. Securing microservices will therefore have to be cloud-agnostic and applicable to any environment with relevant controls in place to achieve uniform effectivity across the various cloud infrastructures.

Insecure DevOps Tool Sets

There are some great open-source tool sets out there built for DevOps teams, and they can be used in most Agile developments. What these tools may not always offer is proper security. Integrating open-source tools into the team’s projects requires assessing exposure and adapting controls ahead of integration, as well as reevaluating them over time. Open-source also means access for all, and that often gives way to opportunities for attackers to plant or exploit vulnerabilities and infect tools with malicious code.

Interservice Communications

Interservice communication is typically not a good idea for projects that exist autonomously, but in some cases it is necessary. These channels can be risky and costly if not designed and implemented properly. Securing interservice communications calls for high standards and encryption on the data level where needed.

Managing Data Layers

Each microservice manages its own data. As a result, data integrity and consistency become critical security challenges to reckon with. This is partly because of the intricacy in planning data stores to keep entries once in each store, avoiding redundancy. One store can keep a reference to a piece of data stored elsewhere, but it should not be duplicated across many stores. From a security viewpoint, we are looking at the CIA triad of confidentiality, integrity, availability — all of which must be managed correctly to provide the organization with better levels of performance and continuity than it had in its monolithic days.

Dive Into Microservice Security

Microservice architectures bring agility, scalability and consistency to the development platform. However, security in these environments often lags behind.

A major concern we face in that domain is imposing the right level of isolation based on application type, platform and data in context. We also look at privacy, regulatory concerns and possible security automation to incubate within the DevOps life cycle.

Though DevOps has already made some strides toward integrating security into the development life cycle, there’s still significant work to be done in this space.

Want to learn more? Check out our paper, “Securing Microservice Architectures — A Holistic Approach.”

The post Securing the Microservices Architecture: Decomposing the Monolith Without Compromising Information Security appeared first on Security Intelligence.