Documento técnico de seguridad de Power BI

Resumen: Power BI es una oferta de servicio de software en línea (SaaS o Software como servicio) de Microsoft que le permite crear fácilmente y rápidamente paneles de inteligencia empresarial de autoservicio, informes, modelos semánticos y visualizaciones. Con Power BI, puede conectarse a muchos orígenes de datos diferentes, combinar y dar forma a los datos de esas conexiones y, a continuación, crear informes y paneles que se pueden compartir con otros usuarios.

Escritores: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Revisores técnicos: Cristian Petculescu, Amir Netz, Sergio Gundorov

Se aplica a: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Nota:

Puede guardar o imprimir este documento técnico seleccionando Imprimir en el explorador y luego seleccionando Guardar como PDF.

Introducción

Power BI es una oferta de servicio de software en línea (SaaS o Software como servicio) de Microsoft que le permite crear fácilmente y rápidamente paneles de inteligencia empresarial de autoservicio, informes, modelos semánticos y visualizaciones. Con Power BI, puede conectarse a muchos orígenes de datos diferentes, combinar y dar forma a los datos de esas conexiones y, a continuación, crear informes y paneles que se pueden compartir con otros usuarios.

El mundo está cambiando rápidamente; Las organizaciones están pasando por una transformación digital acelerada, y estamos viendo un aumento masivo en el trabajo remoto, una mayor demanda de clientes para los servicios en línea y un mayor uso de tecnologías avanzadas en operaciones y toma de decisiones empresariales. Y todo esto funciona con la nube.

A medida que la transición a la nube ha cambiado de un goteo a un torrente, y con la nueva área expuesta que viene con ella, más empresas preguntan ¿Qué tan seguros están mis datos en la nube? y ¿Qué protección integral está disponible para evitar que mis datos confidenciales se filtren? Y para las plataformas de BI que a menudo manejan parte de la información más estratégica de la empresa, estas preguntas son doblemente importantes.

Las bases antiguas del modelo de seguridad de BI (seguridad de nivel de objeto y de nivel de fila), aunque aún son importantes, ya no son suficientes para proporcionar el tipo de seguridad necesaria en la era de la nube. En su lugar, las organizaciones deben buscar una solución de seguridad nativa de nube, de varios niveles y de defensa en profundidad para sus datos de inteligencia empresarial.

Power BI se creó para proporcionar protección completa e impenetrable de los datos, líder en el sector. El producto ha obtenido las clasificaciones de seguridad más altas disponibles en la industria, y hoy en día muchos organismos de seguridad nacionales, instituciones financieras y proveedores de atención médica lo confían con su información más confidencial.

Todo comienza con la base. Después de un período difícil a principios de los años 2000, Microsoft realizó inversiones masivas para abordar sus vulnerabilidades de seguridad y, en las décadas siguientes, creó una pila de seguridad sólida que va tan profundamente como el kernel de la bios del chip de la máquina y se extiende todo el camino hasta las experiencias de los usuarios finales. Estas inversiones profundas continúan y en la actualidad más de 3500 ingenieros de Microsoft se dedican a crear y mejorar la pila de seguridad de Microsoft y abordar de forma proactiva el panorama de amenazas que cambia constantemente. Con miles de millones de equipos, billones de inicios de sesión e innumerables zettabytes de información encomendada a la protección de Microsoft, la empresa ahora posee la pila de seguridad más avanzada del sector tecnológico y se ve ampliamente como líder global en la lucha contra actores malintencionados.

Power BI se basa en esta base sólida. Usa la misma pila de seguridad que le otorgó a Azure la capacidad de servir y proteger los datos más confidenciales del mundo, y se integra con las herramientas de protección de la información y cumplimiento más avanzadas de Microsoft 365. Además de esto, ofrece seguridad a través de medidas de seguridad multicapa, lo que da lugar a una protección integral diseñada para afrontar los desafíos únicos de la era de la nube.

Para proporcionar una solución de un extremo a otro para proteger los recursos confidenciales, el equipo de productos necesitaba abordar problemas desafiantes de los clientes en varios frentes simultáneos:

• ¿Cómo controlamos quién puede conectarse, dónde se conectan y cómo se conectan?¿Cómo podemos controlar las conexiones?
• ¿Cómo se almacenan los datos?¿Cómo se cifra?¿Qué controles tengo en mis datos?
• ¿Cómo puedo controlar y proteger mis datos confidenciales?¿Cómo puedo asegurarme de que estos datos no se pueden filtrar fuera de la organización?
• ¿Cómo audito quién realiza las operaciones?¿Cómo puedo reaccionar rápidamente si hay actividad sospechosa en el servicio?

En este artículo se proporciona una respuesta completa a todas estas preguntas. Comienza con una visión general de la arquitectura del servicio y explica cómo funcionan los flujos principales del sistema. A continuación, pasa a describir cómo se autentican los usuarios en Power BI, cómo se establecen las conexiones de datos y cómo Power BI almacena y mueve los datos a través del servicio. En la última sección se describen las características de seguridad que le permiten, como administrador de servicios, proteger los recursos más valiosos.

El servicio Power BI se rige por los Términos de Microsoft Online Services y la Declaración de privacidad de Microsoft Enterprise. Para obtener la ubicación del procesamiento de datos, consulte La ubicación de los términos de procesamiento de datos en los términos de Microsoft Online Services y el anexo de protección de datos. Para obtener información de cumplimiento, el Centro de confianza de Microsoft es el recurso principal de Power BI. El equipo de Power BI está trabajando duro para aportar a sus clientes las últimas innovaciones y productividad. Obtenga más información sobre el cumplimiento en las ofertas de cumplimiento de Microsoft.

El servicio Power BI sigue el Ciclo de Vida de Desarrollo de Seguridad (SDL), que incluye prácticas de seguridad estrictas para garantizar el cumplimiento y la seguridad. La SDL ayuda a los desarrolladores a crear software más seguro reduciendo el número y la gravedad de las vulnerabilidades del software, al tiempo que se reducen los costes de desarrollo. Obtenga más información en Prácticas de ciclo de vida de desarrollo de seguridad de Microsoft.

Arquitectura de Power BI

El servicio Power BI se basa en Azure, la plataforma informática en la nube de Microsoft. Power BI se implementa actualmente en muchos centros de datos de todo el mundo; hay muchas implementaciones activas disponibles para los clientes de las regiones atendidas por esos centros de datos y un número igual de implementaciones pasivas que sirven como copias de seguridad para cada implementación activa.

Clúster front-end web (WFE)

El clúster de front-end web (WFE) proporciona al navegador del usuario el contenido inicial de la página HTML cuando se carga el sitio, así como punteros al contenido de la red de entrega de contenido de Azure (CDN) utilizado para representar el sitio en el navegador.

Un clúster WFE consta de un sitio web de ASP.NET que se ejecuta en Azure App Service Environment. Cuando los usuarios intentan conectarse al servicio Power BI, el servicio DNS del cliente puede comunicarse con Azure Traffic Manager para encontrar el centro de datos más adecuado (normalmente más cercano) con una implementación de Power BI. Para más información sobre este proceso, consulte Método de enrutamiento de tráfico de rendimiento para Azure Traffic Manager.

Los recursos estáticos como *.js, *.css y los archivos de imagen se almacenan principalmente en una red CDN de Azure y se recuperan directamente mediante el explorador. Tenga en cuenta que las implementaciones de clústeres de Gobierno soberano son una excepción a esta regla y, por motivos de cumplimiento, omitirá la red CDN y, en su lugar, usará un clúster WFE de una región compatible para hospedar contenido estático.

Clúster de back-end de Power BI

El clúster back-end es la red troncal de toda la funcionalidad disponible en Power BI. Consta de varios puntos de conexión de servicio consumidos por clientes de WFE y API, así como servicios de trabajo en segundo plano, bases de datos, memorias caché y otros componentes.

El back-end está disponible en la mayoría de las regiones de Azure y se está implementando en nuevas regiones a medida que estén disponibles. Una sola región de Azure hospeda uno o varios clústeres back-end que permiten el escalado horizontal ilimitado del servicio Power BI una vez agotados los límites de escalado vertical y horizontal de un único clúster.

Cada clúster de back-end tiene estado y hospeda todos los datos de todos los inquilinos asignados a ese clúster. Un clúster que contiene los datos de un inquilino específico se conoce como clúster principal del inquilino. El servicio global proporciona información del clúster principal de un usuario autenticado y la usa WFE para enrutar las solicitudes al clúster principal del inquilino.

Cada clúster de back-end consta de varias máquinas virtuales combinadas en varios conjuntos de escalado ajustables, diseñados para realizar tareas específicas, y que pueden incluir recursos con estado como bases de datos SQL, cuentas de almacenamiento, buses de servicio, cachés y otros componentes necesarios en la nube.

Los metadatos y los datos del inquilino se almacenan dentro de los confines del clúster, salvo para la replicación de datos en un clúster de back-end secundario en una región de Azure emparejada en la misma geografía de Azure. El clúster back-end secundario actúa como un clúster de conmutación por error en caso de interrupción regional y es pasivo en cualquier otro momento.

La funcionalidad del back-end es proporcionada por microservicios que se ejecutan en diferentes máquinas dentro de la red virtual del clúster, las cuales no son accesibles desde el exterior, salvo para dos componentes a los que se puede acceder desde la internet pública:

• Servicio de puerta de enlace
• Azure API Management

Infraestructura de Power BI Premium

Power BI Premium ofrece un servicio para suscriptores que requieren características premium de Power BI, como inteligencia artificial avanzada, distribución a usuarios sin licencia, etc. Cuando un cliente se suscribe a una suscripción de Power BI Premium, la capacidad Premium se crea a través de Azure Resource Manager.

Las capacidades de Power BI Premium se hospedan en clústeres back-end que son independientes del back-end normal de Power BI, como se ha descrito anteriormente. Esto proporciona un mejor aislamiento, asignación de recursos, compatibilidad, aislamiento de seguridad y escalabilidad de la oferta Premium.

En el diagrama siguiente se muestra la arquitectura de la infraestructura de Power BI Premium:

La conexión a la infraestructura de Power BI Premium se puede realizar de muchas maneras, en función del escenario de usuario. Los clientes de Power BI Premium pueden ser el explorador de un usuario, un back-end de Power BI normal, conexiones directas a través de clientes XMLA, API de ARM, etc.

La infraestructura de Power BI Premium en una región de Azure consta de varios clústeres de Power BI Premium (el mínimo es uno). La mayoría de los recursos Premium se encapsulan dentro de un clúster (por ejemplo, proceso) y hay algunos recursos regionales comunes (por ejemplo, almacenamiento de metadatos). La infraestructura Premium permite dos maneras de lograr escalabilidad horizontal en una región: aumentar los recursos dentro de los clústeres o agregar más clústeres a petición según sea necesario (si los recursos del clúster se aproximan a sus límites).

La red troncal de cada clúster es los recursos de proceso administrados por Virtual Machine Scale Sets y Azure Service Fabric. Virtual Machine Scale Sets y Service Fabric permiten un aumento rápido e indoloro de los nodos de proceso a medida que aumenta el uso y organiza la implementación, la administración y la supervisión de los servicios y aplicaciones de Power BI Premium.

Hay muchos recursos circundantes que garantizan una infraestructura segura y confiable: equilibradores de carga, redes virtuales, grupos de seguridad de red, service bus, almacenamiento, etc. Azure Key Vault administra exclusivamente los secretos, las claves y los certificados necesarios para Power BI Premium. Cualquier autenticación se realiza a través de la integración con microsoft Entra ID exclusivamente.

Cualquier solicitud que llegue a la infraestructura de Power BI Premium se dirige primero a los nodos front-end: son los únicos nodos disponibles para las conexiones externas. El resto de los recursos se ocultan detrás de las redes virtuales. Los nodos front-end autentican la solicitud, la controlan o reenvía a los recursos adecuados (por ejemplo, nodos back-end).

Los nodos back-end proporcionan la mayoría de las funcionalidades y características de Power BI Premium.

Power BI Mobile

Power BI Mobile es una colección de aplicaciones diseñadas para las tres plataformas móviles principales: Android, iOS y Windows (UWP). Las consideraciones de seguridad para las aplicaciones de Power BI Mobile se dividen en dos categorías:

• comunicación de dispositivos
• La aplicación y los datos en el dispositivo

Para la comunicación con el dispositivo, todas las aplicaciones Power BI Mobile se comunican con el servicio Power BI, y usan las mismas secuencias de conexión y autenticación usadas por los exploradores, que se describen en detalle anteriormente en esta nota de producto. Las aplicaciones móviles de Power BI para iOS y Android traen una sesión del explorador dentro de la propia aplicación, mientras que la aplicación móvil de Windows abre un agente para establecer el canal de comunicación con Power BI (para el proceso de inicio de sesión).

En la tabla siguiente se muestra la compatibilidad con la autenticación basada en certificados (CBA) para Power BI Mobile, en función de la plataforma de dispositivos móviles:

Soporte técnico de CBA	Ios	Androide	Windows
Power BI (iniciar sesión en el servicio)	Compatible	Compatible	No está soportado
SSRS ADFS local (conectarse al servidor SSRS)	No está soportado	Compatible	No está soportado
Proxy de aplicación de SSRS	Compatible	Compatible	No está soportado

Las aplicaciones Power BI Mobile se comunican activamente con el servicio Power BI. Se usan datos de telemetría para recopilar estadísticas de uso y datos similares de las aplicaciones móviles, que se transmiten a los servicios que se usan para supervisar el uso y la actividad; no se envían datos personales con los datos de telemetría.

La aplicación Power BI almacena datos en el dispositivo que facilitan el uso de la aplicación:

• Los tokens de actualización y Microsoft Entra ID se almacenan en un mecanismo seguro en el dispositivo, usando medidas de seguridad estándar del sector.
• Los datos y la configuración (pares clave-valor para la configuración de usuario) se almacenan en caché en el almacenamiento en el dispositivo y se pueden cifrar mediante el sistema operativo. En iOS, esto se realiza automáticamente cuando el usuario establece un código de acceso. En Android, esto se puede configurar en la configuración. En Windows, se logra mediante BitLocker.
• En el caso de las aplicaciones de Android e iOS, los datos y la configuración (pares clave-valor para la configuración de usuario) se almacenan en caché en la memoria del dispositivo dentro de un entorno protegido y un almacenamiento interno accesible exclusivamente para la aplicación.
• La geolocalización es habilitada o deshabilitada explícitamente por el usuario. Si está habilitado, los datos de geolocalización no se guardan en el dispositivo y no se comparten con Microsoft.
• Las notificaciones están habilitadas o deshabilitadas explícitamente por el usuario. Si está habilitado, Android e iOS no admiten los requisitos de residencia de datos geográficos para las notificaciones.

El cifrado de datos se puede mejorar aplicando el cifrado de nivel de archivo a través de Microsoft Intune, un servicio de software que proporciona administración de aplicaciones y dispositivos móviles. Las tres plataformas para las que Power BI Mobile está disponible admiten Intune. Con Intune habilitado y configurado, se cifran los datos en el dispositivo móvil y la propia aplicación de Power BI no se puede instalar en una tarjeta SD. Más información sobre Microsoft Intune.

La aplicación de Windows también admite Windows Information Protection (WIP).

Para implementar el inicio de sesión único, algunos valores de almacenamiento protegidos relacionados con la autenticación basada en tokens están disponibles para otras aplicaciones de microsoft (como Microsoft Authenticator) y se administran mediante la Biblioteca de autenticación de Microsoft (MSAL).

Los datos almacenados en caché de Power BI Mobile se eliminan cuando se elimina la aplicación, cuando el usuario cierra la sesión de Power BI Mobile o cuando el usuario no puede iniciar sesión (por ejemplo, después de un evento de expiración de token o cambio de contraseña). La caché de datos incluye los paneles e informes a los que se ha accedido anteriormente desde la aplicación de Power BI Mobile.

Power BI Mobile no tiene acceso a otras carpetas o archivos de aplicación en el dispositivo.

Las aplicaciones de Power BI para iOS y Android permiten proteger los datos mediante la configuración de una identificación adicional, como proporcionar Face ID, Touch ID o un código de acceso para iOS y datos biométricos (id. de huella digital) para Android. Más información sobre la identificación adicional.

Autenticación en el servicio Power BI

La autenticación de usuario en el servicio Power BI consta de una serie de solicitudes, respuestas y redireccionamientos entre el explorador del usuario y el servicio Power BI o los servicios de Azure usados por Power BI. Esta secuencia describe el proceso de autenticación de usuario en Power BI, que sigue el flujo de concesión de código de autenticación de Microsoft Entra. Para obtener más información sobre las opciones de los modelos de autenticación de usuario (modelos de inicio de sesión) de una organización, consulte Elección de un modelo de inicio de sesión para Microsoft 365.

Secuencia de autenticación

La secuencia de autenticación de usuario para el servicio Power BI se produce como se describe en los pasos siguientes, que se muestran en la imagen que los sigue.

1. Un usuario inicia una conexión con el servicio Power BI desde un explorador, ya sea escribiendo la dirección de Power BI en la barra de direcciones o seleccionando Iniciar sesión en la página de marketing de Power BI (https://powerbi.microsoft.com). La conexión se establece mediante TLS y HTTPS, y todas las comunicaciones posteriores entre el explorador y el servicio Power BI usan HTTPS.

2. Azure Traffic Manager comprueba el registro DNS del usuario para determinar el centro de datos más adecuado (normalmente más cercano) donde se implementa Power BI y responde al DNS con la dirección IP del clúster WFE al que se debe enviar el usuario.

3. A continuación, WFE devuelve una página HTML al cliente del explorador, que contiene una referencia de biblioteca de MSAL.js necesaria para iniciar el flujo de inicio de sesión.

4. El cliente del explorador carga la página HTML recibida de WFE y redirige al usuario a la página de inicio de sesión de Microsoft Online Services.

5. Una vez autenticado el usuario, la página de inicio de sesión redirige al usuario a la página WFE de Power BI con un código de autenticación.

6. El cliente del explorador carga la página HTML y usa el código de autenticación para solicitar tokens (acceso, identificador, actualización) de Microsoft Entra ID.

7. El cliente del explorador usa el identificador de inquilino del usuario para consultar el servicio global de Power BI, que mantiene una lista de inquilinos y sus ubicaciones de clúster de back-end de Power BI. El servicio global de Power BI determina qué clúster del servicio de back-end de Power BI contiene el tenant del usuario y devuelve la dirección URL del clúster de back-end de Power BI al cliente.

8. El cliente ahora puede comunicarse con la API de URL del clúster posterior de Power BI mediante el token de acceso en el encabezado de autorización de las solicitudes HTTP. El token de acceso de Microsoft Entra tendrá una fecha de expiración establecida según las directivas de Microsoft Entra y, para mantener la sesión actual, el cliente de Power BI en el explorador del usuario realizará solicitudes periódicas para renovar el token de acceso antes de que expire.

En los casos poco frecuentes en los que se produce un error inesperado en la autenticación del lado cliente, el código intenta revertir al uso de la autenticación del lado servidor en WFE. Consulte la sección de preguntas y respuestas al final de este documento para obtener más información sobre el flujo de autenticación del lado servidor.

Residencia de datos

A menos que se indique lo contrario en la documentación, Power BI almacena los datos de los clientes en una geografía de Azure que se asigna cuando un inquilino de Microsoft Entra se suscribe a los servicios de Power BI por primera vez. Un inquilino de Microsoft Entra alberga las identidades de usuario y aplicación, los grupos y otra información relevante que pertenecen a una organización y su seguridad.

La asignación de una ubicación geográfica de Azure para el almacenamiento de datos del inquilino se realiza mediante la asignación del país o región seleccionado como parte de la configuración del inquilino de Microsoft Entra a la geografía de Azure más adecuada en la que existe una implementación de Power BI. Una vez realizada esta determinación, todos los datos del cliente de Power BI se almacenarán en esta geografía de Azure seleccionada (también conocida como geo principal), excepto en los casos en los que las organizaciones usen implementaciones multigeográficas.

Varias zonas geográficas (multigeográficas)

Algunas organizaciones tienen una presencia global y pueden requerir servicios de Power BI en varias zonas geográficas de Azure. Por ejemplo, una empresa podría tener su sede en los Estados Unidos, pero también puede hacer negocios en otras áreas geográficas, como Australia. En tales casos, la empresa podría requerir que determinados datos de Power BI permanezcan almacenados en reposo en la región remota para cumplir las normativas locales. Esta característica del servicio Power BI se conoce como multigeográfica.

La capa de ejecución de consultas, las cachés de consultas y los datos de artefacto asignados a un área de trabajo multigeográfica se hospedan y permanecen en la capacidad remota de Azure Geography. Sin embargo, algunos metadatos de artefacto, como la estructura del informe, pueden permanecer almacenados en reposo en la geo de inicio del inquilino. Además, es posible que algunos tránsitos y procesamientos de datos sigan sucediendo en la ubicación geográfica principal del inquilino, incluso para las áreas de trabajo hospedadas en una capacidad Premium multigeográfica.

Para más información sobre la creación y administración de implementaciones que abarcan varias zonas geográficas de Azure, consulte Configuración de la compatibilidad con varias regiones geográficas para Fabric.

Regiones y centros de datos

Los servicios de Power BI están disponibles en zonas geográficas específicas de Azure, como se describe en el Centro de confianza de Microsoft. Para obtener más información sobre dónde se almacenan los datos y cómo se usa, consulte el Centro de confianza de Microsoft. Los compromisos sobre la ubicación de los datos de cliente en reposo se especifican en los Términos de procesamiento de datos de los Términos de Microsoft Online Services.

Microsoft también proporciona centros de datos para entidades soberanas. Para más información sobre la disponibilidad del servicio Power BI para nubes nacionales o regionales, consulte Nubes nacionales o regionales de Power BI.

Manejo de datos

En esta sección se describen los procedimientos de control de datos de Power BI en lo que respecta al almacenamiento, procesamiento y transferencia de datos de clientes.

Datos en reposo

Power BI usa dos tipos de recursos de almacenamiento de datos principales:

• Azure Storage
• Bases de datos de Azure SQL

En la mayoría de los escenarios, Azure Storage se usa para conservar los datos de artefactos de Power BI, mientras que las bases de datos de Azure SQL se usan para conservar los metadatos del artefacto.

Todos los datos almacenados por Power BI se cifran de forma predeterminada mediante claves administradas por Microsoft. Los datos del cliente almacenados en bases de datos de Azure SQL están totalmente cifrados mediante la tecnología de cifrado de datos transparente (TDE) de Azure SQL . Los datos del cliente almacenados en Azure Blob Storage se cifran mediante el cifrado de Azure Storage.

Opcionalmente, las organizaciones pueden usar Power BI Premium para usar sus propias claves para cifrar los datos en reposo que se importan en un modelo semántico. Este enfoque suele describirse como Bring Your Own Key (BYOK). El uso de BYOK ayuda a garantizar que, incluso en el caso de un error del operador de servicio, los datos del cliente no se expongan, algo que no se puede lograr fácilmente mediante el cifrado transparente del lado del servicio. Vea Traiga sus propias claves de cifrado para Power BI para obtener más información.

Los modelos semánticos de Power BI permiten varios modos de conexión de origen de datos que determinan si los datos del origen de datos se conservan en el servicio o no.

Modo de modelo semántico (tipo)	Datos persistentes en Power BI
Importación	Sí
Consulta Directa	No
Live Connect	No
Compuesto	Si contiene un origen de datos de importación
Transmisión en línea	Si está configurado para conservarse

Independientemente del modo de modelo semántico utilizado, Power BI podría almacenar temporalmente en caché los datos recuperados para optimizar el rendimiento de la carga de consultas e informes.

Datos en procesamiento

Los datos se procesan cuando uno o varios usuarios lo usan activamente como parte de un escenario interactivo, o cuando un proceso en segundo plano, como la actualización, toca estos datos. Power BI carga datos procesados activamente en el espacio de memoria de una o varias cargas de trabajo de servicio. Para facilitar la funcionalidad requerida por la carga de trabajo, los datos procesados en memoria no se cifran.

Datos en tránsito

Power BI requiere que todo el tráfico HTTP entrante se cifre mediante TLS 1.2 o superior. Las solicitudes que intenten usar el servicio con TLS 1.1 o versiones inferiores se rechazarán.

Autenticación en fuentes de datos

Al conectarse a un origen de datos, un usuario puede optar por importar una copia de los datos en Power BI o conectarse directamente al origen de datos.

En el caso de la importación, un usuario establece una conexión basada en el inicio de sesión del usuario y accede a los datos con la credencial. Una vez publicado el modelo semántico en el servicio Power BI, Power BI siempre usa la credencial de este usuario para importar datos. Una vez importados los datos, ver los datos en informes y paneles no tiene acceso al origen de datos subyacente. Power BI admite la autenticación de inicio de sesión único para orígenes de datos seleccionados. Si la conexión está configurada para usar el inicio de sesión único, las credenciales del propietario del modelo semántico se usan para conectarse al origen de datos.

Si un origen de datos se conecta directamente mediante credenciales preconfiguradas, las credenciales preconfiguradas se usan para conectarse al origen de datos cuando cualquier usuario ve los datos. Si un origen de datos se conecta directamente mediante el inicio de sesión único, las credenciales del usuario actual se usan para conectarse al origen de datos cuando un usuario ve los datos. Cuando se usa con el inicio de sesión único, la seguridad de nivel de fila (RLS) o la seguridad de nivel de objeto (OLS) se puede implementar en el origen de datos. Esto permite a los usuarios ver solo los datos a los que tienen privilegios de acceso. Cuando la conexión es a orígenes de datos en la nube, la autenticación de Microsoft Entra se usa para el inicio de sesión único; para orígenes de datos locales, se admiten Kerberos, Lenguaje de marcado de aserción de seguridad (SAML) y Id. de Microsoft Entra.

Si el origen de datos es Azure Analysis Services o Analysis Services local, y RLS o OLS está configurado, el servicio Power BI aplicará esa seguridad de nivel y los usuarios que no tengan credenciales suficientes para acceder a los datos subyacentes (que podrían ser una consulta usada en un panel, informe u otro artefacto de datos) no verán los datos para los que no tienen privilegios suficientes.

Características Premium

Arquitectura de flujos de datos

Los flujos de datos proporcionan a los usuarios la capacidad de configurar operaciones de procesamiento de datos back-end que extraerán datos de orígenes de datos polimórficos, ejecutarán la lógica de transformación en los datos y, a continuación, lo colocarán en un modelo de destino para su uso en diversas tecnologías de presentación de informes. Cualquier usuario que tenga un rol miembro, colaborador o administrador en un área de trabajo podría crear un flujo de datos. Los usuarios del rol Visor pueden ver los datos procesados por el flujo de datos, pero es posible que no realicen cambios en su composición. Una vez creado un flujo de datos, cualquier miembro, colaborador o administrador del área de trabajo podría programar actualizaciones, así como ver y editar el flujo de datos tomando posesión de él.

Cada origen de datos configurado está enlazado a una tecnología de cliente para acceder a ese origen de datos. La estructura de las credenciales necesarias para acceder a ellas se forma para que coincida con los detalles de implementación necesarios del origen de datos. Los servicios de Power Query aplican la lógica de transformación mientras los datos están en tránsito. En el caso de los flujos de datos Premium, los servicios de Power Query se ejecutan en nodos back-end. Los datos se pueden extraer directamente de los orígenes de nube o a través de una puerta de enlace instalada en el entorno local. Cuando se extrae directamente de un origen de nube al servicio o a la puerta de enlace, el transporte usa la metodología de protección específica de la tecnología del cliente, si procede. Cuando los datos se transfieren de la puerta de enlace al servicio en la nube, se cifran. Consulte la sección Datos en tránsito anterior.

Cuando los orígenes de datos especificados por el cliente requieren credenciales para el acceso, el propietario o creador del flujo de datos los proporcionará durante la creación. Se almacenan mediante almacenamiento estándar de credenciales del producto. Consulte Autenticación de orígenes de datos arriba. Hay varios enfoques que los usuarios pueden configurar para optimizar la persistencia y el acceso a los datos. De forma predeterminada, los datos se colocan en una cuenta de almacenamiento protegida y propiedad de Power BI. El cifrado de almacenamiento está habilitado en los contenedores de Blob Storage para proteger los datos mientras está en reposo. Consulte Los datos en reposo a continuación. Sin embargo, los usuarios pueden configurar su propia cuenta de almacenamiento asociada a su propia suscripción de Azure. Al hacerlo, se concede acceso a un principal del servicio de Power BI a esa cuenta de almacenamiento para que pueda escribir los datos allí durante la actualización de datos. En este caso, el propietario del recurso de almacenamiento es responsable de configurar el cifrado en la cuenta de Azure Data Lake Storage configurada. Los datos siempre se transmiten a Blob Storage mediante cifrado.

Dado que el rendimiento al acceder a las cuentas de almacenamiento puede ser poco óptimo para algunos datos, los usuarios también tienen la opción de usar un motor de proceso hospedado en Power BI para aumentar el rendimiento. En este caso, los datos se almacenan con redundancia en una base de datos SQL que está disponible para DirectQuery a través del acceso mediante el sistema back-end de Power BI. Los datos siempre se cifran en el sistema de archivos. Si el usuario proporciona una clave para cifrar los datos almacenados en la base de datos SQL, esa clave se usará para cifrarlo doblemente.

Al consultar mediante DirectQuery, el protocolo de transporte cifrado HTTPS se usa para acceder a la API. Todos los controles de acceso descritos anteriormente controlan todo el uso secundario o indirecto de DirectQuery. Dado que los flujos de datos siempre están enlazados a un área de trabajo, el acceso a los datos siempre está cerrado por el rol del usuario en esa área de trabajo. Un usuario debe tener al menos acceso de lectura para poder consultar los datos a través de cualquier medio.

Cuando Power BI Desktop se usa para acceder a los datos de un flujo de datos, primero debe autenticar al usuario mediante el identificador de Entra de Microsoft para determinar si el usuario tiene derechos suficientes para ver los datos. Si es así, se adquiere una clave SaS y se usa para acceder al almacenamiento directamente mediante el protocolo de transporte cifrado HTTPS.

El procesamiento de datos en toda la tubería emite eventos de auditoría de Office 365. Algunos de estos eventos capturarán operaciones relacionadas con la seguridad y la privacidad.

Informes paginados

Están diseñados para imprimirse o compartirse. Se denominan paginados porque presentan un formato apto para encajar en una página. Muestran todos los datos en una tabla, incluso si esta abarca varias páginas. Puede controlar el diseño de la página del informe totalmente.

Los informes paginados admiten expresiones enriquecidas y eficaces escritas en Microsoft Visual Basic .NET. En los informes paginados de Power BI Report Builder se usan ampliamente expresiones para recuperar, calcular, mostrar, agrupar, ordenar, filtrar, parametrizar y dar formato a los datos.

El autor del informe crea expresiones con acceso a la amplia gama de características de .NET Framework. El procesamiento y ejecución de informes paginados se realiza dentro de un espacio aislado.

Las definiciones de informes paginados (.rdl) se almacenan en Power BI y, para publicar o representar un informe paginado, un usuario debe autenticarse y autorizar de la misma manera que se describe en Autenticación en el servicio Power BI.

El token de Microsoft Entra obtenido durante la autenticación se usa para comunicarse directamente desde el explorador al clúster de Power BI Premium.

En Power BI Premium, el entorno de ejecución de servicio Power BI proporciona un entorno de ejecución de aislamiento adecuado para cada representación de informe. Esto incluye casos en los que los informes que se generan pertenecen a espacios de trabajo asignados a la misma capacidad.

Un informe paginado puede acceder a un amplio conjunto de orígenes de datos como parte de la representación del informe. El espacio aislado no se comunica directamente con ninguno de los orígenes de datos, sino que se comunica con el proceso de confianza para solicitar datos y, a continuación, el proceso de confianza anexa las credenciales necesarias a la conexión. De este modo, el espacio aislado nunca tiene acceso a ninguna credencial o secreto.

Para admitir características como Mapas de Bing o llamadas a Funciones de Azure, el espacio aislado sí tiene acceso a internet.

Análisis integrados de Power BI

Los proveedores de software independientes (ISV) y los proveedores de soluciones tienen dos modos principales de insertar artefactos de Power BI en sus aplicaciones web y portales: insertar para su organización e insertar para sus clientes. El artefacto se inserta en un IFrame en la aplicación o el portal. No se permite que un IFrame lea o escriba datos desde la aplicación web externa o el portal, y la comunicación con IFrame se realiza mediante el SDK de cliente de Power BI mediante mensajes POST.

En un escenario de inserción para su organización, los usuarios de Microsoft Entra acceden a su propio contenido de Power BI a través de portales personalizados por sus empresas y departamentos de TI. Todas las directivas y funcionalidades de Power BI descritas en este documento, como RLS y OLS, se aplican automáticamente a todos los usuarios independientemente de si acceden a Power BI a través del portal de Power BI o a través de portales personalizados.

En un escenario de inserción para sus clientes, los ISV normalmente poseen inquilinos de Power BI y elementos de Power BI (paneles, informes, modelos semánticos y otros). Es responsabilidad de un servicio back-end de ISV autenticar a sus usuarios finales y decidir qué artefactos y qué nivel de acceso es adecuado para ese usuario final. Las decisiones de directiva de ISV se cifran en un token de inserción generado por Power BI y se pasan al back-end de ISV para su posterior distribución a los usuarios finales según la lógica de negocios del ISV. Los usuarios finales que usan un explorador u otras aplicaciones cliente no pueden descifrar ni modificar tokens de inserción. Los SDK del lado cliente, como las API de cliente de Power BI , anexan automáticamente el token de inserción cifrado a las solicitudes de Power BI como un encabezado Authorization: EmbedToken . En función de este encabezado, Power BI aplicará todas las directivas (como el acceso o RLS) exactamente según lo especificado por el ISV durante la generación.

Para habilitar la inserción y la automatización, y para generar los tokens de inserción descritos anteriormente, Power BI expone un amplio conjunto de API REST. Estas API REST de Power BI admiten métodos de autenticación y autorización delegados por el usuario y principal de servicio de Microsoft Entra.

Los análisis integrados de Power BI y sus API REST admiten todas las funcionalidades de aislamiento de red de Power BI que se describen en este artículo, incluidas las etiquetas de servicio y los vínculos privados.

Características de IA

Actualmente, Power BI admite dos amplias categorías de características de inteligencia artificial en el producto: objetos visuales de inteligencia artificial y enriquecimientos con IA. Las características de inteligencia artificial de nivel visual incluyen funcionalidades como influenciadores clave, árbol de descomposición, narración inteligente, detección de anomalías, objeto visual de R, objeto visual de Python, agrupación en clústeres, previsión, preguntas y respuestas, Conclusiones rápidas, etc. Las funcionalidades de enriquecimiento con IA incluyen funcionalidades como AutoML, Azure Machine Learning, CognitiveServices, transformaciones de R/Python, etc.

La mayoría de las características mencionadas anteriormente se admiten en las áreas de trabajo Compartidas y Premium actuales. Sin embargo, AutoML y CognitiveServices solo se admiten en áreas de trabajo Premium, debido a restricciones de IP. En la actualidad, con la integración de AutoML en Power BI, un usuario puede compilar y entrenar un modelo de aprendizaje automático personalizado (ML) (por ejemplo, Predicción, Clasificación, Regresión, etc.) y aplicarlo para obtener predicciones al cargar datos en un flujo de datos definido en un área de trabajo Premium. Además, los usuarios de Power BI pueden aplicar varias API de CognitiveServices, como TextAnalytics e ImageTagging, para transformar los datos antes de cargarlos en un modelo semántico o flujo de datos definido en un área de trabajo Premium.

Las características de enriquecimiento con inteligencia artificial Premium se pueden ver mejor como una colección de funciones o transformaciones de inteligencia artificial sin estado que pueden usar los usuarios de Power BI en sus canalizaciones de integración de datos usadas por un modelo semántico de Power BI o un flujo de datos. Tenga en cuenta que también se puede acceder a estas funciones desde entornos de creación de modelos semánticos o flujos de datos actuales en el servicio Power BI y Power BI Desktop. Estas funciones o transformaciones de IA siempre se ejecutan en un área de trabajo o capacidad Premium. Estas funciones se muestran en Power BI como origen de datos que requiere un token de Microsoft Entra para el usuario de Power BI que usa la función de IA. Estos orígenes de datos de IA son especiales porque no exponen ninguno de sus propios datos y solo proporcionan estas funciones o transformaciones. Durante la ejecución, estas características no realizan ninguna llamada saliente a otros servicios para transmitir los datos del cliente. Echemos un vistazo individualmente a los escenarios Premium para comprender los patrones de comunicación y los detalles pertinentes relacionados con la seguridad relacionados con ellos.

Para el entrenamiento y la aplicación de un modelo de AutoML, Power BI usa el SDK de Azure AutoML y ejecuta todo el entrenamiento en la capacidad de Power BI del cliente. Durante las iteraciones de entrenamiento, Power BI llama a una experimentación de Azure Machine Learning Service para seleccionar un modelo adecuado y hiperparámetres para la iteración actual. En esta llamada saliente, solo se envían metadatos de experimento pertinentes (por ejemplo, precisión, algoritmo de ml, parámetros de algoritmo, etc.) de la iteración anterior. El entrenamiento de AutoML genera un modelo ONNX y los datos del informe de entrenamiento que, a continuación, se guardan en el flujo de datos. Más adelante, los usuarios de Power BI pueden aplicar el modelo de aprendizaje automático entrenado como una transformación para operacionalizar el modelo de aprendizaje automático de manera programada. En el caso de las API TextAnalytics e ImageTagging, Power BI no llama directamente a las API del servicio CognitiveServices, sino que usa un SDK interno para ejecutar las API en la capacidad de Power BI Premium. Actualmente, estas API se admiten tanto en flujos de datos de Power BI como en modelos semánticos. Al crear un modelo de datos en Power BI Desktop, los usuarios solo pueden acceder a esta funcionalidad si tienen acceso a un área de trabajo de Power BI Premium. Por lo tanto, se pide a los clientes que proporcionen sus credenciales de Microsoft Entra.

Aislamiento de red

En esta sección se describen las características de seguridad avanzadas en Power BI. Algunas de las características tienen requisitos de licencia específicos. Consulte las secciones siguientes para obtener más información.

Etiquetas de servicio

Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio de Azure determinado. Ayuda a minimizar la complejidad de las actualizaciones frecuentes de las reglas de seguridad de red. Los clientes pueden usar etiquetas de servicio para definir controles de acceso a la red en grupos de seguridad de red o Azure Firewall. Los clientes pueden usar etiquetas de servicio en lugar de direcciones IP específicas al crear reglas de seguridad. Al especificar el nombre de etiqueta de servicio (como PowerBI) en el campo de origen o destino adecuado (para las API) de una regla, los clientes pueden permitir o denegar el tráfico para el servicio correspondiente. Microsoft administra los prefijos de direcciones que la etiqueta de servicio incluye y actualiza automáticamente dicha etiqueta a medida que las direcciones cambian.

Integración de Private Link

Las redes de Azure proporcionan la característica Azure Private Link que permite a Power BI proporcionar acceso seguro a través de puntos de conexión privados de redes de Azure. Con Azure Private Link y puntos de conexión privados, el tráfico de datos se envía de forma privada mediante la infraestructura de red troncal de Microsoft y, por tanto, los datos no atraviesan Internet.

Private Link garantiza que los usuarios de Power BI usen la red troncal de red privada de Microsoft al ir a los recursos del servicio Power BI.

El uso de Private Link con Power BI proporciona las siguientes ventajas:

• Private Link garantiza que el tráfico fluya a través de la red troncal de Azure a un punto de conexión privado para los recursos basados en la nube de Azure.
• El aislamiento del tráfico de red de la infraestructura no basada en Azure, como el acceso local, requeriría que los clientes tuvieran ExpressRoute o una VPN configurada.

Consulte Vínculos privados para obtener acceso seguro a Fabric para obtener información adicional.

Conectividad VNet

Aunque la característica de integración de Private Link proporciona conexiones entrantes seguras a Power BI, la característica de conectividad de red virtual permite una conectividad saliente segura de Power BI a orígenes de datos dentro de una red virtual.

Las puertas de enlace de red virtual (administradas por Microsoft) eliminan la sobrecarga de instalar y supervisar puertas de enlace de datos locales para conectarse a orígenes de datos asociados a una red virtual. Sin embargo, siguen el proceso familiar de gestión de orígenes de datos y seguridad, tal como lo harían con una puerta de enlace de datos local.

A continuación se muestra información general sobre lo que sucede cuando interactúa con un informe de Power BI conectado a un origen de datos dentro de una red virtual mediante puertas de enlace de red virtual:

1. El servicio en la nube de Power BI (o uno de los otros servicios en la nube admitidos) inicia una consulta y envía la consulta, los detalles del origen de datos y las credenciales al servicio power Platform VNet (PP VNet).

2. A continuación, el servicio de red virtual pp inserta de forma segura un contenedor que ejecuta una puerta de enlace de red virtual en la subred. Este contenedor ahora puede conectarse a los servicios de datos accesibles desde esta subred.

3. A continuación, el servicio de red virtual pp envía la consulta, los detalles del origen de datos y las credenciales a la puerta de enlace de red virtual.

4. La puerta de enlace de red virtual obtiene la consulta y se conecta a las fuentes de datos con esas credenciales.

5. A continuación, la consulta se envía al origen de datos para su ejecución.

6. Después de la ejecución, los resultados se envían a la puerta de enlace de red virtual y el servicio de red virtual pp inserta de forma segura los datos del contenedor en el servicio en la nube de Power BI.

Principales del servicio

Power BI admite el uso de entidades de servicio. Almacene las credenciales de entidad de servicio que se utilizan para cifrar o acceder a Power BI en un Key Vault, asigne directivas de acceso adecuadas al almacén y revise periódicamente los permisos de acceso.

Consulte Automatización del área de trabajo Premium y tareas de modelo semántico con entidades de servicio para obtener más información.

Microsoft Purview para Power BI

Microsoft Purview Information Protection (Protección de la Información)

Power BI está profundamente integrado con Microsoft Purview Information Protection. Microsoft Purview Information Protection permite a las organizaciones tener una única solución integrada para clasificación, etiquetado, auditoría y cumplimiento en Azure, Power BI y Office.

Cuando la protección de la información está habilitada en Power BI:

• Los datos confidenciales, tanto en el servicio Power BI como en Power BI Desktop, se pueden clasificar y etiquetar con las mismas etiquetas de confidencialidad que se usan en Office y en Azure.
• Las directivas de gobernanza se pueden aplicar cuando el contenido de Power BI se exporta a archivos excel, PowerPoint, PDF, Word o .pbix , para ayudar a garantizar que los datos están protegidos incluso cuando sale de Power BI.
• Es fácil clasificar y proteger archivos .pbix en Power BI Desktop, como se hace en aplicaciones de Excel, Word y PowerPoint. Los archivos se pueden etiquetar fácilmente según su nivel de confidencialidad. Aún más, se pueden cifrar si contienen datos confidenciales de la empresa, lo que garantiza que solo los usuarios autorizados puedan editar estos archivos.
• Los libros de Excel heredan automáticamente etiquetas de sensibilidad cuando se conectan a Power BI, lo que permite mantener una clasificación integral y aplicar protección cuando los modelos semánticos de Power BI se analizan en Excel.
• Las etiquetas de confidencialidad aplicadas a los informes y paneles de Power BI están visibles en las aplicaciones móviles iOS y Android de Power BI.
• Las etiquetas de confidencialidad se conservan cuando un informe de Power BI está incrustado en Teams, SharePoint o en un sitio web seguro. Esto ayuda a las organizaciones a mantener la clasificación y la protección tras la exportación al insertar contenido de Power BI.
• La herencia de etiquetas tras la creación de contenido nuevo en el servicio Power BI garantiza que las etiquetas aplicadas a modelos semánticos o datamarts en el servicio Power BI se aplicarán al nuevo contenido creado sobre esos modelos semánticos y datamarts.
• Las API de escaneo del administrador de Power BI pueden extraer la etiqueta de sensibilidad de un elemento de Power BI, lo que permite a los administradores de Power BI e InfoSec supervisar el etiquetado en el servicio Power BI y elaborar informes para ejecutivos.
• Las API de administración de Power BI permiten que los equipos centrales apliquen mediante programación etiquetas de confidencialidad al contenido del servicio Power BI.
• Los equipos centrales pueden crear directivas de etiquetas obligatorias para aplicar etiquetas en contenido nuevo o editado en Power BI.
• Los equipos centrales pueden crear directivas de etiqueta predeterminadas para asegurarse de que se aplica una etiqueta de confidencialidad a todo el contenido nuevo o cambiado de Power BI.
• El etiquetado automático de sensibilidad descendente en el servicio Power BI garantiza que cuando se aplica o cambia una etiqueta en un modelo semántico o datamart, la etiqueta se aplicará o cambiará automáticamente en todo el contenido descendente conectado al modelo semántico o datamart.

Para más información, consulte Etiquetas de confidencialidad en Power BI.

Directivas de prevención de pérdida de datos (DLP) de Microsoft Purview para Power BI

Las directivas de prevención de pérdida de datos (DLP) de Microsoft Purview ayudan a las organizaciones a reducir el riesgo de pérdida de datos empresariales confidenciales de Power BI. Las directivas DLP les ayudan a cumplir los requisitos de cumplimiento de las normativas gubernamentales o del sector, como el Reglamento general de protección de datos (RGPD) de la Unión Europea o la Ley de Privacidad del Consumidor de California (CCPA) y asegúrese de que sus datos en Power BI se administran.

Cuando se configuran directivas DLP para Power BI:

• La directiva evalúa todos los modelos semánticos dentro de las áreas de trabajo especificadas en la directiva.
• Puede detectar cuándo se cargan datos confidenciales en sus capacidades Premium. Las directivas DLP pueden detectar:
  • Etiquetas de sensibilidad.
  • Tipos de información confidencial. Se admiten más de 260 tipos. La detección de tipos de información confidencial se basa en el examen de contenido de Microsoft Purview.
• Cuando encuentre un modelo semántico identificado como confidencial, puede ver una sugerencia de directiva personalizada que le ayude a comprender lo que debe hacer.
• Si es propietario del modelo semántico, puede invalidar una directiva e impedir que el modelo semántico se identifique como "confidencial" si tiene un motivo válido para hacerlo.
• Si es propietario del modelo semántico, puede notificar un problema con una directiva si concluye que se ha identificado un tipo de información confidencial de forma falsa.
• Se pueden invocar mitigaciones automáticas de riesgos, como alertas al administrador de seguridad.

Para más información, consulte Directivas de prevención de pérdida de datos para Fabric y Power BI.

Microsoft Defender para Cloud Apps para Power BI

Microsoft Defender for Cloud Apps es uno de los principales agentes de seguridad de acceso a la nube del mundo, denominados líderes en el cuadrante mágico de Gartner para el mercado del agente de seguridad de acceso a la nube (CASB). Defender for Cloud Apps se usa para proteger el uso de aplicaciones en la nube. Permite a las organizaciones supervisar y controlar, en tiempo real, sesiones de Power BI de riesgo, como el acceso de usuarios desde dispositivos no administrados. Los administradores de seguridad pueden definir directivas para controlar las acciones del usuario, como descargar informes con información confidencial.

Con Defender for Cloud Apps, las organizaciones pueden obtener las siguientes funcionalidades DLP:

• Establezca controles en tiempo real para aplicar sesiones de usuario de riesgo en Power BI. Por ejemplo, si un usuario se conecta a Power BI desde fuera de su país o región, los controles en tiempo real de Defender for Cloud Apps pueden supervisar la sesión y las acciones de riesgo, como descargar datos etiquetados con una etiqueta de confidencialidad "Extremadamente confidencial", se pueden bloquear inmediatamente.
• Investigue la actividad del usuario de Power BI con el registro de actividad de Defender for Cloud Apps. El registro de actividad de Defender for Cloud Apps incluye la actividad de Power BI, tal como se captura en el registro de auditoría de Office 365, que contiene información sobre todas las actividades de usuario y administrador, así como información de etiquetas de confidencialidad para actividades relevantes, como aplicar, cambiar y quitar etiqueta. Los administradores pueden aprovechar los filtros avanzados de Defender for Cloud Apps y las acciones rápidas para una investigación eficaz de problemas.
• Cree directivas personalizadas para alertar sobre la actividad sospechosa del usuario en Power BI. La característica de directiva de actividad de Defender for Cloud Apps se puede aprovechar para definir sus propias reglas personalizadas, para ayudarle a detectar el comportamiento del usuario que se desvía de la norma e incluso puede actuar sobre ella automáticamente, si parece demasiado peligroso.
• Trabaje con la detección de anomalías integrada de Defender for Cloud Apps. Las directivas de detección de anomalías de Defender for Cloud Apps proporcionan análisis de comportamiento del usuario y aprendizaje automático de modo que esté preparado desde el principio para ejecutar la detección avanzada de amenazas en su entorno de nube. Cuando una directiva de detección de anomalías identifica un comportamiento sospechoso, desencadena una alerta de seguridad.
• Rol de administrador de Power BI en el portal de Defender for Cloud Apps. Defender for Cloud Apps proporciona un rol de administrador específico de la aplicación que se puede usar para conceder a los administradores de Power BI solo los permisos necesarios para acceder a los datos relevantes de Power BI en el portal, como alertas, usuarios en riesgo, registros de actividad y otra información relacionada con Power BI.

Para obtener más información, consulte Uso de controles de Microsoft Defender for Cloud Apps en Power BI.

Preguntas y respuestas de seguridad de Power BI

Las siguientes preguntas son preguntas de seguridad comunes y respuestas para Power BI. Estos se organizan en función de cuándo se agregaron a este libro blanco, para facilitar la capacidad de encontrar rápidamente nuevas preguntas y respuestas cuando se actualiza este documento. Las preguntas más recientes se agregan al final de esta lista.

¿Cómo se conectan los usuarios y obtienen acceso a orígenes de datos al usar Power BI?

• Power BI administra las credenciales en los orígenes de datos de cada usuario para las credenciales en la nube o para la conectividad a través de una puerta de enlace personal. Los orígenes de datos administrados por una puerta de enlace de datos local se pueden compartir entre la empresa y los permisos para estos orígenes de datos se pueden administrar mediante el administrador de la puerta de enlace. Al configurar un modelo semántico, el usuario puede seleccionar una credencial de su almacén personal o usar una puerta de enlace de datos local para usar una credencial compartida.

  En el caso de importación, un usuario establece una conexión basada en el inicio de sesión del usuario y accede a los datos con la credencial. Una vez publicado el modelo semántico en el servicio Power BI, Power BI siempre usa la credencial de este usuario para importar datos. Una vez importados los datos, ver los datos en informes y paneles no tiene acceso al origen de datos subyacente. Power BI admite la autenticación de inicio de sesión único para orígenes de datos seleccionados. Si la conexión está configurada para usar el inicio de sesión único, se usa la credencial del propietario del modelo semántico para conectarse con el origen de datos.

  Para los informes que están conectados a DirectQuery, el origen de datos se conecta directamente mediante una credencial preconfigurada. La credencial preconfigurada se usa para conectarse al origen de datos cuando cualquier usuario ve los datos. Si un origen de datos se conecta directamente mediante el inicio de sesión único, la credencial del usuario actual se usa para conectarse al origen de datos cuando el usuario ve los datos. Cuando se usa con el inicio de sesión único, RLS y/o OLS se pueden implementar en el origen de datos, y esto permite a los usuarios ver los datos a los que tienen privilegios de acceso. Cuando la conexión es a orígenes de datos en la nube, la autenticación de Microsoft Entra se usa para el inicio de sesión único; para orígenes de datos locales, se admiten kerberos, SAML y el identificador de Entra de Microsoft.

  Al conectarse con Kerberos, el UPN del usuario se pasa a la puerta de enlace y, mediante la delegación restringida de Kerberos, se suplanta al usuario y se conecta a los orígenes de datos respectivos. SAML también se admite en la pasarela para el origen de datos de SAP HANA. Hay más información disponible en información general sobre el inicio de sesión único para puertas de enlace.

  Si el origen de datos es Azure Analysis Services o local Analysis Services y RLS o OLS está configurado, el servicio Power BI aplicará esa seguridad de nivel y los usuarios que no tengan credenciales suficientes para acceder a los datos subyacentes (que podrían ser una consulta usada en un panel, informe u otro artefacto de datos) no verán los datos para los que el usuario no tiene privilegios suficientes.

  RLS con Power BI se puede usar para restringir el acceso a datos para usuarios dados. Los filtros restringen el acceso a los datos en el nivel de fila y puede definir filtros dentro de un rol.

  OLS se puede usar para proteger las tablas o columnas confidenciales. Sin embargo, a diferencia de RLS, OLS también protege los nombres de objeto y los metadatos. Esto ayuda a evitar que los usuarios malintencionados detecten incluso la existencia de estos objetos. Las tablas y columnas protegidas se ocultan en la lista de campos cuando se usan herramientas de informes como Excel o Power BI, y además, los usuarios sin permisos no pueden acceder a objetos de metadatos protegidos a través de DAX o cualquier otro método. Desde el punto de vista de los usuarios sin permisos de acceso adecuados, las tablas y columnas protegidas simplemente no existen.

  OLS, junto con RLS, permite mejorar la seguridad de nivel empresarial en informes y modelos semánticos, lo que garantiza que solo los usuarios con los permisos necesarios tengan acceso para ver e interactuar con datos confidenciales.

¿Cómo se transfieren los datos a Power BI?

• Todos los datos solicitados y transmitidos por Power BI se cifran en tránsito mediante HTTPS (excepto cuando el origen de datos elegido por el cliente no admite HTTPS) para conectarse desde el origen de datos al servicio Power BI. Se establece una conexión segura con el proveedor de datos y solo una vez establecida esa conexión, los datos atravesarán la red.

¿Cómo almacena en caché Power BI los datos de informes, paneles o modelos, y es seguro?

• Cuando se accede a un origen de datos, el servicio Power BI sigue el proceso descrito en Autenticación a orígenes de datos.

¿Los clientes almacenan en caché los datos de la página web localmente?

• Cuando los clientes del explorador acceden a Power BI, los servidores web de Power BI establecen la directiva Cache-Control en sin almacenamiento. La directiva no-store indica a los exploradores que no almacenen en caché la página web que ve el usuario y que no almacenen la página web en la carpeta de caché del cliente.

¿Qué ocurre con la seguridad basada en roles, el uso compartido de informes o paneles y las conexiones de datos? ¿Cómo funciona eso en términos de acceso a datos, visualización de paneles, acceso a informes o actualización?

• En el caso de orígenes de datos no habilitados para RLS , si un panel, informe o modelo de datos se comparte con otros usuarios a través de Power BI, los datos están disponibles para los usuarios con los que se comparte para ver e interactuar. Power BI no vuelve a autenticar a los usuarios en el origen original de los datos; Una vez que los datos se cargan en Power BI, el usuario que se autentica en los datos de origen es responsable de administrar qué otros usuarios y grupos pueden ver los datos.

  Cuando se realizan conexiones de datos a un origen de datos compatible con RLS , como un origen de datos de Analysis Services, solo los datos del panel se almacenan en caché en Power BI. Cada vez que se ve o se accede a un informe o modelo semántico en Power BI que usa datos del origen de datos compatible con RLS, el servicio Power BI accede al origen de datos para obtener datos en función de las credenciales del usuario y, si existen permisos suficientes, los datos se cargan en el informe o el modelo de datos para ese usuario. Si se produce un error en la autenticación, el usuario verá un error.

  Para más información, consulte Autenticación en orígenes de datos.

Nuestros usuarios se conectan a los mismos orígenes de datos todo el tiempo, algunos de los cuales requieren credenciales que difieren de sus credenciales de dominio. ¿Cómo pueden evitar tener que introducir estas credenciales cada vez que realizan una conexión de datos?

• Power BI ofrece el Gateway personal de Power BI, que es una característica que permite a los usuarios crear credenciales para varios orígenes de datos diferentes y, a continuación, usar automáticamente esas credenciales al acceder posteriormente a cada uno de esos orígenes de datos. Para más información, consulte Uso de una puerta de enlace personal en Power BI.

¿Qué puertos usan una puerta de enlace de datos local y una puerta de enlace personal? ¿Hay nombres de dominio que deba permitirse con fines de conectividad?

• La respuesta detallada a esta pregunta está disponible en el siguiente artículo: Ajuste de la configuración de comunicación para la puerta de enlace de datos local.

Al trabajar con la puerta de enlace de datos local, ¿cómo se usan las claves de recuperación y dónde se almacenan? ¿Qué ocurre con la administración segura de credenciales?

• Durante la instalación y configuración de la puerta de enlace, el administrador introduce una clave de recuperación. Esa clave de recuperación se usa para generar una clave simétrica AES segura. También se crea una clave asimétrica RSA al mismo tiempo.

  Esas claves generadas (RSA y AES) se almacenan en un archivo ubicado en el equipo local. Ese archivo también está cifrado. El contenido del archivo solo se puede descifrar con esa máquina Windows concreta y solo con esa cuenta de servicio de puerta de enlace determinada.

  Cuando un usuario escribe las credenciales del origen de datos en la interfaz de usuario del servicio Power BI, las credenciales se cifran con la clave pública en el explorador. La puerta de enlace descifra las credenciales mediante la clave privada RSA y las vuelve a cifrar con una clave simétrica AES antes de que los datos se almacenen en el servicio Power BI. Con este proceso, el servicio Power BI nunca tiene acceso a los datos sin cifrar.

¿Qué protocolos de comunicación usan la puerta de enlace de datos local y cómo están protegidos?

• La puerta de enlace admite los dos protocolos de comunicaciones siguientes:

  • AMQP 1.0 : TCP + TLS: este protocolo requiere que los puertos 443, 5671-5672 y 9350-9354 estén abiertos para la comunicación saliente. Se prefiere este protocolo, ya que tiene una menor sobrecarga de comunicación.

  • HTTPS: WebSockets a través de HTTPS + TLS: este protocolo solo usa el puerto 443. El WebSocket se inicia con un único mensaje HTTP CONNECT. Una vez establecido el canal, la comunicación es básicamente TCP+TLS. Puede forzar a la puerta de enlace local a usar este protocolo, modificando una configuración descrita en el artículo de la puerta de enlace local.

¿Cuál es el rol de Azure CDN en Power BI?

• Como se mencionó anteriormente, Power BI usa Azure CDN para distribuir eficazmente el contenido estático y los archivos necesarios a los usuarios en función de la configuración regional geográfica. Para profundizar más detalladamente, el servicio Power BI usa varias redes CDN para distribuir eficazmente el contenido estático y los archivos necesarios a los usuarios a través de la red pública de Internet. Estos archivos estáticos incluyen descargas de productos (como Power BI Desktop, la puerta de enlace de datos local o aplicaciones de Power BI de varios ISV), archivos de configuración del explorador que se usan para iniciar y establecer cualquier conexión posterior con el servicio Power BI, así como la página de inicio de sesión segura inicial de Power BI.

  En función de la información proporcionada durante una conexión inicial al servicio Power BI, el explorador de un usuario se pone en contacto con la red CDN de Azure especificada (o para algunos archivos, WFE) para descargar la colección de archivos comunes especificados necesarios para habilitar la interacción del explorador con el servicio Power BI. A continuación, la página del explorador incluye el token de Microsoft Entra, la información de sesión, la ubicación del clúster de back-end asociado y la colección de archivos descargados del clúster de Azure CDN y WFE, durante la sesión del explorador del servicio Power BI.

En el caso de los objetos visuales de Power BI, ¿Microsoft realiza alguna evaluación de seguridad o privacidad del código visual personalizado antes de publicar elementos en la Galería?

• No. Es responsabilidad del cliente revisar y determinar si se debe confiar en el código visual personalizado. Todo el código visual personalizado se opera en un entorno de espacio aislado, de modo que cualquier código errante de un objeto visual personalizado no afecte negativamente al resto del servicio Power BI.

¿Hay otros objetos visuales de Power BI que envíen información fuera de la red del cliente?

• Sí. Los mapas de Bing y los objetos visuales de ESRI transmiten datos del servicio Power BI para los objetos visuales que utilizan esos servicios.

En el caso de las aplicaciones de plantilla, ¿Realiza Microsoft alguna evaluación de seguridad o privacidad de la aplicación de plantilla antes de publicar elementos en la Galería?

• No. El publicador de la aplicación es responsable del contenido mientras es responsabilidad del cliente revisar y determinar si confía en el publicador de la aplicación de plantilla.

¿Hay aplicaciones de plantilla que puedan enviar información fuera de la red del cliente?

• Sí. Es responsabilidad del cliente revisar la directiva de privacidad del publicador y determinar si instalar la aplicación de plantilla en el inquilino. El publicador es responsable de informar al cliente sobre el comportamiento y las funcionalidades de la aplicación.

¿Qué ocurre con la soberanía de datos? ¿Se pueden aprovisionar inquilinos en centros de datos ubicados en zonas geográficas específicas para asegurarse de que los datos no salen de los bordes de país o región?

• Algunos clientes de determinadas zonas geográficas tienen una opción para crear un inquilino en una nube nacional o regional, donde el almacenamiento y el procesamiento de datos se mantienen separados de todos los demás centros de datos. Las nubes nacionales o regionales tienen un tipo de seguridad ligeramente diferente, ya que un administrador de datos independiente opera el servicio Power BI en la nube nacional o regional en nombre de Microsoft.

  Como alternativa, los clientes también pueden configurar un inquilino en una región específica. Sin embargo, estos inquilinos no tienen un administrador de datos independiente de Microsoft. Los precios de las nubes nacionales o regionales son diferentes del servicio Power BI comercial disponible con carácter general. Para más información sobre la disponibilidad del servicio Power BI para nubes nacionales o regionales, consulte Nubes nacionales o regionales de Power BI.

¿Cómo trata Microsoft las conexiones para los clientes que tienen suscripciones de Power BI Premium? ¿Esas conexiones son diferentes de las establecidas para el servicio Power BI no Premium?

• Las conexiones establecidas para los clientes con suscripciones de Power BI Premium implementan un proceso de autorización de Microsoft Entra de negocio a negocio (B2B), mediante el identificador de Microsoft Entra para habilitar el control de acceso y la autorización. Power BI controla las conexiones de los suscriptores de Power BI Premium a los recursos de Power BI Premium igual que cualquier otro usuario de Microsoft Entra.

¿Cómo funciona la autenticación del lado servidor en WFE?

• La autenticación de la secuencia de usuario del lado del servicio ocurre tal y como se describe en los siguientes pasos, que se ilustran en la imagen posterior.

1. Un usuario inicia una conexión con el servicio Power BI desde un explorador, ya sea escribiendo la dirección de Power BI en la barra de direcciones o seleccionando Iniciar sesión en la página de marketing de Power BI (https://powerbi.microsoft.com). La conexión se establece mediante TLS 1.2 y HTTPS, y todas las comunicaciones posteriores entre el explorador y el servicio Power BI usan HTTPS.

2. Azure Traffic Manager comprueba el registro DNS del usuario para determinar el centro de datos más adecuado (normalmente más cercano) donde se implementa Power BI y responde al DNS con la dirección IP del clúster WFE al que se debe enviar el usuario.

3. A continuación, WFE redirige al usuario a la página de inicio de sesión de Microsoft Online Services.

4. Una vez autenticado el usuario, la página de inicio de sesión redirige al usuario al clúster WFE del servicio Power BI más cercano determinado previamente con un código de autenticación.

5. El clúster WFE verifica con Microsoft Entra ID para obtener un token de seguridad de Microsoft Entra utilizando el código de autenticación. Cuando Microsoft Entra ID devuelve la autenticación correcta del usuario y devuelve un token de seguridad de Microsoft Entra, el clúster WFE consulta el servicio global de Power BI, que mantiene una lista de inquilinos y sus ubicaciones de clúster de back-end de Power BI y determina qué clúster del servicio back-end de Power BI contiene el inquilino del usuario. A continuación, el clúster WFE devuelve una página de aplicación al explorador del usuario con la información de sesión, acceso y enrutamiento necesaria para su operación.

6. Ahora, cuando el navegador del cliente requiera datos de cliente, enviará solicitudes a la dirección del clúster de back-end con el token de acceso de Microsoft Entra en el encabezado de autorización. El clúster de back-end de Power BI lee el token de acceso de Microsoft Entra y valida la firma para asegurarse de que la identidad de la solicitud es válida. El token de acceso de Microsoft Entra tendrá una fecha de expiración establecida según las directivas de Microsoft Entra y, para mantener la sesión actual, el cliente de Power BI en el explorador del usuario realizará solicitudes periódicas para renovar el token de acceso antes de que expire.

Recursos adicionales

Para más información sobre Power BI, consulte los siguientes recursos.

• Introducción a Power BI Desktop
• Referencia de la API de Power BI
• Puerta de enlace de datos local
• Nubes nacionales o regionales de Power BI
• Fundamentos de seguridad de Microsoft Fabric
• Privacidad, seguridad y uso responsable de Copilot en Power BI