Asegurar el acceso a datos en Microsoft Fabric

¿Qué te enseña este módulo?

Este módulo cubre cómo securizar el acceso a datos en Fabric — desde los workspace roles hasta la nueva OneLake Security. Los objetivos oficiales:

1. Describir el modelo de permisos en Microsoft Fabric.
2. Configurar workspace e item permissions.
3. Aplicar permisos granulares (OneLake security, RLS, CLS, OLS).

Peso en el examen DP-700

La idea general

Microsoft Fabric usa un modelo de seguridad multi-capa con controles de acceso a distintos niveles. Cada capa añade control adicional sin reemplazar a las demás.

Las capas (visión general)

• Layer 1: Tenant settings — configuración global del tenant, capabilities de Fabric admin.
• Layer 2: Capacity — quién puede consumir la Fabric capacity. SKUs (F2, F4, ..., F2048).
• Layer 3: Workspace — workspace roles (Admin, Member, Contributor, Viewer). Primer nivel práctico de seguridad.
• Layer 4: Item — item permissions (Read, ReadData, ReadAll, Write, Share). Granularidad por item.
• Layer 5: OneLake Security ⭐ — seguridad de data plane, granular hasta rows y columns.
• Layer 6: Compute-level — T-SQL security (RLS, CLS, OLS, DDM) en Warehouse/SQL DB, KQL RLS en Eventhouse, RLS de semantic model en Power BI.

Filosofía: seguridad aplicada en TODOS los engines

Muy importante: la seguridad en Fabric se aplica en todos los compute engines. Si un usuario solo tiene acceso a ciertas rows de una tabla, las verá limitadas vía SQL, vía Spark notebooks, vía Power BI y vía KQL. Fabric mantiene una única verdad de seguridad que respeta cualquier engine.

Este es EL concepto fundamental que tienes que dominar. Se pregunta en el examen y aparece por todos lados.

Los 2 planes

OneLake aplica la seguridad en dos planos:

A) Control plane permissions 🎛️

• Gobiernan qué puedes HACER con un item: crear, configurar, compartir, gestionar, borrar.
• Se establecen a nivel workspace (workspace roles) y a nivel item (item permissions).

B) Data plane permissions 📊

• Gobiernan qué DATA puedes ver o cambiar.
• Para OneLake, este plano es OneLake Security.
• Define roles en un item y los acota a folders, tables, schemas, rows y columns.

Tabla comparativa oficial

Los 3 niveles de la jerarquía

OneLake es un data lake jerárquico como ADLS Gen2. Los planos aplican a distintos niveles:

1. Workspace — entorno colaborativo. Seguridad de control plane vía workspace roles.
2. Item — capabilities agrupadas (lakehouse, warehouse, SQL DB). Hereda los permisos del workspace pero puede tener permisos adicionales de control plane. Aquí también defines los OneLake security roles.
3. Folders y por debajo — folders (Tables/, Files/), tables, schemas, rows, columns. OneLake Security acota el acceso de data plane aquí.

Los items siempre viven dentro de workspaces, y los workspaces siempre viven directamente bajo el namespace de OneLake.

Ejemplo mental

Escenario: quiero que Sareta pueda VER una tabla pero no otras, y que NO pueda crear tablas nuevas:

• Control plane: le doy el item permission Read (puede conectar al item).
• Data plane: creo un OneLake security role que concede Read solo a esa tabla concreta.
• NO le doy el workspace role Contributor (evita que cree tablas).

Resultado: puede ver una tabla concreta y nada más 🎯

Los 4 roles

1. Viewer 👀 — puede ver todo el contenido del workspace, pero no modificarlo.
2. Contributor ✏️ — puede ver y modificar todo el contenido.
3. Member 🤝 — puede ver, modificar y compartir todo el contenido.
4. Admin 👑 — puede ver, modificar, compartir y gestionar todo el contenido, incluida la gestión de permisos.

Confinamiento

Los workspace roles están confinados a un workspace concreto. No aplican a otros workspaces, ni a la capacity, ni al tenant. Cada workspace tiene sus roles independientes.

Usuarios sin rol

Los usuarios que NO tienen ningún workspace role NO pueden acceder al workspace. Excepción: si el item se ha compartido con ellos individualmente (vía item permissions), pueden acceder al item concreto sin acceso al workspace.

Asignación a grupos

Puedes asignar roles a usuarios individuales (usuarios de Microsoft Entra), security groups, grupos de Microsoft 365 y distribution lists (soporte limitado).

Tabla oficial resumen

Acceso a workloads

Detalles adicionales por item

Data warehouse (Warehouse): Admin/Member/Contributor tienen full admin + full data access; el Viewer puede leer data y metadata y conectar.

SQL database: similar al Warehouse.

Lakehouse: Admin/Member/Contributor pueden escribir data (vía Spark); el Viewer no tiene acceso OneLake por defecto (necesita un OneLake security role o el item permission ReadAll).

Eventhouse (KQL): usa un modelo híbrido de control de acceso basado en roles — workspace roles + roles específicos de KQL.

Notebooks

Muy examinable:

• Admin, Member, Contributor: pueden hacer CRUD de notebooks vía API.
• Viewer: no puede.

Ejecución vía Job Scheduler API: Admin, Member y Contributor pueden iniciar y cancelar runs. Todos los roles, incluido Viewer, pueden monitorizar el estado del run y ver el output de la ejecución (metadata como estado y exit values).

¿Qué son?

Los item permissions controlan el acceso a items individuales de Fabric dentro de un workspace. Están confinados a un item concreto, no aplican a otros items, y se usan para conceder acceso a un único item sin dar acceso al workspace.

Cuándo usarlas

• Quieres compartir un item específico sin dar acceso al workspace entero.
• Consumo downstream: publicar un warehouse para reporting sin exponer el workspace de desarrollo.
• Sharing granular entre equipos.

Cómo compartir

Cuando compartes un item con un usuario o grupo, puedes configurar los item permissions. Compartir un item concede permiso de lectura por defecto.

⚠️ Los permisos Read permiten:

• ✅ Ver los metadatos del item.
• ✅ Ver cualquier report asociado.

Los permisos Read NO permiten:

• ❌ Acceder a la data subyacente en SQL o en OneLake.

Para un acceso más profundo a la data, hay que conceder permisos adicionales a nivel compute a través del SQL analytics endpoint o de la seguridad del semantic model.

Los item permissions varían por item

Distintos items de Fabric tienen distintos permisos: los semantic models tienen los suyos; el Warehouse tiene Read, ReadData, ReadAll, Write y Share; el Lakehouse es similar al Warehouse; SQL Database, similar; los items de Data Factory tienen los suyos; los de Real-Time Intelligence usan roles KQL; y las mirrored databases tienen los suyos. Consulta la doc de cada item cuando trabajes con casos específicos.

Este es EL punto más examinable de los item permissions. Domínalo bien.

Los 3 permisos clave

Para items como Warehouse, SQL Database y Lakehouse:

A) Read 🔑

• Permite conectar al item (SQL analytics endpoint).
• Sin Read → la conexión FALLA del todo.
• NO da acceso a la data automáticamente.

B) ReadData 📊

• Permite leer data vía SQL (queries a tables/views).
• Necesita también Read.

C) ReadAll 📂

• Permite leer los ficheros Parquet raw en OneLake directamente.
• El más amplio en términos de acceso a ficheros raw.

Tabla comparativa

SQL Database específico

Write permission

Write = acceso administrativo completo y acceso completo a la data. Para items como Warehouse y SQL Database: full CRUD, crear/alterar/borrar objects y gestionar la seguridad dentro del item.

Nota: si tienes el workspace role Admin/Member/Contributor, ya tienes acceso de escritura implícito.

Share permission

Share permite compartir el item y gestionar sus item permissions. Es decir: puedes decidir a quién dar item permissions aunque no seas admin del workspace. Útil cuando delegas la gestión de acceso de un item concreto sin dar admin completo del workspace.

Reshare permission

En algunos items existe Reshare — permite compartir con otros un item que a su vez te compartieron a ti. Los Contributors y Viewers pueden compartir items de un workspace si tienen permisos de Reshare. Sin Reshare, no pueden extender el sharing.

Otros permisos específicos

Por tipo de item puede haber más:

• Execute — para ejecutar notebooks/pipelines.
• Build — para crear reports contra semantic models.
• Monitor — ver ejecuciones.
• SubscribeOneLakeEvents — suscribirse a eventos de items (por defecto lo tienen Admin/Member/Contributor; el Viewer no, salvo concesión explícita).

La feature de sharing

Puedes compartir items de Fabric con usuarios de tu organización que no tienen ningún workspace role. El sharing da acceso restringido — permite a los usuarios acceder solo al item compartido dentro del workspace.

Cómo funciona

1. En el workspace, click en un item.
2. Botón Share.
3. Añadir usuarios o grupos.
4. Elegir qué permisos conceder.
5. Opcional: enviar email de notificación.

Los usuarios reciben acceso al item concreto, no al workspace completo.

Casos de uso típicos

• Compartir un warehouse con el equipo de analytics.
• Compartir un report de Power BI con usuarios de negocio.
• Compartir un semantic model con los diseñadores de reports.
• Compartir un lakehouse con data scientists.

Sin que tengan que entrar al workspace de desarrollo.

Página Manage permissions

En cada item puedes ir a Manage permissions para ver quién tiene qué permiso, añadir o quitar item permissions individuales y revocar accesos. Cada tipo de item determina qué permisos están disponibles.

Este es el gran tema del módulo. Feature relativamente nueva y muy examinable 💕

¿Qué es?

OneLake Security provee seguridad granular basada en roles para la data almacenada en OneLake y aplica esa seguridad de forma consistente en todos los compute engines de Fabric. Es el modelo de seguridad de data plane para la data de OneLake.

Por qué es importante

Antes (sin OneLake Security): seguridad a nivel workspace (todo o nada), a nivel item (Read/ReadData/ReadAll) y específica por compute — SQL RLS en Warehouse, políticas KQL en Eventhouse. Cada engine tenía su propio modelo de seguridad.

Ahora (con OneLake Security): un único modelo de seguridad en OneLake, granular a nivel folder, table, schema, row y column, aplicado en TODOS los engines (SQL, Spark, KQL, Power BI). Defines una vez, aplica en todas partes.

Beneficios

• ✅ Single source of truth para los permisos.
• ✅ Consistencia entre engines.
• ✅ Granularidad hasta rows y columns.
• ✅ Menos overhead de configuración.
• ✅ Los data owners mantienen el control incluso cuando la data pasa a otros workspaces.

Quién puede crear roles

Los usuarios de Fabric con workspace role Admin o Member pueden crear OneLake security roles.

A quién afectan

Los OneLake security roles conceden acceso a los usuarios con workspace role Viewer y a los usuarios con permiso Read sobre el item.

NO afectan a los Admins, Members ni Contributors del workspace, porque ellos ya tienen permisos de lectura y escritura sobre toda la data del workspace.

Componentes obligatorios

1. Permissions 🔑 — los permisos que el role concede sobre la data. Opciones: Read o ReadWrite.
2. Type 🎯 — el tipo de role. OneLake security solo soporta roles de tipo Grant (dan acceso a la data).
3. Data in role 📊 — las tables, folders o schemas a los que el role da acceso. También puedes definir el acceso con row-level y column-level security.
4. Members in role 👥 — las identidades de Microsoft Entra asignadas al role: usuarios, grupos o identidades no-usuario (service principals).

Ejemplo mental

Role: Analytics_Team_Sales

• Permissions: Read
• Type: Grant
• Data in role:
  • Tabla sales_orders (completa)
  • Tabla customer_master (con RLS: solo rows donde region = "EU")
  • Columna credit_card_number excluida vía CLS
  • Folder raw_files/2026/ completo
• Members in role: grupo Analytics_Team_EU, usuario sareta@kawaiibi.es y service principal SP-BI-Automation

Los 2 tipos

A) Read 📖 — leer data. Puedes aplicar RLS y CLS a los roles Read.

B) ReadWrite ✏️ — leer y escribir data. RLS y CLS NO están disponibles en los roles ReadWrite.

Cuándo cada uno

Read ✅ cuando el usuario solo debe consumir data, necesitas restringir a un subconjunto de rows/columns, o son consumidores de analytics y visualizadores de reports.

ReadWrite ✅ cuando el usuario necesita escribir data a la tabla/folder, como data engineers que ingestan data, y sin restricciones granulares (sin RLS/CLS).

⚠️ Nota sobre Lakehouse

Según la doc oficial de lakehouse-sharing: "OneLake security does not grant write permissions - it only provides granular control over read access for users who already have basic read access to the lakehouse. Write permissions must still be granted through workspace roles (Contributor or higher)."

Esta doc parece contradictoria con la general que menciona ReadWrite. La realidad matizada:

• En lakehouses, OneLake security se usa principalmente para acceso READ a nivel folder.
• ReadWrite es una capability más nueva y limitada — para escribir en OneLake, los workspace roles siguen siendo el mecanismo principal.

Para el examen: quédate con que Read es el uso primario, y ReadWrite es una capability adicional pero con restricciones.

Escritura vía Spark, OneLake file explorer y APIs

Cuando ReadWrite está disponible, esos permisos se utilizan a través de notebooks de Spark, el OneLake file explorer y las OneLake APIs. Las operaciones de escritura vía la UX del Lakehouse para viewers NO están soportadas actualmente.

¿Qué es?

El DefaultReader role existe en todos los lakehouses y da a cualquier usuario con permiso ReadAll acceso a la data del lakehouse.

Comportamiento por defecto

Cuando creas un lakehouse, el DefaultReader role se crea automáticamente, concede acceso a todos los usuarios con ReadAll a nivel item, y esos usuarios pueden ver toda la data del lakehouse.

Cuándo modificarlo o borrarlo

Si quieres restringir el acceso de forma más granular: borra el DefaultReader role o edítalo para modificar qué concede. Sin DefaultReader, los usuarios con ReadAll NO ven data automáticamente — necesitan un OneLake security role específico.

Ejemplo del examen

Escenario: quieres que Sareta solo vea la tabla sales_summary, no todas.

1. Borra o modifica el DefaultReader para que no le dé acceso general.
2. Crea un nuevo OneLake security role con Read solo a sales_summary.
3. Añade a Sareta al role.

Sin borrar el DefaultReader, Sareta seguiría viéndolo todo.

Prerequisites

Permisos Write o Reshare en Fabric (generalmente incluidos para los usuarios con workspace role Admin o Member).

Items soportados

Nota: la lista puede crecer conforme Fabric evoluciona.

Pasos completos

Paso 1: abrir el item de Fabric donde quieres controlar el acceso a los datos.

Paso 2: seleccionar Manage OneLake security en el menú del item.

Paso 3: en el panel de OneLake security, seleccionar New.

Paso 4: rellenar la info del nuevo role:

Paso 5: Add data to your role. Define el scope:

• All data: concede acceso a todas las tables y files del item, incluidos los folders que se añadan en el futuro.
• Selected data: concede acceso a un grupo seleccionado de tables y folders.

Paso 6: si elegiste Selected data:

• Edit → expandir los directorios Tables y Files.
• Marcar las casillas de tables y files.
• Para aplicar RLS o CLS a una tabla, seleccionar el nombre de la tabla → Data access → elegir opción.
• Add data para añadir los items seleccionados al role.

Paso 7: Add members to your role — manualmente (nombres o emails) o con configuración avanzada para asignar miembros virtuales (basados en workspace role).

Paso 8: Create.

Virtual members

Feature poderosa: asignar miembros virtuales según el workspace role. Ejemplo: "cualquier usuario que sea Viewer en este workspace → se asigna automáticamente a este role". Perfecto para automation y consistencia.

¿Qué es OLS en OneLake?

Object-Level Security (OLS) = conceder acceso a tables o folders concretos de un data item. Con OLS creas permisos para data estructurada y no estructurada a nivel folder.

Concepto clave

Las tablas Delta Parquet en OneLake se representan como folders. Por eso puedes securizar las tablas igual que los folders. Los schemas también son folders, así que puedes securizarlos igual.

Estructura OneLake típica

lakehouse/
├── Tables/
│   ├── sales_orders/          ← folder = table
│   ├── customer_master/       ← folder = table
│   └── product_catalog/       ← folder = table
├── Files/
│   ├── raw_2026/              ← folder
│   │   ├── jan/
│   │   ├── feb/
│   │   └── mar/
│   └── archive_2025/          ← folder

Puedes conceder acceso a un folder concreto (Files/raw_2026/jan/), a una tabla concreta (Tables/sales_orders/) o a un schema completo (el folder que agrupa tablas).

Uso típico

Escenario: el compliance requiere que Sareta acceda solo a Files/archive_2025/ para una auditoría, pero no a la raw data.

• Data: Files/archive_2025/
• Permissions: Read
• Members: sareta@kawaiibi.es

Sin acceso a Files/raw_2026/ ni a otras tablas.

Herencia

La seguridad de folder es heredable por todos los subfolders. Conceder acceso a Files/2026/ lo aplica automáticamente a Files/2026/jan/, Files/2026/feb/, etc. Muy útil para organización jerárquica de datos.

¿Qué es?

Row-Level Security (RLS) = restringe qué rows puede ver un usuario en una tabla. Aplica a nivel fila, sin afectar a la estructura de la tabla.

Cómo funciona en OneLake

Defines las reglas de RLS dentro de un OneLake security role que concede permiso Read. Ejemplo: role EU_Analysts con Read sobre sales_orders y regla RLS region = 'EU' → los analistas solo ven las rows donde region = 'EU'.

Diferencia con el RLS de Power BI clásico

El RLS clásico de Power BI vive solo en el semantic model. El RLS de OneLake Security vive en la data — cualquier engine lo respeta. Es una diferencia arquitectónica importante.

Cómo definirlo

Al crear o editar un OneLake security role:

1. Añadir la tabla.
2. Seleccionar el nombre de la tabla → Data access.
3. Elegir Row-level security.
4. Definir la expresión de filtro.
5. Guardar.

¿Qué es?

Column-Level Security (CLS) = restringe qué columns son visibles para usuarios concretos.

Uso típico

Escenario: la tabla employees tiene columnas employee_id, name y department (públicas) y salary, ssn y personal_email (sensibles).

Con CLS: el role HR_Full ve todas las columnas, y el role HR_General excluye salary, ssn y personal_email.

Enforcement

Cross-engine igual que RLS: las queries SQL no devuelven las columnas restringidas, las lecturas de Spark las excluyen y los reports de Power BI no las muestran.

Cómo definirlo

1. Añadir la tabla.
2. Data access → Column-level security.
3. Incluir/excluir columnas.
4. Guardar.

La filosofía

OneLake Security aplica la seguridad de forma consistente en todos los compute engines de Fabric. Es decir: defines la seguridad una vez y aplica en todas partes.

Engines que respetan OneLake Security

• ✅ SQL analytics endpoint (Warehouse, Lakehouse).
• ✅ Spark notebooks (Fabric Notebooks).
• ✅ KQL queries (Eventhouse).
• ✅ Power BI (Direct Lake, DirectQuery, Import donde aplique).
• ✅ OneLake APIs (REST, SDKs).
• ✅ OneLake file explorer.

Enforcement en engines de terceros (preview)

Feature más nueva: aplicar OneLake security en engines de terceros autorizados (preview). La idea es que los engines externos autorizados también respeten OneLake Security. Ejemplos potenciales: Snowflake consultando OneLake, o Databricks externo con la autenticación adecuada.

Cómo trabaja bajo el capó

Los engines consultan las políticas de OneLake Security al acceder a la data. El propio engine aplica los filtros según el usuario que llama: recupera las políticas aplicables al usuario y al item, aplica los filtros de RLS, las exclusiones de CLS y las concesiones de OLS, y devuelve solo lo permitido. Este flujo es automático y transparente.

Matriz de soporte actual

Items que aún NO soportan

Actualmente NO soportados (usan otros mecanismos):

• ❌ Warehouse (usa T-SQL security: OLS, RLS, CLS, DDM).
• ❌ SQL Database (usa T-SQL security).
• ❌ KQL Database (usa políticas KQL de RLS).
• ❌ Semantic models (usan RLS/OLS con DAX).

Para estos items: usa la seguridad a nivel compute que ya vimos en módulos anteriores.

Estrategia mixta

Muy común: mezclar OneLake Security + compute-level. Data en Lakehouse → OneLake Security roles. Data en Warehouse → T-SQL RLS/CLS. Data en KQL DB → políticas KQL de RLS. Data en Semantic Model → RLS con DAX. Cada engine con la seguridad que le corresponde.

Roadmap

Se espera que el soporte para más items crezca. OneLake Security es la dirección estratégica para la seguridad en Fabric.

Direct Lake y seguridad

Direct Lake lee la data directamente de OneLake sin importarla en memoria. Esto significa que aplica la seguridad del data source.

Los 3 approaches para el control de acceso

A) Workspace roles: contributors, members y admins pueden leer data en OneLake. Simple pero poco fino.

B) Item-level y compute permissions: conceder acceso granular vía item permissions y seguridad a nivel compute (RLS en Warehouse, etc.).

C) OneLake Security ⭐: seguridad granular basada en roles en todos los compute engines de Fabric. Recomendado para setups modernos.

SSO vs Fixed identities

A) Single Sign-On (SSO): cada usuario accede con sus propias credenciales, con RLS/OLS por usuario real. Lo mejor para aplicar seguridad granular.

B) Fixed identity: todos los usuarios acceden con un único principal. Sin RLS por usuario (se aplica al principal). Más simple pero menos seguro.

Recomendación: SSO cuando necesitas seguridad granular; fixed identity para dashboards públicos o cuando los usuarios no están en el tenant.

OLS y RLS en Direct Lake

Object-level security (OLS) y row-level security (RLS) están completamente soportados en Direct Lake. Los modelos con RLS/OLS en OneLake Security funcionan de forma natural con las queries Direct Lake desde Power BI.

¿Qué son?

Las sensitivity labels son una clasificación de datos que aplica cifrado o restricciones de acceso. Se aplican a los items de OneLake igual que a los documentos.

Ejemplos de labels

Típicamente definidas a nivel tenant/organización: Public, Internal, Confidential, Highly Confidential, Restricted. O labels custom del negocio (según industria/compliance).

Propiedades

Las sensitivity labels aplican cifrado automático, restricciones de acceso basadas en la label, marcas de agua en documentos, y hacen que las políticas DLP sean conscientes de las labels.

Aplicar labels

En el Fabric portal: click en el item → Sensitivity label → seleccionar la label apropiada → guardar. O configurar auto-labeling a nivel workspace/tenant.

¿Qué es DLP?

Data Loss Prevention = políticas que detectan y previenen fugas de datos sensibles. Fabric se integra con las políticas DLP de Microsoft Purview.

Qué detectan las políticas DLP

• Subidas de datos sensibles a OneLake.
• Descargas de datos sensibles de OneLake.
• Compartición con destinatarios externos que no deberían.
• Copia de datos a ubicaciones no aprobadas.

Acciones posibles

Cuando una política DLP detecta una violación puede alertar al admin, bloquear la acción, notificar al usuario (con justificación) y registrar el evento para auditoría.

Casos de uso

• Detección de PII en subidas.
• Números de tarjeta de crédito en tablas.
• Datos de salud con compliance HIPAA.
• Datos financieros en dashboards públicos.

Setup

Las políticas DLP se configuran en el portal de compliance de Microsoft Purview, no en Fabric directamente. Fabric las aplica automáticamente cuando están activas.

¿Qué es?

El Secure tab del OneLake catalog es la ubicación central para ver, monitorizar y configurar los security roles entre workspaces e items.

Qué muestra

Centraliza en un solo sitio:

1. Vista de los workspace roles y permisos — para auditar el acceso a workspaces y datos.
2. Vista de los OneLake security roles entre workspaces y tipos de item — los admins pueden crear, editar o borrar OneLake security roles desde una única ubicación.

Filtros

El Secure tab muestra los items relevantes, incluidos los workspaces a los que tienes acceso. Se requieren los roles Admin y Member en un workspace para ver los datos de ese workspace. Los Contributors o Viewers de un workspace solo ven la info de su propio acceso.

Página View security roles

En la página View security roles puedes ver todos los OneLake security roles de los workspaces seleccionados. Cada fila es un role dentro de un item de Fabric.

Detalles que puedes ver: nombre del item, nombre del role, tipo de role (solo OneLake security soportado), permiso concedido, ubicación (workspace) y data owner.

Operaciones desde el Secure tab

Puedes ver los roles existentes, editarlos, borrarlos, crear nuevos y duplicar roles existentes. Todo desde una única página centralizada — muy útil para admins.

Caso de uso de auditoría

Perfecto para auditar: "¿Qué OneLake security roles existen en producción?", "¿Quién tiene acceso a la tabla X?", "¿Este role sigue siendo necesario?". Sin tener que ir workspace por workspace.

Cuándo aplica

Cuando OneLake Security no cubre tu item (Warehouse, SQL DB, KQL DB, Semantic Models), usas la seguridad a nivel compute que ya vimos:

Warehouse y SQL Database: seguridad T-SQL — OLS (GRANT/DENY sobre objects), RLS (security policies), CLS (DENY sobre columnas) y DDM (dynamic data masking).

Eventhouse (KQL): política de row-level security (funciones KQL) y política de restricted view access.

Semantic Models (Power BI): RLS con filtros DAX y OLS con TMDL/Tabular Editor.

Layering

Muy común: seguridad por capas. El workspace role controla quién puede ver el item, el item permission controla qué operaciones puede hacer, y la seguridad a nivel compute controla qué data concreta ve. Todo funciona junto.

El desafío

Data en un workspace, usuarios en otro. ¿Cómo conceder acceso sin comprometer la seguridad?

Approaches

A) Compartir items: compartir el warehouse/lakehouse con usuarios de otros workspaces, concediendo Read/ReadData según necesidad, sin dar workspace role.

B) OneLake shortcuts: crear shortcuts desde el workspace consumidor al workspace productor. El usuario consume vía shortcut sin acceso directo al origen.

C) Workspace membership: añadir usuarios a varios workspaces con los roles apropiados.

Best practice del escenario oficial

Escenario del Learn oficial: arquitectura medallion con 3 workspaces (bronze, silver, gold).

Setup:

• Data engineers con rol Contributor en los 3 workspaces (bronze, silver, gold).
• Usuarios de negocio con acceso restringido solo a la capa gold, vía item permissions en el semantic model y RLS en el semantic model o en OneLake Security roles.

Resultado: los data engineers pueden ingestar y transformar data entre capas, y los usuarios de negocio solo ven la capa gold con las filas filtradas por RLS.

El principio

Least privilege access = principio fundamental de seguridad. Restringir los permisos de los usuarios solo a lo necesario para sus tareas. Para OneLake: no sobre-aprovisionar usuarios, conceder permisos al nivel apropiado y reducir riesgo.

Best practices oficiales

1. Comparte items individuales si los usuarios solo necesitan uno — usa la feature Share para dar acceso a un solo item, y asigna un workspace role solo si necesitan ver TODOS los items.

2. Usa OneLake Security para restringir folders/tables — para data sensible, RLS o CLS aseguran que las filas o columnas queden ocultas.

3. Elige el mecanismo apropiado para las escrituras — workspace roles (Admin/Member/Contributor) para escritura general, y OneLake Security ReadWrite para escritura granular a folders/tables concretos.

4. Gestionar el acceso a datos requiere roles Admin o Member — para compartir items o configurar OneLake Security roles.

5. Permiso SubscribeOneLakeEvents — los usuarios lo necesitan para suscribirse a eventos de un item de Fabric. Admin/Member/Contributor lo tienen por defecto; para el Viewer hay que añadirlo explícitamente si hace falta.

Revisiones periódicas

Best practice: revisar los roles y las membresías con regularidad — revisiones de seguridad trimestrales, eliminar ex-empleados, verificar que los accesos siguen siendo necesarios y borrar los roles sin uso.

• Trampa 1: "Control plane y data plane son lo mismo" ❌ Distintos. Control plane = qué puedes HACER con el item. Data plane = qué DATA puedes ver/cambiar. Concepto fundamental.
• Trampa 2: "El workspace role Viewer permite acceder a OneLake" ❌ El Viewer NO tiene acceso OneLake por defecto. Admin/Member/Contributor sí, Viewer no. Necesita un OneLake security role específico o un item permission.
• Trampa 3: "El permiso Read da acceso a la data" ❌ Read solo permite CONECTAR. Necesitas también ReadData o ReadAll para ver data.
• Trampa 4: "ReadAll y ReadData son lo mismo" ❌ ReadData = data vía SQL. ReadAll = ficheros Parquet raw en OneLake. Distintos.
• Trampa 5: "Compartir un item da acceso al workspace" ❌ El sharing da acceso solo al item concreto, no al workspace.
• Trampa 6: "OneLake security afecta a los workspace admins" ❌ NO afecta a Admin, Member ni Contributor. Solo a Viewers y a usuarios con permiso Read. Es un grant model, no un deny.
• Trampa 7: "OneLake security puede DENEGAR acceso" ❌ Es solo grant model. No puede quitar acceso concedido en otro sitio.
• Trampa 8: "OneLake security funciona en el Warehouse" ❌ Actualmente NO. El Warehouse usa seguridad T-SQL (RLS/CLS/OLS/DDM). OneLake Security aplica a Lakehouse y Mirrored DBs.
• Trampa 9: "El DefaultReader role no importa" ❌ Muy importante. Concede acceso al lakehouse a los usuarios con ReadAll. Bórralo o modifícalo si quieres restringir.
• Trampa 10: "ReadWrite permite RLS y CLS" ❌ NO. RLS y CLS solo están disponibles en roles con permiso Read. Con ReadWrite no puedes aplicar RLS/CLS.
• Trampa 11: "Las sensitivity labels no aplican fuera de Fabric" ❌ Las labels persisten al exportar (Excel, etc.). El cifrado y las restricciones se mantienen.
• Trampa 12: "Puedo compartir un report de Power BI y el usuario lo ve todo" ❌ Necesita también permisos de datos (OneLake o compute-level). El Read del report solo da metadata + vista del report.
• Trampa 13: "El Viewer puede ejecutar notebooks" ❌ NO. Solo Admin/Member/Contributor pueden ejecutar notebooks. El Viewer puede monitorizar runs pero no iniciarlos.
• Trampa 14: "Los cambios en los OneLake security roles requieren refresh" ❌ Surten efecto en cuanto se guardan. Sin refresh manual.
• Trampa 15: "Direct Lake ignora el RLS" ❌ Respeta el RLS de OneLake Security. Si hay RLS en el modelo SQL, hace fallback a DirectQuery.
• Trampa 16: "Puedo usar single sign-on siempre" ❌ El SSO requiere que los usuarios tengan acceso al data source. Para usuarios externos o casos donde no aplique, usa fixed identity.
• Trampa 17: "Los item permissions y los workspace roles son redundantes" ❌ Son complementarios. Los item permissions dan acceso granular sin workspace role; los workspace roles dan acceso amplio.
• Trampa 18: "OneLake Security siempre está habilitada por defecto" ❌ Debes crear los roles explícitamente. El DefaultReader existe, pero puedes borrarlo o modificarlo.
• Trampa 19: "El enforcement cross-engine es opcional" ✅ Al contrario — es su fortaleza. Automático en SQL, Spark, KQL y Power BI.
• Trampa 20: "Solo los admins pueden ver el Secure tab" ❌ Todos ven el Secure tab, pero Admin/Member ven los datos del workspace y Contributor/Viewer solo ven la info de su propio acceso.

Los 4 workspace roles

Acceso a OneLake por role

Item permissions (Warehouse/SQL DB/Lakehouse)

Control plane vs Data plane

Componentes de un OneLake Security role

Soporte de RLS/CLS/OLS en OneLake Security

Items con soporte de OneLake Security

Mecanismos de seguridad por engine

DefaultReader role

Opciones de seguridad en Direct Lake

• Módulo Learn: secure-data-access-in-fabric
• Security overview: security-overview
• Permission model: permission-model
• Roles in workspaces: roles-workspaces
• End-to-end security scenario: security-scenario
• Data security in OneLake: get-started-security
• Create and manage OneLake security roles: create-manage-roles
• Table, column, and row-level security: table-column-row-security
• Read data secured with OneLake security: read-secured-data
• Data access control model: data-access-control-model
• SQL analytics endpoint OneLake security: sql-analytics-endpoint-onelake-security
• Best practices OneLake security: best-practices-secure-data-in-onelake
• Lakehouse sharing: lakehouse-sharing
• Secure your Fabric data (Secure tab): secure-your-data
• Direct Lake security integration: direct-lake-security-integration
• Authorization in SQL database: database/sql/authorization
• Share Fabric items: share-items
• Give users access to workspaces: give-access-workspaces
• Troubleshoot restricted access: troubleshoot-restricted-access
• Row-level security (Power BI service): service-admin-row-level-security
• Column-level security (Warehouse): column-level-security
• Object-level security: service-admin-object-level-security