Los Dataset publicados se pueden configurar con seguridad de datos mediante seguridad a nivel de filas (RLS) (para tablas) o seguridad a nivel de objetos (OLS) (para tablas y columnas). El objetivo de la seguridad de los datos es garantizar que los usuarios solo vean y usen los datos para los que tienen permiso, tanto en Report publicados como al crear sus propias soluciones de datos de autoservicio. Para ello, a los usuarios se les asignan roles con reglas de RLS u OLS, que aplican FILTER (RLS) o restringen (OLS) las consultas generadas por Report y herramientas de cliente como Power BI Desktop o Excel.
¿POR QUÉ CONFIGURAR LA SEGURIDAD A NIVEL DE FILAS O LA SEGURIDAD A NIVEL DE OBJETOS?
Configurar RLS u OLS puede ser beneficioso para su modelo y sus Reports:
Reduce el riesgo y mejora la gobernanza, garantizando que los usuarios solo vean los datos a los que tienen acceso.
Configura RLS dinámico con tablas centrales de roles para mantener la consistencia y facilitar el mantenimiento.
Mantén un control granular sobre qué datos y objetos se pueden consultar.
¿Cómo funciona?
La seguridad de datos funciona a nivel de modelo. Se configura siguiendo los pasos que se indican a continuación:
1. Crear roles:
Los roles son grupos de usuarios que comparten los mismos permisos o la misma lógica de seguridad de datos. En este caso, los usuarios se identifican por su correo electrónico, o por el correo electrónico de un grupo de seguridad de Azure AD. Ejemplos de roles:
Usuarios de la misma región, equipo o departamento (EMEA, UA Sales Team).
Usuarios con el mismo rol, función o nivel de autorización de acceso (Key Account Managers, SC Clearance).
Grupos definidos por otra lógica de negocio o por reglas arbitrarias (Externals, Build Users).
Figura 1: En Tabular Editor, los roles son uno de los tipos de objetos de nivel superior (como tablas, relaciones, etc.).
Important
Después de crear un nuevo rol en Tabular Editor, primero debe establecer la propiedad Model Permission en Read.
2. Especificar reglas:
Las reglas se aplican para cada rol a uno o varios objetos, en función del tipo de seguridad:
Permisos de tabla para RLS: Expresiones de tabla DAX: devuelven cada fila que evalúa como True. Estos permisos atraviesan relaciones; el diseño del modelo es clave para definir buenas reglas de RLS.
Figura 2: En Tabular Editor, los permisos de tabla para RLS son visibles bajo el rol. Se pueden crear nuevos permisos de tabla haciendo clic con el botón derecho en un rol y seleccionando "Agregar partición de tabla..."Figura 3: El DAX del permiso de tabla se muestra en el Editor de expresiones al seleccionar un permiso de tabla.
Permisos de objeto de OLS: Estos permisos se aplican a los objetos principales, así como a todos los dependientes aguas abajo.
Read (Puede ver / consultar)
None (No puede ver / consultar)
Default (No hay ninguna directiva configurada; equivale a Read)
Figura 4: En Tabular Editor, los permisos de objeto están disponibles en la ventana "Propiedades", en el encabezado "Traducciones, Perspectivas, Seguridad".
3. Asignar usuarios a los roles:
Una vez configurado el Dataset, debes asignar a los usuarios a sus roles correspondientes.
Puedes asignar y quitar usuarios/grupos de los roles en Tabular Editor de la siguiente manera:
Haz clic con el botón derecho en el rol y selecciona Editar miembros...
Figura 7: Los usuarios pueden asignarse a los roles haciendo clic con el botón derecho en un rol y seleccionando 'Editar miembros...'.
Haz clic en el botón desplegable de 'Agregar miembro de Windows AD' y elige Miembro de Azure AD:
Figura 8: En modelos AAS/SSAS, los usuarios pueden agregarse mediante el cuadro de diálogo 'Editar miembros...'.
Especifica la identidad del usuario de Azure AD (normalmente, el correo electrónico del usuario) como la propiedad Nombre del miembro.
Haz clic en Aceptar.
Guarda el modelo.
Important
Si tu organización usa Active Directory local con SQL Server Analysis Services, tendrás que usar la opción Miembro de Windows AD en lugar de Miembro de Azure AD.
Note
Se recomienda gestionar la seguridad de los datos y el acceso con grupos de Azure Active Directory. Se prefiere este enfoque, ya que puedes centralizar la administración de la seguridad y la segmentación de usuarios.
4. Conceder a los usuarios acceso al Dataset:
Power BI: Se debe conceder a los usuarios acceso al Dataset según el escenario de uso.
App Audience: Los usuarios o sus grupos de Azure AD se agregan a la App Audience adecuada.
Workspace Viewer: Los usuarios o sus grupos de Azure AD se agregan como visores del Workspace
Dataset Readers: A los usuarios o a sus grupos de Azure AD se les conceden permisos específicos del Dataset mediante un Dataset o un elemento dependiente (es decir. Report).
Warning
A los usuarios a los que se les asignen los roles de Workspace de Administrador, Miembro o Colaborador se les conceden permisos de escritura sobre un Dataset. Por lo tanto, la seguridad de datos, como RLS y OLS, no filtrará ni bloqueará datos para los usuarios con estos roles.
Si un usuario es Administrador, Miembro o Colaborador, podrá ver todos los datos.
En la medida de lo posible, procura distribuir y administrar los permisos mediante Power BI Apps.
5. Validación de seguridad:
RLS y OLS solo se pueden probar mediante suplantación una vez que se hayan agregado los grupos de usuarios y se les haya concedido acceso. Valida la seguridad mediante:
Figura 5: La forma más sencilla de probar la seguridad de datos es mediante suplantación con Tabular Editor. La opción "Suplantación" está disponible en cualquier función de consulta de datos (Consultas DAX, Pivot Grid, Vista previa de datos).
Note
Para validar la seguridad de datos mediante suplantación, deben cumplirse todas las condiciones siguientes:
Al usuario se le debe asignar un rol.
El usuario debe tener permisos de lectura sobre el Dataset.
El usuario debe tener permisos de compilación sobre el Dataset.
Figura 6: Una demostración de pruebas de RLS en Tabular Editor mediante suplantación. Se muestran pruebas con (A) Vista previa de datos, (B) Consultas DAX y (C) Pivot Grid.
Important
Las pruebas de seguridad de datos mediante suplantación con Tabular Editor 3 están limitadas a los Datasets alojados en el servicio Power BI Datasets. Las licencias de escritorio de TE3 no pueden aprovechar esta funcionalidad. Esto se debe a que los roles se asignan en el servicio de Power BI.
¿Qué aspecto tiene?
En función de cómo hayas diseñado y configurado la seguridad de datos, la experiencia puede variar para los usuarios.
A continuación se muestran ejemplos típicos de escenarios comunes de implementación de RLS y/o OLS en un Dataset
Haz clic en una pestaña para ver el ejemplo y obtener una explicación de cada uno:
Sin seguridad, cualquier persona con acceso al Dataset puede ver todos los datos.
La única restricción es si tienen acceso a los Report o a los Dataset.
En el ejemplo, tanto Jack como Janet pueden ver todos los datos.
Con RLS configurado, los datos se filtran para mostrar solo las filas que el usuario tiene permiso para ver. Esto se hace según los permisos de tabla configurados en el modelo para esa tabla y ese rol. Estos permisos de tabla son expresiones de tabla DAX configuradas para una tabla específica del modelo. Se devuelven las filas que se evalúan como True; las filas que devuelven False se filtran debido a RLS.
Los permisos de tabla más sencillos son estáticos:
// permiso de tabla para la tabla 'Regions' y el rol 'CTG'
'Regions'[Territory] = "Central Transit Gate"
En el ejemplo:
Jack solo puede ver las filas para las que 'Region'[Territory] = "Central Transit Gate", ya que pertenece al rol 'CTG'.
Los directivos, que tienen permiso para ver todos los datos, se agregan a un rol sin permisos de tabla.
Tommy, un usuario que puede acceder al Dataset pero no pertenece a ningún rol, no verá ningún dato. Todos los Visual y las consultas devolverán un «recuadro gris de la muerte».
Es necesario crear roles al usar la seguridad de datos, incluso cuando hay usuarios como los directivos, que tienen acceso a los datos sin restricciones.
Con RLS configurado, los datos se filtran para mostrar solo las filas que el usuario tiene permiso para ver.
Esto se hace según los permisos de tabla configurados en el modelo para esa tabla y ese rol.
Estos permisos de tabla son expresiones de tabla DAX configuradas para una tabla específica del modelo.
Se devuelven las filas que se evalúan como True; las filas que devuelven False se filtran debido a RLS.
El RLS dinámico se basa en las funciones USERPRINCIPALNAME() o USERNAME() para compararlas con los valores de una tabla de seguridad.
La tabla de seguridad devolverá entonces la lógica que aplica el filtro de tabla a esa u otra tabla del modelo.
A esto se le llama RLS dinámico porque el resultado cambiará en función del usuario, es decir, su USERPRINCIPALNAME().
A continuación se muestra un ejemplo de permiso de tabla de RLS dinámico:
// permiso de tabla para 'Regions' y el rol 'Territory Directors'.
// Obtener el usuario actual
VAR _CurrentUser =
SELECTCOLUMNS (
FILTER (
'Employees',
'Employees'[Employee Email] = USERPRINCIPALNAME ()
),
"@Name", 'Employees'[Employee Name]
)
RETURN
'Regions'[Territory Directors] IN _CurrentUser
El permiso de tabla anterior obtiene el alias de la columna Employee Name de la tabla 'Employees' y se aplica sin que exista una relación con la tabla 'Regions'.
El resultado para cualquier usuario agregado a este rol es que solo verá datos donde:
Su correo electrónico está en la columna 'Employees'[Employee Email]
Su alias en 'Employees'[Employee Name] coincide con uno en 'Regions'[Territory Directors]
En el ejemplo, cada director de territorio solo ve los territorios de los que es responsable:
Jack ve "Central Transit Gate" y "Io".
Janet ve "Arcadia III".
Elisa ve todos los datos, ya que el rol Execs no tiene ningún permiso de tabla configurado.
La RLS dinámica es la forma más común de proteger un Dataset empresarial. Normalmente requiere configurar y mantener una Tabla de seguridad central, utilizada en todos los Datasets empresariales.
Cuando se asigna un usuario a varios roles, cada uno con permisos de tabla diferentes, verá los datos permitidos por cualquiera de esos roles. Los usuarios verán datos cuando al menos una expresión DAX de permisos de tabla se evalúe como True para las filas de las tablas del modelo; se aplica el operador lógico OR.
Esto puede ser peligroso si no se espera; algunos desarrolladores pueden anticipar que se tome la intersección; es decir, mostrar solo las filas donde ambos permisos de tabla devuelven True. Esto solo ocurrirá si los permisos de tabla se configuran para varias tablas del modelo; dentro de un rol, se toma la intersección de todos los permisos de tabla del modelo.
En el ejemplo:
Jack está asignado a los roles 'CTG' y 'FTL'. Verá todas las filas en las que 'Products'[Type] = "FTL" O en las que 'Regions'[Territory] = "Central Transit Gate". Es probable que este no sea el comportamiento esperado; el desarrollador probablemente pretende obtener el resultado del rol 'CTG/FTL', que devuelve solo las filas donde ambas condiciones son verdaderas.
_Elijah tiene el rol 'FTL' y solo verá las filas en las que 'Products'[Type] = "FTL".
Abdullah tiene el rol 'CTG/FTL' y solo verá las filas en las que AMBAS 'Products'[Type] = "FTL" Y 'Regions'[Territory] = "Central Transit Gate".
Situaciones como esta ilustran la importancia de diseñar una configuración de seguridad de datos clara durante el diseño del modelo, asegurando que se alinee con las políticas de la organización y las prácticas existentes de seguridad de datos y administración de accesos.
Con OLS configurado como None, se impide que las consultas se evalúen; devuelven un error. Esta es una diferencia importante respecto a RLS; RLS filtra los datos, pero OLS impide la evaluación. Si el permiso de OLS se establece en Read, no hay ningún efecto. Esto se hace según el nivel de permiso de OLS de la columna o la tabla, y afecta a todos los elementos dependientes aguas abajo como las relaciones y las medidas.
En el ejemplo, la columna 'Territory Sales'[Cost] tiene un permiso de OLS de None para el rol 'Sales'. Esto se debe al siguiente requisito:
Los usuarios de 'Sales' pueden ver los datos de 'Sales', pero no los de Cost ni los de Margin.
Esto significa que un usuario que pertenezca al rol 'Sales', como Jack, no podrá ver:
Cualquier consulta o Visual que haga referencia directamente a la columna 'Territory Sales'[Cost]
Cualquier medida de DAX o elemento de cálculo que haga referencia directamente a la columna 'Territory Sales'[Cost], como [Margin %]
Cualquier medida de DAX o elemento de cálculo que haga referencia indirectamente (aguas abajo) a la columna 'Territory Sales'[Cost].
Cualquier objeto que tenga una columna con una relación con 'Territory Sales'[Cost]
El resultado de 1-4 será un error durante la evaluación de la consulta. Un Visual de Power BI mostrará un cuadro gris de la muerte.
Warning
__Los usuarios de negocio a menudo percibirán los resultados esperados de OLS como si el Report, el Visual o la consulta estuvieran "rotos". __ Si usas OLS y se espera que los usuarios se enfrenten a estas evaluaciones, prueba lo siguiente:
Forma a los usuarios sobre la seguridad.
Intenta controlar el error y devolver un mensaje más significativo.
En escenarios de Build, considera ocultar el objeto.
Otra optimización que conviene probar es establecer IsPrivate en True o IsAvailableInMDX en False.
Con RLS y OLS configurados, hay dos posibles resultados:
El usuario tiene un rol con RLS y OLS: La seguridad funcionará como se espera, siempre que esté configurada correctamente.
El usuario tiene varios roles en los que RLS y OLS están configurados por separado: La combinación de roles no es compatible y el usuario recibirá un error.
Debido a #2, si esperas usar tanto RLS como OLS, esto debe considerarse cuidadosamente durante el diseño del modelo.
A continuación se muestra un ejemplo de #1:
En el ejemplo:
Jack, que tiene asignado el rol 'CTG':
Solo puede ver los datos de "Central Transit Gate" debido al permiso de tabla RLS en 'Regions'.
Solo puede ver datos de ventas; no puede ver [Margin %]. Esto se debe al permiso de objeto de OLS None en 'Territory Sales'[Cost], lo que afecta a la medida dependiente [Margin %]
Elisa, que tiene asignado el rol 'Execs', puede ver todos los datos. No se ha configurado ningún permiso de tabla de RLS ni permiso de objeto de OLS (establecido en Default) para 'Execs'.
Tommy, que no tiene asignado ningún rol, no puede ver ningún dato.
Warning
Los escenarios que combinan RLS y OLS no son raros. Los escenarios en los que se usan correctamente sí lo son. Asegúrate de que, si necesitas RLS y OLS a la vez, lo consideres detenidamente durante el diseño del modelo.
Con RLS y OLS configurados, hay dos resultados posibles:
El usuario tiene un rol con RLS y OLS: La seguridad funcionará como se espera, siempre que esté configurada correctamente.
El usuario tiene varios roles en los que RLS y OLS están configurados por separado: La combinación de roles no es compatible y el usuario recibirá un error.
Debido a #2, si prevés usar RLS y OLS, debes considerarlo cuidadosamente durante el diseño del modelo.
A continuación se muestra un ejemplo de #2:
En el ejemplo anterior:
Jack, que tiene asignado el rol 'Read Users':
Solo puede ver los datos de "Central Transit Gate" debido al permiso de tabla RLS en 'Regions'.
Solo puede ver datos de ventas; no puede ver [Margin %]. Esto se debe al permiso de objeto de OLS None en 'Territory Sales'[Cost], lo que afecta a la medida dependiente [Margin %]
Janet, a quien se le han asignado los roles "Read Users" y "Build Users":
No se puede ver ningún dato. La combinación de permisos de RLS/OLS entre los roles no es válida.
Los usuarios a los que se conceden permisos de compilación en el Dataset se agregan al grupo de seguridad Build de Azure AD, que está asignado al rol "Build Users". Los usuarios de compilación pueden ver tablas que no están en los Report ya existentes, por lo que se configura el permiso OLS None para la tabla "Employees". Esto produce una combinación en la que los permisos de RLS y OLS no se pueden conciliar, lo que provoca un error.
Warning
Los escenarios que combinan RLS y OLS no son raros. Los escenarios en los que se usan correctamente sí lo son. Asegúrate de que, si tienes el requisito de usar RLS y OLS juntos, lo consideres cuidadosamente durante el diseño del modelo.
Ningún usuario podrá leer ningún dato hasta que se le agregue al rol, siempre que la seguridad de datos esté configurada en el Dataset.
Note
No olvides dar a los usuarios acceso al Dataset y añadirlos al rol de seguridad.
Si añades a un usuario a un rol de seguridad, eso no le dará automáticamente acceso de lectura al Dataset. Aun así, no podrá acceder a ningún Dataset ni a ningún Report.
Note
No olvides dar a los usuarios acceso al Dataset y añadirlos al rol de seguridad.
Warning
Es una práctica recomendada evitar la distribución mediante roles de Workspace, siempre que sea posible. Si es necesario, asegúrate de aplicar el Principio de mínimo privilegio: los usuarios deben tener el acceso mínimo necesario para hacer lo que necesitan.
Si le das a un usuario acceso a un Dataset mediante los roles de Administrador, Miembro o Colaborador, podrá ver todos los datos, independientemente de la configuración de seguridad de datos y de los roles que tenga asignados. Este es un error habitual al escalar o en ecosistemas de Power BI de autoservicio, y provoca filtraciones de datos e incumplimiento.
Warning
Es una práctica recomendada evitar la distribución mediante roles de Workspace, siempre que sea posible. Si es necesario, asegúrate de aplicar el Principio de mínimo privilegio: los usuarios deben tener el acceso mínimo necesario para hacer lo que necesitan.
Limitaciones estrictas
Algunas características de Report o de Data model no funcionarán con una configuración de RLS u OLS. Algunos ejemplos son:
