Azure Private Link para Azure SQL Database y Azure Synapse Analytics
SE APLICA A:
Azure SQL Database Azure Synapse Analytics (solo grupo de SQL dedicado [anteriormente SQL DW])
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 según los pasos que se muestran en la captura de pantalla siguiente.
- (1) Seleccione las conexiones del punto de conexión privado en el panel izquierdo
- (2) Muestra una lista de todas las conexiones del punto de conexión privado (PEC)
- (3) Punto de conexión privado (PE) correspondiente creado
Seleccione una conexión del 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, al hacer clic en el nombre del punto de conexión privado
conduce a los detalles de la interfaz de red
que, por último, conduce a la dirección IP del punto de conexión privado.
Importante
Cuando agregue una conexión de punto de conexión privado, el enrutamiento público al servidor lógico de Azure SQL no se bloqueará de forma predeterminada. En el panel Firewall y redes virtuales, la opción Denegar acceso a la red pública no está seleccionada de forma predeterminada. Para deshabilitar el acceso a la red pública, asegúrese de seleccionar Denegar acceso a la red pública.
Deshabilitación del acceso público al servidor lógico de Azure SQL
Para este escenario, supongamos que quiere deshabilitar todo el acceso público al servidor lógico de Azure SQL y permitir solo las conexiones desde su 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 al panel Firewalls y redes virtuales del servidor lógico de Azure SQL.
- 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 de Telnet y especifique la dirección IP y el punto de conexión privado de la base de datos SQL Database.
>telnet 10.9.0.4 1433
Cuando Telnet se conecte correctamente, verá una pantalla en blanco en la ventana de comandos como la de 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 especifique el nombre de dominio completo del servidor SQL lógico y el puerto 1433:
>psping.exe mysqldbsrvr.database.windows.net:1433
...
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 pudo 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 especifique el intervalo de direcciones de la subred que hospeda el punto de conexión privado.
>nmap -n -sP 10.9.0.0/24
...
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 coincida 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
Limitaciones
Las conexiones a un punto de conexión privado solo admitenProxy como directiva de conexión
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. A continuación, puede ver un diagrama simplificado que muestra los casos de uso habituales.
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 con 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 VM 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 y 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 la base de datos SQL mediante controles de acceso a la 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 máquina virtual 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.
Pasos siguientes
- Para obtener información general sobre la seguridad de Azure SQL Database, vea Protección de bases de datos SQL.
- Para obtener información general sobre la conectividad de Azure SQL Database, consulte Arquitectura de conectividad de Azure SQL
- Puede que también le interese el escenario de arquitectura Conectividad privada de una aplicación web a Azure SQL Database, que conecta una aplicación web situada fuera de la red virtual con el punto de conexión privado de una base de datos.