Escalado de la administración de asignaciones de roles de Azure mediante condiciones y atributos de seguridad personalizados

Artículo
11/15/2023

El control de acceso basado en rol de Azure (RBAC de Azure) tiene un límite de asignaciones de roles por suscripción. Si necesita crear cientos o incluso miles de asignaciones de roles de Azure, es posible que se encuentre con esta limitación. Administrar cientos o miles de asignaciones de roles puede ser difícil. En función de su escenario, es posible que pueda reducir el número de asignaciones de roles y facilitar la administración del acceso.

En este artículo se describe una solución para escalar la administración de asignaciones de roles mediante condiciones de control de acceso basado en atributos (Azure ABAC) de Azure y atributos de seguridad personalizados de Microsoft Entra para entidades de seguridad.

Escenario de ejemplo

Piense en una empresa denominada Contoso con miles de clientes que quiere implementar la configuración siguiente:

Distribución de los datos de los clientes entre 128 cuentas de almacenamiento por motivos de seguridad y rendimiento.
Incorporación de 2000 contenedores a cada cuenta de almacenamiento donde haya un contenedor para cada cliente.
Represente a cada cliente por una entidad de servicio única de Microsoft Entra.
Permiso para que cada cliente acceda a los objetos de su contenedor, pero no a los de otros contenedores

Esta configuración podría requerir hasta 256 000 asignaciones de roles de Propietario de datos de blobs de almacenamiento en una suscripción, lo cual supera ampliamente el límite de asignaciones de roles. Tener tantas asignaciones de roles sería difícil de mantener, si no imposible.

Diagram showing thousands for role assignments.

Solución de ejemplo

Una manera de manejar este escenario de una forma sostenible es usar condiciones de asignación de roles. En el diagrama siguiente se muestra una solución para reducir las 256 000 asignaciones de roles a una sola asignación de roles mediante una condición. La asignación de roles está en un ámbito de grupo de recursos superior y una condición ayuda a controlar el acceso a los contenedores. La condición comprueba si el nombre del contenedor coincide con el atributo de seguridad personalizado de la entidad de servicio del cliente.

Diagram showing one role assignment and a condition.

Esta es la expresión de la condición que hace que esta solución funcione:

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

La condición completa sería similar a la siguiente. La lista de acciones podría ajustarse a solo las acciones que necesita.

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

¿Por qué usar esta solución?

Hay varios mecanismos de control de acceso que puede usar para proporcionar acceso a los recursos del plano de datos.

Las claves de acceso son una manera común de proporcionar acceso a los recursos del plano de datos. Las claves de acceso proporcionan permisos de lectura, escritura y eliminación a quien posee la clave de acceso. Esto significa que los atacantes pueden obtener acceso a los datos confidenciales si logran obtener las claves de acceso. Las claves de acceso no tienen enlace de identidad, no tienen una fecha de expiración y suponen un riesgo de seguridad a la hora de almacenarlas.

Al igual que las claves de acceso, los tokens de firma de acceso compartido (SAS) no tienen enlace de identidad, pero expiran periódicamente. La falta de enlace de identidad representa los mismos riesgos de seguridad que los de las claves de acceso. Debe administrar la expiración para asegurarse de que los clientes no experimentan errores. Los tokens de SAS requieren código adicional para administrar y operar diariamente, y pueden ser una sobrecarga importante para un equipo de DevOps.

RBAC de Azure proporciona control de acceso centralizado específico. RBAC de Azure tiene un enlace de identidad que reduce el riesgo de seguridad. Mediante el uso de condiciones puede escalar potencialmente la administración de asignaciones de roles y facilitar el mantenimiento del control de acceso, ya que el acceso se basa en atributos flexibles y dinámicos.

Estas son algunas de las ventajas de esta solución:

Control de acceso centralizado
Más fácil de mantener
No se basa en claves de acceso ni tokens de SAS
No requiere que administre el acceso en cada objeto
Puede mejorar potencialmente su posición de seguridad

¿Puede usar esta solución?

Si tiene un escenario similar, siga estos pasos para ver si podría usar esta solución.

Paso 1: Determinar si cumple los requisitos previos

Para usar esta solución, debe tener:

Varias asignaciones de roles integradas o personalizadas que tengan acciones de datos de almacenamiento de blobs. Entre estas se incluyen los siguientes roles integrados:

Paso 2: Identificar los atributos que podría usar en la condición

Hay varios atributos que puede usar en su condición como, por ejemplo, estos:

Nombre del contenedor
Ruta del blob
Etiquetas de índice de blobs [claves]
Etiquetas de índice de blobs [Valores en clave]

También puede definir sus propios atributos de seguridad personalizados para usuarios, aplicaciones empresariales e identidades administradas.

Para obtener más información, consulte Formato y sintaxis de la condición de asignación de roles de Azure y ¿Qué son los atributos de seguridad personalizados en Microsoft Entra ID?.

Paso 3: Crear una condición en un ámbito superior

Cree una o varias asignaciones de roles que usen una condición en un ámbito superior para administrar el acceso. Para más información, consulte Incorporación o edición de condiciones de asignación de roles de Azure mediante Azure Portal.

Share via