Seguridad de nivel de fila (RLS) con Power BI

La seguridad de nivel de fila (RLS) restringe el acceso a los datos para usuarios específicos. Los filtros restringen los datos a nivel de fila y se definen dentro de los roles. En el servicio Power BI, los usuarios con acceso a un área de trabajo tienen acceso a modelos semánticos del área de trabajo. RLS solo restringe el acceso a los datos para los usuarios con permisos de Visor . No se aplica a administradores, miembros o colaboradores.

Para implementar RLS, siga este flujo de trabajo de alto nivel:

1. Definir roles y reglas en Power BI Desktop mediante expresiones de filtro DAX.
2. Publish el modelo semántico e informe al servicio de Power BI.
3. Agregar miembros en los roles del servicio de Power BI.
4. Valide mediante la característica Probar como rol para confirmar que el filtrado de datos funciona según lo previsto.

Puede configurar RLS para los modelos semánticos importados en Power BI Desktop o el servicio Power BI. También puede configurar RLS en modelos semánticos que usan DirectQuery, como SQL Server. Para las conexiones dinámicas de Analysis Services o Azure Analysis Services, debe configurar la seguridad a nivel de fila en el modelo, no en Power BI. La opción de seguridad no se muestra para los modelos semánticos de conexión dinámica.

Definir roles y reglas en Power BI Desktop

Puede definir roles y reglas en Power BI Desktop. Con este editor, puede alternar entre usar la interfaz desplegable predeterminada y una interfaz DAX. Al publicar en Power BI, publicará también las definiciones de roles.

Para definir roles de seguridad:

1. Importar datos en el informe de Power BI Desktop o configurar una conexión de DirectQuery.

   Nota

   No puede definir roles en Power BI Desktop para conexiones dinámicas de Analysis Services. Tienes que hacerlo en el modelo de Analysis Services.

2. En la pestaña Modelado , seleccione Administrar roles.

3. En la ventana Administrar roles, seleccione Nuevo para crear un rol.

4. En Roles, proporcione un nombre para el rol y seleccione ENTRAR.

   Nota

   No se puede definir un rol con una coma, por ejemplo, London,ParisRole.

5. En Seleccionar tablas, seleccione la tabla a la que quiere aplicar un filtro de seguridad de nivel de fila.

6. En Filtrar datos, use el editor predeterminado para definir los roles. Las expresiones creadas devuelven un valor verdadero o falso.

   Nota

   No todos los filtros de seguridad de nivel de fila admitidos en Power BI se pueden definir mediante el editor predeterminado. Entre las limitaciones se incluyen expresiones que actualmente solo se pueden definir mediante DAX, incluidas reglas dinámicas como username() o userprincipalname(). Para definir roles con estos filtros, empiece a usar el editor DAX.

7. Opcionalmente, seleccione Cambiar al editor DAX para cambiar al uso del editor DAX para definir el rol. Las expresiones DAX devuelven un valor de verdadero o falso. Por ejemplo: [Entity ID] = “Value”. El editor DAX se completa con autocompletar para las fórmulas (IntelliSense). Puede seleccionar la marca de verificación situada encima del cuadro de expresión para validar la expresión y el botón X situado encima del cuadro de expresión para revertir los cambios.

   Nota

   Puede usar username() dentro de esta expresión. Tenga en cuenta que username() tiene el formato DOMAIN\username en Power BI Desktop. En el servicio Power BI y en Power BI Report Server, está en el formato del nombre principal de usuario (UPN). Además, en este cuadro de expresión, use comas para separar argumentos de función DAX incluso si usa una configuración regional como la del francés o el alemán, que normalmente usa separadores de punto y coma.

8. Para volver al editor predeterminado, seleccione Cambiar al editor predeterminado. Todos los cambios que se hacen en cualquiera de las interfaces del editor se conservarán cuando sea posible cambiar las interfaces. Al definir un rol mediante el editor DAX que no se puede definir en el editor predeterminado, si intenta cambiar al editor predeterminado, se le pedirá una advertencia de que cambiar de editor puede provocar que se pierda información. Para conservar esta información, seleccione Cancelar y siga editando este rol en el editor DAX.

   Nota

   En este cuadro de expresión, use comas para separar argumentos de función DAX incluso si usa una localización que normalmente usa separadores de punto y coma, como el francés o el alemán.

9. Seleccione Guardar.

No puede asignar usuarios a un rol en Power BI Desktop. Los asigna en el servicio Power BI. Puede habilitar la seguridad dinámica en Power BI Desktop mediante el uso de las funciones DAX username() o userprincipalname() y tener configuradas las relaciones adecuadas.

Patrones de filtro DAX comunes

En los ejemplos siguientes se muestran expresiones de filtro DAX comunes que puede usar al definir roles de RLS:

• RLS estático : restringe los datos a un valor fijo:

  [Region] = "West"
  

• RLS dinámico con UPN : restringe los datos en función de la dirección de correo electrónico del usuario que ha iniciado sesión:

  [UserEmail] = USERPRINCIPALNAME()
  

• RLS dinámico con NOMBRE DE USUARIO : restringe los datos en función del dominio y el nombre de usuario del usuario:

  [UserDomain] = USERNAME()
  

• RLS dinámico con CUSTOMDATA : restringe los datos en función de una cadena personalizada que se pasa desde la aplicación de inserción:

  [AppRole] = CUSTOMDATA()
  

  Nota

  CUSTOMDATA() se usa principalmente en escenarios insertados en los que la aplicación pasa una cadena de identidad efectiva personalizada a través de la API REST de Power BI.

RLS dinámico es el enfoque más común porque permite que una única definición de rol filtre los datos de forma diferente para cada usuario, en función de una tabla de asignación de usuarios en el modelo de datos.

Filtrado cruzado bidireccional

De forma predeterminada, el filtrado de la seguridad de nivel de fila utiliza filtros unidireccionales, independientemente de si las relaciones se establecen de forma unidireccional o bidireccional.

Para habilitar manualmente un filtro cruzado bidireccional con seguridad de nivel de fila, seleccione la relación y marque la casilla de verificación Aplicar filtro de seguridad en ambas direcciones. Active esta opción al implementar también la seguridad de nivel de fila dinámica en el nivel del servidor, donde la seguridad de nivel de fila se basa en el nombre de usuario o el identificador de inicio de sesión. Si una tabla participa en varias relaciones bidireccionales, solo puede seleccionar esta opción para una de esas relaciones.

Para más información, consulte los artículos técnicos Filtrado cruzado bidireccional con DirectQuery en Power BI y Protección del modelo semántico tabular de BI.

Administrar la seguridad en tu modelo

Para administrar la seguridad en el modelo semántico, abra el área de trabajo donde guardó el modelo semántico en Fabric y siga estos pasos:

1. En Fabric, seleccione el menú Más opciones de un modelo semántico. Este menú aparece al mover el puntero sobre el nombre de un modelo semántico.

   

2. Seleccione Seguridad.

   

La seguridad le llevará a la página de Seguridad a nivel de rol, donde puede agregar miembros a un rol que haya creado. Los usuarios con roles de Contribuidor o superiores en el área de trabajo ven la opción de Seguridad y pueden asignar usuarios a un rol. También se puede requerir la propiedad del modelo semántico o el permiso de compilación en función del escenario.

Administrar la pertenencia a roles

Agregar miembros

En el servicio Power BI, puede agregar un miembro al rol escribiendo la dirección de correo electrónico o el nombre del usuario o el grupo de seguridad. No se pueden agregar grupos creados en Power BI. Puede agregar miembros externos a la organización. Para obtener instrucciones sobre cómo funciona RLS con usuarios invitados B2B externos, consulte Consideraciones para usuarios externos (invitados B2B).

Puede usar los siguientes grupos para configurar la seguridad de nivel de fila.

• Grupo de distribución
• Grupo habilitado para correo
• Grupo de seguridad de Microsoft Entra

Puede ver cuántos miembros forman parte del rol por el número entre paréntesis junto al nombre del rol, o junto a Miembros.

Quitar miembros

Puede quitar miembros seleccionando la X junto a su nombre.

Validación del rol en el servicio Power BI

Puede validar que el rol definido funciona correctamente en el servicio Power BI probando el rol.

1. Seleccione Más opciones (...) junto al rol.
2. Seleccione Probar como rol.

Cuando se cargue el informe, compruebe lo siguiente:

• El informe muestra solo las filas de datos que coinciden con la expresión de filtro definida en el rol.
• Los objetos visuales, las tablas y los gráficos reflejan los datos filtrados, no el conjunto de datos completo.
• Si usa RLS dinámico, los datos corresponden a la identidad que se muestra en el encabezado Viendo ahora como.

En el encabezado de la página, se muestra la función que se está aplicando. Pruebe otros roles, una combinación de roles o una persona específica seleccionando Ahora se muestra como. Aquí verá detalles de permisos importantes relacionados con la persona o el rol que se está probando. Para más información sobre cómo interactúan los permisos con RLS, consulte Experiencia del usuario de RLS.

Pruebe otros informes conectados al modelo semántico seleccionando Vista en el encabezado de página. Solo puede probar informes ubicados en el mismo área de trabajo que el modelo semántico.

Para volver a la vista normal, seleccione Volver a seguridad de nivel de fila.

Uso de la función DAX username() o userprincipalname()

Puede aprovechar las ventajas de las funciones DAX username() o userprincipalname() dentro del conjunto de datos. Puede usarlas dentro de expresiones en Power BI Desktop. Cuando publique el modelo, se utilizará dentro del servicio Power BI.

En Power BI Desktop, username() devolverá un usuario con el formato de DOMINIO\Usuario y userprincipalname() lo devolverá con el formato de user@contoso.com.

En el servicio Power BI, username() y userprincipalname() devolverán ambos el nombre principal de usuario (UPN) del usuario. Es similar a una dirección de correo electrónico.

Uso de RLS con áreas de trabajo en Power BI

Si publica un informe de Power BI Desktop en un área de trabajo del servicio Power BI, los roles de RLS se aplican a los miembros que tienen asignado el rol de Espectador en el área de trabajo. Incluso si a los Visualizadores se les concede permisos de compilación al modelo semántico, la RLS todavía se aplica. Por ejemplo, si los visores con permisos de creación usan la función Analizar en Excel, su vista de los datos está restringida por RLS. Los miembros del área de trabajo asignados administrador, miembro o colaborador tienen permiso de edición para el modelo semántico y, por lo tanto, RLS no se aplica a ellos. Si desea que RLS se aplique a las personas de un área de trabajo, solo puede asignarles el rol Visor. Obtenga más información sobre los roles en las áreas de trabajo.

Consideraciones para usuarios externos (invitados B2B)

Si comparte contenido Power BI con usuarios externos a través de Microsoft Entra B2B, es importante comprender cómo interactúa RLS con las identidades de usuario invitado.

Resolución UPN para invitados B2B

Cuando un usuario invitado B2B externo accede a un informe de Power BI, la función DAX de USERPRINCIPALNAME() normalmente devuelve un identificador similar al correo electrónico (por ejemplo, user@partner.com). En algunas configuraciones, podría devolver un UPN invitado en el #EXT# formato (por ejemplo, user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Esta distinción es importante para RLS dinámico. Si la tabla de asignación de usuarios almacena un formato de identificador diferente al USERPRINCIPALNAME() que devuelve, la expresión de filtro no coincidirá y es posible que el usuario invitado no vea datos o datos incorrectos.

Comportamiento de USERNAME() para usuarios B2B

La USERNAME() función DAX devuelve el identificador domain\username del usuario. Para los usuarios invitados B2B, esta función normalmente devuelve el UPN del inquilino principal del invitado (por ejemplo, user@partner.com) en lugar de un formato domain\username. Dado que USERNAME() y USERPRINCIPALNAME() a menudo devuelven el mismo valor para los invitados B2B, la mayoría de las implementaciones usan USERPRINCIPALNAME() para mantener la coherencia.

[UserEmail] = USERPRINCIPALNAME()

Donde la UserEmail columna contiene direcciones de correo electrónico como user@partner.com para usuarios internos y externos.

Solución de problemas: el invitado externo no ve datos

Si un usuario invitado B2B ve un informe vacío o recibe un mensaje "sin datos", siga estos pasos:

1. Verifique el formato UPN devuelto – cree una medida de prueba con USERPRINCIPALNAME() y muéstrela en un objeto visual de tarjeta. Haga que el usuario invitado vea el informe para ver el valor real devuelto.
2. Compruebe la tabla de asignación de usuarios : confirme que la tabla de asignación contiene una fila con un valor que coincida exactamente con lo que USERPRINCIPALNAME() devuelve ese invitado.
3. Verificar la sensibilidad a mayúsculas y minúsculas: las comparaciones de cadenas DAX no distinguen entre mayúsculas y minúsculas de forma predeterminada, pero compruebe que el origen de datos no ha introducido valores sensibles a mayúsculas y minúsculas.
4. Revise la configuración de acceso entre inquilinos: si su organización usa directivas de acceso entre inquilinos, esto puede afectar el formato del UPN que se presenta a Power BI.
5. Prueba con el usuario invitado real : la característica Prueba como rol usa tu propia identidad. Valide siempre con la cuenta de invitado externa real. Para obtener más información sobre cómo compartir contenido de Power BI con usuarios externos, vea Distribute Power BI contenido a usuarios invitados externos con Microsoft Entra B2B.

Consideraciones y limitaciones

Aquí puede ver las limitaciones actuales de la seguridad de nivel de fila en los modelos en la nube:

• Si anteriormente definió roles y reglas en el servicio Power BI, debe volver a crearlos en Power BI Desktop.
• Solo puede definir RLS en los modelos semánticos creados con Power BI Desktop. Si desea habilitar RLS para los modelos semánticos creados con Excel, primero debe convertir los archivos en archivos de Power BI Desktop (PBIX). Más información.
• Las entidades de servicio no se pueden agregar a un rol de RLS. En consecuencia, la RLS no se aplica a las aplicaciones que usan una entidad de servicio como la identidad efectiva final.
• Solo se admiten conexiones de importación y de DirectQuery. Las conexiones dinámicas con Analysis Services se controlan en el modelo local.
• Con RLS habilitado, el uso de la función USERELATIONSHIP() en consultas DAX y medidas podría provocar errores inesperados. Para solucionar este problema, vuelva a diseñar las expresiones DAX para evitar USERELATIONSHIP() y usar relaciones de nivel de modelo u otros patrones DAX en su lugar.
• La función Probar como rol/Ver como rol no funciona para los modelos de DirectQuery con SSO (inicio de sesión único) habilitado.
• La característica Probar como rol/ver como rol solo muestra informes del área de trabajo de modelos semánticos.
• La característica Probar como rol/ver como rol no funciona para los informes paginados.

Tenga en cuenta que si un informe de Power BI hace referencia a una fila con RLS configurado, el mismo mensaje se muestra como para un campo eliminado o no existente. A estos usuarios, les parece que el informe está roto.

Preguntas más frecuentes

Pregunta: ¿Qué ocurre si tengo roles y reglas creados previamente para un conjunto de datos en el servicio Power BI? ¿Siguen funcionando si no hago nada?
Respuesta: No, los objetos visuales no se representarán correctamente. Tiene que volver a crear los roles y las reglas en Power BI Desktop y, después, publicarlos en el servicio Power BI.

Pregunta: ¿Puedo crear estos roles para orígenes de datos de Analysis Services?
Respuesta: Puede hacerlo si importa los datos a Power BI Desktop. Si usa una conexión dinámica, no podrá configurar RLS en el servicio Power BI. Usted define RLS en el modelo local de Analysis Services.

Pregunta: ¿Puedo usar RLS para limitar las columnas o medidas accesibles por mis usuarios?
Respuesta: No, si un usuario tiene acceso a una fila de datos determinada, puede ver todas las columnas de datos de esa fila. Para restringir el acceso a las columnas y los metadatos de las columnas, considere la posibilidad de usar la seguridad de nivel de objeto.

Pregunta: ¿Permite RLS ocultar datos detallados pero dar acceso a datos resumidos en objetos visuales?
Respuesta: No, aunque proteja las filas de datos individuales, los usuarios siempre pueden ver los detalles o los datos resumidos.

Pregunta: Mi origen de datos ya tiene definidos roles de seguridad (por ejemplo, roles de SQL Server o de SAP BW). ¿Cuál es la relación entre estos roles y RLS?
Respuesta: La respuesta depende de si se importan datos o se usa DirectQuery. Si va a importar datos en el conjunto de datos de Power BI, no se usan los roles de seguridad del origen de datos. En este caso, se debe definir RLS para aplicar las reglas de seguridad para los usuarios que se conectan en Power BI. Si estás utilizando DirectQuery, se utilizan los roles de seguridad del origen de datos. Cuando un usuario abre un informe, Power BI envía una consulta al origen de datos subyacente, que aplica las reglas de seguridad a los datos basándose en las credenciales del usuario.

Pregunta: ¿Un usuario puede pertenecer a más de un rol?
Respuesta: Un usuario puede pertenecer a varios roles y los roles son aditivos. Por ejemplo, si un usuario pertenece a los roles "Ventas" y "Marketing", puede ver los datos de ambos roles.

Contenido relacionado

• Restricción del acceso a datos con seguridad de nivel de fila (RLS) en Power BI Desktop
• Planeamiento de la implementación de Power BI: Planeamiento de la seguridad del consumidor de informes
• RLS para escenarios insertados para ISV
• Distribute Power BI contenido a usuarios invitados externos con Microsoft Entra B2B

¿Tiene alguna pregunta? Pruebe a preguntar a la comunidad de Power BI¿Alguna sugerencia? Ideas para contribuir a mejorar Power BI