Azure NSG - Jak skutecznie zabezpieczyć sieć?

W Azure za rolę network security group odpowiada NSG, czyli wirtualna zapora, która decyduje, czy ruch do maszyny przejdzie, czy zostanie ucięty. Ja traktuję ją jako pierwszą warstwę ochrony między podsieciami, interfejsami i światem zewnętrznym, bo pozwala precyzyjnie dopuścić albo zablokować ruch przychodzący i wychodzący. Poniżej rozkładam na czynniki pierwsze, jak działa ta warstwa, gdzie ją umieszczać, jak pisać reguły bez chaosu i kiedy trzeba dołożyć mocniejszą kontrolę.

Czym jest NSG i co faktycznie zabezpiecza

NSG to warstwa filtrowania L3/L4, czyli sieciowa i transportowa. Nie analizuje treści aplikacji, nie zastępuje firewalla w systemie operacyjnym i nie rozwiązuje problemów z autoryzacją na poziomie aplikacji. Jej zadanie jest prostsze i przez to bardzo użyteczne: dopuścić lub odrzucić ruch według źródła, celu, portu, protokołu i kierunku. Przy ruchu przychodzącym reguły są oceniane po translacji publicznego adresu na prywatny, więc patrzysz na realny adres zasobu w sieci wirtualnej, a nie na sam adres publiczny. W praktyce przypina się ją do podsieci albo do interfejsu sieciowego konkretnej maszyny, więc działa jak lokalna, ale centralnie zarządzana bramka bezpieczeństwa.

Najczęstszy błąd, który widzę, to traktowanie NSG jak zastępstwa dla całego bezpieczeństwa sieci. To tylko jedna warstwa. Jeśli masz usługę wystawioną do Internetu, nadal potrzebujesz sensownej architektury, segmentacji, aktualizacji systemu i normalnej higieny w samej aplikacji. NSG robi porządek w ruchu, ale nie naprawia złej ekspozycji usługi. I właśnie dlatego warto zrozumieć, jak ocenia reguły.

Jak reguły są oceniane i dlaczego kolejność ma znaczenie

W NSG reguły są dopasowywane do pięciu parametrów: źródła, portu źródłowego, celu, portu docelowego i protokołu. Priorytet mieści się w zakresie od 100 do 4096, a im niższa liczba, tym wyższy priorytet. Azure zatrzymuje się na pierwszym dopasowaniu, więc jedna zbyt ogólna reguła potrafi skutecznie zepsuć całą resztę.

NSG jest też stanowe. Jeśli ruch został już zaakceptowany, odpowiedź na to połączenie nie wymaga osobnej reguły zwrotnej. Co więcej, usunięcie reguły zezwalającej na istniejące połączenie nie zrywa go od razu. To bywa mylące w testach, bo stary SSH albo aktywna sesja aplikacji może działać jeszcze przez chwilę, mimo że nowa próba połączenia już zostanie zablokowana.

W praktyce oznacza to, że jeśli chcesz otworzyć port 443 tylko dla konkretnej podsieci albo grupy maszyn, musisz dać regułę bardziej priorytetową niż domyślne deny. Gdy już to zrozumiesz, naturalnie pojawia się kolejne pytanie: gdzie najlepiej podpiąć tę ochronę, żeby nie utrudnić sobie życia.

Gdzie przypinać NSG i jak działa zakres ochrony

NSG możesz przypiąć do podsieci albo do konkretnego interfejsu sieciowego, a jedna i ta sama NSG może być używana wielokrotnie. Ja zwykle zaczynam od poziomu podsieci, bo to prostsze do utrzymania i lepiej pasuje do segmentacji ról, np. osobno web, aplikacja i baza. Poziom interfejsu zostawiam na wyjątki, gdy jedna maszyna potrzebuje innej polityki niż reszta w tym samym segmencie.

Warto pamiętać, że skuteczne reguły są sumą tego, co przypięte do podsieci i do interfejsu. Jeśli w organizacji działa też Azure Virtual Network Manager, do tej układanki dochodzą jeszcze reguły administracyjne. To właśnie dlatego w praktyce lepiej patrzeć na efekt końcowy, a nie tylko na jedną widoczną NSG. W praktyce, jeśli na podsieci masz deny inbound, reguła allow na NIC nie ma już czego przepuszczać. Z takiego podejścia naturalnie wynika projektowanie reguł tak, żeby dało się nimi zarządzać bez ręcznego pilnowania każdego adresu.

Jak pisać reguły, żeby nie utopić się w wyjątkach

Najbardziej użyteczne reguły są zwykle najprostsze. Zamiast wpisywać pojedyncze adresy IP wszędzie tam, gdzie to możliwe, lepiej korzystać z service tags i Application Security Groups. Tagi usług upraszczają dostęp do usług Azure, bo Microsoft aktualizuje za ciebie zakresy adresów. ASG z kolei pozwalają grupować maszyny według roli aplikacyjnej, a nie według ręcznie wpisanej listy IP.

• Użyj tagu usługi, gdy chcesz dopuścić ruch do konkretnej usługi Azure bez śledzenia zmian jej adresacji.
• Użyj Application Security Group, gdy zestaw maszyn pełni jedną rolę, np. front-end, worker albo baza danych.
• Użyj reguł rozszerzonych, gdy chcesz połączyć kilka portów lub zakresów adresów w jednej czytelnej regule.
• Unikaj szerokich wyjątków typu „na chwilę otworzę wszystko do Internetu”, bo takie reguły zostają najdłużej.

ASG działa tylko w obrębie jednej sieci wirtualnej, więc nie planowałbym nim przekrojowych reguł między różnymi VNetami. Jeśli adresy są stałe, możesz też bez problemu oprzeć regułę na zakresie CIDR zamiast na pojedynczych hostach, ale tam, gdzie adresy zmieniają się często, tags i ASG wygrywają z ręcznym utrzymywaniem list. Przykład, który często robi różnicę: aplikacja ma wyjście tylko do tagu Storage, administracja wchodzi z firmowego VPN, a baza danych nie ma żadnej drogi do Internetu. To nie jest efektowne, ale bardzo dobrze skaluje się operacyjnie.

Jeśli prowadzisz środowisko z webem i bazą, sensowny układ wygląda zwykle tak: z Internetu wpuszczasz tylko 443 do warstwy frontowej, front może gadać z warstwą aplikacji po konkretnym porcie, a baza przyjmuje ruch wyłącznie z ASG aplikacji. Taki model ogranicza liczbę wyjątków i daje czytelną architekturę bezpieczeństwa. Gdy jednak potrzebujesz kontroli szerszej niż allow/deny na poziomie IP i portu, sam NSG zaczyna być zbyt wąski.

Kiedy sam NSG nie wystarczy

NSG świetnie nadaje się do segmentacji i podstawowej ochrony sieciowej, ale nie zastąpi centralnej zapory, gdy potrzebujesz bardziej rozbudowanej polityki. Azure Firewall jest tu naturalnym uzupełnieniem: daje scentralizowane egzekwowanie reguł, obsługę FQDN i bardziej aplikacyjne podejście do filtrowania. Microsoft traktuje oba mechanizmy jako warstwy, które się uzupełniają, a nie wykluczają.

Ja najczęściej widzę sprawdzony układ: NSG pilnuje ruchu „wewnątrz” środowiska, a Azure Firewall stoi bliżej granicy i obsługuje bardziej złożone wyjątki oraz kontrolę wyjścia do Internetu. W webowych systemach często dochodzi jeszcze WAF, ale to już osobna warstwa. Gdy polityka jest dobrze ustawiona, zostaje ostatni etap: szybka diagnostyka, kiedy coś mimo wszystko nie działa.

Jak diagnozować blokadę ruchu bez zgadywania

Jeśli połączenie nie przechodzi, zaczynam od reguł skutecznych, a nie od zgadywania. To widok wszystkich reguł, które faktycznie obejmują interfejs, czyli sumy reguł z podsieci i z NIC. W praktyce bardzo często okazuje się, że ruch blokuje nie ta reguła, którą właśnie edytujesz, tylko inna o wyższym priorytecie. W Azure masz też IP flow verify, które pokazuje, czy ruch jest dozwolony czy odrzucony i która reguła odpowiada za decyzję.

1. Sprawdź, czy NSG jest przypięta do podsieci, do NIC, czy do obu.
2. Zweryfikuj priorytet reguły i jej kierunek, bo inbound i outbound to dwa oddzielne zestawy decyzji.
3. Upewnij się, że nie blokuje cię reguła deny z niższym numerem priorytetu.
4. Jeśli testujesz z VM, pamiętaj, że OS firewall może blokować ruch niezależnie od NSG.
5. Jeżeli ruch nadal wygląda dziwnie, sprawdź reguły skuteczne dla każdego NIC osobno, bo jedna maszyna może mieć kilka interfejsów.

Warto też pamiętać o logowaniu. Klasyczne NSG flow logs są wycofywane 30 września 2027, a po 30 czerwca 2025 nie da się tworzyć nowych. Jeśli w 2026 budujesz nowe środowisko albo porządkujesz monitoring, planowałbym już przejście na virtual network flow logs, zamiast przywiązywać się do starego mechanizmu. To nie jest detal administracyjny, tylko realna kwestia utrzymania widoczności ruchu w czasie. Zostaje jeszcze ostatnia rzecz: kilka prostych decyzji projektowych, które oszczędzają najwięcej czasu na później.

Co sprawdzić przed wdrożeniem, żeby reguły nie rozjechały się po miesiącu

• Zacznij od podziału na role: osobne podsieci dla web, aplikacji, bazy i administracji zwykle dają więcej porządku niż jeden wielki segment.
• Nie otwieraj szerokich zakresów „na wszelki wypadek”; lepiej dodać jedną regułę więcej niż zostawić trwały wyjątek.
• Ustal nazewnictwo, z którego naprawdę da się korzystać po trzech miesiącach, bo deny-db-internet-out jest lepsze niż rule-12.
• Jeśli masz wiele maszyn o podobnej roli, grupuj je w ASG zamiast powielać IP w każdej regule.
• Do administracji trzymaj osobną ścieżkę, najlepiej przez Azure Bastion albo JIT, zamiast zostawiać stałe RDP/SSH z Internetu.
• Jeśli środowisko rośnie, zapisuj NSG w IaC, bo ręczne klikanie szybko rozjeżdża zgodność między środowiskami.
• Dokumentuj wyjątki administracyjne i przeglądaj je po wdrożeniach, bo to właśnie one najczęściej stają się stałym ryzykiem.

Jeśli mam wskazać jedną praktykę, która najbardziej podnosi skuteczność NSG, to jest nią myślenie w strefach i rolach, a nie w pojedynczych portach. Taka perspektywa upraszcza reguły, ogranicza liczbę wyjątków i sprawia, że kontrola ruchu pozostaje czytelna także wtedy, gdy środowisko rośnie.