Glosario de seguridad para Azure Cosmos DB for NoSQL

SE APLICA A: NoSQL

Diagrama de la secuencia de la guía de implementación, incluidas estas ubicaciones, en orden: Información general, Conceptos, Preparación, Control de acceso basado en rol, Red y Referencia. La ubicación "Conceptos" está resaltada actualmente.

En este artículo se incluye un glosario de terminología común que se usa en esta guía de seguridad para Azure Cosmos DB for NoSQL.

Control de acceso basado en roles

El control de acceso basado en roles hace referencia a un método para administrar el acceso a los recursos de Azure. Este método se basa en identidades específicas a las que se asignan roles que administran el nivel de acceso que tienen a uno o varios recursos. El control de acceso basado en roles ofrece un sistema flexible de administración de acceso específico que garantiza que las identidades solo tengan el nivel de acceso con privilegios mínimos que necesitan para cumplir con su tarea.

Para más información, consulte la Información general del control de acceso basado en roles.

Identidad/entidad de seguridad

Las identidades hacen referencia a objetos de Microsoft Entra que representan alguna entidad que podría necesitar un nivel de acceso al sistema. En el contexto de Azure y Microsoft Entra, las identidades podrían hacer referencia a uno de los siguientes tipos de entidades:

	Descripción
Identidades de carga de trabajo	Una identidad de carga de trabajo representa una carga de trabajo de software que tiene que acceder a otros servicios o recursos.
Identidades humanas	Una identidad humana representa un usuario que puede ser nativo del inquilino o que se haya agregado como invitado.
Identidades administradas	Las identidades administradas son recursos individuales en Azure que representan la identidad de un servicio de Azure
Entidades de servicio	Una entidad de servicio es una cuenta de servicio que se puede usar en un número flexible de escenarios de autenticación.
Identidades de dispositivo	Una identidad de dispositivo es un objeto de Microsoft Entra que está asignado a un dispositivo.
Grupos	Los grupos son objetos que se usan para administrar el acceso a una o varias identidades como una única operación.

Para obtener más información, consulte Aspectos básicos de la identidad.

Role

Los roles son las unidades principales de aplicación del acceso y los permisos. Usted asigna un rol a una identidad, y la definición del rol determina qué nivel de acceso puede tener esa identidad. El ámbito de la asignación determina a qué tiene acceso exactamente la identidad.

Azure tiene un gran conjunto de roles integrados que puede usar para conceder acceso a varios recursos. Considere este ejemplo:

	Valor
Rol	CosmosBackupOperator
Definición	Microsoft.DocumentDB/databaseAccounts/backup/action & Microsoft.DocumentDB/databaseAccounts/restore/action
Ámbito	Un grupo de recursos

En este ejemplo, se le asigna el rol CosmosBackupOperator para un grupo de recursos específico. Esta asignación le proporciona acceso para realizar las acciones backup o restore en cualquier cuenta de Azure Cosmos DB dentro de ese grupo de recursos.

Importante

Algunos servicios de Azure, como Azure Cosmos DB, tienen su propia implementación nativa de control de acceso basado en roles que usa diferentes propiedades de Azure Resource Manager, comandos de la CLI de Azure y cmdlets de Azure PowerShell. Los comandos que se usan normalmente para administrar el control de acceso basado en roles no funcionarán con el acceso al plano de datos de Azure Cosmos DB. Algunos de los comandos para el control de acceso basado en roles de Azure pueden funcionar con el acceso al plano de control de Azure Cosmos DB.

Para más información, consulte Roles integrados de Azure.

Definición de roles

Una definición de rol es un objeto JSON que contiene la lista de acciones del plano de control y del plano de datos permitidas y no permitidas. Considere este ejemplo truncado del rol integrado CosmosRestoreOperator:

{
  "roleName": "CosmosRestoreOperator",
  "type": "Microsoft.Authorization/roleDefinitions",
  ...
  "permissions": [
    {
      "actions": [
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/restore/action",
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/*/read",
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  ...
}

En esta definición, una identidad asignada a este rol puede realizar una acción restore. Una vez completada la operación de restauración, la identidad puede leer varios recursos para validar que la restauración finalizó correctamente. Podemos determinar que puede leer estos recursos debido al operador * (comodín) para read.

Para obtener más información, consulte Conceptos de definiciones de roles.

Asignación de roles

Una asignación de roles concede a una identidad acceso a un recurso específico de Azure. Las asignaciones de roles constan de los siguientes componentes:

	Descripción
Principal	A qué identidad se le asigna este rol
Rol	Rol que está asignado a la identidad.
Ámbito	Recurso o grupo de Azure de destino de la asignación
Nombre/descripción	Metadatos que facilitan la administración de asignaciones a escala

Sugerencia

En el control de acceso basado en roles, es posible que vea que los términos identidad y entidad de seguridad se usan de manera indistinta.

Para obtener más información, consulte Conceptos de la asignación de roles.

Acciones

Las acciones definen qué permisos específicos tiene un rol para un recurso de destino. Las acciones son cadenas que normalmente incluyen el tipo de recurso y un nombre descriptivo que detalla los permisos que concede la acción. A continuación aparecen algunos ejemplos habituales:

	Descripción	Plano
Microsoft.DocumentDB/databaseAccounts/listKeys/action	Solo leer claves de cuenta	Plano de control
Microsoft.DocumentDB/databaseAccounts/backup/action	Realizar copias de seguridad.	Plano de control
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace	Reemplazar completamente un elemento existente	Plano de datos
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQuery	Ejecutar una consulta NoSQL	Plano de datos

Las acciones también pueden contener caracteres * (comodín) para que no tenga que detallar manualmente cada permiso secundario específico. Estos son algunos ejemplos de acciones con caracteres comodín:

	Descripción
Microsoft.DocumentDb/databaseAccounts/*	Crear y administrar cuentas de Azure Cosmos DB
Microsoft.DocumentDB/*/read	Leer cualquier contenedor o base de datos

Las acciones se separan en el plano de control y el plano de datos. Debe definir por separado acciones en recursos y acciones del plano de control que pueden influir en los datos. En una definición de roles, las acciones del plano de control usan la propiedad actions y las acciones del plano de datos están dentro de la propiedad dataActions. También puede definir acciones que una identidad no puede realizar mediante las propiedades notActions y notDataActions respectivas.

Nota:

La separación de acciones en el plano de control y el plano de datos es una medida de seguridad para evitar que las acciones comodín de las definiciones de roles heredadas tengan acceso irrestricto e involuntario a los datos.

Para más información, consulte Acciones de control y datos.

Privilegio mínimo

El concepto de "privilegio mínimo" hace referencia a un procedimiento operativo recomendado para asegurar que todos los usuarios solo tengan el nivel mínimo de acceso que necesitan para realizar su tarea o trabajo. Por ejemplo, una aplicación que lee datos de una base de datos solo necesitaría acceso de lectura al almacén de datos. Si esa aplicación tuviera acceso de lectura y escritura al almacén de datos, podrían suceder varias cosas, por ejemplo:

• La aplicación podría destruir datos por error.
• Un usuario no autorizado podría obtener acceso a las credenciales de la aplicación y modificar los datos.

Seguir la práctica de privilegios mínimos garantiza que las posibles vulneraciones de datos tengan un ámbito limitado. Esta práctica maximiza la seguridad operativa, al tiempo que permite a los usuarios seguir siendo eficaces.

Para obtener más información, consulte Rol con privilegios mínimos recomendados por tarea.

Plano de control

El acceso al plano de control hace referencia a la capacidad de administrar recursos para un servicio de Azure sin administrar datos. Por ejemplo, el acceso al plano de control de Azure Cosmos DB podría incluir las capacidades siguiente:

• Leer todos los metadatos de cuentas y recursos
• Leer y regenerar las claves de cuentas y cadenas de conexión
• Hacer copias de seguridad y restauración de cuentas
• Iniciar y hacer el seguimiento de trabajos de transferencia de datos
• Administrar bases de datos y contenedores
• Modificar las propiedades de las cuentas

Importante

En Azure Cosmos DB, se necesita acceso al plano de control para administrar las definiciones y asignaciones nativas del control de acceso basado en roles del plano de datos. Dado que el mecanismo de control de acceso basado en roles del plano de datos de Azure Cosmos DB es nativo, necesitará acceso al plano de control para crear definiciones y asignaciones y almacenarlas como recursos dentro de una cuenta de Azure Cosmos DB.

Plano de datos

El acceso al plano de datos hace referencia a la capacidad de leer y escribir datos dentro de un servicio de Azure sin la capacidad de administrar los recursos de la cuenta. Por ejemplo, el acceso al plano de datos de Azure Cosmos DB podría incluir las capacidades siguiente:

• Leer algunos los metadatos de cuentas y recursos
• Crear, leer, actualizar, revisar y eliminar elementos
• Ejecutar consultas de NoSQL
• Leer de la fuente de cambios de un contenedor
• Ejecutar procedimientos almacenados
• Administrar conflictos en la fuente de conflictos

Autenticación portátil

En el desarrollo, es habitual escribir dos conjuntos de lógica de autenticación distintas para las instancias de desarrollo y producción locales. Con el SDK de Azure, puede escribir la lógica mediante una única técnica y esperar que el código de autenticación funcione sin problemas en desarrollo y producción.

La biblioteca cliente de Azure Identity está disponible en varios lenguajes de programación como parte del SDK de Azure. Con esta biblioteca, puede crear un objeto DefaultAzureCredential que recorra de forma inteligente varias opciones para encontrar la credencial correcta en función del entorno. Estas opciones de autenticación incluyen (en orden):

1. Secreto de cliente o certificado almacenado como variable de entorno
2. Microsoft Entra Workload ID
3. Identidad administrada asignada por el usuario o por el sistema
4. Credenciales de Azure derivadas de la configuración de Visual Studio
5. Credenciales usadas en la extensión de la cuenta de Azure de Visual Studio Code
6. Credenciales actuales de la CLI de Azure
7. Credenciales actuales de Azure PowerShell
8. Credenciales actuales de Azure Developer CLI
9. Una sesión interactiva que inicia el explorador del sistema para iniciar sesión

Cada biblioteca moderna del SDK de Azure admite un constructor para sus respectivos objetos de cliente o clases que aceptan una instancia DefaultAzureCredential o su tipo de base.

Sugerencia

Para que el código de producción sea más fácil de depurar y más predecible, puede elegir usar DefaultAzureCredential durante el desarrollo y cambiar a una credencial más específica, como WorkloadIdentityCredential o ManagedIdentityCredential, una vez que se haya implementado la aplicación. Todas estas clases se basan en la clase TokenCredential que muchos SDK de Azure esperan como parte de su lógica de inicialización de clientes, lo que facilita el intercambio de ida y vuelta.

Identificador único

Cada identidad de Microsoft Entra tiene un identificador único. A veces, verá que se hace referencia a este identificador único como id, objectId o principalId. Al crear asignaciones de roles, necesita el identificador único de la identidad que se va a usar con la asignación.

Ámbito

Al asignar un rol, debe decidir a qué recursos o grupos de Azure conceder acceso. El ámbito de una asignación de roles define el nivel en el que se realiza una asignación.

Por ejemplo:

• El ámbito de un único recursos aplica permisos solo a ese recurso singular
• Un ámbito establecido en el nivel de grupo de recursos aplica los permisos a todos los recursos pertinentes del grupo.
• Los ámbitos en los niveles de grupo de administración o suscripción se aplican a todos los grupos y recursos secundarios.

Al asignar un rol en el control de acceso basado en roles de Azure, es ideal establecer el ámbito de esa asignación para incluir tan pocos recursos como sea necesario para la carga de trabajo. Por ejemplo, puede establecer el ámbito de una asignación en un grupo de recursos. Ese ámbito de grupo de recursos incluye todos los recursos de Azure Cosmos DB dentro del grupo de recursos:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>

Como alternativa, puede establecer el ámbito en un único recurso de Azure y hacer que la asignación de permisos sea más granular y estrecha. En este ejemplo, el proveedor y el nombre del recurso de Azure Cosmos DB se usan para restringir el ámbito:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>

Para más información, consulte ámbito de control de acceso basado en rol de Azure.

Ámbito (nativo de Azure Cosmos DB)

En la implementación nativa de Azure Cosmos DB del control de acceso basado en rol, el ámbito hace referencia a la granularidad de los recursos dentro de una cuenta para la que desea aplicar el permiso.

En el nivel más alto, puede definir el ámbito de una asignación de control de acceso basado en rol del plano de datos a toda la cuenta mediante el ámbito más grande. Este ámbito incluye todas las bases de datos y contenedores dentro de la cuenta:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/

O bien, puede definir el ámbito de la asignación de roles del plano de datos a una base de datos específica:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>

Por último, puede definir el ámbito de la asignación a un único contenedor, el ámbito más granular:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>/colls/<container-name>

Paso siguiente

Obtención de la identidad de la cuenta conectada