How to develop secure applications using Azure Cosmos DB

Before we begin to discuss how to develop secure applications using Azure Cosmos DB, we should also highlight some of the different layers of security that Azure Cosmos DB offers. The following image illustrates these various layers of security:

Azure Cosmos DB is a ring zero Azure service, this means it will be available in any new Azure data center as soon as it goes online and must keep all its compliance certificates current.

The first layer of Azure provides physical safety of data centers and continuous protections from DDoS attacks. Azure has dedicated teams to continuously monitor the security issues. All Azure services run a common security agent to collect anomalous activity. Production resources are patched regularly and all the secrets, certificates, or passwords have a defined lifetime. These certificates or secrets should be rotated after they expire. All the production ports in Azure Cosmos DB are scanned and penetration tested regularly. The source code is scanned for security issues and they require two approvers before integrating into the product. 

Access to Azure is restricted. Operations staff or developers working for Azure Cosmos DB cannot access any production from their machines. All production is accessed via dedicated secure access workstations (SAWs). These workstations are watertight, there is no outside access from these machines unless it is through Azure. Engineers get just in time (JIT) approval for all production access. All access is monitored and every activity of an engineer is monitored by an escort.  All production deployments require multiple approvals including test sign off and approvers.

Azure has a very strict access policy by Microsoft personnel. It is almost impossible for any Microsoft employee to access the production system if he or she is not authorized. I am mentioning these details because customers often ask if their data is secure in Azure and whether Azure Cosmos DB engineering teams can access their data.

Security offered by IP firewall

Using an IP firewall is the first layer of protection to secure your database. Azure Cosmos DB supports policy driven IP-based access controls for inbound firewall support. This model is like the firewall rules of a traditional database system and provides an additional level of security to the Azure Cosmos DB account. With this model, you can now configure an Azure Cosmos DB account to be accessible only from an approved set of machines and/or cloud services. Access to Azure Cosmos DB resources from these approved sets of machines and services still require the caller to present a valid authorization token.

The IP access control policy can be set in the Azure portal, or programmatically through Azure CLI, Azure PowerShell, or the REST API by updating the “ipRangeFilter” property.

Security offered by virtual network

Virtual network is the next layer that secures Azure Cosmos DB accounts. You can configure your Azure Cosmos DB account to allow access only from a specific subnet of Azure Virtual Networks. By enabling a service endpoint for Azure Cosmos DB from a virtual network and its subnet, traffic is ensured an optimal and secure route to Azure Cosmos DB.

Once an Azure Cosmos DB account is configured with a virtual network service endpoint, it can be accessed only from the specified subnet, and the public or Internet access is removed. To learn in detail about service endpoints, refer to the Azure “Virtual Network Service Endpoints” overview article. 

You can filter network traffic to and from Azure resources in an Azure Virtual Network with a network security group. A network security group contains security rules that allow or deny inbound network traffic and outbound network traffic from several types of Azure resources. 

Access control with keys

The security layers discussed so far come as part of Azure Cosmos DB and don’t require much other than configuring the firewall and virtual network. Now, let’s discuss what you can do as an application developer. All access to Azure Cosmos DB is controlled by two keys, a master key and read-only key. Master key, as its name implies is a master key and can do all operations on Azure Cosmos DB. A read-only key enables you to read the data, but no other actions are possible with this key.

Developers may worry about keys, wondering if someone could steal them and access their data. The rest of this post will discuss the architecture you should adopt to build a secure application on Azure Cosmos DB.

Architecture for building a secure application

First, no application should have access keys in the config file or in code. Keys should always be kept in Key Vault. Your application or users can have managed identities registered with Key Vault and they can get the keys at the run time.

Second, application should not try to access the database directly. They should have a middle tier web service to access data. This approach provides the following benefits:

◈ Frontend application can call REST service to get the data. Frontend does not need to understand different API’s of Azure Cosmos DB. Azure Cosmos DB is a multi-model database, data can be kept in different formats, but the frontend applications can be abstracted away from all the details of data access.

◈ Generally you may have many applications, in different formats (PC, phone, and web) which will be accessing the same data. Not all application must repeat the data retrieval logic.

◈ You can provide throttling if needed to any rogue application at the web service layer before they can harm the database.

◈ You can audit at the finer granularity all the access to database.

◈ And then of course, there are different benefits of three tier architecture e.g. abstraction from data layer, opportunity for caching, different teams can work on different layer parallelly, scaling different layers separately, ease of maintenance etc.

Moreover, the biggest benefit is that you only have one service which needs to access keys. As you rotate keys only one service will need to refresh them, rather than hundreds or thousands of clients.

As shown above, you can have an application, which is authenticated by AAD and calls the REST web service. The application shown above can be tens of thousands of instance of a web site. REST API will get the caller identity in the call. Here is an opportunity for this web service to apply some business rules for the call. This web service can consult its custom rules to see which user has permission for which Azure Cosmos DB collection. Once the business rule layer validates the call, Data Service can get the keys from Key-Vault to access the data from Azure Cosmos DB.

If you are following Azure Cosmos DB closely, you may wonder about resource tokens. You should prefer the above architecture rather than implementing a service which can dispense the resource tokens and then a client can use those resource tokens to access Azure Cosmos DB directly.

I will assert having a data service is a better design than letting multiple client apps directly access the database. Resource token is a right solution for any small application, but it has some of its own limitations. Resource token does not work for all the API’s. It works only for SQL API. You still have to create a web service, which will dispense the token as per your business rules, so why don’t that service go one-step ahead and dispense the data itself.

Yes, you are adding a hop for the application, and it may be adding few milliseconds, but this is a better alternative to Resource token.

Azure Cosmos DB keeps all your data encrypted at rest and on wire.  With virtual network, IP Filtering, Key-Vault you can built a very secure application with Azure Cosmos DB.

Continue reading

SQL Database Transparent Data Encryption with Azure Key Vault configuration checklist

Azure SQL Database and Data Warehouse offer encryption-at-rest by providing Transparent Data Encryption (TDE) for all data written to disk, including databases, log files and backups. This protects data in case of unauthorized access to hardware. TDE provides a TDE Protector that is used to encrypt the Database Encryption Key (DEK), which in turn is used to encrypt the data. The TDE protector is by default managed by the service in a fully transparent fashion, rotated every 90 days and maintained in archive for access to backups. Optionally management of the TDE Protector can be assumed by the customer if more control is desired. This requires storing the TDE protector in a customer-owned Azure Key Vault. If this option is chosen, it is important to fully understand all TDE implications and carefully plan for ongoing key management.

Overview of TDE with customer managed keys and Azure Key Vault integration:

In this scenario, customers must maintain Azure Key Vault, control SQL Database permissions to Azure Key Vault and maintain access to all TDE Protectors to open or restore databases or backups and enable all other operations that require database access to the TDE Protector. The following checklist will help to systematically plan all key management related duties in Azure Key Vault. In addition, we list the most important setup considerations and configuration requirements that must be followed to configure TDE with customer managed keys in Azure Key Vault.

General guidelines:

• Ensure Azure Key Vault and Azure SQL Database are going to be in the same tenant. Cross-tenant key vault and server interactions are not supported.
• Decide which subscriptions will be used for the required resources. Moving the server across subscriptions later requires a new setup of TDE with BYOKs.
• When configuring TDE with BYOK, it is important to consider the load placed on the key vault by repeated wrap/unwrap operations. For example, since all databases associated with a logical server use the same TDE protector, a failover of that server will trigger as many key operations against the vault as there are databases in the server. Based on our experience and documented key vault service limits, we recommend associating at most 500 Standard or 200 Premium databases with one Azure Key Vault in a single subscription to ensure consistently high availability when accessing the TDE protector in the vault.
• Recommended: Keep a copy of the TDE protector on premises. This requires a HSM device to create a TDE Protector locally and a key escrow system to store a local copy of the TDE Protector.

Guidelines for configuring Azure Key Vault:

• Use a key vault with soft-delete enabled (required) to protect from data loss in case of accidental key or key vault deletion scenarios:
• Soft deleted resources are retained for 90 days unless they are recovered or purged.
• The recover and purge actions have their own permissions associated in a key vault access policy.
• Grant the SQL server access to the key vault using its Azure Active Directory (Azure AD) Identity. When using the Portal UI, the Azure AD identity will be automatically created and the key vault access permissions will be granted to the server. Using PowerShell, these steps must be completed individually in the correct order and need to be verified. See Configure TDE with BYOK for detailed step-by-step instructions when using PowerShell. Note: The server will lose access to the key vault if the Azure AD Identity is accidentally deleted or the server’s permissions are revoked using the key vault’s access policy.
• Enable auditing and reporting in Azure Key Vault on all encryption keys: Key Vault provides logs that are easy to inject into other security information and event management (SIEM) tools. Operations Management Suite (OMS) Log Analytics is one example of a service that is already integrated.
• To ensure high-availability of encrypted databases, configure one logical server with two Azure Key Vaults in different regions.
• For High Availability of a single SQL database, consider configuring two key vaults:

• Use the Backup-AzureKeyVaultKey cmdlet to retrieve the key in encrypted format and then use the Restore-AzureKeyVaultKey cmdlet and specify a key vault in the second region.
• For Geo-replicated databases, the following AKV configuration is required:

• One primary database with a key vault in region and one secondary database with a key vault in region.
• One secondary is required, up to four secondaries are supported.
• Secondaries of secondaries (chaining) is not supported.
• Note: when assigning the server identity, assign the identity for the secondary first, and for the primary second.

Guidelines for configuring TDE Protectors (asymmetric key) stored in Azure Key Vault:

• Create your encryption key locally on a local HSM device. Ensure this is an asymmetric, RSA 2048 key so it is storable in Azure Key Vault. Larger key sizes are currently not supported by Azure SQL Database.
• Escrow the key in a key escrow system.
• Import the encryption key file (.pfx, .byok, or .backup) to Azure Key Vault.
• (Note: For testing purposes, it is possible to create a key with Azure Key Vault, however this key cannot be escrowed, because the private key can never leave the key vault. A key used to encrypt production data should always be escrowed, as the loss of the key (accidental deletion in key vault, expiration etc.) will result in permanent data loss.)
• Use a key without an expiration date and never set an expiration date on a key already in use: once the key expires, the encrypted databases lose access to their TDE Protector and are dropped within 24 hours.
• Ensure the key is enabled and has permissions to perform get, wrap key, and unwrap key operations.
• Create an Azure Key Vault key backup before using the key in Azure Key Vault for the first time. Learn more about the Backup-AzureKeyVaultKey command.
• Create a new backup whenever any changes are made to the key (for example, add ACLs, add tags, add key attributes).
• Keep previous versions of the key in the key vault when rotating keys, so that databases can still access their virtual log files that continue to be encrypted with the original keys. In addition, when the TDE Protector is changed for a database, old backups of the database are not updated to use the latest TDE Protector. Key rotations can be performed following the instructions at Rotate the Transparent Data Encryption Protector Using PowerShell.
• Keep all previously used keys in Azure Key Vault after changing back to service-managed keys. This will ensure database backups can be restored with the TDE protectors stored in Azure Key Vault. TDE protectors will have to be maintained in Azure Key Vault until all needed backups have been created while using service-managed keys.
• Make recoverable backup copies of these keys using Backup-AzureKeyVaultKey.
• To remove a potentially compromised key during a security incident without the risk of data loss, follow the steps at Remove a potentially compromised key.

Continue reading