Power BI de seguridad

Resumen: Power BI es una oferta de servicio de software en línea (SaaS o software como servicio) de Microsoft que le permite crear fácilmente y rápidamente paneles, informes, conjuntos de datos 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.

Escritores: Yhakhak Kesselman,Oid Osborne, Matt Neely, Chris Bencic, SrinivasanNuskere, Asínculo Petculescu, Adi Regev, Naveen Siomisiónj, Ben Glarín, Evgeny Tshiorny, Arthi Ramasubrarevn Iyer, SidDjadevan,DjReván, Ori Eduar,DjDj, Idan Sheinberg, Ron Vhad,Reviv Hadrev, Paul Inbar, Igor Uzhviev, Michael Roth, Asín Tarquino, Gennady Pats, Orion Lee, Yury Beibansky, Maya Shenhav, Romit Chattopadariy, Yariv Maimon, Cri crivat de Handán

Revisores técnicos: Chris Petculescu, Aúl netz, Sergei Gundorov

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

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 observamos un aumento masivo del trabajo remoto, una mayor demanda de clientes de servicios en línea y un mayor uso de tecnologías avanzadas en operaciones y toma de decisiones empresariales. Y todo esto funciona con la tecnología de la nube.

A medida que la transición a la nube ha cambiado de una forma complicada a una crecida, y con el nuevo área expuesta expuesta que incluye, cada vez más empresas preguntan ¿Qué tan seguros son 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 antiguos del modelo de seguridad de BI (seguridad de nivel de objeto y de fila), aunque siguen siendo importantes, claramente 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 la nube y de varios niveles para sus business intelligence datos.

Power BI se creó para proporcionar protección completa y hermética líder del sector para los datos. El producto ha obtenido las clasificaciones de seguridad más altas disponibles en el sector y, actualmente, muchos organismos de seguridad nacionales, instituciones financieras y proveedores de asistencia sanitaria le confían su información más confidencial.

Todo comienza con la base. Después de un período aproximado a principios de la década de 2000, Microsoft realizó inversiones masivas para abordar sus vulnerabilidades de seguridad y, en las siguientes décadas, creó una pila de seguridad muy sólida que va tan profunda como el kernel bios en chip de la máquina y se extiende 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 a abordar de forma proactiva el panorama de amenazas en constante cambio. Con miles de millones de equipos, billones de inicios de sesión e incontables zbytes de información que confían en la protección de Microsoft, la empresa posee ahora la pila de seguridad más avanzada del sector tecnológico y se ve ampliamente como líder global en la defensa contra actores malintencionados.

Power BI se basa en esta base muy sólida. Usa la misma pila de seguridad que ha ganado a Azure el derecho 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, ofrece seguridad a través de medidas de seguridad de varias capas, lo que da lugar a una protección de un extremo a otro 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 los desafíos de los clientes en varios frentes simultáneos:

• ¿Cómo se controla quién se puede conectar, desde dónde se conecta y cómo se conecta? ¿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 introducción a la arquitectura del servicio y explica cómo funcionan los flujos principales en el 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 datos a través del servicio. La última sección describe 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 los términos Ubicación del procesamiento de datos en microsoft Términos de los Servicios en Línea 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 Power BI sigue el ciclo de vida de desarrollo de seguridad (SDL), prácticas de seguridad estrictas que admiten los requisitos de cumplimiento y control de seguridad. El SDL ayuda a los desarrolladores a crear software más seguro, ya que reduce el número y la gravedad de las vulnerabilidades del software, a la vez que reduce el costo de desarrollo. Obtenga más información en Ciclo de vida de desarrollo de seguridad de Microsoft Practices.

Power BI arquitectura

El Power BI se basa en Azure, la plataforma de informática en la nube deMicrosoft . 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 de la página HTML inicial en la carga del sitio y administra el proceso de autenticación y conexión inicial para Power BI, mediante Azure Active Directory (Azure AD) para autenticar clientes y proporcionar tokens para las posteriores conexiones de cliente al servicio back-end de Power BI.

Un clúster WFE consta de un sitio web ASP.NET que se ejecuta en el Azure App Service Environment. Cuando los usuarios intentan conectarse al servicio Power BI, el servicio DNS del cliente puede comunicarse con el Azure Traffic Manager para encontrar el centro de datos más adecuado (normalmente más cercano) con una implementación Power BI cliente. Para obtener más información sobre este proceso, vea Método de enrutamiento del tráfico derendimiento 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 Azure AD una vez que la autenticación se realiza correctamente. El 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 Power BI global. WfE especifica en el explorador qué clúster de back-end aloja 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 back-end o el clúster Premium, sin que WFE sea un intermediario para esas solicitudes.

Los recursos estáticos como *.js, *.css y los 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 Administración soberana son una excepción a esta regla y, por motivos de cumplimiento, omitirán el CDN y, en su lugar, usarán un clúster WFE de una región compatible para hospedar contenido estático.

Power BI de back-end (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 de API y front-end web, 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 el escalado horizontal ilimitado del servicio Power BI una vez que se agotan 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 la información del clúster principal de un usuario autenticado y la 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 de tamaño ajustables para realizar tareas específicas, recursos con estado como bases de datos de SQL, cuentas de almacenamiento, bus 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 la replicación de datos en un clúster de back-end secundario en una región de Azure emparejada en la misma ubicación geográfica de Azure. El clúster de back-end secundario actúa como clúster de conmutación por error en caso de interrupción regional y es pasivo en cualquier otro momento.

La funcionalidad de back-end se proporciona mediante microservicios que se ejecutan en diferentes máquinas dentro de la red virtual del clúster que no son accesibles desde el exterior, 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

Power BI Premium infraestructura

Power BI Premium ofrece un servicio para los suscriptores que requieren características Power BI premium, como flujos de datos, informes paginados, inteligencia artificial, etc. Cuando un cliente se suscribe a una suscripción Power BI Premium, la Premium se crea a través del Azure Resource Manager.

Power BI Premium capacidades se hospedan en clústeres de back-end que son independientes del back-end de Power BI normal ( consulte más arriba). Esto proporciona un mejor aislamiento, asignación de recursos, compatibilidad, aislamiento de seguridad y escalabilidad de Premium oferta.

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

La conexión a la 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 Power BI Premium en una región de Azure consta de varios Power BI Premium clústeres (el mínimo es uno). La mayoría de los Premium se encapsulan dentro de un clúster (por ejemplo, proceso) y hay algunos recursos regionales comunes (por ejemplo, almacenamiento de metadatos). Premium infraestructura 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 los recursos de proceso administrados por Virtual Machine Scale Sets (VMSS) y Azure Service Fabric. VMSS y Service Fabric permiten un aumento rápido y sin problemas de los nodos de proceso a medida que crece el uso y orquesta la implementación, administración y supervisión de Power BI Premium servicios y aplicaciones.

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. Los secretos, las claves y los certificados necesarios para Power BI Premium administran Azure Key Vault exclusivamente. Cualquier autenticación se realiza a través de la integración Azure AD exclusivamente.

Cualquier solicitud que llegue a Power BI Premium infraestructura va 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 la reenvía a los recursos adecuados (por ejemplo, los nodos back-end).

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

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 Power BI Mobile aplicaciones se divide 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 que usan los exploradores, que se describen con detalle anteriormente en estas white paper. Las aplicaciones móviles 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 con la autenticación basada en certificados (CBA) para Power BI Mobile, en función de la plataforma de dispositivos móviles:

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ía ningún dato de cliente con telemetría.

La 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 del dispositivo y el sistema operativo puede cifrarlo. En iOS, esto se hace automáticamente cuando el usuario establece un código de acceso. En Android, se puede configurar en la configuración. En Windows se realiza mediante BitLocker.
• En el caso de las aplicaciones Android e iOS, los datos y la configuración (pares clave-valor para la configuración del usuario) se almacenan en caché en el almacenamiento del dispositivo en un espacio aislado y un almacenamiento interno al que solo puede acceder la aplicación. Para la Windows, el usuario (y el administrador del sistema) solo pueden acceder a los datos.
• El usuario habilita o deshabilita explícitamente la geolocalización. Si está habilitada, 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á habilitada, Android e iOS no admiten los requisitos de residencia de datos geográficos para las notificaciones.

El cifrado de datos se puede mejorar mediante la aplicación de cifrado de nivel de archivo mediante Microsoft Intune, un servicio de software que proporciona administración de dispositivos móviles y aplicaciones. Las tres plataformas para las que Power BI Mobile 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 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 de primera entidad (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 eliminan 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 del 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 acceso a otras carpetas o archivos de aplicación en el dispositivo.

Las 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. Obtenga más información sobre la identificación adicional.

Autenticación en el servicio Power BI web

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. En esta secuencia se describe el proceso de autenticación de usuario en Power BI, que sigue el flujo de concesión de código de autenticación del Azure Active Directory del usuario. 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,vea 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 al servicio Power BI desde un explorador, ya sea escribiendo la dirección 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. El 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 al usuario.

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

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

5. El clúster WFE comprueba con el servicio Azure AD para obtener un token Azure AD seguridad 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 de back-Power BI end de Power BI y determina qué clúster de servicio back-end 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 requiere datos del cliente, enviará solicitudes a la dirección del clúster de back-end con el token de acceso Azure AD en el encabezado autorización. El Power BI back-end 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 Azure AD tiene una duración predeterminada de 1hora 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.

Residencia de datos

A menos que se indique lo contrario en la documentación, Power BI almacena los datos de los clientes en una ubicación geográfica de Azure que se asigna cuando un inquilino de Azure AD se suscribe Power BI servicios por primera vez. Un Azure AD inquilino aloja las identidades de usuario y aplicación, los grupos y otra información pertinente que pertenece a una organización y su seguridad.

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

Varias zonas geográficas (varias zonas geográficas)

Algunas organizaciones tienen una presencia global y pueden requerir Power BI servicios en varias zonas geográficas de Azure. Por ejemplo, una empresa puede tener su oficina 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 Power BI datos permanezcan almacenados en reposo en la región remota para cumplir con la normativa local. Esta característica del servicio Power BI se conoce como multigeágeo.

La capa de ejecución de consultas, las cachés de consultas y los datos de artefacto asignados a un área de trabajo de varias zonas geográficas 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 el tránsito y el procesamiento de datos se puedan seguir teniendo en la geoágeda principal del inquilino, incluso en las áreas de trabajo hospedadas en una capacidad de Premium varias geoágeas.

Consulte Configuración de la compatibilidad con varias zonas geográficas para Power BI Premium para 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

Power BI servicios están disponibles en determinadas zonas geográficas de Azure, como se describe en el Centro de confianza de Microsoft. Para obtener más información sobre dónde se almacenan los datos y cómo se usan, consulte el Centro de confianza de Microsoft. Los compromisos relativos a la ubicación de los datos de los clientes en reposo se especifican en los Términos de procesamiento de datos de microsoft Términos de los Servicios en Línea.

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 Power BI prácticas de control de datos cuando se trata de almacenar, procesar y transferir datos del cliente.

Datos en reposo

Power BI 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 que conserva Power BI se cifran de forma predeterminada mediante claves administradas por Microsoft. Los datos de cliente almacenados en Azure SQL Databases SQL están totalmente cifrados mediante la tecnología Cifrado de datos transparente de azure (TDE). Los datos de cliente almacenados en Azure Blob Storage se cifran mediante Azure Storage Encryption.

Opcionalmente, las organizaciones pueden usar Power BI Premium 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 caso de error de un operador de servicio, los datos del cliente no se exponán, algo que no se puede lograr fácilmente mediante el cifrado transparente del lado del servicio. Consulte Bring your own encryption keys for Power BI (Traiga sus propias claves de cifrado para Power BI más información).

Power BI conjuntos de datos 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.

Independientemente del modo de conjunto de datos utilizado, Power BI 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 los usan activamente como parte de un escenario interactivo, o cuando un proceso en segundo plano, como la actualización, tocan estos datos. Power BI carga los 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 cifra mediante TLS 1.2 o posterior. Se rechazarán las solicitudes que intenten usar el servicio con TLS 1.1 o una versión inferior.

Autenticación en orígenes de datos

Al conectarse a un origen de datos, un usuario puede elegir 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 Power BI servicio, Power BI siempre usa la credencial de este usuario para importar datos. Una vez importados los datos, la visualización de 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 está conectado 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, Seguridad de nivel de fila (RLS) o la seguridad de nivel de objeto (OLS) se pueden 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, Azure AD autenticación se usa para el inicio de sesión único; para orígenes de datos locales, se admiten Kerberos, Lenguaje de marcado de aserción de seguridad (SAML) y Azure AD de datos.

Si el origen de datos es 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 para los que no tienen privilegios suficientes.

Premium características

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órfos, ejecutarán la lógica de transformación en los datos y, a continuación, los pondrán en un modelo de destino para su uso en varias 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 es posible que no realicen cambios en su composición. Una vez creado un flujo de datos, cualquier miembro, colaborador o administrador del área de trabajo 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 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 Power Query servicios mientras los datos están en marcha. En el caso de los flujos de datos Premium, Power Query servicios se ejecutan en nodos back-end. Los datos se pueden sacar directamente de los orígenes en la 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 desde 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 de todo el producto. Consulte la sección Autenticación en 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 Power BI propiedad y protegida. Storage cifrado 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 Power BI entidad de servicio se le concede acceso a esa cuenta de almacenamiento para que pueda escribir allí los datos 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 de forma redundante en una base de datos SQL que está disponible para DirectQuery a través del acceso por parte del sistema Power BI back-end. 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 cifrarla doblemente.

Al realizar consultas mediante DirectQuery, se usa el protocolo de transporte cifrado HTTPS para acceder a la API. Todo el uso secundario o indirecto de DirectQuery se controla mediante los mismos controles de acceso descritos anteriormente. Puesto 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 por cualquier medio.

Cuando 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 enriquecciones 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 realizan dentro de un espacio aislado.

Las definiciones de informes paginados (.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 para el servicio Power BI anterior.

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

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

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

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. Un iframe no puede leer ni escribir 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 una inserción para su escenario de organización, Azure AD los usuarios acceden a su propio contenido Power BI a través de portales personalizados por sus empresas e internet. Todas las directivas y funcionalidades de Power BI descritas en este documento, como Seguridad de nivel de fila (RLS) y la 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 Power BI y Power BI artefactos (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 ni modificar tokens de inserción. Los SDK del lado cliente, como Power BI API de cliente, anexan automáticamente el token de inserción cifrado a Power BI solicitudes como un encabezado Authorization: EmbedToken. En función de este encabezado, Power BI aplicará todas las directivas (como acceso o RLS) exactamente como especificó el ISV durante la generación.

Para habilitar la inserción y automatización, y para generar los tokens de inserción descritos anteriormente, Power BI un amplio conjunto de API REST. Estas Power BI REST admiten tanto la entidad de servicio como la delegada por el usuario Azure AD métodos de autenticación y autorización.

Power BI análisis insertado 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

Power BI admite actualmente dos categorías amplias de características de IA en el producto: objetos visuales de IA y enriquecimientos con IA. Las características de IA de nivel visual incluyen funcionalidades como Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomaly-Detection, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights, etc. Las funcionalidades de enriquecimiento con inteligencia artificial 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 Premium actuales. Sin embargo, AutoML y CognitiveServices solo se admiten en Premium de trabajo, 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 de Premium. Además, Power BI usuarios 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 trabajo.

Las características Premium enriquecimiento con IA de 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 utilizadas por un conjunto de datos o flujo de datos de Power BI. Tenga en cuenta que también se puede acceder a estas funciones desde los entornos de creación de conjuntos de datos o flujos de datos actuales en Power BI Service y Power BI Desktop. Estas funciones o transformaciones de inteligencia artificial siempre se ejecutan en Premium área de trabajo o capacidad. Estas funciones se encuentran en Power BI como un origen de datos que requiere un token de Azure AD para el usuario Power BI que usa la función de IA. Estos orígenes de datos de inteligencia artificial son especiales porque no superficien ninguno de sus propios datos y solo suministran estas funciones o transformaciones. Durante la ejecución, estas características no hacen llamadas salientes a otros servicios para transmitir los datos del cliente. Echemos un vistazo a los escenarios Premium para comprender los patrones de comunicación y los detalles relacionados con la seguridad pertinentes que les pertenecen.

Para entrenar y aplicar un modelo de AutoML, Power BI usa el SDK de Azure AutoML y ejecuta todo el entrenamiento en la capacidad de Power BI cliente. Durante las iteraciones de entrenamiento, Power BI llama a un servicio AzureML de experimentación para seleccionar un modelo y hiperparámetros adecuados para la iteración actual. En esta llamada saliente, solo se envían los metadatos pertinentes del experimento (por ejemplo, precisión, algoritmo de ml, parámetros de algoritmo, etc.) de la iteración anterior. El entrenamiento de AutoML genera un modelo DE ONNX y datos de informe de entrenamiento que luego se guardan en el flujo de datos. Más adelante, Power BI usuarios pueden aplicar el modelo de ML entrenado como una transformación para operacionalizar el modelo ML de forma programada. En el caso de las API de 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 Power BI Premium capacidad. En la actualidad, estas API se admiten tanto en flujos Power BI como en conjuntos de datos. Al crear un conjunto de datos en Power BI Desktop, los usuarios solo pueden acceder a esta funcionalidad si tienen acceso a un área Premium Power BI trabajo. Por lo tanto, se solicita a los clientes que proporcionen sus Azure AD credenciales.

Aislamiento de red

En esta sección se describen las características de seguridad avanzadas 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 (por ejemplo, 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.

Private Link integración

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

El 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 de la infraestructura no basada en Azure, como el acceso local, requeriría que los clientes tengan configurado ExpressRoute o una red privada virtual (VPN).

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 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) 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 el conocido proceso de administración de la seguridad y los orígenes de datos, como con una puerta de enlace de datos local.

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

1. El Power BI en la nube (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. A continuación, el servicio de red virtual PP inserta de forma segura un contenedor que ejecuta una puerta de enlace de red virtual en la subred. Este contenedor ahora puede conectarse a servicios de datos accesibles desde esta subred.

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

4. La puerta de enlace de red virtual obtiene la consulta y se conecta a 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 Power BI en la nube.

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

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, asigne las directivas de acceso adecuadas al almacén y revise periódicamente los permisos de acceso.

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

Prevención de pérdida de datos (DLP)

Microsoft 365 etiquetas de confidencialidad

Power BI una integración profunda con etiquetas de confidencialidad de Microsoft Information Protection (MIP), que permiten a las organizaciones tener una única solución integrada para la administración, auditoría y cumplimiento de directivas DLP en el conjunto de Office.

Cuando las etiquetas de confidencialidad están habilitadas 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 de Microsoft Information Protection conocidas que se usan en Office y en Azure Purview.
• Se pueden aplicar directivas de gobernanza, incluso cuando se exporta contenido Power BI archivos Excel, PowerPoint, PDF o .pbix, para ayudar a garantizar que los datos están protegidos incluso cuando dejan de Power BI.
• Los archivos .pbix se pueden cifrar según las directivas de etiquetas de MIP cuando se aplica una etiqueta MIP en el archivo .pbix en Desktop, lo que garantiza que solo los usuarios autorizados puedan editar este archivo.
• Es fácil clasificar y proteger los archivos .pbix como se hace con Excel, Word y PowerPoint archivos. Con solo dos clics, un archivo se puede etiquetar según su nivel de confidencialidad y, aún más, cifrarse si contiene datos confidenciales para la empresa.
• Excel los libros 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 el conjunto de datos Power BI se analiza en Excel.
• Las etiquetas de confidencialidad Power BI informes y paneles estarán visibles en Power BI aplicaciones móviles iOS y Android.
• Las etiquetas de confidencialidad se conservarán cuando un informe Power BI se inserte en Teams, SharePoint o un sitio web seguro (versión preliminar). Esto ayuda a las organizaciones a mantener la clasificación y la protección tras la exportación al insertar Power BI contenido.
• La herencia de etiquetas tras la creación de contenido nuevo en el servicio Power BI garantiza que la etiqueta aplicada a un conjunto de datos en el servicio Power BI se aplicará en el nuevo contenido creado sobre el conjunto de datos.
• Power BI API de examen de administración pueden extraer la etiqueta de confidencialidad de un artefacto 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.
• Power BI se asegura de que solo los usuarios autorizados pueden cambiar o quitar etiquetas con la configuración de protección en el Power BI servicio.
• Próximamente
  • Power BI API de administrador para aplicar etiquetas de MIP para permitir que los equipos centrales etiqueten mediante programación el contenido del Power BI servicio.
  • Los administradores podrán aplicar la aplicación de etiquetas en contenido nuevo o editado con una directiva de etiquetas obligatoria en Power BI servicio (versión preliminar).
  • Etiquetado automático de artefactos de bajada dentro Power BI servicio. Cuando se aplica o cambia una etiqueta en un conjunto de datos, la etiqueta se aplicará automáticamente en todo el contenido de nivel inferior conectado a este artefacto.

Consulte la documentación Microsoft Information Protection etiqueta de confidencialidad en Power BI para obtener más detalles.

Microsoft Cloud App Security (MCAS) para Power BI

Microsoft Cloud App Security es uno de los principales agentes de seguridad de acceso a la nube del mundo, llamado líder en el cuadrante mágico de Gartner para el mercado de Cloud Access Security Broker (CASB). Cloud App Security se usa para proteger el uso de aplicaciones en la nube. Permite a las organizaciones supervisar y controlar, en tiempo real, las sesiones de Power BI, 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 Cloud App Security, las organizaciones pueden obtener las siguientes funcionalidades de 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 Cloud App Security 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 Power BI actividad del usuario con Cloud App Security de actividad del usuario. El registro de actividad de Cloud App Security incluye una actividad de Power BI tal como se captura en el registro de auditoría de Office 365, que contiene información sobre todas las actividades de usuario y administrador, así como información de etiquetas de confidencialidad para actividades relevantes como aplicar, cambiar y quitar etiqueta. Los administradores pueden aprovechar Cloud App Security filtros avanzados y 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 Cloud App Security 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, posiblemente, actuar sobre ella automáticamente, si parece demasiado peligroso.
• Trabaje con Cloud App Security de anomalías integrada de la aplicación. Cloud App Security directivas de detección de anomalías de Cloud App Security 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 en la nube. Cuando una directiva de detección de anomalías identifica un comportamiento sospechoso, desencadena una alerta de seguridad.
• Power BI de administrador en Cloud App Security portal. Cloud App Security 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 Power BI los datos pertinentes en el portal, como alertas, usuarios en riesgo, registros de actividad y otra información relacionada con Power BI.

Vea Using Microsoft Cloud App Security Controls in Power BI (Uso de controles de 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 están previstas para publicarse hasta marzo de 2021. Dado que en este tema se enumeran las características que aún no se han publicado, las escalas de tiempo de entrega pueden cambiar y la funcionalidad proyectada puede publicarse más tarde que marzo de 2021 o no se puede publicar en absoluto. Para obtener más información, acerca de las versiones preliminares, revise el 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 de análisis avanzado de Azure Log Analytics, el lenguaje de consulta interactivo y las construcciones de aprendizaje automático integradas.

Power BI preguntas y respuestas de seguridad

Las preguntas siguientes son preguntas y respuestas comunes sobre seguridad para Power BI. Se organizan en función de cuándo se agregaron a estas white paper, para facilitar la capacidad de encontrar rápidamente nuevas preguntas y respuestas al actualizar 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 las credenciales a 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 el administrador de la puerta de enlace puede administrar los permisos para estos orígenes de datos. 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 Power BI servicio, Power BI siempre usa la credencial de este usuario para importar datos. Una vez importados los datos, la visualización de 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 conjunto de datos 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 preconfigurado, la credencial configurada previamente se usa para conectarse al origen de datos cuando cualquier usuario ve los datos. Si un origen de datos se conecta directamente mediante el inicio de sesión único, la credencial del usuario actual se usa para conectarse al origen de datos cuando el usuario ve los datos. Cuando se usa con inicio de sesión único, se puede implementar Seguridad de nivel de fila (RLS) o seguridad de nivel de objeto (OLS) en el origen de datos, lo que 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, Azure AD autenticación se usa para el inicio de sesión único; Para los 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, mediante 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 la puerta de enlace para SAP HANA origen de datos. 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 local Analysis Services y Seguridad de nivel de fila (RLS) o la seguridad de nivel de objeto (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á los datos para los que el usuario no tiene privilegios suficientes.

  La seguridad de nivel de fila Power BI se puede usar para restringir el acceso a datos para usuarios determinados. 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 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 usuarios malintencionados detecte incluso la existencia de estos objetos. Las tablas y columnas protegidas se ocultan en la lista de campos al usar 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 los 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 conjuntos de datos, lo que garantiza que solo los usuarios con los permisos necesarios tengan acceso para ver datos confidenciales e interactuar con ellos.

¿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 tiene acceso a un origen de datos, Power BI servicio sigue el proceso descrito anteriormente en la sección Autenticación en orígenes de datos de 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 esto en términos de acceso a datos, visualización de paneles, acceso a informes o actualización?

• 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 Analysis Services, solo los datos del panel se almacenan en caché 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 a los mismos orígenes de datos todo el tiempo, algunos de los cuales requieren credenciales que difieren de sus credenciales de dominio. ¿Cómo pueden evitar tener que especificar 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 usan la puerta de enlace de datos local y la puerta de enlace personal? ¿Hay algún nombre de dominio que deba permitirse con fines de conectividad?

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

Al trabajar con la puerta de enlace de datos local, ¿cómo se usan las claves de recuperación y dónde se almacenan? ¿Qué 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 Power BI servicio. 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 se abran 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 solo usa 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 a usar este protocolo modificando una configuración descrita en el artículo de 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 de 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 del servicio Power BI.

Para Power BI objetos visuales, ¿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 que es responsabilidad del cliente revisar y determinar si debe 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 datos? ¿Podemos aprovisionar inquilinos en centros de datos ubicados en zonas geográficas específicas para garantizar que los datos no salen 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 Power BI Premium suscripciones? ¿Son esas conexiones diferentes de las establecidas para el servicio que no Premium Power BI conexión?

• Las conexiones establecidas para los clientes con suscripciones Power BI Premium implementan un proceso de autorización de negocio 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.

• 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 de Power BI
• Power BI Premium
• Introducción al inicio de sesión único (SSO) para puertas de enlace de Power BI