Security Pattern – API based Microservices

Overview

The following security pattern describes security architecture for enabling microservices-based applications exposing Restful API’s.

The microservices architecture is built around decoupled components that are separated into individual self-contained applications, and invoke each other across network communication services. Microservice applications represent small, loosely coupled entities that communicate with each other (typically) via RESTful interfaces over HTTP/S.

This differs in comparison to traditional monolithic architectures, whereby each component invokes another using internalised methods via shared memory or system resources within the same host.

The document focuses on the challenges associated to establishing a microservices architecture and the typical methods of deployment.

Typically Challenges

The decoupled nature of microservice applications increases the risk of inadvertently exposing internal functionality and components. Threats can target weakness within those microservices by directly communicating across exposed API interfaces on the network.
API based Microservices typically form a broader eco-system of interactions for multiple different consumers. API endpoints exposed may be consumed by a blend of internal, public or partner APIs clients with different security postures. These models also break down traditional perimeter based network segregation (DMZ) for securing web application services.
Microservices architecture allow for faster and more agile development cycles, but subsequently can allow for broader logic flaws to occur due to additional complexity of managing distributed systems.

Scope

The scope of this document is for addressing the security threats that relate to

ID	Description	Example
01	Deployment and execution of restful API-based microservices	Node.js microservice application
02	Consumption of microservices from internal and external clients	External B2B (Partner) and B2C (Consumer) clients

Out of Scope

ID	Description of exclusion	Reason for Exclusion
01	This pattern does not cover SOAP based services or XML structured communications.	These services require additional considerations to threat modelling and web app security.
02	This pattern does not cover microservices using web sockets	Controls applied for Restful APIs may not be applicable.
03	Application development environments and tooling for Microservices	Covered under broader security patterns such as Source Code Management and CI/CD Pipelines.

Dependencies

ID	Description	Impact from dependency not met
01	Summarised security design principles outlined under Jericho Forum® Commandments. https://publications.opengroup.org/w124	Minimal impact as these principles are used as an example set of baseline requirements within security pattern.

Constraints

ID	Description	Impact from constraint
01

Assumptions

ID	Description	Impact if assumption is false
01	Design decisions assume microservices conform to typically practices in Restful API design.	Non-conformance to best practise for Restful API will require separate considerations to controls required.
02	Design decisions assume microservices deployed within containerisation.	Different threat modelling maybe required for other technology services used to deploy microservices.

Assets at Risk

The following section provides a list of assets affected by the problem statement:

Asset Title	Asset Description
API Microservice	Represents an application that performs a complete and standalone function. It exposes API’s (Application Programming Interface) that provide a set of operations available for consuming data and services.
API Gateway	Primary function of the API gateway is to route inbound API requests to the correct microservices. It can be used as front-door and enforcement point when exposing API’s to various consumers (such as external, partners and or internal developers).
API Lifecycle Manager	Allow developers to register, publish, promote and manage API’s exposed via the API Gateway. This includes developer portals for searching and discovering published API’s associated to specific microservices. This also typically integrates into CI/CD tooling used for microservice deployments.

The following assets are also referenced within the pattern but not in scope

Identity Provider – Referenced in this pattern to describe services used for authentication of clients.
Secure Token Service – Referenced in this pattern to describe services used for issuing access tokens for authentication and authorisation.
CI/CD tooling – Required for deployment of Microservices into target hosting environments.

Threat Model

The following section provides a list of threats within the problem statement:

Threat Event (ID / Title)	Threat Description and Characteristics	Diagram
TE-14: Inadequate workflows or processes leading to flaws in deployment	Microservice based applications have increased exposure to flaws in workflows and processes due to their distributed nature. Security controls implemented for upstream components could potentially be skipped or bypassed by directly accessing downstream components (confused deputy scenario). A microservice maybe restricted from accessing sensitive processes, data or information, but can potentially still gain access by forwarding requests via other intermediary or downstream microservices that have approved access.
TE-24: Identity theft or impersonation	Microservices are reliant on passing identity and context within each request for communicating with other microservices. This opens up exposure to replay attacks for tokens, thief of exposed tokens/API Keys in query strings or exposure of unprotected credentials within HTTP header requests.
TE-26: Abuse of resources through misconfiguration	Microservices are vulnerable to flaws or misconfiguration within underlying HTTP/S or TLS protocols, used to expose Restful API’s. Microservices can be compromise if these protocols are not correctly implemented, such as poor TLS certificate validation, restrictions to HTTP Methods or weak TLS ciphers.
TE-29: Web application attacks or code injection attack	Microservice based applications still remain vulnerable to web application attacks and susceptible to command injection, encoding or serialization attacks, cross site scripting (XSS), Cross-Site Request Forgery (CSRF), and HTTP parameter tampering.
TE-40: Distributed Denial of service (DDoS) across application services	Denial of service attackers may overwhelm microservice applications with a flood of HTTP/HTTPS requests. Flaws in processing or load balancing of HTTP traffic may also allow for an application-based DOS attack within microservices.

Target State Solution

Summary

The target state solution evaluates the following design requirements to provide the expected target state solution and design principles.

Design Requirements

The target state solution is required to meet the following requirements, as referenced under Dependencies, Assumptions and Constraints.

Requirement	Implication to Design Principles
1. The scope and level of protection are specific and appropriate to the asset at risk.	Maintain segregation of microservices for connectivity between trust domains and environments
2. Security mechanisms must be pervasive, simple, scalable, and easy to manage.	The security pattern maintains clear security principles to be applied for microservices
3. Assume context at your peril.	Controls defined in this security pattern are used to identify and measure problems, limitations or issues
4. Devices and applications must communicate using open, secure protocols.	Open and encrypted communication channels such as HTTPS are applied for API Microservices
5. All devices must be capable of maintaining their security policy on an un-trusted network.	API microservices are protected against both external and internal threats
6. All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place.	Validate and inspect all traffic flows to API Microservices via API Gateways
7. Mutual trust assurance levels must be determinable.	Apply mutual trust between API Gateway and API Microservices
8. Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control.	Apply authentication and authorization for both internal, partner and public clients.
9. Access to data are controlled by security attributes of the data itself.	Maintain security attributes for API Microservices
10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges.	Apply access restrictions to API Microservice for environments hosting sensitive or high value data
11. By default, data must be appropriately secured when stored, in transit, and in use.	Apply uniform security policies within API Gateway for inbound, outbound and mediated traffic flows for API Microservices

Solution Overview

The enforcement of segmentation for API Microservices is reliant on API Gateway services. Microservices establish mutual trust with API Gateway to allow delegation for enforcement of security controls. This includes maintaining segregation for flows between environments and different flows

The consumption of APIs exposed by microservice can be summarised into three main interactions. These interactions are separated on inbound, outbound and internal flows across trust boundaries.

Flow Direction	Description
Inbound Flows	These flows represent various clients consuming APIs exposed by microservices, using the API Gateway as a broker.
Outbound Flows	These flows represent microservices consuming other internal or external services.
Internal Flows	These flows represent microservices consuming APIs exposed by microservices, using the API Gateway as a broker.

These interactions have different implications to how security controls are applied. The following further describes the security model for each flow.

Inbound Flows

The following diagram represents inbound flows originating from different client types to API Microservices.

Regardless of location (internal, public or partner) all inbound flows from various client types are strongly authenticated. The below summary list of client types are expected to authenticate using the following industry standards.

Client Type	Example	Recommended methods ^[1]
Browser	Internet browser executing Single Page Application (SPA) on a client machine. e.g. Chrome or Firefox	OpenID Connect Authorisation Code Type OR OpenID Connect Implicit Grant Type
Application Client	Stand-alone application that runs on a client machine, i.e.: .NET or Java application running on a workstation.	OpenID Connect Authorisation Code Type.
Native	Stand-alone application that runs on a mobile device, e.g. iOS or Android.	OpenID Connect Authorisation Code Type.
System to System	System application runs on a server machine to consume APIs e.g. Partner B2B transactions	OAuth2 Client Credentials grant over TLS-MA.
Server-Side Application	Traditional frontend web application that runs on a server machine to consume backend APIs.	N/A – Specific authentication method implemented on frontend presentation server not in scope for this pattern.

[1] Note: The following is a summary based on industry best practise at the time of writing. Please also refer to latest documentation from OpenID Connect and OAuth standards regarding best practice for authentication and authorisation for specific implementations.

Using Access Tokens to Establish Trust Domains

Internal and external trust domains can be established through different types of access tokens. Once the API Gateway validates an access tokens, it exchanges the ‘external’ token with a separately issued ‘internal’ access token.

The separation of ‘external’ and ‘internal’ access tokens is not prescribed under OpenID Connect or OAuth2 standards, but is a design choice for establishing boundaries between external client/provider entities and internally protected resources.

A summary for the characteristics of ‘external’ versus ‘internal’ access tokens is as follows

External	Internal
Used for resource level (coarse grained) authentication and authorisation to API Gateway.	Exchanged and passed onto API Microservices for fine grained authorisation.
Used across different trust domains such as public or partner sites	Remain within internal trusted domains and zones.
Tokens are generated, issued and signed by Security Token Service.	Tokens are generated, issued and signed by Security Token Service.
Lightweight and don't contain any contextual information for internal system or services.	Encompass same claims as corresponding external token, but are populated with more contextual information for roles and entitlements.

The use of access tokens is applied within the following model

Additional Notes

API Gateway operates as enforcement point for authorisation and access.
Clients are strongly authenticated, regardless of location (i.e. Internal, Partner or Public)
Clients are issued ‘external’ access tokens for interactions with API Gateway.
Once validated, API Gateway replaces ‘external’ access tokens with ‘internal’ access tokens (via exchange with Secure Token Service).
The Secure Token Service is responsible for maintaining the mapping between external and internal tokens, and maintain associated token lifecycles.

Outbound Flows

The following diagram represents outbound flows originating from API Microservice to a service provider.

Additional Notes

Any traffic to external public or partner locations uses content inspection for protection against data exfiltration.
- Some controls may look to whitelist connectivity to partners where controls are not applicable (e.g. web content filtering)
API Microservice traffic to backend internal provider services is not required to traverse the API Gateway (as enforcement and access control are maintained within those assets).
- Connectivity may traverse the API Gateway is mediation is required (e.g. Converting RESTful based JSON formatted traffic into SOAP based XML traffic).

Internal Flows

The following diagram represents internal flows originating from API Microservice to another API Microservice.

Additional Notes

API to API Microservice communications occurs via API Gateway as intermediary proxy.
The API Gateway is responsible for maintaining boundaries between API based microservices.

Traffic Flow Traversal Across Environments

Further to above, it’s important to also look at the trust boundaries that exist between different environments. Within this model, we look to categorise environments into the following security attributes.

Network Security Zoning: Placement of assets within network security environment (see Locations section).
Security Configuration Hardening: Tightening of asset configurations to meet security baselines (i.e. loosely controlled or tightly restricted)
Information Security Classification: Access within environment to sensitive data (i.e. sanitised data versus live data).

The security criteria for the environments are evaluated on the following attributes.

Attribute	Development	Testing	Staging	Production
Network Security Zoning	Application Development Environment	Application Non-Production Environment	Application Non-Production Environment	Application Production Environment
Security Configuration Hardening	Loosely Controlled	Tightly Restricted	Tightly Restricted	Tightly Restricted
Information Security Classification	Sanitised Data	Sanitised Data	Sanitised Data	Live Data

The following provides an overlay to the previous interactions across different environments whereby

Permitted: General access provided for endpoints and associated APIs
Restricted: Limited access provided for specific endpoints or approved APIs
Blocked: No access provided by default. Access provided by exception

Inbound Restrictions

The main principles to restrictions within inbound flows is access from clients in untrusted location accessing environments with loosely controls security configuration hardening.

	Development	Testing	Staging	Production
Internal	Permitted	Permitted	Permitted	Permitted
Partner	Blocked	Restricted	Permitted	Permitted
Public	Blocked	Blocked	Restricted	Permitted

Microservices within Development and Testing environments that would not yet be security tested or hardened are not exposed to external partner or public domains.

Outbound Restrictions

The main principles to restrictions within outbound flows is untrusted content accessed from environments with loosely controls security configuration hardening.

	Internal	Partner	Public
Development	Permitted	Restricted	Blocked
Testing	Permitted	Restricted	Restricted
Staging	Permitted	Permitted	Restricted
Production	Permitted	Permitted	Permitted

Development environments are blocked from directly accessing resources or content within external public domains. Content is cached and sync’d into internal private repository or internal services where possible.

Internal Restrictions

The main principles to restrictions within internal flows is data sensitivity associated to live data within Production environment.

	Development	Testing	Staging	Production
Development	Permitted	Permitted	Restricted	Restricted
Testing	Permitted	Permitted	Permitted	Restricted
Staging	Permitted	Permitted	Permitted	Restricted
Production	Permitted	Permitted	Permitted	Permitted

Development environments are restricted (but not blocked) from access to Production environments.

Any production environments hosting microservices that allows access to sensitive data are blocked from Development.
The exception however maybe for Production environments permitting access to underlying core infrastructure functions (e.g. Certificate Mgmt, Secrets Mgmt) are permitted.

Design Principles

The following design principles are applied for this pattern, based on the requirements.

API Gateway operates as enforcement point for inbound, outbound and internal flows.
API Gateway enforces segregation for flows between Development, Non-Production and Production environments.
Apply ‘shift-left’ methodology for security controls in Non-Production and Pre-Production environments.
Maintain segmentation between API Microservices using controls within both network security and identity and access management.
API Microservices are deployed as immutable services within environments.

Actors

List the actors involved in this pattern.

Actor Type	Actor Description
Internal API consumers	Internal staff consuming Rest APIs for microservice applications, typically via native or browser client types
Public API consumers (B2C)	External public consumer or anonymous access to Rest APIs for microservice applications
Partner API consumers (B2B)	External partners or suppler access to Rest APIs for microservice applications
API Developers	Application developers for build, compile and deploy microservice applications.
System Administrators	Manage and operate API Gateway and API Lifecycle tooling.

Locations

This pattern is applied to any locations for assets being utilised

Location	Location Description
Application Development Environment	Development or sandpit environment for API development
Application Non-Production Environment	Non-production and Pre-production environment for multiple test stage gates for API testing and deployed via CI/CD pipeline
Application Production Environment	Production environment for deploying and publishing APIs that have passed all testing stage gates required as part of CI/CD pipeline.

Sequencing

The pattern is designed within the following sequences

Stage gate	Description
Build time	Register and develop stage gate for microservices within API lifecycle
Deploy time	Compile and deploy stage-gate for microservices within API lifecycle
Run time	Execution stage gate for microservices within API lifecycle

Mapping Threats to Controls

The following provides a mapping of security threats to affected assets and the security control objectives required to mitigate them (further detailed in subsequent security pattern logical designs).

Threat Event	Affects Assets	Security Controls Objectives
TE-14: Inadequate workflows or processes leading to flaws in deployment	Microservice API Lifecycle Manager	CM-02: Baseline Configuration IA-02: Identification and Authentication (organizational Users) IA-08: Identification and Authentication (non-organizational Users) RA-02: Security Categorization SC-02: Separation of System and User Functionality SC-08: Transmission Confidentiality and Integrity SC-11: Trusted Path SC-13: Cryptographic Protection SC-32: System Partitioning SI-02: Flaw Remediation
TE-24: Identity theft or impersonation	Microservice API Gateway	AC-03: Access Enforcement AC-04: Information Flow Enforcement AC-14: Permitted Actions Without Identification or Authentication AC-24: Access Control Decisions AU-02: Event Logging IA-09: Service Identification and Authentication SC-08: Transmission Confidentiality and Integrity SC-13: Cryptographic Protection SC-17: Public Key Infrastructure Certificates SC-23: Session Authenticity SC-26: Decoys
TE-26: Abuse of resources through misconfiguration	Microservice API Gateway	AU-02: Event Logging CM-02: Baseline Configuration CM-06: Configuration Settings RA-05: Vulnerability Monitoring and Scanning SC-11: Trusted Path
TE-29: Web application attacks or code injection attack	Microservice	AU-02: Event Logging RA-02: Security Categorization SI-09: Information Input Restrictions SI-11: Error Handling
TE-40: Distributed Denial of service (DDoS) across application services	API Gateway	SC-05: Denial of Service Protection SC-06: Resource Availability SC-14: Public Access Protections SC-36: Distributed Processing and Storage

Security Pattern

Pattern View: API Microservices

Control list: Microservice

Control Objective	Control Description
AC-03: Access Enforcement	Access to APIs are authenticated using access tokens, i.e. JSON Web Tokens.
AC-04: Information Flow Enforcement	Enforce access to API microservices via API Gateway by validating requests using cryptographic checks i.e. API request is signed by API Gateway.
AC-14: Permitted Actions Without Identification or Authentication	Do not permit anonymous access directly to API’s. API’s always authenticate and validate requests to ensure these have traversed API Gateway.
AC-24: Access Control Decisions	Resource level access control is validated within API Gateway. Fine Grained access control is validated within Microservice.
AU-02: Event Logging	Microservices that generate security event records are aggregated into a centralised security event monitoring (SIEM).
CM-02: Baseline Configuration	Maintain hardened security configuration for exposing APIs from Microservice.
IA-09: Service Identification and Authentication	Ensure access tokens or credentials (API Keys) are issued from trusted identity providers.
RA-02: Security Categorization	Maintain metadata for each Microservice on security categorisation and approved exposure across different endpoints (Internal, Partner, Public)
RA-05: Vulnerability Monitoring and Scanning	Regularly apply vulnerability scanning across API interfaces to identify potential weakness or flaws in TLS or HTTP configuration.
SC-08: Transmission Confidentiality and Integrity	Enforce usage of secure protocols for data transmission.
SC-11: Trusted Path	Consumption of APIs is only initiated from API Gateway when the requests are properly signed.
SC-13: Cryptographic Protection	API clients and Microservices implement message or field-level encryption if end-to-end encryption is required.
SC-23: Session Authenticity	Validate authenticity of access token (expiry and signature) for all API requests.
SC-26: Decoys	Honeypot microservices are deployed for detection of malicious activity or use of compromised credentials.
SC-32: System Partitioning	Microservice deployments are partitioned and segregated between environments (Production, Non-Production and Development)
SI-02: Flaw Remediation	Security testing is applied for microservices within Application Non-Production Environment. This may include Static Source Code Analysis, Software Component Analysis, Malware Scan or Dynamic application security testing.
SI-09: Information Input Restrictions	Apply fine-grained validation rules to inspect API messages, i.e. Business rules validation.
SI-11: Error Handling	Microservice manage errors and report sanitised failure information.

Control list: API Gateway

Control Objective	Control Description
AC-03: Access Enforcement	Client access to APIs is authenticated and authorised using industry standards (OpenID Connect / OAuth2). Once authenticated, API Gateway exchanges ‘external’ token for ‘internal’ token (issued by Secure Token Service) before forwarding messages to API Microservices or downstream systems.
AC-04: Information Flow Enforcement	Ensure API requests are via API Gateway. Apply digitally signature in request header for API Requests being forwarded to downstream APIs.
AC-14: Permitted Actions Without Identification or Authentication	Anonymous public APIs do not require authentication or authorisation. Exposure of these APIs are separated from authenticated endpoints.
AC-24: Access Control Decisions	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.
AU-02: Event Logging	Endpoints exposed via API Gateways generate security authentication and authorisation audit records for all API transactions.
CM-02: Baseline Configuration	Maintain hardened security configuration for exposing APIs within endpoints.
CM-06: Configuration Settings	Maintain separate configuration settings for different endpoints exposed on API Gateway (Internal, Public, Partner)
IA-09: Service Identification and Authentication	Challenge clients for access credentials from trusted whitelist of identity providers.
RA-05: Vulnerability Monitoring and Scanning	Regularly apply vulnerability scanning across endpoints exposed by API Gateways to identify potential weakness or flaws in TLS or HTTP configuration.
SC-05: Denial of Service Protection	Denial of Service and Distributed Denial of Service Protection is implemented for protection against network and HTTP protocol abuse.
SC-06: Resource Availability	Apply performance counters, thresholds and rate limitation to protect availability of APIs and back-end resources.
SC-08: Transmission Confidentiality and Integrity	Enforce usage of secure protocols for data transmission.
SC-11: Trusted Path	Expose separate endpoints to API consumers originating from different trust domains (e.g. Internal, Partner, Public). Apply API firewall rules to control access to APIs.
SC-13: Cryptographic Protection	Ensure support for API requests that implement message or field level encryption.
SC-14: Public Access Protections	Enforce web application firewall rules to inspect API messages (e.g. CWE/SANS Top 25 or OWASP Top 10). Ensure API messages containing binary data or used for file transfer are scanned against malicious payloads or malware.
SC-17: Public Key Infrastructure Certificates	Endpoints exposed to external public or partner trust domains utilise trusted 3^rd party Certificate Authority. Endpoints exposed to internal domain may use internal private Certificate Authority.
SC-26: Decoys	Expose APIs from honeypot microservices to detect malicious behaviour or attempts to use credentials stolen or compromised.
SC-36: Distributed Processing and Storage	Support backend scaling of immutable microservices as additional mitigation to Denial of Service attacks.

Control list: API Lifecycle

Control Objective	Control Description
CM-02: Baseline Configuration	Ensure standard deployment of microservices to each environment using approved CI/CD orchestration tooling.
IA-02: Identification and Authentication (organizational Users)	Uniquely identify all developers accessing API Developer Portals or other lifecycle tooling. Remove any shared accounts.
IA-08: Identification and Authentication (non-organizational Users)	Uniquely identify all developers from external or partner organisations accessing API developer portals or other lifecycle tooling.
RA-02: Security Categorization	API Developer portals are able to query microservice metadata for approved endpoints and security categorisations.
SC-02: Separation of System and User Functionality	Limit access to system functions and portals for API lifecycle management versus access provided to API developer portals.
SC-08: Transmission Confidentiality and Integrity	Ensure access to API lifecycle management tooling and API developer portal occurs across encrypted channels.
SC-11: Trusted Path	Ensure API registration and deployments to environments occur through appropriate CI/CD tooling.
SC-13: Cryptographic Protection	Sensitive authentication data such as API keys or credentials managed under secrets management. Registration for access to APIs are also exchange sensitive authentication data via secrets management (rather than exposing via developer portals).
SI-02: Flaw Remediation	Any microservice detected with security defects identifying in test environments are not permitted onto further deployment phases.

Appendix A – References

Please see below links to external sites for further reading