Utiliza endpoints y reglas de servicios de red virtual para Azure Synapse Analytics

Se aplica a: grupos de SQL dedicados de Azure Synapse Analytics

Las reglas de red virtual son una función de seguridad de cortafuegos que controla si el servidor lógico de tu pool SQL dedicado (anteriormente SQL DW) en Azure Synapse Analytics acepta comunicaciones enviadas desde subredes particulares en redes virtuales. Este artículo explica por qué las reglas de red virtual a veces son la mejor opción para permitir la comunicación segura con tu pool SQL dedicado.

Para crear una regla de red virtual, primero debe haber un punto final de servicio de red virtual al que la regla pueda hacer referencia.

Creación de una regla de red virtual

Si solo quieres crear una regla de red virtual, puedes saltar a los pasos y explicaciones más adelante en este artículo.

Detalles sobre las reglas de red virtual

Esta sección describe varios detalles sobre las reglas de red virtual.

Solo una región geográfica

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

Cualquier regla de red virtual está limitada a la región a la que se aplica su punto final subyacente.

A nivel de servidor, no a nivel de base de datos

Cada regla de red virtual se aplica a todo tu servidor, no solo a una base de datos concreta en el servidor. En otras palabras, las reglas de red virtual se aplican a nivel de servidor, no a nivel de base de datos.

Roles de administración de la seguridad

Hay una separación de roles de seguridad en la administración de los endpoints de servicios de red virtual. Se requiere acción de cada uno de los siguientes roles:

• Administrador de red (rol de Colaborador de Red ): Activa el endpoint.
• Administrador de bases de datos (rol de colaborador de SQL Server): Actualizar la lista de control de acceso (ACL) para añadir la subred dada al servidor.

Alternativa a Azure RBAC

Los roles de Administrador de Red y Administrador de Bases de Datos tienen más capacidades de las necesarias para gestionar las reglas de red virtual. Solo se necesita un subconjunto de sus capacidades.

Tienes la opción de usar el control de acceso basado en roles (RBAC) en Azure para crear un único rol personalizado que solo tenga el subconjunto necesario de capacidades. El rol personalizado podría usarse en lugar de involucrar al Administrador de Red o al Administrador de Bases de Datos. La superficie de tu exposición a la seguridad es menor si añades un usuario a un rol personalizado en comparación con añadir al usuario a los otros dos roles principales de administrador.

Limitations

En los grupos de SQL dedicados independientes, la característica de reglas de red virtual tiene las siguientes limitaciones:

• En el cortafuegos de tu servidor lógico, cada regla de red virtual hace referencia a una subred. Todas las subredes referenciadas deben estar alojadas en la misma región geográfica que el pool dedicado de SQL.
• Cada servidor puede tener hasta 128 entradas ACL para cualquier red virtual.
• Las reglas de red virtual se aplican solo a redes virtuales de Azure Resource Manager y no a redes del modelo de implementación clásico.
• En el cortafuegos, los rangos de direcciones IP sí se aplican a los siguientes elementos de red, pero las reglas de red virtual no:
  • Red privada virtual (VPN) sitio a sitio (S2S)
  • En el entorno local mediante Express Route
• Ambas suscripciones deben estar en el mismo tenant de Microsoft Entra.

Consideraciones al utilizar endpoints de servicio

Cuando utilices endpoints de servicio para un pool SQL dedicado, revisa la siguiente consideración:

• Se requiere acceso saliente a IPs públicas de Azure Synapse Analytics. Los grupos de seguridad de red (NSGs) deben permitir la conectividad a las IPs de servicio. Puedes usar la Sqletiqueta de servicio NSG.

ExpressRoute

Si usas ExpressRoute desde tus instalaciones, para peering público o peering de Microsoft, tendrás que identificar las direcciones IP NAT que se usan. Para el emparejamiento público, cada circuito ExpressRoute utiliza por defecto dos direcciones IP NAT aplicadas al tráfico de servicio de Azure cuando el tráfico entra en la red troncal de Microsoft Azure. Para el peering de Microsoft, las direcciones IP NAT utilizadas las proporciona el cliente o el proveedor del servicio. 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 IP de tu circuito público de peering ExpressRoute, abre un ticket de soporte con ExpressRoute a través del portal de Azure. Para saber más sobre NAT para el emparejamiento público y de Microsoft de ExpressRoute, consulta los requisitos de NAT para el emparejamiento público de Azure.

Para permitir la comunicación desde tu circuito a Azure Synapse Analytics, debes crear reglas de red IP para las direcciones IP públicas de tu NAT.

Impacto de usar puntos finales de servicios 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 utiliza esta característica con una cuenta de Azure Storage que utilice Azure Synapse Analytics, puede encontrar problemas.

Las siguientes secciones analizan las funciones afectadas de Azure Synapse Analytics.

Azure Synapse Analytics PolyBase y la instrucción COPY

PolyBase y la instrucción COPY se utilizan comúnmente 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 escenarios de importación y exportación usando COPY y PolyBase, con Azure Synapse Analytics conectándose a Azure Storage que está asegurado en una red virtual, sigue los pasos de esta sección.

Prerequisites

• Instale Azure PowerShell. Para más información, consulte Instalación del módulo Azure Az PowerShell.
• Si tienes una cuenta de uso general v1 o Azure Blob Storage, primero debes actualizar a v2 de propósito general siguiendo los pasos de Actualizar a una cuenta de almacenamiento de propósito general v2.
• Debes tener activada la opción Permitir que los servicios de confianza de Microsoft 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, consulta esta guía.

Steps

1. Si tienes un pool SQL dedicado independiente (anteriormente SQL DW), registra tu servidor SQL con Microsoft Entra ID usando 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 pools SQL dedicados dentro de un espacio 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.

2. Crea una cuenta de almacenamiento v2 de propósito general siguiendo los pasos en Crear una cuenta de almacenamiento.

   • Si tienes una cuenta de uso general v1 o Blob Storage, primero debes actualizar a v2 siguiendo los pasos de Actualizar a una cuenta de almacenamiento de uso general v2.
   • Para problemas conocidos con Azure Data Lake Storage Gen2, véase Problemas conocidos con Azure Data Lake Storage Gen2.

3. En la página de tu cuenta de almacenamiento, selecciona Control de acceso (IAM).

4. Seleccione Agregar>Agregar asignación de roles para abrir la página Agregar asignación de roles.

5. Asigne el siguiente rol. Para ver los pasos detallados, consulte Asignación de roles de Azure mediante Azure Portal.

   Setting	Value
   Rol	Colaborador de datos de Storage Blob
   Asignar acceso a	Usuario, grupo o entidad de servicio
   Members	Servidor o espacio de trabajo que aloja tu pool SQL dedicado que hayas registrado con Microsoft Entra ID

   

   Note

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

6. Para habilitar la conectividad de PolyBase a la cuenta de Azure Storage:

   1. Crea una clave maestra de base de datos si no has creado una antes.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = '<password>'];
      

   2. Crear una credencial con alcance 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 utiliza Managed Identity de forma transparente. Este paso no es necesario para los pools SQL dedicados dentro de un espacio 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 IDENTITY debe ser 'Managed Service Identity' para que la conectividad de PolyBase funcione con una cuenta de Azure Storage asegurada a 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 tienes tablas externas asociadas a una cuenta v1 o Blob Storage de propósito general, primero deberías eliminar esas tablas externas. Luego elimina la fuente de datos externa correspondiente. A continuación, crea una fuente de datos externa con el abfss:// esquema que se conecta a una cuenta de almacenamiento v2 de propósito general, como se mostró anteriormente. Luego recrea todas las tablas externas usando esta nueva fuente de datos externa. Podrías usar el Generate and Publish Scripts Wizard para generar scripts de creación para todas las tablas externas y así facilitarlo.
      • Para más información sobre el abfss:// esquema, consulte Use el URI de Azure Data Lake Storage Gen2.
      • Para más información sobre los comandos T-SQL, véase CREATE EXTERNAL DATA SOURCE.

   4. Consulta normalmente usando tablas externas.

Auditoría de Azure Synapse Analytics en el almacenamiento de blobs

Azure Synapse Analytics Auditing puede escribir registros de auditoría SQL en tu 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.

Agregar una regla de firewall de red virtual al servidor SQL del grupo de SQL dedicado

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 relacionan una subred de red virtual determinada con un grupo de SQL dedicado. A enero de 2018, puedes eludir este requisito configurando la bandera IgnoreMissingVNetServiceEndpoint . Ahora, puedes añadir una regla de cortafuegos de red virtual a tu servidor sin activar los endpoints de servicios de red virtual.

Simplemente establecer una regla de firewall no ayuda a proteger el servidor. También debes activar los endpoints de servicios de red virtual para que la seguridad surta efecto. Cuando activas los endpoints de servicio, tu subred de red virtual experimenta inactividad hasta completar la transición de apagado a activado. Este periodo de inactividad es especialmente aplicable en el contexto de grandes redes virtuales. Puedes usar la bandera IgnoreMissingVNetServiceEndpoint para reducir o eliminar el tiempo de inactividad durante la transición.

Puedes configurar el IgnoreMissingVNetServiceEndpoint indicador usando PowerShell. Para más información, consulte New-AzSqlServerVirtualNetworkRule.

Utiliza el portal de Azure para crear una regla de red virtual

En esta sección, aprende cómo puedes usar el portal de Azure para crear una regla de red virtual para un pool SQL dedicado independiente. La regla indica al servidor lógico que acepte comunicación de una subred concreta que ha sido etiquetada como un punto final de servicio de red virtual.

Prerequisites

Ya debe tener una subred etiquetada con el nombre de tipo del punto de conexión de servicio de red virtual que utiliza Azure Synapse Analytics.

• El nombre relevante del tipo de endpoint es Microsoft.Sql.
• Si tu subred puede no estar etiquetada con el nombre del tipo, consulta Verificar que el endpoint del servicio esté habilitado.

Pasos de Azure Portal

1. Inicie sesión en Azure Portal.

2. Busca y selecciona servidores SQL, y luego selecciona tu servidor. En Seguridad, seleccione Redes.

3. En la pestaña de acceso público , asegúrate de que el acceso a redes públicas esté configurado para seleccionar redes, de lo contrario la configuración de redes virtuales queda oculta. Seleccionar + Añadir red virtual existente en la sección de redes virtuales .

4. En el nuevo panel Crear/Actualizar, rellena los cuadros con los nombres de tus recursos de Azure.

   Tip

   Debes incluir el prefijo de dirección correcto para tu subred. Puede encontrar el valor Prefijo de dirección en el portal. Ir a Todos los recursos>Todos los tipos>Redes virtuales. El filtro muestra tus redes virtuales. Selecciona tu red virtual y luego selecciona Subredes. La columna RANGO DE DIRECCIONES tiene el prefijo de dirección que necesitas.

5. Consulta la regla de red virtual resultante en el panel Firewall.

6. Configura Permitir que los servicios y recursos de Azure accedan a este servidor como No.

   Important

   Si dejas activado Permitir que los servicios y recursos de Azure accedan a este servidor, tu servidor acepta 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. Dejar el control activado podría otorgar un acceso excesivo desde el punto de vista de la seguridad. La característica de puntos de conexión del servicio Microsoft Azure Virtual Network, junto con las reglas de red virtual de Azure Synapse Analytics, puede reducir su superficie de ataque de seguridad.

7. Selecciona el botón OK cerca de la parte inferior del panel.

Utiliza PowerShell para crear una regla de red virtual

Un script también puede crear reglas de red virtual usando el cmdlet New-AzSqlServerVirtualNetworkRule de PowerShell o az network vnet create. Para más información, consulte New-AzSqlServerVirtualNetworkRule.

Utiliza la API REST para crear una regla de red virtual

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

Solucionar errores 40914 y 40615

El error de conexión 40914 se refiere a las reglas de red virtual, tal como se especifica en el panel Firewall del portal de Azure.
El error 40615 es similar, salvo que se refiere a las reglas de dirección IP en el cortafuegos.

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 servicio de red virtual. Pero el servidor no tiene una regla de red virtual que conceda a la subred el derecho a comunicarse con la base de datos.

Resolución de errores: En el panel Firewall del portal de Azure, utiliza el control de reglas de red virtual para añadir 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 está intentando conectarse desde una dirección IP que no está autorizada para conectarse al servidor. El cortafuegos del servidor no tiene una regla de dirección IP que permita a un cliente comunicarse con la base de datos desde la dirección IP indicada.

Resolución de errores: Introduce la dirección IP del cliente como regla de IP. Usa el panel Firewall en el portal de Azure para hacer este paso.

Contenido relacionado

• Punto de conexión de servicio de red virtual de Azure
• Reglas de firewall IP de Azure Synapse
• Use New-AzSqlServerVirtualNetworkRule para crear una regla de red virtual
• Reglas de red virtual: Operaciones