Database Firewall Rules (w Azure SQL)

Database Firewall Rules w Azure SQL to reguły ograniczające dostęp sieciowy do bazy danych na poziomie adresów IP.

Rola reguł Database Firewall Rules w Azure SQL Database

Database Firewall Rules w Azure SQL Database są regułami zapory opartymi na adresach IP, które określają, z jakich źródeł sieciowych można nawiązać połączenie z konkretną bazą danych. Mechanizm działa przed uwierzytelnieniem użytkownika w bazie. Oznacza to, że prawidłowy login i hasło nie wystarczą do nawiązania połączenia, jeżeli adres źródłowy klienta nie mieści się w żadnym dozwolonym zakresie. Reguły dotyczą publicznego punktu końcowego logicznego serwera Azure SQL Database i nie zastępują kontroli tożsamości, uprawnień użytkowników ani innych mechanizmów kontroli dostępu.

Reguła na poziomie bazy jest przypisana do jednej bazy danych. Można ją zdefiniować zarówno dla bazy użytkownika, jak i dla bazy master. Wpis obejmuje nazwę oraz początkowy i końcowy adres IP zakresu. Jeżeli adres początkowy i końcowy są takie same, reguła dopuszcza pojedynczy adres. Zakres może obejmować wiele adresów, dlatego zbyt szerokie wartości zwiększają obszar, z którego możliwa jest próba połączenia. Domyślnie nowe środowisko Azure SQL Database odrzuca połączenia do publicznego punktu końcowego, dopóki nie zostanie dodana odpowiednia reguła zapory.

Różnica między poziomem serwera a poziomem bazy

Reguła serwerowa obejmuje wszystkie bazy danych znajdujące się na danym logicznym serwerze. Jest przechowywana w bazie master i może być zarządzana między innymi z użyciem portalu Azure, Azure PowerShell, Azure CLI, interfejsu REST albo poleceń Transact-SQL. Reguła bazodanowa ma węższy zakres: pozwala udostępnić tylko wskazaną bazę określonym adresom IP. Dzięki temu różne bazy na tym samym logicznym serwerze mogą mieć odmienne wymagania dotyczące źródeł połączeń.

Podczas sprawdzania połączenia Azure SQL Database najpierw analizuje reguły bazodanowe dotyczące bazy wskazanej w żądaniu. Jeżeli adres klienta pasuje do takiej reguły, połączenie do tej bazy może przejść dalej. Gdy nie ma dopasowania, sprawdzane są reguły serwerowe. Ich dopasowanie otwiera dostęp do wszystkich baz objętych tym logicznym serwerem. Z tego powodu obecność szerokiej reguły serwerowej może w praktyce rozszerzyć dostęp bardziej, niż wynikałoby to z samych reguł bazodanowych. Reguły należy więc analizować razem, a nie jako dwa niezależne zestawy.

Konfiguracja i kontrola wpisów T-SQL

Reguły bazodanowe konfiguruje się wyłącznie za pomocą Transact-SQL i dopiero po utworzeniu pierwszej reguły serwerowej. Do utworzenia albo aktualizacji wpisu służy procedura sp_set_database_firewall_rule. Przykładowa instrukcja ma postać EXECUTE sp_set_database_firewall_rule N'Biuro', '203.0.113.10', '203.0.113.10';, przy czym użyty adres jest wyłącznie przykładowym adresem dokumentacyjnym. Ponowne wywołanie procedury z tą samą nazwą reguły aktualizuje zakres zamiast tworzyć drugi wpis o identycznej nazwie. Do usunięcia reguły służy sp_delete_database_firewall_rule.

Bieżące reguły można odczytać z widoku katalogowego sys.database_firewall_rules. Kontrola powinna obejmować nazwę reguły, adres początkowy i końcowy oraz bazę, w której wykonano zapytanie. Do zarządzania regułami bazodanowymi wymagane jest uprawnienie CONTROL do danej bazy. Samo dodanie wpisu nie nadaje użytkownikowi uprawnień do odczytu ani modyfikowania tabel. Reguła tylko przepuszcza ruch na poziomie sieciowym; dalszy dostęp zależy od uwierzytelnienia i uprawnień w Azure SQL Database.

Diagnostyka odmowy połączenia z Azure SQL Database

Analizę problemu należy rozpocząć od ustalenia, jaki publiczny adres IP rzeczywiście widzi usługa Azure SQL Database. Adres komputera w sieci lokalnej może być prywatny, a po drodze może występować translacja adresów, firmowy router, zapora brzegowa albo dostawca VPN. Wpisanie do reguły nieaktualnego adresu powoduje odmowę mimo poprawnej konfiguracji klienta SQL. Trzeba również sprawdzić, czy połączenie kierowane jest do właściwego logicznego serwera i właściwej bazy, ponieważ reguła bazodanowa nie jest automatycznie kopiowana do innych baz.

W diagnostyce trzeba rozdzielić trzy warstwy: dostęp sieciowy, uwierzytelnienie oraz uprawnienia. Komunikat o odrzuceniu przez firewall wskazuje na problem z dopasowaniem adresu lub zasięgiem reguły, natomiast błąd logowania pojawia się dopiero po przejściu kontroli sieciowej. Azure SQL Database korzysta z portu TCP 1433 dla standardowej komunikacji, dlatego lokalna lub firmowa zapora musi zezwalać na ruch wychodzący do tego portu. Zmiany reguł IP nie zawsze są widoczne natychmiast; według dokumentacji mogą być tymczasowo buforowane i propagacja modyfikacji może potrwać do kilku minut. W razie utrzymującego się problemu należy sprawdzić również publiczny dostęp do serwera, aktualny zakres adresów oraz ewentualne reguły serwerowe, które mogą zmieniać końcowy zasięg dostępu.