¡Hola, chicos! ¿Cómo estás? ¿Emocionado por otra publicación?

Introducción

Todo DBA que administra bases de datos en Azure SQL Database se enfrenta a un escenario clásico de seguridad y gobernanza. Es muy común que diferentes aplicaciones necesiten acceso a bases de datos específicas dentro de la misma instancia lógica (Servidor Lógico) de Azure SQL Database. Si libera la IP de estas aplicaciones en el firewall del servidor, tendrán visibilidad (incluso sin permiso de acceso a datos) para todos los demás bancos alojados allí.

Aquí es donde la implementación de reglas de firewall a nivel de base de datos se vuelve clave. Muchas personas terminan configurando todo a través del Portal de Azure, lo que limita la vista solo a las reglas del servidor, ignorando el poder y la granularidad de las reglas de la base de datos que solo se pueden administrar a través de T-SQL.

En la publicación de hoy, analizaremos cómo funciona el firewall en Azure SQL Database, comprenderemos el orden en el que se evalúan las reglas y cómo automatizarlo mediante un script.

Resumen de la publicación en vídeo:

Arquitectura de firewall: nivel de servidor frente a nivel de base de datos

En Azure SQL Database, el firewall es la primera línea de defensa. Incluso antes de que el motor SQL Server procese cualquier intento de autenticación, Azure Gateway verifica si la IP de origen tiene permiso para intentar conectarse en el puerto 1433. Si la IP no está permitida, incluso si tiene permiso en la base de datos, la conexión no se realizará y no será posible saber si esta base de datos realmente existe o no.

Hay dos niveles principales de reglas:

  • Reglas de firewall a nivel de servidor: Se almacenan en la base de datos. maestro. Le permiten intentar conectarse a todo el servidor lógico, incluidas todas las bases de datos que contiene. Son ideales para administradores e IP de redes corporativas fijas.
  • Reglas de firewall a nivel de base de datos: Se almacenan dentro de la propia base de datos del usuario. Le permiten conectarse sólo a ese banco específico. Si un usuario intenta conectarse a otro banco en el mismo servidor sin una regla coincidente, la conexión será rechazada.

Comparación técnica:

Característica Cortafuegos a nivel de servidor Cortafuegos a nivel de base de datos
Almacenamiento Base de datos maestro Base de datos de usuarios
Alcance Todo el servidor lógico Sólo el banco específico
Ajustes Portal de Azure, PowerShell, CLI, T-SQL Solo T-SQL
Portabilidad No sigue al banco en migraciones Siga al banco (por ejemplo: grupos de conmutación por error)
Escenario ideal DBA e IP corporativas Aplicaciones específicas y multiinquilino
NOTA: El orden de evaluación es crucial. Cuando se realiza un intento de conexión, Azure primero verifica las reglas a nivel de base de datos (si la base de datos de destino se especifica en la cadena de conexión). Si no encuentra una coincidencia, verifica las reglas a nivel de servidor. Si ambos fallan, la conexión se bloquea.

Administrar el firewall del servidor (nivel de servidor)

Las reglas del servidor son las más comunes. Facilitan la vida del DBA, ya que una única entrada permite el acceso a todos los recursos del servidor. Sin embargo, desde el punto de vista de Principio de privilegio mínimo (Mínimo Privilegio), pueden resultar excesivos para los usuarios finales.

Para gestionar estas reglas, usted debe estar conectado a la base de datos maestro.

-- FIREWALL DO SERVIDOR (SERVER-LEVEL)

-- 1. Consultar as regras existentes no servidor
-- Nota: Executar no contexto do banco 'master'
SELECT
    [name],
    [start_ip_address],
    [end_ip_address],
    [create_date],
    [modify_date]
FROM
    sys.firewall_rules
ORDER BY
    [name];

-- 2. Criar ou atualizar uma regra de IP
-- Caso start e end sejam iguais, você libera apenas um IP fixo (/32)
EXEC sp_set_firewall_rule
    @name = N'IP_Dirceu',
    @start_ip_address = '138.99.35.0',
    @end_ip_address = '138.99.35.0';

-- 3. Remover uma regra de IP do servidor
EXEC sp_delete_firewall_rule
    @name = N'IP_Dirceu';

La gestión de reglas a nivel de servidor también se puede realizar a través de la interfaz del portal Azure, accediendo a la pestaña Redes al acceder a la configuración lógica del servidor (y no a la Base de Datos SQL)

Aunque en realidad es mucho más fácil gestionar las reglas a través de la interfaz del portal, la gran ventaja de poder gestionar las reglas del firewall del servidor utilizando T-SQL es la posibilidad de automatización.

ALERTA: Dado que las reglas de firewall a nivel de servidor existen en el nivel de servidor y se almacenan en la base de datos maestro, en casos de conmutación por error, las reglas NO Se replican automáticamente y también deben crearse en las réplicas para evitar problemas de acceso, ya que en los grupos de disponibilidad (Always On) o Geo-Replicación, el banco maestro de cada servidor es independiente. No forma parte del conjunto de datos replicado.

Administrar el firewall de la base de datos (nivel de base de datos)

Aquí es donde se diferencia el DBA de trinchera. Debido a que Azure Portal no muestra estas reglas, muchos administradores ni siquiera saben que existen, lo que puede causar confusión en las auditorías de seguridad.

Las reglas de la base de datos son fundamentales para los escenarios de bases de datos. Bases de datos contenidas y Alta disponibilidad. En un escenario de grupo de conmutación por error, si la base de datos conmuta por error a otra región, las reglas del firewall de la base de datos migran con ella, lo que garantiza que la aplicación continúe conectándose sin intervención manual en el firewall del nuevo servidor.

-- FIREWALL DO DATABASE (DATABASE-LEVEL)
--- 1. Conectar no banco que será consultado e listar regras
SELECT
    [name],
    [start_ip_address],
    [end_ip_address],
    [create_date],
    [modify_date]
FROM
    sys.database_firewall_rules
ORDER BY
    [name];

-- 2. Criar ou atualizar uma regra de IP para o banco atual
-- Isso restringe o acesso deste IP apenas a este DB específico
EXEC sp_set_database_firewall_rule
    @name = N'IP_Dirceu',
    @start_ip_address = '138.99.35.0',
    @end_ip_address = '138.99.35.0';

-- 3. Remover a regra de IP do banco de dados
EXEC sp_delete_database_firewall_rule
    @name = N'IP_Dirceu';

Cuando utilice reglas a nivel de base de datos, recuerde cambiar la base de datos en la conexión de SQL Server Management Studio (u otra herramienta que esté utilizando) o configurar la propiedad "Catálogo inicial" si está utilizando una cadena de conexión en cualquier aplicación.

Análisis de rendimiento y seguridad

Aunque el procesamiento del firewall se produce en la capa de Azure Gateway, es importante tener en cuenta que una configuración excesiva de reglas (cientos o miles de entradas individuales) puede agregar una latencia mínima en el protocolo de enlace inicial.

Al monitorear el rendimiento, esté atento a los errores de conexión que provocan tiempos de espera. En Azure SQL, los problemas de conectividad relacionados con el firewall normalmente no generan Tipos de espera objetos pesados ​​dentro del motor (como RECURSO_SEMÁFORO o PAQUETE CX), sino errores de red del lado del cliente (Error 40613).

NOTA CRÍTICA: Si utiliza la opción "Permitir que los servicios y recursos de Azure accedan a este servidor", está permitiendo que CUALQUIER recurso proveniente del centro de datos de Azure (incluso de otros clientes) intente autenticarse en su SQL. En entornos de alta seguridad, deshabilite esta opción y trabaje con puntos finales de servicio de red virtual (VNet) o Private Link.

Un punto que siempre destaco: al utilizar sp_set_database_firewall_rule, aumenta la resiliencia de su recuperación ante desastres. Si su base de datos se restaura en otro servidor para una prueba de validación, las reglas de acceso de sus socios ya estarán allí, lo que reducirá el RTO (objetivo de tiempo de recuperación) operativo.

Espero que te haya gustado este tip, un fuerte abrazo y ¡hasta la próxima!