Arquitectura de red de Microsoft Purview y procedimientos recomendados

Las soluciones de gobernanza de datos de Microsoft Purview son soluciones de plataforma como servicio (PaaS) para la gobernanza de datos. Las cuentas de Microsoft Purview tienen puntos de conexión públicos a los que se puede acceder a través de Internet para conectarse al servicio. Sin embargo, todos los puntos de conexión se protegen mediante inicios de sesión de Azure Active Directory (Azure AD) y control de acceso basado en rol (RBAC).

Nota:

Estos procedimientos recomendados cubren la arquitectura de red para las soluciones unificadas de gobernanza de datos de Microsoft Purview. Para obtener más información sobre las soluciones de cumplimiento y riesgo de Microsoft Purview, vaya aquí. Para obtener más información sobre Microsoft Purview en general, vaya aquí.

Para una capa de seguridad agregada, puede crear puntos de conexión privados para su cuenta de Microsoft Purview. Obtendrá una dirección IP privada de la red virtual de Azure a la cuenta de Microsoft Purview y sus recursos administrados. Esta dirección restringirá todo el tráfico entre la red virtual y la cuenta de Microsoft Purview a un vínculo privado para la interacción del usuario con las API y el portal de gobernanza de Microsoft Purview, o para el examen y la ingesta.

Actualmente, el firewall de Microsoft Purview proporciona control de acceso para el punto de conexión público de la cuenta de Purview. Puede usar el firewall para permitir todo el acceso o bloquear todo el acceso a través del punto de conexión público al usar puntos de conexión privados. Para obtener más información, consulte Opciones de firewall de Microsoft Purview.

En función de los requisitos de red, conectividad y seguridad, puede configurar y mantener cuentas de Microsoft Purview para acceder a los servicios subyacentes o a la ingesta. Use esta guía de procedimientos recomendados para definir y preparar el entorno de red para que pueda acceder a Microsoft Purview y examinar orígenes de datos desde la red o la nube.

En esta guía se tratan las siguientes opciones de red:

• Use puntos de conexión públicos de Azure.
• Use puntos de conexión privados.
• Use puntos de conexión privados y permita el acceso público en la misma cuenta de Microsoft Purview.
• Use puntos de conexión públicos de Azure para acceder al portal de gobernanza de Microsoft Purview y a los puntos de conexión privados para la ingesta.

En esta guía se describen algunos de los escenarios de arquitectura de red más comunes para Microsoft Purview. Aunque no se limita a esos escenarios, tenga en cuenta las limitaciones del servicio al planear redes para sus cuentas de Microsoft Purview.

Requisitos previos

Para comprender qué opción de red es la mejor para su entorno, se recomienda realizar primero las siguientes acciones:

• Revise la topología de red y los requisitos de seguridad antes de registrar y examinar los orígenes de datos en Microsoft Purview. Para obtener más información, consulte : Definición de una topología de red de Azure.

• Defina el modelo de conectividad de red para los servicios paaS.

Opción 1: Usar puntos de conexión públicos

De forma predeterminada, puede usar cuentas de Microsoft Purview a través de los puntos de conexión públicos accesibles a través de Internet. Permitir redes públicas en su cuenta de Microsoft Purview si tiene los siguientes requisitos:

• No se requiere conectividad privada al examinar o conectarse a puntos de conexión de Microsoft Purview.
• Todos los orígenes de datos son solo aplicaciones de software como servicio (SaaS).
• Todos los orígenes de datos tienen un punto de conexión público al que se puede acceder a través de Internet.
• Los usuarios empresariales requieren acceso a una cuenta de Microsoft Purview y al portal de gobernanza de Microsoft Purview a través de Internet.

Opciones de Integration Runtime

Para examinar orígenes de datos mientras el firewall de la cuenta de Microsoft Purview está establecido para permitir el acceso público, puede usar azure integration runtime y un entorno de ejecución de integración autohospedado. La forma de usarlas depende de la compatibilidad de los orígenes de datos.

Estos son algunos procedimientos recomendados:

• Puede usar El entorno de ejecución de integración de Azure o un entorno de ejecución de integración autohospedado para examinar orígenes de datos de Azure, como Azure SQL Database o Azure Blob Storage, pero se recomienda usar El entorno de ejecución de integración de Azure para examinar orígenes de datos de Azure cuando sea posible, con el fin de reducir el costo y la sobrecarga administrativa.

• Para examinar varios orígenes de datos de Azure, use una red pública y el entorno de ejecución de integración de Azure. En los pasos siguientes se muestra el flujo de comunicación en un nivel alto cuando se usa El entorno de ejecución de integración de Azure para examinar un origen de datos en Azure:

  

  1. Se inicia un examen manual o automático desde el Mapa de datos de Microsoft Purview a través del entorno de ejecución de integración de Azure.

  2. El entorno de ejecución de integración de Azure se conecta al origen de datos para extraer metadatos.

  3. Los metadatos se ponen en cola en el almacenamiento administrado de Microsoft Purview y se almacenan en Azure Blob Storage.

  4. Los metadatos se envían al Mapa de datos de Microsoft Purview.

• El examen de orígenes de datos locales y basados en máquinas virtuales siempre requiere usar un entorno de ejecución de integración autohospedado. El entorno de ejecución de integración de Azure no es compatible con estos orígenes de datos. Los pasos siguientes muestran el flujo de comunicación en un nivel alto cuando se usa un entorno de ejecución de integración autohospedado para examinar un origen de datos. En el primer diagrama se muestra un escenario en el que los recursos se encuentran en Azure o en una máquina virtual de Azure. En el segundo diagrama se muestra un escenario con recursos locales. Los pasos entre los dos son los mismos desde la perspectiva de Microsoft Purview:

  

  

  1. Se desencadena un examen manual o automático. Microsoft Purview se conecta a Azure Key Vault para recuperar la credencial para acceder a un origen de datos.

  2. El examen se inicia desde el Mapa de datos de Microsoft Purview a través de un entorno de ejecución de integración autohospedado.

  3. El servicio integration runtime autohospedado de la máquina virtual o la máquina local se conecta al origen de datos para extraer metadatos.

  4. Los metadatos se procesan en la memoria de la máquina para el entorno de ejecución de integración autohospedado. Los metadatos se ponen en cola en el almacenamiento administrado de Microsoft Purview y, a continuación, se almacenan en Azure Blob Storage. Los datos reales nunca salen del límite de la red.

  5. Los metadatos se envían al Mapa de datos de Microsoft Purview.

Opciones de autenticación

Al examinar un origen de datos en Microsoft Purview, debe proporcionar una credencial. A continuación, Microsoft Purview puede leer los metadatos de los recursos mediante el entorno de ejecución de integración de Azure en el origen de datos de destino. Cuando se usa una red pública, las opciones de autenticación y los requisitos varían en función de los siguientes factores:

• Tipo de origen de datos. Por ejemplo, si el origen de datos está Azure SQL Database, debe usar un inicio de sesión con db_datareader acceso a cada base de datos. Puede ser una identidad administrada por el usuario o una identidad administrada de Microsoft Purview. O bien, puede ser una entidad de servicio en Azure Active Directory agregada a SQL Database como db_datareader.

  Si el origen de datos está Azure Blob Storage, puede usar una identidad administrada de Microsoft Purview o una entidad de servicio en Azure Active Directory agregada como rol lector de datos de Blob Storage en la cuenta de Almacenamiento de Azure. O bien, use la clave de la cuenta de almacenamiento.

• Tipo de autenticación. Se recomienda usar una identidad administrada de Microsoft Purview para examinar orígenes de datos de Azure siempre que sea posible, con el fin de reducir la sobrecarga administrativa. Para cualquier otro tipo de autenticación, debe configurar las credenciales para la autenticación de origen dentro de Microsoft Purview:

  1. Genere un secreto dentro de un almacén de claves de Azure.
  2. Registre el almacén de claves dentro de Microsoft Purview.
  3. Dentro de Microsoft Purview, cree una nueva credencial mediante el secreto guardado en el almacén de claves.

• Tipo en tiempo de ejecución que se usa en el examen. Actualmente, no se puede usar una identidad administrada de Microsoft Purview con un entorno de ejecución de integración autohospedado.

Otras consideraciones

• Si decide examinar orígenes de datos mediante puntos de conexión públicos, las máquinas virtuales de Integration Runtime autohospedadas deben tener acceso saliente a orígenes de datos y puntos de conexión de Azure.

• Las máquinas virtuales del entorno de ejecución de integración autohospedado deben tener conectividad saliente con los puntos de conexión de Azure.

• Los orígenes de datos de Azure deben permitir el acceso público. Si un punto de conexión de servicio está habilitado en el origen de datos, asegúrese de permitir que los servicios de Azure de la lista de servicios de confianza accedan a los orígenes de datos de Azure. El punto de conexión de servicio enruta el tráfico desde la red virtual a través de una ruta de acceso óptima a Azure.

Opción 2: Usar puntos de conexión privados

De forma similar a otras soluciones paaS, Microsoft Purview no admite la implementación directamente en una red virtual. Por lo tanto, no puede usar ciertas características de red con los recursos de la oferta, como grupos de seguridad de red, tablas de rutas u otros dispositivos dependientes de la red, como Azure Firewall. En su lugar, puede usar puntos de conexión privados que se pueden habilitar en la red virtual. A continuación, puede deshabilitar el acceso público a Internet para conectarse de forma segura a Microsoft Purview.

Si tiene alguno de los siguientes requisitos, debe usar puntos de conexión privados para su cuenta de Microsoft Purview:

• Debe tener aislamiento de red de un extremo a otro para las cuentas y orígenes de datos de Microsoft Purview.

• Debe bloquear el acceso público a las cuentas de Microsoft Purview.

• Los orígenes de datos de la plataforma como servicio (PaaS) se implementan con puntos de conexión privados y ha bloqueado todo el acceso a través del punto de conexión público.

• Los orígenes de datos locales o de infraestructura como servicio (IaaS) no pueden llegar a puntos de conexión públicos.

Consideraciones sobre diseño

• Para conectarse a la cuenta de Microsoft Purview de forma privada y segura, debe implementar una cuenta y un punto de conexión privado del portal. Por ejemplo, esta implementación es necesaria si tiene previsto conectarse a Microsoft Purview a través de la API o usar el portal de gobernanza de Microsoft Purview.

• Si necesita conectarse al portal de gobernanza de Microsoft Purview mediante puntos de conexión privados, debe implementar puntos de conexión privados de cuenta y de portal.

• Para examinar orígenes de datos a través de conectividad privada, debe configurar al menos una cuenta y un punto de conexión privado de ingesta para Microsoft Purview. Debe configurar los exámenes mediante un entorno de ejecución de integración autohospedado a través de un método de autenticación distinto de una identidad administrada de Microsoft Purview.

• Revise Matriz de compatibilidad para examinar orígenes de datos a través de un punto de conexión privado de ingesta antes de configurar los exámenes.

• Revise los requisitos de DNS. Si usa un servidor DNS personalizado en la red, los clientes deben poder resolver el nombre de dominio completo (FQDN) de los puntos de conexión de la cuenta de Microsoft Purview en la dirección IP del punto de conexión privado.

• Para examinar orígenes de datos de Azure a través de conectividad privada, use Managed VNet Runtime. Ver las regiones admitidas. Esta opción puede reducir la sobrecarga administrativa de la implementación y administración de máquinas de Integration Runtime autohospedadas.

Opciones de Integration Runtime

• Si los orígenes de datos están en Azure, puede elegir cualquiera de las siguientes opciones en tiempo de ejecución:

  • Tiempo de ejecución de red virtual administrada. Use esta opción si la cuenta de Microsoft Purview está implementada en cualquiera de las regiones admitidas y tiene previsto examinar cualquiera de los orígenes de datos admitidos.

  • Entorno de ejecución de integración autohospedado.

    • Si usa integration runtime autohospedado, debe configurar y usar un entorno de ejecución de integración autohospedado en una máquina virtual Windows que se implemente dentro de la misma red virtual o en una red virtual emparejada donde se implementan los puntos de conexión privados de ingesta de Microsoft Purview. El entorno de ejecución de integración de Azure no funcionará con puntos de conexión privados de ingesta.

    • Para examinar orígenes de datos locales, también puede instalar un entorno de ejecución de integración autohospedado en una máquina Windows local o en una máquina virtual dentro de una red virtual de Azure.

    • Cuando se usan puntos de conexión privados con Microsoft Purview, es preciso permitir la conectividad de red desde orígenes de datos a la máquina virtual de integración autohospedada en la red virtual de Azure donde se implementan los puntos de conexión privados de Microsoft Purview.

    • Se recomienda permitir la actualización automática del entorno de ejecución de integración autohospedado. Asegúrese de abrir las reglas de salida necesarias en la red virtual de Azure o en el firewall corporativo para permitir la actualización automática. Para obtener más información, consulte Requisitos de red de Integration Runtime autohospedado.

Opciones de autenticación

• No puede usar una identidad administrada de Microsoft Purview para examinar orígenes de datos a través de puntos de conexión privados de ingesta. Use una entidad de servicio, una clave de cuenta o la autenticación de SQL en función del tipo de origen de datos.

• Asegúrese de que las credenciales se almacenan en un almacén de claves de Azure y se registran en Microsoft Purview.

• Debe crear una credencial en Microsoft Purview en función de cada secreto que cree en el almacén de claves de Azure. Como mínimo, debe asignar y enumerar el acceso a los secretos de Microsoft Purview en el recurso Key Vault de Azure. De lo contrario, las credenciales no funcionarán en la cuenta de Microsoft Purview.

Limitaciones actuales

• No se admite el examen de varios orígenes de Azure mediante la suscripción completa o el grupo de recursos a través de puntos de conexión privados de ingesta y un entorno de ejecución de integración autohospedado cuando se usan puntos de conexión privados para la ingesta. En su lugar, puede registrar y examinar orígenes de datos individualmente.

• Para conocer las limitaciones relacionadas con los puntos de conexión privados de Microsoft Purview, consulte Limitaciones conocidas.

• Para conocer las limitaciones relacionadas con el servicio de Private Link, consulte límites de Azure Private Link.

Escenarios de punto de conexión privado

Una sola red virtual, una sola región

En este escenario, todos los orígenes de datos de Azure, las máquinas virtuales del entorno de ejecución de integración autohospedado y los puntos de conexión privados de Microsoft Purview se implementan en la misma red virtual en una suscripción de Azure.

Si existen orígenes de datos locales, la conectividad se proporciona a través de una VPN de sitio a sitio o una conectividad de Azure ExpressRoute a una red virtual de Azure donde se implementan los puntos de conexión privados de Microsoft Purview.

Esta arquitectura es adecuada principalmente para organizaciones pequeñas o para escenarios de desarrollo, pruebas y pruebas de concepto.

Una sola región, varias redes virtuales

Para conectar dos o más redes virtuales en Azure, puede usar el emparejamiento de redes virtuales. El tráfico de red entre redes virtuales emparejadas es privado y se mantiene en la red troncal de Azure.

Muchos clientes crean su infraestructura de red en Azure mediante la arquitectura de red en estrella tipo hub-and-spoke, donde:

• Los servicios compartidos de red (como las aplicaciones virtuales de red, las puertas de enlace de ExpressRoute/VPN o los servidores DNS) se implementan en la red virtual del centro.
• Las redes virtuales de radio consumen esos servicios compartidos a través del emparejamiento de redes virtuales.

En las arquitecturas de red en estrella tipo hub-and-spoke, el equipo de gobernanza de datos de la organización se puede proporcionar con una suscripción de Azure que incluya una red virtual (centro). Todos los servicios de datos se pueden encontrar en otras suscripciones conectadas a la red virtual del centro a través de un emparejamiento de red virtual o una conexión VPN de sitio a sitio.

En una arquitectura en estrella tipo hub-and-spoke, puede implementar Microsoft Purview y una o varias máquinas virtuales de Integration Runtime autohospedadas en la suscripción del centro y la red virtual. Puede registrar y examinar orígenes de datos de otras redes virtuales de varias suscripciones de la misma región.

Las máquinas virtuales del entorno de ejecución de integración autohospedado se pueden implementar dentro de la misma red virtual de Azure o en una red virtual emparejada donde se implementan la cuenta y los puntos de conexión privados de ingesta.

Opcionalmente, puede implementar otro entorno de ejecución de integración autohospedado en las redes virtuales de radio.

Varias regiones, varias redes virtuales

Si los orígenes de datos se distribuyen entre varias regiones de Azure en una o varias suscripciones de Azure, puede usar este escenario.

Para optimizar el rendimiento y los costos, se recomienda implementar una o varias máquinas virtuales de Integration Runtime autohospedadas en cada región donde se encuentran los orígenes de datos.

Examen mediante el entorno de ejecución de red virtual administrada

Puede usar Managed VNet Runtime para examinar orígenes de datos en una red privada, si la cuenta de Microsoft Purview se implementa en cualquiera de las regiones admitidas y tiene previsto examinar cualquiera de los orígenes de datos de Azure admitidos.

El uso del entorno de ejecución de red virtual administrada ayuda a minimizar la sobrecarga administrativa de la administración del tiempo de ejecución y a reducir la duración general del examen.

Para examinar los orígenes de datos de Azure mediante Managed VNet Runtime, se debe implementar un punto de conexión privado administrado en Microsoft Purview Managed Virtual Network, incluso si el origen de datos ya tiene una red privada en la suscripción de Azure.

Si necesita examinar orígenes de datos locales o orígenes de datos adicionales en Azure que no son compatibles con Managed VNet Runtime, puede implementar Managed VNet Runtime y Self-hosted Integration Runtime.

Si Microsoft Purview no está disponible en la región primaria

Microsoft Purview es una solución de plataforma como servicio de Azure. Puede implementar una cuenta de Microsoft Purview dentro de la suscripción de Azure en cualquier región de Azure admitida.

Si Microsoft Purview no está disponible en la región principal de Azure, tenga en cuenta los siguientes factores al elegir una región secundaria para implementar la cuenta de Microsoft Purview:

• Revise la latencia entre la región de Azure principal donde se implementan los orígenes de datos y la región secundaria de Azure, donde se implementará la cuenta de Microsoft Purview. Para obtener más información, consulte Estadísticas de latencia de ida y vuelta de red de Azure.
• Revise los requisitos de residencia de datos. Al examinar orígenes de datos en el Mapa de datos de Microsoft Purview, la información relacionada con los metadatos se ingiere y se almacena dentro del mapa de datos en la región de Azure donde se implementa la cuenta de Microsoft Purview. Para obtener más información, vea Dónde se almacenan los metadatos.
• Revise los requisitos de red y seguridad si se requiere conectividad de red privada para el acceso de usuario o la ingesta de metadatos. Para obtener más información, consulte Si Microsoft Purview no está disponible en la región primaria.

Opción 1: implemente la cuenta de Microsoft Purview en una región secundaria e implemente todos los puntos de conexión privados en la región primaria, donde se encuentran los orígenes de datos de Azure. Para este escenario:

• Esta es la opción recomendada, si El sudeste de Australia es la región principal de todos los orígenes de datos y tiene todos los recursos de red implementados en la región primaria.
• Implemente una cuenta de Microsoft Purview en la región secundaria (por ejemplo, Este de Australia).
• Implemente todos los puntos de conexión privados de Microsoft Purview, incluida la cuenta, el portal y la ingesta en la región primaria (por ejemplo, Sudeste de Australia).
• Implemente todas las máquinas virtuales de Integration Runtime autohospedadas de Microsoft Purview en la región primaria (por ejemplo, Sudeste de Australia). Esto ayuda a reducir el tráfico entre regiones, ya que los exámenes de Mapa de datos se producirán en la región local donde se encuentran los orígenes de datos y solo se ingieren metadatos en la región secundaria donde se implementa la cuenta de Microsoft Purview.
• Si usa redes virtuales administradas de Microsoft Purview para la ingesta de metadatos, Managed VNet Runtime y todos los puntos de conexión privados administrados se implementarán automáticamente en la región donde se implementa Microsoft Purview (por ejemplo, Este de Australia).

Opción 2: implemente la cuenta de Microsoft Purview en una región secundaria e implemente puntos de conexión privados en las regiones principal y secundaria. Para este escenario:

• Esta opción se recomienda si tiene orígenes de datos en regiones primarias y secundarias y los usuarios están conectados a través de la región primaria.
• Implemente una cuenta de Microsoft Purview en la región secundaria (por ejemplo, Este de Australia).
• Implemente el punto de conexión privado del portal de gobernanza de Microsoft Purview en la región primaria (por ejemplo, Sudeste de Australia) para que el usuario acceda al portal de gobernanza de Microsoft Purview.
• Implemente la cuenta de Microsoft Purview y los puntos de conexión privados de ingesta en la región primaria (por ejemplo, sudeste de Australia) para examinar los orígenes de datos localmente en la región primaria.
• Implemente la cuenta de Microsoft Purview y los puntos de conexión privados de ingesta en la región secundaria (por ejemplo, Este de Australia) para examinar los orígenes de datos localmente en la región secundaria.
• Implemente máquinas virtuales de Integration Runtime autohospedadas de Microsoft Purview en regiones primarias y secundarias. Esto ayudará a mantener el tráfico de análisis de mapa de datos en la región local y a enviar solo metadatos a Mapa de datos de Microsoft Purview donde está configurado en la región secundaria (por ejemplo, Este de Australia).
• Si usa redes virtuales administradas de Microsoft Purview para la ingesta de metadatos, Managed VNet Runtime y todos los puntos de conexión privados administrados se implementarán automáticamente en la región donde se implementa Microsoft Purview (por ejemplo, Este de Australia).

Configuración de DNS con puntos de conexión privados

Resolución de nombres para varias cuentas de Microsoft Purview

Se recomienda seguir estas recomendaciones si su organización necesita implementar y mantener varias cuentas de Microsoft Purview mediante puntos de conexión privados:

1. Implemente al menos un punto de conexión privado de cuenta para cada cuenta de Microsoft Purview.
2. Implemente al menos un conjunto de puntos de conexión privados de ingesta para cada cuenta de Microsoft Purview.
3. Implemente un punto de conexión privado del portal para una de las cuentas de Microsoft Purview en los entornos de Azure. Cree un registro DNS A para el punto de conexión privado del portal para resolver web.purview.azure.com. Todas las cuentas de purview de la misma red virtual de Azure o redes virtuales conectadas a través del emparejamiento de red virtual pueden usar el punto de conexión privado del portal .

Este escenario también se aplica si se implementan varias cuentas de Microsoft Purview en varias suscripciones y varias redes virtuales conectadas a través del emparejamiento de redes virtuales. El punto de conexión privado del portal representa principalmente los recursos estáticos relacionados con el portal de gobernanza de Microsoft Purview, por lo que es independiente de la cuenta de Microsoft Purview, por lo que solo se necesita un punto de conexión privado del portal para visitar todas las cuentas de Microsoft Purview en el entorno de Azure si las redes virtuales están conectadas.

Nota:

Es posible que tenga que implementar puntos de conexión privados del portal independientes para cada cuenta de Microsoft Purview en los escenarios en los que las cuentas de Microsoft Purview se implementan en segmentaciones de red aisladas. El portal de Microsoft Purview es contenido estático para todos los clientes sin información del cliente. Opcionalmente, puede usar la red pública (sin punto de conexión privado del portal) para iniciarse web.purview.azure.com si los usuarios finales pueden iniciar Internet.

Opción 3: Usar puntos de conexión públicos y privados

Puede elegir una opción en la que un subconjunto de los orígenes de datos use puntos de conexión privados y, al mismo tiempo, debe examinar cualquiera de las siguientes opciones:

• Otros orígenes de datos configurados con un punto de conexión de servicio
• Orígenes de datos que tienen un punto de conexión público al que se puede acceder a través de Internet

Si necesita examinar algunos orígenes de datos mediante un punto de conexión privado de ingesta y algunos orígenes de datos mediante puntos de conexión públicos o un punto de conexión de servicio, puede:

1. Use puntos de conexión privados para su cuenta de Microsoft Purview.
2. Establezca Acceso a la red pública en Habilitado desde todas las redes de su cuenta de Microsoft Purview.

Opciones de Integration Runtime

• Para examinar un origen de datos de Azure configurado con un punto de conexión privado, debe configurar y usar un entorno de ejecución de integración autohospedado en una máquina virtual Windows implementada dentro de la misma red virtual o emparejada donde se implementan la cuenta de Microsoft Purview y los puntos de conexión privados de ingesta.

  Cuando usa un punto de conexión privado con Microsoft Purview, debe permitir la conectividad de red desde orígenes de datos a una máquina virtual de integración autohospedada en la red virtual de Azure donde se implementan los puntos de conexión privados de Microsoft Purview.

• Para examinar un origen de datos de Azure configurado para permitir un punto de conexión público, puede usar el entorno de ejecución de integración de Azure.

• Para examinar orígenes de datos locales, también puede instalar un entorno de ejecución de integración autohospedado en una máquina Windows local o en una máquina virtual dentro de una red virtual de Azure.

• Se recomienda permitir la actualización automática para un entorno de ejecución de integración autohospedado. Asegúrese de abrir las reglas de salida necesarias en la red virtual de Azure o en el firewall corporativo para permitir la actualización automática. Para obtener más información, consulte Requisitos de red de Integration Runtime autohospedado.

Opciones de autenticación

• Para examinar un origen de datos de Azure configurado para permitir un punto de conexión público, puede usar cualquier opción de autenticación, en función del tipo de origen de datos.

• Si usa un punto de conexión privado de ingesta para examinar un origen de datos de Azure configurado con un punto de conexión privado:

  • No se puede usar una identidad administrada de Microsoft Purview. En su lugar, use una entidad de servicio, una clave de cuenta o la autenticación SQL, en función del tipo de origen de datos.

  • Asegúrese de que las credenciales se almacenan en un almacén de claves de Azure y se registran en Microsoft Purview.

  • Debe crear una credencial en Microsoft Purview basada en cada secreto que cree en Azure Key Vault. Como mínimo, asigne acceso get y list para los secretos de Microsoft Purview en el recurso Key Vault de Azure. De lo contrario, las credenciales no funcionarán en la cuenta de Microsoft Purview.

Opción 4: Usar puntos de conexión privados solo para la ingesta

Puede elegir esta opción si necesita:

• Examine todos los orígenes de datos mediante el punto de conexión privado de ingesta.
• Los recursos administrados deben configurarse para deshabilitar la red pública.
• Habilite el acceso al portal de gobernanza de Microsoft Purview a través de una red pública.

Para habilitar esta opción:

1. Configure el punto de conexión privado de ingesta para la cuenta de Microsoft Purview.
2. Establezca Acceso a la red públicaen Deshabilitado solo para la ingesta (versión preliminar) en la cuenta de Microsoft Purview.

Opciones de Integration Runtime

Siga la recomendación de la opción 2.

Opciones de autenticación

Siga la recomendación de la opción 2.

Recomendaciones de red y proxy de Integration Runtime autohospedado

Para examinar orígenes de datos en las redes locales y de Azure, es posible que tenga que implementar y usar una o varias máquinas virtuales de Integration Runtime autohospedadas dentro de una red virtual de Azure o una red local, para cualquiera de los escenarios mencionados anteriormente en este documento.

• Para simplificar la administración, siempre que sea posible, use el entorno de ejecución de Azure y el entorno de ejecución administrado de Microsoft Purview para examinar los orígenes de datos de Azure.

• El servicio integration runtime autohospedado puede comunicarse con Microsoft Purview a través de una red pública o privada a través del puerto 443. Para obtener más información, consulte Requisitos de red de Integration Runtime autohospedado.

• Se puede usar una máquina virtual de Integration Runtime autohospedada para examinar uno o varios orígenes de datos en Microsoft Purview; sin embargo, el entorno de ejecución de integración autohospedado solo debe estar registrado para Microsoft Purview y no se puede usar para Azure Data Factory ni Azure Synapse al mismo tiempo.

• Puede registrar y usar uno o varios entornos de ejecución de integración autohospedados en una cuenta de Microsoft Purview. Se recomienda colocar al menos una máquina virtual del entorno de ejecución de integración autohospedado en cada región o red local donde residen los orígenes de datos.

• Se recomienda definir una línea base para la capacidad necesaria para cada máquina virtual del entorno de ejecución de integración autohospedado y escalar la capacidad de la máquina virtual en función de la demanda.

• Se recomienda configurar la conexión de red entre máquinas virtuales de Integration Runtime autohospedadas y Microsoft Purview y sus recursos administrados a través de una red privada, siempre que sea posible.

• Permitir la conectividad saliente a download.microsoft.com, si la actualización automática está habilitada.

• El servicio integration runtime autohospedado no requiere conectividad saliente a Internet, si las máquinas virtuales del entorno de ejecución de integración autohospedado se implementan en una red virtual de Azure o en la red local que está conectada a Azure a través de una conexión VPN de sitio a sitio o ExpressRoute. En este caso, el proceso de exploración y ingesta de metadatos se puede realizar a través de una red privada.

• El entorno de ejecución de integración autohospedado puede comunicar Microsoft Purview y sus recursos administrados directamente o a través de un servidor proxy. Evite usar la configuración de proxy si la máquina virtual del entorno de ejecución de integración autohospedado está dentro de una red virtual de Azure o está conectada a través de ExpressRoute o la conexión VPN de sitio a sitio.

• Revise los escenarios admitidos, si necesita usar el entorno de ejecución de integración autohospedado con la configuración de proxy.

Siguientes pasos

• Uso de puntos de conexión privados para un acceso seguro a Microsoft Purview