La idea
La seguridad por filas (RLS) es un filtro sobre el modelo que el lector no puede apagar. Escribes una
regla para una tabla, una expresión verdadero/falso como customers[segment] = "business", y para
quien esté en ese rol la tabla conserva solo las filas donde la regla es verdadera. Todo lo demás
desaparece antes de que corra una sola medida.
La palabra importante es modelo. RLS no es un segmentador oculto en una página ni un filtro de un visual. Se aplica a los datos que lee todo el informe, así que una tabla, un gráfico, un tooltip y una exportación ven las mismas filas reducidas.
Figura 1
Una regla RLS sobre customers viaja como cualquier otro filtro
'Date'
- Date
- Year
- Month
orders
- order_id
- customer_id
- channel
- status
customers
- customer_id
- segment
- state
state in {CA, OR, WA, NV, AZ}
products
- product_id
- category
order_items
- order_id
- product_id
- line_total
- El modelo de Harbor & Pine. Ava Reed solo debe ver los clientes de sus estados. Los datos de clientes viven en
customers, así que ahí va la regla. - La regla es un filtro sobre
customers, aquístateen sus cinco estados. Se aplica antes de que corra cualquier medida o visual, y el lector no puede quitarla. - Baja por las relaciones como un segmentador: primero a
ordersy luego aorder_items. Cada cifra de ventas que ve Ava se construye ahora solo con las líneas de sus clientes. productsy'Date'no se filtran: ella sigue viendo todos los nombres de producto y todas las fechas, con ventas solo de sus clientes. RLS filtra filas a través de las relaciones, nada más.
Por qué existe
Los cuarenta gerentes de Harbor & Pine abren el mismo informe cada mañana, y cada uno debe ver solo los clientes de los que es responsable. Hay dos formas de lograrlo: construir cuarenta informes y mantenerlos al día, o construir uno y dejar que el modelo decida qué puede ver cada persona. La segunda es la única que escala, y la única que cambia sola cuando un territorio se mueve.
También es una propiedad de seguridad. Si un número del informe está mal por un segmentador, alguien hizo clic donde no debía. Si una fila restringida aparece ante la persona equivocada, el informe ha filtrado datos. Una seguridad que depende de que los lectores se porten bien no es seguridad.
Cómo funciona por dentro
Una regla se evalúa en cuatro pasos.
- El usuario inicia sesión. El Service conoce su correo, que una regla puede leer con
USERPRINCIPALNAME(). - Se aplica el rol del usuario. Los roles se definen en Desktop (Modeling → Manage roles) y las personas se agregan a ellos en el Service (Security del conjunto de datos).
- La regla filtra su tabla. Una regla estática nombra los valores (
stateen una lista). Una regla dinámica los busca en una tabla, de modo que la lógica se escribe una sola vez. - El filtro fluye por las relaciones. Filtrar
customersfiltraordersy luegoorder_items, igual que un segmentador. Las tablas sin relación concustomersno se filtran.
Estática y dinámica
Un rol estático es una regla por grupo: West, Texas, B2B. Es simple y correcto para un puñado de grupos. Con veinte se vuelve una tarea pesada, y cada trimestre alguien edita el modelo.
Una regla dinámica pregunta "¿quién es esta persona?" y busca qué puede ver.
Figura 2
Una regla dinámica, evaluada cliente por cliente
| customer_id | state | segment | Sales |
|---|---|---|---|
| 3 | CA | business | $27,371.95 |
| 26 | CA | business | $48,298.90 |
| 56 | NY | business | $9,744.38 |
| 221 | TX | business | $13,114.99 |
| 106 | FL | business | $6,153.25 |
| state | manager_email |
|---|---|
| CA | ava.reed@harborandpine.com |
| NY | grace.kim@harborandpine.com |
| TX | luis.ortega@harborandpine.com |
| customer_id | Sales |
|---|---|
| 3 | $27,371.95 |
| 26 | $48,298.90 |
- La regla es
LOOKUPVALUE(Territories[manager_email], Territories[state], customers[state]) = USERPRINCIPALNAME(). Para cada cliente busca quién es dueño de su estado y lo compara con el usuario que inició sesión. - Ava Reed inicia sesión. El cliente 3 está en CA, cuya responsable es ava.reed@harborandpine.com. Coincide, así que la fila se queda.
- El cliente 56 está en NY, de Grace, y el 221 en TX, de Luis. La comparación falla y esas filas desaparecen para Ava.
- El cliente 106 está en FL, que no aparece en
Territories. La búsqueda devuelve un vacío, un vacío nunca es igual a un correo, y la fila desaparece para todos hasta que Sales Ops agregue el estado. - Ava ve dos clientes y sus pedidos: $27,371.95 + $48,298.90 = $75,670.85 de ventas. Cambiar las filas de
Territoriescambia quién ve qué, sin tocar el modelo.
La correspondencia vive en una tabla (aquí Territories) que Sales Ops edita como datos normales.
El modelo y la regla no cambian nunca. Dos detalles importan: compara con USERPRINCIPALNAME() y
piensa en la persona que no está en la tabla, porque para ella la regla es falsa en todas las filas.
Figura 3
Del inicio de sesión a los números filtrados
- Inicio de sesión El Service conoce el correo del usuario
- Rol A qué rol pertenece el usuario
-
[state] in {CA, OR}La regla, una por tabla - Modelo El filtro fluye por las relaciones
- Visuales Las medidas se calculan sobre las filas filtradas
- La seguridad empieza al iniciar sesión. El Service sabe quién pregunta.
- En **Manage roles** defines los roles y, en el Service, agregas personas o grupos a ellos. El rol del usuario decide qué reglas se aplican.
- Un rol contiene reglas, cada una una expresión verdadero/falso sobre una tabla. Se ven las filas donde es verdadera.
- El filtro de la regla fluye a las tablas relacionadas, como lo hace un segmentador.
- Solo entonces los visuales evalúan sus medidas. El usuario nunca ve un número sin filtrar.
Combinar reglas
Dos combinaciones aparecen en cuanto el informe crece. Dentro de un mismo rol, una regla en
customers y otra en products se aplican juntas: una fila debe pasar ambas, así que se
restringen mutuamente. Entre roles ocurre lo contrario. Quien pertenece a dos roles recibe la
unión: una fila es visible si cualquiera de los roles la permite. Un error habitual es agregar a
alguien a un rol amplio "por si acaso" y anular sin querer el rol estrecho que debía restringirlo.
Una sola regla también puede combinar pruebas con &&. El informe B2B usa una:
customers[segment] = "business" Y que el usuario sea el representante o el gerente que figura para
el estado del cliente en una tabla Reps. Solo clientes de empresa, y solo los estados que esa
persona cubre. Escribir las búsquedas en líneas VAR mantiene legible una regla así: una línea para
el usuario, una para el representante, una para el gerente y una prueba corta en RETURN.
A quién se aplica RLS
RLS se aplica a quienes tienen el rol Viewer en un área de trabajo y a los usuarios de una app. No se aplica a quienes pueden editar el contenido: Admin, Member y Contributor ven todas las filas, porque pueden abrir el modelo y quitar la regla de todos modos. Por eso una prueba con tu propia cuenta de administrador no demuestra nada. Usa Modeling → View as en Desktop, o Test as role en el Service, para ver lo que ve un usuario.
Lo que RLS no hace
No oculta columnas (eso es la seguridad a nivel de objeto), y no vuelve seguro un modelo si una tabla que debería restringirse no tiene relación con la tabla que lleva la regla. Revisa el camino de cada tabla hacia la regla antes de publicar. Lo que sí hace es proteger el modelo y no el informe: un Viewer con permiso de Build que consulte el conjunto de datos desde Excel recibe las mismas filas filtradas.
Errores comunes
"Probaré la regla abriendo el informe yo mismo"
Si eres el propietario o un administrador, RLS no se te aplica y verás todo. Una regla que nunca viste como otro usuario no está probada. Usa View as con un rol real y un correo real, y prueba también a alguien que no coincida con nada.
"RLS oculta filas en el visual"
Las quita del modelo para ese usuario, que es más fuerte: las filas no están ocultas en la página, para esa persona no existen. Por eso los totales, los tooltips y las exportaciones coinciden con lo que ve la persona, y por eso un total del panel puede ser distinto entre dos personas.
"Un rol RLS por región es lo normal"
Es lo más simple, y funciona con tres regiones. Con veinte es una carga de mantenimiento, y los roles se alejan de la realidad. Una regla dinámica con una tabla de correspondencia escala y es más fácil de auditar, porque la regla se escribe una vez y los datos muestran quién ve qué.
Ponte a prueba
Una pregunta. Al responderla, la lección queda marcada en el mapa; nunca bloquea un nivel.
No del todo. RLS funciona con lista de permitidos: una fila es visible solo cuando la regla es verdadera para ella. Sin coincidencia es falso en todas las filas, no una vista sin restricciones.Prueba otra respuesta.
No del todo. La regla se evalúa bien. LOOKUPVALUE devuelve la responsable de cada estado y ninguna es igual al correo de Hannah, así que la regla simplemente es falsa.Prueba otra respuesta.
No del todo. Los estados sin dueño devuelven un vacío, y un vacío tampoco es igual a su correo. Esas filas también se ocultan.Prueba otra respuesta.
Correcto. La regla es falsa en todas las filas, así que customers queda vacía para ella, el filtro baja a orders y order_items, y su matriz queda en blanco.
Lección hecha: ya está marcada en el mapa.