Planeamiento de la implementación de Power BI: Planeamiento de la seguridad del consumidor de informes

En este artículo de planificación de seguridad se describen las estrategias para los consumidores de solo lectura. Nos centramos en los permisos de espectador para informes y aplicaciones y cómo hacer cumplir la seguridad de los datos. Se dirige principalmente a:

• Administradores de Power BI: los administradores responsables de supervisar Power BI en la organización.
• Centro de excelencia, equipo de TI y BI: los equipos que también son responsables de supervisar Power BI. Es posible que necesiten colaborar con administradores de Power BI, equipos de seguridad de la información y otros equipos pertinentes.
• Creadores y propietarios de contenido: creadores de BI de autoservicio que necesitan crear, publicar, proteger y administrar contenido que otros usuarios consumen.

La serie de artículos está pensada para ampliar el contenido de las Notas del producto sobre la seguridad de Power BI. Aunque las notas del producto sobre la seguridad de Power BI se centran en temas técnicos clave tales como la autenticación, la residencia de datos y el aislamiento de red, el objetivo principal de la serie es proporcionarle consideraciones y decisiones que le ayuden a planear la seguridad y la privacidad.

En una organización, muchos usuarios se clasifican como consumidores. Los consumidores ven el contenido que otros usuarios han creado y publicado. Los consumidores son el foco de este artículo. Para la planificación de la seguridad centrada en los creadores y propietarios de contenido, consulte el artículo Planificación de la seguridad del creador de contenido.

Para sacar el máximo partido de este artículo, resulta útil comprender el significado de los términos uso compartido y distribución en el contexto de Power BI.

El uso compartido es un acto en el que un usuario proporciona a otro usuario (o grupo de usuarios) acceso a un elemento de contenido específico. La capacidad de hacer uso compartido en el servicio Power BI tiene el ámbito de un elemento. Por lo general, el uso compartido tiene lugar entre individuos que se conocen entre sí y trabajan estrechamente juntos.

La distribución es donde el contenido se entrega a otros usuarios, llamados destinatarios. A menudo implica un mayor número de usuarios en varios equipos. Es posible que los destinatarios no hayan solicitado explícitamente el contenido, pero se reconoce que lo necesitan para realizar su rol. Los destinatarios que consumen el contenido distribuido pueden o no conocer al creador original del contenido. Por lo tanto, el concepto de distribución es más formal que el de uso compartido.

Al hablar con otras personas, determine si usan el término uso compartido de forma general o literalmente. El uso compartido puede interpretar de dos maneras.

• A veces uso compartido se usa de forma general referido a compartir contenido con colegas. Hay varias técnicas para entregar contenido de solo lectura, que se describen en este artículo.
• El uso compartido también es una característica específica de Power BI. Es una funcionalidad en la que se concede acceso a un usuario o grupo a un solo elemento. Este artículo se centra en describir los vínculos de uso compartido y el uso compartido de accesos directos.

Estrategia para consumidores de solo lectura

En el servicio Power BI los consumidores podrán ver un informe o panel cuando tengan permiso para:

• Ver el elemento de Power BI que contiene las visualizaciones (como un informe o panel).
• Lea los datos subyacentes (modelo semántico u otro origen).

Existen técnicas diferentes para proporcionar acceso de solo lectura a los consumidores. Entre las técnicas comunes que usan los creadores de contenido de autoservicio se incluyen las siguientes:

• Conceder a los usuarios y grupos acceso a una aplicación de Power BI.
• Agregar usuarios y grupos a un rol de espectador de área de trabajo de Power BI.
• Proporcionar permisos de usuarios y grupos por elemento mediante un vínculo de uso compartido.
• Proporcionar permisos de usuarios y grupos por elemento mediante un acceso directo.

Las opciones de rol de espectador de áreas de trabajo de Power BI y aplicación de Power BI implican la administración de permisos para un conjunto de elementos. Las dos técnicas de permisos por elemento implican la administración de permisos para un elemento individual.

Al revisar la configuración de seguridad de un elemento, es posible que vea que sus permisos:

• Se han heredado del área de trabajo o de una aplicación.
• Se han aplicado directamente al elemento.

En la captura de pantalla siguiente, se muestran los permisos de acceso directo para un informe. En este caso, el área de trabajo Administración y los roles miembro se asignan a un grupo. Estos roles se muestran para el informe porque el acceso de nivel de informe se hereda del área de trabajo. También hay un usuario que tiene permisos de lectura aplicados directamente al informe.

La estrategia que elija para los consumidores de solo lectura puede ser diferente. Debe basarse en la solución individual, las preferencias de quién administra la solución o las necesidades del consumidor. En el resto de esta sección se describe cuándo se debe considerar el uso de cada una de las técnicas disponibles.

Lista de comprobación: al crear su estrategia para ofrecer contenido a los consumidores de solo lectura, plantéese estas decisiones y acciones:

Permisos en la aplicación de Power BI

Una aplicación de Power BI ofrece una colección de informes, paneles y libros a los consumidores. Una aplicación proporciona la mejor experiencia de usuario para los consumidores por las siguientes razones:

• El panel de navegación de la aplicación proporciona una experiencia de usuario sencilla e intuitiva. Es más agradable que acceder al contenido directamente en un área de trabajo.
• El contenido se puede organizar en secciones lógicas (que son como carpetas) en el panel de navegación de la aplicación.
• Los consumidores solo tienen acceso a elementos específicos que se han incluido explícitamente en la aplicación para su audiencia.
• Los vínculos a información adicional, la documentación y el resto del contenido se pueden agregar al panel de navegación para su audiencia.
• Hay un flujo de trabajo de solicitud de acceso integrado.

Puede crear una aplicación para cada área de trabajo, con el fin de distribuir una parte o todo el contenido del área de trabajo. Las aplicaciones son útiles para distribuir ampliamente contenido dentro de una organización, especialmente con usuarios que no conoce o con quienes no colabora estrechamente.

Los permisos de aplicación se administran por separado de los roles del área de trabajo. Separar los permisos tiene dos ventajas:

• Conceder acceso al área de trabajo a los creadores de contenido: Incluye a los usuarios que colaboran activamente en el contenido, como los creadores de modelos semánticos, los creadores de informes y los probadores.
• Conceder permisos de aplicación a los consumidores: a diferencia de los permisos del área de trabajo, si se concede un permiso de aplicación, este es exclusivamente de solo lectura.

Todos los usuarios con acceso al área de trabajo pueden ver automáticamente la aplicación (cuando se haya publicado una aplicación de Power BI para el área de trabajo). Debido a este comportamiento, puede considerar conceptualmente los roles de área de trabajo como heredados por cada audiencia de aplicaciones. Algunos usuarios con acceso al área de trabajo también pueden actualizar la aplicación Power BI, en función de su rol de área de trabajo asignada.

El uso de una aplicación para distribuir contenido a consumidores de solo lectura es la mejor opción cuando:

• Quiere que los usuarios puedan ver solo elementos específicos que sean visibles para esa audiencia (en lugar de todos los elementos del área de trabajo subyacente).
• Quiere administrar permisos de solo lectura para la aplicación por separado del área de trabajo.
• Quiere una administración de permisos más sencilla para los usuarios de solo lectura que los permisos por elemento.
• Quiere asegurarse de que la seguridad a nivel de fila se aplica a los consumidores (cuando tienen permiso de solo lectura en el modelo semántico subyacente).
• Quiere asegurarse de que los consumidores no puedan ver los informes nuevos y modificados hasta que se vuelva a publicar la aplicación.

Aunque que los cambios en los informes y paneles no son visibles para los usuarios de la aplicación hasta que se vuelva a publicar la aplicación, hay dos consideraciones que requieren precaución.

• Cambios inmediatos del modelo semántico: Los cambios del modelo semántico siempre tienen efecto inmediato. Por ejemplo, si se introducen cambios de última hora en un modelo semántico del área de trabajo, los informes podrían volverse inestables sin querer (aunque no se hayan vuelto a publicar en la aplicación). Hay dos maneras de mitigar este riesgo. Primero, realice todo el trabajo de desarrollo en Power BI Desktop (fuera del área de trabajo). Segundo, aísle la aplicación de producción mediante áreas de trabajo independientes para desarrollo y pruebas. (Opcionalmente, puede lograr un mayor nivel de control sobre la implementación del contenido del área de trabajo desde el desarrollo hasta la prueba y producción mediante las canalizaciones de implementación).
• El contenido y los permisos se publican juntos: al publicar una aplicación, sus permisos se publican al mismo tiempo que el contenido. Por ejemplo, puede haber cambios de informe en un área de trabajo que aún no se han completado, probado exhaustivamente o aprobado. Por ello, no puede volver a publicar la aplicación para actualizar exclusivamente los permisos. Para mitigar este riesgo, asigne permisos de aplicación a grupos de seguridad y use pertenencias a grupos de seguridad (en lugar de usuarios individuales) al conceder permisos de aplicación. Evite volver a publicar una aplicación simplemente para aplicar cambios de permisos.

Audiencia de aplicación

Cada área de trabajo del servicio Power BI solo puede tener una aplicación de Power BI. Sin embargo, dentro de la aplicación puede crear una o varias audiencias. Considere el siguiente escenario:

• Tiene cinco informes de ventas que se distribuyen a muchos usuarios en toda la organización de ventas global.
• Una audiencia se define en la aplicación para los representantes de ventas. Esta audiencia puede ver tres de los cinco informes.
• Otra audiencia se define en la aplicación para el equipo de liderazgo de ventas. Esta audiencia puede ver los cinco informes, incluidos los dos informes que no están disponibles para los representantes de ventas.

Esta capacidad para asociar contenido y audiencias tiene las siguientes ventajas.

• Algunos informes pueden estar disponibles para su visualización por parte de varias audiencias. Por lo tanto, la creación de varias audiencias elimina la necesidad de duplicar el contenido en diferentes áreas de trabajo.
• Algunos informes pueden estar disponibles solo para una audiencia. Por lo tanto, el contenido de esa audiencia puede residir en la misma área de trabajo que otro contenido relacionado.

En la captura de pantalla siguiente se muestra una aplicación con dos audiencias: Sales Leadership (Liderazgo de ventas) y Sales Reps (Representantes de ventas). El panel Manage Audience Access (Administrar acceso de audiencia) proporciona acceso al grupo de audiencias de Sales Leadership para dos grupos de seguridad: Sales Leadership-North America (Liderazgo de ventas: Norteamérica) y Sales Leadership-Europe (Liderazgo de ventas: Europa). El informe Gross Margin Analysis (Análisis de margen bruto) que se muestra en la captura de pantalla del grupo de audiencias Sales Leadership no está disponible para el grupo de audiencias Sales Reps.

Al administrar permisos para una aplicación, en la página Acceso directo puede ver los miembros de cada audiencia. También puede ver que los usuarios con un rol de área de trabajo aparecen en Todas las audiencias. No se pueden actualizar los permisos de la aplicación desde la página Acceso directo. En su lugar, debe volver a publicar la aplicación. Sin embargo, puede actualizar los permisos de la aplicación desde la página Pendiente cuando haya solicitudes de acceso abiertas para la aplicación.

Opciones de permisos de aplicación

Al crear (o volver a publicar) una aplicación, cada audiencia tiene un panel Administrar acceso de audiencia. En ese panel, están disponibles los siguientes permisos.

• Conceder acceso a: para cada audiencia, puede conceder acceso a usuarios y grupos individuales. Es posible publicar la aplicación en toda la organización si se ha habilitado mediante la configuración de inquilino Publicar aplicaciones en toda la organización y la aplicación no se instala automáticamente. Siempre que sea posible, se recomienda asignar grupos a audiencias, porque agregar o quitar usuarios implica volver a publicar la aplicación. Todos los usuarios con acceso al área de trabajo tienen permiso automáticamente para ver o actualizar la aplicación en función de su rol de área de trabajo.
• Permisos de modelo semántico: Se pueden conceder dos tipos de permisos de modelo semántico al publicar una aplicación:
  • Volver a compartir el modelo semántico: Cuando se habilita, se concede a los usuarios de la app el permiso de Volver a compartir con otros modelos semánticos subyacentes. Tiene sentido habilitar esta opción cuando los modelos semánticos subyacentes pueden compartirse fácilmente con cualquiera. Le recomendamos que obtenga la aprobación de los propietarios del modelo semántico antes de conceder el permiso de volver a compartir al público de una aplicación.
  • Creación de modelos semánticos: Cuando se habilita, se concede a los usuarios de la app el permiso Crear para los modelos semánticos. Con el permiso de compilación los usuarios pueden crear nuevos informes, exportar datos subyacentes de informes, etc. Le recomendamos que obtenga la aprobación de los propietarios del modelo semántico antes de conceder el permiso de creación al público de una aplicación.

La posibilidad de agregar el modelo semántico Volver a compartir o Crear permisos al publicar una aplicación es conveniente. Sin embargo, le recomendamos que considere la posibilidad de administrar los permisos de la aplicación y los permisos del modelo semántico por separado. Estas son las razones:

• El modelo semántico compartido puede estar en un área de trabajo separada: Si el modelo semántico se publica en un área de trabajo separada de la aplicación, tendrá que administrar sus permisos directamente. La posibilidad de agregar permisos de lectura, creación o uso compartido al publicar una aplicación solo funciona para los modelos semánticos que se encuentran en la misma área de trabajo que la aplicación. Por este motivo, le recomendamos que se acostumbre a administrar los permisos de los modelos semánticos de forma independiente.
• Los permisos del modelo semántico se administran por separado: Si elimina o cambia los permisos de una app, esa acción solo afecta a la app. No elimina automáticamente ningún permiso de modelo semántico que se haya asignado previamente. De este modo, se puede pensar que los permisos de la aplicación y los permisos del modelo semántico están desacoplados. Tendrá que administrar el modelo semántico directamente, por separado de la aplicación, cuando los permisos del modelo semántico cambien o deban eliminarse.
• Los permisos del modelo semántico deben ser controlados: Conceder permisos de modelo semántico a través de una app quita el control al propietario del modelo semántico. La concesión del permiso para volver a compartir se basa en el buen juicio de los usuarios que deciden volver a compartir el modelo o modelos semánticos. La gobernanza interna o las directrices de seguridad pueden resultar más difíciles de administrar cuando se permite volver a compartir.
• Los consumidores y creadores tienen objetivos diferentes: normalmente, hay muchos más consumidores de contenido que creadores en una organización. De acuerdo con el principio del mínimo privilegio, los consumidores solo necesitan permiso de lectura para el modelo semántico subyacente. No necesitan el permiso de compilación a menos que tengan intención de crear nuevos informes.

Derechos de preinstalación de la aplicación

Cuando publique una aplicación de Power BI, un usuario normalmente tendrá que instalarla para poder abrirla. El usuario puede instalar una aplicación desde la página Aplicaciones del servicio Power BI o mediante un vínculo que haya recibido de otro usuario. Podrá encontrar (e instalar) una aplicación cuando se incluyan en al menos una audiencia de la aplicación.

Un enfoque alternativo para instalar una aplicación es insertarla para los consumidores de la aplicación. Esto da como resultado la preinstalación de la aplicación para que aparezca automáticamente en la página Aplicaciones del servicio Power BI. Esto es más cómodo para los consumidores porque no necesitan encontrar e instalar la aplicación. Sin embargo, las aplicaciones preinstaladas pueden ser una molestia para los usuarios, ya que pueden terminar con demasiadas aplicaciones que no son relevantes para ellos.

La configuración Insertar aplicaciones en el inquilino de los usuarios finales controla quién puede instalar automáticamente las aplicaciones. Se recomienda usar esta característica porque es práctica para los usuarios. Sin embargo, también se recomienda educar a los creadores de contenido para que hagan un uso conveniente y moderado de la misma.

Lista de comprobación: al crear la estrategia para usar aplicaciones para espectadores de contenido, las decisiones y las acciones clave incluyen:

Rol de espectador del área de trabajo

Como se describe en los artículos de planificación del área de trabajo, el propósito principal de un área de trabajo es la colaboración. Los colaboradores del área de trabajo, como los creadores de modelos semánticos, los creadores de informes y los probadores, deben ser asignados a uno de estos tres roles: Colaborador, Miembro o Administrador. Estos roles se describen en el artículo Planificación de la seguridad del creador de contenidos.

Puede asignar el rol de espectador del área de trabajo a los consumidores. Permitir que los consumidores accedan al contenido directamente en un área de trabajo puede tener sentido para los equipos pequeños y los equipos informales que trabajan estrechamente juntos.

Permitir que los consumidores accedan directamente al contenido del área de trabajo es una buena opción cuando:

• La formalidad de una aplicación, con sus permisos independientes, no sea necesaria.
• Los espectadores puedan ver todos los elementos almacenados en el área de trabajo.
• Se desea una administración de permisos más sencilla que los permisos por elemento.
• Los usuarios del área de trabajo también puedan ver una aplicación (cuando se publica una aplicación para el área de trabajo).
• La intención sea que los espectadores revisen el contenido antes de publicarlo en una aplicación.

Estas son algunas sugerencias para admitir espectadores de áreas de trabajo.

• Organice el contenido en cada área de trabajo para que los consumidores del informe encuentren fácilmente los elementos y estos se alineen bien con la seguridad. La organización del área de trabajo por área de asunto o proyecto suele funcionar bien.
• Separe el contenido de desarrollo y prueba del contenido de producción para que los espectadores no puedan acceder a los elementos de trabajo en curso.
• Use aplicaciones (o permisos por elemento cuando corresponda) cuando espere que se procesen muchas solicitudes de acceso. No hay un flujo de trabajo de solicitud de acceso para áreas de trabajo.

Lista de comprobación: al crear la estrategia para usar áreas de trabajo para espectadores de contenido, las decisiones y las acciones clave incluyen:

Permisos por elemento

El uso compartido de elementos individuales concede permiso a un solo elemento. Los creadores de contenido menos experimentados suelen usar esto como la técnica de uso compartido principal porque los comandos de uso compartido se muestran de forma destacada en el servicio Power BI. Por este motivo, es importante educar a los creadores de contenido sobre las diferentes opciones de uso compartido. Por ejemplo, cuándo usar permisos de aplicación en lugar de roles de área de trabajo.

Los permisos por elemento son una buena opción cuando:

• Quiera proporcionar acceso de solo lectura a un elemento (informe o panel).
• No quiera que el consumidor vea todo el contenido publicado en un área de trabajo.
• No quiera que el consumidor vea todo el contenido publicado en un audiencia de aplicación.

Use permisos por elemento con moderación porque el uso compartido concede permiso de lectura a un solo elemento. Una forma de entender los permisos por elemento es considerarlos como una invalidación de los roles de área de trabajo o los permisos de aplicación.

Compartir muchos elementos mediante permisos por elemento puede ser tedioso y propenso a errores, especialmente cuando se comparten con usuarios individuales en lugar de grupos. Considere este ejemplo: tiene 40 informes que ha compartido con sus compañeros mediante sus cuentas de usuario individuales. Cuando se transfiera a un compañero a otro departamento, deberá revocar su acceso, lo que implicará permisos de edición para los 40 informes.

Al compartir un elemento individual, tiene varias opciones de permiso.

• Permiso para volver a compartir: Cuando está habilitado, los usuarios pueden compartir el elemento con otros usuarios, incluidos sus modelos semánticos subyacentes. Tiene sentido conceder este permiso cuando el elemento se pueda compartir fácilmente con cualquier persona. El control se quita de la persona o equipo que administra el elemento y se confía en que los usuarios a los que se les haya concedido el permiso de volver a compartir lo usen con prudencia. Sin embargo, tenga en cuenta que la gobernanza interna o las directrices de seguridad pueden ser más difíciles de administrar con este permiso.
• Permiso de creación: Cuando se habilita, se concede a los usuarios el permiso Crear para el modelo semántico subyacente. El permiso de creación permite a los usuarios crear nuevos contenidos basados en el modelo semántico. También les permite exportar datos subyacentes de informes, etc. Las consideraciones para conceder el permiso de compilación se describen en el artículo Planificación de seguridad del creador de contenido.

Los permisos por elemento para informes y paneles pueden tener sentido en escenarios informales cuando el contenido se comparta con algunos usuarios. Es recomendable educar a los usuarios sobre la administración de permisos con aplicaciones y áreas de trabajo, especialmente cuando comparten contenido con un gran número de usuarios o con usuarios fuera de su equipo. Es importante destacar los siguientes puntos.

• Resulta más difícil determinar qué contenido se ha compartido con qué usuarios, ya que los permisos de cada informe y panel deben revisarse individualmente.
• En muchos casos, se establece el permiso de volver a compartir porque la experiencia del usuario habilita esta opción de forma predeterminada. Por lo tanto, existe el riesgo de que el contenido se comparta con un conjunto más amplio de usuarios de lo previsto. Puede evitar este resultado si desactiva la opción Permitir que los destinatarios compartan este informe cuando se realiza el uso compartido. Para minimizar el uso compartido excesivo se debe educar al usuario. El creador de contenido que establece los permisos de uso compartido debe tener en cuenta esta opción cada vez.
• Todos los cambios en los informes y paneles son visibles inmediatamente por los demás, lo que puede confundir a los usuarios cuando las modificaciones de contenido son un trabajo en curso. Este posible problema se puede mitigar si distribuye el contenido en una aplicación o si usa áreas de trabajo independientes para separar el contenido de desarrollo, prueba y producción. Para obtener más información, consulte el escenario de uso de publicación de contenido de autoservicio.
• Cuando un usuario comparte contenido de su área de trabajo personal y sale de la organización, el equipo de TI normalmente deshabilita su cuenta de usuario. En este caso, todos los destinatarios del contenido compartido perderán inmediatamente el acceso al contenido.

Hay tres tipos específicos de uso compartido: vínculos de uso compartido, uso compartido de accesos directos y vistas compartidas.

Vínculos de permisos por elemento

Al compartir un elemento individual, la experiencia predeterminada da como resultado un vínculo de uso compartido. Hay tres tipos de vínculos de uso compartido.

• Personas de su organización: cuando se habilita en la configuración del inquilino de Power BI, este tipo de vínculo de uso compartido facilita proporcionar acceso de solo lectura a todos los usuarios de la organización. Sin embargo, el vínculo de uso compartido no funcionará para los usuarios externos. Esta opción es más adecuada para cuando cualquier usuario pueda ver el contenido y el vínculo se pueda compartir libremente en toda la organización. A menos que esté deshabilitado en la configuración del inquilino Permitir que los vínculos para compartir den acceso a todos los miembros de su organización, este tipo de uso compartido será el valor predeterminado.
• Personas con acceso existente: esta opción no crea un nuevo vínculo de uso compartido. En su lugar, le permite recuperar la dirección URL para que pueda enviarla a alguien que ya tenga acceso.
• Personas específicas: esta opción genera un vínculo de uso compartido para usuarios o grupos específicos. Se recomienda usar esta opción la mayor parte del tiempo, ya que proporciona acceso específico. Si normalmente trabaja con usuarios externos, puede usar este tipo de vínculo para los usuarios invitados que ya existen en microsoft Entra ID. Para obtener más información sobre el proceso de invitación planeado para crear usuarios invitados, consulte el artículo Planificación de la seguridad a nivel de inquilino.

Un vínculo de uso compartido agrega permiso de lectura al elemento. El permiso de volver a compartir está seleccionado de forma predeterminada. También es posible agregar el permiso Crear al modelo semántico subyacente al mismo tiempo que se crea el vínculo de uso compartido.

Los vínculos de uso compartido son más fáciles de mantener que el uso compartido de acceso directo, especialmente cuando es necesario realizar cambios en masa. Esto es una ventaja significativa cuando se conceden permisos de uso compartido a usuarios individuales más que a los grupos (lo que suele ocurrir cuando los usuarios de autoservicio son responsables de administrar permisos). Tenga en cuenta las siguientes comparaciones.

• Vínculo de uso compartido: se concede acceso a 20 usuarios individuales con un vínculo de uso compartido. Hacer un solo cambio en el vínculo sirve para los 20 usuarios.
• Acceso directo: se concede a 20 personas acceso directo a un elemento. Para realizar un cambio, se deben modificar los 20 permisos de usuario.

Permisos de acceso directo por elemento

También puede lograr permisos por elemento mediante el acceso directo. El acceso directo implica configurar los permisos para un solo elemento. También puede determinar los permisos heredados derivados de los roles del área de trabajo.

Cuando se concede acceso directo a un usuario, se le concede permiso de lectura para el elemento. El permiso Volver a compartir está seleccionado por defecto, al igual que el permiso Crear para el modelo semántico subyacente. Le recomendamos que enseñe a los creadores de contenido a habilitar el permiso Crear solo cuando el consumidor de este informe sea también un creador de contenido que pueda necesitar crear informes, exportar datos o crear modelos compuestos a partir del modelo semántico subyacente.

Vistas compartidas

Use una vista compartida para compartir una perspectiva filtrada de un informe con otro usuario. Puede publicar una vista compartida mediante un vínculo de uso compartido o mediante un acceso directo.

Las vistas compartidas son un concepto temporal. Expiran automáticamente después de 180 días. Por este motivo, las vistas compartidas son más adecuadas para escenarios de uso compartido informal y temporal. Asegúrese de que los usuarios conozcan esta limitación.

Lista de comprobación: al crear la estrategia para usar permisos por elemento, las decisiones y las acciones clave incluyen:

Otras técnicas de consulta de consumidor

Las herramientas más comunes para que los consumidores interactúen con Power BI son las aplicaciones, las áreas de trabajo y los permisos por elemento (ya descritos en este artículo).

Sin embargo, también existen otras técnicas que los consumidores pueden usar para consultar datos de Power BI. Cada una de las siguientes técnicas de consulta requiere el permiso de creación de modelos semánticos o datamart.

• Analyze in Excel: Los consumidores que prefieran utilizar Excel pueden consultar un modelo semántico de Power BI mediante Analyze in Excel. Esta funcionalidad es una excelente alternativa a la exportación de datos a Excel porque los datos no están duplicados. Con una conexión dinámica al modelo semántico, los usuarios pueden crear tablas dinámicas, gráficos y segmentaciones. Después, pueden publicar el libro en un área de trabajo en el servicio Power BI, lo que permite a los consumidores abrirlo e interactuar con él.
• Punto de conexión XMLA: Los consumidores pueden consultar un modelo semántico conectándose al punto de conexión XMLA. Una aplicación compatible con XMLA puede conectarse, consultar y consumir un modelo semántico almacenado en un área de trabajo Premium. Esta capacidad es útil cuando los consumidores desean utilizar un modelo semántico de Power BI como fuente de datos para una herramienta de visualización de datos fuera del ecosistema de Microsoft.
• Editor de Datamart: los consumidores pueden consultar un datamart de Power BI mediante el editor de datamart. Es un editor de consultas visuales basado en web para crear consultas sin código. También hay un editor SQL basado en web por si los consumidores prefieren escribir consultas SQL. Ambos editores consultan la base de datos administrada Azure SQL Database que subyace al datamart de Power BI (en lugar del modelo semántico incorporado).
• Punto de conexión de SQL: los consumidores pueden consultar un datamart de Power BI mediante el punto de conexión de SQL. Pueden usar herramientas como Azure Data Studio o SQL Server Management Studio (SSMS) para ejecutar consultas SQL. El punto de conexión SQL dirige las consultas a la base de datos Azure SQL administrada que subyace a la tabla de datos de Power BI (en lugar del modelo semántico incorporado).

Para obtener más información sobre el permiso de compilación, consulte el artículo Planificación de seguridad del creador de contenido.

Lista de comprobación: al planear qué técnicas de consulta usarán los consumidores, las decisiones clave y las acciones incluyen:

Solicitud del flujo de trabajo de acceso para consumidores

Al compartir contenido, es habitual que un usuario reenvíe un vínculo (URL) a otro. Cuando el destinatario intenta ver el contenido y detecta que no tiene acceso a él, puede seleccionar el botón Solicitar acceso. Esta acción inicia el flujo de trabajo Solicitar acceso. A continuación, se le pide al usuario que proporcione un mensaje para explicar por qué desea acceder.

Existe un flujo de trabajo de solicitud de acceso para:

• Acceso a una aplicación de Power BI.
• Acceso a un elemento, como un informe o panel.
• Acceso a un modelo semántico. Para obtener más información sobre el flujo de trabajo Solicitar acceso cuando un modelo semántico se puede descubrir, consulte el artículo Planificación de la seguridad del creador de contenidos.

Solicitudes de acceso para una aplicación

Hay dos maneras de obtener información sobre las solicitudes de acceso pendientes que se han enviado para una aplicación.

• Correo electrónico: el contacto o contactos de la aplicación reciben una notificación por correo electrónico. De forma predeterminada, este contacto es el publicador de la aplicación. Para proporcionar una mejor compatibilidad con las aplicaciones críticas, se recomienda establecer el contacto en un grupo que pueda responder rápidamente a las solicitudes de acceso.
• Menú de administración de permisos: los administradores y miembros del área de trabajo pueden ver, aprobar o rechazar solicitudes de acceso. La página Administrar permisos está disponible en la página Aplicaciones y se puede abrir para cada aplicación. Esta funcionalidad también está disponible para los colaboradores del área de trabajo cuando la opción Permitir a los colaboradores actualizar la aplicación para esta área de trabajo está habilitada.

Las solicitudes de acceso pendientes para una aplicación muestran el mensaje proporcionado por el usuario. Cada solicitud pendiente se puede aprobar o rechazar. Al elegir aprobar una solicitud, se debe seleccionar una audiencia de la aplicación.

En la captura de pantalla siguiente se muestra una solicitud de acceso pendiente de un usuario. Para aprobarla, se debe seleccionar una de las dos audiencias de la aplicación, Sales Reps (Representantes de ventas) o (Sales Leadership) Liderazgo de ventas.

Al publicar una aplicación, el contenido y los permisos se publican al mismo tiempo. Como se ha descrito anteriormente, no es posible publicar solo los permisos de la aplicación sin cambiar también el contenido. Sin embargo, hay una excepción: al aprobar una solicitud de acceso pendiente (como la que se muestra en la captura de pantalla anterior), el cambio de permiso se produce sin publicar el contenido más reciente en el área de trabajo.

Solicitudes de acceso al área de trabajo

Los usuarios que pertenecen al rol de administrador o al rol de miembro conceden acceso al área de trabajo.

Un usuario que intenta ver un área de trabajo recibe un mensaje de acceso denegado cuando no es miembro de un rol de área de trabajo. Dado que no hay un flujo de trabajo integrado de acceso a solicitudes para áreas de trabajo, son más recomendables para equipos pequeños o para equipos informales que trabajan estrechamente juntos. Esta es una de las razones por las que una aplicación de Power BI es más adecuada para equipos más grandes y contextos de distribución de contenido más amplios.

Solicitudes de acceso por elemento

Hay dos maneras de obtener información sobre las solicitudes de acceso pendientes que se han enviado para una aplicación.

• Correo electrónico: el contacto o contactos del elemento reciben una notificación por correo electrónico. Para proporcionar una mejor compatibilidad con los informes críticos, se recomienda establecer el contacto en un grupo que pueda responder rápidamente a las solicitudes de acceso.
• Menú Administrar permisos: los administradores y miembros del área de trabajo pueden acceder a la página Administrar permisos para cada elemento. Pueden ver, aprobar o rechazar las solicitudes pendientes de acceso.

Administración de solicitudes de acceso con grupos

Cuando un usuario envía el formulario de Solicitud de acceso a un elemento de Power BI (como un informe o un modelo semántico) o a una aplicación de Power BI, la solicitud se envía para un usuario individual. Sin embargo, muchas organizaciones grandes necesitan usar grupos para cumplir con sus directivas de seguridad internas.

Se recomienda usar grupos, en lugar de personas, para proteger el contenido siempre que convenga este fin. Para obtener más información sobre la planificación de grupos, consulte el artículo Planificación de la seguridad a nivel de inquilino.

Si piensa proporcionar acceso a grupos en lugar de a usuarios individuales, el propietario del contenido o el administrador que está procesando la solicitud de acceso deberá completar la solicitud en varios pasos:

1. Rechazar la solicitud pendiente en Power BI (porque está asociada a un usuario individual).
2. Agregar el solicitante al grupo correcto según el proceso actual.
3. Notificar al solicitante que ahora tiene acceso.

Lista de comprobación: al planear el flujo de trabajo Solicitar acceso, las decisiones clave y las acciones incluyen:

Cumplimiento de la seguridad de los datos en función de la identidad del consumidor

Puede planear la creación de menos modelos semánticos e informes aplicando la seguridad de los datos. El objetivo es aplicar la seguridad de los datos en función de la identidad del usuario que está viendo el contenido.

Por ejemplo, digamos que puede compartir un único informe de ventas con todos los vendedores (consumidores), y sabe que cada vendedor solo verá los resultados de ventas de su región. Este enfoque le permite evitar la complejidad de crear informes independientes por cada región que deban compartirse con los vendedores de esa región de ventas.

Algunas organizaciones tienen requisitos específicos para los modelos semánticos o datamarts avalados (certificados o promovidos). En el caso de los datos que se usarán ampliamente, puede haber un requisito para usar la seguridad de los datos.

Puede proteger los datos de varias maneras.

• Modelo semántico de Power BI: Como creador de datos de Power BI, puede aplicar la seguridad a nivel de fila (RLS) y la seguridad a nivel de objeto (OLS). RLS implica definir roles y reglas que filtran las filas del modelo de datos, mientras que OLS restringe el acceso a tablas o columnas específicas. Estas reglas definidas de RLS y OLS no se aplican a las referencias almacenadas fuera del modelo semántico, como la segmentación de datos y las selecciones de filtros. Las técnicas RLS y OLS se describen más adelante en esta sección.
• Analysis Services: Un modelo semántico de conexión dinámica puede conectarse a un modelo de datos remoto, que está alojado en Azure Analysis Services (AAS) o en SQL Server Analysis Services (SSAS). El modelo remoto puede hacer cumplir RLS o OLS en función de la identidad del consumidor.
• Origen de datos: Algunos orígenes de datos, como Azure SQL Database, pueden hacer cumplir RLS. En este caso, el modelo de Power BI puede aprovechar la seguridad existente en lugar de volver a definirla. Ese enfoque puede ser una ventaja significativa cuando el RLS definido en el origen sea complejo. Puede desarrollar y publicar un modelo DirectQuery y establecer las credenciales de origen de datos del modelo semántico en el servicio Power BI para habilitar el inicio de sesión único (SSO). Cuando un consumidor de informes abra un informe, Power BI pasará su identidad al origen de datos. A continuación, el origen de datos aplica RLS en función de la identidad del consumidor del informe. Para obtener más información sobre Azure SQL Database RLS, consulte este artículo.

Seguridad de nivel de fila

La seguridad de nivel de fila (RLS) permite a un modelador de datos restringir el acceso a un subconjunto de datos. Normalmente se usa para asegurarse de que algunos consumidores de informes no puedan ver datos específicos, como los resultados de ventas de otras regiones de ventas.

Tenga cuidado, ya que si un informe de Power BI hace referencia a una fila con RLS configurado, se mostrará el mismo mensaje para un campo eliminado o inexistente. estos usuarios pensarían que el informe ha dejado de funcionar.

Hay dos pasos para configurar RLS: reglas y asignaciones de roles.

Reglas RLS

Para los modelos semánticos, un modelador de datos puede configurar RLS en Power BI Desktop creando uno o más roles. Un rol tiene un nombre único en el modelo y normalmente incluye una o varias reglas. Las reglas aplican filtros en las tablas del modelo mediante expresiones de filtro de DAX (expresiones de análisis de datos). De forma predeterminada, un modelo no tiene roles.

Las expresiones de regla se evalúan dentro del contexto de fila. El contexto de fila significa que la expresión se evalúa para cada fila mediante los valores de columna de esa fila. Cuando la expresión devuelve TRUE, el usuario puede ver la fila. Puede definir reglas estáticas o dinámicas.

• Reglas estáticas: se usan expresiones DAX que hacen referencia a constantes, como [Region] = "Midwest".
• Reglas dinámicas: se usan funciones DAX específicas que devuelven valores de entorno (en lugar de constantes). Los valores del entorno se devuelven a partir de tres funciones DAX específicas: USERNAME, USERPRINCIPALNAME y CUSTOMDATA. La definición de reglas dinámicas es sencilla y eficaz cuando una tabla de modelo almacena los valores de nombre de usuario. Permite aplicar un diseño RLS controlado por datos.

Asignaciones de rol RLS

Después de publicar el modelo en el servicio Power BI, debe configurar las asignaciones de roles con antelación para los usuarios que acceden a los informes relacionados. La asignación de roles implica asignar objetos de seguridad de Microsoft Entra a los roles. Los objetos de seguridad pueden ser cuentas de usuario o grupos de seguridad.

Cuando sea posible, se recomienda asignar roles a grupos de seguridad. De este modo, habrá menos asignaciones y el propietario del grupo puede controlar la administración de pertenencia a grupos.

Se recomienda que la información de la cuenta de seguridad de Microsoft Entra esté disponible para los creadores de contenido. Una opción es crear un flujo de datos con datos que se mantienen sincronizados con Microsoft Entra ID. De este modo, los creadores de contenidos pueden integrar los datos de flujo de datos para producir un modelo semántico basado en datos.

Experiencia del usuario de RLS

Algunas organizaciones deciden usar RLS como una capa extra de seguridad, además de los permisos estándar de Power BI. A modo de ejemplo, digamos que comparte un vínculo a un informe con toda la organización. A cualquier usuario que vea el informe se le debe asignar a un rol de RLS para poder ver los datos en el informe. Si no están asignados a un rol de RLS, no verán ningún dato.

La presencia de RLS cambia la experiencia predeterminada para los consumidores.

• Cuando RLS no está definido para el modelo semántico: Los creadores y consumidores con al menos permiso de Lectura en el modelo semántico pueden ver todos los datos del modelo semántico.
• Cuando RLS está definido en el modelo semántico: Los creadores y consumidores que solo tengan permiso de Lectura en el modelo semántico solo podrán ver los datos que tienen permiso para ver (en función de su asignación de roles RLS).

Cuando un usuario visualiza un informe en un área de trabajo o en una aplicación, el RLS puede aplicarse o no en función de los permisos de su modelo semántico. Por este motivo, es fundamental que los consumidores y creadores de contenidos solo posean permiso de lectura sobre el modelo semántico subyacente cuando deba aplicarse el RLS.

Estas son las reglas de permisos que determinan si se impone el cumplimiento de RLS.

• El usuario tiene permiso de lectura sobre el modelo semántico: RLS se aplica para el usuario.
• El usuario tiene permisos de Lectura y Creación en el modelo semántico: RLS se aplica para el usuario.
• El usuario tiene permiso de escritura en el modelo semántico: RLS no se aplica al usuario, lo que significa que puede ver todos los datos del modelo semántico. El permiso de escritura permite editar un modelo semántico. Se puede conceder de dos maneras:
  • Con los roles de área de trabajo Colaborador, Miembro o Administrador (para el área de trabajo donde se almacena el modelo semántico).
  • Con el permiso de modelo semántico de escritura por elemento.

Para más información sobre RLS, consulte Restringir el acceso a los datos del modelo de Power BI.

RLS para datamarts

Los datamarts de Power BI también pueden hacer cumplir RLS. Sin embargo, la implementación es diferente.

La principal diferencia es que RLS para datamarts se configura en el servicio Power BI, en lugar de Power BI Desktop.

Otra diferencia es que los datamarts aplican RLS tanto en el modelo semántico como en la base de datos Azure SQL Database administrada asociada al datamart. La aplicación de RLS en ambas capas proporciona coherencia y flexibilidad. Los mismos filtros RLS se aplican independientemente de cómo el usuario consulte los datos, ya sea conectándose al modelo semántico o a la base de datos Azure SQL administrada.

Para más información, consulte RLS para datamarts.

Seguridad de nivel de objeto

La seguridad de nivel de objeto (OLS) permite a un modelador de datos restringir el acceso a tablas y columnas específicas, y a sus metadatos. Normalmente, se usa OLS para asegurarse de que las columnas confidenciales, como el salario de los empleados, no son visibles para determinados usuarios. Aunque no es posible restringir el acceso a las medidas, cualquier medida que haga referencia a una columna restringida se restringirá.

Considere un ejemplo de una tabla de empleados. Contiene columnas que almacenan el nombre del empleado y el número de teléfono, así como el salario. Puede usar OLS para asegurarse de que solo determinados usuarios, como el personal sénior de Recursos Humanos, puedan ver los valores de salario. Para aquellos usuarios que no pueden ver los valores de salario, es como si esa columna no existiera.

Tenga cuidado, ya que si un objeto visual de informe de Power BI incluyera el salario, los usuarios que no tienen acceso a ese campo recibirían un mensaje de error. El mensaje les informaría de que el objeto no existe y estos usuarios pensarían que el informe ha dejado de funcionar.

Actualmente no hay una interfaz en Power BI Desktop para configurar OLS. Puede usar el Editor tabular, que es una herramienta de terceros para crear, mantener y administrar modelos. Para obtener más información, consulte los escenarios de uso de administración avanzada de modelos de datos.

Para más información sobre OLS, consulte Restringir el acceso a los objetos del modelo de Power BI.

Lista de comprobación: al planear los RLS y OLS, estas son algunas decisiones y acciones clave:

Contenido relacionado

En el próximo artículo de esta serie, obtendrá información sobre la planificación de la seguridad para los creadores de contenidos encargados de crear modelos semánticos, flujos de datos, datamarts, informes o cuadros de mando.