Perímetro de seguridad de red para Azure SQL Database (vista previa)

Se aplica a:Azure SQL Database

El perímetro de seguridad de red (preview) protege tanto el tráfico de red entrante como saliente entre Azure SQL Database y otros recursos de plataforma como servicio (PaaS), como Azure Storage y Azure Key Vault. Bloquea los intentos de comunicación con los recursos de Azure fuera del perímetro.

Nota:

Como característica en versión preliminar, la tecnología que se presenta en este artículo está sujeta a los términos de uso complementarios para las versiones preliminares de Microsoft Azure.

Get started

  1. En Azure Portal, busque Perímetro de seguridad de red en la lista de recursos y seleccione Crear.

    Captura de pantalla de la creación de un perímetro de seguridad de red en Azure Portal.

  2. Proporcione un Nombre y Región y elija la suscripción.

  3. En la sección Recursos , seleccione el botón Agregar y vaya a la instancia de SQL Database que desea asociar al perímetro.

  4. Añade una regla de acceso entrante. El tipo de origen puede ser una dirección IP, una suscripción u otros perímetros de seguridad de red.

  5. Añadir una regla de acceso saliente para permitir que los recursos dentro del perímetro se conecten con recursos fuera del perímetro.

Si ya tienes una Azure SQL Database y quieres añadir un perímetro de seguridad de red, utiliza los siguientes pasos:

  1. En Azure Portal, busque el perímetro de seguridad de red existente.

  2. Seleccione Recursos asociados en el menú Configuración .

  3. Seleccione el botón Agregar y seleccione Asociar recursos a un perfil existente.

    Captura de pantalla de los recursos asociados para el perímetro de seguridad de red en Azure Portal.

  4. Selecciona tu perfil en la lista desplegable y selecciona Añadir.

    Captura de pantalla de la adición de un recurso asociado para el perímetro de seguridad de red en Azure Portal.

  5. Busca tu recurso de base de datos SQL, selecciona el recurso requerido y luego selecciona Asociado.

Utiliza una base de datos SQL con un perímetro de seguridad de red

Por defecto, un perímetro de seguridad de red utiliza el modo de transición, anteriormente llamado modo de aprendizaje, que puedes usar para registrar todo el tráfico hacia y desde la base de datos SQL. Puedes registrar el tráfico de red en un espacio de trabajo de Log Analytics o en una cuenta de Azure Storage usando el registro de diagnóstico para Azure Network Security Perimeter. Cuando estés listo, cambia el perímetro a modo Reforzado . En modo Enforced , el acceso denegado devuelve el siguiente error:

Error 42118
Login failed because the network security perimeter denied inbound access.

Soporte de funcionalidades

No todas las funciones de Azure SQL Database interactúan de la misma manera con un perímetro de seguridad de red. Algunas funciones mueven datos entre servidores lógicos, otras se conectan hacia fuera a otros servicios de Azure y otras no funcionan dentro de un perímetro en absoluto. La siguiente tabla cubre las características documentadas hasta ahora. Esta lista crece a medida que más características completan la validación del perímetro. Selecciona una función para saber más sobre cómo funciona con un perímetro de seguridad de red, incluyendo los pasos de configuración y las limitaciones.

Feature Soporte perimetral Aspectos que debe saber
Replicación geográfica activa Supported En modo forzado, cada servidor lógico en un perímetro necesita tanto una regla de entrada como una de salida para cada otro servidor del conjunto de geo-replicación que no esté en su perímetro. Las reglas se ejecutan en ambas direcciones porque un geo-failover invierte la dirección del movimiento de datos. La replicación en un enlace establecido sigue ejecutándose incluso si luego cambias las reglas para no permitirla.
Cambio del streaming de eventos Supported La base de datos se conecta de forma saliente a Azure Event Hubs o Fabric Eventstream. En modo forzado, añade una regla saliente que especifique el FQDN de destino. Sin esa regla, no puedes crear un grupo de stream, y un stream existente deja de publicar y mantiene abierto el registro de transacciones.
Copia de base de datos Supported En modo forzado, un servidor fuente en un perímetro necesita una regla de salida, y un servidor objetivo en un perímetro necesita una regla de entrada. Ninguno necesita regla si ambos servidores están en el mismo perímetro o si la copia permanece en un solo servidor. Cuando un servidor lógico pertenece a un perímetro, Transact-SQL no es una forma compatible de copiar a otro servidor lógico.
Trabajos elásticos Supported El servidor lógico del agente de tareas necesita una regla de salida para cada servidor objetivo. El perímetro se comprueba en tiempo de ejecución, por lo que un trabajo puede crearse con éxito y luego fallar durante la ejecución.
Elastic Query Admitido dentro de un solo perímetro La base de datos que ejecuta la consulta y la base de datos remota deben estar en el mismo perímetro. La consulta elástica no necesita una configuración perimetral propia.
Eventos Extendidos Supported El destino event_file y las funciones que leen datos de eventos se conectan de forma saliente a Azure Storage. En modo forzado, usa una identidad gestionada o añade una regla FQDN saliente para la cuenta de almacenamiento cuando uses un token SAS.
Creación de reflejo de Fabric Supported Fabric se conecta en entrada al servidor lógico para configurar y supervisar la creación de reflejo, y la base de datos se conecta en salida a OneLake para publicar los datos. En modo forzado, añade una regla entrante para las etiquetas de servicio DataFactory, PowerBI y PowerQueryOnline, y una regla saliente que nombre el FQDN de destino de OneLake. Fabric no tiene perímetro propio, así que configuras todas las reglas en el lado de Azure SQL Database.
Restauración de retención a largo plazo Supported En modo forzado, un servidor fuente en un perímetro necesita una regla de salida, y un servidor objetivo en un perímetro necesita una regla de entrada. Ninguna de las dos opciones necesita una regla si ambas se encuentran en el mismo perímetro. Después de eliminar el servidor de origen, solo se puede validar el lado de destino.
SQL Data Sync No compatible por diseño Data Sync se ejecuta como un servicio proxy en lugar de un recurso de Azure, por lo que no tiene FQDN ni dirección IP contra la que escribir reglas perimetrales. Un perímetro bloquea los caminos de red que requiere Data Sync tanto en modo transición como en modo forzado.

Limitaciones

  • Un servidor lógico de Azure SQL Database no se puede asociar a un perímetro de seguridad de red si contiene uno o varios grupos de SQL dedicados (anteriormente SQL DW).
  • El soporte para perímetros de seguridad de red para Azure SQL Database está disponible en las regiones de la nube pública de Azure. No está disponible en Azure Government. Para la lista actual de servicios incorporados, véase Recursos privados de enlace incorporados.

Contenido relacionado

  • Se actualizó por última vez el