Dostawcy chmury, tacy jak Microsoft, pozwalają nam w mgnieniu oka budować infrastrukturę IT (chociażby wyklikując ją w panelu web). Nie wygląda to już tak jak kiedyś, gdy użytkownik musiał zgłosić zapotrzebowanie na nowy serwer czy maszynę wirtualną, a dział IT musiał to przeprocesować, kupić sprzęt, skonfigurować go i dopiero udostępnić.
Teraz dzieje się to błyskawicznie i często poza pełną kontrolą IT, inżynierowie DevOps czy nawet sami deweloperzy są w stanie zdeployować infrastrukturę chmurową dopasowaną do swoich potrzeb w zaledwie kilka chwil.
Jak w tak dynamicznie zmieniającym się środowisku pilnować bezpieczeństwa?
Dynamicznie zmieniająca się infrastruktura i wiążące się z tym problemy
W nowoczesnych infrastrukturach chmurowych, które zmieniają się dynamicznie każdego dnia, nowe maszyny wirtualne czy usługi mogą być uruchamiane w ciągu zaledwie kilku minut. Co więcej, istniejące systemy są modyfikowane na bieżąco zależnie od potrzeb użytkowników i bez udziału działu IT. Podnosi to ryzyko przypadkowego wystawienia usług do Internetu bez odpowiednich zabezpieczeń. Często robią to osoby, które nie zajmują się bezpieczeństwem i mogą nie znać podstaw hardeningu infrastruktury (choć jeśli dajemy komuś tak szerokie uprawnienia, powinien być przeszkolony z higieny security).
Takie podejście jest po prostu niezwykle podatne na błąd ludzki, nawet jeśli konfigurujemy infrastrukturę za pomocą kodu (IaC) i sprawdzamy jego poprawność odpowiednimi narzędziami przed deploymentem na produkcje. Ktoś może po prostu nie wiedzieć, jak zrobić coś zgodnie ze sztuką, albo robi deployment na szybko, byle tylko dowieźć temat pod presją czasu.
Zamiast ciągle gasić pożary i gonić ludzi, aby poprawiali swoje deploymenty (co przy dużej organizacji jest walką z wiatrakami), warto wykorzystać podejście typu Guardrails. Pozwala ono narzucić zasady, których absolutnie musi przestrzegać każdy nowy deployment infrastruktury.
Dla ekosystemu Microsoft Azure takim rozwiązaniem jest właśnie Azure Policy. Umożliwia ono konfigurowanie reguł (oraz ich zbiorów), które wymuszają odpowiednie standardy w subskrypcjach należących do organizacji. I choć ten artykuł skupia się na bezpieczeństwie, za pomocą Azure Policy możemy robić znacznie więcej (na przykład ograniczać dopuszczalne SKU usług w celu kontroli kosztów czy narzucać reguły pod konkretne wymogi compliance).
Kluczowe scenariusze użycia Azure Policy
Azure Policy pozwala skutecznie zaadresować następujące wyzwania:
- Blokowanie publicznego dostępu do zasobów (np. wyłączanie publicznych punktów końcowych dla baz danych czy kont Storage).
- Wymuszanie odpowiedniego poziomu szyfrowania: zarówno w spoczynku (at-rest), jak i w transmisji (in-transit).
- Geofencing na potrzeby RODO / GDPR: ograniczenie możliwości tworzenia zasobów wyłącznie do regionów europejskich.
- Wymuszanie enrollmentu nowo tworzonych zasobów do Microsoft Defender for Cloud, co gwarantuje ciągły monitoring bezpieczeństwa.
- Centralizacja logów: automatyczne podpinanie zasobów do jednego Log Analytics Workspace (np. na potrzeby dalszego przesyłania zdarzeń do systemu SIEM).
- Ograniczenie dozwolonych SKU usług, co pozwala utrzymać w rygorze budżet chmurowy.
To niezwykle potężne narzędzie, które pozwala zapanować nad chaosem tak powszechnym w nowoczesnych środowiskach i znacząco ograniczyć ich powierzchnię ataku.
Architektura wdrożenia i przykłady konfiguracji
Zanim przejdziemy do konfiguracji Azure Policy w praktyce, musimy poznać kluczową terminologię oraz funkcje tej usługi. Zacznijmy od podstawowych pojęć:
- Policy definition – podstawowy klocek konstrukcyjny. Jest to pojedyncza reguła zapisana w formacie JSON, która opisuje warunki, jakie musi spełniać dany zasób, oraz efekt, jaki nastąpi w przypadku braku ich spełnienia.
- Policy Initiative – pakiet połączonych ze sobą polityk. Zamiast przypisywać każdą regułę z osobna, możemy zebrać je w grupę (np. SQL Databases baseline security). Microsoft udostępnia nam też bogaty katalog gotowych inicjatyw, np. Microsoft Cloud Security Benchmark (MCSB) z setkami dobrych praktyk czy predefiniowane paczki pod wymogi compliance (RODO / GDPR, ISO 27001 czy PCI DSS).
- Scope – określa miejsce przypisania reguł. Polityki możemy nakładać na całe Management Groups, pojedyncze subskrypcje, a nawet konkretne Resource Groups. Wszystko zależy od tego, jak granularnie chcemy wymuszać zasady.
Same polityki oraz inicjatywy mogą wywoływać różne efekty w przypadku wykrycia niezgodności:
- DeployIfNotExists / Modify – automatycznie naprawia zasób lub dołącza brakującą konfigurację (warto pamiętać, że opcja ta nie jest dostępna dla każdego typu zasobu).
- Audit – pozwala na utworzenie zasobu, ale oznacza go w systemie jako niezgodny (idealne rozwiązanie do testów i audytu środowiska).
- Deny – całkowicie blokuje wdrożenie lub modyfikację zasobu, jeśli narusza on reguły.
- Disabled – wyłącza daną politykę (przydatne, gdy chcemy zachować konfigurację, ale tymczasowo znieść wymuszanie zasad).
Ważne: Koszt i wymagane uprawnienia
Usługa Azure Policy jest całkowicie darmowa i jej użycie nie wiąże się z żadnymi dodatkowymi opłatami. Wyjątkiem są sytuacje, w których wymuszamy reguły na zasobach zarządzanych przez Azure Arc (serwery on-premises wciągnięte do chmury), w takim przypadku koszt wynosi około 5,15 EUR miesięcznie za każdy objęty polityką serwer lub maszynę wirtualną.
Aby móc konfigurować i przypisywać polityki, musimy posiadać odpowiednie uprawnienia na poziomie zakresu, którym chcemy zarządzać. Wymagana jest rola Owner lub Resource Policy Contributor. Ta druga jest bardziej bezpieczna ze względu na zasadę Least Privilege, ponieważ nie daje pełnej kontroli nad środowiskiem Azure, a pozwala w pełni zarządzać samymi politykami.
Mając opanowane podstawowe pojęcia, możemy przejść do praktyki i skonfigurować pierwsze reguły w Azure Policy.
Weryfikacja zgodności z wymogami compliance
Zaczniemy od polityk zgodności (compliance). Służą one, jak wspomniałem wcześniej, do weryfikacji naszej infrastruktury pod kątem regulacji prawnych oraz standardów branżowych.
Rekomendowanym podejściem jest użycie gotowych paczek udostępnianych przez Microsoft, nie ma sensu tworzyć koła na nowo, ponieważ producent oferuje wzorce dla większości popularnych norm. Aby je wdrożyć, przechodzimy do portalu Azure Policy, wybieramy zakładkę Compliance, a następnie klikamy Assign initiative.
W menu konfiguracji wskazujemy zakres (Scope), do którego chcemy przypisać inicjatywę. W moim przypadku będzie to Management Group, dla której narzucę zasady weryfikujące zgodność z normą ISO 27001:2022 (w wersji 1.3).
Warto zauważyć, że w kreatorze mamy możliwość wykluczenia wybranych elementów z działania polityki (np. pojedynczej subskrypcji). Możemy też skonfigurować Resource Selector, który za pomocą zapytań (np. filtrując zasoby po typie czy lokalizacji) pozwala na dynamiczne obejmowanie ich inicjatywą.
Bardzo ważnym elementem konfiguracji jest też opcja Policy enforcement. Jak wspominałem wcześniej, każda pojedyncza reguła w ramach inicjatywy ma zdefiniowane własne efekty działania. To, co wybierzemy w tej sekcji, wpłynie na globalne zachowanie całej inicjatywy:
- Default: Wymuszanie jest włączone. System stosuje domyślne efekty zdefiniowane bezpośrednio w regułach inicjatywy (np. Deny, Modify czy Audit).
- Do not enforce: Wyłącza bezpośrednie wymuszanie reguł. Polityka działa wyłącznie w trybie audytu, zbiera informacje o niezgodnościach, ale w żaden sposób nie blokuje ani nie modyfikuje procesu deploymentu usług.
- Enroll: Opcja stosowana w scenariuszach automatyzacji i zarządzania zasobami. Pozwala na automatyczne dołączanie zasobów do procesów naprawczych (Remediation) oraz rejestrowanie ich w usłudze, aby przygotować infrastrukturę pod wymuszanie polityk bez natychmiastowego blokowania użytkowników.
W naszym scenariuszu użyjemy opcji Do not enforce, ponieważ w tym scenariuszu zależy nam wyłącznie na audycie zasobów.
W zakładce Parameters możemy określić, czy polityka ma objąć również zasoby on-premise połączone z chmurą za pomocą Azure Arc. W naszym przypadku wszystkie te opcje ustawiamy na false (jak wspominałem wcześniej, objęcie analizą maszyn z Azure Arc wiąże się z dodatkowymi opłatami).
W zakładce Remediation możemy skonfigurować automatyczne naprawianie wykrytych niezgodności z politykami, jednak w przypadku tej konkretnej inicjatywy funkcja ta nie jest wspierana.
Zakładka Managed Identity pozwala stworzyć tożsamość w Entra ID, za pomocą której inicjatywa będzie mogła automatycznie naprawiać wykryte niezgodności. Jest to warunek konieczny do działania automatyzacji, Azure Policy potrzebuje tożsamości z odpowiednimi uprawnieniami, aby w naszym imieniu wprowadzać modyfikacje w zasobach.
W zakładce Non-compliance message możemy skonfigurować komunikat, który wyświetli się użytkownikom, gdy zdeployują (lub spróbują zdeployować) zasób niezgodny z ustanowionymi przez nas regułami.
Po skonfigurowaniu całości przechodzimy do zakładki Review + create. Jeśli wszystkie parametry się zgadzają, klikamy przycisk Create.
Uruchomienie usługi i przeanalizowanie wybranych zasobów przez Azure Policy zajmie chwilę. Gdy konfiguracja w tle dobiegnie końca, otrzymamy powiadomienie w portalu.
Gdy analiza dobiegnie końca, wyniki zobaczymy bezpośrednio w głównym widoku zakładki Compliance. Stamtąd możemy przejść do szczegółowych raportów i dokładnie przeanalizować stan poszczególnych zasobów, klikając w wybrane pozycje.
W zakładce Remediation będziemy też zobaczyć zalecenia Microsoftu, odnośnie tego co zrobić aby nasze zasoby były zgodne z politykami.
Niestety nie mogę zaprezentować tego na zrzutach ekranu, w moim prywatnym środowisku testowym mam zbyt mało usług, by wykonać miarodajną weryfikację, z kolei udostępnienie screenów z produkcyjnego systemu korporacyjnego (nawet solidnie zanonimizowanych) niosłoby ze sobą ryzyko bezpieczeństwa. Ponieważ jednak sama usługa Azure Policy jest darmowa, gorąco zachęcam do wyklikania jej i wypróbowania we własnym środowisku! 🙂
Tworzenie własnych polityk i inicjatyw
Oprócz korzystania z gotowych szablonów udostępnianych przez Microsoft, możemy oczywiście tworzyć własne, pojedyncze polityki (wykorzystując konfigurator w portalu lub pisząc je bezpośrednio w formacie JSON) albo budować całe inicjatywy dopasowane do specyficznych potrzeb naszej organizacji.
Wszystkie własne reguły i zestawy konfigurujemy w sekcji Authoring -> Definitions, korzystając z przycisków + Policy definition lub + Initiative definition.
Jak wspominałem wcześniej, poszczególne polityki pisze się w formacie JSON. Jest to rozwiązanie niezwykle wygodne i przejrzyste, a w dzisiejszych czasach, przy wsparciu generatywnej sztucznej inteligencji, taki szablon można stworzyć od zera w dosłownie kilka chwil.
Weryfikacja konfiguracji maszyn wirtualnych
W zakładce Machine Configuration możemy również skonfigurować weryfikację maszyn wirtualnych, zarówno tych zdefiniowanych bezpośrednio w Azure, jak i serwerów on-premise połączonych za pomocą Azure Arc. Pozwala to na kontrolowanie nie tylko zgodności samego procesu deploymentu zasobu, ale także szczegółowej konfiguracji wewnątrz systemu operacyjnego danego serwera.
Klikając przycisk + Enable, zostaniemy przekierowani do kreatora, który poprowadzi nas przez cały proces. Oprócz standardowego wyboru zakresu, jaki chcemy objąć usługą, musimy również utworzyć Managed Identity w Entra ID. Będzie ona wykorzystywana do automatycznego naprawiania wykrytych niezgodności. Ta tożsamość otrzyma dostęp do naszych maszyn wirtualnych z uprawnieniami na poziomie Contributor (warto pamiętać, że tego zakresu uprawnień nie można zmienić).
Po objęciu maszyn tą usługą możemy przypisać do nich dedykowane pakiety reguł. Co ciekawe, nie są to standardowe inicjatywy, o których wspominałem wcześniej, ale osobne definicje zgodności, takie jak Azure Security Baseline dla systemów Windows i Linux czy zestawy zaleceń oparte na uznanych benchmarkach CIS.
Jak wskazuje komunikat na powyższym zrzucie ekranu, do poprawnego działania tej funkcji wymagane jest, aby wszystkie objęte nią maszyny wirtualne posiadały włączone rozszerzenie Machine Configuration extension. Zostanie ono automatycznie dodane przez Azure Policy. Rozszerzenie to, w połączeniu z Managed Identity, służy bezpośrednio do zarządzania serwerami oraz wymuszania ich zgodności z politykami.
Policy as Code
Warto również wspomnieć o podejściu Policy as Code. Dojrzałe organizacje chmurowe nie wyklikują konfiguracji ręcznie przez portal Azure, takie rozwiązanie jest trudne do skalowania, ciężkie w utrzymaniu i podatne na błędy ludzkie. Zamiast tego stosuje się podejście Infrastructure as Code (IaC), które pozwala opisać całą infrastrukturę za pomocą kodu i przewidywalnie wdrażać ją na dużą skalę. Kod ten trafia do systemu kontroli wersji (np. Git) i przechodzi automatyczną weryfikację przed każdym deploymentem w ramach procesów CI/CD.
Tę samą logikę przekładamy bezpośrednio na Azure Policy. Definicje polityk, inicjatywy oraz ich przypisania do zakresów (Assignments) zapisujemy jako kod i automatycznie egzekwujemy w naszych potokach CI/CD. Funkcjonalność tę natywnie wspierają wszystkie popularne narzędzia do zarządzania infrastrukturą, takie jak Terraform czy Azure Bicep.
Więcej informacji na ten temat możecie znaleźć w dokumentacji Microsoftu: Design Azure Policy as Code workflows.