Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Seguridad a nivel de fila en Power BI y Fabric: cómo DAX, roles y grupos deciden quién ve qué (Doblaje IA)

Transcript

Seguridad a nivel de fila en Power BI y Fabric: cómo DAX, roles y grupos deciden quién ve qué (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Listo para 10 días de Microsoft 365 Copilot, EA, Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del trabajo.
0:07
Speaker 2: Este enero vuelve M365 con más fuerza. Y venimos con
0:12
Speaker 2: más fuerza. Únete a nosotros para sesiones en vivo, demostraciones
0:15
Speaker 2: reales y conocimientos prácticos de MVPs y expertos de la
0:17
Speaker 2: industria de Tormund. Nada de diapositivas en Eric. Nada de
0:20
Speaker 2: tecnicismo sin terminar. Abordamos los desafíos reales. Copilot Studio, agentes
0:25
Speaker 2: de IA, Fabric, Seguridad, Gobernanza y Automatización. Ya seas un
0:30
Speaker 2: profesional de TI, desarrollador o líder empresarial, hay sesiones diseñadas
0:34
Speaker 2: para ti. Con 10 días completos, puedes explorar múltiples tecnologías
0:38
Speaker 2: y conectar con una comunidad global. Míralo en vivo y
0:42
Speaker 2: lleva ideas prácticas de vuelta a tu organización. Enero de 2027.
0:46
Speaker 2: 10 días. Una sola comunidad Microsoft. Las inscripciones ya están abiertas.
0:51
Speaker 2: Reserva tu lugar hoy mismo. Eso es m365.net. Únete ahora
1:01
Speaker 2: en m365.com.net y nos vemos en vivo en enero.
1:05
Speaker 4: Una vez te has preguntado a quién puede ver realmente
1:06
Speaker 4: tus datos en Power BI, alerta de spoiler, no es
1:08
Speaker 4: tan privado como crees a menos que domines la seguridad
1:10
Speaker 4: a nivel de fila. En este episodio, no solo marcamos
1:14
Speaker 4: la casilla de RLS, desglosamos las partes móviles desde las
1:16
Speaker 4: definiciones de roles hasta las expresiones DAX que deciden silenciosamente
1:19
Speaker 4: quién ve qué. La mayoría se detiene en la configuración,
1:23
Speaker 4: pero te mostraremos cómo cada decisión se conecta para que
1:26
Speaker 4: tus datos no solo estén bloqueados, sino diseñados para la seguridad.¿
1:30
Speaker 4: Por qué la seguridad a nivel de fila es un sistema,
1:32
Speaker 4: no una casilla de verificación? Si estás acostumbrado a proteger
1:35
Speaker 4: una hoja de cálculo confidencial poniéndole una contraseña, ya sabes
1:37
Speaker 4: que hay una brecha entre lo que intentas y lo
1:39
Speaker 4: que realmente protege tus datos. Power BI con seguridad a
1:44
Speaker 4: nivel de fila puede sentirse exactamente igual. Activas el interruptor
1:47
Speaker 4: de RS, asignas un par de errores y piensas que
1:49
Speaker 4: estamos cubiertos. Pero en realidad es diferente. Los datos confidenciales
1:53
Speaker 4: encuentran una salida cuando esas conexiones entre roles, filtros y
1:56
Speaker 4: usuarios no están bien mapeadas. La gente rara vez habla
1:59
Speaker 4: de las veces que alguien del equipo de ventas abrió
2:01
Speaker 4: un panel y terminó viendo números que nunca debió haber visto.
2:06
Speaker 4: Pero sucede, y casi siempre comienza con la suposición de
2:08
Speaker 4: que RLS es solo una casilla más para marcar durante
2:10
Speaker 4: la configuración. Pongámonos en los zapatos de alguien que ha
2:13
Speaker 4: dado acceso a un panel pensando que solo está empoderando
2:16
Speaker 4: a un colega. Parece inofensivo, pero en demasiadas organizaciones, el
2:20
Speaker 4: acceso a un panel es acceso a todo lo que
2:22
Speaker 4: hay detrás. He visto entornos donde un único rol de
2:25
Speaker 4: gerente global permitió accidentalmente que usuarios junior navegaran por datos
2:28
Speaker 4: confidenciales de RR. Solo porque el nombre no coincidía con
2:32
Speaker 4: la realidad. Esto tampoco es un caso raro y aislado.
2:35
Speaker 4: Es más cercano a la regla que a la excepción,
2:36
Speaker 4: especialmente cuando una empresa crece y los paneles se multiplican.
2:40
Speaker 4: Todos quieren avanzar rápido, pero al moverse sin estructura se
2:42
Speaker 4: dejan pequeños agujeros que pueden convertirse en brechas enormes durante
2:45
Speaker 4: una auditoría. En teoría la RDS no podría sonar más sencilla.
2:50
Speaker 4: Crea un rol, llámalo ventas, añade un filtro como región
2:52
Speaker 4: igual a EEE y asigna usuarios a él. Pero detrás
2:57
Speaker 4: de cada menudo desplegable y casi de verificación en Power BI,
2:59
Speaker 4: hay un sistema decidiendo qué datos viajan a dónde. Si
3:03
Speaker 4: pasas por alto una relación en un filtro, no captura
3:05
Speaker 4: una nueva fuente de datos, no es solo un error técnico,
3:08
Speaker 4: es un incidente de seguridad a punto de ocurrir. No
3:11
Speaker 4: te enterarás hasta que alguien tropiece con datos que no
3:13
Speaker 4: debería haber y a veces, ni siquiera entonces. Y eso
3:16
Speaker 4: es lo que hace que esos pequeños fallos sean tan
3:18
Speaker 4: difíciles de detectar. No vienen con alarma si las auditorías
3:20
Speaker 4: estándar a menudo no profundizan lo suficiente para notarlos. Uh-huh.
3:25
Speaker 4: Lo que se pasa por alto es cuán estrechamente conectados
3:27
Speaker 4: están los componentes de la RLS. La mayoría de los
3:30
Speaker 4: tutoriales pasan rápido por la configuración guiándote en la creación
3:32
Speaker 4: de roles y conceptos básicos de filtros. Demuestran cómo asignar
3:35
Speaker 4: usuarios y marcar una casilla de vista previa, pero casi
3:38
Speaker 4: nadie se tira a analizar cómo un filtro en la
3:40
Speaker 4: tabla de ventas afecta, por ejemplo, a una tabla de
3:42
Speaker 4: territorio relacionada. Cada parte de la lógica en la RLS
3:46
Speaker 4: repercute en las demás. Las asignaciones, las expresiones DAX e
3:49
Speaker 4: incluso los nombres de los roles mismos. Trata esas elecciones
3:52
Speaker 4: como pasos aislados y estarás confiando en que el sistema
3:54
Speaker 4: no tiene cabos sueltos. Pero un filtro olvidado y de
3:57
Speaker 4: repente tu cuidadosa configuración de roles es como un colador.
4:01
Speaker 4: Esta es una de esas áreas donde la analogía correcta
4:04
Speaker 4: no es una puerta cerrada. Es una red de hilos.
4:09
Speaker 4: Cambias una parte y todo el conjunto puede desplazarse de repente.
4:12
Speaker 4: Pasas por alto un hilo. Has creado una fuga que
4:13
Speaker 4: ni siquiera es obvia hasta que alguien la explota. Los
4:16
Speaker 4: incidentes reales muestran cómo sucede esto. Historias internas de equipos
4:19
Speaker 4: de análisis cuentan el momento en que el jefe de
4:21
Speaker 4: ventas de Europa se topó con datos del flujo de
4:23
Speaker 4: trabajo de Norteamérica. Eso no fue alguien entrando por la fuerza,
4:27
Speaker 4: fue un filtro mal aplicado, un valor predeterminado involuntario o
4:29
Speaker 4: un rol que nadie pensó en verificar. Y no se
4:32
Speaker 4: trata solo de historias de terror en el mundo real.
4:34
Speaker 4: Los propios informes de vulnerabilidad de Microsoft catalogan la seguridad
4:38
Speaker 4: a nivel de fila mal configurada como una de las
4:40
Speaker 4: principales causas de vergonzosas exposiciones de datos públicos en grandes organizaciones.
4:44
Speaker 4: Por cada titular de noticias sobre una gran brecha hay
4:46
Speaker 4: docenas que no se denuncian pero que tienen consecuencias duraderas
4:49
Speaker 4: tras bambalinas. Lo que une estos problemas es la falsa
4:52
Speaker 4: sensación de seguridad que ofrece la RLS cuando la tratas
4:56
Speaker 4: como un simple elemento para marcar en una lista de tareas.
5:00
Speaker 4: Los estudios de los equipos de seguridad de Microsoft subrayan
5:03
Speaker 4: que superponer filtros, apilarlos entre tablas, aplicar expresiones DAX adicionales
5:07
Speaker 4: o usar combinaciones de lógica estática y dinámica aumenta tanto
5:10
Speaker 4: la protección como la complejidad. Cada capa que añades no
5:15
Speaker 4: solo aumenta la seguridad, sino que multiplica los puntos donde
5:17
Speaker 4: puede ocurrir un error de configuración. En lugar de un
5:22
Speaker 4: simple portero en la puerta, tienes una red compleja, donde
5:24
Speaker 4: un nodo olvidado puede arruinar meses de planificación de seguridad.
5:29
Speaker 4: Tampoco ignoremos las realidades prácticas. Un sistema puede funcionar bien
5:34
Speaker 4: en pruebas, pero al llevarlo a producción con usuarios, departamentos
5:37
Speaker 4: y equipos que cambian constantemente, surgen situaciones donde alguien que
5:41
Speaker 4: cambió de equipo el trimestre pasado sigue teniendo acceso a
5:44
Speaker 4: los números financieros trimestrales. Nombres y asignaciones que tenían sentido
5:49
Speaker 4: al principio se convierten en misteriosos artefactos heredados. Nadie quiere
5:53
Speaker 4: tocarlos por si acaso se siguen utilizando. Si solo activas
5:57
Speaker 4: RLS durante la configuración y luego te olvidas, no estás
5:59
Speaker 4: protegiendo tus datos. Estás esperando que nadie toque la puerta equivocada,
6:03
Speaker 4: ya sea por curiosidad o por error. Todo esto nos
6:06
Speaker 4: lleva a una verdad fundamental. La seguridad a nivel de
6:09
Speaker 4: fila está viva. Cambia la par de tu organización. Cada
6:12
Speaker 4: rol que creas, cada filtro DAX que aplicas, cada grupo
6:14
Speaker 4: que asignas no son decisiones menores. Fluyen juntos para crear
6:18
Speaker 4: un sistema de protección vivo y dinámico o si se ignoran,
6:20
Speaker 4: una malla llena de agujeros. Así que antes de pasar
6:23
Speaker 4: al siguiente panel o entregar un modelo, detente y pregúntate realmente.¿
6:27
Speaker 4: Estoy gestionando un sistema de seguridad o solo espero que
6:29
Speaker 4: el interruptor sea suficiente? La siguiente parte de esta historia
6:33
Speaker 4: comienza con la pieza central, la lógica del filtro en sí,
6:36
Speaker 4: y cómo guía todas las demás decisiones que tomas. Pues
6:41
Speaker 4: una base segura filtrado de datos y diseño de roles.
6:44
Speaker 4: Si alguna vez configuraste la seguridad a nivel de fila
6:46
Speaker 4: pensando que solo se trataba de ocultar ciertas filas, no
6:48
Speaker 4: eres el único. La razón principal por la que la
6:50
Speaker 4: RSS vuelve un desastre es un simple malentendido. No se
6:53
Speaker 4: trata solo de lo que es visible, sino de dar
6:54
Speaker 4: forma a toda la experiencia del usuario. Un paso en falso,
6:59
Speaker 4: y de repente esa... La tabla confidencial de bonos o
7:02
Speaker 4: la cifra de salario ejecutivo se filtra en el panel
7:04
Speaker 4: de alguien. Pero la gente descubre estas fugas cuando los
7:07
Speaker 4: informes ya están en circulación y para entonces corregir el
7:10
Speaker 4: error puede ser incómodo. Lo incómodo es que estos fallos
7:13
Speaker 4: rarales parecen dramáticos. Suele ser un caso aislado. Un gerente
7:16
Speaker 4: de E inicia sesión y ve lo que debe ver.
7:19
Speaker 4: Pero un colega de Londres abre el mismo modelo y
7:21
Speaker 4: sin que nadie se dé cuenta encuentra los números de
7:23
Speaker 4: Nueva York ahí mismo. Piensa en iniciar un modelo de
7:27
Speaker 4: fabric para ventas globales. quieres que los gerentes en diferentes
7:30
Speaker 4: regiones vean solo sus propios datos. El reflejo es añadir
7:34
Speaker 4: un filtro, algo sencillo. Región igual a E, U, o
7:37
Speaker 4: país igual a Reino Unido. Pero aquí está el problema.
7:41
Speaker 4: La forma en que escribes ese filtro y lo integras
7:43
Speaker 4: en tu modelo determina si tu sistema se mantiene firme
7:45
Speaker 4: o se desmorona en cuanto las cosas se complican. Muchos
7:49
Speaker 4: suponen que es algo sumamente sencillo, un filtro DAX de
7:51
Speaker 4: una línea, y siguen adelante. Pero no todo DAX se
7:54
Speaker 4: comporta de la misma manera. De hecho, esos matices suelen
7:58
Speaker 4: causar problemas más tarde, especialmente al pasar de Power BI
8:00
Speaker 4: Desktop a Fabric, donde surgen particularidades de la nube. La
8:04
Speaker 4: seguridad a nivel de fila de RSS se complica rápidamente
8:06
Speaker 4: cuando entras en detalles. La gente suele confiar en funciones
8:09
Speaker 4: como Username o User Principal Name, creyendo que hacen lo
8:13
Speaker 4: mismo o simplemente usando la que vieron en algún blog.
8:16
Speaker 4: Pero al cambiar Username, que obtiene tu nombre de Windows
8:19
Speaker 4: en Desktop, por User Principal Name, que toma tu correo
8:22
Speaker 4: en Fabric, tu lógica de filtrado empieza a fallar. Si
8:26
Speaker 4: alguna vez una prueba funcionó en desktop pero falló al
8:28
Speaker 4: publicar en Fabric, probablemente esta sea la razón. Y elegir
8:32
Speaker 4: mal es lo que abre hechas silenciosas permitiendo que las
8:34
Speaker 4: personas equivocadas vean datos que nunca deberían tocar. Seamos específicos.
8:39
Speaker 4: Para escenarios básicos,¿ una comprobación fija funciona?¿ Región igual a E?¿
8:44
Speaker 4: Significa que solo aparecen las filas donde la región es EE?
8:48
Speaker 4: Eso es RDS estático de Detex. Es rápido, simple y
8:51
Speaker 4: para divisiones fijas como un informe solo para gerentes de EE.
8:54
Speaker 4: Cumple su función. Pero en cuanto alguien pide seguridad dinámica,
8:57
Speaker 4: todo cambia. Puede que necesites determinar el acceso no solo
9:00
Speaker 4: según quien ve el informe, sino basándote en relaciones en
9:02
Speaker 4: otra tabla, como una tabla de acceso de usuarios que
9:04
Speaker 4: indique qué regiones puede ver cada uno. Ahora,¿ tu filtro
9:08
Speaker 4: RLS no es solo un valor fijo? Es una fórmula
9:11
Speaker 4: que busca en tiempo real a qué regiones debe acceder
9:13
Speaker 4: cada persona. Aquí es donde DAX puede engañarte si no
9:16
Speaker 4: tienes cuidado. Podrías usar algo como User Principal Name e
9:20
Speaker 4: intentar unirlo con tu tabla de acceso. Pero si tu
9:24
Speaker 4: DAX depende de columnas calculadas o usa una lógica que
9:26
Speaker 4: no responde al contexto del usuario al momento de la visualización,
9:29
Speaker 4: podrías romper el filtro dinámico accidentalmente. Un ejemplo real. Una
9:33
Speaker 4: empresa configura un filtro dinámico basado en una columna calculada
9:37
Speaker 4: en su tabla de hechos, solo para notar después que
9:39
Speaker 4: las columnas calculadas se evalúan al cargar los datos, no
9:44
Speaker 4: al visualizarlos. Esto significa que los usuarios no ven sus
9:48
Speaker 4: filas personalizadas, o peor aún, ven demasiado. No te das
9:51
Speaker 4: cuenta hasta que un usuario te pregunta por qué un
9:53
Speaker 4: informe se ve diferente para él que para alguien más
9:55
Speaker 4: del mismo equipo. La documentación de Microsoft y un sinfín
9:58
Speaker 4: de publicaciones de MVP advierten constantemente. No confíes en las
10:02
Speaker 4: columnas calculadas para el RLS. Las columnas calculadas se bloquean
10:06
Speaker 4: al actualizar. No cambian según el usuario. Para que la
10:10
Speaker 4: LS responda al espectador, tu lógica de filtro debe crearse
10:13
Speaker 4: como una expresión DAX en tablas que se actualizan en
10:15
Speaker 4: el contexto del informe. Ignora esto y tus términos te
10:19
Speaker 4: traicionarán silenciosamente, mostrando las mismas filas sin importar quién ha
10:22
Speaker 4: iniciado sesión. La RLS estática frente a la dinámica no
10:25
Speaker 4: es solo una distinción técnica. Se trata de cuándo y
10:28
Speaker 4: cómo se filtran los datos. Una RLS estática es rápida
10:33
Speaker 4: y rígida, ideal cuando sabes de antemano exactamente qué rol
10:36
Speaker 4: necesita qué datos. Si lanzas un informe solo para un
10:40
Speaker 4: grupo de finanzas o ventas, esto funciona. Esto funciona. pero
10:44
Speaker 4: al usar la dinámica cada sesión de acceso ocurre al instante,
10:47
Speaker 4: usualmente comparando la identidad del usuario con una entrada en
10:50
Speaker 4: una tabla de permisos. La flexibilidad es poderosa, especialmente para
10:54
Speaker 4: grandes organizaciones o despliegue multiusuario, pero cada paso en flexibilidad
10:58
Speaker 4: añade complejidad, y la complejidad siempre conlleva riesgos ocultos. Incluso
11:03
Speaker 4: los administradores avanzados tropiezan al creer que los filtros son
11:05
Speaker 4: siempre directos. La estructura real de tu organización cambia constantemente
11:09
Speaker 4: y tus filtros DAX deben seguir el ritmo. Muchos fallan
11:13
Speaker 4: porque no comprenden cómo se aplica la lógica RLS, no
11:16
Speaker 4: al cargar datos, sino cada vez que un usuario interactúa
11:19
Speaker 4: con el informe. Olvida eso y podrías abrir o bloquear
11:23
Speaker 4: accidentalmente secciones enteras de tu modelo de datos sin darte cuenta.
11:27
Speaker 4: En conclusión, si los cimientos están mal, nada más de
11:30
Speaker 4: lo que construyas con RLS importará. La forma en que
11:34
Speaker 4: escribes tu DAX, el tipo de filtros que usas y
11:36
Speaker 4: dónde los aplicas, se combinan para definir tu postura de
11:39
Speaker 4: seguridad real. Ignora los matices y terminarás con una configuración
11:43
Speaker 4: que funciona en teoría pero falla en la práctica. Todo
11:46
Speaker 4: esto sucede antes de asignar usuarios a roles que resulta
11:48
Speaker 4: ser el siguiente lugar donde las cosas se tuercen silenciosamente.
11:52
Speaker 4: Asignar roles a usuarios, la trampa de la asignación. Entonces,
11:55
Speaker 4: has configurado tus roles, creado los filtros y todo parece
11:58
Speaker 4: sólido en el modelo. El siguiente paso, asignar usuarios, parece
12:02
Speaker 4: sencillo pero aquí es donde la mayoría de los planes
12:04
Speaker 4: de seguridad a nivel de rol comienzan a agrietarse. Esta
12:07
Speaker 4: es la encrucijada del pensamiento informático que La lógica técnica
12:11
Speaker 4: está lista, pero ahora apuestas a que la capa humana,
12:14
Speaker 4: tus asignaciones de usuarios y grupos realmente coincide con la
12:16
Speaker 4: realidad operativa de tu empresa. Parece simple porque hay un
12:19
Speaker 4: campo de grupo y una lista de roles, pero la
12:21
Speaker 4: experiencia dicta que aquí es donde los errores se esconden.
12:25
Speaker 4: Mi maestro.¿ Has creado un rol de gerente?¿ Le has
12:27
Speaker 4: aplicado tu filtro cuidadosamente diseñado?¿ Y has asignado el rol
12:30
Speaker 4: en Power BI o Fabric a un grupo de Azure
12:33
Speaker 4: AD llamado gerentes?¿ Lo revisas dos veces?¿ Tal vez pides
12:37
Speaker 4: una segunda opinión y lo implementas en la organización? Al
12:40
Speaker 4: principio parece sencillo. Ese es el problema porque la lógica
12:43
Speaker 4: de grupos, especialmente en organizaciones grandes, rara vez permanece simple
12:46
Speaker 4: por mucho tiempo. Los equipos cambian, los departamentos se reorganizan,
12:50
Speaker 4: los roles evolucionan, la gente deja proyectos y se une
12:52
Speaker 4: a otros.¿ Qué sucede si alguien pasa de ventas a
12:54
Speaker 4: operaciones y nadie elimina sus antiguas membresías de grupo? De
12:58
Speaker 4: repente tu esquema hermético de RS tiene a un usuario
13:01
Speaker 4: en dos lugares a la vez. Y existe un riesgo
13:04
Speaker 4: real de que acceda a datos que ya no le
13:05
Speaker 4: corresponden Es fácil asumir que todos en un grupo específico
13:09
Speaker 4: de Azure AD deben tener el mismo acceso, pero en
13:11
Speaker 4: realidad las membresías de los grupos pueden quedar obsoletas. Alguien
13:14
Speaker 4: puede transferirse a una región diferente, pero su nombre nunca
13:17
Speaker 4: sale de la lista original del equipo. Incluso si tú
13:21
Speaker 4: como administrador eres muy disciplinado con la limpieza, los propietarios
13:24
Speaker 4: de los grupos rara vez siguen el ritmo de cada cambio,
13:26
Speaker 4: especialmente en trimestres ocupados. Y recuerda que la sincronización entre
13:31
Speaker 4: Azure AD, Power BI o Fabric no siempre es instantánea.
13:34
Speaker 4: A veces hay horas de retraso y eso es tiempo
13:35
Speaker 4: más que suficiente para que alguien vea algo que no
13:37
Speaker 4: debería tras un cambio. Pero un proceso nocturno y un
13:41
Speaker 4: empleado que se marcha puede irse con mucha más información
13:44
Speaker 4: de la que pretendías. Las asignaciones fantasma pueden sonar dramáticas,
13:48
Speaker 4: pero son casi rutinarias. En la mayoría de los entornos reales,
13:51
Speaker 4: un solo usuario puede terminar fácilmente en múltiples grupos, cada
13:54
Speaker 4: uno asignado a diferentes roles de RLS. Diseño pretende ser flexible,
13:58
Speaker 4: lo cual está bien en teoría. En la práctica, significa
14:01
Speaker 4: hacer malabares con una red de permisos heredados, y no
14:03
Speaker 4: siempre está claro quién puede ver qué, a menos que
14:05
Speaker 4: lo rastrees manualmente. Por ejemplo, si Sara de finanzas se
14:09
Speaker 4: mueve a RR.chachi y nadie la saca del grupo de finanzas,
14:12
Speaker 4: ahora tiene dos roles, uno actual y otro obsoleto. La
14:15
Speaker 4: mayoría ni siquiera lo nota hasta que la misma Sara
14:18
Speaker 4: intenta acceder a un informe de finanzas y sigue entrando
14:21
Speaker 4: mucho después de haberse ido a otro departamento. Los propios
14:25
Speaker 4: equipos de seguridad de Microsoft señalan los errores de asignación
14:28
Speaker 4: de roles como la causa número uno de exposición accidental
14:30
Speaker 4: de datos en entornos de análisis. La matemática es igual.
14:33
Speaker 4: Cuantos más grupos y más usuarios en movimiento haya, más
14:36
Speaker 4: fácil es pasar por alto quien está realmente asignado a
14:39
Speaker 4: cada rol. Lo que lo hace más difícil de detectar
14:42
Speaker 4: es la falta de retroalimentación evidente. A diferencia de otros
14:44
Speaker 4: errores de seguridad, no recibes un mensaje de error ni
14:47
Speaker 4: una falla en la interfaz. Normalmente no hay advertencias automáticas
14:50
Speaker 4: ni revisiones forzadas y una asignación incorrecta puede permanecer oculta
14:54
Speaker 4: por meses, surgiendo solo en una auditoría o cuando alguien
14:56
Speaker 4: descubre datos que no debía tocar. Hasta las mejores intenciones
15:00
Speaker 4: se desvanecen con las realidades del día a día. Revisar
15:03
Speaker 4: las membresías de grupos es una mejor práctica que todos recomiendan,
15:07
Speaker 4: pero pocos equipos siguen con rigor. Desde el punto de
15:10
Speaker 4: vista administrativo, es un trabajo tedioso. Las revisiones manuales de
15:13
Speaker 4: grupos no son una prioridad inmediata, especialmente si el equipo
15:16
Speaker 4: de análisis está resolviendo otros problemas. En la mayoría de
15:19
Speaker 4: las organizaciones no existe un proceso de auditorías periódicas, pues
15:22
Speaker 4: se asume que los cambios en RR se reflejarán automáticamente.
15:26
Speaker 4: Pero estas suposiciones son las que permiten la deriva de
15:28
Speaker 4: permisos y la persistencia de accesos ocultos. El resultado con
15:32
Speaker 4: el tiempo es que su RLS, por preciso que sea
15:34
Speaker 4: en papel, pierde sincronía con quién debería ver qué. Las
15:39
Speaker 4: herramientas de auditoría automatizada ayudan a detectar estas asignaciones persistentes,
15:43
Speaker 4: pero implementarlas requiere esfuerzo. Deben conectarse a su Azure AD
15:47
Speaker 4: y¿ Marcar cambios y quizás activar un flujo de trabajo
15:49
Speaker 4: cuando las membresías de grupo de alguien ya no coinciden
15:51
Speaker 4: con su unidad de negocio? No todos los entornos de
15:54
Speaker 4: Power BI tienen esos controles, especialmente en empresas pequeñas o
15:57
Speaker 4: proyectos con plazos ajustados. Por lo tanto, la proliferación de
16:00
Speaker 4: grupos se vuelve inevitable. Cuanto más tiempo pase su sistema RLS,
16:04
Speaker 4: más probable es que los permisos caduquen, o peor aún,
16:06
Speaker 4: que se propaguen, a capas que ni siquiera está rastreando.
16:10
Speaker 4: Lo que realmente toma a la gente por sorpresa es
16:11
Speaker 4: que las asignaciones no son solo una marca de verificación.
16:14
Speaker 4: son el vínculo continuo que une su lógica de seguridad
16:16
Speaker 4: a personas reales. Si los deja a la deriva, ni
16:19
Speaker 4: los DAC más inteligentes del mundo los salvarán. La higiene
16:22
Speaker 4: de las asignaciones es un proceso activo, no una configuración
16:25
Speaker 4: de más o menos. Los sistemas evolucionan, los usuarios se mueven,
16:27
Speaker 4: su modelo debe seguir esos cambios. O dependerá de la suerte,
16:30
Speaker 4: la suerte no es una estrategia de seguridad. Ahora bien,
16:34
Speaker 4: incluso con los procesos de asignación más estrictos, surge un
16:36
Speaker 4: gran inconveniente al llevar su solución desde Power BI Desktop
16:40
Speaker 4: al entorno real de fábrica. Hasta este punto, la mayoría
16:44
Speaker 4: de los equipos prueban en un entorno local en su
16:46
Speaker 4: propia máquina solo con cuentas de prueba. Todo parece predecible,
16:50
Speaker 4: pero al pasar a Fabric, comienzan a aparecer diferencias sutiles
16:53
Speaker 4: en el contexto del usuario, la resolución de grupos y
16:55
Speaker 4: los tiempos de autenticación. Ahí es donde encontramos las peculiaridades
16:59
Speaker 4: que nadie espera, y por qué las asignaciones que parecen
17:02
Speaker 4: perfectas en teoría pueden fallar espectacularmente en producción. Desde Stop
17:06
Speaker 4: a Fabric, los cambios ocultos, en el comportamiento de RLS...
17:09
Speaker 4: Si alguna vez estuvo convencido de que tenía la seguridad
17:11
Speaker 4: a nivel de fila bajo control en Power BI Desktop,
17:14
Speaker 4: pero vio cómo todo se desmoronaba al publicar en Fabric,
17:17
Speaker 4: está en territorio conocido. Esta es la parte que nadie
17:20
Speaker 4: le cuenta en los tutoriales de RS, el momento en
17:22
Speaker 4: que toda esa lógica impecable de roles y filtros choca
17:25
Speaker 4: de frente con la realidad de la nube. Ha verificado
17:28
Speaker 4: cada filtro, mapeado cuidadosamente cada grupo, e incluso ordenado sus
17:31
Speaker 4: asignaciones de casos excepcionales. Pero en cuanto te pasas al
17:34
Speaker 4: servicio Fabric, las cosas cambian de una forma que toma
17:36
Speaker 4: por sorpresa incluso a los administradores experimentados. Comencemos con lo
17:40
Speaker 4: que ves en desktop. La vista previa funciona exactamente como esperaría.
17:44
Speaker 4: Pruebas los roles de usuario y alternas entre identidades de muestra.
17:47
Speaker 4: Todo encaja a la perfección, los números coinciden y por
17:50
Speaker 4: un momento parece que dominas un proceso sencillo. Pero tan
17:54
Speaker 4: pronto como tus compañeros abren ese mismo archivo de Power
17:57
Speaker 4: BI en la nube, empiezan a llegar los problemas. Alguien
18:00
Speaker 4: reporta ver números fuera de su región o, peor aún,
18:03
Speaker 4: alguien no puede acceder a un conjunto de datos que
18:05
Speaker 4: necesita para trabajar. La frustración crece al darte cuenta de
18:08
Speaker 4: que la misma configuración de RLS que era infalible en
18:10
Speaker 4: tu equipo ahora parece más una sugerencia que una regla.
18:14
Speaker 4: Pero esa confusión se debe a diferencias que no puedes
18:16
Speaker 4: ver realmente hasta que publicas. El entorno en la nube
18:19
Speaker 4: de Fabric opera en un mundo distinto en cuanto a seguridad,
18:22
Speaker 4: identidad y contexto de datos. Una trampa clásica golpea justo
18:26
Speaker 4: en el corazón de los patrones de RSDinámico. En escritorio,
18:29
Speaker 4: una función DAX como Username extrae tu inicio de sesión
18:32
Speaker 4: local de Windows. Simple, predecible y dentro de tu entorno
18:35
Speaker 4: tranquilizadoramente estable. pero en Fabric esa misma llamada username captura
18:39
Speaker 4: tu dirección de correo electrónico completa. Parece menor, pero si
18:42
Speaker 4: tu filtro o búsqueda hace referencia a nombres de dominio,
18:45
Speaker 4: o si tu tabla de seguridad usa formatos cortos en
18:47
Speaker 4: lugar de correos completos, todo el sistema falla en cuanto
18:50
Speaker 4: los usuarios llegan a la nube. Inevitablemente empiezan a llegar
18:53
Speaker 4: las quejas. Esto es lo que sucede en entornos reales.
18:57
Speaker 4: Un informe muestra un desglose por país en el escritorio,
18:59
Speaker 4: pero tras publicar, los usuarios ven números globales. Quizás tu
19:03
Speaker 4: modelo dependía del nombre principal de usuario porque todas tus
19:06
Speaker 4: claves de acceso son direcciones de correo. Es una buena
19:09
Speaker 4: práctica para la nube. Pero si empezaste en escritorio y
19:12
Speaker 4: no sabías que este cambio ocurre, estás depurando un problema
19:14
Speaker 4: que no existe localmente pero explota a escala. La verdad
19:18
Speaker 4: es que lo que funciona en tu portátil es más
19:19
Speaker 4: un prototipo decente que una solución terminada. La lógica local
19:24
Speaker 4: puede ocultar una mina terrestre que es solo la autenticación
19:26
Speaker 4: en la nube activa. También hay algunas palancas invisibles que
19:30
Speaker 4: Fabric mueve sin previo aviso. Las actualizaciones de datos, por ejemplo,
19:33
Speaker 4: pueden ejecutarse con diferentes credenciales o recaer en un propietario
19:36
Speaker 4: de modelo distinto al esperado. Si el propietario del conjunto
19:39
Speaker 4: de datos publicado no está en el grupo correcto, puede
19:41
Speaker 4: terminar sin ver datos o accediendo a todo por accidente.
19:44
Speaker 4: Cambiar la propiedad de la nube no solo afecta a
19:47
Speaker 4: los permisos. Puede romper las conexiones a las puertas de
19:50
Speaker 4: enlace o cambiar cómo se evalúan las credenciales frente a
19:52
Speaker 4: los sistemas de origen. A veces la configuración del inquilino
19:55
Speaker 4: oculta comportamientos heredados o aplica opciones predeterminadas que anulan lo
19:59
Speaker 4: que configuraste durante las pruebas en el escritorio. Para organizaciones
20:03
Speaker 4: con políticas de inquilino por capas algo tan pequeño como
20:05
Speaker 4: cambiar el uso compartido externo puede alterar la lógica de
20:07
Speaker 4: quien ve qué de la noche a la mañana. Lo
20:10
Speaker 4: que confunde a la gente es lo sutiles que son
20:11
Speaker 4: estos cambios. No gritan, oye, tu RSS está roto ahora.
20:15
Speaker 4: En cambio, las cosas funcionan más silenciosamente. Un pequeño cambio
20:18
Speaker 4: en la autenticación o en la forma en que un
20:20
Speaker 4: modelo resuelve la pertenencia a grupos durante el inicio de sesión,
20:22
Speaker 4: muta el contexto de seguridad por completo. Los foros de
20:26
Speaker 4: soporte de Microsoft están llenos de administradores compartiendo historias de
20:29
Speaker 4: terror sobre informes que pasaron todas las pruebas de escritorio
20:31
Speaker 4: solo para desmoronarse. Cuando los usuarios empezaron a acceder a
20:35
Speaker 4: ellos en la nube... Bésilos donde tras un despliegue los
20:39
Speaker 4: equipos luchan por parchear o rediseñar todas sus funciones de RS,
20:42
Speaker 4: no porque la lógica fuera mala, sino porque el traslado
20:45
Speaker 4: a Fabric cambió el contexto de identidad lo suficiente como
20:48
Speaker 4: para hacer todo poco fiable. Incluso las actualizaciones en la
20:52
Speaker 4: nube o las actualizaciones de todo el inquilino pueden empujar
20:54
Speaker 4: la seguridad en nuevas direcciones. A veces, tras una actualización,
20:57
Speaker 4: las asignaciones de grupos gestionadas por Azure AD se sincronizan
21:00
Speaker 4: de forma un poco diferente a la anterior, por lo
21:02
Speaker 4: que las asignaciones fantasma de repente tienen más prioridad o
21:05
Speaker 4: ciertas búsquedas dinámicas encuentran nulos donde esperabas una coincidencia. Los
21:09
Speaker 4: pequeños se acumulan. Un ajuste en una parte de la
21:11
Speaker 4: pila se propaga por toda la red de seguridad y
21:13
Speaker 4: tu patrón más fiable del trimestre pasado simplemente no se
21:16
Speaker 4: sostiene hoy. Es por eso que los equipos del mundo
21:18
Speaker 4: real han comenzado a tratarlas por ADRS como un trabajo
21:21
Speaker 4: de producción, no solo como una verificación local. No basta
21:24
Speaker 4: con hacer clic en las funciones desde tu propio portátil
21:26
Speaker 4: Necesitas preparar realmente el modelo en Fabric, traer cuentas de
21:30
Speaker 4: usuarios reales y recorrer el flujo de permisos de extremo
21:33
Speaker 4: a extremo. Solo entonces detectarás errores de autenticación sutiles o
21:38
Speaker 4: desalineaciones entre las asignaciones de grupo y lo que Power
21:41
Speaker 4: BI considera actual en Azure AD. Algunas organizaciones incluso programan
21:45
Speaker 4: auditorías de RSS periódicas en la nube solo para comprobar
21:48
Speaker 4: si hay desviaciones entre la lógica del modelo de asignación
21:51
Speaker 4: y lo que Fabric aplica realmente. No hay atajos aquí.
21:54
Speaker 4: Si no estás realizando pruebas con personas reales en el
21:57
Speaker 4: entorno donde reside realmente tu informe, tu RLS básicamente funciona
22:00
Speaker 4: por esperanza. La nube es el juez final, y la
22:04
Speaker 4: única forma de ver cómo los filtros y roles interactúan
22:06
Speaker 4: con las identidades a escala es construir tu RLS pensando
22:09
Speaker 4: en la producción desde el principio. Si dejas estas pruebas
22:13
Speaker 4: para después, vas a ciegas y las consecuencias, datos expuestos,
22:16
Speaker 4: equipos frustrados o un trabajo de seguridad cuidadoso deshecho por
22:19
Speaker 4: un interruptor oculto, terminan costando mucho más arreglarlas una vez
22:22
Speaker 4: que el informe está en uso. Ahora, frente a este panorama,
22:26
Speaker 4: la gran pregunta no es solo sobre parchear tu RDS
22:28
Speaker 4: cada vez que algo cambia. Se trata de si tienes
22:31
Speaker 4: un plan que funciona a medida que tu configuración de
22:33
Speaker 4: fabric se vuelve más compleja, tus datos crecen y el
22:35
Speaker 4: modelo de negocio.