Administración de identidades y acceso
En este artículo se examinan las consideraciones de diseño y las recomendaciones relacionadas con la administración de identidades y acceso. Se centra en la implementación de una plataforma de análisis a escala de nube en Microsoft Azure. Dado que el análisis a escala de nube es un elemento crítico, la orientación sobre las áreas de diseño de la zona de aterrizaje también debe incluirse en su diseño.
Este artículo se basa en consideraciones y recomendaciones sobre las zonas de aterrizaje de Azure. Para obtener más información, consulte Consideraciones sobre la administración de identidades y acceso.
Diseño de zona de aterrizaje
El análisis a escala de nube admite un modelo de control de acceso mediante identidades de Microsoft Entra. El modelo sua el control de acceso basado en rol (RBAC de Azure) y las listas de control de acceso (ACL).
Revise las actividades de administración y supervisión de Azure que deben llevar a cabo los equipos. Tenga en cuenta el análisis a escala de nube en Azure. Determine el mejor reparto posible de responsabilidades dentro de la organización.
Asignaciones de roles
Para desarrollar, entregar y servir productos de datos de forma autónoma dentro de la plataforma de datos, los equipos de aplicaciones de datos requieren pocos derechos de acceso en el entorno de Azure. Antes de pasar por los requisitos RBAC respectivos, debe resaltarse que se deben usar diferentes modelos de acceso para los entornos de desarrollo y superiores. Además, los grupos de seguridad se deben usar siempre que sea posible para reducir el número de asignaciones de roles y simplificar el proceso de administración y revisión de los derechos RBAC. Esto es fundamental, debido al número limitado de asignaciones de roles que se pueden crear por suscripción.
El equipo de desarrollo debe tener acceso al entorno de desarrollo y sus respectivas identidades de usuario para permitirles iterar más rápidamente, obtener información sobre ciertas funcionalidades dentro de los servicios de Azure y solucionar problemas de forma eficaz. El acceso a un entorno de desarrollo le ayudará a desarrollar o mejorar la infraestructura como código (IaC) y otros artefactos de código. Una vez que una implementación dentro del entorno de desarrollo funciona según lo previsto, se puede implementar continuamente en los entornos más altos. Los entornos más altos, como prueba y producción, deben bloquearse para el equipo de aplicaciones de datos. Solo una entidad de servicio debe tener acceso a estos entornos y, por tanto, todas las implementaciones se deben ejecutar a través de la identidad de la entidad de servicio mediante canalizaciones de CI/CD. En resumen, en los derechos de acceso del entorno de desarrollo se deben proporcionar a una entidad de servicio Y a las identidades de usuario, y en entornos superiores solo se deben proporcionar a una identidad de entidad de servicio.
Para poder crear recursos y asignaciones de roles entre recursos dentro de los grupos de recursos de aplicación de datos, se deben proporcionar los permisos Contributor y User Access Administrator. Esto permitirá a los equipos crear y controlar servicios dentro de su entorno y dentro de los límites de Azure Policy. El análisis a escala de nube recomienda el uso de puntos de conexión privados para superar el riesgo de filtración de datos y, dado que el equipo de la plataforma Azure debe bloquear otras opciones de conectividad a través de directivas, los equipos de aplicaciones de datos requerirán derechos de acceso a la red virtual compartida de una zona de aterrizaje de datos para poder configurar correctamente la conectividad de red necesaria para los servicios que planean usar. Para seguir el principio de privilegios mínimos, supere los conflictos entre distintos equipos de aplicaciones de datos y tenga una separación clara de los equipos, el análisis a escala de nube propone crear una subred dedicada por equipo de aplicación de datos y crear una asignación de roles Network Contributor a esa subred (ámbito de grupo de recursos). Esta asignación de roles permite a los equipos unirse a la subred mediante puntos de conexión privados.
Estas dos primeras asignaciones de roles habilitarán la implementación de autoservicio de servicios de datos en estos entornos. Para abordar el problema de administración de costos, las organizaciones deben agregar la etiqueta del centro de costo a los grupos de recursos para habilitar la distribución y el reparto de los costos. Esto aumenta la concienciación dentro de los equipos y les exige tomar las decisiones adecuadas con respecto a las SKU y los niveles de servicio necesarios.
Para habilitar también el uso de autoservicio de otros recursos compartidos dentro de la zona de aterrizaje de datos, se requieren pocas asignaciones de roles adicionales. Si se requiere acceso a un entorno de Databricks, las organizaciones deben usar SCIM Synch desde Microsoft Entra ID para proporcionar acceso. Esto es importante, ya que este mecanismo sincroniza automáticamente los usuarios y grupos de Microsoft Entra ID al plano de datos de Databricks y también quita automáticamente los derechos de acceso cuando un individuo abandona la organización o la empresa. Si se usan cuentas de usuario independientes en Azure Databricks, esto no pudo ser el caso. Los equipos de aplicaciones de datos deben agregarse al área de trabajo de Databricks en shared-product-rg y shared-integration-rg. En Azure Databricks, los equipos de aplicaciones de datos deben tener derechos de acceso Can Restart a un clúster predefinido para poder ejecutar cargas de trabajo dentro del área de trabajo.
Los equipos individuales requerirán acceso a la cuenta central de Purview para detectar recursos de datos dentro de las zonas de aterrizaje de datos correspondientes. Por lo tanto, los equipos tendrán que agregarse como Data Reader a la colección de nivel superior de Purview. Además, los equipos requerirán en la mayoría de los casos la opción de editar los recursos de datos catalogados que poseen para proporcionar detalles adicionales, como los detalles de contacto de los propietarios y expertos de datos, así como detalles más detallados sobre qué columnas de un conjunto de datos describen y qué información incluyen.
Resumen de los requisitos de control de acceso basado en roles
Para fines de automatización de la implementación de zonas de aterrizaje de datos, necesita estos roles:
Nombre de rol
Descripción
Ámbito
Implemente todas las zonas DNS privadas para todos los servicios de datos en una sola suscripción y grupo de recursos. La entidad de servicio debe ser Private DNS Zone Contributor en el grupo de recursos DNS global que se creó durante la implementación de la zona de aterrizaje de administración de datos. Este rol es necesario para implementar registros A para los puntos de conexión privados.
(Ámbito de grupo de recursos) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Para configurar el emparejamiento de red virtual entre la red de zona de aterrizaje de datos y la red de zona de aterrizaje de administración de datos, la entidad de servicio necesita derechos de acceso Network Contributor en el grupo de recursos de la red virtual remota.
(Ámbito de grupo de recursos) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Este permiso es necesario para compartir el entorno de ejecución de integración auto-hospedado que se implementa en el grupo de recursos integration-rg con otras factorías de datos. También es necesario asignar el acceso de identidades administradas de Azure Data Factory y Azure Synapse Analytics en los sistemas de archivos de la cuenta de almacenamiento correspondientes.
(Ámbito de recursos) /subscriptions/{{dataLandingZone}subscriptionId}
Nota
El número de asignaciones de roles se puede reducir en un escenario de producción. La asignación de roles Network Contributor solo es necesaria para configurar el emparejamiento de red virtual entre la zona de aterrizaje de administración de datos y la zona de aterrizaje de datos. Sin esta consideración, la resolución DNS no funciona. El tráfico entrante y saliente se descarta porque no hay ninguna línea de visión a Azure Firewall.
Private DNS Zone Contributor tampoco es necesario si la implementación de registros A de DNS de los puntos de conexión privados se automatiza mediante directivas de Azure con efecto deployIfNotExists. Lo mismo se aplica a User Access Administrator porque la implementación se puede automatizar mediante directivas deployIfNotExists.
Asignaciones de roles para los productos de datos
Las siguientes asignaciones de roles son necesarias para una implementación de un producto de datos dentro de una zona de aterrizaje de datos:
Nombre de rol
Descripción
Ámbito
Implemente todas las zonas DNS privadas para todos los servicios de datos en una sola suscripción y grupo de recursos. La entidad de servicio debe ser Private DNS Zone Contributor en el grupo de recursos DNS global que se creó durante la implementación de la zona de aterrizaje de administración de datos. Este rol es necesario para implementar registros A para los puntos de conexión privados respectivos.
(Ámbito de grupo de recursos) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Implemente todos los servicios de streaming de integración de datos en un único grupo de recursos dentro de la suscripción de la zona de aterrizaje de datos. La entidad de servicio requiere una asignación de roles Contributor en ese grupo de recursos.
(Ámbito de grupo de recursos) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Para implementar puntos de conexión privados en la subred de Private Link especificada, que se creó durante la implementación de la zona de aterrizaje de datos, la entidad de servicio requiere acceso Network Contributor en esa subred.
(Ámbito de grupo de recursos) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Acceso a otros recursos
Fuera de Azure, los equipos de integración de datos y productos de datos también requerirán acceso a un repositorio para almacenar artefactos de código, colaborar de forma eficaz e implementar actualizaciones y cambios de forma coherente a través de CI/CD en entornos más altos. Además, se debe proporcionar un panel de proyecto para permitir el desarrollo ágil, la planificación de sprints, el seguimiento de tareas y, los comentarios de los usuarios y las solicitudes de características.
Por último, la automatización de CI/CD requerirá la configuración de una conexión a Azure, que se realiza en la mayoría de los servicios mediante principios de servicio. Por lo tanto, los equipos requerirán acceso a un principio de servicio para lograr la automatización dentro de su proyecto.
Administración del acceso a las aplicaciones
La administración del acceso a los datos debe realizarse mediante grupos de Microsoft Entra. Agregue nombres principales de usuario o nombres de entidad de servicio a los grupos de usuarios de Microsoft Entra. Agregue los grupos a los servicios y conceda permisos al grupo. Este enfoque permite el control de acceso más preciso.
En el caso de los productos de datos en lagos de datos de Azure, considere la posibilidad de usar listas de control de acceso (ACL). Para obtener más información, consulte Modelo de control de acceso en Azure Data Lake Storage Gen2. La mayoría de los servicios nativos de Azure admiten el acceso directo de Microsoft Entra con listas de control de acceso, incluidos Azure Machine Learning, Azure Synapse SQL sin servidor, Apache Spark para Azure Synapse y Azure Databricks.
Es probable que se utilice otro almacenamiento políglota en el análisis a escala de nube. Algunos ejemplos son Azure Database for PostgreSQL, Azure Database for MySQL, Azure SQL Database, SQL Managed Instance y grupos dedicados de Azure Synapse SQL. Los equipos de aplicaciones de datos pueden usarlos para almacenar productos de datos.
- Uso de Microsoft Entra ID para la autenticación con Azure Database for PostgreSQL
- Uso de la autenticación de Microsoft Entra con Azure SQL Database, SQL Managed Instance y Azure Synapse Analytics
- Uso de Microsoft Entra ID para la autenticación con Azure Database for MySQL
Se recomienda usar grupos de Microsoft Entra para proteger los objetos de base de datos, en lugar de cuentas de usuarios de Microsoft Entra individuales. Estos grupos de Microsoft Entra se usan para autenticar a los usuarios y ayudar a proteger los objetos de base de datos. De forma similar al patrón del lago de datos, puede usar la incorporación de su dominio o productos de datos para crear estos grupos dentro de su servicio Microsoft Entra.
Este enfoque también proporciona una ubicación de administración única y permite revisar los derechos de acceso dentro de Azure Graph.
Para obtener más información sobre cómo impulsar la seguridad para las zonas de aterrizaje de administración de datos, y cómo las zonas de aterrizaje de datos administran su patrimonio de datos, consulte Aprovisionamiento de la seguridad para el análisis a escala de nube en Azure.