Protección del acceso a los datos de Azure Cosmos DB

SE APLICA A: NoSQL

En este artículo se proporciona información general sobre el control de acceso de Azure Cosmos DB.

Azure Cosmos DB proporciona tres maneras de controlar el acceso a los datos.

Tipo de control de acceso Características
Claves principal o secundaria Secreto compartido que permite cualquier operación de administración o de datos. Se incluye en las variantes de lectura y escritura y de solo lectura.
Control de acceso basado en roles Modelo de permisos específico basado en roles mediante identidades de Azure Active Directory (Azure AD) para la autenticación.
Tokens de recursos Modelo de permisos específico basado en permisos y usuarios nativos de Azure Cosmos DB.

Claves principal o secundaria

Las claves principal o secundaria proporcionan acceso a todos los recursos administrativos de la cuenta de base de datos. Cada cuenta consta de dos claves: una principal y una secundaria. El fin de las claves dobles es que se pueda regenerar, o distribuir claves, lo que proporciona un acceso continuo a su cuenta y datos. Para obtener más información sobre las claves principales o secundarias, vea el artículo Seguridad de bases de datos.

Rotación y regeneración de claves

Nota:

En la sección siguiente se describen los pasos para girar y regenerar claves para la API para NoSQL. Si usa una API diferente, consulte las secciones API para MongoDB, API para Cassandra, API para Gremlin o API para Table.

Si desea supervisar la regeneración y actualizaciones de clave, consulte el artículo sobre cómo supervisar las actualizaciones de clave con métricas y alertas.

El proceso de rotación y regeneración de claves es sencillo. En primer lugar, asegúrese de que la aplicación usa de forma coherente la clave principal o la clave secundaria para acceder a la cuenta de Azure Cosmos DB. Después, siga los pasos que se describen a continuación.

  1. Vaya a la cuenta de Azure Cosmos DB en Azure Portal.

  2. Seleccione Claves en el menú de la izquierda y después Regenerar clave secundaria en los puntos suspensivos situados a la derecha de la clave secundaria.

    Captura de pantalla de Azure Portal en la que se muestra cómo regenerar la clave secundaria.

  3. Compruebe que la nueva clave secundaria funciona de forma coherente con la cuenta de Azure Cosmos DB. La regeneración de claves puede tardar entre un minuto y varias horas, en función del tamaño de la cuenta de Azure Cosmos DB.

  4. Reemplace la clave principal por la clave secundaria en la aplicación.

  5. Vuelva a Azure Portal y desencadene la regeneración de la clave principal.

    Captura de pantalla de Azure Portal en la que se muestra cómo regenerar la clave principal.

Ejemplo de código para usar una clave principal

En el ejemplo de código siguiente se ilustra cómo usar un punto de conexión y la clave principal de la cuenta de Azure Cosmos DB para crear una instancia de CosmosClient:

// 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);

Control de acceso basado en rol

Azure Cosmos DB expone un sistema de control de acceso basado en roles integrado que le permite:

  • Autenticar las solicitudes de datos con una identidad de Azure Active Directory (Azure AD).
  • Autorizar las solicitudes de datos con un modelo de permisos basado en roles específico.

RBAC de Azure Cosmos DB es el método de control de acceso ideal en situaciones en las que:

  • No quiere usar un secreto compartido como la clave principal y prefiere depender de un mecanismo de autenticación basado en tokens.
  • Quiere usar identidades de Azure AD para autenticar las solicitudes.
  • Necesita un modelo de permisos específico para restringir estrechamente qué operaciones de base de datos pueden realizar las identidades.
  • Desea materializar las directivas de control de acceso como "roles" que puede asignar a varias identidades.

Consulte Configuración del control de acceso basado en rol para la cuenta de Azure Cosmos DB para obtener más información sobre RBAC de Azure Cosmos DB.

Para obtener información y código de ejemplo con los que configurar RBAC en Azure Cosmos DB for MongoDB, consulte el artículo Configuración del control de acceso basado en roles para Azure Cosmos DB for MongoDB.

Tokens de recursos

Los tokens de recursos proporcionan acceso a los recursos de la aplicación en una base de datos. Los tokens de recursos:

  • Proporcionan acceso a contenedores, claves de partición, documentos, datos adjuntos, procedimientos almacenados, desencadenadores y UDF concretos.
  • Se crean cuando a un usuario se le conceden permisos para un recurso concreto.
  • Se vuelven a crear cuando una llamada POST, GET o PUT aplica una acción a un recurso de permiso.
  • Usan un token de recurso de hash construido específicamente para el usuario, el recurso y el permiso.
  • Está limitado por un período de validez personalizable. El intervalo de tiempo válido predeterminado es una hora. Sin embargo, la vigencia del token puede especificarse explícitamente, hasta un máximo de 24 horas.
  • Proporcionan una alternativa segura a proporcionar la clave principal.
  • Permiten que los clientes lean, escriban y eliminen recursos de la cuenta de Azure Cosmos DB en función de los permisos que se les haya otorgado.

Si quiere proporcionar acceso a los recursos de su cuenta de Azure Cosmos DB a un cliente que no es de confianza con la clave principal, puede usar un token de recurso (mediante la creación de usuarios y permisos de Azure Cosmos DB).

Los tokens de recurso de Azure Cosmos DB ofrecen una alternativa segura que permite a los clientes leer, escribir y eliminar recursos de la cuenta de Azure Cosmos DB en función de los permisos que se les hayan concedido y sin necesidad de una clave principal o de solo lectura.

Este es un patrón de diseño típico para solicitar, generar y entregar tokens de recursos a los clientes:

  1. Se configura un servicio de nivel intermedio para que una aplicación móvil pueda usarlo para compartir fotos del usuario.

  2. Dicho servicio tiene la clave principal de la cuenta de Azure Cosmos DB.

  3. La aplicación fotográfica se instala en los dispositivos móviles de los usuarios finales.

  4. Al iniciar sesión, dicha aplicación establece la identidad del usuario con el servicio de nivel intermedio. Este mecanismo de establecimiento de identidad depende únicamente de la aplicación.

  5. Una vez establecida la identidad, el servicio de nivel intermedio solicita permisos en función de esta.

  6. El servicio de nivel intermedio reenvía un token de recurso a la aplicación de teléfono.

  7. La aplicación de teléfono puede seguir usando el token de recurso para obtener acceso directo a los recursos de Azure Cosmos DB con los permisos definidos por el token de recurso y para el intervalo permitido por dicho token.

  8. Cuando el token de recurso expira, las solicitudes posteriores reciben un mensaje 401 de excepción no autorizada. En este punto, la aplicación de teléfono restablece la identidad y solicita un nuevo token de recurso.

    Flujo de trabajo de tokens de recursos de Azure Cosmos DB

Las bibliotecas cliente de Azure Cosmos DB nativas controlan la generación y administración de los tokens de recursos; sin embargo, si se usa REST, debe construir los encabezados de solicitud o autenticación. Para más información sobre cómo crear encabezados de autenticación para REST, consulte Control de acceso en recursos de Azure Cosmos DB o el código fuente de nuestros .NET SDK o Node.js SDK.

Para ver un ejemplo de un servicio de nivel intermedio que se usa para generarlo o los tokens de recursos del agente, consulte la aplicación ResourceTokenBroker.

Usuarios

Los usuarios de Azure Cosmos DB están asociados a una base de datos de Azure Cosmos DB. Cada base de datos puede contener cero, o más, usuarios de Azure Cosmos DB. En el siguiente código de ejemplo se muestra cómo crear un usuario de Azure Cosmos DB mediante el SDK de .NET v3 de Azure Cosmos DB.

// Create a user.
Database database = client.GetDatabase("SalesDatabase");
User user = await database.CreateUserAsync("User 1");

Nota

Cada usuario de Azure Cosmos DB tiene un método ReadAsync() que se puede usar para recuperar la lista de permisos asociados al usuario.

Permisos

Un recurso de permiso está asociado a un usuario y se asigna a un recurso específico. Cada usuario puede contener cero o más permisos. Un recurso de permiso proporciona acceso a un token de seguridad que el usuario necesita al intentar acceder a un contenedor específico o a los datos de una clave de partición específica. Hay dos niveles de acceso disponibles que puede proporcionar un recurso de permiso:

  • Todo: el usuario tiene pleno permiso en el recurso.
  • Lectura: el usuario solo puede leer el contenido del recurso, pero no realizar operaciones de escritura, actualización o eliminación en este.

Nota:

Para ejecutar procedimientos almacenados, el usuario debe tener el permiso "Todo" en el contenedor donde se va a ejecutar el procedimiento almacenado.

Si habilita los registros de diagnóstico en solicitudes del plano de datos, se registran las dos propiedades siguientes correspondientes al permiso:

  • resourceTokenPermissionId: esta propiedad indica el identificador del permiso del token de recurso que ha especificado.

  • resourceTokenPermissionMode: esta propiedad indica el modo de permiso que estableció al crear el token de recurso. El modo de permiso puede tener valores como "all" o "read".

Ejemplo de código para crear permisos

El código de ejemplo siguiente muestra cómo crear un recurso de permisos, leer el token de dicho recurso y asociar los permisos al usuario creado anteriormente.

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

Ejemplo de código para los permisos de lectura del usuario

En el siguiente fragmento de código se muestra cómo recuperar el permiso asociado al usuario creado anteriormente y crear una instancia de un nuevo elemento CosmosClient en nombre del usuario, en el ámbito de una única clave de partición.

// Read a permission, create user client session.
Permission permission = await user.GetPermission("permissionUser1Orders").ReadAsync();

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

Diferencias entre RBAC y los tokens de recursos

Asunto RBAC Tokens de recursos
Authentication Con Azure Active Directory (Azure AD) Basado en los usuarios de Azure Cosmos DB nativos
La integración de tokens de recursos con Azure AD requiere trabajo adicional para unir identidades de Azure AD y usuarios de Azure Cosmos DB.
Authorization Basada en roles: las definiciones de roles asignan acciones permitidas y se pueden asignar a varias identidades. Basada en permisos: para cada usuario de Azure Cosmos DB se debe asignar permisos de acceso a datos.
Ámbito del token Un token de Azure AD lleva la identidad del solicitante. Esta identidad se compara con todas las definiciones de roles asignadas para realizar la autorización. Un token de recurso lleva el permiso concedido a un usuario de Azure Cosmos DB específico en un recurso de Azure Cosmos DB específico. Las solicitudes de autorización en diferentes recursos pueden requerir distintos tokens.
Actualización de tokens Los SDK de Azure Cosmos DB actualizan automáticamente el token de Azure AD cuando este expira. No se admite la actualización del token del recurso. Cuando expira un token del recurso, es necesario emitir uno nuevo.

Incorporación de usuarios y asignación de roles

Para agregar acceso de lectura en la cuenta de Azure Cosmos DB a su cuenta de usuario, necesita que un propietario de la suscripción realice los pasos siguientes en Azure Portal.

  1. Vaya a Azure Portal y seleccione su cuenta de Azure Cosmos DB.

  2. Seleccione Access Control (IAM) .

  3. Seleccione Agregar>Agregar asignación de roles para abrir la página Agregar asignación de roles.

  4. Asigne el siguiente rol. Para asignar roles, consulte Asignación de roles de Azure mediante Azure Portal.

    Configuración Valor
    Role Lector de cuentas de Cosmos DB
    Asignar acceso a Usuario, grupo o entidad de servicio
    Miembros El usuario, el grupo o la aplicación en el directorio al que desea conceder acceso.

    Captura de pantalla que muestra la página Agregar asignación de roles en Azure Portal.

La entidad ahora puede leer los recursos de Azure Cosmos DB.

Eliminación o exportación de datos de usuario

Como servicio de base de datos, Azure Cosmos DB le permite buscar, seleccionar, modificar y eliminar los datos que se encuentran en la base de datos o en los contenedores. No obstante, es responsabilidad suya usar las API proporcionadas y definir la lógica necesaria para buscar y borrar datos personales, si es necesario. Cada API multimodelo (SQL, MongoDB, Gremlin, Cassandra, Table) proporciona SDK de diferentes lenguajes que contienen métodos para buscar y eliminar datos basados en predicados personalizados. También puede habilitar la característica período de vida (TTL) para eliminar datos automáticamente después de un período especificado, sin incurrir en ningún costo adicional.

Nota:

Para más información sobre cómo ver o eliminar datos personales, consulte Solicitudes de interesados de datos de Azure para el RGPD. Para más información sobre RGPD, consulte Información sobre los procedimientos recomendados para el cumplimiento del RGPD y la sección RGPD del portal de confianza de servicios.

Pasos siguientes