Azure Private Link for Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse es un almacenamiento relacional de escala empresarial en una base de lago de datos, con una arquitectura lista para el futuro, inteligencia artificial integrada y nuevas características. Si no está familiarizado con el almacenamiento de datos, comience con Fabric Data Warehouse. Las cargas de trabajo del grupo dedicado de SQL pueden actualizarse a Fabric para acceder a funcionalidades avanzadas en ciencia de datos, análisis en tiempo real e informes.

Usando Azure Private Link, puedes conectarte a Synapse SQL a través de un endpoint privado. Un punto final privado es una interfaz de red con una dirección IP privada en tu red virtual y subred. El tráfico permanece en la red troncal de Microsoft en lugar de pasar por internet público.

Use siempre el nombre de dominio completo (FQDN) del servidor (<server>.database.windows.net) en cadenas de conexión para todos los controladores y herramientas de cliente. Los intentos de autenticación que usan la dirección IP privada o el enlace privado FQDN (<server>.privatelink.database.windows.net) no funcionan. Este comportamiento es intencionado porque el endpoint privado enruta el tráfico a la pasarela SQL, que necesita el FQDN correcto para enrutar correctamente las solicitudes de autenticación.

Proceso de creación

Crea endpoints privados utilizando el portal de Azure, PowerShell o la CLI de Azure:

Proceso de aprobación

Una vez que el administrador de red cree el punto de conexión privado (PE), el administrador de SQL puede administrar la conexión del punto de conexión privado (PEC) a SQL Database.

  1. Ve al recurso del servidor en el portal de Azure.

  2. Ve a la página de aprobación de endpoints privados. En el recurso servidor SQL de Azure Synapse Analytics, en Seguridad del menú de recursos, seleccione Conexiones del punto de conexión privado.

  3. Consulta lo siguiente:

    • Lista de todas las conexiones de extremo privado (PEC)
    • Puntos finales privados (PE) creados

  4. Si no hay puntos finales privados, crea uno seleccionando Crear un punto final privado. De lo contrario, seleccione una conexión de punto de conexión privado en la lista.

  5. El administrador de SQL puede aprobar o rechazar un PEC y, opcionalmente, añadir una respuesta corta en texto.

  6. Tras la aprobación o rechazo, la lista refleja el estado correspondiente junto con el texto de la respuesta.

  7. Selecciona el nombre del endpoint privado.

    Esta acción te lleva a la página de resumen de Private endpoint. Seleccione el vínculo Interfaces de red para ver los detalles de la interfaz de red de la conexión del punto de conexión privado.

    En la página Interfaz de red se muestra la dirección IP privada para la conexión de punto de conexión privado.

Important

Cuando se agrega una conexión de punto de conexión privado, el enrutamiento público al servidor lógico no se bloquea de forma predeterminada. En el panel Firewall y redes virtuales, el valor Denegar acceso a la red pública no está seleccionado de forma predeterminada. Para deshabilitar el acceso a la red pública, asegúrese de seleccionar Denegar acceso a la red pública.

Deshabilitar el acceso público al servidor lógico

En tu servidor SQL de Azure Synapse Analytics, puedes desactivar todo el acceso público a tu servidor lógico y permitir conexiones solo desde tu red virtual.

En primer lugar, asegúrese de que las conexiones de punto de conexión privado se hayan habilitado y configurado. A continuación, para deshabilitar el acceso público al servidor lógico:

  1. Vaya a la página Redes del servidor lógico.
  2. Seleccione la casilla Denegar acceso a la red pública.

Prueba de la conectividad con SQL Database desde una VM de Azure que se encuentre en la misma red virtual

Para este escenario, supongamos que creaste una Máquina Virtual (VM) de Azure ejecutando una versión reciente de Windows en la misma red virtual que el punto final privado.

  1. Inicie una sesión de Escritorio remoto (RDP) y conéctese a la máquina virtual.

  2. Luego puedes hacer algunas comprobaciones básicas de conectividad para asegurarte de que la VM se conecta a la base de datos SQL a través del endpoint privado usando las siguientes herramientas:

Comprueba la conectividad usando Telnet

Telnet es una función de Windows que puedes usar para probar la conectividad. Dependiendo de la versión de Windows, puede que necesites activar explícitamente esta función.

Abre una ventana del Símbolo del sistema después de instalar Telnet. Ejecute el comando Telnet y especifique la dirección IP y el punto de conexión privado de la base de datos SQL.

telnet 10.9.0.4 1433

Cuando Telnet se conecta correctamente, devuelve una pantalla en blanco en la ventana de comandos.

Comprueba la conectividad usando PowerShell

Usa un comando PowerShell para comprobar la conectividad:

Test-NetConnection -computer myserver.database.windows.net -port 1433

Comprueba la conectividad usando PsPing

Utiliza PsPing de la siguiente manera para comprobar que el endpoint privado está escuchando conexiones en el puerto 1433.

Ejecuta PsPing proporcionando el FQDN para el servidor SQL lógico y el puerto 1433:

PsPing.exe mysqldbsrvr.database.windows.net:1433

Este ejemplo muestra la salida esperada:

TCP connect to 10.9.0.4:1433:
5 iterations (warmup 1) ping test:
Connecting to 10.9.0.4:1433 (warmup): from 10.6.0.4:49953: 2.83ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49954: 1.26ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49955: 1.98ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49956: 1.43ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49958: 2.28ms

La salida muestra que PsPing puede hacer ping a la dirección IP privada asociada al punto final privado.

Comprueba la conectividad usando Nmap

Nmap (Network Mapper) es una herramienta gratuita y de código abierto para el descubrimiento de redes y auditorías de seguridad. Para más información y el enlace de descarga, visita https://Nmap.org. Utiliza esta herramienta para asegurarte de que el endpoint privado está a la escucha de conexiones en el puerto 1433.

Ejecuta Nmap proporcionando el rango de direcciones de la subred que aloja el endpoint privado.

Nmap -n -sP 10.9.0.0/24

Este ejemplo muestra la salida esperada:

Nmap scan report for 10.9.0.4
Host is up (0.00s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 207.00 seconds

El resultado muestra que una dirección IP está activa, que corresponde a la dirección IP del punto final privado.

Comprueba la conectividad utilizando SQL Server Management Studio (SSMS)

Use el nombre de dominio completo (FQDN) del servidor en las cadenas de conexión de los clientes (<server>.database.windows.net). Cualquier intento de inicio de sesión realizado directamente en la dirección IP o usando el enlace privado FQDN (<server>.privatelink.database.windows.net) falla. Este comportamiento es intencionado, ya que el punto final privado enruta el tráfico hacia la pasarela SQL en la región. Necesitas especificar el FQDN correcto para que los inicios de sesión tengan éxito.

Sigue los pasos en Usar SSMS para conectarte a la base de datos SQL. Después de conectarte usando SSMS, la siguiente consulta devuelve client_net_address que coincide con la dirección IP privada de la máquina virtual de Azure desde la que te conectas:

SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Conectividad local a través del emparejamiento privado

Cuando te conectas al endpoint público desde equipos locales, necesitas añadir tu dirección IP al firewall basado en IP usando una regla de firewall a nivel de servidor. Aunque este modelo funciona bien para permitir el acceso a equipos individuales para las cargas de trabajo de desarrollo o de prueba, es difícil de administrar en los entornos de producción.

Mediante Private Link, puede habilitar el acceso entre entornos locales y la nube al punto de conexión privado mediante ExpressRoute, el emparejamiento privado o la tunelización VPN. A continuación, puede deshabilitar todo el acceso a través del punto de conexión público y no utilizar el firewall basado en IP para permitir ninguna dirección IP.

Los clientes pueden conectarse al punto de conexión privado desde la misma red virtual, una red virtual emparejada en la misma región o mediante una conexión de red virtual a red virtual entre regiones. Además, los clientes pueden conectarse desde las instalaciones locales utilizando ExpressRoute, peering privado o túnel VPN. En el siguiente diagrama simplificado se muestran los casos de uso comunes.

Además, los servicios que no se ejecutan directamente en la red virtual, sino que se integran con ella (por ejemplo, las aplicaciones web de App Service o Functions) también pueden lograr conectividad privada a la base de datos.

Conéctate desde una máquina virtual de Azure en una red virtual emparejada

Configure el emparejamiento de red virtual para establecer la conectividad con SQL Database desde una VM de Azure en una red virtual emparejada.

Conexión desde una VM de Azure en la red virtual a un entorno de red virtual

Configure la conexión de VPN Gateway entre redes virtuales para establecer la conectividad con una base de datos de SQL Database desde una VM de Azure de otra región o suscripción.

Conexión desde un entorno local a través de VPN

Para establecer conectividad desde un entorno local, elige e implementa una de las siguientes opciones:

Considere también escenarios de configuración de DNS, ya que el FQDN del servicio puede resolverse en la dirección IP pública.

Conéctese desde Azure Synapse Analytics a Azure Storage usando PolyBase y la instrucción COPY

Utiliza PolyBase y la instrucción COPY para cargar datos en Azure Synapse Analytics desde cuentas de Azure Storage. Si la cuenta de Azure Storage desde la que carga datos limita el acceso solo a un conjunto de subredes de red virtual mediante puntos de conexión privados, puntos de conexión de servicio o firewalls basados en IP, se interrumpe la conectividad desde PolyBase y la instrucción COPY a la cuenta. Para habilitar los escenarios de importación y exportación con Azure Synapse Analytics conectándose a Azure Storage protegido por una red virtual, consulte Impacto del uso de los puntos de conexión de servicio de red virtual con Azure Storage.

Prevención de la filtración de datos

La exfiltración de datos ocurre cuando un usuario, como un administrador de bases de datos, extrae datos de un sistema y los traslada a otra ubicación o sistema fuera de la organización. Por ejemplo, el usuario mueve los datos a una cuenta de almacenamiento propiedad de una entidad que no sea Microsoft.

Piense en un escenario en el que un usuario ejecuta SQL Server Management Studio (SSMS) dentro de una máquina virtual de Azure que se conecta a una base de datos en SQL Database. Esta base de datos se encuentra en el centro de datos de Oeste de EE. UU. El siguiente ejemplo muestra cómo limitar el acceso con endpoints públicos utilizando controles de acceso a la red.

  1. Desactiva todo el tráfico de servicios de Azure hacia la base de datos SQL a través del endpoint público configurando Permitir servicios Azure en OFF. Asegúrate de que las reglas del firewall a nivel de servidor y base de datos no permitan ninguna dirección IP. Para más información, consulta Azure Synapse Analytics controles de acceso a la red.
  2. Permite tráfico solo a la dirección IP privada de la máquina virtual. Para más información, consulte reglas de cortafuegos de red virtual.
  3. En la máquina virtual de Azure, reduce el alcance de las conexiones salientes utilizando Grupos de Seguridad de Red (NSGs) y Etiquetas de Servicio de la siguiente manera:
    • Especificar una regla NSG para permitir tráfico para Service Tag = SQL.WestUs - solo permitir la conexión a la base de datos SQL en el oeste de EE. UU.
    • Especificar una regla NSG con prioridad mayor para denegar tráfico para Service Tag = Sql - denegando conexiones a la base de datos SQL en todas las regiones.

Al final de esta configuración, la VM de Azure solo puede conectarse a un recurso en la región del oeste de EE. UU. Sin embargo, la conectividad no se limita a una sola base de datos. La máquina virtual aún puede conectarse a cualquier base de datos en la región del oeste de EE. UU., incluidas las bases de datos que no forman parte de la suscripción. Aunque en el escenario anterior reduces el alcance de la exfiltración de datos a una región específica, no la eliminas por completo.

Usando Private Link, puedes configurar controles de acceso a la red como NSGs para restringir el acceso al punto final privado. Puedes asignar recursos PaaS individuales de Azure a puntos finales privados específicos. Un insider malicioso solo puede acceder al recurso PaaS mapeado y a ningún otro recurso.

Contenido relacionado

  • Se actualizó por última vez el