Azure Key Management Best Practices

From cryptographic access keys to identity-based access control

Published in

Geek Culture

7 min readMar 23, 2021

Overview

As we move towards a cloud-based architecture more and more applications and services need access to cloud resources. Typically such access is authenticated with an access key or a connection string. That introduces the challenge of key management in a modern cloud environment. This page introduces the principles and technologies involved in securing access to cloud resources from the authentication & authorization perspective. Networking is another important aspect of secure access but it is not the scope of this page.

https://brightlineit.com/understanding-encryption-key-management-businesses/

The problem

Services typically do not have a user interface and thus use different access control mechanisms when accessing backend resources. The legacy approach is to have some sort of secret key to secure the access. The key is embedded in a connection string or used to sign requests. Access is given to anyone who knows the key. This approach is simple and therefore popular yet it has two major weaknesses. First, the resource provider can validate the key before allowing access to the resource but it cannot know who is the caller to which access is granted, because the key is not associated with any identity. Second, such keys tend to be distributed across all the stakeholders who need access, and from there it’s easy to lose track and control. Keys are typically written to files that are persisted in source control and from there it’s a short way to unsecured storage or even to be sent over unsecured channels such as mail and instant messaging. A scenario of a key that finds its way to malicious hands, is often difficult to identify and fix.

From key to identity

The problem of key management is probably one of the most common problems all modern applications face. To solve the problem modern applications replace cryptographic keys with identities leveraging recent progress in Identity management standards and technologies. OAuth 2.0 and OpenId Connect 1.0 standards are the foundation of the technologies that enable us to give identities to applications, similar to identities given to human users. Using identities instead of keys has several advantages. First, with identity-based access control, every request can be identified and audited so that administrators know who sent the request. Second, the scope of identity is limited by design so revoking access to a specific identity is much simpler than revoking a key. Third, with services and users share the same access control mechanism we can reuse Role Base Access Control (RBAC) for authorizing all access to all resources no matter who the client is — human or machine.

Identities in Azure

Azure fully adopted the transition from keys to identities. Today almost all Azure resources support RBAC natively in their API, SDK, and portal interfaces. This is possible by two major Azure components. Azure Active Directory, and Managed Identities.
Azure Active Directory (AAD) is Microsoft’s cloud-based identity and access management service that is responsible for all identity aspects of Azure as well as other Microsoft services and countless independent applications.
Managed identity are automatic principals assigned to Azure resources such as Azure Functions or Virtual machine. Managed Identities eliminate the need for developers having to manage credentials by providing an identity for the Azure resource in Azure AD and using it to obtain access tokens. There are two types of managed identities:

System-assigned. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, an identity is created in Azure AD that is tied to the lifecycle of that service instance. So when the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
User-assigned. You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it.

If managed identities are not possible, Application and Service Principal almost always can be used as an alternative. Unlike managed identities, Application and Service Principal do have credentials (e.g App id, and App secret) that are created on application registration. With those, your code can be executed in the security context of the service principal, and in that context, it is able to access resources based on the role assignments given to the principal. Application Identities complement user identities. When relevant (usually in the UI layer) you will authenticate the user by implementing the OAuth 2.0 authorization or implicit flows and run within the security context of the user, but on the service layer, you will probably want to use a managed identity or an Application and Service Principal.

Identity-Based Access Flow.

In an Identity-Based Access, your code authenticates to AAD and requests an access token for specific access to a certain resource (e.g, Azure Storage). If your code has a Managed Identity no credentials are required. If a Service Principal is used your code will have to present the App id, and App secret. If a role assignment that allows the principal such access to the resource, was created, AAD will issue a token. This token is a short-lived JWT token that can be used only to access that particular resource. You can view the content of a JWT token by using utilities such as JWT.ms. Once the code has the token it can use it to access the resource by placing it in the Authorization header of request (i.e. Authorization: bearer {token}). Almost all current Azure SDKs implement this pattern and support AAD authentication out of the box. You can always add code to your application that authenticates a security principal and acquire an OAuth 2.0 (JWT) token. To authenticate and acquire the token, you can use either one of the Microsoft identity platform authentication libraries or another open-source library that supports OpenID Connect 1.0. Your application can then use the access token to authorize a request against Azure resource

Access Key as a Fallback

There might be scenarios where it will not be possible to use Identity-Based access, such as a scenario where your application requires access to a legacy database that only supports keys embedded in a connection string. In those situations, you will need to use the good old access keys, but it does not mean that the key has to be stored in an unsecured configuration file. Azure has a key vault service that is designed exactly for those situations. Azure Key Vault is a cloud service that provides a secure store for secrets. You can securely store keys, passwords, certificates, and other secrets. Instead of hard coding sensitive information such as connection strings in your application configuration files, you will store it in the vault as a secret and reference it by name. Azure Key Vault does support identity-Based access so your code can authenticate with its Application or Managed identity, obtain access to the vault, request the secret by name, read the secret value and use it. (e.g. to establish a connection to the legacy database.)

Keys Rotation

Keys rotation is always a good practice, but it must be done right. If you rotate a key and then manually update each and every application that uses it, you will quickly face a nightmare and break your code. Azure Key Vault is a great place not only to protect your keys and secrets but also to manage keys’ lifetime and act as a central repository for your keys so once rotated a single update is required. The following tutorial explains the key rotation automation flow in detail.

Threat Analysis

Keys are a major element in your Application Security implementation both for access control and cryptographic operation. Different threats might exist depending on the key management strategy we implement. For example, if there is a situation where there is no other choice but to store keys in the application configuration, then the threat of key theft becomes real. As part of the Security Development Lifecycle (SDL) we execute the process of threat modeling in which we identify threats and assess the risk involved. It is important to document the threats specifically related to key management and find mitigations to lower the risk as much as possible.

Mitigation Example

A common mitigation strategy is to reduce the attack vector. For example, AzureWebJobsStorage is an Azure Function configuration setting that contains the connection string for an Azure storage account. It is required when using triggers other than HTTP and does not support Identity based access. This is an example where we need to include an access key in the configuration. To mitigate the risk, we segregate operational data from business data by creating a separate storage account that will be dedicated to Azure function operational temporary data. Our business data will be stored in another storage account / data-lake and the access to it will be identity-based.

Another common pattern is the parking lot pattern. Applications that have a lower level of security (e.g. they contain access key in configuration) are allowed to write only to a staging storage account. They do not have access to the business data lake. In the staging account (i.e. lower level of trust) we create a parking lot area per application to which the application can push data. Another service will monitor the parking lot (blob trigger) and validate each incoming file. Files that pass validation will be copied to the trusted business data lake, and then will be removed from the parking lot.

Conclusions

Use identity-based access control instead of cryptographic keys as much as possible.
Store keys and secrets in managed key vault service. Control permissions with an RBAC access model.
Rotate keys and other secrets frequently. Replace secrets at the end of their lifetime or if they have been compromised.
Document the threats involved with your key management strategy.

Final note: To be able to continue and publish new stories Medium now requires writers to have a minimum number of followers, so please help me continue to publish and press the ‘follow’ button next to my name.