Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La autorización es el acto de conceder a una entidad autenticada permiso para realizar una acción. El principio clave de control de acceso es proporcionar a los usuarios solo la cantidad de acceso que necesitan para realizar sus trabajos y permitir solo determinadas acciones en un ámbito determinado. La seguridad basada en roles corresponde al control de acceso. Muchas organizaciones usan la seguridad basada en roles para controlar el acceso en función de roles definidos o funciones de trabajo en lugar de usuarios individuales. A los usuarios se les asigna uno o varios roles de seguridad y a cada rol se le conceden permisos autorizados para realizar tareas específicas.
Microsoft Entra ID es un proveedor de identidades centralizado que concede autorización para acceder a servicios de datos y almacenamiento para cada usuario o para cada aplicación en función de una identidad de Microsoft Entra.
Autorización del servicio de datos
El control de acceso basado en rol (RBAC) y las listas de control de acceso (ACL) de Azure desempeñan roles cruciales para administrar el acceso y garantizar la seguridad. RBAC y ACL de Azure requieren que el usuario o la aplicación tengan una identidad en microsoft Entra ID. En el análisis a escala de la nube, RBAC es eficaz para las bases de datos y Azure Data Lake Storage. Las ACL se usan principalmente en Data Lake Storage para proporcionar un control de acceso específico en los niveles de archivo y directorio. Las ACL complementan RBAC al proporcionar permisos más detallados dentro de la jerarquía de almacenamiento.
Azure RBAC proporciona roles integrados como propietario, colaboradory Lector, pero también puede crear roles personalizados para necesidades específicas. Los siguientes roles integrados son fundamentales para todos los tipos de recursos de Azure, incluidos los servicios de datos de Azure:
| Rol | Descripción |
|---|---|
| Propietario | Este rol tiene acceso total al recurso y puede administrar todo sobre el recurso, incluido el derecho a conceder acceso a él. |
| Colaborador | Este rol puede administrar el recurso, pero no puede concederle acceso. |
| Lector | Este rol puede ver el recurso y la información, excepto la información confidencial, como las claves de acceso o los secretos, sobre el recurso. No pueden realizar ningún cambio en el recurso. |
Nota
Algunos servicios tienen roles de RBAC específicos, como colaborador de datos de Storage Blob o colaborador de Data Factory, por lo que debe usar estos roles para estos servicios. RBAC es un modelo aditivo en el que agregar asignaciones de roles es un permiso activo. RBAC también admite asignaciones de denegación, que tienen prioridad sobre las asignaciones de roles.
Sugerencia
Al planear una estrategia de control de acceso, se recomienda conceder a los usuarios solo la cantidad de acceso que necesitan para realizar sus trabajos. También debe permitir solo determinadas acciones en un ámbito concreto.
Control de acceso en bases de datos de Azure
RBAC en bases de datos de Azure gira en torno a roles, ámbitos y permisos. Azure proporciona varios roles integrados para la administración de bases de datos. Uno de esos roles es Colaborador de SQL Server, que permite la administración de bases de datos y servidores SQL Server. Otro rol es colaborador de base de datos SQL, que permite la administración de bases de datos SQL, pero no del propio servidor. Además, puede crear roles personalizados que tengan permisos específicos para cumplir los requisitos únicos.
Puede asignar roles en distintos ámbitos, entre los que se incluyen:
- En el nivel de suscripción, donde los roles se aplican a todos los recursos de la suscripción.
- En el nivel de grupo de recursos, donde los roles se aplican a todos los recursos del grupo de recursos especificado.
- En el nivel de recurso, donde puede asignar roles directamente a bases de datos o servidores individuales. Este enfoque proporciona un control preciso.
Los permisos definen las acciones que puede realizar un rol, como la administración de la configuración de lectura, escritura, eliminación o seguridad. Estos permisos se agrupan en roles para simplificar la administración.
En Azure SQL Database, puede asignar roles a usuarios, grupos o aplicaciones para controlar el acceso. Por ejemplo, a un administrador de bases de datos se le puede asignar el rol de colaborador de SQL Server para administrar el servidor y las bases de datos. Los roles como colaborador de base de datos SQL permiten a los usuarios crear, actualizar y eliminar bases de datos, mientras que el rol de administrador de seguridad de SQL se centra en las configuraciones de seguridad.
En Azure Cosmos DB, puede asignar roles para administrar el acceso a las cuentas, bases de datos y contenedores de Azure Cosmos DB. Los roles integrados como Lector de Cuentas de Cosmos DB y Colaborador de Cuentas de Cosmos DB proporcionan distintos niveles de acceso.
En Azure Database for MySQL y Azure Database for PostgreSQL, puede asignar roles para administrar servidores de bases de datos y bases de datos individuales. Puede usar roles como colaborador y Lector para controlar el acceso.
Para obtener más información, consulte Roles integrados de Azure para bases de datos.
Control de acceso en Data Lake Storage
Azure RBAC permite conceder acceso genérico específico, como el acceso de lectura o escritura, a todos los datos de la cuenta de almacenamiento. Las ACL permiten conceder acceso específico, como el acceso de escritura a un directorio o archivo específico.
En muchos escenarios, puede usar RBAC y ACL juntos para proporcionar un control de acceso completo en Data Lake Storage. Puede usar RBAC para administrar el acceso de alto nivel a los datos, lo que ayuda a garantizar que solo los usuarios autorizados puedan acceder al servicio. A continuación, puede aplicar ACL dentro de la cuenta de almacenamiento para controlar el acceso a archivos y directorios específicos, lo que mejora la seguridad.
El control de acceso basado en atributos de Azure se basa en RBAC de Azure mediante la adición de condiciones de asignación de roles basadas en atributos en el contexto de acciones específicas. Básicamente, permite refinar las asignaciones de roles de RBAC mediante la adición de condiciones. Por ejemplo, puede conceder acceso de lectura o escritura a todos los objetos de datos de una cuenta de almacenamiento que tengan una etiqueta específica.
Los roles siguientes permiten que una entidad de seguridad acceda a los datos de una cuenta de almacenamiento.
| Rol | Descripción |
|---|---|
| Propietario de datos de blobs de almacenamiento | Este rol proporciona acceso total a los contenedores y datos de Blob Storage. Este acceso permite a la entidad de seguridad establecer el propietario de un elemento y modificar las ACL de todos los elementos. |
| Colaborador de datos de blobs de almacenamiento | Este rol proporciona acceso de lectura, escritura y eliminación a blobs y contenedores de Blob Storage. Este acceso no permite que la entidad de seguridad establezca la propiedad de un elemento, pero puede modificar la ACL de los elementos que posee la entidad de seguridad. |
| Lector de datos de blobs de almacenamiento | Este rol puede leer y enumerar contenedores y blobs de Blob Storage. |
Roles como Propietario, Colaborador, Lectory Colaborador de la cuenta de almacenamiento permiten que una entidad de seguridad administre una cuenta de almacenamiento, pero no proporcionan acceso a los datos de esa cuenta. Sin embargo, estos roles, excepto Lector, pueden obtener acceso a las claves de almacenamiento, que se pueden usar en varias herramientas de cliente para acceder a los datos. Para más información, consulte Modelo de control de acceso en Data Lake Storage.
Control de acceso en Azure Databricks
Azure Databricks proporciona sistemas de control de acceso para administrar el acceso en el entorno de Azure Databricks. Estos sistemas se centran en objetos protegibles y gobernanza de datos. Los tres sistemas de control de acceso principales dentro de Azure Databricks son:
- ACL, que puede usar para configurar el permiso para acceder a objetos del área de trabajo, como cuadernos. Para obtener más información, consulte Introducción al control de acceso.
- RBAC de cuenta, que puede usar para configurar el permiso para usar objetos de nivel de cuenta, como entidades de servicio y grupos.
- Unity Catalog, que puede utilizar para proteger y controlar los objetos de datos.
Además del control de acceso en objetos, Azure Databricks proporciona roles integrados en la plataforma. Puede asignar roles a usuarios, entidades de servicio y grupos. Para obtener más información, consulte Roles de administrador y derechos de área de trabajo.
Procedimientos recomendados para la autorización en el análisis a escala de la nube
En esta guía se describen los procedimientos recomendados para implementar RBAC en entornos de análisis a escala en la nube. Incluye principios generales de RBAC, control de acceso a bases de datos y procedimientos recomendados de control de acceso del lago de datos para ayudar a garantizar una administración segura y eficaz de los recursos.
Procedimientos recomendados generales de RBAC para el análisis a escala de la nube
Los siguientes procedimientos recomendados pueden ayudarle a empezar a trabajar con RBAC:
Use roles RBAC para la administración de servicios y operaciones, y use roles específicos del servicio para el acceso a datos y tareas específicas de la carga de trabajo. Usa roles de RBAC en recursos de Azure para conceder permiso a las entidades de seguridad que necesitan gestionar y operar recursos. Las entidades de seguridad que necesitan acceder a los datos dentro del almacenamiento no requieren un rol RBAC en el recurso porque no necesitan administrarlos. En su lugar, conceda permiso directamente a objetos de datos. Por ejemplo, conceda acceso de lectura a una carpeta en Data Lake Storage, o conceda permisos de usuario tabla de base de datos contenida en una base de datos en SQL Database.
Use de roles de RBAC integrados. En primer lugar, use los roles de recursos de Azure RBAC integrados para administrar los servicios y asignar roles de operaciones para controlar el acceso. Cree y use roles personalizados para los recursos de Azure solo cuando los roles integrados no satisfagan sus necesidades específicas.
Use grupos para administrar el acceso. Asigne acceso a grupos de Microsoft Entra y administre las pertenencias a grupos para la administración continua del acceso.
Considere los ámbitos de suscripción y grupo de recursos. En entornos que no son de producción, conceda acceso en el ámbito del grupo de recursos para separar las necesidades de acceso de operaciones y administración de servicios en lugar de conceder acceso a recursos individuales. Este enfoque tiene sentido porque, en entornos que no son de producción, los desarrolladores y evaluadores necesitan administrar recursos. Por ejemplo, es posible que necesiten crear una canalización de ingesta de Azure Data Factory o un contenedor en Data Lake Storage.
Sin embargo, en entornos de producción, puede conceder acceso a recursos individuales para tareas específicas de la carga de trabajo, como la compatibilidad y las operaciones del sistema de archivos de Data Lake. Este enfoque tiene sentido en entornos de producción porque los usuarios solo necesitan usar recursos como ver el estado de una canalización de ingesta programada de Data Factory o leer archivos de datos en Data Lake Storage.
No conceda acceso innecesario en el ámbito de la suscripción. El ámbito de la suscripción abarca todos los recursos de la suscripción.
Opte por el acceso con privilegios mínimos. Seleccione el único y correcto rol para el trabajo.
Procedimientos recomendados de control de acceso a bases de datos
La implementación de RBAC eficaz es fundamental para mantener la seguridad y la capacidad de administración en su entorno de análisis. En esta sección se proporcionan procedimientos recomendados para usar grupos de Microsoft Entra y roles integrados y para evitar permisos directos de usuario para ayudar a garantizar un proceso de administración de acceso simplificado y seguro.
Los entornos de análisis a escala en la nube suelen contener varios tipos de soluciones de almacenamiento, como PostgreSQL, MySQL, SQL Database e Instancia administrada de Azure SQL.
Use grupos de Microsoft Entra en lugar de cuentas de usuario individuales. Se recomienda usar grupos de Microsoft Entra para proteger objetos de base de datos en lugar de cuentas de usuario individuales de Microsoft Entra. Use grupos de Microsoft Entra para autenticar a los usuarios y proteger los objetos de base de datos. Puede usar la incorporación de aplicaciones de datos para crear estos grupos, de manera similar al patrón de lago de datos.
Usa roles predeterminados para administrar el acceso. Cree roles personalizados solo si necesita cumplir requisitos específicos o si los roles integrados conceden demasiados permisos.
Evite asignar permisos a usuarios individuales. En cambio, use de forma coherente roles como los de base de datos o de servidor. Los roles ayudan en gran medida a los informes y a la solución de problemas. RBAC de Azure solo admite la asignación de permisos a través de roles.
Procedimientos recomendados de control de acceso de Data Lake Storage
En entornos de datos modernos, el control de acceso seguro y eficaz es fundamental. Data Lake Storage proporciona mecanismos sólidos para administrar el acceso a través de ACL. En esta sección se describen los procedimientos recomendados para implementar RBAC en Data Lake Storage y aplicar ACL, grupos de seguridad de Microsoft Entra y el principio de privilegios mínimos para mantener un entorno de lago de datos más seguro y administrable. Además, resalta la importancia de alinear las ACL con esquemas de partición de datos y usar unity Catalog para usuarios de Azure Databricks para ayudar a garantizar una seguridad y gobernanza integrales.
Use ACL para el control de acceso específico. Las ACL desempeñan un papel importante en la definición del acceso en un nivel granular. En Data Lake Storage, las ACL funcionan con entidades de seguridad para administrar el acceso específico a los archivos y directorios.
Aplique ACL en los niveles de archivo y carpeta. Para controlar el acceso a los datos del lago de datos, se recomienda usar ACL en el nivel de archivos y carpetas. Data Lake Storage también adopta un modelo de ACL similar a la interfaz de sistema operativo portátil (POSIX). POSIX es un grupo de estándares para sistemas operativos. Un estándar define una estructura de permisos sencilla pero eficaz para acceder a archivos y carpetas. POSIX se usa ampliamente para recursos compartidos de archivos de red y equipos Unix.
Use grupos de seguridad de Microsoft Entra como entidad de seguridad asignada a una entrada ACL. En lugar de asignar directamente usuarios individuales o entidades de servicio, use este enfoque para agregar y quitar usuarios o entidades de servicio sin necesidad de volver a aplicar las ACL a toda una estructura de directorios. Puede agregar o quitar usuarios y entidades de servicio del grupo de seguridad de Microsoft Entra adecuado.
Asigne acceso a los grupos de Microsoft Entra y administre la pertenencia de grupos para la administración continua del acceso. Para más información, consulte Modelo de control de acceso en Data Lake Storage.
Aplique el principio de privilegios mínimos a las ACL. En la mayoría de los casos, los usuarios solo deberían tener permiso de lectura en las carpetas y los archivos que necesiten en el lago de datos. Los usuarios de datos no deben tener acceso al contenedor de la cuenta de almacenamiento.
Alinee las ACL con esquemas de partición de datos. Las ACL y el diseño de particiones de datos deben alinearse para ayudar a garantizar un control eficaz de acceso a los datos. Para obtener más información, consulte la sección del documento sobre la creación de particiones de lago de datos.
Para los usuarios de Azure Databricks, controle exclusivamente el acceso a objetos de datos con Unity Catalog. Conceder acceso directo de nivel de almacenamiento al almacenamiento externo en Data Lake Storage no respeta los permisos concedidos ni las auditorías mantenidas por Unity Catalog. El acceso directo omite las características de auditoría, linaje y otras características de seguridad y supervisión del catálogo de Unity, incluido el control de acceso y los permisos. Por lo tanto, no debe conceder a los usuarios de Azure Databricks acceso directo a nivel de almacenamiento a tablas y volúmenes administrados de Unity Catalog.