Azure Private Link para Azure SQL Database y Azure Synapse Analytics
Se aplica a:
Azure SQL DatabaseAzure Synapse Analytics (solo grupos de SQL dedicados)
Private Link permite conectarse a varios servicios PaaS en Azure mediante un punto de conexión privado. Para obtener una lista de los servicios PaaS que admiten la funcionalidad Private Link, vaya a la página de la documentación de Private Link. Un punto de conexión privado es una dirección IP privada dentro de una red virtual y una subred específicas.
Importante
Este artículo se aplica tanto a Azure SQL Database como al grupo de SQL dedicado (antes SQL DW) en Azure Synapse Analytics. Estos valores se aplican a todas las bases de datos de SQL Database y de grupo de SQL dedicado (anteriormente, SQL DW) asociadas al servidor. Para simplificar, el término "base de datos" hace referencia a las bases de datos de Azure SQL Database y a las de Azure Synapse Analytics. Del mismo modo, todas las referencias a "servidor" indican el servidor lógico que hospeda Azure SQL Database y el grupo de SQL dedicado (anteriormente SQL DW) en Azure Synapse Analytics. Este artículo no se aplica a Azure SQL Managed Instance o a grupos de SQL dedicados de áreas de trabajo de Azure Synapse Analytics.
Configuración de Private Link
Proceso de creación
Los puntos de conexión privados se pueden crear mediante Azure Portal, PowerShell o la CLI de Azure:
Proceso de aprobación
Una vez que el administrador de red crea el punto de conexión privado (PE), el administrador de SQL puede administrar la conexión de punto de conexión privado (PEC) a la base de datos SQL.
Vaya al recurso de servidor en Azure Portal.
Vaya a la página de aprobación del punto de conexión privado:
- En Azure SQL Database, en Seguridad en el menú de recursos, seleccione Redes. Seleccione la pestaña Acceso privado.
- En el área de trabajo de Synapse, en Seguridad en el menú de recursos, seleccione Conexiones de punto de conexión privado.
En la página se muestra lo siguiente:
- Una lista de todas las conexiones de punto de conexión privado (PEC)
- Punto de conexión privados (PE) creados
Si no hay puntos de conexión privados, cree uno mediante el botón Crear un punto de conexión privado. De lo contrario, seleccione una conexión de punto de conexión privado en la lista.
El administrador de SQL puede elegir aprobar o rechazar cualquier conexión de punto de conexión privado y, además, tiene la opción de agregar una respuesta con un texto breve.
Después de la aprobación o el rechazo, la lista reflejará el estado apropiado, junto con el texto de respuesta.
Por último, seleccione el nombre del punto de conexión privado
Esto le lleva a la página de información general Punto de conexión privado. Seleccione el vínculo Interfaces de red para obtener los detalles de la interfaz de red de la conexión de 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.
Importante
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 el servidor SQL lógico de Azure SQL Database, suponga que quiere deshabilitar todo el acceso público al servidor lógico y permitir solo las conexiones desde la 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:
Vaya a la página Redes del servidor lógico.
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
En este escenario, suponga que ha creado una máquina virtual de Azure que ejecuta una versión reciente de Windows en la misma red virtual que el punto de conexión privado.
Inicie una sesión de Escritorio remoto (RDP) y conéctese a la máquina virtual.
Después, puede realizar algunas comprobaciones de conectividad básicas para asegurarse de que la máquina virtual se conecta a SQL Database a través del punto de conexión privado. Para ello, utilice estas herramientas:
- Telnet
- PsPing
- Nmap
- SQL Server Management Studio (SSMS)
Comprobación de la conectividad mediante Telnet
El cliente Telnet es una característica de Windows que se puede usar para probar la conectividad. En función de la versión del sistema operativo Windows, es posible que tenga que habilitar esta característica de forma explícita.
Tras instalar Telnet, abra una ventana del símbolo del sistema. 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, muestra una pantalla en blanco en la ventana de comandos, como se muestra en la siguiente imagen:
Uso del comando de PowerShell para comprobar la conectividad:
Test-NetConnection -computer myserver.database.windows.net -port 1433
Comprobación de la conectividad mediante PsPing
Se puede usar PsPing como se indica a continuación para comprobar que el punto de conexión privado escucha conexiones en el puerto 1433.
Ejecute PsPing como se indica a continuación y proporcione el nombre de dominio completo del servidor SQL lógico y el puerto 1433:
PsPing.exe mysqldbsrvr.database.windows.net:1433
Este es un ejemplo de 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 ha podido hacer ping a la dirección IP privada asociada al punto de conexión privado.
Comprobación de la conectividad mediante Nmap
Nmap (asignador de red) es una herramienta gratuita de código abierto que se usa para la detección de redes y las auditorías de seguridad. Para más información y para obtener el vínculo de descarga, visite https://Nmap.org. Esta herramienta se puede usar para asegurarse de que el punto de conexión privado escucha conexiones en el puerto 1433.
Ejecute Nmap como se indica a continuación y proporcione el intervalo de direcciones de la subred en la que se hospeda el punto de conexión privado.
Nmap -n -sP 10.9.0.0/24
Este es un ejemplo de 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, la cual corresponde a la dirección IP del punto de conexión privado.
Comprobación de la conectividad mediante SQL Server Management Studio (SSMS)
Nota:
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 con el nombre de dominio completo del vínculo privado (<server>.privatelink.database.windows.net) generará un error. Este comportamiento es así por diseño, ya que el punto de conexión privado enruta el tráfico a la puerta de enlace de SQL de la región y es preciso especificar el nombre de dominio completo correcto para que los inicios de sesión se realicen correctamente.
Siga los pasos para usar SSMS para conectarse a SQL Database. Después de conectarse a SQL Database mediante SSMS, la consulta siguiente reflejará el valor de client_net_address que coincide con la dirección IP privada de la máquina virtual de Azure desde la que se conecta:
SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Uso de la directiva de conexión de redirección con puntos de conexión privados
Se recomienda que los clientes usen el vínculo privado con la directiva de conexión de redireccionamiento para reducir la latencia y mejorar el rendimiento. Para que las conexiones usen este modo, los clientes deben cumplir los siguientes requisitos previos:
Permitir la comunicación entrante a la VNET que aloja el punto de conexión privado al rango de puertos del 1433 al 65535.
Permitir la comunicación saliente desde la VNET que aloja el cliente al rango de puertos del 1433 al 65535.
Use la última versión de los controladores que tienen la compatibilidad con el redireccionamiento integrada. La compatibilidad con el redireccionamiento se incluye en los controladores ODBC, OLEDB, NET SqlClient Data Provider, Core .NET SqlClient Data Provider y JDBC (versión 9.4 o superior). Las conexiones que se originan en todos los demás controladores reciben proxy.
Después de cumplir los requisitos previos, los clientes deben elegir de forma explcita la directiva de conexión de redireccionamiento.
Si no es factible modificar la configuración del firewall para permitir el acceso saliente en el rango de puertos 1433-65535; una solución alternativa es cambiar la directiva de conexión a Proxy.
Los puntos de conexión privados existentes que usan la directiva de conexión predeterminada deben estar en proxy, es decir, usarán la directiva de conexión de proxy con el puerto 1433. El motivo de esto es evitar que se produzca ninguna interrupción en el tráfico del cliente para llegar a Sql Database debido a que los intervalos de puertos necesarios para el redireccionamiento no están abiertos.
Conectividad local a través del emparejamiento privado
Cuando los clientes se conectan al punto de conexión público desde equipos locales, es necesario agregar su dirección IP al firewall basado en IP mediante una regla de firewall de 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.
Con Private Link, los clientes pueden habilitar el acceso entre locales al punto de conexión privado mediante ExpressRoute, el emparejamiento privado o la tunelización de VPN. Luego, los clientes pueden deshabilitar todo el acceso a través del punto de conexión público y no usar el firewall basado en IP para permitir direcciones IP.
Casos de uso de Private Link para Azure SQL Database
Los clientes pueden conectarse al punto de conexión privado desde la misma red virtual, desde una red virtual emparejada de la misma región o a través de una conexión entre redes virtuales entre regiones. Además, los clientes pueden conectarse de forma local mediante ExpressRoute, emparejamiento privado o tunelización de 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. Para más información sobre este caso de uso específico, consulte el escenario de arquitectura Conectividad privada de una aplicación web a Azure SQL Database.
Conexión 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 la conectividad desde un entorno local a una base de datos de SQL Database, elija e implemente 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.
Conexión desde Azure Synapse Analytics a Azure Storage mediante Polybase y la instrucción COPY
PolyBase y la instrucción COPY se suelen usar para cargar datos en Azure Synapse Analytics desde cuentas de Azure Storage. Si la cuenta de Azure Storage desde la que se cargan los datos limita el acceso a solo 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 interrumpirá la conectividad entre PolyBase y la instrucción COPY a la cuenta. Para habilitar los escenarios de importación y exportación con la conexión de Azure Synapse Analytics a Azure Storage protegido para una red virtual, siga los pasos que se indican aquí.
Prevención de la filtración de datos
La filtración de datos en Azure SQL Database tiene lugar cuando un usuario, como un administrador de base de datos, puede extraer datos de un sistema y moverlos a una ubicación o sistema que está fuera de la organización. Por ejemplo, el usuario mueve los datos a una cuenta de almacenamiento propiedad de un tercero.
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. En el ejemplo siguiente se muestra cómo limitar el acceso con puntos de conexión públicos en SQL Database mediante controles de acceso de red.
- Deshabilite todo el tráfico de los servicios de Azure a la base de datos SQL mediante el punto de conexión público, para lo que debe seleccionar OFF (Desactivado) en Allow Azure Services (Permitir servicios de Azure). Asegúrese de que no se permiten direcciones IP en el servidor y en las reglas de firewall en el nivel de base de datos. Para más información, consulte Controles de acceso a la red de Azure SQL Database y Azure Synapse Analytics.
- Solo se permite el tráfico a la base de datos de SQL Database mediante la dirección IP privada de la VM. Para más información, consulte los artículos sobre el punto de conexión de servicio y las reglas de firewall de la red virtual.
- En la VM de Azure, restrinja el ámbito de la conexión saliente mediante el uso de grupos de seguridad de red (NSG) y etiquetas de servicio, como se indica a continuación.
- Especifique una regla de NSG para permitir el tráfico en Service Tag = SQL.WestUs (solo se permite la conexión a una base de datos SQL en Oeste de EE. UU.).
- Especifique una regla de NSG (con una prioridad mayor) para denegar el tráfico a Service Tag = SQL (se deniegan las conexiones a una base de datos SQL en todas las regiones).
Al final de esta configuración, la VM de Azure solo puede conectarse a una base de datos de SQL Database de la región Oeste de EE. UU. Sin embargo, la conectividad no está restringida a una sola base de datos en SQL Database. La VM puede conectarse a cualquier base de datos de la región Oeste de EE. UU., incluidas las bases de datos que no forman parte de la suscripción. Aunque en el escenario anterior se ha reducido el ámbito de la filtración de datos a una región concreta, no se ha eliminado por completo.
Con Private Link, los clientes pueden configurar controles de acceso a la red como grupos de seguridad de red para restringir el acceso al punto de conexión privado. Los recursos PaaS de Azure individuales se asignan a puntos de conexión privados concretos. Un usuario interno malintencionado solo puede acceder al recurso PaaS asignado (por ejemplo, una base de datos en SQL Database), pero no a los demás recursos.
Contenido relacionado
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de