Fala pessoal! Tudo bem com vocês? Animados para mais um post???
Introduction
Todo DBA que gerencia bancos no Azure SQL Database, se depara com um cenário clássico de segurança e governança. É muito comum que aplicações diferentes precisem de acesso a bancos de dados específicos dentro da mesma instância lógica (Logical Server) do Azure SQL Database. Se você liberar o IP dessas aplicações no firewall do servidor, eles terão visibilidade (mesmo que sem permissão de acesso aos dados) a todos os outros bancos ali hospedados.
É aí que a implementação de Database-level Firewall Rules se torna a peça-chave. Muita gente acaba configurando tudo pelo Portal do Azure, o que limita a visão apenas às regras de servidor, ignorando o poder e a granularidade das regras de banco de dados que só podem ser gerenciadas via T-SQL.
No post de hoje, vamos dissecar o funcionamento do firewall no Azure SQL Database, entender a ordem de avaliação das regras e como automatizar isso via script.
Resumo do post em vídeo:
Arquitetura de Firewall: Server-level vs. Database-level
No Azure SQL Database, o firewall é a primeira linha de defesa. Antes mesmo de qualquer tentativa de autenticação ser processada pelo motor do SQL Server, o Azure Gateway verifica se o IP de origem tem permissão para tentar se conectar na porta 1433. Caso o IP não esteja permitido, mesmo que tenha permissão no banco, a conexão não será realizada e não será possível saber nem se realmente esse banco existe ou não.
Existem dois níveis principais de regras:
- Server-level Firewall Rules: São armazenadas no banco de dados master. Elas permitem tentar se conectar em todo o servidor lógico, incluindo todos os bancos de dados contidos nele. São ideais para administradores e IPs de redes corporativas fixas.
- Database-level Firewall Rules: São armazenadas dentro do próprio banco de dados do usuário. Elas permitem realizar a conexão apenas àquele banco específico. Se um usuário tentar se conectar a outro banco no mesmo servidor sem uma regra correspondente, a conexão será recusada.
Comparativo Técnico:
| Característica | Server-level Firewall | Database-level Firewall |
|---|---|---|
| Armazenamento | Banco de dados master | Banco de dados do usuário |
| Escopo | Todo o Servidor Lógico | Apenas o banco específico |
| Configuração | Portal Azure, PowerShell, CLI, T-SQL | Apenas T-SQL |
| Portabilidade | Não segue o banco em migrações | Segue o banco (ex: Failover Groups) |
| Cenário Ideal | DBAs e IPs corporativos | Aplicações específicas e multi-tenant |
Gerenciando o Firewall do Servidor (Server-level)
As regras de servidor são as mais comuns. Elas facilitam a vida do DBA, pois uma única entrada libera o acesso a todos os recursos do servidor. No entanto, do ponto de vista de Principle of Least Privilege (Privilégio Mínimo), elas podem ser excessivas para usuários finais.
Para gerenciar essas regras, você deve estar conectado ao banco de dados master.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
-- 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'; |
O gerenciamento das regras a nível de servidor também pode ser realizado pela interface do portal da Azure, acessando a aba de Rede (Networking) ao acessar as configurações do servidor lógico (e não do SQL Database)
Embora seja realmente muito mais fácil gerenciar as regras pela interface do portal, a grande vantagem de poder gerenciar as regras de firewall do servidor utilizando T-SQL é possibilidade de automação.
Gerenciando o Firewall do Banco de Dados (Database-level)
Aqui é onde o DBA de trincheira se diferencia. Como o Portal do Azure não exibe essas regras, muitos administradores sequer sabem que elas existem, o que pode causar confusão em auditorias de segurança.
As regras de banco de dados são fundamentais para cenários de Contained Databases e High Availability. Em um cenário de Failover Group, se o banco sofrer um failover para outra região, as regras de firewall de banco de dados migram com ele, garantindo que a aplicação continue conectando sem intervenção manual no firewall do novo servidor.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
-- 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'; |
Ao utilizar regras a nível de banco de dados, lembre-se de alterar o banco de dados na conexão do SQL Server Management Studio (ou outra ferramenta que esteja utilizando) ou definir a propriedade “Initial Catalog” se estiver utilizando uma string de conexão em alguma aplicação.
Análise de Performance e Segurança
Embora o processamento do firewall ocorra na camada de Gateway do Azure, é importante notar que uma configuração excessiva de regras (centenas ou milhares de entradas individuais) pode adicionar uma latência mínima no handshake inicial.
Ao monitorar performance, fique atento a erros de conexão que resultam em timeouts. No Azure SQL, problemas de conectividade relacionados ao firewall geralmente não geram Wait Types pesados dentro da engine (como RESOURCE_SEMAPHORE ou CXPACKET), mas sim erros de rede no lado do cliente (Error 40613).
Um ponto que sempre destaco: ao utilizar sp_set_database_firewall_rule, você aumenta a resiliência do seu desastre recovery. Se o seu banco for restaurado em outro servidor para um teste de validação, as regras de acesso dos seus parceiros já estarão lá, reduzindo o RTO (Recovery Time Objective) operacional.
Espero que tenham gostado dessa dica, um grande abraço e até a próxima!
Portuguese 
English