This repository documents a proposed architecture for implementing a microservices-based design hosted in Azure App Services (Azure Functions). The use-case for this architecture is focused on organizations building "greenfield" (cloud-native) applications that process sensitive data. Sample code and deployment scripts are included to provide an end-to-end demonstration of the security components supporting this design.
The security model behind this architecture is an attempt to reflect the following objectives:
- Supportabiity - Avoid introduction of software components that cannot be supported by Microsoft.
- Productivity - Bias towards Azure-native services as much as possible to reduce or eliminate administrative burden and security needs introduced by IaaS.
- Performance and Scalability - Security layers should not impose significant performance penalties. The solution must support enterprise scalability needs without incerases in complexity.
- Manageability - Provide clear separation of responsibility across enterprise teams (ex. developers, DevOps, monitoring and incident response, governance, etc.)
From an operational perspectice, the security model is organized into the following three layers:
In the outer layer, platform configuration standards represent baseline governance controls, many of which can be applied enterprise-wide via policies regardless of the workload type. These policies enforce settings for most services used by the architecture. The application security controls layer represents the architecture and configurations of the application itself and its surroundoing lifecycle activities. For microservices, this could mean adherence to concepts like Zero Trust Security, secure development lifecycle workflows, logical segmentation of services, and aligment to specific threat models. Finally, the data authorization layer is responsible for ensuring all operations are executed within a legitimate and approved context. In this layer, factors such as user consent and industry compliance requirements are taken into account.
The three layers of the above conceptual security model are realized in Azure through the following architecture components:
| Layer | Component | Security Capabilities |
|---|---|---|
| Platform | Azure Policy | Enforce Azure SKUs. Mandatory PaaS service settings |
| Platform | Network Security Groups | Ingress and egress network topology and controls. Network level segmentation. |
| Application | App Services > Mutual TLS | Allow only authenticated network connections. Forward client certificates. |
| Application | Azure Functions Premium | HTTP triggers from private VNET w/ access to resources in a private VNET |
| Application | App Services Environment | Fully private and dedicated instance of App Services injected into a VNET |
| Application | Application middleware | Authorize network connection based on client certificate |
| Application | Managed Identity | Authorize API calls via OAuth |
| Application | Azure API Management | Centralized data and control plane for microservices |
| Application | Application Insights | Monitor network connections. Customized alerts. Application telemetry. |
| Data Authorization | Data authorization service | Custom service for evaluating application API calls |
Two deployment topologies are under consideration in this repository. The first leverages Azure Functions Premium for hosting microservices as shown in the followign diagram:
The second deployment makes use of Azure's fully private PaaS offering, App Service Environment (ASE). Because ASE is a fully private compute environment for hosting Functions, network segmentation controls are simplified.
Further documentation, including deployment scripts can be found on the following pages: