Microservices Security | Best practices to follow

Neova Solutions
6 min readApr 27, 2020

Microservices is an architecture in which all the components of the system are put into individual components that can be built, deployed, and scaled individually. Microservices can serve as an elegant way to break the shackles of monolithic architectures when building or deploying applications. Apart from pioneers such as Netflix, which began exploring this territory a few years ago, chances are microservices are something relatively new for your organization. Protection against cyber-attacks illustrates an even bigger unknown for many.

Let me explain to you a simple analogy

You must have seen how bees build their honeycomb by orienting hexagonal wax cells. In the first instance, they start with a small section using various materials and continue to build a large beehive out of it. These cells form a pattern resulting in a strong structure that holds together a particular section of the beehive. Here, each cell is independent of the other but it also corresponds with the other cells. This means that damage to one cell doesn’t damage the other cells so bees can recreate these cells without impacting the complete beehive.

In this above diagram, each hexagonal shape represents an individual service component. Similar to the working of bees, each agile team builds an individual service component with the available frameworks and the hand-pick technology stack. Just as in a beehive, each service component forms a robust microservice architecture to provide better scalability. Besides, issues with each service component can be handled individually by the agile team with minimal or no impact on the entire application.

Why microservices?

Microservices Security — Presumably not what you think it is

Microservices and container security are sometimes incorrectly referred to interchangeably, even though they are two different things. This may be due, in part, to how most enterprises run microservices on containers.

The incertitude between containers and microservices might also have a lot to do with how container security protocols can help to protect against potential vulnerabilities of microservices within containers.

It would be easier if there were a simple algorithm on how to secure a microservice. Unfortunately, there is no such thing. However, there are some practices that can be used as a guide on the way to securing microservices.

1. Use TLS protocols for all APIs

Any application consisting of microservices needs an API as a key. If there are many independent API services, this software might require some additional tools to manage those APIs.

So, what you definitely need is access control. That will provide you secure authentication and authorization. There are some frequently used servers that allow administrators and developers to attain tokens for API authentication.

You can also use third-layer-security protocols for all the APIs to make sure that the system is protected from practicable attacks. All APIs that might be exposed must have an HTTPS certificate. One more last but not the least essential element is to encrypt all the communication between client and server with transport layer security (TLS).

2. Profile all your APIs due to their deployment zones

Malicious software, such as bots often aims at exposing the capabilities of the service too many more recipients than required. Technically, only authorized users are supposed to have access to them. To avoid unnecessary exposure, developers can label all the APIs to ensure who should be able to access them.

The API topology goes as follows:

  • Corporate Zone — private traffic.
  • Hybrid Zone — minimal deployments can be recorded at the data center.
  • DMZ — a zone for traffic originating from the Internet.
  • Ethernet — the app is vulnerable to those outside the data center.

There is also a process called network segmentation. This allows developers to perform partition of traffic and illustrate different content to different user segments.

3. Use OpenID or OAuth 2.0

The main task of these tools is to allow the developer to process user tokens. OAuth 2.0 protocol particularly simplifies the process of securing microservices.

It is an authorization framework that allows users to procure admittance to a resource from the resource server. This is done using tokens.

There are 4 different roles that OAuth 2.0 can play in microservices security patterns: resource server, resource owner, authorization server, and client. These tokens are accountable for access to the resource prior to its expiry time.

There are also refresh tokens that are in charge of requesting new access after the original token has expired.

4. Don’t show sensitive data as plain text

Plain text is easy to read, copy, and overwrite by people and machines. While working on securing the personally identifying information you need to make sure that it is not being displayed as a plain text. All the credentials — passwords and usernames should be masked during the storing in logs or records.

However, adding extra encryption above TLS or HTTP won’t add protection for traffic traveling through the wire. It can only help a little bit at the point where TLS terminates, so it can protect sensitive data from accidentally dumping into a request log.

Additional encryption might help you protect data against those attacks that aim at accessing the log data but it will not help with those which try accessing the memory of the application servers or the main data storage.

5. Use Multi-factor Authentication

It is safer to use a multi-factor authentication system when a user comes to the website and you need to authorize that user. Most apps use two-factor authentication, which requires a username and password as well as another form of identity verification.

By using multi-factor authentication (MFA), you offer your users better protection by default as some aspects are harder to steal than others. For example, using biometrics for authentication takes microservice security on a whole new level.

6. Protect Public APIs From Denial-Of-Service-Attacks

It’s not a rare situation for applications to get sabotaged by Denial-Of-Service-Attacks. Deliberately those are attempts of sending an overwhelming number of service messages with the aim of causing website failure. Such attacks can present themselves in many different shapes. They can also target the entire platform and network stack out of which most of the DoS attacks concentrate on volumetric flooding of the network pipe.

There is a way to prevent huge numbers of API requests causing the DoS attack or other problems with API services. You need to set a limit or restriction on how many requests in a given period of time can be sent to each API.

If the number exceeds the limit, you can block the access from a particular API for some reasonable interval, and also make sure to analyze the payload for threats.

7. Use Encryption Before Persisting The Data

We have already discussed additional encryption of sensitive data instead of showing it as a plain text. Another option that is highly recommended is that you encrypt the user data before persisting it.

You can also adopt some strong cryptographic algorithms such as RSA 2048+ or Blowfish. They make data transmission much safer. Remember to make sure that the algorithms are compliant with industry standards.

Conclusion

Microservices security requires non-trivial or ready-made solutions. We categorized some of the best practices that might help you with the security of your applications.

Nevertheless, remember that when it comes to security, there is always room and demand for innovation. It’s always better to use cutting edge tools and technologies than sticking with old-fashioned approaches and hoping for the best.

Originally published at https://www.neovasolutions.com on April 27, 2020.

--

--

Neova Solutions

We transform ideas into beautiful products. Since 2007, we are empowering startups to build disruptive products that are feature-rich and robust.