Microsoft llevó a disponibilidad general la seguridad de OneLake y sus data access roles, con control a nivel de carpeta, tabla, fila y columna.
Microsoft amplió la seguridad a nuevos escenarios, mejoró la integración con Eventhouse, Graph y endpoints SQL, simplificó CLS y añadió APIs de seguridad para automatizar gobierno.
Cuando todos los datos convergen en OneLake, “quién puede entrar al workspace” deja de ser una política de seguridad suficiente.
Microsoft Fabric simplifica arquitectura al ofrecer un único lago lógico para datos analíticos. Lakehouses, warehouses, notebooks, Power BI, Data Engineering, Data Science, Real-Time Intelligence y otras cargas pueden trabajar sobre una base común. Esa unificación reduce copias y fricción, pero obliga a gobernar el acceso de forma más precisa.
La pregunta ya no es únicamente si un usuario puede entrar en un workspace. Hay que decidir qué tablas necesita, qué carpetas puede leer, qué filas debe ver según país o unidad de negocio, qué columnas sensibles deben ocultarse y qué ocurre cuando consume esos datos desde Spark, SQL, Power BI o herramientas externas autorizadas.
Workspace security y OneLake security resuelven problemas distintos.
Los roles de workspace de Fabric controlan qué puede hacer una identidad dentro de un espacio de trabajo: administrar, crear elementos, modificar contenido, compartir o consumir. Son esenciales para gobernar la plataforma, pero pueden ser demasiado amplios cuando una persona necesita consultar solo una parte de los datos.
OneLake Security opera sobre el plano de datos. Sus roles permiten conceder acceso a tablas, carpetas, esquemas, filas y columnas concretas dentro de elementos compatibles. Esa granularidad permite separar la capacidad de usar Fabric de la capacidad de leer determinados datos.
La distinción es crítica porque los roles de seguridad de OneLake utilizan un modelo de concesión. No sirven para quitar acceso que una identidad ya ha recibido por otro mecanismo más amplio. Por eso la arquitectura debe empezar reduciendo permisos excesivos en workspace e item antes de esperar que RLS o CLS solucionen el problema.
La seguridad granular funciona bien cuando la identidad no llega con un acceso superior por otro camino.
OneLake puede proteger desde una carpeta completa hasta una columna concreta.
La granularidad permite construir modelos mucho más próximos a la realidad empresarial. No todas las personas que necesitan consultar una tabla deberían ver todas sus filas o todos sus atributos.
Object-level security
Permite conceder acceso a tablas, esquemas o carpetas específicas en lugar de entregar todo el item. Es útil para separar dominios funcionales, datasets o zonas de datos dentro de un mismo activo.
Row-level security
Filtra registros según reglas definidas. Puede utilizarse para que un usuario vea solo su país, región, sociedad o perímetro cuando la lógica de datos lo permite.
Column-level security
Permite ocultar columnas sensibles como salario, margen, identificadores personales o determinados atributos cuando el usuario necesita la tabla pero no todos sus campos.
Read vs ReadWrite
RLS y CLS se aplican sobre roles de lectura. Si un rol concede ReadWrite, esas opciones granulares no están disponibles porque la identidad necesita capacidad de modificación sobre el ámbito concedido.
La arquitectura correcta empieza por el mínimo acceso posible y añade permisos; no por conceder mucho e intentar recortarlo después.
El modelo de OneLake es de grant. Si otra asignación concede acceso superior, el rol granular no actúa como una regla de denegación. Esa lógica debe estar presente en cualquier diseño de grupos, roles y sharing.
El mismo lago puede servir a distintas áreas sin convertir cada workspace en una copia física diferente del dato.
Una única tabla puede necesitar tres experiencias de acceso distintas.
Imagina una tabla de ventas global con sociedad, país, cliente, pedido, vendedor, coste, margen, importe y determinados datos personales. El equipo comercial de España necesita consultar pedidos y clientes españoles. Dirección financiera necesita la información completa de todas las sociedades, incluidos costes y margen. Un partner externo puede necesitar acceso solo a sus operaciones.
Duplicar la tabla tres veces resolvería el problema a corto plazo, pero introduce sincronización, coste, lineage adicional y riesgo de divergencia. Un diseño granular permite que el dato permanezca en una ubicación común y que cada rol reciba solo el ámbito necesario.
La ganancia no es únicamente de seguridad. También reduce copias, simplifica gobierno y ayuda a que Power BI, notebooks y otros motores trabajen sobre una fuente compartida con reglas consistentes.
RLS y CLS no protegen a usuarios que ya tienen acceso amplio como Admin, Member o Contributor del workspace.
Microsoft documenta una limitación que debería estar en cualquier revisión de seguridad de Fabric: los controles granulares de OneLake no restringen a identidades que tienen acceso suficiente a través de los roles altos del workspace. Es lógico desde el modelo de permisos, pero puede sorprender a equipos que esperan que una regla de fila se comporte como una denegación global.
Por eso la enfoque de mínimo privilegio empieza por reducir quién necesita ser Admin, Member o Contributor. Los consumidores de datos deberían utilizar Viewer, permisos de item o roles de OneLake cuando su función no requiere crear o modificar contenido. La seguridad granular funciona mejor sobre una base de privilegios ya controlada.
Admin / Member
Gestionan y crean contenido y pueden administrar seguridad según el rol. No son perfiles apropiados para un consumidor que solo necesita leer una porción de datos.
Contributor
Puede crear y escribir contenido y mantiene acceso al plano de datos suficiente para que los roles granulares no actúen como límite efectivo.
Viewer
Es el rol natural para consumo cuando el acceso real al dato se concede después mediante OneLake Security o permisos específicos.
Grupos de Entra
Gestionar miembros mediante grupos de seguridad reduce asignaciones individuales y ayuda a mantener un modelo auditable y escalable.
La regla de seguridad debe acompañar al dato, no depender de la herramienta desde la que se consulta.
Una de las ventajas estratégicas de OneLake Security es que Microsoft plantea la seguridad granular como parte del plano de datos y no solo de un motor concreto. Los motores de Fabric autorizados pueden aplicar RLS y CLS al consultar la información, de manera que el consumidor vea únicamente las filas y columnas permitidas.
Esto importa porque los datos pueden consultarse desde Spark notebooks, SQL analytics endpoints, semantic models y determinados motores externos autorizados. El comportamiento exacto puede variar entre motores —por ejemplo, cómo responde un SELECT * ante columnas ocultas—, pero la política de acceso se mantiene vinculada al dato.
Una arquitectura madura debe probar todos los caminos de acceso reales. No basta con validar que Power BI oculta una columna si el mismo usuario puede leer el fichero subyacente por otro motor o mediante un permiso más amplio.
La seguridad debe sobrevivir al cambio de herramienta de consumo.
Compartir datos sin copiarlos no elimina el problema de permisos: lo hace más importante.
Los shortcuts permiten que Fabric acceda a datos sin duplicarlos físicamente. Ese modelo es muy potente para arquitectura de dominios, multi-cloud y distribución entre equipos, pero obliga a entender dónde se evalúa la autorización y con qué identidad se consulta el origen.
Microsoft ha reforzado durante 2026 los patrones de distribución segura con OneLake Security y shortcuts. Los passthrough shortcuts pueden respetar permisos del destino, mientras los delegated shortcuts —todavía en preview— permiten utilizar una identidad intermedia para delegar acceso, incluso entre tenants en determinados escenarios. La simplicidad visual del shortcut no debe ocultar la complejidad real de identidad y permisos.
Source-managed access
El origen conserva autoridad sobre quién puede leer. Es útil cuando el equipo propietario del dato debe mantener el control y los consumidores no deberían heredar permisos por pertenecer a otro workspace.
Delegated identity
Permite usar una identidad específica asociada al shortcut para mediar el acceso. Es potente para escalabilidad, pero requiere gobierno claro y sigue sujeto a capacidades preview en algunos escenarios.
Zero-copy no significa zero-governance.
Cuantas menos copias físicas existen, más importante es entender qué identidad atraviesa el acceso, qué permisos se evalúan y quién mantiene la autoridad sobre el dato original.
La IA no convierte datos sensibles en datos públicos. Solo aumenta la velocidad con la que pueden consultarse.
La seguridad del dato se vuelve todavía más crítica cuando la interfaz deja de ser un informe y pasa a ser una conversación.
Un usuario puede no saber qué tablas existen, pero sí puede preguntarle a un agente “dime qué clientes tienen peor margen” o “muéstrame salarios de mi región”. La interfaz conversacional reduce barreras de consulta y, por tanto, aumenta la importancia de que el modelo de permisos sea correcto en la capa de datos.
Microsoft está integrando sensibilidad, gobierno y contexto de datos cada vez más cerca de experiencias de IA. Fabric, Purview y los agentes deben entenderse como partes de una misma arquitectura: Fabric almacena y sirve datos; OneLake Security define acceso; Purview clasifica y aporta contexto de sensibilidad; la IA consume dentro de esos límites.
La empresa que prepara Fabric solo para dashboards tendrá que rehacer parte del gobierno cuando lleguen agentes. La empresa que diseña desde ahora permisos, grupos, sensibilidad y ownership estará mucho mejor preparada para ampliar el consumo a IA sin multiplicar excepciones.
Permitir acceso y entender sensibilidad son dos controles distintos que deben trabajar juntos.
OneLake Security responde principalmente a “quién puede leer o escribir qué”. Microsoft Purview añade clasificación, sensibilidad, descubrimiento, lineage y gobierno que ayudan a responder “qué tipo de dato es este, quién es responsable y qué políticas deberían aplicarse”. Ninguna de las dos capas sustituye a la otra.
OneLake Security
Control de acceso al plano de datos: tablas, carpetas, filas, columnas, lectura y escritura según item compatible y tipo de rol.
Microsoft Purview
Clasificación, etiquetas de sensibilidad, catálogo, lineage, protección y contexto de gobierno a escala del patrimonio de datos.
Una etiqueta “Confidencial” no arregla automáticamente un rol mal asignado.
La clasificación ayuda a definir políticas y contexto. El control efectivo de acceso debe seguir configurado y probado. La arquitectura madura conecta ambas cosas para que sensibilidad y permisos no vivan en mundos separados.
Un modelo de seguridad escalable empieza por identidades y dominios, no por permisos usuario a usuario.
Asignar personas una a una funciona durante una prueba. En una plataforma empresarial termina creando accesos huérfanos, excepciones y auditorías imposibles. Conviene diseñar grupos, roles y ownership alrededor de dominios y funciones de negocio.
Microsoft Entra groups
Utiliza grupos para representar funciones como Finanzas EMEA, Analistas Comerciales o Data Science. La entrada y salida de personas se gestiona en identidad, no reconfigurando decenas de items.
Ownership claro
Cada dominio de datos necesita propietarios que conozcan sensibilidad, reglas de negocio y consumidores legítimos. Seguridad central no puede decidir sola qué filas necesita cada área.
Roles mínimos de workspace
Admin, Member y Contributor deben reservarse a quien realmente crea o administra. Consumidores deberían entrar por rutas de lectura controladas.
Roles por necesidad real
Concede tablas, carpetas, filas y columnas a los grupos que las necesitan. Evita roles gigantes “corporativos” que terminan replicando acceso total.
Cuando Fabric crece, la seguridad no puede depender de configurar cada role manualmente.
Las mejoras de 2026 incluyen APIs de seguridad de OneLake que permiten integrar la gestión de permisos con procesos de plataforma. Esto abre la puerta a patrones donde el alta de un dominio, workspace o producto de datos incluya también roles, grupos y controles estandarizados.
La automatización debe reforzar políticas, no reproducir desorden más rápido. Antes de crear scripts o pipelines conviene definir convenciones de nombres, grupos autorizados, tipos de roles, mínimos de workspace y proceso de excepción.
En organizaciones grandes, esta aproximación convierte seguridad en una capacidad de plataforma: los equipos de datos reciben una experiencia rápida para crear productos sin tener que rediseñar permisos desde cero cada vez.
APIs, grupos, estándares y ownership permiten crecer sin convertir permisos en una tarea artesanal.
Controlar quién puede leer no basta si no controlas desde dónde puede llegar el tráfico.
La seguridad de datos responde a qué identidad puede acceder a qué contenido. La seguridad de red responde a qué rutas de conectividad están permitidas para alcanzar OneLake. Ambas capas son complementarias. Una organización puede tener permisos correctos y seguir necesitando restringir el acceso a través de endpoints públicos, redes corporativas o servicios de Azure específicos.
Microsoft ha ido ampliando durante 2026 los controles de red alrededor de OneLake. Entre ellos se encuentran reglas que permiten autorizar instancias concretas de recursos de Azure para acceder a OneLake mediante el endpoint público mientras Fabric sigue aplicando los permisos del plano de datos. Esa combinación evita tratar conectividad y autorización como sustitutos.
El principio es sencillo: una aplicación puede tener ruta de red hacia OneLake y seguir sin tener permiso para leer un dataset concreto. Del mismo modo, una identidad autorizada puede no alcanzar el servicio si la política de red no permite ese origen. El diseño robusto exige que ambas condiciones se cumplan.
Red
Decide qué recursos, redes o rutas pueden alcanzar OneLake.
Identidad
Determina quién o qué servicio está intentando acceder.
Dato
Define qué tablas, carpetas, filas o columnas puede consumir esa identidad.
Resultado
Solo cuando conectividad y permisos coinciden se produce el acceso esperado.
Service principals, workspace identities y agentes necesitan el mismo rigor que los usuarios humanos.
En una plataforma de datos real, muchas consultas y escrituras no las realiza una persona. Pipelines, notebooks programados, aplicaciones, integraciones, shortcuts delegados y futuras experiencias agentic operan mediante identidades de servicio. El riesgo es concederles permisos excesivos porque “la aplicación lo necesita” y mantenerlos durante años sin revisión.
El mismo principio de mínimo privilegio debe aplicarse a identidades no humanas: conocer su propietario, finalidad, datos necesarios, periodo de uso y mecanismo de revocación. Un service principal que accede a todo OneLake puede tener un impacto mucho mayor que un usuario individual si sus credenciales o permisos se utilizan de forma incorrecta.
Propietario definido
Toda identidad técnica necesita un equipo responsable que pueda justificar por qué existe, qué datos utiliza y qué ocurre si deja de funcionar.
Permiso acotado
Una integración de lectura no debería recibir escritura. Un agente que consulta un dominio no debería heredar todo el workspace por comodidad.
Trazabilidad
Los accesos automáticos deben poder distinguirse de actividad humana para investigar errores, abuso o consumos inesperados.
Recertificación
Las identidades técnicas también cambian de función. Revisar permisos periódicamente evita que un proceso antiguo conserve acceso a datos que ya no necesita.
Fabric también incorpora opciones de customer-managed keys para organizaciones con requisitos específicos de gestión de claves.
La seguridad de acceso decide quién puede leer. La gestión de claves responde a cómo se protege el dato almacenado.
Microsoft Fabric cifra los datos y proporciona controles de seguridad de plataforma. Algunas organizaciones, por requisitos regulatorios, contractuales o internos, necesitan además mayor control sobre la gestión de claves. Fabric ofrece customer-managed keys en escenarios compatibles para integrar esa responsabilidad dentro del modelo de seguridad corporativo.
No conviene mezclar las dos conversaciones. Una CMK no impide que un usuario autorizado vea una tabla que no debería haber recibido. Y una política RLS no sustituye las decisiones sobre cifrado, residencia, red o custodia de claves. El diseño completo suma capas que responden a amenazas distintas.
Para un CIO o CISO, esta separación facilita priorizar: primero clasificar datos y casos de uso, después decidir identidades y permisos, y finalmente aplicar controles adicionales de red, cifrado y operación según riesgo y requisitos.
La seguridad no termina cuando el role se guarda: hay que comprobar qué ve realmente cada identidad.
Un diseño puede parecer correcto en la pantalla de administración y fallar por una pertenencia a otro grupo, un permiso heredado, un rol de workspace demasiado alto o un shortcut que utiliza otra identidad. Por eso conviene validar permisos efectivos con usuarios de prueba representativos antes de abrir el acceso a producción.
La prueba debe intentar tanto lo permitido como lo prohibido: confirmar que Finanzas ve margen, comprobar que Comercial no lo ve, validar que un partner solo accede a sus registros y demostrar que ninguna ruta alternativa por SQL, Spark o sharing permite saltarse esas restricciones. Una prueba negativa bien diseñada vale más que revisar únicamente la configuración.
Usuario permitido
Debe poder realizar exactamente las consultas necesarias para su función, sin errores artificiales que dificulten el trabajo diario.
Usuario restringido
Debe fallar de forma consistente cuando intenta leer otra sociedad, una columna sensible o un item que no forma parte de su ámbito.
Prueba también los caminos que nadie utiliza “normalmente”.
Los incidentes no siguen el camino ideal. Si existe acceso mediante endpoint SQL, notebook, shortcut o herramienta autorizada de terceros, esa superficie debe formar parte de la validación aunque el usuario habitual consuma los datos desde Power BI.
Seis formas de tener OneLake Security y seguir exponiendo demasiado dato.
Dar Contributor a consumidores
Un usuario que solo necesita leer no debería recibir un rol pensado para crear y modificar contenido. El acceso amplio inutiliza parte del valor del control granular.
Confundir grant con deny
Ocultar una columna en un rol no elimina un acceso concedido por otro rol o mecanismo. Debes revisar el conjunto completo de permisos efectivos.
Crear roles usuario a usuario
Funciona durante el piloto y fracasa cuando cambian equipos. Los grupos de Entra reducen deuda operativa y facilitan auditoría.
Probar solo Power BI
Si el mismo dato se consulta por SQL o Spark, esos caminos deben formar parte de las pruebas. El control efectivo se valida contra todas las superficies reales.
Olvidar shortcuts
Compartir sin copiar es útil, pero debes comprender qué identidad se utiliza y dónde se evalúan los permisos del dato origen.
Esperar a que llegue la IA
Agentes y experiencias conversacionales amplían el consumo. Corregir permisos después de desplegar IA es mucho más difícil que diseñarlos bien desde el lakehouse.
Doce comprobaciones antes de considerar gobernado el acceso a OneLake.
Revisar quién necesita realmente Admin, Member o Contributor.
Sustituir asignaciones individuales por grupos mantenibles y auditables.
Comprobar que ningún rol por defecto concede acceso más amplio del que después intentamos restringir.
Aplicar OLS donde no sea necesario exponer todo el item.
Definir y probar filtros de filas sobre los casos que necesitan separación por ámbito.
Ocultar columnas sensibles solo cuando el usuario ya tiene una ruta de acceso coherente.
Comprobar permisos efectivos si una persona pertenece a varios grupos o roles.
Validar Power BI, SQL, Spark y motores externos utilizados en producción.
Documentar identidad, origen, autorización y ownership en cada patrón de acceso sin copia.
Conectar clasificación y etiquetas de Purview con decisiones reales de acceso.
Revisar service principals, workspace identities, procesos automatizados y futuras identidades de agentes.
Los permisos deben revisarse periódicamente; un acceso correcto hoy puede ser innecesario dentro de seis meses.
Lo que conviene tener claro sobre OneLake Security en Microsoft Fabric.
¿OneLake Security está disponible de forma general?
Sí. Microsoft llevó OneLake Security y sus data access roles a disponibilidad general en mayo de 2026 y posteriormente amplió capacidades durante julio.
¿Puede restringir filas y columnas?
Sí. OneLake Security admite RLS y CLS sobre tablas compatibles, además de controles a nivel de tabla y carpeta.
¿RLS bloquea a un Contributor del workspace?
No debe asumirse. Microsoft indica que los controles granulares no restringen a usuarios con roles de workspace que ya les conceden acceso amplio, como Admin, Member o Contributor.
¿Los roles de OneLake permiten deny?
El modelo actual es de grant. Una restricción de un rol no elimina acceso concedido por otro rol o modelo de permisos, por lo que hay que revisar permisos efectivos completos.
¿Se puede usar con grupos de Microsoft Entra?
Sí. Los roles admiten usuarios, grupos e identidades no humanas compatibles. Los grupos son el enfoque más escalable para gobierno empresarial.
¿RLS y CLS funcionan con ReadWrite?
No. Microsoft indica que las opciones de seguridad a nivel de fila y columna se aplican a roles de lectura; los roles ReadWrite no ofrecen esas opciones granulares.
¿La seguridad se aplica también desde Spark o SQL?
Los motores de Fabric autorizados aplican las reglas de OneLake, aunque el comportamiento concreto de consultas puede variar según el motor. Conviene validar cada ruta utilizada.
¿OneLake Security sustituye a Purview?
No. OneLake Security controla acceso al dato; Purview aporta clasificación, sensibilidad, gobierno, lineage y políticas complementarias.
¿Qué ocurre con los shortcuts?
La seguridad depende del tipo de shortcut y de la identidad utilizada. Los patrones passthrough y delegated permiten modelos diferentes y deben diseñarse conscientemente.
¿Cuál es el primer paso para revisar seguridad?
Inventariar roles de workspace, grupos de Entra, permisos directos, sharing, shortcuts y rutas de acceso antes de empezar a añadir reglas RLS o CLS.
Fabric necesita gobierno del dato desde el principio, no cuando el primer informe expone demasiado.
Ayesa Digital combina capacidades en Microsoft Fabric, Power BI, Azure, Microsoft Purview, seguridad, datos e IA. Esa cobertura permite diseñar OneLake como plataforma empresarial: dominios, identidades, accesos, ownership, sensibilidad, consumo y evolución hacia agentes.
Una revisión útil no empieza creando más roles. Empieza identificando quién tiene hoy acceso, por qué camino lo recibe, qué datos son sensibles y qué casos de uso requieren granularidad. Después se diseña el modelo objetivo y se prueba sobre todos los motores relevantes.
El objetivo es conseguir que Fabric sea más fácil de consumir sin que eso signifique más fácil de sobreexponer. Esa disciplina será todavía más importante a medida que agentes y experiencias de IA consulten OneLake de forma natural.
Assessment de permisos
Workspace roles, grupos, sharing, accesos directos, service principals y shortcuts.
Diseño granular
OLS, RLS, CLS, roles de lectura y ownership por dominio.
Fabric + Purview
Sensibilidad, catálogo, lineage y permisos trabajando sobre un modelo común.
Preparación para IA
Identidades, agentes, permisos y consumo seguro de datos empresariales.
Microsoft Fabric
Plataforma unificada para ingeniería, analítica, Power BI, ciencia de datos y datos empresariales sobre OneLake.
Microsoft Purview
Clasificación, sensibilidad, catálogo, lineage, protección y gobierno para datos e IA.
Microsoft Fabric + Dynamics
Cómo conectar Finance, Business Central y Fabric para analítica y dato empresarial sin perder gobierno.
Microsoft Learn · OneLake Security
Documentación oficial del modelo de seguridad, roles, RLS, CLS y acceso al plano de datos de OneLake.
¿Sabes qué usuarios pueden llegar hoy a datos sensibles de OneLake y por qué camino reciben ese acceso?
Podemos revisar roles de workspace, identidades, sharing, shortcuts, RLS, CLS y Purview para construir un modelo de acceso granular preparado para crecer con Fabric, Power BI y agentes de IA.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)