Planeamiento de la implementación de Power BI: planeamiento de seguridad del creador de contenido

En este artículo de planeación de seguridad se describen las estrategias para los creadores de contenido responsables de crear modelos semánticos, flujos de datos, datamarts, informes o paneles. 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 consumen.

La serie de artículos está pensada para ampliar el contenido de las Notas del producto sobre 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 son creadores de contenido. Los creadores de contenido generan y publican contenido que ven otros usuarios. Los creadores de contenido son el tema central de este artículo.

Estrategia para creadores de contenido

La base de un sistema de BI de autoservicio bien regulado comienza con los creadores y propietarios de contenido. Estos crean y validan modelos semánticos e informes. En muchos casos, los creadores de contenido también configuran permisos para administrar la seguridad de su contenido.

A efectos de seguridad y permisos, tenga en cuenta que hay dos tipos de creadores de contenido: creadores de datos y creadores de informes. Pueden ser responsables de crear y administrar contenido de BI empresarial o BI de autoservicio.

Creadores de datos

Un creador de datos es cualquier usuario de Power BI que cree modelos semánticos, flujos de datos o datamarts.

A continuación, se detallan algunos escenarios comunes de creación de datos.

• Creación de un modelo semántico: cree y pruebe un nuevo modelo de datos en Power BI Desktop. Después, se publicará en el servicio Power BI para que se pueda usar como modelo semántico compartido para muchos informes. Para más información sobre la reutilización de modelos semánticos compartidos, consulte el escenario de uso BI con características de autoservicio administrado.
• Extensión y personalización de un modelo semántico: cree una conexión dinámica a un modelo semántico compartido existente en Power BI Desktop. Convierta la conexión dinámica en un modelo local, lo que permitirá extender el diseño del modelo con nuevas tablas o columnas. Para obtener más información sobre cómo extender y personalizar modelos semánticos compartidos, consulte el escenario de uso BI con características de autoservicio administrado personalizable.
• Creación de un nuevo flujo de datos: en el servicio Power BI, cree un flujo de datos para que muchos modelos semánticos puedan usarlo como origen. Para obtener más información sobre cómo reutilizar las actividades de preparación de datos, consulte el escenario de uso de preparación de datos de autoservicio.
• Creación de un datamart. En el servicio Power BI, cree un datamart.

Los creadores de datos a menudo se encuentran en equipos de BI empresarial y en el Centro de excelencia (COE). También tienen un papel clave que desempeñar en unidades de negocio descentralizadas y departamentos que mantienen y administran sus propios datos.

Para conocer otras consideraciones sobre la BI dirigida por la empresa, la BI de autoservicio administrada y la BI empresarial, consulte el artículo Propiedad y administración del contenido.

Creadores de informes

Los creadores de informes crean informes y paneles para visualizar los datos procedentes de modelos semánticos existentes.

A continuación, se detallan algunos escenarios comunes de creación de informes.

• Creación de un informe, incluido un modelo de datos: cree y pruebe un nuevo informe y modelo de datos en Power BI Desktop. El archivo de Power BI Desktop que contiene una o varias páginas de informe e incluye un modelo de datos se publica en el servicio Power BI. Los nuevos creadores de contenido suelen usar este método antes de conocer el uso de los modelos semánticos compartidos. También es adecuado para casos de uso reducido que no necesitan reutilizar los datos.
• Creación de un informe de conexión dinámica: cree un informe de Power BI que se conecte a un modelo semántico compartido en el servicio Power BI. Para más información sobre la reutilización de modelos semánticos compartidos, consulte el escenario de uso BI con características de autoservicio administrado.
• Creación de un libro de Excel conectado: cree un informe de Excel que se conecte a un modelo semántico compartido en el servicio Power BI. Las experiencias conectadas de Excel, en lugar de las descargas de datos, son muy recomendables.
• Creación de un informe de DirectQuery: cree un informe de Power BI que se conecte a un origen de datos compatible en modo DirectQuery. Una situación en la que este método es útil es cuando quiere aprovechar la seguridad del usuario implementada por el sistema de origen.

Los creadores de informes se encuentran en todas las unidades de negocio de la organización. Normalmente, hay muchos más creadores de informes que creadores de datos en una organización.

Permisos para creadores

En esta sección se describen los permisos más comunes para los creadores de datos y los creadores de informes.

Esta sección no está pensada para ser una lista completa de todos los permisos posibles. En su lugar, se ha creado para ayudarte a planear tu estrategia para admitir diferentes tipos de creadores de contenido. Tu objetivo debe ser seguir el principio de privilegios mínimos. Este principio permite que los usuarios tengan los permisos suficientes para ser productivos, sin un aprovisionamiento excesivo de estos.

Creación de contenido

Los permisos siguientes suelen ser necesarios para crear contenido.

Permiso	Creador de informes	Creador de modelos semánticos	Creador del flujo de datos	Creador de datamart
Acceso al origen de datos subyacente
Permisos de lectura y compilación del modelo semántico
Permiso de lectura del flujo de datos (cuando se usa un flujo de datos como origen a través del rol Visor del área de trabajo)
Acceso a la ubicación de almacenamiento del archivo original de Power BI Desktop
Permiso para usar objetos visuales personalizados

Permisos de publicación de contenido

Los permisos siguientes suelen ser necesarios para publicar contenido.

Permiso	Creador de informes	Creador de modelos semánticos	Creador del flujo de datos	Creador de datamart
Rol del área de trabajo: Colaborador, Miembro o Administrador
Permiso de escritura del modelo semántico (cuando el usuario no pertenece a un rol del área de trabajo)
Rol de canalización de implementación para publicar elementos (opcional)

Actualizando datos

Normalmente, los permisos siguientes son necesarios para actualizar los datos.

Permiso	Creador de informes	Creador de modelos semánticos	Creador del flujo de datos	Creador de datamart
Propietario asignado (que ha definido la configuración o tomado el control del elemento)
Acceso al origen de datos subyacente (cuando no se usa una puerta de enlace)
Acceso al origen de datos en una puerta de enlace (cuando el origen es local o en una red virtual)

En el resto de este artículo se describen las consideraciones para los permisos de creador de contenido.

Lista de comprobación: al planear la estrategia de seguridad para creadores de contenido, entre las decisiones y las acciones clave, se incluyen las siguientes:

Detección de contenido para creadores

Los usuarios pueden confiar en la detección de datos para buscar modelos semánticos y datamarts. La detección de datos es una característica de Power BI que permite a los creadores de contenido localizar recursos de datos existentes, incluso aunque no tengan permisos para ese contenido.

La detección de datos existentes es útil para lo siguiente:

• Creadores de informes que quieren usar un modelo semántico existente para un nuevo informe.
• Creadores de informes que quieran consultar datos de un datamart existente.
• Creadores de modelos semánticos que quieren usar un modelo semántico existente para un nuevo modelo compuesto.

Puede configurar un modelo semántico o datamart como reconocible cuando se ha aprobado (certificado o promocionado). Cuando se puede detectar, los creadores de contenido pueden encontrarlo en el centro de datos.

Un creador de contenido también puede solicitar acceso al modelo semántico o al datamart. Básicamente, una solicitud de acceso solicita permiso de compilación, que es necesario para crear contenido nuevo en función de este objeto. Al responder a las solicitudes de acceso, considere la posibilidad de usar grupos en lugar de usuarios individuales. Para obtener más información sobre cómo usar grupos para este propósito, consulte Solicitud del flujo de trabajo de acceso para consumidores.

Tenga en cuenta los tres ejemplos siguientes.

• El modelo semántico Resumen de venta está certificado. Es el origen confiable y autorizado para el seguimiento de ventas. Muchos creadores de informes de autoservicio de todos los departamentos de una organización usan este modelo semántico. Por lo tanto, hay muchos informes existentes y modelos compuestos basados en el modelo semántico. Para animar a otros creadores a buscar y usar el modelo semántico, este se establece como reconocible.
• El modelo semántico Estadísticas de inventario está certificado. Es un origen confiable y autorizado para el análisis de inventario. El equipo de BI empresarial mantiene y distribuye el modelo semántico y los informes relacionados. Debido al diseño complejo del modelo semántico, solo se permite al equipo de BI empresarial crear y mantener el contenido del inventario. Dado que el objetivo es recomendar a los creadores de informes que no usen el modelo semántico, este no se establece como reconocible.
• El modelo semántico Bonos ejecutivos contiene información extremadamente confidencial. Los permisos para ver o actualizar este modelo semántico están restringidos a algunos usuarios. Este modelo semántico no se establece como reconocible.

En la captura de pantalla siguiente, se muestra un modelo semántico en el centro de datos del servicio Power BI. En concreto, se muestra un ejemplo de un mensaje de solicitud de acceso para un modelo semántico reconocible. Este mensaje se muestra si el usuario no tiene acceso actualmente. El mensaje de solicitud de acceso se ha personalizado en la configuración del modelo semántico.

El mensaje de solicitud de acceso indica lo siguiente: Para los informes de ventas estándar de MTD/QTD/YTD, este modelo semántico es el origen autoritativo y certificado. Solicite acceso al modelo semántico completando el formulario ubicado en https://COE.contoso.com/RequestAccess. Se le pedirá una breve justificación comercial, y también será necesario que el gerente del Centro de excelencia apruebe la solicitud. El acceso se auditará cada seis meses.

Hay tres configuraciones de inquilinos relacionadas con la detección.

• La configuración de inquilino Detectar contenido permite a los administradores de Power BI establecer qué grupos de usuarios pueden detectar datos. Se dirige principalmente a los creadores de informes que podrían necesitar localizar los modelos semánticos existentes al crear informes. También es útil para los creadores de modelos semánticos que podrían buscar datos existentes que pueden usar en su desarrollo de modelos compuestos. Aunque es posible establecerla para grupos de seguridad específicos, es recomendable habilitar la configuración para toda la organización. La configuración de detección en modelos semánticos individuales y flujos de datos controlará lo que se puede detectar. Con menos frecuencia, podría considerar restringir esta capacidad solo a los creadores de contenido aprobados.
• La configuración de inquilino Hacer que el contenido certificado sea reconocible permite a los administradores de Power BI definir qué grupos pueden establecer que el contenido se pueda detectar (cuando también tienen permiso para editar el elemento, así como permiso para certificar el contenido, que se concede mediante la configuración de inquilino Certificación). La capacidad de certificar el contenido debe controlarse estrictamente. En la mayoría de los casos, se debe permitir que los mismos usuarios que puedan certificar contenido lo establezcan como reconocible. En algunas situaciones, es posible que quiera restringir esta funcionalidad solo a los creadores de datos aprobados.
• La configuración de inquilino Hacer que el contenido promocionado se pueda detectar permite a los administradores de Power BI establecer qué grupos pueden establecer el contenido como reconocible (cuando también tienen permisos para editar los datos). Dado que la capacidad de promover contenido está abierta a todos los creadores de contenido, en la mayoría de los casos, esta capacidad debe estar disponible para todos los usuarios. Con menos frecuencia, podría considerar restringir esta capacidad solo a los creadores de contenido aprobados.

Lista de comprobación: al planear la detección de datos para los creadores de contenido, entre las decisiones clave y las acciones, se incluyen las siguientes:

Solicitud del flujo de trabajo de acceso para creadores

Un usuario puede solicitar acceso al contenido de dos maneras.

• Para los consumidores de contenido: un usuario recibe un vínculo a un informe o aplicación existente en el servicio Power BI. Para ver el elemento, el consumidor puede seleccionar el botón Solicitar acceso. Para obtener más información, consulte el artículo Planeamiento de la seguridad del consumidor de informes.
• Para creadores de contenido: el usuario detecta un modelo semántico o datamart en el centro de datos. Para crear un nuevo informe o modelo compuesto basado en los datos existentes, el creador de contenido puede seleccionar el botón Solicitar acceso. Esta experiencia es el tema central de esta sección.

De forma predeterminada, las solicitudes de acceso a un modelo semántico o un datamart se dirigen al propietario. El propietario es el usuario que programó la actualización de datos o especificó las credenciales por última vez. Confiar en un usuario para procesar las solicitudes de acceso podría ser aceptable para los modelos semánticos del equipo. Sin embargo, esto podría no ser práctico o fiable.

En lugar de confiar en un propietario, puede definir instrucciones personalizadas que se presentarán a los usuarios cuando soliciten acceso a un modelo semántico o datamart. Las instrucciones personalizadas son útiles cuando:

• El modelo semántico se establece como reconocible.
• La aprobación de la solicitud de acceso la realizará alguien que no sea el propietario de los datos.
• Hay un proceso existente que debe seguirse para las solicitudes de acceso.
• Seguimiento de quién solicitó acceso, cuándo y por qué es necesario por razones de auditoría o cumplimiento.
• Es necesaria una explicación sobre cómo solicitar acceso y establecer las expectativas.

En la captura de pantalla siguiente, se muestra un ejemplo de configuración de las instrucciones personalizadas que verá un usuario cuando solicite el permiso de compilación. Las instrucciones personalizadas indican lo siguiente: Para los informes de ventas estándar de MTD/QTD/YTD, este modelo semántico es el origen autoritativo y certificado. Solicite acceso al modelo semántico completando el formulario ubicado en https://COE.contoso.com/RequestAccess. Se le pedirá una breve justificación comercial, y también será necesario que el gerente del Centro de excelencia apruebe la solicitud. El acceso se auditará cada seis meses.

Hay muchas opciones para crear un formulario. Power Apps y Microsoft Forms son opciones de poco código y fáciles de usar. Le recomendamos que cree un formulario de manera que sea independiente de un solo usuario. Es fundamental que el formulario lo cree, lo administre y lo supervise un equipo adecuado.

Se recomienda crear información útil para:

• Creadores de contenido, para que sepan qué esperar cuando solicitan acceso.
• Propietarios y administradores de contenido, para que sepan cómo administrar las solicitudes que se envían.

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

Creación y publicación de un plan

En esta sección, se incluyen aspectos de seguridad que se aplican a los creadores de contenido.

Roles de área de trabajo

Para conceder acceso al área de trabajo, agregue usuarios o grupos (incluidos los grupos de seguridad, los grupos de Microsoft 365 y las listas de distribución) a los roles del área de trabajo. La asignación de usuarios a roles del área de trabajo permite especificar lo que pueden hacer con el área de trabajo y su contenido.

Dado que el propósito principal de un área de trabajo es la colaboración, el acceso al área de trabajo es relevante principalmente para los usuarios que poseen y administran su contenido. Al empezar a planear los roles de área de trabajo, resulta útil formularse las siguientes preguntas.

• ¿Cuáles son las expectativas de cómo se producirá la colaboración en el área de trabajo?
• ¿Quién será responsable de administrar el contenido en el área de trabajo?
• ¿Tiene la intención de asignar usuarios individuales o grupos a roles de área de trabajo?

Hay cuatro roles de área de trabajo de Power BI: Administrador, Miembro, Colaborador y Espectador. Los tres primeros roles son relevantes para los creadores de contenido, que crean y publican contenido. El rol Espectador es relevante para los consumidores de solo lectura.

Los cuatro permisos de rol del área de trabajo están anidados. Esto significa que los administradores del área de trabajo tienen todas las funcionalidades disponibles para los miembros, los colaboradores y los espectadores. Del mismo modo, los miembros tienen todas las funcionalidades disponibles para los colaboradores y los espectadores. Los colaboradores tienen todas las funcionalidades disponibles para los espectadores.

Administrador del área de trabajo

Los usuarios asignados al rol Administrador se convierten en administradores del área de trabajo. Pueden administrar toda la configuración y realizar todas las acciones, incluida la adición o eliminación de usuarios (también lo pueden hacer otros administradores del área de trabajo).

Los administradores del área de trabajo pueden actualizar o eliminar la aplicación Power BI (si existe alguna). Opcionalmente, pueden permitir que los colaboradores actualicen la aplicación para el área de trabajo. Para más información, consulte Variaciones en los roles del área de trabajo más adelante en este artículo.

Tenga cuidado y asegúrese de que solo usuarios fiables y de confianza sean administradores del área de trabajo. Un administrador del área de trabajo tiene privilegios elevados. Tienen acceso para ver y administrar todo el contenido del área de trabajo. Pueden agregar y quitar usuarios (incluidos otros administradores) en cualquier rol del área de trabajo. También pueden eliminar el área de trabajo.

Se recomienda que haya al menos dos administradores, para que uno actúe como sustituto si el administrador principal no está disponible. Un área de trabajo que no tiene un administrador se conoce como área de trabajo huérfana. El estado huérfano se produce cuando un usuario abandona la organización y no hay ningún administrador alternativo asignado al área de trabajo. Para más información sobre cómo detectar y rectificar áreas de trabajo huérfanas, consulte el artículo Visualización de áreas de trabajo.

Idealmente, debería poder determinar quién es responsable del contenido del espacio de trabajo por quiénes son los administradores y miembros del espacio de trabajo (y los contactos especificados para el área de trabajo). Sin embargo, algunas organizaciones adoptan una estrategia de administración y propiedad de contenido que restringe la creación del área de trabajo a usuarios o grupos específicos. Normalmente tienen un proceso de creación de área de trabajo establecido que administra el departamento de TI. En este caso, los administradores del área de trabajo serían el departamento de TI en lugar de los usuarios que crean y publican directamente el contenido.

Miembro del área de trabajo

Los usuarios asignados al rol Miembro pueden agregar a otros usuarios del área de trabajo (pero no administradores). También pueden administrar permisos para todo el contenido del área de trabajo.

Los miembros del área de trabajo pueden publicar o anular la publicación de la aplicación para el área de trabajo, compartir un elemento de área de trabajo o la aplicación y permitir que otros usuarios compartan elementos del área de trabajo de la aplicación.

Los miembros del área de trabajo deben limitarse a los usuarios que necesitan administrar la creación de contenido del área de trabajo y publicar la aplicación. En algunos casos, los administradores del área de trabajo cumplen ese propósito, por lo que es posible que no tenga que asignar usuarios o grupos al rol Miembro. Cuando los administradores del área de trabajo no están directamente relacionados con el contenido del área de trabajo (por ejemplo, porque TI administra el proceso de creación del área de trabajo), los miembros del área de trabajo pueden ser los verdaderos propietarios responsables del contenido del área de trabajo.

Colaborador del área de trabajo

Los usuarios asignados al rol Colaborador pueden crear, editar o eliminar contenido del área de trabajo.

Los colaboradores no pueden actualizar la aplicación de Power BI (cuando existe una para el área de trabajo) a menos que la configuración del área de trabajo lo permita. Para más información, consulte Variaciones en los roles del área de trabajo más adelante en este artículo.

La mayoría de los creadores de contenido de la organización son colaboradores del área de trabajo.

Visor del área de trabajo

Los usuarios asignados al rol Espectador pueden ver e interactuar con todo el contenido del área de trabajo.

El rol Espectador es relevante para los consumidores de solo lectura para equipos pequeños y escenarios informales. Se describe completamente en el artículo Planeamiento de la seguridad del consumidor de informes.

Consideraciones sobre la propiedad del área de trabajo

Considere un ejemplo en el que se realizan las siguientes acciones para configurar una nueva área de trabajo.

1. A los campeones y miembros satélite específicos de Power BI del Centro de excelencia (COE) se les ha concedido permiso en la configuración del inquilino para crear nuevas áreas de trabajo. Se han entrenado en estrategias de organización de contenido y estándares de nomenclatura.
2. Usted (creador de contenido) envía una solicitud para crear un área de trabajo para un nuevo proyecto que va a administrar. El área de trabajo incluirá informes en los que se realizará un seguimiento del progreso del proyecto.
3. Un campeón de Power BI de su unidad de negocio recibe la solicitud. Determina que una nueva área de trabajo está justificada. Después, crea un área de trabajo y asigna el grupo de seguridad de campeones de Power BI (para su unidad de negocio) al rol Administrador del área de trabajo.
4. El campeón de Power BI le asigna a usted (creador de contenido) el rol Miembro del área de trabajo.
5. Asigna un compañero de confianza al rol Miembro del área de trabajo para asegurarse de que habrá un sustituto en caso de que esté fuera.
6. Asigne otros compañeros al rol Colaborador del área de trabajo porque serán los responsables de crear el contenido del área de trabajo, incluidos los modelos semánticos y los informes.
7. Asigna a su administrador el rol Espectador del área de trabajo porque ha solicitado acceso para supervisar el progreso del proyecto. El administrador quiere revisar el contenido del área de trabajo antes de publicar una aplicación.
8. Usted tiene la responsabilidad de administrar otras propiedades del área de trabajo, como la descripción y los contactos. También tiene la responsabilidad de administrar el acceso al área de trabajo de forma continua.

En el ejemplo anterior, se muestra una manera eficaz de permitir que una unidad de negocio descentralizada pueda actuar de forma independiente. También se muestra el principio de privilegios mínimos.

Para el contenido regulado o el contenido crítico que se administra de forma más estricta, se recomienda asignar grupos en lugar de cuentas de usuario individuales a los roles del área de trabajo. De este modo, puede administrar la pertenencia a grupos de forma independiente al área de trabajo. Sin embargo, al asignar grupos a roles, es posible que los usuarios se asignen a varios roles de área de trabajo (porque el usuario pertenece a varios grupos). En ese caso, sus permisos efectivos se basan en el rol más alto al que están asignados. Para más consideraciones, consulte Estrategia para usar grupos.

Cuando un área de trabajo es propiedad conjunta de varias personas o equipos, puede complicar la administración del contenido. Intente evitar escenarios de propiedad de varios equipos separando las áreas de trabajo. De este modo, las responsabilidades son claras y las asignaciones de roles, sencillas de configurar.

Variaciones en los roles del área de trabajo

Hay dos variaciones en los cuatro roles del área de trabajo (descritos anteriormente).

• De forma predeterminada, solo los administradores y miembros del área de trabajo pueden crear, publicar y actualizar la aplicación para el área de trabajo. La configuración Permitir que los colaboradores actualicen la aplicación para este espacio de trabajo es una configuración a nivel de espacio de trabajo, que permite a los administradores del espacio de trabajo delegar la capacidad de actualizar la aplicación para el área de trabajo a los colaboradores. Sin embargo, los colaboradores no pueden publicar una nueva aplicación ni cambiar quién tiene permiso para editarla. Esta configuración es útil cuando quiere que los colaboradores puedan actualizar la aplicación (si existe una para el área de trabajo), pero sin concederles los demás permisos disponibles para los miembros.
• La opción de configuración de inquilino Bloqueo del intento de volver a publicar y deshabilitación de la actualización de paquetes solo permite a los propietarios del modelo semántico publicar actualizaciones. Cuando está habilitada esta opción, los administradores, los miembros y los colaboradores del área de trabajo no pueden publicar los cambios a menos que primero se hagan cargo del modelo semántico como propietarios. Dado que esta configuración se aplica a toda la organización, habilítela con una medida de precaución porque afecta a todos los modelos semánticos para el inquilino. Asegúrese de comunicar a los creadores de modelos semánticos qué pueden esperar, ya que cambia el comportamiento normal de los roles del área de trabajo.

Lista de comprobación: al planear los roles del área de trabajo, las decisiones clave y las acciones incluyen las siguientes:

Permisos de creador de aplicaciones

Los creadores de contenido que son administradores o miembros del área de trabajo pueden crear y publicar una aplicación de Power BI.

Un administrador del área de trabajo también puede especificar una configuración en el área de trabajo que permita a los colaboradores del área de trabajo actualizar la aplicación. Se trata de una variación de la seguridad de roles del área de trabajo, porque concede a los colaboradores otro permiso que normalmente no tendrían. Esta configuración se establece por área de trabajo.

Lista de comprobación : al planear los permisos de creador de aplicaciones, las decisiones clave y las acciones incluyen las siguientes:

Permisos de origen de datos

Cuando un creador de datos inicia un nuevo proyecto, los permisos necesarios para acceder a orígenes de datos externos son una de sus primeras consideraciones relacionadas con la seguridad. También pueden necesitar instrucciones sobre otros aspectos relacionados con el origen de datos, incluidos los niveles de privacidad, las consultas de base de datos nativas y los conectores personalizados.

Acceso al origen de datos

Cuando un creador de datos crea un modelo semántico, un flujo de datos o datamart, debe autenticarse con orígenes de datos para poder recuperar datos. Normalmente, la autenticación implica credenciales de usuario (cuenta y contraseña), que podrían ser para una cuenta de servicio.

A veces, resulta útil crear cuentas de servicio específicas para acceder a orígenes de datos. Consulte al departamento de TI las instrucciones sobre cómo se deben usar las cuentas de servicio en su organización. Cuando se permiten, con las cuentas de servicio puede hacer lo siguiente:

• Centralizar los permisos necesarios para los orígenes de datos.
• Reducir el número de usuarios individuales que necesitan permisos para un origen de datos.
• Evitar errores de actualización de datos cuando un usuario abandona la organización.

Al acceder a orígenes de datos, aplique el principio de privilegios mínimos para asegurarse de que los usuarios (o cuentas de servicio) tengan permiso para leer solo los datos que necesitan. Nunca deben tener permiso para realizar modificaciones de los datos. Los administradores de bases de datos que crean estas cuentas de servicio deben consultar las consultas y cargas de trabajo esperadas y tomar medidas para asegurarse de que existen optimizaciones adecuadas (como índices) y recursos.

Las credenciales (cuenta y contraseña) se pueden aplicar de dos maneras.

• Power BI Desktop: las credenciales se cifran y almacenan localmente en el equipo de usuario.
• servicio Power BI: las credenciales se cifran y almacenan de forma segura para:
  • El modelo semántico (cuando una puerta de enlace de datos no está en uso para llegar al origen de datos).
  • El origen de datos de la puerta de enlace (cuando una puerta de enlace estándar o un servicio de puerta de enlace de red virtual está en uso para llegar al origen de datos).

Las credenciales se cifran y almacenan por separado del modelo de datos tanto en Power BI Desktop como en Power BI. Esta separación de datos tiene las siguientes ventajas de seguridad.

• Facilita la reutilización de credenciales para varios modelos semánticos, flujos de datos y datamarts.
• Cuando alguien analiza los metadatos de un modelo semántico, no puede extraer las credenciales.
• En Power BI Desktop, otro usuario no puede conectarse al origen de datos original para actualizar los datos sin aplicar primero las credenciales.

Algunos orígenes de datos admiten el inicio de sesión único (SSO), que se puede establecer al escribir las credenciales en el servicio Power BI (para orígenes de datos de modelo semántico o de puerta de enlace). Al habilitar el inicio de sesión único, Power BI envía las credenciales del usuario autenticado al origen de datos. Esta opción permite a Power BI respetar la configuración de seguridad que se configura en el origen de datos, como la seguridad de nivel de fila. El inicio de sesión único es especialmente útil cuando las tablas del modelo de datos usan el modo de almacenamiento DirectQuery.

Niveles de privacidad

Los niveles de privacidad de datos especifican niveles de aislamiento que definen el grado en que un origen de datos está aislado respecto a los demás. Cuando se establecen correctamente, garantizan que Power Query solo transmita datos compatibles entre orígenes. Cuando Power Query puede transmitir datos entre orígenes de datos, puede dar lugar a consultas más eficaces que reducen el volumen de datos que se envían a Power BI. Cuando no puede transmitir datos entre orígenes de datos, puede dar lugar a un rendimiento más lento.

Hay tres niveles de privacidad.

• Privado: incluye datos confidenciales que deben aislarse de todos los demás orígenes de datos. Este nivel es el más restrictivo. Los datos de origen de datos privados no se pueden compartir con ningún otro origen de datos. Por ejemplo, una base de datos de recursos humanos que contenga valores de salario de empleados debe establecerse en el nivel de privacidad Privado.
• Organizativo: se aísla de los orígenes de datos públicos, pero está visible para otras fuentes de datos de la organización. Este nivel es el más común. Los datos del origen de datos de la organización se pueden compartir con orígenes de datos privados u otros orígenes de datos de la organización. La mayoría de las bases de datos operativas internas se pueden establecer con el nivel de privacidad Organizativo.
• Público: datos no confidenciales que se podrían hacer visibles para cualquier origen de datos. Este nivel es el menos restrictivo. Los datos de orígenes de datos públicos se pueden compartir con cualquier otro origen de datos. Por ejemplo, un informe del censo obtenido de un sitio web gubernamental se puede establecer en el nivel de privacidad Público.

Al combinar consultas de distintos orígenes de datos, es importante establecer los niveles de privacidad correctos. Cuando los niveles de privacidad se establecen correctamente, existe la posibilidad de que los datos de un origen de datos se transmitan a otro origen de datos para consultar datos de forma eficaz.

Imaginemos un escenario en el que un creador de modelos semánticos tiene dos orígenes de datos: un libro de Excel y una tabla en una base de datos de Azure SQL. Quiere filtrar los datos de la tabla de base de datos de Azure SQL mediante un valor de origen del libro de Excel. La manera más eficaz de Power Query para generar una instrucción SQL para la base de datos de Azure SQL es aplicar una cláusula WHERE para realizar el filtrado necesario. Sin embargo, esa instrucción SQL contendrá un predicado de cláusula WHERE con un valor de origen del libro de Excel. Si el libro de Excel contiene datos confidenciales, podría representar una infracción de seguridad porque el administrador de bases de datos podría ver la instrucción SQL mediante una herramienta de seguimiento. Aunque es menos eficaz, la alternativa es que el motor de mashup de Power Query descargue todo el conjunto de resultados de la tabla de base de datos y realice el filtrado en el servicio Power BI. Este enfoque será lento y menos eficaz, pero seguro.

Los niveles de privacidad se pueden establecer para cada origen de datos:

• Por modeladores de datos en Power BI Desktop.
• Por propietarios de modelos semánticos en el servicio Power BI (para orígenes de datos en la nube que no requieren una puerta de enlace).
• Por creadores y propietarios de orígenes de datos de puerta de enlace en el servicio Power BI (para orígenes de datos de puerta de enlace).

Hay una opción de seguridad de Power BI Desktop que permite omitir los niveles de privacidad para mejorar el rendimiento. Podrá usar esta opción para mejorar el rendimiento de las consultas al desarrollar un modelo de datos cuando no haya ningún riesgo de vulnerar la seguridad de los datos (porque esté trabajando con datos de desarrollo o prueba que no sean confidenciales). Sin embargo, el servicio Power BI no respeta esta configuración.

Para más información, consulte Niveles de privacidad de Power BI Desktop.

Consultas de bases de datos nativas

Para crear consultas Power Query eficaces, puede usar una consulta nativa para acceder a los datos. Una consulta nativa es una instrucción escrita en un idioma que admite el origen de datos. Las consultas nativas solo son compatibles con orígenes de datos específicos, que suelen ser bases de datos relacionales, como Azure SQL Database.

Las consultas nativas pueden suponer un riesgo de seguridad porque podrían ejecutar una instrucción SQL malintencionada. Una instrucción malintencionada podría realizar modificaciones de datos o eliminar registros de base de datos (si el usuario tiene los permisos necesarios en el origen de datos). Por este motivo, de forma predeterminada, las consultas nativas requieren la aprobación del usuario para ejecutarse en Power BI Desktop.

Hay una opción de seguridad Power BI Desktop que permite deshabilitar el requisito de aprobación previa. Se recomienda dejar la configuración predeterminada que requiere la aprobación del usuario, especialmente cuando se prevé que otros usuarios podrían actualizar el archivo de Power BI Desktop.

Conectores personalizados

Los desarrolladores pueden usar el SDK de Power Query para crear conectores personalizados. Los conectores personalizados permiten el acceso a orígenes de datos de propiedad o implementan autenticación específica con extensiones de datos personalizadas. Microsoft ha certificado y distribuido algunos conectores personalizados como conectores certificados. Los conectores certificados se han auditado y revisado para garantizar que cumplen ciertos requisitos de código especificados que Microsoft ha probado y aprobado.

Hay una opción de seguridad de extensión de datos de Power BI Desktop que restringe el uso de conectores no certificados. De forma predeterminada, se produce un error cuando se intenta cargar un conector no certificado. Al establecer esta opción para permitir conectores no certificados, los conectores personalizados se cargarán sin validación ni advertencia.

Se recomienda mantener el nivel de seguridad de la extensión de datos en el nivel superior, que impide la carga de código no certificado. Sin embargo, puede haber muchos casos en los que quiera cargar conectores específicos, como los que haya desarrollado usted mismo o conectores proporcionados por un consultor o proveedor de confianza fuera de la ruta de certificación de Microsoft.

Lista de comprobación: al planear los permisos del origen de datos, las decisiones clave y las acciones incluyen las siguientes:

Permisos de creador de modelos semánticos

Puede asignar permisos para editar un modelo semántico a un usuario o grupo de maneras diferentes.

• Rol de área de trabajo: la asignación de cualquiera de los roles del área de trabajo proporciona acceso a todos los modelos semánticos del área de trabajo. La posibilidad de ver o editar un modelo semántico existente dependerá del rol del área de trabajo que asigne. Los administradores, los miembros y los colaboradores pueden publicar o editar contenido en un área de trabajo.
• Vínculos de permisos por elemento: si se creó un vínculo para compartir para un informe, el vínculo también concede el permiso para leer el modelo semántico (y, opcionalmente, compilarlo, escribirlo o volverlo a compartir).
• Permisos de acceso directo por elemento: puede asignar el permiso de acceso directo a un modelo semántico específico.

En la captura de pantalla siguiente, observe los permisos asignados al modelo semántico Datos del centro de llamadas. Un usuario tiene permiso de lectura, que se concedió mediante permisos de acceso directo por elemento. Los usuarios y grupos restantes tienen permisos porque están asignados a roles del área de trabajo.

Permisos del modelo semántico

Puede asignar los siguientes permisos de modelo semántico.

• Lectura: este permiso, que va dirigido principalmente a los consumidores de informes, permite que un informe consulte los datos del modelo semántico. Para obtener más información sobre los permisos para ver el contenido de solo lectura, consulte el artículo Planeamiento de la seguridad del consumidor de informes.
• Compilación: este permiso, que va dirigido a los creadores de informes, permite a los usuarios crear informes basados en el modelo semántico compartido. Para obtener más información, vea la sección Permisos de creador de informes más adelante en este artículo.
• Escritura: este permiso, que va dirigido a los creadores de modelos semánticos que crean, publican y administran modelos semánticos, permite a los usuarios editar el modelo semántico. Se describe más adelante en esta sección.
• Volver a compartir: este permiso, que va dirigido a cualquier persona con permiso existente para el modelo semántico, permite a los usuarios compartirlo con otro usuario. Se describe más adelante en esta sección.

Un administrador o miembro del área de trabajo puede editar los permisos de un modelo semántico.

Permiso de lectura del modelo semántico

El permiso de lectura del modelo semántico va dirigido principalmente a los consumidores. Este permiso es necesario para que los usuarios puedan ver los datos que se muestran en los informes. Tenga en cuenta que los informes basados en el modelo semántico también deben tener permiso de lectura; de lo contrario, el informe no se cargará. Para obtener más información sobre la configuración de permisos de lectura de informes, consulte el artículo Planeamiento de seguridad del consumidor de informes.

Permiso de compilación del modelo semántico

Además del permiso de lectura del modelo semántico, los creadores de contenido también necesitan el permiso de compilación del modelo semántico. En concreto, el permiso de creación permite a los creadores de informes hacer lo siguiente:

• Crear informes de Power BI basados en el modelo semántico.
• Conectarse al modelo semántico mediante Analizar en Excel.
• Consultar el modelo semántico mediante el punto de conexión XMLA.
• Exportar los datos subyacentes del objeto visual de informes de Power BI (en lugar de los datos resumidos recuperados por el objeto visual).
• Crear una conexión de DirectQuery a un modelo semántico de Power BI. En este caso, el nuevo modelo semántico se conecta a uno o varios modelos semánticos de Power BI existentes (conocidos como encadenamientos). Para consultar modelos semánticos encadenados, el creador del modelo semántico necesitará el permiso de compilación para todos los modelos semánticos ascendentes. Para más información, consulte Modelos semánticos encadenados más adelante en este artículo.

Puede conceder el permiso de creación a un usuario o grupo, directa o indirectamente, de diferentes maneras.

• Conceda el permiso de creación directamente de las siguientes maneras:
  • Establezca permisos de modelo semántico en la página de configuración del modelo semántico en el servicio Power BI.
  • Establezca permisos de modelo semántico mediante la API REST de Power BI.
• Conceda el permiso de creación indirectamente de las siguientes maneras:
  • Comparta un informe o panel y establezca la opción para conceder permiso de compilación al modelo semántico.
  • Publique una aplicación de Power BI y establezca la opción avanzada (para una audiencia) para conceder permiso de compilación en los modelos semánticos relacionados.
  • Asigne usuarios a los roles del área de trabajo Administrador, Miembro o Colaborador.

Establecer el permiso de compilación directamente para un modelo semántico es adecuado cuando quiere administrar la seguridad elemento por elemento. Establecer el permiso de creación indirectamente es adecuado cuando los usuarios que verán o usarán el contenido a través de uno de los métodos indirectos también crearán contenido.

Permiso de escritura del modelo semántico

Normalmente, la configuración de permisos de quién puede editar y administrar modelos semánticos se realizará mediante la asignación de usuarios al rol del área de trabajo Administrador, Miembro o Colaborador. Sin embargo, también es posible establecer el permiso de escritura para un modelo semántico específico.

Se recomienda usar los roles del área de trabajo siempre que sea posible, ya que es la manera más sencilla de administrar y auditar permisos. Use los permisos de escritura del modelo semántico por elemento cuando haya elegido crear menos áreas de trabajo y cuando un área de trabajo contenga modelos semánticos para diferentes áreas de asunto que requieran una administración de permisos diferente.

Permiso para volver a compartir el modelo semántico

El permiso Volver a compartir del modelo semántico permite a un usuario con un permiso existente compartir el modelo semántico con otros usuarios. Puede conceder este permiso cuando el contenido del modelo semántico se pueda compartir libremente, en función de la discreción del usuario.

En muchos casos, se recomienda limitar el uso del permiso Volver a compartir para asegurarse de que los permisos del modelo semántico se controlen cuidadosamente. Obtenga la aprobación del propietario del modelo semántico antes de conceder el permiso Volver a compartir.

Seguridad de los datos del modelo semántico

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.

Un creador de modelos semánticos puede aplicar la seguridad de los datos de dos maneras.

• La seguridad de nivel de fila (RLS) permite a un modelador de datos restringir el acceso a un subconjunto de datos.
• 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.

La implementación de RLS y OLS se dirige a los consumidores de informes. Para obtener más información, consulte el artículo Planeamiento de la seguridad del consumidor de informes. Describe cómo y cuándo se aplican RLS y OLS para los consumidores que tienen permiso de solo visualización para el modelo semántico.

Para RLS y OLS destinados a otros creadores de informes, consulte la seguridad de los datos en la sección Permisos para creadores de informes más adelante en este artículo.

Modelos semánticos encadenados

Los modelos semánticos de Power BI pueden conectarse a otros modelos semánticos en un proceso conocido como encadenamiento, que son conexiones con modelos semánticos ascendentes. Para más información, consulte Uso de DirectQuery para modelos semánticos de Power BI y Analysis Services.

La opción Permitir conexiones de DirectQuery a modelos semánticos de Power BI permite a los administradores de Power BI configurar qué grupos de creadores de contenido pueden crear modelos semánticos encadenados. Si no quiere restringir que los creadores de modelos semánticos puedan encadenar modelos semánticos, puede dejar esta opción habilitada para toda la organización y confiar en los permisos de acceso y de modelo semántico del área de trabajo. En algunos casos, podría considerar la posibilidad de restringir esta funcionalidad a los creadores de contenido aprobados.

Consultas de API de modelos semánticos

En algunas situaciones, es posible que quiera ejecutar una consulta DAX mediante la API REST de Power BI. Por ejemplo, puede que quiera realizar validaciones de calidad de datos. Para obtener más información, consulte Conjuntos de datos: ejecutar consultas.

La configuración del inquilino de la API REST Conjuntos de datos: ejecutar consultas permite a los administradores de Power BI establecer qué grupos de usuarios pueden enviar consultas DAX mediante la API REST de Power BI. En la mayoría de los casos, puede dejar esta opción habilitada para toda la organización y confiar en los permisos de acceso y de modelo semántico del área de trabajo. En algunos casos, podría considerar la posibilidad de restringir esta funcionalidad a los creadores de contenido aprobados.

Lista de comprobación: al planear los permisos de creador de modelos semánticos, las decisiones clave y las acciones incluyen las siguientes:

Permisos de creador de informes

Los creadores de informes necesitan acceso al área de trabajo para crear informes en el servicio Power BI o publicarlos desde Power BI Desktop. Deben ser administradores, miembros o colaboradores en el área de trabajo de destino.

Siempre que sea posible, los creadores de informes deben usar un modelo semántico compartido existente (a través de una conexión dinámica o DirectQuery). De este modo, el proceso de creación de informes se desacopla del proceso de creación del modelo semántico. Este tipo de separación proporciona muchas ventajas para los escenarios de seguridad y desarrollo en equipo.

Un creador de informes debe ser administrador, miembro o colaborador del área de trabajo.

A diferencia de los modelos semánticos, no hay un permiso de escritura para los informes. Para admitir creadores de informes, se deben usar los roles del área de trabajo. Por este motivo, el diseño óptimo del área de trabajo es importante para equilibrar las necesidades de seguridad y organización de contenido.

Permisos de lectura y compilación para el modelo semántico subyacente

Los creadores de informes deben tener permisos de lectura y compilación en los modelos semánticos que usarán sus informes, lo que incluye modelos semánticos encadenados. Ese permiso se puede conceder explícitamente en los modelos semánticos individuales o se puede conceder implícitamente para los modelos semánticos del área de trabajo cuando el creador del informe es administrador, miembro o colaborador del área de trabajo.

La opción Uso de modelos semánticos entre áreas de trabajo permite a los administradores de Power BI configurar qué grupos de usuarios pueden crear informes que usan modelos semánticos ubicados en otras áreas de trabajo. Esta configuración está destinada a los creadores de informes y modelos semánticos. Normalmente, se recomienda dejar esta configuración habilitada para toda la organización y confiar en la configuración de acceso al área de trabajo y los permisos del modelo semántico. De este modo, puede fomentar el uso de los modelos semánticos existentes. En algunos casos, podría considerar la posibilidad de restringir esta funcionalidad solo a los creadores de contenido aprobados.

También existe la configuración de inquilino Permitir conexiones dinámicas, que permite a los administradores de Power BI configurar qué grupos de usuarios pueden crear conexiones dinámicas a modelos semánticos en Power BI Desktop o Excel. Se destina específicamente a los creadores de informes y también requiere que se les conceda permiso de lectura y compilación en el modelo semántico que usará el informe. Se recomienda dejar esta opción habilitada para toda la organización y confiar en los permisos de acceso y de modelo semántico del área de trabajo. De este modo, puede fomentar el uso de los modelos semánticos existentes. En algunos casos, podría considerar la posibilidad de restringir esta funcionalidad solo a los creadores de contenido aprobados.

Seguridad de los datos para el modelo semántico subyacente

RLS y OLS (descritos anteriormente en este artículo) se dirigen a consumidores de informes. Sin embargo, a veces también es necesario aplicarlos a los creadores de informes. La creación de áreas de trabajo independientes se justifica cuando es necesario aplicar RLS a los creadores de informes y también a los consumidores de informes.

Considere el siguiente escenario:

• Modelos semánticos compartidos centralizados con RLS: el equipo de BI empresarial publicó modelos semánticos de ventas en el área de trabajo Datos de ventas. Estos modelos semánticos aplican RLS para mostrar los datos de ventas de la región de ventas asignada del consumidor del informe.
• Creadores de informes de autoservicio descentralizados: la unidad de negocio de ventas y marketing tiene muchos analistas capacitados que crean sus propios informes. Publican sus informes en el área de trabajo Análisis de ventas.
• Permisos de lectura y compilación para modelos semánticos: siempre que es posible, los analistas usan los modelos semánticos del área de trabajo Datos de ventas para evitar la duplicación innecesaria de datos. Dado que los analistas solo tienen permisos de lectura y compilación en estos modelos semánticos (sin permisos de escritura o edición), se aplica RLS a los creadores de informes (y también a los consumidores de informes).
• Permisos de edición para el área de trabajo de informes: los analistas tienen más derechos en el área de trabajo Análisis de ventas. Los roles del área de trabajo administrador, miembro o colaborador les permiten publicar y administrar sus informes.

Para obtener más información sobre RLS y OLS, consulte el artículo Planeamiento de la seguridad del consumidor de informes. Describe cómo y cuándo se aplican RLS y OLS para los consumidores que tienen permiso de solo visualización para el modelo semántico.

Conexión a modelos semánticos externos

Cuando un creador de informes se conecta a un modelo semántico compartido para su informe, normalmente se conecta a un modelo semántico compartido publicado en su propio inquilino de Power BI. Cuando se ha concedido el permiso, también es posible conectarse a un modelo semántico compartido en otro inquilino. El otro inquilino podría ser un asociado, cliente o proveedor.

Esta funcionalidad se conoce como uso compartido de modelos semánticos en contexto (también denominado uso compartido de modelos semánticos entre inquilinos). Los informes creados por el creador de informes (o los nuevos modelos compuestos creados por un creador de modelos semánticos) se almacenan y protegen en el inquilino de Power BI mediante el proceso normal. El modelo semántico compartido original permanece en su inquilino original de Power BI y todos los permisos se administran allí.

Para obtener más información, consulte el artículo Planeamiento de la seguridad a nivel de inquilino. Incluye información sobre la configuración del inquilino y del modelo semántico que hace que el uso compartido externo funcione.

Tablas presentadas

En Power BI Desktop, los creadores de modelos semánticos pueden establecer una tabla modelo para que se convierta en una tabla destacada. Cuando el modelo semántico se publica en el servicio Power BI, los creadores de informes pueden usar la Galería de tipos de datos en Excel para encontrar la tabla destacada, lo que les permite agregar datos de la tabla destacada para aumentar sus hojas de cálculo de Excel.

La configuración de inquilino Permitir conexiones a tablas destacadas permite los administradores de Power BI configurar qué grupos de usuarios pueden acceder a las tablas destacadas. Se dirige a los usuarios de Excel que quieran acceder a las tablas destacadas de Power BI en los tipos de datos de la organización de Excel. Se recomienda dejar esta opción habilitada para toda la organización y confiar en los permisos de acceso y de modelo semántico del área de trabajo. De este modo, puede fomentar el uso de tablas destacadas.

Permisos visuales personalizados

Además de los objetos visuales principales, los creadores de informes de Power BI pueden usar objetos visuales personalizados. En Power BI Desktop, los objetos visuales personalizados se pueden descargar desde Microsoft AppSource. También se pueden desarrollar internamente mediante Microsoft Power BI SDK e instalar abriendo el archivo visual (.pbviz).

Algunos objetos visuales disponibles para su descarga desde AppSource son objetos visuales certificados. Los objetos visuales cumplen determinados requisitos de código especificados que el equipo de Power BI ha probado y aprobado. Las pruebas verifican que las imágenes no accedan a servicios o recursos externos.

La configuración de inquilino Permitir los objetos visuales que haya creado Microsoft Power BI SDK permite a los administradores de Power BI controlar qué grupos de usuarios pueden usar objetos visuales personalizados.

También existe la configuración de inquilino Agregar y usar solo objetos visuales certificados, que permite a los administradores de Power BI bloquear el uso de objetos visuales no certificados en el servicio Power BI. Esta configuración se puede habilitar o deshabilitar para toda la organización.

Power BI Desktop tiene una opción para mostrar una advertencia de seguridad cuando un creador de informes agrega un objeto visual personalizado al informe. Los creadores de informes pueden deshabilitar esta opción. Esta opción no prueba si el objeto visual está certificado.

Los administradores de Power BI pueden aprobar e implementar los objetos visuales personalizados de Power BI para su organización. A continuación, los creadores de informes pueden detectar, actualizar y usar fácilmente estos objetos visuales. Después, los administradores pueden administrar estos objetos visuales actualizando versiones o deshabilitando y habilitando objetos visuales personalizados específicos. Este enfoque es útil si quiere que un objeto visual desarrollado internamente esté disponible para los creadores de informes o si adquiere un objeto visual personalizado de un proveedor que no esté en AppSource. Consulte Objetos visuales de la organización de Power BI para obtener más información.

Considere la estrategia equilibrada de habilitar solo objetos visuales personalizados certificados en su organización (con la configuración de inquilino y la directiva de grupo descritas anteriormente) al implementar objetos visuales de la organización para controlar las excepciones.

Lista de comprobación : al planear los permisos de creador de informes, las decisiones clave y las acciones incluyen las siguientes:

Permisos de creador de flujos de datos

Los flujos de datos son útiles para centralizar la preparación de datos para que el trabajo realizado en Power Query no se repita en muchos modelos semánticos. Son un bloque de creación para lograr una única fuente de información, lo que impide que los analistas requieran acceso directo a los orígenes, y para ayudar a realizar operaciones de extracción, transformación y carga (ETL) a escala.

Un creador de flujo de datos debe ser administrador, miembro o colaborador del área de trabajo.

Para consumir un flujo de datos (por ejemplo, a partir de un nuevo modelo de datos creado en Power BI Desktop o en otra área de trabajo), un creador de modelos semánticos puede pertenecer a cualquier rol de área de trabajo, incluido el rol Espectador. No hay ningún concepto de RLS para flujos de datos.

Además de los roles de área de trabajo, se debe habilitar la configuración de inquilino Crear y usar flujos de datos. Esta configuración de inquilino se aplica a toda la organización.

Considere el siguiente escenario:

• Muchos modelos semánticos de la organización deben aplicar RLS dinámicos. Requiere que los nombres principales de usuario (UPN) se almacenen en el modelo semántico (para filtrar por la identidad del consumidor del informe).
• Un creador de flujo de datos, que pertenece al departamento de Recursos Humanos, crea un flujo de datos de los detalles actuales de los empleados, incluidos sus UPN. Configura el flujo de datos para que se actualice diariamente.
• Después, los creadores de modelos semánticos consumen el flujo de datos en sus diseños de modelo para configurar RLS.

Para obtener más información sobre el uso de flujos de datos, consulte los escenarios de uso de preparación de datos avanzados y preparación de datos de autoservicio.

Lista de comprobación: al planear los permisos de creador de flujo de datos, las decisiones clave y las acciones incluyen las siguientes:

Permisos de creador de datamart

Un datamart es una solución de análisis de autoservicio que permite a los usuarios almacenar y explorar datos cargados en una base de datos relacional totalmente administrada. También consta de un modelo semántico generado automáticamente.

Los datamarts proporcionan una experiencia sencilla de poco código para ingerir datos de diferentes orígenes de datos y extraer, transformar y cargar (ETL) los datos mediante Power Query Online. Los datos se cargan en una instancia de Azure SQL Database totalmente administrada y no se requieren ajustes ni optimización. El modelo semántico generado automáticamente siempre se sincroniza con la base de datos administrada porque está en modo DirectQuery.

Puede crear un datamart si es administrador, miembro o colaborador del área de trabajo. Los roles del área de trabajo también se asignan a los roles de nivel de base de datos en Azure SQL Database (sin embargo, dado que la base de datos está totalmente administrada, los permisos de usuario no se pueden editar ni administrar en la base de datos relacional).

La configuración de inquilino Crear datamarts permite a los administradores de Power BI configurar qué grupos de usuarios pueden crear datamarts.

Uso compartido de datamarts

En el caso de los datamarts, el término compartir toma un significado diferente en comparación con otros tipos de contenido de Power BI. Normalmente, una operación de uso compartido está destinada a un consumidor porque proporciona permiso de solo lectura a un elemento, como un informe.

El uso compartido de un datamart está destinado a creadores de contenido (en lugar de consumidores). Concede los permisos de lectura y compilación, lo que permite a los usuarios consultar el modelo semántico o la base de datos relacional, lo que prefieran.

Compartir un datamart permite a los creadores de contenido realizar lo siguiente:

• Compilar contenido mediante el modelo semántico generado automáticamente: el modelo semántico es la capa semántica en la que se pueden compilar informes de Power BI. La mayoría de los creadores de informes deben usar el modelo semántico.
• Conectarse a y consultar Azure SQL Database: la base de datos relacional es útil para los creadores de contenido que quieran crear nuevos modelos semánticos o informes paginados. Pueden escribir consultas del lenguaje de consulta estructurado (SQL) para recuperar datos mediante el punto de conexión de SQL.

Seguridad de nivel de fila de datamart

Puede definir que RLS para datamarts restrinja el acceso a datos para los usuarios especificados. RLS se configura en el editor de datamart del servicio Power BI y se aplica automáticamente al modelo semántico generado automáticamente y a Azure SQL Database (como reglas de seguridad).

Independientemente de cómo un usuario decida conectarse al datamart (al modelo semántico o a la base de datos), se aplicarán permisos RLS idénticos.

Lista de comprobación: al planear los permisos de creador de datamarts, las decisiones clave y las acciones incluyen las siguientes:

Permisos de creador de cuadros de mandos

Las métricas en Power BI le permiten mantener métricas específicas y realizar un seguimiento de ellas con los objetivos empresariales clave. Las métricas se agregan a los cuadros de mandos, que se pueden compartir con otros usuarios y ver en un solo panel.

Los cuadros de mandos se pueden proteger con tres niveles de permisos:

• Área de trabajo.
• Permisos de cuadro de mandos (por elemento).
• Métricas (dentro del cuadro de mandos).

Un usuario que crea o administra por completo un cuadro de mandos debe ser un administrador, miembro o colaborador del área de trabajo.

Dado que las métricas suelen abarcar varias áreas de asunto, se recomienda crear un área de trabajo independiente para que pueda administrar de forma independiente los permisos para creadores y consumidores.

La configuración de inquilino Crear y usar métricas permite a los administradores de Power BI configurar qué grupos de usuarios pueden crear métricas de cuadro de mandos.

Permisos de cuadro de mandos

Puede asignar los siguientes permisos de cuadro de mandos.

• Lectura: este permiso permite a un usuario ver el cuadro de mandos.
• Volver a compartir: este permiso, que va dirigido a cualquier persona con permiso existente para el cuadro de mandos, permite a los usuarios compartirlo con otro usuario.

Los permisos por elemento, coherentes con otros tipos de contenido del servicio Power BI, son útiles cuando la intención es compartir un elemento con otro usuario. Se recomienda usar roles de área de trabajo y permisos de aplicación siempre que sea posible.

Permisos de nivel de métrica

Cada cuadro de mandos tiene un conjunto de permisos de nivel de métrica que puede configurar en la configuración del cuadro de mandos. Los permisos de nivel de métrica (dentro de un cuadro de mandos) se pueden conceder de forma diferente a los permisos del área de trabajo o del cuadro de mandos (por elemento).

Los roles de nivel de métrica le permiten establecer lo siguiente:

• Quién puede ver métricas individuales en un cuadro de mandos.
• Quién puede actualizar métricas individuales mediante lo siguiente:
  • Actualización del estado durante una comprobación.
  • Adición de notas durante una comprobación.
  • Actualización del valor actual durante una comprobación.

Para reducir el nivel de mantenimiento futuro, es posible establecer los permisos predeterminados que heredarán las submétricas que cree en el futuro.

Lista de comprobación : al planear los permisos de creador de métricas, las decisiones clave y las acciones incluyen las siguientes:

Publicación de contenido

En esta sección se incluyen temas relacionados con la publicación de contenido relevante para los creadores de contenido.

Áreas de trabajo

Los creadores de contenido necesitarán acceso de administrador, miembro o colaborador para publicar contenido en un área de trabajo. Para obtener más información, consulte los roles del área de trabajo descritos anteriormente en este artículo.

Excepto para la BI personal, se debe animar a los creadores de contenido a publicar contenido en áreas de trabajo estándar, en lugar de en su área de trabajo personal.

La configuración de inquilino Bloqueo del intento de volver a publicar y deshabilitación de la actualización de paquetes cambia el comportamiento de los modelos semánticos de publicación. Cuando está habilitada, los administradores del área de trabajo, los miembros o los colaboradores no pueden publicar cambios en un modelo semántico. Solo se permite al propietario del modelo semántico publicar una actualización (forzando la adquisición de un modelo semántico antes de publicar un modelo semántico actualizado). Dado que esta configuración de inquilino se aplica a toda la organización, habilítela con una medida de precaución porque afecta a todos los modelos semánticos de todo el inquilino. Asegúrese de comunicar a los creadores de modelos semánticos qué pueden esperar, ya que cambia el comportamiento normal de los roles del área de trabajo.

Sincronización de Power Apps

Es posible crear una solución de Power Apps que incluya informes de Power BI insertados. El proceso de Power Apps creará automáticamente un área de trabajo de Power BI dedicada para almacenar y proteger los informes y modelos semánticos de Power BI. Para administrar los elementos que existen en Power Apps y Power BI, hay un proceso de sincronización.

El proceso sincroniza los roles de seguridad para asegurarse de que Power BI herede los mismos roles que se configuraron inicialmente en Power Apps. También permite al creador de contenido administrar permisos sobre quién puede ver los informes de Power BI (y modelos semánticos relacionados) que se insertan en una aplicación de Power Apps.

Para más información sobre la sincronización de roles de Power Apps con roles de área de trabajo de Power BI, consulte Sincronización de permisos entre el entorno de Power Apps y el área de trabajo de Power BI.

Acceso a la canalización de implementación

Los creadores y propietarios de contenido pueden usar canalizaciones de implementación de Power BI para la publicación de contenido de autoservicio. Las canalizaciones de implementación simplifican el proceso de publicación y mejoran el nivel de control al publicar contenido nuevo.

Los permisos de canalización se administran (para usuarios que pueden implementar contenido con una canalización de implementación) por separado de los roles del área de trabajo. Se requiere acceso tanto al área de trabajo como a la canalización de implementación para los usuarios que realizan una implementación.

Los creadores de contenido también pueden necesitar lo siguiente:

• Permisos de creación del área de trabajo (cuando la canalización debe crear las áreas de trabajo).
• Permisos de capacidad Premium o Fabric (cuando la canalización asigna áreas de trabajo).

Para más información, consulte Acceso a las canalizaciones de implementación.

Punto de conexión de XMLA

El punto de conexión XMLA usa el protocolo XMLA para exponer todas las características de un modelo de datos tabular, incluidas algunas operaciones de modelado de datos que no son compatibles con Power BI Desktop. Puede usar la API del Modelo de objetos tabulares (TOM) para realizar cambios mediante programación en un modelo de datos.

El punto de conexión XMLA también proporciona conectividad. Solo puede conectarse a un modelo semántico cuando el área de trabajo que tiene su modo de licencia establecido en Premium por usuario, Premium por capacidad o Embedded. Una vez realizada una conexión, una herramienta compatible con XMLA puede funcionar en el modelo de datos para leer o escribir datos. Para obtener más información sobre cómo puede usar el punto de conexión XMLA para administrar un modelo semántico, consulte el escenario de uso de administración avanzada de modelos de datos.

El acceso a través del punto de conexión XMLA respetará los permisos existentes. Los administradores, miembros y colaboradores del área de trabajo tienen implícitamente permiso de escritura del modelo semántico, lo que significa que pueden implementar nuevos modelos semánticos desde Visual Studio y ejecutar scripts del lenguaje de scripting tabular de modelado (TMSL) en SQL Server Management Studio (SSMS).

Los usuarios con el permiso de compilación del modelo semántico pueden usar el punto de conexión XMLA para conectarse a los modelos semánticos y examinar los modelos semánticos para su consumo y visualización. Se respetan las reglas de RLS y los usuarios no pueden ver los metadatos internos del modelo semántico.

La configuración de inquilino Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales hace referencia a dos funcionalidades: controla qué grupos de usuarios pueden usar el punto de conexión XMLA para consultar o mantener modelos semánticos en el servicio Power BI. y también determina si Analizar en Excel se puede usar con modelos locales de SQL Server Analysis Services (SSAS).

Publicar en Web

Publicar en la web es una característica que proporciona acceso a los informes de Power BI a cualquier persona de Internet. No requiere autenticación y el acceso no se registra con fines de auditoría. Dado que los consumidores de informes no necesitan pertenecer a la organización o tener una licencia de Power BI, esta técnica es adecuada para el periodismo de datos, un proceso en el que los informes se insertan en entradas de blog, sitios web, correos electrónicos o redes sociales.

La configuración de inquilino Publicar en la web permite a los administradores de Power BI controlar qué grupos de usuarios pueden publicar informes en la web. Para mantener un mayor nivel de control, se recomienda no incluir otros grupos en esta configuración de inquilino (como administradores de Power BI u otros tipos de creadores de contenido). En su lugar, aplique el acceso de usuario específico mediante un grupo de seguridad, como la publicación pública de Power BI. Asegúrese de que el grupo de seguridad esté bien administrado.

Inserción en aplicaciones personalizadas

La configuración de inquilino Insertar contenido en aplicaciones permite a los administradores de Power BI controlar qué usuarios pueden insertar contenido de Power BI fuera del servicio Power BI. Cuando planee insertar contenido de Power BI en aplicaciones personalizadas, habilite esta configuración para grupos específicos, como los desarrolladores de aplicaciones.

Inserción en PowerPoint

La configuración de inquilino Habilitar complemento de Power BI para PowerPoint permite a los administradores de Power BI controlar qué usuarios pueden insertar páginas de informes de Power BI en presentaciones de PowerPoint. Cuando corresponda, habilite esta configuración para grupos específicos, como los creadores de informes.

Informe a los creadores de informes de que deben tener cuidado de dónde guardan sus presentaciones de PowerPoint y con quién las comparten. Esto se debe a que se muestra una imagen de los objetos visuales de informe de Power BI a los usuarios cuando abren la presentación. Esa imagen se capturó la última vez que se conectó el archivo de PowerPoint. Sin embargo, la imagen podría revelar accidentalmente los datos que el usuario receptor no tiene permiso para ver.

Aplicaciones plantilla

Las aplicaciones de plantilla permiten a los asociados de Power BI y a los proveedores de software crear aplicaciones de Power BI sin tener que escribir código (o muy poco) e implementarlas en cualquier cliente de Power BI.

La configuración de inquilino Publicar aplicaciones de plantilla permite a los administradores de Power BI controlar qué usuarios pueden publicar aplicaciones de plantilla fuera de la organización, como a través de Microsoft AppSource. Para la mayoría de las organizaciones, esta configuración de inquilino debe deshabilitarse o controlarse con detalle. Considere la posibilidad de usar un grupo de seguridad como creadores de aplicaciones de plantillas externas de Power BI.

Suscripciones de correo electrónico

Puede suscribirse y suscribir a otros usuarios a informes, paneles e informes paginados de Power BI. A continuación, Power BI enviará un correo electrónico según una programación establecida. El correo electrónico contendrá una instantánea y un vínculo al informe o panel.

Puede crear una suscripción que incluya a otros usuarios cuando sea administrador, miembro o colaborador del área de trabajo. Si el informe está en un área de trabajo Premium, puede suscribirse a grupos (tanto si están en el dominio como si no) y a usuarios externos. Al configurar la suscripción, también está la opción de conceder permisos al elemento. Los permisos de acceso directo por elemento se usan para este propósito y se describen en el artículo Planeamiento de la seguridad del consumidor de informes.

La configuración de inquilino Suscripciones de correo electrónico permite a los administradores de Power BI controlar si esta característica está habilitada o deshabilitada para toda la organización.

Existen algunas limitaciones relativas a los datos adjuntos relacionados con las restricciones de configuración de inquilinos y licencias. Para más información, vea Suscripciones de correo electrónico para informes y paneles en el servicio Power BI.

Lista de comprobación: al planear la publicación de contenido, las decisiones clave y las acciones incluyen las siguientes:

Actualización de datos

Una vez publicados, los creadores de datos deben asegurarse de que sus modelos semánticos y flujos de datos (que contienen datos importados) se actualicen periódicamente. También debe decidir las estrategias adecuadas para los propietarios del modelo semántico y del flujo de datos.

Propietario del modelo semántico

Cada modelo semántico tiene un propietario, que corresponde a una sola cuenta de usuario. El propietario del modelo semántico es necesario para configurar el modelo semántico y establecer los parámetros del modelo semántico.

De forma predeterminada, el propietario del modelo semántico también recibe solicitudes de acceso de los creadores de informes que quieren permisos de compilación (a menos que se establezca la configuración de solicitud de acceso para el modelo semántico para proporcionar instrucciones personalizadas). Para obtener más información, consulte la sección Solicitud del flujo de trabajo de acceso para creadores de este artículo.

Hay dos maneras de que Power BI pueda obtener credenciales para actualizar un modelo semántico.

• El propietario del modelo semántico almacena las credenciales en la configuración del modelo semántico.
• El propietario del modelo semántico hace referencia a una puerta de enlace en la configuración del modelo semántico (que contiene un origen de datos con credenciales almacenadas).

Si un usuario diferente necesita configurar los parámetros de actualización o del modelo semántico, debe tomar posesión del modelo semántico. Un administrador del área de trabajo, un miembro o un colaborador pueden asumir la propiedad del modelo semántico.

Lo ideal es que el propietario del modelo semántico sea el usuario responsable del mismo. Debe actualizar el propietario del modelo semántico cuando este abandone la organización o se cambien los roles. Además, tenga en cuenta que cuando la cuenta de usuario del propietario del modelo semántico está deshabilitada en el identificador de Microsoft Entra, la actualización de datos se deshabilita automáticamente. En este caso, otro usuario deberá tomar posesión del modelo semántico para permitir que se reanuden las operaciones de actualización de datos.

Propietario del flujo de datos

Al igual que los modelos semánticos, los flujos de datos también tienen un propietario, que es una sola cuenta de usuario. La información y las instrucciones proporcionadas en el tema anterior sobre los propietarios de modelos semánticos también se aplican a los propietarios del flujo de datos.

Lista de comprobación: al planear la seguridad relacionada con los procesos de actualización de datos, las decisiones y las acciones clave incluyen:

Contenido relacionado

Para obtener otras consideraciones, acciones, criterios de toma de decisiones y recomendaciones para las decisiones de implementación de Power BI, vea las áreas temáticas que se deben tener en cuenta.