This article describes an architecture for incorporating a Zero Trust approach to identity for your custom apps.
Architecture
Download a Visio file of this architecture.
Workflow
This scenario is based on a fictional company named Contoso Media that works with a company called Fabrikam.
(1a) After Contoso Media provides APIs via Azure API Management, external partner developers from Fabrikam test the APIs by using the API Management Fabrikam Developer product key, issued for non-production purposes.
(2a) Fabrikam runs developer tests through the API Management developer portal or through any HTTP client software. They can integrate the APIs into the Fabrikam Analytics service. The requests reach the Contoso Media API Management gateway, which validates the Fabrikam Developer product key and applies associated policies. A throttling policy is commonly used in cases like this one.
(1b) After Fabrikam developers complete the tests and the integration work, the Fabrikam Analytics solution is deployed to the Fabrikam pre-production and production environments. These external services are configured by the Fabrikam operations teams and use production API Management product keys, provided by Contoso Media.
(2b) The requests from Fabrikam Analytics also reach the Contoso Media API Management gateway, which validates the Fabrikam production API Management product keys and applies associated API Management policies.
(3) The API Management gateway accesses the back-end API for both request sources: 2a and 2b. Because the HTTP API back end, which is based on Azure Functions, is configured for Active Directory authentication and trusts only the managed identity of the API Management gateway, it can access the function. No services, other than this particular API Management instance, can access the function.
(4) Azure Functions accesses Azure SQL Database. Because the managed identity of the Azure function is granted access to the SQL database, only the Azure function can access the database.
Steps 3 and 4 demonstrate an identity-based implementation of the Zero Trust principle.
Components
- Microsoft Entra ID provides critical functionality for your Zero Trust strategy. It enables strong authentication, a point of integration for device security, and the core of your user-centric policies to guarantee least-privileged access. Microsoft Entra Conditional Access provides the policy decision point for access to resources based on user identity, environment, device health, and risk, verified explicitly at the point of access.
- Microsoft Entra application registration. To delegate identity and access management functions to Microsoft Entra ID, an application must be registered with a Microsoft Entra tenant. When you register your application with Microsoft Entra ID, you create an identity configuration for your application that allows it to integrate with Microsoft Entra ID.
- Microsoft Entra managed identities. Managed identities provide an automatically managed identity for applications to use when they connect to resources that support Microsoft Entra authentication. Applications can use managed identities to obtain Microsoft Entra tokens. You don't need to manage credentials.
- API Management is a hybrid, multicloud management platform for APIs.
- API Management developer portal. The developer portal is a website that provides the documentation of your APIs. On the portal, API consumers can discover your APIs, learn how to use them, request access, and try them out.
- API Management gateway. All requests from client applications first reach the API gateway, which then forwards them to appropriate back-end services. The API gateway acts as a facade to the back-end services, allowing you to abstract API implementations and evolve back-end architecture without affecting API consumers. The gateway enables consistent configuration of routing, security, throttling, caching, and observability.
- Azure Functions is a serverless solution that enables you to write less code, maintain less infrastructure, and save money. The cloud infrastructure provides all the up-to-date resources needed to keep your applications running so you don't have to deploy and maintain servers.
- SQL Database is an always-up-to-date, fully managed relational database service built for the cloud.
Alternatives
In addition to using managed identities, you can also limit access to the API back end by using the following methods:
You can use Azure Key Vault to store client certificates for the client certificate authentication alternative. You can also use it to store the SQL Database connection strings that are used by the API back end. This alternative, however, might require manual work or additional automation for rotating the information stored in Key Vault.
As an alternative to deploying Azure functions from Visual Studio Code, you can use GitHub Actions or Azure Pipelines for the production environments. You can generate your GitHub Actions or Azure Pipelines from the deployment center of your Azure function.
Instead of using Microsoft Entra app roles to limit access to the functions-based API back end, you can use Microsoft Entra security groups. This configuration, however, is more sensitive. It might involve communication with the corporate Microsoft Entra management team.
Scenario details
You can't assume a secure network perimeter around applications. Nearly every application, by design, is accessed from outside the network perimeter. You also can't assume that applications are secure when they're developed or remain secure after they're deployed. It's the responsibility of the application developer to maximize the security of the application and also to minimize the damage that can occur if it's compromised.
For more information, see Increase application security using Zero Trust principles.
This scenario is based on a fictional company named Contoso Media.
The Contoso Media product team has migrated some applications into Azure App Service. These applications use custom-implemented authentication and authorization.
Contoso Media applications and data are moving from on-premises to hybrid and cloud environments. Contoso Media can no longer rely on traditional network controls for security. Controls need to move to where the data is: on devices, inside apps, and with partners.
The Contoso Media team wants to increase developer speed and decrease costs while using serverless and platform as a service (PaaS) technologies like Azure Functions and SQL Database. They've heard about Microsoft Zero Trust and want to implement more modern and secure access to their services. They want to:
- Expose and provide their APIs to partners through API Management. Partner developers need to have limited access to the APIs during development. Partner pre-production and production environments, however, should have unlimited access to the Contoso Media APIs.
- Protect access to the API back end so that only one specific API Management instance can access it.
- Protect access to the Azure SQL database used by the API back end so that only one specific identity of the REST API back end can access it.
Zero Trust provides a unified approach to help the Contoso Media operations team ensure that their applications, and the data they contain, are protected. Zero Trust:
- Applies controls and technologies to discover shadow IT.
- Ensures appropriate in-app permissions.
- Limits access based on real-time analytics.
- Monitors for abnormal behavior.
- Controls user actions.
- Validates secure configuration options.
Applying protection to an API implementation and to Azure SQL, as described here, is just one facet of the verify explicitly Zero Trust principle. Other elements include user identity and device protection. All elements use the framework and services provided by Microsoft Entra ID.
Potential use cases
This pattern can be applied in many industries and architectures. Here are some example scenarios:
- A database service needs to trust only a limited number of web applications or APIs.
- An API back end needs to trust only a limited number of API Management instances.
- An API back end needs to trust only a limited number of web applications.
In all of these cases, the architecture needs to implement the identity-based verify explicitly Zero Trust principle, for end-user identities and also for the services included in the architecture.
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.
Reliability
Reliability ensures that your application can meet the commitments you make to your customers. For more information, see Overview of the reliability pillar.
API Management supports zone redundancy and multi-region deployment.
The active/active pattern, implemented via Azure Front Door, is the best cross-region deployment model for the functions-based API.
This scenario uses SQL Database for data storage. SQL Database features include zone-redundant databases, failover groups, and geo-replication. For more information, see SQL Database availability capabilities.
Security
Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.
This solution implements a modern security perimeter to ensure a consistent set of controls (a perimeter) between enterprise assets and the threats to them. You should design perimeters to intercept authentication requests for the resources (identity controls) rather than intercepting network traffic on enterprise networks. The traditional approach isn't feasible for enterprise assets that are outside the network.
Cost optimization
Cost optimization is about reducing unnecessary expenses and improving operational efficiencies. For more information, see Overview of the cost optimization pillar.
Cost optimization and development speed are the main drivers for this implementation of serverless technology for the components of the API. All components in this solution have a consumption pricing tier:
You can use the Azure pricing calculator to model your projected costs. You can validate costs by using Azure Load Testing.
Deploy this scenario
To implement this architecture manually and test it, you need to complete these steps:
- Create Azure functions in Visual Studio Code.
- Create a SQL database and add SQL bindings to the functions.
- Deploy the back-end API, based on Azure Functions, into Azure from Visual Studio Code.
- Create an API Management instance and expose the API back end by using API Management.
- Secure the back-end API via Microsoft Entra ID so that only this API Management identity can access the back-end API.
- Be sure that your API Management instance is assigned to a managed identity.
- Configure your Azure Functions app to use Microsoft Entra sign-in.
- Allow API Management to access the function.
- Allow API Management identity only to access your back end by creating an app role in Microsoft Entra ID for it.
- Limit access to the function to only the users/roles in the app role.
- Add your API Management managed identity to the app role.
- Create two API Management products with two different API key sets:
- Fabrikam Developer for partner developers. This product is exposed via the API Management developer portal, restricted by the corresponding policies.
- Fabrikam Production for the partner IT department.
- Provide improved-security function access to Azure SQL via Azure AD.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
- Genady Belenky | Senior Cloud Solution Architect
Other contributor:
- Mick Alberts | Technical Writer
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
- Embrace proactive security with Zero Trust
- Microsoft Learn: Establish the guiding principles and core components of Zero Trust
- Introduction to Azure Functions
- What is Azure SQL?