Securing application services in Azure

Application design in Azure can use a number of Azure constructs to protect against security threats. Is it possible to summarize much of these in a single picture? Given the scale of security seems unlikely.

Perhaps if we leave out people identities and focus on back-end systems, the task becomes easier. Indeed, there are well established protocols that allow people with a social or corporate identity to be authenticated. This underlying infrastructure is not included here.

Fundamentally, most application to application conversations noways leverage TLS, ideally v1.3 and likely v1.2. Any earlier versions, including SSL, are deemed less unsecure and should not be used.

In a typical distributed system interaction, we have a consumer service and a provider service. Excluding the ubiquitous case where the the customer uses a browser to talk with a web server, the consumer service has its own identity. In this context, the picture below depicts the security elements to be considered when building an Azure solution.

A service that expects a secret response from an Azure resource can register a managed service identity. This is kept in Azure Active Directory which acts as a trusted intermediary. A service provider (e.g. Azure SQL Server, Azure Key Vault) can use its policies against the trusted identity and return the appropriate response. The code of the consumer service does not need to manage credentials anymore and delegates this responsibility to Azure instead.

Next, consumer and provider service can be placed in distinct network security groups (NSGs) within a single Azure virtual network. An NSG defines the incoming and outgoing network traffic rules, thus reducing the attack surface on services exposed to the internet.

The third security barrier comprises a number of Azure offerings that combine protection with load balancing. They further take away from the security concerns, letting the developer focus on system functionality.