Notas del producto sobre la seguridad de Power BI

Resumen: Power BI es un 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, conjuntos de datos 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 Chattopadhyay, Yariv Maimon, Bogdan Crivat

Revisores técnicos: Christian 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:

Para guardar o imprimir este documento técnico, seleccione Imprimir en el explorador y, a continuación, seleccione 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 permite crear de forma rápida y sencilla paneles de inteligencia empresarial con características de autoservicio, informes, conjuntos de datos 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.

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 servicios en línea y un mayor uso de tecnologías avanzadas en las operaciones y la toma de decisiones empresariales. Y todo esto funciona con la nube.

A medida que la transición a la nube ha cambiado de un truco a una inundación, y con el nuevo área expuesta expuesta que viene con ella, más y más empresas preguntan ¿Qué seguridad tienen mis datos en la nube? y ¿Qué protección de un extremo a otro está disponible para evitar que se filtren mis datos confidenciales? 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.

Los fundamentos de décadas del modelo de seguridad de BI : seguridad de nivel de objeto y de nivel de fila, aunque aún son importantes, ya no bastan 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 y nativa de la nube para sus datos de inteligencia empresarial.

Power BI se creó para proporcionar protección hermética y completa líder del sector para los datos. 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 fundación. Después de un período aproximado en los primeros años de 2000, Microsoft realizó inversiones masivas para abordar sus vulnerabilidades de seguridad, y en las décadas siguientes creó una pila de seguridad muy fuerte que va tan profundamente como el kernel del bios del equipo en chip y amplía todo el camino hasta las experiencias del usuario final. Estas inversiones profundas continúan y hoy en día 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 cada vez más cambiante. 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 considera ampliamente como líder global en la lucha contra actores malintencionados.

Power BI se basa en esta base muy sólida. Usa la misma pila de seguridad que ganó el derecho de Azure a 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 de esto, ofrece seguridad a través de medidas de seguridad multicapa, 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 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 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 lleva a cabo 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 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 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 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 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. El SDL ayuda a los desarrolladores a crear software más seguro al reducir el número y la gravedad de las vulnerabilidades en el software, a la vez que reduce el costo de desarrollo. Obtenga más información en Prácticas 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.

WFE y back-end

Clúster 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 administra el proceso inicial de conexión y autenticación para Power BI, mediante Azure Active Directory (Azure AD) para autenticar clientes y proporcionar tokens para las conexiones de cliente posteriores al servicio back-end de Power BI.

El clúster WEF

Un clúster WFE consta de un sitio web de ASP.NET que se ejecuta en el entorno de Azure App Service. 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.

El clúster WFE asignado al usuario administra la secuencia de inicio de sesión y autenticación (descrita más adelante en este artículo) y obtiene un token de acceso de Azure AD una vez que la autenticación se realiza correctamente. El componente ASP.NET dentro del clúster WFE analiza el token para determinar a qué organización pertenece el usuario y, a continuación, consulta el servicio global de Power BI. WFE especifica el explorador en el que el clúster de back-end alberga el inquilino de la organización. Una vez autenticado un usuario, las interacciones de cliente posteriores para los datos del cliente se producen directamente con el clúster back-end o Premium, sin que WFE sea un intermediario para esas solicitudes.

Los recursos estáticos como *.js, *.css y archivos de imagen se almacenan principalmente en Azure Content Delivery Network (CDN) 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á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 de back-end de Power BI (BE)

El clúster de 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 front-end web y api, así como servicios de trabajo en segundo plano, bases de datos, cachés 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 un 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 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 redimensionable optimizados para realizar tareas específicas, recursos con estado, como bases de datos SQL, cuentas de almacenamiento, buses de servicio, cachés y otros componentes de nube necesarios.

Los metadatos y los datos del inquilino se almacenan dentro de los límites del clúster, excepto para la replicación de datos en un clúster 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.

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

El clúster de back-end

infraestructura de Power BI Premium

Power BI Premium ofrece un servicio para los suscriptores que requieren características premium de Power BI, como flujos de datos, informes paginados, inteligencia artificial, 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.

Power BI Premium capacidades se hospedan en clústeres back-end que son independientes del back-end normal de Power BI( consulte 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:

Power BI Premium

La conexión a la infraestructura de Power BI Premium se puede realizar de varias maneras, en función del 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 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 la 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 conjuntos de escalado de máquinas virtuales y Azure Service Fabric. Los conjuntos de escalado de máquinas virtuales y Service Fabric permiten un aumento rápido e indolido 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, 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 Azure AD 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 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 de dispositivos, 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 con detalle anteriormente en esta notas del 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:

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

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

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

  • Azure AD y los tokens de actualización se almacenan en un mecanismo seguro en el dispositivo mediante medidas de seguridad estándar del sector.
  • Los datos y la configuración (pares clave-valor para la configuración del 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 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 en un 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).
  • El usuario habilita o deshabilita explícitamente la geolocalización. 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 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. Obtenga 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 1st (como Microsoft Authenticator) y se administran mediante el SDK de la Biblioteca de autenticación de Azure Active Directory (ADAL).

Power BI Mobile datos almacenados en caché se elimina cuando se quita 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 un 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 le 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. 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 Azure Active Directory. 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, escribiendo la dirección de Power BI en la barra de direcciones o seleccionando Iniciar sesión en la página de aterrizaje 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 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 de WFE más servicio Power BI cercano determinado anteriormente con un código de autenticación.

  5. El clúster de WFE comprueba con el servicio Azure AD para obtener un token de seguridad de Azure AD mediante el código de autenticación. Cuando Azure AD devuelve la autenticación correcta del usuario y devuelve un token de seguridad de Azure AD, el clúster WFE consulta el servicio global de Power BI, que mantiene una lista de inquilinos y sus ubicaciones de clúster back-end de Power BI y determina qué clúster de 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 explorador del cliente requiera datos de cliente, enviará solicitudes a la dirección del clúster de back-end con el token de acceso de Azure AD en el encabezado Autorización. El clúster de back-end de Power BI lee el token de acceso de Azure AD y valida la firma para asegurarse de que la identidad de la solicitud es válida. El token de acceso de Azure AD tiene una duración predeterminada de 1 hora y, para mantener la sesión actual, el explorador del usuario realizará solicitudes periódicas para renovar el token de acceso antes de que expire.

Secuencia de autenticación

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 Azure AD se suscribe por primera vez a los servicios de Power BI. Un inquilino de Azure AD aloja las identidades de usuario y aplicación, los grupos y otra información relevante que pertenecen a una organización y a su seguridad.

La asignación de una ubicación geográfica de Azure para el almacenamiento de datos de inquilino se realiza mediante la asignación del país o región seleccionado como parte de la configuración del inquilino de Azure AD a la ubicación geográfica 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 geográfica 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 puede tener su sede central en la Estados Unidos, pero también puede hacer negocios en otras áreas 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 cachés 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 sigan ocurriendo en la ubicación geográfica principal del inquilino, incluso para áreas de trabajo hospedadas en una capacidad Premium multigeográfica.

Consulte Configuración de la compatibilidad multigeográfica 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 el Centro de confianza de Microsoft. Los compromisos relativos a la ubicación de los datos del 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 obtener más información sobre la disponibilidad del servicio Power BI para nubes nacionales, vea Nubes nacionales de Power BI.

Control 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 los clientes.

Datos en reposo

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

  • Azure Storage
  • 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 guardados por Power BI se cifran de forma predeterminada mediante claves administradas por Microsoft. Los datos del cliente almacenados en Azure SQL Bases de datos se cifran completamente 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 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 conjunto de datos. 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. Consulte Traiga sus propias claves de cifrado para Power BI para más información.

Los conjuntos de datos de Power BI permiten una variedad de 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 conjunto de datos (Tipo) Datos persistentes en Power BI
Importar
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 conjunto de datos utilizado, Power BI puede almacenar temporalmente en caché los datos recuperados para optimizar el rendimiento de la carga de consultas y informes.

Datos en procesamiento

Los datos se procesan cuando uno o varios usuarios los 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 todas las solicitudes que intenten usar el servicio con TLS 1.1 o inferior.

Autenticación 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 conjunto de datos 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 conjunto de datos 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 está conectado 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 Azure AD se usa para el inicio de sesión único; para orígenes de datos locales, Kerberos, lenguaje de marcado de aserción de seguridad (SAML) y Azure AD se admiten.

Si el origen de datos está Azure Analysis Services o Analysis Services local, y se configura RLS o 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ían ser una consulta usada en un panel, informe u otro artefacto de datos) no verán los datos que no tienen privilegios suficientes. Para.

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 la lógica de transformación en los datos y, a continuación, la 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, los servicios 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 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 de 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 procesamiento 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 para todo el producto. Consulte 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án en reposo. Consulte 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, a una entidad de seguridad servicio Power BI se le concede acceso 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 con redundancia en una base de datos SQL que está disponible para DirectQuery a través del acceso por parte del 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. Todo el uso secundario o indirecto de DirectQuery se controla mediante los mismos controles de acceso descritos anteriormente. 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 Azure AD 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. A veces se denominan perfectos hasta el último detalle, porque se puede controlar con exactitud el diseño de las páginas del informe.

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 la 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 la sección Autenticación en el servicio Power BI anterior.

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

Para Premium Gen1, existe un único espacio aislado por cada una de las capacidades del inquilino y las áreas de trabajo asignadas a la capacidad comparten.

Informes paginados Gen 1

Para Premium Gen2, se crea un espacio aislado efímero individual y exclusivo para cada una de las representaciones de un informe, lo que proporciona un mayor nivel de aislamiento entre los usuarios.

Informes paginados Gen 2

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 los 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 de inserción para su organización , los usuarios de Azure AD 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 los clientes , los ISV suelen ser propietarios de inquilinos de Power BI y artefactos de Power BI (paneles, informes, conjuntos de datos, etc.). 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 o 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 tal como lo especificó 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 la entidad de servicio de Azure AD.

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: por ejemplo, etiquetas de servicio y vínculos privados.

Características de inteligencia artificial

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 Key-Influencers, Descomposition-Tree, Smart-Narrative, Anomaly-Detection, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights etc. Las funcionalidades de enriquecimiento con IA incluyen funcionalidades como AutoML, AzureML, 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 en la actualidad. 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 flujo de datos o conjunto 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 los usuarios de Power BI pueden usar en sus canalizaciones de integración de datos usadas por un conjunto de datos o un flujo de datos de Power BI. Tenga en cuenta que también se puede acceder a estas funciones desde entornos actuales de creación de flujos de datos o conjuntos de datos en el servicio Power BI y Power BI Desktop. Estas funciones o transformaciones de inteligencia artificial siempre se ejecutan en un área de trabajo o capacidad Premium. Estas funciones se exponen en Power BI como un origen de datos que requiere un token de Azure AD 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 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 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 un servicio AzureML de experimentación para seleccionar un modelo adecuado y hiperparámetres 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, 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 poner en marcha el modelo de 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 en flujos de datos y conjuntos de datos de Power BI. Al crear un conjunto 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 Azure AD.

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 la 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.

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 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 privada de Microsoft al ir a los recursos de la servicio Power BI.

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

  • Private Link garantiza que el tráfico fluya por 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 red privada virtual (VPN) configurada.

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

Conectividad de red virtual (versión preliminar: próximamente)

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) eliminarán 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, seguirán 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 de red virtual de Power Platform (VNet PP).

  2. Después, 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 dentro de esta subred.

  3. Después, 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 los orígenes 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.

Esta característica estará disponible en versión preliminar pública próximamente.

Entidades de servicio

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

Consulte Automatización de tareas de conjunto de datos y áreas de trabajo Premium con entidades de servicio para más información.

Microsoft Purview para Power BI

Microsoft Purview Information Protection

Power BI está profundamente integrado con microsoft Perview Information Protection (anteriormente, Information Protection de cumplimiento de Microsoft 365). Microsoft Purview Information Protection permite a las organizaciones tener una única solución integrada para la clasificación, el etiquetado, la auditoría y el 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 salen de Power BI.
  • Es fácil clasificar y proteger archivos .pbix en Power BI Desktop, al igual que 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 empresariales, 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 los conjuntos de datos 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 iOS y Android de Power BI.
  • Las etiquetas de confidencialidad se conservan cuando un informe de Power BI se inserta 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 nuevo contenido en el servicio Power BI garantiza que las etiquetas aplicadas a conjuntos de datos o datamarts del servicio Power BI se aplicarán al nuevo contenido creado sobre esos conjuntos de datos 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 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 una etiqueta de confidencialidad se aplica a todo el contenido de Power BI nuevo o cambiado.
  • El etiquetado automático de confidencialidad de bajada en el servicio Power BI garantiza que, cuando se aplica o cambia una etiqueta en un conjunto de datos o datamart, la etiqueta se aplicará o cambiará automáticamente en todo el contenido de nivel inferior conectado al conjunto de datos o datamart.

Para 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 (versión preliminar)

Las directivas DLP de Microsoft Purview pueden ayudar a las organizaciones a reducir el riesgo de pérdida de datos empresariales confidenciales de Power BI. Las directivas DLP pueden ayudarles 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 (la 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 conjuntos de datos 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 análisis de contenido de Microsoft Purview.
  • Al encontrar un conjunto de datos identificado como confidencial, puede ver una sugerencia de directiva personalizada que le ayude a comprender lo que debe hacer.
  • Si es propietario del conjunto de datos, puede invalidar una directiva e impedir que el conjunto de datos se identifique como "confidencial" si tiene un motivo válido para hacerlo.
  • Si es propietario del conjunto de datos, 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 Power BI.

Microsoft Defender for Cloud Apps para Power BI

Microsoft Defender for Cloud Apps es uno de los agentes de seguridad de acceso a la nube líderes 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 arriesgadas, 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, 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 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 de usuario y aprendizaje automático listos para usar para que esté listo desde el principio para ejecutar la detección avanzada de amenazas en el 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 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.

Consulte Uso de controles de Microsoft Defender for Cloud Apps en Power BI para obtener más información.

Vista previa de las características de seguridad

En este tema se enumeran las características que se planean publicar 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 obtener más información, sobre las versiones preliminares, revise los Términos de Online Services.

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 de seguridad de Power BI

Las preguntas siguientes son preguntas y respuestas comunes sobre seguridad para Power BI. Estos se organizan en función de cuándo se agregaron a este documento técnico, para facilitar su capacidad de encontrar rápidamente nuevas preguntas y respuestas cuando se actualice este documento. 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 la puerta de enlace Administración. Al configurar un conjunto de datos, 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 conjunto de datos en 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, la credencial del propietario del conjunto de datos se usa para conectarse con el origen de datos.

    En el caso de los informes que están 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. 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 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 Azure AD para el inicio de sesión único; para orígenes de datos locales, se admiten Kerberos, SAML y Azure AD.

    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 se admite en el origen de datos gateway for 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 está configurado Azure Analysis Services o de Analysis Services local y seguridad de nivel de fila (RLS) o 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ían ser una consulta usada en un panel, informe u otro artefacto de datos) no verán datos para los que el usuario no tiene privilegios suficientes.

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

    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 una mayor seguridad de nivel empresarial en informes y conjuntos de datos, 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 Autenticación a orígenes 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 los datos del panel se almacenan en caché en Power BI. Cada vez que se ve o se accede a un informe o conjunto de datos en Power BI en el que se usan datos procedentes 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 modelo de datos o informe para ese usuario. Si se produce un error de autenticación, el usuario verá un error.

    Para obtener más información, consulte 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?

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 los puertos 443, 5671-5672 y 9350-9354 estén abiertos 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 que la puerta de enlace use este protocolo modificando una configuración descrita en el artículo puerta de enlace 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 aplicaciones de Power BI de distintos proveedores de servicios independientes), archivos de configuración del explorador que se usan para iniciar y establecer las sucesivas conexiones con Power BI, así como la página de inicio de sesión seguro inicial 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. A continuación, la página del explorador incluye el token de Azure AD, la información de sesión, la ubicación del clúster back-end asociado y la colección de archivos descargados del clúster de Azure CDN y WFE, mientras dure la sesión del explorador 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 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.

En el caso de las aplicaciones de plantilla, ¿Microsoft realiza 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 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 se debe 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 asegurarse de que los datos no salgan de las fronteras del país?

  • Algunos clientes de zonas geográficas concretas tienen la opción de crear un inquilino en una nube nacional, donde el almacenamiento y el procesamiento de datos son independientes de otros centros de datos. Las nubes nacionales tienen un tipo de seguridad ligeramente diferente, puesto que un administrador de datos independiente controla el servicio Power BI de la nube nacional 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 son diferentes del servicio Power BI comercial disponible con carácter general. Para obtener más información sobre la disponibilidad del servicio Power BI para nubes nacionales, vea Nubes nacionales 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 establecidas para los clientes con suscripciones de Power BI Premium implementan un proceso de autorización empresarial a negocio (B2B) de Azure, mediante Azure AD 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 Azure AD.

Recursos adicionales

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