In this article, let’s have a look at what all things can be done to secure the data in Azure Cosmos DB.

There is an extensive security checklist published at Azure Cosmos DB documentation. The below sections provide very high level overview of what you can do in Azure to secure the data in Cosmos DB.

Encryption at Rest

Encryption at rest refers to encrypting data on non-volatile devices e.g. SSD or HDD. The primary copy of Cosmos DB is always stored on SSD.

With the release of encryption at rest for Cosmos DB, all your databases, media attachments, and backups are encrypted. Your data is now encrypted in transit (over the network) and at rest (nonvolatile storage), giving you end-to-end encryption.

You do not need any additional settings to turn this encryption on or off. This is by default enabled on Cosmos DB.

Network Security

By default, Azure Cosmos DB is available from all over the internet. But you can configure set of IP addresses which are allowed to access the Cosmos DB resource using IP firewall . You can either allow traffic from only one specific IP address or range of IP addresses.

You can also enable the service endpoint functionality, using which you can allow access only from specific network or v-net.

Secure Access to Data

Azure Cosmos DB provides two ways by which you can secure access to the data – master keys and resource tokens.

Master Keys

Like every Azure resource, Azure Cosmos DB has two master keys, primary key and secondary key. Any one of these two keys can be used to access the Cosmos DB. If you navigate to Cosmos DB resource in Azure Portal, you can find the master keys under “Keys” section, as shown in below snapshot.

As the name suggests, they provide full access to your Cosmos DB account. Hence in real world applications, handing over these keys to different applications should be avoided. Because if it is compromised, then it poses a great risk to your data and Cosmos DB account.

Below code shows how the master key can be used to create a new database. The key and endpoint URI are placed in application configuration file.

string endpointUrl = ConfigurationManager.AppSettings["EndPointUrl"];
string authorizationKey = ConfigurationManager.AppSettings["AuthorizationKey"];

client = new DocumentClient(new Uri(endpointUrl), authorizationKey);

// Create Database
Database database = await client.CreateDatabaseAsync(
    new Database
    {
        Id = databaseName
    });

Although there are two master keys, you should use only one of them at any given point of time. This is because if you have to regenerate the distributed key, then you can regenerate it without any downtime. You can just replace usages of primary key with secondary key and then regenerate primary key.

In addition to regular keys, there are two read only keys. These keys can be used for same purpose, the only difference is you will get readonly access if you use readonly keys.

Resource Tokens

The resource tokens are created when a user is granted permissions on specific resource. Unlike master keys, the resource tokens are granular, and they are created for every user based on their assigned permissions on specific resource (e.g. database, container, user defined functions, stored procedure, etc. )

The resource tokens are time bound and the expiry time can be configured based on need of your application. Also, they are regenerated once the permission reassignment happens.

Below code shows how to add user, assign permission and get the resource token.

//Create a user.
User docUser = new User
{
    Id = "mobileuser"
};

docUser = await client.CreateUserAsync(UriFactory.CreateDatabaseUri("db"), docUser);

// Create a read permission.
Permission docPermission = new Permission
{
    PermissionMode = PermissionMode.Read,
    ResourceLink = UriFactory.CreateDocumentCollectionUri("db", "collection"),
    Id = "readperm"
};
  
docPermission = await client.CreatePermissionAsync(UriFactory.CreateUserUri("db", "user"), docPermission);

Console.WriteLine(docPermission.Id + " has token of: " + docPermission.Token);

Role Based Access Control

Azure Cosmos DB also has in built support for Role Based Access control for common management scenarios.

If you login to Azure portal and navigate to your Cosmos DB account, then under “IAM Control (IAM)” pane, you will be able to configure the role based access control.

The roles are applied to users, groups, service principals, and managed identities in Active Directory. You can use built-in roles or custom roles for individuals and groups.

Advanced Threat Control

This is an additional layer of security intelligence, which detects unusual and potentially harmful attempts to exploit Azure Cosmos DB account.

Even without being a security expert, you can address these threats by just enabling the advanced threat control in your Cosmos DB account as shown in below snapshot.

Security alerts are triggered when anomalies in activity occur.

These security alerts are integrated with Azure Security Center, and are also sent via email to subscription administrators, with details of the suspicious activity and recommendations on how to investigate and remediate the threats.

There are two types of alert:

• Access from unusual location, this alert is triggered when there is change in access pattern of Cosmos DB account. That means, if somebody tries to access Cosmos DB account form an unusual location, then this alert is triggered. It may give false positive in some cases.
• Unusual data extraction, this alert is triggered when a client is trying to extract unusually large amount of data from Cosmos DB account.

I hope this article helps you to know the options to secure your Cosmos DB account. Let me know your thoughts.