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

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

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

Outbound Flows

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

Additional Notes

Internal Flows

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

Additional Notes

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.

  1. Network Security Zoning: Placement of assets within network security environment (see Locations section).
  2. Security Configuration Hardening: Tightening of asset configurations to meet security baselines (i.e. loosely controlled or tightly restricted)
  3. 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

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.

Design Principles  

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

  1. API Gateway operates as enforcement point for inbound, outbound and internal flows.
  2. API Gateway enforces segregation for flows between Development, Non-Production and Production environments.
  3. Apply ‘shift-left’ methodology for security controls in Non-Production and Pre-Production environments.
  4. Maintain segmentation between API Microservices using controls within both network security and identity and access management.
  5. 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 3rd 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