Protección de datos para arquitecturas de datos comunes
En este artículo se proporciona información general sobre cómo configurar la seguridad de los datos de OneLake tanto para arquitecturas de malla de datos como radiales.
Características de seguridad
Microsoft Fabric usa un modelo de seguridad de varias capas con distintos controles disponibles en distintos niveles para proporcionar solo los permisos mínimos necesarios. Para obtener más información sobre los distintos tipos de seguridad que se describen en esta guía paso a paso, consulte Modelo de control de acceso a datos en OneLake.
Protección para mallas de datos
La malla de datos es un paradigma arquitectónico que trata los datos como un producto, en lugar de un servicio o un recurso. La malla de datos tiene como objetivo descentralizar la propiedad y gobernanza de los datos en distintos dominios y equipos, al tiempo que permite la interoperabilidad y la detectabilidad a través de una plataforma común. En una arquitectura de malla de datos, cada equipo descentralizado administra la propiedad de los datos que forman parte de su producto de datos. La guía de seguridad proporcionada en esta sección se centra en un único equipo de productos de datos que configura el acceso a su área de trabajo. Los pasos están diseñados para que los repita cada equipo del producto de datos en su propia área de trabajo, ya que permiten el acceso a los usuarios de nivel inferior.
Para empezar a crear una malla de datos, use la característica de dominio de Microsoft Fabric para etiquetar áreas de trabajo según su producto de datos asociado y su propiedad.
Dentro de los dominios, cada equipo tiene su propia área o áreas de trabajo. El área de trabajo almacena los datos necesarios para crear los productos de datos finales para su consumo. Conceda a los usuarios acceso al área de trabajo mediante roles de área de trabajo.
Identifique los consumidores de nivel inferior de los productos de datos y conceda acceso según los permisos mínimos necesarios para lograr sus objetivos. Para mantener a los usuarios alineados con sus experiencias de destino, cada tipo de usuario de nivel inferior puede tener acceso a un único elemento de datos de Fabric. En la tabla siguiente se muestran algunos casos de uso comunes para los consumidores de malla de datos y los elementos de Fabric pertinentes.
| Usuario | Elementos de Fabric |
|---|---|
| Científicos de datos | Cuadernos de Apache Spark o lakehouse |
| Ingenieros de datos | Cuadernos de Apache Spark, flujos de datos o canalizaciones |
| Analistas de negocios | Punto de conexión de análisis SQL |
| Creadores de informes | Modelos semánticos |
| Consumidores informes | Informes de Power BI |
Protección para arquitecturas radiales
Una arquitectura radial difiere de una malla de datos al tener todos los productos de datos certificados administrados en una única ubicación de propiedad central. Los consumidores de nivel inferior se centran menos en la creación de productos de datos adicionales y, en su lugar, realizan análisis sobre los datos producidos por el equipo central.
Identifique los consumidores de nivel inferior y conceda acceso según los permisos mínimos necesarios para lograr sus objetivos. Para mantener a los usuarios alineados con sus experiencias de destino, cada tipo de usuario de nivel inferior puede tener acceso a un único elemento de datos de Fabric. En la tabla de roles de usuario se muestran algunos casos de uso comunes para la arquitectura radial junto con los elementos de Fabric pertinentes.
| Usuario | Elementos de Fabric |
|---|---|
| Científicos de datos | Cuadernos de Apache Spark o lakehouse |
| Analistas de negocios | Punto de conexión de análisis SQL |
| Creadores de informes | Modelos semánticos |
| Consumidores informes | Informes de Power BI |
Roles de área de trabajo
Las asignaciones de roles del área de trabajo siguen las mismas directrices para las arquitecturas de malla de datos y radial. En la tabla de responsabilidades del trabajo se describe qué rol de área de trabajo asignar a los usuarios según las funciones que realizan en el área de trabajo.
| Responsabilidades del cargo | Rol de área de trabajo |
|---|---|
| Propietario del área de trabajo y administración de asignaciones de roles | Administración |
| Administración de asignaciones de roles para usuarios que no son administradores | Member |
| Creación de elementos de Fabric y escritura de datos | Colaborador |
| Creación de tablas y vistas con SQL | Visor + permisos de SQL |
Científicos de datos
Los científicos de datos necesitan acceder a los datos de una instancia de Lakehouse para consumir a través de Apache Spark. En el caso de arquitecturas de malla de datos y radial, los usuarios de Spark consumen datos de un área de trabajo independiente de aquella en la que residen los datos. Esto permite a los científicos de datos tener acceso para crear modelos y experimentos sin desordenar el área de trabajo que contiene los datos. Los científicos de datos también pueden usar otros servicios que no son de Spark y que se conectan directamente a las rutas de datos de OneLake, como Azure Databricks o Dremio.
Para aprovisionar el acceso de los científicos de datos, use el botón Compartir para compartir la instancia de Lakehouse. Seleccione el cuadro Leer todo Apache Spark en el cuadro de diálogo. En el caso de instancias de Lakehouse con roles de acceso a datos de OneLake habilitados, asigne a los mismos usuarios acceso al agregarlos a un rol de acceso a datos de OneLake. El uso de roles de acceso a datos de OneLake proporciona acceso más preciso a los datos. Después, los ingenieros de datos pueden crear accesos directos para seleccionar tablas o carpetas en una instancia de Lakehouse.
Ingenieros de datos
Los ingenieros de datos necesitan acceso a los datos de una instancia de Lakehouse para crear productos de datos de bajada. Los ingenieros de datos necesitan acceder a los datos de OneLake para que se puedan crear canalizaciones o cuadernos para leer los datos. En un modelo radial verdadero, el rol de ingeniero de datos solo existe dentro de las capas del equipo central. Sin embargo, para mallas de datos, los ingenieros de datos combinan productos de datos entre dominios para crear nuevos conjuntos de datos.
Use el botón Compartir para compartir la instancia de Lakehouse con ingenieros de datos. Marque el cuadro Leer todo Apache Spark en el cuadro de diálogo. En el caso de instancias de Lakehouse con roles de acceso a datos de OneLake habilitados, asigne a los mismos usuarios acceso al agregarlos a un rol de acceso a datos de OneLake. El uso de roles de acceso a datos de OneLake proporciona acceso más preciso a los datos. Después, los ingenieros de datos pueden crear accesos directos para seleccionar tablas o carpetas en una instancia de Lakehouse.
Analistas de negocios
Los analistas de negocios (a veces llamados analistas de datos) consultan datos a través de SQL para responder a preguntas empresariales.
Use el botón Compartir para compartir la instancia de Lakehouse con los analistas de negocios. Marque el cuadro Leer todos los datos del punto de conexión de SQL en el cuadro de diálogo. Esta configuración proporciona a los analistas de negocios acceso a los datos del punto de conexión de análisis de SQL de un lago de datos, pero no para ver los archivos de OneLake subyacentes.
El acceso a los datos se puede restringir aún más para estos usuarios mediante la definición de la seguridad a nivel de fila o columna directamente en SQL.
Creadores de informes
Los creadores de informes crean informes de Power BI para que otros usuarios los consuman.
Use el botón Compartir para compartir la instancia de Lakehouse con los creadores de informes. Marque el cuadro Generar informes en el modelo semántico predeterminado en el cuadro de diálogo. Este permiso permite a los creadores de informes crear informes mediante el modelo semántico asociado a la instancia de Lakehouse. Esos usuarios no pueden acceder a los datos de OneLake ni tener acceso completo al punto de conexión de análisis de SQL.
Consumidores informes
Los consumidores de informes son los líderes empresariales o directores que ven los datos de un informe de Power BI para tomar decisiones.
Comparta un informe con los consumidores mediante el botón Compartir. No marque ninguno de los cuadros para conceder acceso para leer el informe, pero no para ver ninguno de los datos subyacentes. Para evitar que los usuarios accedan al punto de conexión de análisis de SQL y vean tablas, asegúrese de que no hay permisos de SQL definidos que concedan acceso a estos usuarios.
También puede compartir datos con consumidores de informes mediante una aplicación. Las aplicaciones permiten a los usuarios acceder a un informe o un conjunto de informes predefinido sin necesidad de acceder al área de trabajo subyacente. Tenga en cuenta que para los informes en modo de lago directo, se tendrá que compartir con los usuarios el lakehouse subyacente para que puedan ver los datos.