Uso de reglas y puntos de conexión de servicio de red virtual para servidores de Azure SQL Database

Artículo
09/27/2023

Se aplica a: Azure SQL Database Azure Synapse Analytics

Las reglas de red virtual son una característica de seguridad del firewall que controla si el servidor de las bases de datos y de los grupos elásticos de Azure SQL Database o de las bases de datos del grupo de SQL dedicado de Azure Synapse Analytics acepta las comunicaciones que se envían desde subredes específicas de redes virtuales. En este artículo se explica por qué las reglas de redes virtuales a veces son la mejor opción para permitir la comunicación de forma segura con la base de datos de SQL Database y Azure Synapse Analytics.

Nota

Este artículo es aplicable a SQL Database y a Azure Synapse Analytics. Para simplificar, el término base de datos hace referencia a las bases de datos de SQL Database y a las de Azure Synapse Analytics. Del mismo modo, todas las referencias a servidor indican el servidor lógico en el que se hospedan SQL Database y Azure Synapse Analytics.

Para crear una regla de red virtual, primero debe existir un punto de conexión de servicio de red virtual para la regla a la que hacer referencia.

Nota:

Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).

Creación de una regla de red virtual

Si solo desea crear una regla de red virtual, puede ir directamente a los pasos y la explicación que hay más adelante en este artículo.

Detalles sobre las reglas de red virtual

En esta sección se describen varios detalles acerca de las reglas de red virtual.

Solo una región geográfica

Cada punto de conexión de servicio de red virtual es aplicable solo a una región de Azure. El punto de conexión no permite que otras regiones acepten la comunicación de la subred.

Cualquier regla de red virtual se limita a la región a la que se aplica su punto de conexión subyacente.

Nivel de servidor y no de base de datos

Cada regla de red virtual se aplica a todo el servidor y no solo a una base de datos determinada del servidor. En otras palabras, la regla de red virtual se aplica en el nivel de servidor y no en el nivel de base de datos.

En cambio, se pueden aplicar reglas IP en cualquier nivel.

Roles de administración de la seguridad

Existe una separación de los roles de seguridad en la administración de puntos de conexión de servicio de red virtual. Se requiere una acción de cada uno de los roles siguientes:

Administrador de red (rol de Colaborador de red): active el punto de conexión.
Administrador de base de datos (rol de Colaborador de SQL Server): actualice la lista de control de acceso (ACL) para a agregar la subred proporcionada al servidor.

Alternativa a RBAC de Azure

Los roles de administrador de red y de base de datos tienen más funcionalidades de las que se necesitan para administrar las reglas de red virtual. Solo se necesita un subconjunto de sus capacidades.

Si quiere, puede optar por usar el control de acceso basado en rol (RBAC) en Azure para crear un rol personalizado único que tenga solo el subconjunto necesario de funcionalidades. Se podría usar el rol personalizado en lugar del administrador de red o el administrador de la base de datos. El área expuesta de la exposición de seguridad es inferior si agrega un usuario a un rol personalizado, en lugar de agregar el usuario a los otros dos roles de administrador principales.

Nota

En algunos casos, la base de datos de SQL Database y la subred de red virtual se encuentran en suscripciones diferentes. En estos casos debe garantizar las siguientes configuraciones:

Las suscripciones deben estar bajo el mismo inquilino de Microsoft Entra.
El usuario tiene los permisos necesarios para iniciar operaciones como habilitar los puntos de conexión de servicio y agregar una subred de red virtual al servidor especificado.
Las dos suscripciones necesitan tener registrado el proveedor Microsoft.Sql.

Limitaciones

Para SQL Database, la característica de regla de red virtual tiene las siguientes limitaciones:

En el firewall de la base de datos de SQL Database, cada regla de red virtual hace referencia a una subred. Todas estas subredes a las que se hace referencia deben estar hospedadas en la misma región geográfica que hospeda la base de datos.
Cada servidor puede tener hasta 128 entradas de ACL para cualquier red virtual.
Las reglas de red virtual solo se aplican a las redes virtuales de Azure Resource Manager, y no a las redes del modelo de implementación clásica.
La activación de puntos de conexión de servicio de red virtual en SQL Database también habilita los puntos de conexión de Azure DB for MySQL y Azure Database for PostgreSQL. Con los puntos de conexión ACTIVADOS, es posible que se produzca un error al intentar conectarse desde los puntos de conexión con las instancias de Azure Database for MySQL o Azure Database for PostgreSQL.
- El motivo subyacente es que es probable que Azure Database for MySQL y Azure Database for PostgreSQL no tengan una regla de red virtual configurada. Debe configurar una regla de red virtual de Azure Database for MySQL y Azure Database for PostgreSQL.
- Para definir las reglas de firewall de red virtual en un servidor lógico de SQL que ya está configurado con puntos de conexión privados, establezca Deny public network access (Denegar acceso a la red pública) en No.
En el firewall, los intervalos de direcciones IP se aplican a los siguientes elementos de red, pero no las reglas de red virtual:
- Red privada virtual (VPN) de sitio a sitio (S2S)
- En el entorno local mediante Express Route

Consideraciones al usar los puntos de conexión de servicio

Al utilizar los puntos de conexión de servicio para SQL Database, revise las consideraciones siguientes:

Se requiere la salida a direcciones IP públicas de Azure SQL Database. Los grupos de seguridad de red deben estar abiertos en las direcciones IP de SQL Database para permitir la conectividad. Puede hacerlo mediante el uso de etiquetas de servicio de grupos de seguridad de red para SQL Database.

ExpressRoute

Si usa ExpressRoute desde el entorno local para el emparejamiento público o el emparejamiento de Microsoft, tendrá que identificar las direcciones IP de NAT que se usan. Para el emparejamiento público, cada circuito ExpressRoute usa de forma predeterminada dos direcciones IP de NAT que se aplican al tráfico del servicio de Azure cuando el tráfico entra en la red troncal de Microsoft Azure. Para el emparejamiento de Microsoft, las direcciones IP de NAT que se utilizan las proporciona el cliente o el proveedor de servicios. Para permitir el acceso a los recursos de servicio, tiene que permitir estas direcciones IP públicas en la configuración del firewall de IP de recursos. Para encontrar las direcciones de IP de circuito de ExpressRoute de los pares públicos, abra una incidencia de soporte técnico con ExpressRoute a través de Azure Portal. Para más información sobre NAT para el emparejamiento de Microsoft y el emparejamiento público de ExpresRoute, consulte Requisitos de NAT para el emparejamiento público de Azure.

Para permitir la comunicación desde el circuito a SQL Database, necesita crear reglas de red IP para las direcciones IP públicas de NAT.

Efectos del uso de puntos de conexión de servicio de red virtual con Azure Storage

Azure Storage ha implementado la misma característica que permite limitar la conectividad con la cuenta de Azure Storage. Si decide utilizar esta característica con una cuenta de Azure Storage que SQL Database esté usando, es posible que se produzcan errores. A continuación se muestra una lista de las características de SQL Database y Azure Synapse Analytics afectadas por esto.

PolyBase de Azure Synapse Analytics e instrucción COPY

PolyBase y la instrucción COPY se suelen usar para cargar datos en Azure Synapse Analytics desde cuentas de Azure Storage para la ingesta de datos de alto rendimiento. 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, se interrumpirá la conectividad cuando se utilice PolyBase y la instrucción COPY con la cuenta de almacenamiento. Para habilitar los escenarios de importación y exportación mediante COPY y PolyBase con la conexión de Azure Synapse Analytics a una instancia de Azure Storage protegida en una red virtual, siga los pasos que se indican en esta sección.

Requisitos previos

Instale Azure PowerShell. Para más información, consulte Instalación del módulo Azure Az PowerShell.
Si tiene una cuenta de uso general v1 o de Azure Blob Storage, primero debe actualizar a una cuenta de uso general v2 mediante los pasos que se indican en Actualización a una cuenta de almacenamiento de uso general v2.
Debe activar Permitir que los servicios de Microsoft de confianza accedan a esta cuenta de almacenamiento en el menú de configuración Firewalls y redes virtuales de la cuenta de Azure Storage. La habilitación de esta configuración permitirá que PolyBase y la instrucción COPY se conecten a la cuenta de almacenamiento mediante la autenticación sólida en la que el tráfico de red permanece en la red troncal de Azure. Para más información, consulte esta guía.

Importante

El módulo de Azure Resource Manager para PowerShell todavía es compatible con Azure SQL Database, pero todo el desarrollo futuro se realizará para el módulo Az.Sql. El módulo de AzureRM continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Los argumentos para los comandos del módulo Az y los módulos AzureRm son esencialmente idénticos. Para obtener más información sobre la compatibilidad, vea Presentación del nuevo módulo Az de Azure PowerShell.

Pasos

Si tiene un grupo de SQL dedicado independiente (anteriormente SQL DW), registre el servidor SQL Server con Microsoft Entra ID mediante PowerShell:
```
Connect-AzAccount
Select-AzSubscription -SubscriptionId <subscriptionId>
Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
```
Este paso no es necesario para los grupos de SQL dedicados que se encuentran en un área de trabajo de Azure Synapse Analytics. El identidad administrada asignada por el sistema (SA-MI) del área de trabajo es miembro del rol de Administrador de Synapse y, por consiguiente, tiene privilegios elevados en los grupos de SQL dedicados del área de trabajo.
Cree una cuenta de almacenamiento de uso general v2 mediante los pasos que se indican en Crear una cuenta de almacenamiento.
- Si tiene una cuenta de uso general v1 o de Blob Storage, primero debe actualizar a una cuenta de uso general v2 mediante los pasos que se indican en Actualización a una cuenta de almacenamiento de uso general v2.
- Para más información sobre los problemas conocidos con Azure Data Lake Storage Gen2, consulte Problemas conocidos con Azure Data Lake Storage Gen2.
En la página de la cuenta de almacenamiento, seleccione Control de acceso (IAM).
Seleccione Agregar>Agregar asignación de roles para abrir la página Agregar asignación de roles.

Asigne el siguiente rol. Para asignar roles, consulte Asignación de roles de Azure mediante Azure Portal.

Configuración	Valor
Role	Colaborador de datos de blobs de almacenamiento
Asignar acceso a	Usuario, grupo o entidad de servicio
Miembros	Servidor o área de trabajo en la que se hospeda el grupo de SQL dedicado que ha registrado con Microsoft Entra ID

Screenshot that shows Add role assignment page in Azure portal.

Nota:

Solo los miembros con el privilegio Propietario sobre la cuenta de almacenamiento pueden realizar este paso. Para conocer los distintos roles integrados de Azure, consulte Roles integrados de Azure.

Para habilitar la conectividad de PolyBase a la cuenta de Azure Storage:
1. Cree una clave maestra de base de datos si no la ha creado anteriormente.
```
CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];
```
2. Cree una credencial con un ámbito de base de datos con IDENTITY = "Managed Service Identity" .
```
CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
```
  - No es necesario especificar SECRET con una clave de acceso de Azure Storage porque este mecanismo usa la identidad administrada en segundo plano. Este paso no es necesario para los grupos de SQL dedicados que se encuentran en un área de trabajo de Azure Synapse Analytics. El identidad administrada asignada por el sistema (SA-MI) del área de trabajo es miembro del rol de Administrador de Synapse y, por consiguiente, tiene privilegios elevados en los grupos de SQL dedicados del área de trabajo.
  - El nombre de IDENTITY debe ser "Managed Service Identity" para que la conectividad de PolyBase funcione con una cuenta de Azure Storage protegida en una red virtual.
3. Cree un origen de datos externo con el esquema abfss:// para conectarse a la cuenta de almacenamiento de uso general v2 mediante PolyBase.
```
CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
```
  - Si ya tiene tablas externas asociadas con una cuenta de uso general v1 o de Blob Storage, primero debe quitarlas. Después, quite el origen de datos externo correspondiente. A continuación, cree un origen de datos externo con el esquema abfss:// que se conecte a una cuenta de almacenamiento de uso general v2 mediante PolyBase como se ha indicado anteriormente. A continuación, vuelva a crear todas las tablas externas mediante este nuevo origen de datos externo. Puede usar el Asistente para generar y publicar scripts para generar scripts de creación para todas las tablas externas con facilidad.
  - Para más información sobre el esquema abfss://, consulte Uso del URI de Azure Data Lake Storage Gen2.
  - Para obtener información sobre los comandos de T-SQL, consulte CREATE EXTERNAL DATA SOURCE.
4. Realice una consulta normal mediante las tablas externas.

Auditoría de blobs de SQL Database

La auditoría de Azure SQL puede escribir registros de auditoría de SQL en su propia cuenta de almacenamiento. Si esta cuenta de almacenamiento usa la característica de puntos de conexión de servicio de red virtual, consulte cómo escribir una auditoría en una cuenta de almacenamiento situada detrás de la red virtual y un firewall.

Incorporación de una regla de firewall de red virtual al servidor

Mucho antes de mejorar esta característica, era necesario activar los puntos de conexión de servicio de red virtual para poder implementar una regla dinámica de red virtual en el firewall. Los puntos de conexión relacionaban una subred de red virtual determinada con una base de datos de SQL Database. A partir de enero de 2018, puede evitar este requisito si establece la marca IgnoreMissingVNetServiceEndpoint. Ahora, puede agregar una regla de firewall de red virtual al servidor sin activar los puntos de conexión de servicio de red virtual.

Si solo establece una regla de firewall, no tendrá el servidor protegido. También debe activar los puntos de conexión de servicio de red virtual para que la seguridad surta efecto. Cuando activa los puntos de conexión de servicio, la subred de la red virtual experimenta cierto tiempo de inactividad hasta que se completa la transición de desactivado a activado. Este período de inactividad es especialmente significativo en el contexto de redes virtuales de gran tamaño. Puede usar la marca IgnoreMissingVNetServiceEndpoint para reducir o eliminar el tiempo de inactividad durante la activación.

Puede establecer la marca IgnoreMissingVNetServiceEndpoint mediante PowerShell. Para más información, consulte PowerShell para crear una regla y un punto de conexión de servicio de red virtual para SQL Database.

Nota:

Para obtener instrucciones similares en Azure Synapse Analytics, consulte Reglas de firewall de IP de Azure Synapse Analytics

Uso de Azure Portal para crear una regla de red virtual

En esta sección se muestra cómo se puede usar Azure Portal para crear una regla de red virtual en la base de datos de SQL Database. La regla indica a la base de datos que acepte la comunicación procedente de una subred concreta que se ha etiquetado como punto de conexión de servicio de red virtual.

Nota:

Asegúrese de que los puntos de conexión de servicio estén activados para la subred si desea agregar un punto de conexión de servicio a las reglas de firewall de red virtual de su servidor.

Si los puntos de conexión de servicio no están activados para la subred, el portal le pedirá que los habilite. Haga clic en el botón Habilitar del mismo panel en el que agrega la regla.

Requisitos previos

Ya debe tener una subred que esté etiquetada con el nombre de tipo concreto del punto de conexión de servicio de red virtual correspondiente a SQL Database.

El nombre de tipo de punto de conexión pertinente es Microsoft.Sql.
Si es posible que su subred no se pueda etiquetar con el nombre de tipo, consulte Comprobar que su subred es un punto de conexión.

Pasos de Azure Portal

Inicie sesión en Azure Portal.
Busque y seleccione Servidores SQL Server y, después, seleccione el servidor. En Seguridad, seleccione Redes.
En la pestaña Acceso público , asegúrese de que el acceso a la red pública esté establecido en Seleccionar redes; de lo contrario, la configuración de redes virtuales está oculta. En la sección Redes virtuales, seleccione + Agregar red virtual existente.
En el nuevo panel Crear/Actualizar, rellene los cuadros con los nombres de los recursos de Azure.

Sugerencia

Debe incluir el prefijo de dirección correcto de la subred. Puede encontrar el valor Prefijo de dirección en el portal. Vaya a Todos los recursos>Todos los tipos>Redes virtuales. El filtro muestra sus redes virtuales. Seleccione la red virtual y, después, seleccione Subredes. La columna INTERVALO DE DIRECCIONES tiene el prefijo de dirección que necesita.
Consulte la regla de red virtual resultante en el panel Firewall.
Establezca Permitir que los servicios y recursos de Azure accedan a este servidor en No.

Importante

Si deja activado Permitir que los servicios y recursos de Azure accedan a este servidor, el servidor acepta la comunicación desde cualquier subred dentro del límite de Azure. Es decir, las comunicaciones que se originan en una de las direcciones IP que se reconocen como pertenecientes a los intervalos definidos para los centros de datos de Azure. Si deja el control establecido en habilitado, el número de accesos podría ser excesivo desde un punto de vista de seguridad. La característica de punto de conexión de servicio de red virtual de Microsoft Azure, junto con la característica de regla de red virtual de SQL Database, pueden reducir el área expuesta de seguridad.
Seleccione el botón Aceptar situado cerca de la parte inferior del panel.

Nota

Se aplican los siguientes estados a las reglas:

Listo: indica que la operación que se ha iniciado se ha realizado correctamente.
Error: indica que se ha producido un error en la operación que se ha iniciado.
Eliminado: solo se aplica a la operación de eliminación e indica que se ha eliminado la regla y que ya no es aplicable.
InProgress: indica que la operación está en curso. Se aplica la regla anterior mientras la operación está en este estado.

Uso de PowerShell para crear una regla de red virtual

Un script también puede crear reglas de red virtual mediante el cmdlet de PowerShell New-AzSqlServerVirtualNetworkRule o az network vnet create. Para más información, consulte PowerShell para crear una regla y un punto de conexión de servicio de red virtual para SQL Database.

Uso de API REST para crear una regla de red virtual

Internamente, los cmdlets de PowerShell para acciones de red virtual de SQL llaman a las API REST. Puede llamar directamente a las API REST. Para más información, consulte Reglas de red virtual: operaciones.

Solución de los errores 40914 y 40615

El error de conexión 40914 se relaciona con reglas de red virtual, tal y como se especifica en el panel Firewall de Azure Portal. El error 40615 es similar, excepto en que se relaciona con las reglas de direcciones IP del firewall.

Error 40914

Texto del mensaje: "No se puede abrir el servidor [server-name] solicitado por el inicio de sesión. Un cliente no puede acceder al servidor."

Descripción del error: el cliente está en una subred que tiene puntos de conexión de servidor de red virtual. Aun así, el servidor tiene ninguna regla de red virtual que conceda a la subred el derecho para comunicarse con la base de datos.

Resolución de errores: en el panel Firewall de Azure Portal, use el control de reglas de red virtual para agregar una regla de red virtual para la subred.

Error 40615

Texto del mensaje: "No se puede abrir el servidor {0} solicitado por el inicio de sesión. El cliente con la dirección IP {1} no tiene permiso para acceder al servidor".

Descripción del error: el cliente intenta conectarse desde una dirección IP que no tiene autorización para conectarse al servidor. El firewall de servidor no tiene ninguna regla de dirección IP que permita que un cliente se comunique con la dirección IP dada a la base de datos.

Resolución de errores: escriba la dirección IP del cliente como una regla de IP. Use el panel Firewall de Azure Portal para realizar este paso.

Uso de reglas y puntos de conexión de servicio de red virtual para servidores de Azure SQL Database

Creación de una regla de red virtual