Compartir vía

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

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 encuentre este límite. La administración de cientos o miles de asignaciones de roles puede ser difícil. En función de su escenario, puede 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 el control de las 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 principales.

Escenario de ejemplo

Considere una empresa denominada Contoso con miles de clientes que quieren configurar la siguiente configuración:

  • Distribuya los datos de los clientes en 128 cuentas de almacenamiento por motivos de seguridad y rendimiento.
  • Agregue 2000 contenedores a cada cuenta de almacenamiento donde haya un contenedor para cada cliente.
  • Represente a cada cliente mediante un servicio principal único de Microsoft Entra.
  • Permitir que cada cliente acceda a objetos de su contenedor, pero no a otros contenedores.

Esta configuración podría potencialmente requerir 256.000 asignaciones de rol de Propietario de Datos de Storage Blob en una suscripción, lo que supera el límite de asignaciones de rol. Tener estas muchas asignaciones de roles sería difícil, si no imposible, mantener.

Diagrama que muestra miles de asignaciones de roles.

Solución de ejemplo

Una manera de controlar este escenario de forma fácil de mantener 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.

Diagrama que muestra una asignación de roles y una condición.

Esta es la expresión en 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 se puede ajustar solo a 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 posea la clave de acceso. Esto significa que los atacantes pueden acceder a los datos confidenciales si pueden obtener las claves de acceso. Las claves de acceso no tienen enlace de identidad, no tienen una expiración y son un riesgo de seguridad para almacenar.

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 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 significativa para un equipo de DevOps.

RBAC de Azure proporciona un control de acceso específico centralizado. Azure RBAC tiene un enlace de identidad que reduce el riesgo de seguridad. El uso de condiciones puede escalar la administración de asignaciones de roles y facilitar el mantenimiento del control de acceso porque 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 potencialmente mejorar su postura 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:

Paso 2: Identifique los atributos que podría usar en su condición

Hay varios atributos que puede usar en su condición, como los siguientes:

  • Nombre del contenedor
  • Ruta de acceso del blob
  • Etiquetas de blobs de índice [Claves]
  • Etiquetas de índice de blobs [Valores de la 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.

Pasos siguientes

  • Last updated on