Notas del producto sobre la 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 paneles de Inteligencia empresarial de autoservicio, informes, modelos semánticos y visualizaciones. Con Power BI, se puede conectar a muchos orígenes de datos diferentes, combinar y dar forma a los datos de esas conexiones y, después, crear informes y paneles que se pueden compartir con otros usuarios.

Escritores: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Christian 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 Chattopadhiay, Yariv Maimon, Bogdan Crivat

Revisores técnicos: Christian Petculescu, Amir Netz, Azure Gundorov

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

Nota:

Para guardar o imprimir estas notas del producto, haga clic en Imprimir en el explorador y después en 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ácil y rápidamente paneles, informes, modelos semánticos y visualizaciones de Business Intelligence de autoservicio. Con Power BI, se puede conectar a muchos orígenes de datos diferentes, combinar y dar forma a los datos de esas conexiones y, después, 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, mayor demanda de clientes para servicios en línea y un mayor uso de tecnologías avanzadas en operaciones y toma de decisiones empresariales. Y todo esto está alimentado por la nube.

A medida que la transición a la nube ha cambiado de un truco a una inundación, y con el área expuesta nueva y expuesta que viene con ella, ¿más empresas preguntan cómo se protegen mis datos en la nube? y ¿Qué protección de un extremo a otro está disponible para evitar que mis datos confidenciales se filtren? Y para las plataformas de BI que a menudo controlan 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 de defensa en profundidad nativa de nube nativa y de varios niveles para sus datos de inteligencia empresarial.

Power BI se creó para proporcionar protección completa y hermética líder del sector para los datos. El producto ha ganado 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 fundación. Después de un período aproximado 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 profunda como el kernel de bios de la máquina en chip y amplía todo el camino hasta las experiencias del usuario final. Estas inversiones profundas continúan y, actualmente, más de 3500 ingenieros de Microsoft se dedican a crear y mejorar la pila de seguridad de Microsoft y abordar proactivamente el panorama de amenazas en constante cambio. Con miles de millones de equipos, billones de inicios de sesión y innumerables zettabytes de información encomendada a la protección de Microsoft, la empresa posee ahora la pila de seguridad más avanzada del sector tecnológico y se considera 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 ganó a Azure el derecho de servir y proteger los datos más confidenciales del mundo, y se integra con las herramientas de cumplimiento y protección de la información más avanzadas de Microsoft 365. Además, ofrece seguridad a través de medidas de seguridad de varias capas, lo que da lugar a una protección integral diseñada para abordar 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 del producto necesitaba abordar problemas de clientes desafiantes en varios frentes simultáneos:

• ¿Cómo se controla 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 controlar y proteger mis datos confidenciales? ¿Cómo asegurarse de que estos datos no se pueden filtrar fuera de la organización?
• Cómo auditar quién realiza las operaciones? ¿Cómo 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 de 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 del servicio, 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 conocer la ubicación del procesamiento de datos, consulte los términos Ubicación del procesamiento de datos en los Términos de Microsoft Online Services y en el Anexo de protección de datos. Para obtener información de cumplimiento, el Centro de confianza de Microsoft es el principal recurso para Power BI. El equipo de Power BI se esfuerza para brindar a sus clientes las innovaciones y la productividad más recientes. 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), prácticas de seguridad estrictas que admiten los requisitos de cumplimiento y garantía de 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 Procedimientos del 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. En la actualidad, Power BI se implementa en muchos centros de datos en todo el mundo: hay muchas implementaciones activas a disposición de los clientes en las regiones a las que sirven esos centros de datos y un número equivalente de implementaciones pasivas que actúan como copias de seguridad para cada implementación activa.

Clúster de front-end Web (WFE)

El clúster WFE proporciona al explorador del usuario el contenido inicial de la página HTML en la carga del sitio y punteros al contenido de la red CDN que se usa para representar el sitio en el explorador.

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 apropiado (generalmente el más cercano) con una implementación de Power BI. Para más información sobre este proceso, vea Métodos de enrutamiento del tráfico de Azure Traffic Manager.

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

Clúster back-end de Power BI (BE)

El clúster de back-end es la red troncal de todas las funcionalidades disponibles en Power BI. Consta de varios puntos de conexión de servicio consumidos por clientes Front End Web 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 implementa en nuevas regiones a medida que están disponibles. Una sola región de Azure hospeda uno o varios clústeres de back-end que permiten el escalado horizontal ilimitado de la 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 es con 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 lo usa el Front End Web 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 redimensionables optimizados para realizar tareas específicas, recursos con estado, como bases de datos SQL, cuentas de almacenamiento, buses de servicio, memorias caché y otros componentes de nube necesarios.

Los metadatos y los datos del inquilino se almacenan dentro de los límites del clúster, excepto la replicación de datos en un clúster back-end secundario en una región emparejada de Azure en la misma geografía de Azure. El clúster de 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.

Los microservicios que se ejecutan en diferentes máquinas dentro de la red virtual del clúster que no son accesibles desde fuera, excepto para dos componentes a los que se puede acceder desde la red pública de Internet:

• 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 registra para una suscripción de Power BI Premium, se crea la capacidad Premium mediante Azure Resource Manager.

Power BI Premium capacidades se hospedan en clústeres back-end que son independientes del back-end normal de Power BI( vea más arriba). 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, según el escenario de usuario. Power BI Premium clientes 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 de 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 son 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, administración y supervisión de 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, servicio de 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 Power BI Premium infraestructura se dirige primero a los nodos front-end: son los únicos nodos disponibles para las conexiones externas. El resto de los recursos están ocultos 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 de 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 principales plataformas móviles: 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 abren una sesión de 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 de autenticación basada en certificados (CBA) para Power BI Mobile en función de la plataforma de dispositivos móviles:

Compatibilidad con CBA	iOS	Android	Windows
Power BI (inicio de sesión en el servicio)	Compatible	Admitido	No compatible
SSRS ADFS local (conexión al servidor SSRS)	No compatible	Compatible	No admitido
Proxy de aplicación de SSRS	Addmitido	Admitido	No compatible

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 del 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 Android e iOS, 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 en un espacio aislado y el almacenamiento interno que solo es accesible para la aplicación. Para la aplicación de Windows, el usuario solo puede acceder a los datos (y al administrador del sistema).
• La geolocalización está 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.
• El usuario habilita o deshabilita explícitamente las notificaciones. 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 está disponible Power BI Mobile son compatibles con 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 primera entidad 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 usuarios 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 que se usan en Power BI. Esa 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 para los modelos de autenticación de usuarios de una organización (modelos de inicio de sesión), vea Elegir un modelo de inicio de sesión para Microsoft 365.

Secuencia de autenticación

La secuencia de autenticación del usuario para el servicio Power BI se produce como se describe en los pasos siguientes, que se ilustran en las imágenes siguientes.

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 seleccionandoIniciar 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 toda la comunicación posterior entre el explorador y el servicio Power BI usa HTTPS.

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

3. Después, WFE devuelve una página HTML al cliente del explorador, que contiene una referencia de biblioteca 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 de nuevo 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) desde 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 back-end de Power BI contiene el inquilino 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 dirección URL del clúster de back-end de Power BI, mediante el token de acceso en el encabezado Autorización para 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 excepcionales en los que se produce un error de autenticación del lado cliente debido a un error inesperado, el código intenta revertir al uso de la autenticación del lado servidor en WFE. Consulte la sección 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 por primera vez a los servicios de Power BI. 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 donde 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 la ubicación geográfica principal), excepto en los casos en los que las organizaciones usen implementaciones multigeográficas.

Varias zonas geográficas (multi-geo)

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

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

Vea Configuración de la compatibilidad con Multi-Geo para Power BI Premium para obtener más información sobre cómo crear y administrar implementaciones de Power BI que abarcan varias zonas geográficas de Azure.

Regiones y centros de datos

Los servicios de Power BI están disponibles en zonas geográficas de Azure específicas, 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 usan, consulte Centro de confianza de Microsoft . Los compromisos sobre la ubicación de los datos de los clientes en reposo se especifican en los Términos de procesamiento de datos de losTérminos de Microsoft Online Services.

Microsoft también proporciona centros de datos para entidades soberanas. Para obtener más información sobre la disponibilidad del servicio Power BI para nubes nacionales/regionales, vea nubes nacionales/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:

• Almacenamiento de Azure
• Instancias de Azure SQL Database

En la mayoría de los escenarios, Azure Storage se usa para conservar los datos de los 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. Toda la información almacenada en Azure SQL Database está totalmente cifrada mediante la tecnología Cifrado de datos transparente (TDE) de Azure SQL. Los datos de cliente almacenados en Azure Blob Storage se cifran mediante Azure Storage Encryption.

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
Import	Sí
DirectQuery	No
Live Connect	No
Compuesto	Si contiene un origen de datos de importación
Streaming	Si está configurado para conservarse

Independientemente del modo de modelo semántico utilizado, Power BI puede 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. Se rechazarán las solicitudes que intenten usar el servicio con TLS 1.1 o inferior.

Autenticación de usuarios en orígenes 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, seguridad de nivel de fila (RLS) o 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, se usa la autenticación de Microsoft Entra para el inicio de sesión único; para orígenes de datos locales, Kerberos, lenguaje de marcado de aserción de seguridad (SAML) y Microsoft Entra ID se admiten.

Si el origen de datos está Azure Analysis Services o analysis Services local, y RLS o OLS está configurado, el servicio Power BI aplicará esa seguridad de nivel de fila 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 de back-end que extraerán datos de orígenes de datos polimórficos, ejecutarán 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 de miembro, colaborador o administrador en un área de trabajo puede crear un flujo de datos. Los usuarios del rol de visor pueden ver los datos procesados por el flujo de datos, pero no pueden realizar cambios en su composición. Una vez creado un flujo de datos, cualquier miembro, colaborador o administrador del área de trabajo puede 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. La lógica de transformación se aplica mediante Power Query servicios mientras los datos están en curso. En el caso de los flujos de datos Premium, Power Query servicios 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 en la nube al servicio o a la puerta de enlace, el transporte usa la metodología de protección específica de la tecnología cliente, si procede. Cuando los datos se transfieren desde 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 el almacenamiento de credenciales estándar de todo el producto. Vea la sección Autenticación a orígenes de datos anterior. 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. Vea la sección 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 una entidad de seguridad de servicio Power BI a esa cuenta de almacenamiento para que pueda escribir los datos allí durante la actualización. En este caso, el propietario del recurso de almacenamiento es responsable de configurar el cifrado en la cuenta de almacenamiento de ADLS 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 redundantemente 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á limitado 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 se usa Power BI Desktop para acceder a los datos de un flujo de datos, primero debe autenticar al usuario mediante Microsoft Entra ID 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 canalización emite Office 365 eventos de auditoría. Algunos de estos eventos capturarán las 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 informe paginado (.rdl) se almacenan en Power BI y para publicar o representar un informe paginado que un usuario necesita autenticar y autorizar de la misma manera que se describe en la sección Autenticación en el servicio Power BI anterior.

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 representan pertenecen a áreas de trabajo asignadas 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 Azure Functions, el espacio aislado 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 el IFrame se realiza mediante el SDK de cliente de Power BI mediante mensajes POST.

En un escenario deinserció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 e identificadores. Todas las directivas y funcionalidades de Power BI descritas en este documento, como seguridad de nivel de fila (RLS) y seguridad de nivel de objeto (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 Autorización: 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 de usuario y entidad 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 descritas en este artículo: Por ejemplo, Etiquetas de servicio y 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 IA y enriquecimientos con IA. Las características de inteligencia artificial de nivel visual incluyen funcionalidades como influenciadores clave, esquema jerárquico, narración inteligente, detección de anomalías, objeto visual de R, objeto visual de Python, agrupación en clústeres, previsión, Q&A, 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 áreas de trabajo compartidas y Premium hoy en día. 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 ML personalizado (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 tener acceso 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 y 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 muestran ninguno de sus propios datos y solo proporcionan estas funciones o transformaciones. Durante la ejecución, estas características no realizan llamadas salientes a otros servicios para transmitir los datos del cliente. Echemos un vistazo a los escenarios Premium individualmente 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 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 un servicio de Experimentación de Azure Machine Learning para seleccionar un modelo adecuado y hiperparámetros para la iteración actual. En esta llamada saliente, solo se envían metadatos de experimento relevantes (por ejemplo, precisión, algoritmo 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 luego se guardan en el flujo de datos. Más adelante, los usuarios de Power BI pueden aplicar el modelo ML entrenado como una transformación para poner en marcha el modelo ML de forma 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. Para más detalles, vea las secciones siguientes.

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 la etiqueta de servicio (como PowerBI) en el campo de origen o destino (para las API) apropiado 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

La categoría Redes de Azure ofrece la característica Azure Private Link, que permite que Power BI Proporcione un acceso seguro mediante los puntos de conexión privados de Redes de Azure. Con Azure Private Link y los 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 lo tanto, los datos no atraviesan Internet.

Private Link garantiza que los usuarios de Power BI usen la red troncal privada de Microsoft cuando se dirijan 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 fluirá 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 desde la infraestructura que no está basada en Azure, como el acceso local, requeriría que los clientes dispusieran de ExpressRoute o una Red privada virtual (VPN) configurada.

Vea Vínculos privados para acceder a Power BI para obtener información adicional.

Conectividad de red virtual

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 desde 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, continúan siguiendo el proceso familiar de administración de orígenes de datos y seguridad, como 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 que está 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 PP VNet inyecta de forma segura en la subred un contenedor que ejecuta una puerta de enlace VNet. Este contenedor puede ahora conectarse a servicios de datos accesibles desde esta subred.

3. El servicio VNet de Microsoft Power Platform luego envía la consulta, los detalles del origen de datos y las credenciales a la puerta de enlace de datos de VNet.

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

5. 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 VNet y el servicio PP VNet envía de forma segura los datos del contenedor al servicio en la nube de Power BI.

Entidades de servicio

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

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

Microsoft Purview para Power BI

Microsoft Purview Information Protection

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 de 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 Excel, Word y aplicaciones de PowerPoint. Los archivos se pueden etiquetar fácilmente según su nivel de confidencialidad. Ademá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 las etiquetas de confidencialidad cuando se conectan a Power BI (versión preliminar), lo que permite mantener la clasificación de un extremo a otro y aplicar protección cuando se analizan modelos semánticos de Power BI en Excel.
• Las etiquetas de confidencialidad aplicadas a los informes y paneles de Power BI están visibles en las aplicaciones móviles de Power BI iOS y Android.
• Las etiquetas de confidencialidad se conservan cuando un informe de Power BI se inserta en Teams, SharePoint o 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 examen de administrador de Power BI pueden extraer la etiqueta de confidencialidad 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 generar informes ejecutivos.
• Las API de administración de Power BI permiten a los equipos centrales aplicar mediante programación etiquetas de confidencialidad al contenido de la servicio Power BI.
• Los equipos centrales pueden crear directivas de etiqueta 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 confidencialidad de bajada 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 de bajada conectado al modelo semántico o datamart.

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

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

Las directivas 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 regulaciones gubernamentales o del sector, como RGPD (reglamento general de protección de datos de la Unión Europea) o CCPA (ley de privacidad del consumidor de California) y asegurarse 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 confidencialidad
  • 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, vea Directivas de prevención de pérdida de datos para Power BI de Fabric.

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, denominado como líder 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 usuario 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 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 de los usuarios en Power BI. La característica de directiva de actividad de Defender for Cloud Apps puede aprovecharse para definir sus propias reglas personalizadas, para ayudarle a detectar comportamientos del usuario que se desvíen de la norma, e incluso posiblemente actuar sobre ellos automáticamente, si parecen demasiado peligrosos.
• 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 de usuario y aprendizaje automático listos para usar, para que esté preparado desde el principio para ejecutar la detección avanzada de amenazas en el entorno en la 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 que necesitan 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, vea Uso de los controles de Microsoft Defender for Cloud Apps en Power BI.

Vista previa de las características de seguridad

En esta sección se enumeran las características que están planeadas para publicarse hasta marzo de 2021. Dado que en este tema se enumeran las características que es posible que aún no se hayan publicado, es posible que las escalas de tiempo de entrega cambien y que la funcionalidad proyectada se publique más adelante que marzo de 2021 o que no se publique en absoluto. Para más información sobre las versiones preliminares, revise los Términos de los servicios en línea .

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics permite la integración entre Power BI y Azure Log Analytics. Esta integración incluye el motor analítico avanzado de Azure Log Analytics, el lenguaje de consulta interactivo y las construcciones de aprendizaje automático integradas.

Preguntas y respuestas sobre la seguridad de Power BI

Las preguntas siguientes son preguntas y respuestas comunes sobre seguridad para Power BI. Se han organizado en función de cuándo se agregaron a esta nota del producto, para facilitarle la búsqueda rápida de nuevas preguntas y respuestas cuando se actualice esta nota. Las preguntas más recientes se han agregado al final de esta lista.

¿Cómo se conectan los usuarios y obtienen acceso a los orígenes de datos mientras usan 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 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 los informes y el panel 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.

  En el caso de los informes conectados con 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 está conectado 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. Al usar 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 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, se usa la autenticación de Microsoft Entra para el inicio de sesión único; para orígenes de datos locales, Kerberos, SAML y Microsoft Entra ID se admiten.

  Al conectarse con Kerberos, el UPN del usuario se pasa a la puerta de enlace y se usa la delegación restringida de Kerberos, el usuario se suplanta y se conecta a los orígenes de datos respectivos. SAML también es compatible con la fuente de datos de la puerta de enlace para SAP HANA. Puede encontrar más información 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 Analysis Services local y se ha configurado la seguridad de nivel de fila (RLS) y/o la seguridad de nivel de objeto (OLS), el servicio Power BI aplicará esa seguridad de nivel de fila, y los usuarios que no tengan credenciales suficientes para acceder a los datos subyacentes (que podría ser una consulta utilizada en un cuadro de mando, informe u otro artefacto de datos) no verán los datos para los que el usuario no tenga privilegios suficientes.

  La seguridad a nivel de fila con Power BI se puede usar para restringir el acceso a los datos a determinados usuarios. Los filtros restringen el acceso a los datos en el nivel de fila y se pueden definir en roles.

  La seguridad de nivel de objeto (OLS) se puede usar para proteger las tablas o columnas confidenciales. Sin embargo, a diferencia de la seguridad de nivel de fila, la seguridad de nivel de objeto 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.

  La seguridad de nivel de objeto, junto con la seguridad de nivel de fila, 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 los datos se desplazan por la red solo cuando se haya establecido esa conexión.

En Power BI, ¿cómo se almacena en caché un modelo, panel o informe? ¿Es seguro?

• Cuando se accede a un origen de datos, el servicio Power BI sigue el proceso descrito en la sección Almacenamiento y movimiento de datos anteriormente en este documento.

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

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

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

• Para los orígenes de datos habilitados que no admiten la seguridad de nivel de rol (RLS), si un panel, informe o modelo de datos se comparte con otros usuarios a través de Power BI, los datos estarán disponibles para verlos e interactuar con ellos para los usuarios con los que se hayan compartido. Power BI no vuelve a autenticar a los usuarios en el origen inicial de los datos; una vez que los datos se cargan en Power BI, el usuario que se ha autenticado en el origen de datos es responsable de administrar qué 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 se almacenan en caché en Power BI los datos de paneles. 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 de autenticación, el usuario verá un error.

  Para más información vea la sección Autenticación en orígenes de datos anteriormente en este documento.

Nuestros usuarios se conectan continuamente a los mismos orígenes de datos, y algunos requieren credenciales diferentes de sus credenciales de dominio. ¿Cómo pueden evitar tener que escribir estas credenciales cada vez que realicen una conexión de datos?

• Power BI ofrece Power BI Personal Gateway, una característica que permite a los usuarios crear credenciales para varios orígenes de datos diferentes y luego usarlas de forma automática cuando accedan a cada uno de esos orígenes de datos. Para más información, vea Power BI Personal Gateway.

¿Qué puertos se usan en la puerta de enlace de datos local y en la puerta de enlace de datos (modo personal)? ¿Hay algún nombre de dominio que se deba permitir con fines de conectividad?

• La respuesta detallada a esta pregunta está disponible en el siguiente vínculo: Puertos de puerta de enlace

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

• Durante la instalación y configuración de puertas de enlace, el administrador escribe una clave de recuperación de puerta de enlace. 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 que se encuentra en el equipo local. Ese archivo también se cifra. El contenido del archivo solo lo puede descifrar ese equipo Windows concreto, y solo mediante esa cuenta de servicio de puerta de enlace concreta.

  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 la servicio Power BI. Con este proceso, el servicio Power BI nunca tiene acceso a los datos sin cifrar.

¿Qué protocolos de comunicación usa la puerta de enlace de datos local y cómo se protegen?

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

  • AMQP 1.0 - TCP + TLS: Este protocolo requiere que se abran los puertos 443, 5671-5672 y 9350-9354 para la comunicación saliente. Es el protocolo preferido, porque tiene una menor sobrecarga de comunicación.

  • HTTPS: WebSockets a través de HTTPS + TLS: este protocolo usa solo el puerto 443. WebSocket se inicia con un único mensaje HTTP CONNECT. Una vez que se ha establecido el canal, la comunicación es esencialmente TCP+TLS. Puede forzar a la puerta de enlace para que use este protocolo si modifica una configuración, como se describe en el artículo Puerta de enlace de datos local.

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

• Como se ha mencionado antes, Power BI usa Azure Content Delivery Network (CDN) para distribuir de forma eficaz el contenido estático y los archivos necesarios a los usuarios en función de la configuración regional geográfica. Para entrar en más detalle, el servicio Power BI usa varias CDN para distribuir de forma eficaz el contenido estático y los archivos necesarios a los usuarios a través de la red Internet pública. Estos archivos estáticos incluyen descargas de productos (como Power BI Desktop, la puerta de enlace de datos local o las aplicaciones de Power BI de varios proveedores de servicios independientes), archivos de configuración del explorador que se usan para iniciar y establecer cualquier conexión posterior con el servicio de Power BI, así como la página inicial de inicio de sesión seguro de Power BI.

  En función de la información proporcionada durante la conexión inicial al servicio Power BI, el explorador del usuario contacta con la instancia de Azure CDN especificada (o para algunos archivos, el WFE) para descargar la colección de archivos comunes especificados que se necesitan para habilitar la interacción del explorador con el servicio Power BI. Luego, la página del explorador incluye el token de Microsoft Entra, la información de la sesión, la ubicación del clúster de back-end asociado y la colección de archivos descargados desde Azure CDN y el clúster WFE, para la duración de la sesión de explorador del servicio Power BI.

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

• No. Es responsabilidad del cliente revisar y determinar si se debe confiar en el código del objeto visual personalizado. El código de todos los objetos visuales personalizados funciona en un entorno de espacio aislado, por lo que cualquier código incorrecto en un objeto visual personalizado no afecta de forma negativa al resto del servicio Power BI.

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

• Sí. Los objetos visuales Bing Maps y ESRI transmiten datos fuera del servicio Power BI para los objetos visuales que usan esos servicios.

Para los objetos visuales personalizados, ¿realiza Microsoft alguna evaluación de seguridad o privacidad del código del objeto visual personalizado 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 confiar 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é sucede con la soberanía de los datos? ¿Se pueden aprovisionar inquilinos en centros de datos situados en zonas geográficas específicas, para garantizar que los datos no salgan de las fronteras del país o la región?

• Algunos clientes de determinadas zonas geográficas tienen la opción de crear un inquilino en una nube nacional o regional, donde el almacenamiento y procesamiento de datos se mantiene separado de todos los demás centros de datos. LLas nubes nacionales o regionales tienen un tipo de seguridad ligeramente diferente, ya que un administrador de datos independiente administra el servicio Power BI de 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 de los del servicio comercial Power BI disponible en general. Para obtener más información sobre la disponibilidad del servicio Power BI para nubes nacionales/regionales, vea nubes nacionales/regionales de Power BI

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

• Las conexiones que se establecen para los clientes con suscripciones de Power BI Premium implementan un proceso de autorización de negocio a negocio (B2B) de Microsoft Entra, mediante Microsoft Entra ID 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 como haría con cualquier otro usuario de Microsoft Entra.

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

• La autenticación del lado del servicio de secuencia de autenticación de usuario 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 seleccionandoIniciar 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 toda la comunicación posterior entre el explorador y el servicio Power BI usa HTTPS.

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

3. Luego, 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 a la servicio Power BI clúster WFE más cercano determinada anteriormente con un código de autenticación.

5. El clúster WFE comprueba con Microsoft Entra ID para obtener un token de seguridad de Microsoft Entra mediante 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 de servicio de 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 explorador del cliente requiera datos de cliente, enviará solicitudes a la dirección del clúster back-end con el token de acceso de Microsoft Entra en el encabezado 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 obtener más información sobre Power BI, vea los recursos siguientes.

• Introducción a Power BI Desktop
• Información general sobre la API REST de Power BI
• Referencia de la API de Power BI
• Puerta de enlace de datos local
• Nubes nacionales o regionales de Power BI
• Power BI Premium
• Introducción al inicio de sesión único (SSO) para puertas de enlace de Power BI