Un informe comercial debe mostrar a cada responsable únicamente sus operaciones. Ocultar un segmentador o una página no demuestra que las demás filas sean inaccesibles. El control necesita aplicarse al modelo y comprobarse con la identidad que utilizará el contenido.
Row-level security, o RLS, restringe filas según las reglas configuradas. Su validación debe incluir permisos del espacio de trabajo, relaciones del modelo y vías de consumo, además de la expresión del filtro.
1. Construye una matriz de acceso esperada
Define identidades de prueba y conjuntos de datos que puedan distinguirse. Utiliza datos sintéticos o autorizados para la prueba.
| Identidad ilustrativa | Alcance esperado | Caso negativo |
|---|---|---|
| Responsable Norte | Operaciones asignadas a Norte | Una operación de Sur |
| Responsable Sur | Operaciones asignadas a Sur | Una operación de Norte |
| Supervisor autorizado | Ámbitos expresamente asignados | Una unidad ajena a su responsabilidad |
| Usuario sin asignación | Sin acceso a datos protegidos | Cualquier operación protegida |
Incluye filas sin unidad o con una asignación desconocida. Una ausencia no debería transformarse accidentalmente en acceso global.
2. Comprueba el rol efectivo en el servicio
La documentación de RLS de Power BI explica que, en un espacio de trabajo, RLS restringe a usuarios con rol Viewer y no se aplica a Admin, Member o Contributor. Una prueba realizada con una cuenta que edita el modelo no representa la experiencia del lector restringido.
Conserva quién recibe contenido, qué permisos tiene sobre el modelo y qué papel ocupa en el espacio de trabajo. No evalúes la seguridad únicamente desde la sesión del desarrollador.
La vista de prueba de roles ayuda a revisar reglas, pero completa la validación con identidades y canales reales cuando corresponda. Determinadas configuraciones tienen limitaciones en los modos de simulación.
3. Sigue el filtro hasta la tabla de hechos
Comprueba la tabla que relaciona identidad y alcance, las claves utilizadas y la propagación por las relaciones. Una regla correcta en una tabla aislada no garantiza que restrinja la tabla que alimenta el gráfico.
Revisa registros huérfanos, claves repetidas y relaciones ambiguas. Si el modelo permite varios caminos de filtro, documenta cuál debe aplicar y prueba los resultados con operaciones identificables.
No añadas relaciones bidireccionales solo para hacer desaparecer un fallo de prueba. La modificación puede cambiar cálculos y accesos en otras partes del modelo. La estructura debe responder al grano y las relaciones del modelo.
4. Valida asignaciones múltiples y cambios
Si una identidad pertenece a varios roles o unidades, comprueba el alcance combinado. No supongas que la regla más restrictiva prevalece sin verificar cómo combina permisos el producto.
Ensaya una reasignación: el responsable deja Norte y pasa a Sur. Define cuándo se actualiza la tabla de permisos y cómo se comprueba que el nuevo acceso es efectivo. El dato de asignación puede tener una frecuencia de actualización diferente del informe.
Incluye usuarios externos y formatos de identidad cuando formen parte del alcance. La correspondencia debe utilizar el identificador que realmente evalúa el servicio, no una etiqueta visual que se le parezca.
5. Prueba las vías de consumo permitidas
Abre el informe, navega al detalle y utiliza las opciones de exportación o análisis que la organización haya habilitado. Comprueba las filas devueltas en cada vía con las mismas identidades.
RLS regula filas dentro de su alcance; no sustituye todos los permisos sobre archivos exportados, capturas o copias que ya salieron del servicio. Define también cómo deben tratarse esos resultados.
Evita basarte solo en totales: dos conjuntos diferentes pueden sumar lo mismo. Utiliza claves de casos positivos y negativos para comprobar presencia y ausencia.
6. Guarda evidencia reproducible
Registra versión del modelo, identidad, permisos, filtro aplicado, datos de prueba y resultado esperado. Repite los casos cuando cambien relaciones, asignaciones o canales de distribución.
Cuando una prueba falla, identifica si el problema está en el permiso del servicio, el mapeo de identidad o la propagación del filtro. Esa distinción permite corregir el control sin alterar innecesariamente la definición de las métricas.
Para revisar la distribución de cuadros de mando empresariales, comparte con Nexeus Big Data la matriz de acceso esperada y cómo reciben los usuarios el informe. Con ese contexto se puede comprobar la seguridad sobre las filas que realmente ve cada persona.