Jedną z pierwszych opcji Azure SQL Database na jaką natrafiają użytkownicy podczas tworzenia tego zasobu jest opcja Allow Azure Services and resources to access this server wraz z innymi ustawieniami sieciowymi związanymi z naszym serwerem. O ile przepuszczanie ruchu z określonego adresu lub zakresu adresów IP do naszego serwera jest dosyć intuicyjne i proste w rozumieniu o tyle wspomniana opcja niekoniecznie dlatego też postanowiłem napisać parę słów na jej temat – zapraszam do lektury.
Opcja ta jest widoczna w kilku miejscach, pierwsze z nich to tworzenie samego SQL Server w Azure gdzie na zakładce Networking znajdziemy właśnie ten przełącznik:
Możliwa jest również zmiana tego ustawienia już po utworzeniu samego serwera. Wystarczy przejść na zakładkę Firewalls and virtual networks naszego serwera i tam odnajdziemy pożądany przełącznik:
Co zatem opcja ta oznacza? Nic innego jak to, że pozwalamy z sieciowego punktu widzenia na dostęp do naszego serwera wszystkim połączeniom pochodzącym z wewnątrz Azure. Warto zwrócić uwagę na fakt, iż określenie “połączenie pochodzące z wewnątrz Azure” wcale nie oznacza naszej subskrypcji – może to być usługa czy też dowolna maszyna wirtualna pochodząca z dowolnej subskrypcji! Warto o tym pamiętać i używać tej opcji z pełną świadomością konsekwencji – dla jednych klientów opcja ta jest w porządku bo co prawda sieciowo mamy nieco uszczuplone zabezpieczenie ale mamy jeszcze uwierzytelnienie po AAD itp. dla innych będzie to nieakceptowalny wyłom w firewallu, który jest zagrożeniem dla danych.
Przetestujmy sobie powyższą opcję z dwóch różnych perspektyw. Mam testowy serwer SQL postawiony w jednej subskrypcji oraz Azure Data Factory znajdujący się całkowicie w innej subskrypcji i lokalizacji. Do połączenia inicjowanego od strony ADF podałem wszystkie niezbędne dane potrzebne do połączenia – w tym czasie opcja “Allow Azure services…” jest ustawiona na No. Jak możecie się domyślić otrzymaliśmy błąd:
Po włączeniu opcji połączenie już się powiodło:
Czyli zgodnie z tym co oczekiwaliśmy – połączenie do serwera jest możliwe. Jeśli przyjrzymy się nieco głębiej temu co się dzieje to odpytując widok systemowy sys.firewall_rules, który wyświetla reguły Firewall na poziomie SQL Server zauważymy dosyć interesujący wpis:
SELECT * FROM sys.firewall_rules
Ustawiona przez nas opcja jest tam widoczna i jednoznacznie wskazuje, że każdy serwis Azure może dostać się do naszego serwera gdyż public endpoint naszego serwera i zawarty w nim firewall dopuszcza połączenia z wewnątrz Azure. ADF to tylko przykład ale możecie zauważyć analogiczne zachowanie z innymi usługami w tym również z Power BI, który jest również usługą Azure.
Jak zatem uniemożliwić włączenie tej opcji w naszej subskrypcji? Jak zazwyczaj w tego typu sytuacjach pomaga nam mechanizm Azure Policy gdzie możemy wymuszać określone ustawienia na zasobach Azure lub je audytować. W tym konkretnym przypadku stworzymy sobie regułę, która uniemożliwi dodawanie adresów IP 0.0.0.0 (a wiemy, że opisywana opcja to tak naprawdę dodanie ip 0.0.0.0 tak więc tworzona reguła powinna zablokować włączenie tej opcji).
Tworzenie swoich własnych reguł w JSON czasem bywa problematyczne jednakże w tym konkretnym przypadku sama treść wygląda następująco:
{
"properties": {
"displayName": "testSQLPolicy",
"policyType": "Custom",
"mode": "All",
"metadata": {
"createdBy": "dd9e754f-ea8a-4d4d-b51f-2ba953bfeab2",
"createdOn": "2021-09-23T18:20:49.3902023Z",
"updatedBy": null,
"updatedOn": null
},
"parameters": {},
"policyRule": {
"if": {
"anyOf": [
{
"field": "Microsoft.Sql/servers/firewallRules/startIpAddress",
"equals": "0.0.0.0"
},
{
"field": "Microsoft.Sql/servers/firewallRules/endIpAddress",
"equals": "0.0.0.0"
}
]
},
"then": {
"effect": "Deny"
}
}
},
"id": "/subscriptions/2934496f-e4ed-49c7-a474-9f8c1c4a78c8/providers/Microsoft.Authorization/policyDefinitions/7ded4bea-72b4-497c-bac4-503d520fbae0",
"type": "Microsoft.Authorization/policyDefinitions",
"name": "7ded4bea-72b4-497c-bac4-503d520fbae0",
"systemData": {
"createdBy": "adrian.chodkowski@hotmail.com",
"createdByType": "User",
"createdAt": "2021-09-25T16:20:49.3274034Z",
"lastModifiedBy": "adrian.chodkowski@hotmail.com",
"lastModifiedByType": "User",
"lastModifiedAt": "2021-09-25T16:20:49.3274034Z"
}
}
Z powyższej definicji wynika, że jako efekt jej działania mamy “Deny” czyli blokujemy modyfikację – jeśli byłaby taka potrzeba to moglibyśmy ustawić np. “Audit” aby po prostu dostać informację o braku zgodności. Warto pamiętać, że powyższa reguła nie wpłynie na istniejące już elementy.
Przejdźmy zatem do usługi Azure Policy od strony portalu wyszukując po prostu “Policy”. Będąc już we właściwym miejscu możemy wybrać Definitions aby móc dodać nową definicję polityki:
W tym miejscu wystarczy wybrać + Policy definition:
W oknie definiowania polityki możemy dodać wylistowany wyżej json z definicją polityki oraz przypisać ją do jednej z istniejących lub nowych kategorii:
W momencie gdy nasza polityka jest już gotowa możemy ją przypisać do określonego elementu hierarchii zasobów Azure:
Definicja przypisania jest raczej zrozumiała i sprowadza się do wypełnienia wartości parametrów (jeśli takowe mamy w naszej polityce) oraz przede wszystkim wskazania czy polityka ma być wymuszana (Policy enforcement -> Enabled) czy też nie (Policy enforcement -> Disabled):
Gdy wejdziemy na zakładkę Compliance to jesteśmy w stanie zobaczyć istniejące zasoby oraz to czy są one kompatybilne ze stworzoną przeze mnie polityką. Jak możecie zobaczyć na poniższym zrzucie ekranowym na trzy instancje SQL Server żadna z nich nie jest kompatybilna:
Po kliknięciu w którykolwiek z komunikatów widzimy dokładny opis braku zgodności:
Z politykami jest tak, że po ich zdefiniowaniu powinny być aktywne po około 30 minutach. Jeśli chcemy możemy uruchomić proces sprawdzenia kompatybilności na żądanie z wykorzystaniem Azure CLI:
az policy state trigger-scan
Jednakże powyższa komenda również trochę czasu zajmie w zależności m.in od tego ile mamy zasobów i jak zakres wybraliśmy.
Podsumowując warto pamiętać czym tak naprawdę zapis Allow Azure Services and resources to access this server jest i jak wpływa na bezpieczeństwo naszych danych. W idealnym świecie najlepiej jakby cała komunikacja ograniczała się tylko i wyłącznie do ruchu z wewnątrz danego VNET, jeśli jednak musimy z jakiegoś powodu nadawać dostępy poprzez podanie adresów IP w firewallu miejmy na uwadze powyższą opcję. Pozdrawiam!
- Executing SQL queries from Azure DevOps using Service Connection credentials - August 28, 2024
- Setup Git credentials for Service Principal in Azure Databricks - August 21, 2024
- Microsoft Fabric 101 Episode 3: Pausing and Scaling using portal and Powershell - August 8, 2024
Last comments