Microservices and Security: Increasing security by increasing surface area

One of the most important security principles for microservices is to ensure that any microservice is well defined, well-documented, and standardized. A best practice for creating that definition and standardization is an API. APIs define, in a productized way,  the mechanism of accessing any particular component of the systems.

In order for an API to provide a secure and well defined access point to a microservice, it must have the following characteristics:

• Confidentiality
• Integrity
• Availability
• Reliability

A secure API is one that can guarantee the confidentiality of the information it processes by making it visible only to the users, apps and servers that are authorized to consume it. It must be able to guarantee the integrity of the information it receives from the clients and servers it collaborates with, so that it will only process such information if it knows that it has not been modified by a third party. The ability to identify the calling systems and their end-users is a prerequisite to guarantee those security qualities. What we have stated also applies to those calls that the API makes to third party servers. An API must always be available to handle requests and process them reliably.

While building APIs to provide standardized and well-defined access to microservices is a good first step to ensuring the security of your microservices, that step is not sufficient in and of itself. The next step is to establish API management policies to provide governance and visibility into how the APIs are functioning.

The four principles of API management for security are:

• Publish your APIs so that developers of consuming software have everything they need to self-serve their needs and understand clearly the purpose, scope and interface of your microservice.
• Adapt your APIs through injectable Policies of logic covering security, quality-of-service, auditing, dynamic data filtering, etc.
• Watch your APIs so that you can strategize scalability according to traffic levels and take a temperature gauge on the impact of your assets.
• Tailor your APIs to the specific needs of different lines of business so that API management becomes a decentralized or federated exercise in collaboration between LOBs and central IT.

If the business has connected a few of these services and exposed those connections as APIs, you should be able to reuse those services, discover that connected entity and go ahead and connect it to the next one. As you're building out, and connecting more and more of these systems, you're not necessarily connecting more and more connections, you're actually reusing the ones you've already done. If somebody's figured out how to access something, or a system level person has enabled access to a certain system, you should be able to reuse that access the next time that you do that. That means that there's a single point of governance for that access, even though multiple people can actually make use of that access. Over time, you end up building just the right connections, not everything to everything, but the ones that actually make business sense and then layering value after value on top of those

Combined with API management principles, the fact that everyone in the business is using those standardized connections means that there is a well-defined, standardized framework through which one can visualize, manage, and control access to central systems. But it’s important that each microservice and its API access point have have built-in mechanisms for visibility and security. Suddenly, if everyone is responsible for security, that means security principles are spread throughout the enterprise and designed into each microservice, rather than security having to impose standards on top of everything, which slows down the process.

An important concept in microservices design is that each microservice has to be well-defined for a specific business capability. A developer doesn’t have to be an security expert in everything to work within a microservices architecture, they do have to understand, for your domain, who should have access, why should they have access, not in the sense of necessarily in creating the authentication mechanism, but saying from a business perspective, "the only things I want to expose, perhaps, is I would like people to be able to get certain information about their invoices."

Take a look at best practices for microservices and more resources.