Implementar aislamiento de red
Contoso Financial Services ejecuta Azure SQL Database para el procesamiento de transacciones y SQL Managed Instance para la evaluación del riesgo de crédito. Ambos servicios exponen actualmente puntos de conexión públicos a Internet. El servicio de detección de fraudes de IA y las aplicaciones bancarias internas se ejecutan en Azure redes virtuales (VNet) y los sistemas bancarios locales se conectan a través de ExpressRoute. El equipo de seguridad debe eliminar la exposición pública a Internet al tiempo que mantiene el acceso a las cargas de trabajo hospedadas en Azure y los sistemas locales.
| Estrategia de implementación | Caso de uso |
|---|---|
| Puntos de conexión privados y deshabilitación del acceso público | Servicios financieros, cargas de trabajo reguladas que no requieren exposición a puntos de conexión públicos |
| Puntos de conexión de servicio de red virtual y reglas de firewall | Entornos de desarrollo en los que el punto de conexión público es aceptable con acceso restringido |
Configuración de puntos de conexión privados para Azure SQL Database
Los puntos de conexión privados llevan Azure SQL Database al espacio de direcciones de la red virtual, lo que elimina la necesidad de acceso al punto de conexión público. Al implementar un punto de conexión privado, Azure crea una interfaz de red con una dirección IP privada desde la subred y la asigna al nombre de dominio completo (FQDN) de SQL Server.
Para la base de datos de procesamiento de transacciones de Contoso, se crea un punto de conexión privado en la red virtual donde se ejecuta la inteligencia artificial de detección de fraudes. En el portal de Azure, vaya a SQL Server, seleccione Security>Networking y elija Private access. Al agregar un punto de conexión privado, especifique la subred de destino y habilite la integración automática de la zona DNS privada. Azure crea el privatelink.database.windows.net zona DNS y agrega un registro que asigna el nombre del servidor a la dirección IP privada.
La directiva de conexión determina cómo fluye el tráfico después de implementar un punto de conexión privado. La directiva de proxy enruta todo el tráfico a través del puerto 1433 y es la opción más sencilla para las implementaciones de puntos de conexión privados; no requiere cambios adicionales del firewall y funciona con puntos de conexión privados existentes que usan la directiva predeterminada. La directiva de redirección proporciona una menor latencia estableciendo una conexión directa al nodo de base de datos, pero requiere que los clientes abran los puertos 1433 a 65535 para la comunicación entrante y saliente en la red virtual que hospeda el punto de conexión privado.
Note
Los puntos de conexión privados existentes que usan la directiva de conexión predeterminada se reservan al modo proxy (solo el puerto 1433) para evitar interrumpir el tráfico del cliente. Para usar el redireccionamiento con un punto de conexión privado, establezca explícitamente la directiva de conexión en Redireccionamiento después de aprovisionar el punto de conexión; puede ser necesario alternar la directiva si se estableció antes de crear el punto de conexión privado.
Para el servicio de detección de fraudes de IA de Contoso que se ejecuta en Azure, el modo proxy en el punto de conexión privado proporciona conectividad segura con una configuración sencilla del firewall. El modo de redirección se puede habilitar más adelante si los requisitos de latencia lo exigen.
Note
La creación de puntos de conexión privados requiere aprobación del administrador de SQL. Después de que el administrador de red cree el punto de conexión, el administrador de SQL debe aprobar la conexión en la lista Conexiones de punto de conexión privado de SQL Server antes de que se active.
Deshabilitación del acceso a la red pública
Después de implementar un punto de conexión privado, deshabilite el punto de conexión público para completar el aislamiento. El punto de conexión privado por sí solo no impide el acceso público: ambos puntos de conexión permanecen activos hasta que se deshabilita explícitamente el acceso a la red pública.
Vaya a la página Redes de SQL Server y seleccione Deshabilitar acceso> público. Esta acción bloquea todas las conexiones de Internet, incluso si las reglas de firewall permiten direcciones IP específicas. La configuración "Permitir que los servicios y recursos de Azure accedan a este servidor", que crea una regla especial para los intervalos IP internos de Azure (0.0.0.0-0.0.0.0), ya no se aplica porque el punto de conexión público está desactivado.
Con el acceso público deshabilitado, los sistemas bancarios locales de Contoso se conectan a través del emparejamiento privado de ExpressRoute. El tráfico se enruta desde la red local a través de ExpressRoute a la red virtual Azure donde existe el punto de conexión privado y, a continuación, al servidor SQL Server. Esta ruta de acceso mantiene todo el tráfico de base de datos en la red troncal privada de Microsoft.
Los cambios en las reglas de firewall pueden tardar hasta cinco minutos en propagarse a través de la infraestructura de Azure. Si necesita un efecto inmediato después de modificar las reglas, conéctese a la base de datos y ejecute el siguiente comando:
DBCC FLUSHAUTHCACHE
Este comando borra la caché de autenticación y obliga al servidor a volver a cargar las reglas de firewall inmediatamente.
Aplicar aislamiento de red a SQL Managed Instance
SQL Managed Instance adopta un enfoque diferente al aislamiento de red porque la implementación está directamente dentro de una red virtual desde el inicio. A diferencia de Azure SQL Database, SQL MI no requiere un punto de conexión privado, ya es nativo de red virtual.
Cuando Contoso implementó SQL MI para la evaluación del riesgo de crédito, asignaron una subred dedicada y la delegaron en Microsoft.Sql/managedInstances. Esta delegación concede al servicio MI de SQL permiso para administrar recursos de red en esa subred. La instancia recibe una dirección IP privada y solo es accesible desde dentro de la red virtual o a través de redes conectadas, como redes virtuales emparejadas o redes locales vinculadas a través de ExpressRoute o VPN.
SQL MI ofrece un punto de conexión público opcional en el puerto 3342, pero está deshabilitado de forma predeterminada. Para el entorno regulado de Contoso, mantenga deshabilitado este punto de conexión. Si se necesita acceso entre redes virtuales, utilice el emparejamiento de redes virtuales en lugar de habilitar el punto de conexión público. El emparejamiento de redes virtuales mantiene la conectividad privada, al tiempo que permite que la inteligencia artificial de detección de fraudes de una red virtual consulte la base de datos de riesgo de crédito en otra red virtual donde reside SQL MI.
La diferencia clave: Azure SQL Database requiere que agregue puntos de conexión privados y deshabilite el acceso público como pasos independientes, mientras que SQL Managed Instance comienza con la conectividad solo privada integrada.
Comprobación del aislamiento completo
Después de implementar el aislamiento de red, confirme que el acceso externo está bloqueado y las redes autorizadas se conectan correctamente. Desde una red externa fuera de Azure, intente conectarse a su servidor SQL Server mediante su FQDN. La conexión debería expirar porque no existe una ruta pública.
Desde el servicio de inteligencia artificial de detección de fraudes que se ejecuta en la red virtual con el punto de conexión privado, pruebe la conectividad mediante el mismo FQDN:
sqlcmd -S contoso-transactions.database.windows.net -U sqladmin -P <password> -Q "SELECT @@VERSION"
La conexión se realiza correctamente porque DNS resuelve el FQDN en la dirección IP privada y la red virtual enruta el tráfico directamente a la base de datos. En el caso de los sistemas bancarios locales, compruebe la conectividad a través de ExpressRoute mediante la ejecución de la misma prueba desde una estación de trabajo local.
El aislamiento de red y la protección de la autenticación funcionan juntos para crear una posición de seguridad completa. Eliminar los puntos de conexión públicos bloquea las redes no autorizadas, mientras que la autenticación de Microsoft Entra y el control de acceso basado en roles determinan qué identidades pueden conectarse desde redes autorizadas. Ambos controles deben estar en vigor para cumplir los requisitos de seguridad de Contoso.