Administración de permisos de usuarios en grupos de SQL sin servidor de Azure Synapse
Para proteger los datos, Azure Storage implementa un modelo de control de acceso que admite el control de acceso basado en roles de Azure (RBAC de Azure) y listas de control de acceso (ACL) como Portable Operating System Interface for Unix (POSIX)
Puede asociar una entidad de seguridad a un nivel de acceso de archivos y directorios. Estas asociaciones se capturan en una lista de control de acceso (ACL) . Cada archivo y directorio de la cuenta de almacenamiento tiene una lista de control de acceso. Cuando una entidad de seguridad intenta realizar una operación en un archivo o directorio, una comprobación de ACL determina si esa entidad de seguridad (usuario, grupo, entidad de servicio o identidad administrada) tiene el nivel de permiso adecuado para llevarla a cabo.
Existen dos tipos de listas de control de acceso:
ACL de acceso
Controlan el acceso a un objeto. Tanto archivos como directorios tienen ACL de acceso.
ACL predeterminadas
Son plantillas de ACL asociadas a un directorio que determinan las ACL de acceso para los elementos secundarios que se crean en ese directorio. Los archivos no tienen ACL predeterminadas.
Tanto las ACL de acceso como las ACL predeterminadas tienen la misma estructura.
Los permisos de un objeto de contenedor son lectura, escritura y ejecución, y se pueden usar en archivos y directorios, como se muestra en la tabla siguiente:
Niveles de permisos
| Permiso | Archivo | Directorio |
|---|---|---|
| Lectura (R) | Puede leer el contenido de un archivo | Requiere permisos de lectura y ejecución para enumerar el contenido del directorio. |
| Escritura (W) | Puede escribir o anexar a un archivo | Requiere permisos de lectura y ejecución para crear elementos secundarios en un directorio. |
| Ejecución (X) | No significa nada en el contexto de Data Lake Storage Gen2 | Se requiere para atravesar los elementos secundarios de un directorio. |
Directrices para configurar las ACL
Use siempre los grupos de seguridad de Microsoft Entra como entidad de seguridad asignada en una entrada de ACL. Ofrece la oportunidad de asignar directamente usuarios individuales o entidades de servicio. Con esta estructura, podrá agregar y quitar usuarios o entidades de servicio sin necesidad de volver a aplicar las ACL en una estructura de directorios completa. En su lugar, puede agregar o quitar usuarios y entidades de servicio del grupo de seguridad de Microsoft Entra adecuado.
Hay muchas maneras de configurar grupos. Por ejemplo, Imagine que tiene un directorio denominado /LogData que contiene los datos de registro generados por su servidor. Azure Data Factory (ADF) ingiere los datos en esa carpeta. Usuarios concretos del equipo de ingeniería de servicios cargarán los registros y administrarán a otros usuarios de esta carpeta y varios clústeres de Databricks de archivos analizarán los registros de esa carpeta.
Para habilitar estas actividades, puede crear un grupo LogsWriter y un grupo LogsReader. Luego, puede asignar permisos como se indica a continuación:
- Agregue el grupo LogsWriter a la lista de control de acceso del directorio /LogData con permisos de rwx.
- Agregue el grupo LogsReader a la lista de control de acceso del directorio /LogData con permisos de r-x.
- Agregue el objeto de entidad de servicio o Managed Service Identity (MSI) para ADF al grupo de LogsWriter.
- Agregue los usuarios del equipo de ingeniería de servicios al grupo LogsWriter.
- Agregue el objeto de entidad de servicio o MSI para Databricks al grupo LogsReader.
Si un usuario del equipo de ingeniería de servicios deja la empresa, puede quitarle del grupo LogsWriter. Si no agregó dicho usuario a un grupo, sino que en su lugar agregó una entrada de ACL dedicada para ese usuario, tendrá que quitar esa entrada del directorio /LogData. También tendría que quitar la entrada de todos los subdirectorios y archivos de toda la jerarquía de directorios del directorio /LogData.
Roles necesarios para los usuarios del grupo de SQL sin servidor
Para los usuarios que necesiten acceso de solo lectura, debe asignar el rol denominado Lector de datos de Storage Blob.
Para los usuarios que necesiten acceso de lectura y escritura, debe asignar el rol denominado Colaborador de datos de Storage Blob. Se necesita acceso de lectura y escritura si el usuario debe tener acceso a CREATE EXTERNAL TABLE AS SELECT (CETAS).
Nota:
Si el usuario tiene un rol de propietario o colaborador, dicho rol no es suficiente. Azure Data Lake Storage Gen2 tiene súper roles que se deben asignar.
Permiso de nivel de base de datos
Para proporcionar un acceso más granular al usuario, debe usar la sintaxis de Transact-SQL para crear inicios de sesión y usuarios.
Para conceder acceso a un usuario a una base de datos única del grupo de SQL sin servidor, siga los pasos de este ejemplo:
Cree LOGIN
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;Cree USER
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];Agregue USER a los miembros del rol especificado
use yourdb -- Use your DB name alter role db_datareader Add member alias -- Type USER name from step 2 -- You can use any Database Role which exists -- (examples: db_owner, db_datareader, db_datawriter) -- Replace alias with alias of the user you would like to give access and domain with the company domain you are using.
Permiso de nivel de servidor
Para conceder acceso total a un usuario a todas las bases de datos del grupo de SQL sin servidor, siga el paso de este ejemplo:
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];