Microservices design and security best practices

Over the past few years, microservices architecture has been an emerging trend in the software development world to provide fast development, better scalability, and loosely coupled services. However, several autonomous services use different technologies, tools, languages, and frameworks in every business domain. Continuous communications occur across these independent services deployed in multi-cloud environments. So, it may cause various security issues like data inconsistency, data leaks, and other surface attacks. Using software security, we protect against data loss, disruption of services, data leaks, and data inconsistencies.

What is microservice?

Microservice is an architectural and organizational approach to developing applications where software is composed of small independent services that communicate over a well-defined interface using lightweight APIs.

These services are highly maintainable, loosely coupled, independently deployable, scalable, and organized around business capabilities. It helps automate testing and deployment and provides short deployment cycles with minimal application downtime.

Secure Architecture Process

To make our system as secure as possible, our system design must be secure. Good design can help to develop a good security system. This process starts at the beginning of the system life cycle and never ends. The threat modeling stage is a crucial stage to sketch all possible threats to the system. This is the first stage that plays a significant role in ensuring our system is as secure as possible. Below are the stages for the security architecture process.

Threat Modelling
Secure Architecture
SDLC
Testing
Production

Threat Modelling

Threat modeling is the process by which potential threats such as structural vulnerability can be identified and enumerated, and countermeasures prioritized. The purpose of threat modeling is to provide defenders with a systematic analysis of what controls or defences need to be included, given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker.

Threat Modelling

Secure Architecture

Define secure architecture based on the threats defined in the Threat Modeling. The architecture process for application development is as below:

Understand the system requirements
Understand the non-functional requirements
Map the components
Select the technology stack
Design the architecture
Secure architecture documents

Secure Microservices Identity

When calling microservices, the called service should know who calls it and whether the call is allowed or not (authentication and authorization).

Service Identity: The called service receives the identity of the service calling it and decides whether this call is allowed. It is useful for managing Service to Service communication. It limits access based on calling services. Service Identity is used for non-interactive scenarios like no login screen for the end user. The calling service must have a token that can be used for authentication. This token data represents the authorized caller to a service. This token comes in one or two shapes, usually API Key or Access Token.
1. API Key: API Key is provided by called service or central identity management. It sends along the request, and the called service validates it and decides whether it is allowed access.
2. Access Token: Access Token is provided as part of the OAuth2 authentication flow. In this flow, before calling to service, calls go to the authentication server, identify yourself using the application id and some secrets, and then get back the access token. This token is sent as part of a service request, and the calling service validates this token by calling the authentication server. This token is time limited. It requires deep integration with the authentication server.
User Identity: The called service receives the identity of the end-user calling it and decides whether this call is allowed and useful for auditing user actions in the system. It limits access based on end-user permissions. User interaction (login page) is required for user identity. The result of authentication is usually JWT. This JWT is passed to the called service, which validates it.

Securing Microservices Data

Securing Microservices data is not different from regular architecture. No matter how many databases are in the system, all data should be encrypted. Always brainstorm to choose the correct and secure cloud or non-cloud database based on application needs.

Microservice architecture best practices

When multiple client apps communicate to large or complex microservice-based applications, all microservices must be exposed to the external world, which makes the attack surface larger than if we hide the microservices that are not directly communicated by the client app. The best solution to reduce the attack surface is API Gateway.

API Gateway

The primary function of the API gateway is to route inbound API requests to the correct microservices. It can be used as a front door and enforcement point when exposing APIs to various consumers (such as external partners and or internal developers).

API Gateway can add value and make it easier to expose your services to your consumers by implementing a standard set of security policies across all APIs. API Gateway operates as an enforcement point for inbound, outbound, and internal flows. It maintains segmentation between API Microservices using controls within both network security and identity and access management.

API Gateway

Microservices architecture using API Gateway:

Client access to APIs is authenticated and authorized using industry standards (OpenID Connect/OAuth2). Once authenticated, API Gateway exchanges an ‘external’ token for an ‘internal’ token (issued by Secure Token Service) before forwarding messages to API Microservices or downstream systems.
Ensure API requests are via API Gateway. Apply digital signature in the request header for API Requests being forwarded to downstream APIs.
Anonymous public APIs do not require authentication or authorization. Exposure of these APIs is separated from authenticated endpoints.
Resource-level access controls are validated within API Gateway based on ‘external’ access tokens. Fine-Grained access controls are validated within API Microservice based on ‘internal’ access tokens.
Endpoints exposed via API Gateways generate security authentication and authorization audit records for all API transactions.
Maintain separate configuration settings for different endpoints exposed on API Gateway (Internal, Public, Partner).
Challenge clients to access credentials from a trusted whitelist of identity providers.
Regularly apply vulnerability scanning across endpoints exposed by API Gateways to identify potential weaknesses or flaws in TLS or HTTP configuration.
Denial of Service and Distributed Denial of Service Protection is implemented for protection against network and HTTP protocol abuse.
Apply performance counters, thresholds, and rate limitations to protect the availability of APIs and back-end resources.
Enforce the usage of secure protocols for data transmission.
Expose separate endpoints to API consumers from different trust domains (e.g., Internal, Partner, Public). Apply API firewall rules to control access to APIs.
Ensure support for API requests that implement message or field-level encryption.
Enforce web application firewall rules to inspect API messages. Ensure API messages containing binary data or used for file transfer are scanned against malicious payloads or malware.
Endpoints exposed to the external public or partner trust domains utilize trusted 3^rd party Certificate Authority. Endpoints exposed to the internal domain may use internal private Certificate Authority.

Microservices Security Testing

Microservices architecture requires much more attention while testing our services. DAST (Dynamic Application Security Testing) and SAST (Static Application Security Testing) approaches are used to test applications to find security vulnerabilities that can make our system liable to attack.

SAST
DAST

SAST is a white box testing methodology; it scans the code to find software flaws and vulnerabilities such as SQL injection, sensitive data exposure, cross-site scripting (XSS), security misconfigurations, outdated components, security logging, identification, authentication failure, etc. Some useful tools to identify security vulnerabilities like 42Crunch, Checkmarx, FOSSA, etc.

DAST is a black box testing methodology that examines an application as its running to find vulnerabilities that an attacker could exploit.

In microservice architecture each services are separate and isolated. When multiple client apps communicate to microservice-based applications, all microservices must be exposed to the external world

Summary

Microservices bring easy scalability and agility to today’s digital world. The complexity of the microservices architecture comes with a wide surface attack. If we want a more secure system, our microservices design and communication should be as secure as possible. To secure microservices, we need to embed security into architecture. Microservices securities strategies covered here should provide a good understanding of microservice design to secure our services. This is not a one-time process to secure our services while designing our system; it needs to be improved from time to time based on the kind of security attacks we are facing.

References

Share On

Copy link