appservice-landing-zone-accelerator

Multitenant App Service Secure Baseline

This reference architecture shows how to run a web-app workload on Azure App Services in a secure configuration. This secure baseline follow Defence in Depth approach to protect AppService workload against cloud vulnerabilities along with additional Well-Architected Framework pillars to enable a resilient solution.

Architecture

Core architecture components

• The application’s users are authenticated by Azure Active Directory (Azure AD) or Azure AD B2C. The browser performs DNS lookups to resolve addresses to Azure Front Door.
• Virtual Network enables Azure resources to securely communicate with each other, the internet, and on-premises networks by creating boundaries, isolation and segmentation of your workloads in the cloud, much like a physical network.
• Network Security Group is a set of security policies that Allow or Deny Inbound/Outbound traffic (Protocols/Ports).
• Azure Front Door is a public front-end for all internet requests, acting as a global HTTP reverse proxy and cache in front of several Azure services. Front Door also provides automatic protection from layer 3 and 4 DDoS attacks, and a range of other features including WAF (web application firewall), caching, and custom rules to enhance the security and performance of your application.
• Azure App Service (Premium) hosts the front-end API applications that are called by the app. Deployment slots are used to provide zero-downtime releases.
• App Services use Virtual Network (VNet) Integration to connect to backend Azure services over a private VNet.
• Azure Cache for Redis provides a high-performance distributed cache for output, session, and general-purpose caching.
• Azure SQL DB provides a fully managed relational database service for back-end application services.
• Private Endpoints allow connections to Azure services from private VNets, and allow the public endpoints on these services to be disabled.
• Azure private DNS automatically configures and updates the DNS records required by private endpoint services.
• Azure Key Vault securely stores secrets and certificates to be accessed by Azure services.
• Azure Monitor and Application Insights collect service logs and application performance metrics for observability.

Networking

Network design topology is based on Hub and Spoke that allows to govern, secure and route traffic in a granular mode.

Private endpoints are used throughout this architecture to improve security. While private endpoints don’t directly improve, or reduce, the availability of this solution, they allow important security principles to be applied. For more information about security design principles, see Azure well architected framework - Security pillar.

Network segmentation boundaries are established along public and private lines. Azure Front Door and Azure App Service are designed to operate on the public internet. These services have their public endpoints enabled. However, App Service has access restrictions in place to ensure that only traffic allowed by Front Door WAF (Web Application Firewall) is allowed to ingress into the App Service.

Azure services that don’t require access from the public internet have private endpoints enabled and public endpoints disabled. The Azure data services SQL DB, SQL DB and Azure Cache for Redis all have public endpoints disabled. Each private endpoint is deployed into one subnet that is dedicate to integrated private link services. Azure service firewalls are used to only allow traffic from other authorized Azure services. Private DNS zones are linked to each private endpoint, via private DNS zone groups and virtual network links, to ensure that private link DNS records are automatically created and updated.

For network and subnet topology details, see the Azure sample template for this architecture.

Alternatives

• Either Azure AD or Azure AD B2C can be used as an identity provider in this scenario. Azure AD is designed for internal applications and business-to-business (B2B) scenarios, while Azure AD B2C is designed for business-to-consumer (B2C) scenarios.
• You can choose to bring your own DNS provider or use Azure-managed DNS, which is recommended.
• Azure Application Gateway can be used solely instead of Azure Front Door when most users are located close to the Azure region that hosts your workload, and when content caching isn’t required. Azure DDoS Network Protection is recommended for protecting internet-facing Application Gateway services.

Scenario details

The scenario describes a secure baseline that allows you to have a protect environment and a good starting point for designing your solution. Defence in depth is a security strategy that involves implementing multiple layers of defence at different points within a network or system. The idea is that if one layer of defence is breached, the next layer will be able to prevent an attacker from gaining access to sensitive information or critical systems. This approach is a key point that drives the architecture decisions ->

• Use isolated network layers for the different components.
• Use protected AD based access via Managed Identity (where possible).
• Use private endpoints for Azure services.
• Use Network Security Groups to control inbound and outbound traffic in the subnet level.
• Enable Standard DDoS Protection for the SPOKE VNET.

Potential use cases

• Public website hosting
• Intranet portal
• Mobile app hosting
• E-commerce
• Media streaming
• Machine learning workloads

Recommendations

• Private endpoints are mostly available on Premium Azure service SKUs. Private endpoints incur hourly and bandwidth (data) charges. For more information, see Private Link pricing.
• Govern your access and follow Role Based Access Control to have a fine-grained access management to Azure resources.
• Review your data classification and determine the protection level you have to enforce in terms of Encryption, Protection, Access and Detection.

Front Door

Azure Front Door is a global service, always available across all Azure geographies and resilient to zone-wide outages and region-wide outages.

• Use Azure managed certificates on all front ends to prevent certificate mis-configuration and expiration issues.
• Enable caching on routes where appropriate to improve availability. Front Door’s cache distributes your content to the Azure PoP (point of presence) edge nodes. In addition to improving your performance, caching reduces the load on your origin servers.
• Deploy Azure Front Door Premium and configure a WAF policy with a Microsoft-managed ruleset. Apply the policy to all custom domains. Use Prevention mode to mitigate web attacks that might cause an origin service to become unavailable.
• Deployments with higher security requirements could also use Private Link in Azure Front Door Premium to secure connectivity to Azure App Service. For more recommendations and information, see Best practices for Front Door.

  App Service

• Access restrictions on Azure App Service should be configured to only allow Front Door traffic. Access restrictions ensure that requests aren’t able to bypass the Azure Front Door WAF, see App Service access restrictions.
• All service-to-service communication in Azure is TLS (transport layer security) encrypted by default. Azure Front Door and Azure App Services should be configured to accept HTTPS traffic only, and the minimum TLS version set.
• Managed identities are used for authenticating Azure service-to-service communication, where available. For more information about managed identities, see What are managed identities for Azure resources?

Check out Defender for App Service for secure and detect operations to protect your Azure App Service web apps and APIs.

SQL Database

• Get to know the risks and Common SQL threats and plan how to Protect.
• Define your encryption policy - you either use a Microsoft managed key or BYOK.
• Verify your needs to protect and detect any malfunction activity within your environment
• Check out Defender for Azure SQL to improve your vulnerabilities assessment and threat protection processes.

For more recommendations and information, see Azure SQL Security Baseline

Cache for Redis

• Set the publicNetworkAccess flag to Disabled to disable the public endpoint.
• To connect to a clustered cache, there can only be one private endpoint connection.

For more recommendations and information, see Azure Redis Cache Security Baseline

Deploy this scenario

Deploy this reference architecture using this Azure sample on GitHub.

• Azure AD, Azure AD B2C, and Azure DNS aren’t deployed by this sample.
• Custom domain names and TLS/SSL certificates aren’t created and configured. Default frontend DNS names are used instead.
• The scripts are modular so you if you already have an existing environment, you can pick and choose the relevant section or adjust the relevant pieces according to your needs (deploy only SPOKE, replace SQL DB with PostgreSQL and etc.).

Considerations for Azure Government cloud

Azure Front Door Premium is not available in Azure Government cloud. The reference implementation will deploy an Azure Application Gateway instead.

Next

Pick one of the IaC options below and follow the instructions to deploy the App Service reference implementation.

:arrow_forward: Terraform

:arrow_forward: Bicep

This site is open source. Improve this page.