Skip to content

Latest commit

 

History

History
181 lines (123 loc) · 11.9 KB

secure-access-to-data.md

File metadata and controls

181 lines (123 loc) · 11.9 KB
title description author ms.author ms.service ms.topic ms.date ms.custom
Learn how to secure access to data in Azure Cosmos DB
Learn about access control concepts in Azure Cosmos DB, including primary keys, read-only keys, users, and permissions.
thomasweiss
thweiss
cosmos-db
conceptual
01/21/2020
devx-track-csharp

Secure access to data in Azure Cosmos DB

This article provides an overview of securing access to data stored in Microsoft Azure Cosmos DB.

Azure Cosmos DB uses two types of keys to authenticate users and provide access to its data and resources.

Key type Resources
Primary keys Used for administrative resources: database accounts, databases, users, and permissions
Resource tokens Used for application resources: containers, documents, attachments, stored procedures, triggers, and UDFs

Primary keys

Primary keys provide access to all the administrative resources for the database account. Primary keys:

  • Provide access to accounts, databases, users, and permissions.
  • Cannot be used to provide granular access to containers and documents.
  • Are created during the creation of an account.
  • Can be regenerated at any time.

Each account consists of two primary keys: a primary key and secondary key. The purpose of dual keys is so that you can regenerate, or roll keys, providing continuous access to your account and data.

In addition to the two primary keys for the Cosmos DB account, there are two read-only keys. These read-only keys only allow read operations on the account. Read-only keys do not provide access to read permissions resources.

Primary, secondary, read only, and read-write primary keys can be retrieved and regenerated using the Azure portal. For instructions, see View, copy, and regenerate access keys.

:::image type="content" source="./media/secure-access-to-data/nosql-database-security-master-key-portal.png" alt-text="Access control (IAM) in the Azure portal - demonstrating NoSQL database security":::

Key rotation

The process of rotating your primary key is simple.

  1. Navigate to the Azure portal to retrieve your secondary key.
  2. Replace your primary key with your secondary key in your application. Make sure that all the Cosmos DB clients across all the deployments are promptly restarted and will start using the updated key.
  3. Rotate the primary key in the Azure portal.
  4. Validate the new primary key works against all resource. Key rotation process can take any where from less than a minute to hours depending on the size of the Cosmos DB account.
  5. Replace the secondary key with the new primary key.

:::image type="content" source="./media/secure-access-to-data/nosql-database-security-master-key-rotate-workflow.png" alt-text="Primary key rotation in the Azure portal - demonstrating NoSQL database security" border="false":::

Code sample to use a primary key

The following code sample illustrates how to use a Cosmos DB account endpoint and primary key to instantiate a DocumentClient and create a database:

//Read the Azure Cosmos DB endpointUrl and authorization keys from config.
//These values are available from the Azure portal on the Azure Cosmos DB account blade under "Keys".
//Keep these values in a safe and secure location. Together they provide Administrative access to your Azure Cosmos DB account.

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

CosmosClient client = new CosmosClient(endpointUrl, authorizationKey);

The following code sample illustrates how to use the Azure Cosmos DB account endpoint and primary key to instantiate a CosmosClient object:

:::code language="python" source="~/cosmosdb-python-sdk/sdk/cosmos/azure-cosmos/samples/access_cosmos_with_resource_token.py" id="configureConnectivity":::

Resource tokens

Resource tokens provide access to the application resources within a database. Resource tokens:

  • Provide access to specific containers, partition keys, documents, attachments, stored procedures, triggers, and UDFs.
  • Are created when a user is granted permissions to a specific resource.
  • Are recreated when a permission resource is acted upon on by POST, GET, or PUT call.
  • Use a hash resource token specifically constructed for the user, resource, and permission.
  • Are time bound with a customizable validity period. The default valid time span is one hour. Token lifetime, however, may be explicitly specified, up to a maximum of five hours.
  • Provide a safe alternative to giving out the primary key.
  • Enable clients to read, write, and delete resources in the Cosmos DB account according to the permissions they've been granted.

You can use a resource token (by creating Cosmos DB users and permissions) when you want to provide access to resources in your Cosmos DB account to a client that cannot be trusted with the primary key.

Cosmos DB resource tokens provide a safe alternative that enables clients to read, write, and delete resources in your Cosmos DB account according to the permissions you've granted, and without need for either a primary or read only key.

Here is a typical design pattern whereby resource tokens may be requested, generated, and delivered to clients:

  1. A mid-tier service is set up to serve a mobile application to share user photos.

  2. The mid-tier service possesses the primary key of the Cosmos DB account.

  3. The photo app is installed on end-user mobile devices.

  4. On login, the photo app establishes the identity of the user with the mid-tier service. This mechanism of identity establishment is purely up to the application.

  5. Once the identity is established, the mid-tier service requests permissions based on the identity.

  6. The mid-tier service sends a resource token back to the phone app.

  7. The phone app can continue to use the resource token to directly access Cosmos DB resources with the permissions defined by the resource token and for the interval allowed by the resource token.

  8. When the resource token expires, subsequent requests receive a 401 unauthorized exception. At this point, the phone app re-establishes the identity and requests a new resource token.

    :::image type="content" source="./media/secure-access-to-data/resourcekeyworkflow.png" alt-text="Azure Cosmos DB resource tokens workflow" border="false":::

Resource token generation and management is handled by the native Cosmos DB client libraries; however, if you use REST you must construct the request/authentication headers. For more information on creating authentication headers for REST, see Access Control on Cosmos DB Resources or the source code for our .NET SDK or Node.js SDK.

For an example of a middle tier service used to generate or broker resource tokens, see the ResourceTokenBroker app.

Users

Azure Cosmos DB users are associated with a Cosmos database. Each database can contain zero or more Cosmos DB users. The following code sample shows how to create a Cosmos DB user using the Azure Cosmos DB .NET SDK v3.

//Create a user.
Database database = benchmark.client.GetDatabase("SalesDatabase");

User user = await database.CreateUserAsync("User 1");

Note

Each Cosmos DB user has a ReadAsync() method that can be used to retrieve the list of permissions associated with the user.

Permissions

A permission resource is associated with a user and assigned at the container as well as partition key level. Each user may contain zero or more permissions. A permission resource provides access to a security token that the user needs when trying to access a specific container or data in a specific partition key. There are two available access levels that may be provided by a permission resource:

  • All: The user has full permission on the resource.
  • Read: The user can only read the contents of the resource but cannot perform write, update, or delete operations on the resource.

Note

In order to run stored procedures the user must have the All permission on the container in which the stored procedure will be run.

Code sample to create permission

The following code sample shows how to create a permission resource, read the resource token of the permission resource, and associate the permissions with the user created above.

// Create a permission on a container and specific partition key value
Container container = client.GetContainer("SalesDatabase", "OrdersContainer");
user.CreatePermissionAsync(
    new PermissionProperties(
        id: "permissionUser1Orders",
        permissionMode: PermissionMode.All,
        container: benchmark.container,
        resourcePartitionKey: new PartitionKey("012345")));

Code sample to read permission for user

The following code snippet shows how to retrieve the permission associated with the user created above and instantiate a new CosmosClient on behalf of the user, scoped to a single partition key.

//Read a permission, create user client session.
PermissionProperties permissionProperties = await user.GetPermission("permissionUser1Orders")

CosmosClient client = new CosmosClient(accountEndpoint: "MyEndpoint", authKeyOrResourceToken: permissionProperties.Token);

Add users and assign roles

To add Azure Cosmos DB account reader access to your user account, have a subscription owner perform the following steps in the Azure portal.

  1. Open the Azure portal, and select your Azure Cosmos DB account.
  2. Click the Access control (IAM) tab, and then click + Add role assignment.
  3. In the Add role assignment pane, in the Role box, select Cosmos DB Account Reader Role.
  4. In the Assign access to box, select Azure AD user, group, or application.
  5. Select the user, group, or application in your directory to which you wish to grant access. You can search the directory by display name, email address, or object identifiers. The selected user, group, or application appears in the selected members list.
  6. Click Save.

The entity can now read Azure Cosmos DB resources.

Delete or export user data

Azure Cosmos DB enables you to search, select, modify and delete any personal data located in database or collections. Azure Cosmos DB provides APIs to find and delete personal data however, it’s your responsibility to use the APIs and define logic required to erase the personal data. Each multi-model API (SQL, MongoDB, Gremlin, Cassandra, Table) provides different language SDKs that contain methods to search and delete personal data. You can also enable the time to live (TTL) feature to delete data automatically after a specified period, without incurring any additional cost.

[!INCLUDE GDPR-related guidance]

Next steps