Konfiguracja sieci w Azure nie jest prostym zagadnieniem. Świeżo po założeniu nowej subskrypcji i stworzeniu naszej pierwszej resource groupy, musimy skonfigurować sieć wirtualną (VNet), ustawić dla niej grupę zabezpieczeń sieciowych (NSG), a na końcu zdeployować zasoby do tej właśnie sieci. Nie pomaga fakt, że sam Azure przy tworzeniu zasobów domyślnie udostępnia je w sieci publicznej – przypisuje im publiczny adres IP i często otwiera cały ruch sieciowy na świat.
Jak zaprojektować i zbudować infrastrukturę sieciową w Azure, aby nasze zasoby były w pełni bezpieczne?
Topologia sieciowa hub-spoke
To jedna z najczęściej stosowanych topologii podczas projektowania sieci w Azure. Pozwala ona skutecznie zabezpieczać, monitorować i w łatwy sposób zarządzać ruchem sieciowym – zarówno przychodzącym, jak i wychodzącym z naszej chmury. Cała koncepcja polega na skonfigurowaniu jednej głównej sieci (VNet), pełniącej rolę „huba”. To właśnie przez nią przechodzi cały ruch i w niej uruchamiamy kluczowe usługi, takie jak Azure Firewall czy VPN Gateway. Do tak przygotowanego centrum podpinamy następnie sieci „spoke”, w których znajdują się nasze zasoby: maszyny wirtualne, usługi App Service czy bazy danych.
Dawniej, aby zbudować taką topologię, musieliśmy ręcznie tworzyć poszczególne VNety, ustawiać między nimi peering, a na końcu dla każdej sieci konfigurować NSG, by odpowiednio filtrować ruch. Dzisiaj możemy ułatwić sobie to zadanie, wykorzystując Azure Virtual Network Manager (AVNM). Jest to narzędzie pozwalające zdefiniować konfigurację sieciową (np. wybierając gotową topologię) oraz reguły bezpieczeństwa, a następnie masowo przypisać je do naszych sieci. AVNM automatycznie skonfiguruje infrastrukturę i pozwoli nią zarządzać w wygodny sposób. To świetne rozwiązanie, zwłaszcza gdy w naszym tenancie posiadamy więcej niż jedną taką strukturę (np. osobne układy hub-and-spoke z różnymi adresami publicznymi do różnych zastosowań).
Zabezpieczanie ruchu sieciowego
Tak jak wspomniałem wcześniej, każda z tych sieci ma przypisany własny NSG (reguły możemy też nakładać bezpośrednio na interfejsy sieciowe zasobów). NSG to zestaw reguł przypominający klasyczny firewall stanowy (stateful), taki jak iptables na Linuxie czy Zapora Windows. Każdej regule nadajemy priorytet – im niższy numer, tym wyższy priorytet. Reguły weryfikowane są po kolei, dlatego jeśli np. reguła z priorytetem 100 blokuje SSH, a reguła 200 na nie pozwala, to ruch i tak zostanie zablokowany. W samej regule definiujemy port, protokół, źródło oraz cel ruchu, a na końcu określamy akcję: zezwalaj (Allow) lub blokuj (Deny).
W naszej sieci typu „hub” powinien znaleźć się również firewall. Może to być natywna usługa Azure Firewall (rozwiązanie dostarczane przez Microsoft) lub rozwiązanie innego dostawcy, wybrane z Azure Marketplace (np. Fortigate Network Appliance). Firewall pełni rolę głównej bramy, która weryfikuje i filtruje cały ruch wchodzący oraz wychodzący z naszej chmury.
Azure Firewall podczas wdrażania tworzy własną, dedykowaną podsieć (o masce minimum /26, aby zapewnić odpowiednią pulę adresów dla skalowania), otrzymuje publiczny adres IP oraz prywatny adres wewnątrz swojej podsieci. Pod maską Azure Firewall to w rzeczywistości zestaw maszyn wirtualnych zarządzanych przez Virtual Machine Scale Sets (VMSS). Dzięki temu usługa może automatycznie skalować się i uruchamiać nowe instancje w zależności od natężenia ruchu. Przed nimi znajduje się wewnętrzny Load Balancer, który rozdziela ruch na poszczególne instancje – to właśnie jego adres IP jest tym prywatnym adresem, na który kierujemy ruch z naszych sieci.
Skoro mowa o kierowaniu ruchem – aby zasoby w naszych sieciach typu „spoke” prawidłowo korzystały z Azure Firewall, musimy ręcznie skonfigurować tabele tras (Azure Route Tables) i przypisać je do poszczególnych podsieci. Kluczowe jest, aby jako typ następnego przeskoku (Next hop type) wskazać „Virtual appliance” i podać prywatny adres IP naszego Azure Firewalla (lub rozwiązania innego dostawcy). Dzięki temu ruch zostanie odpowiednio przekierowany do inspekcji. Ważne jest również, aby w ustawieniach peeringu zezwolić na przesyłanie ruchu dalej (Allow gateway transit / Forwarded traffic), co umożliwi obsługę pakietów pochodzących spoza podsieci firewalla. Warto jednak pamiętać, że jeśli korzystamy z AVNM, narzędzie to może automatycznie skonfigurować te trasy za nas.
Azure Firewall dostępny jest w dwóch głównych wariantach, które różnią się zakresem dostępnych funkcjonalności:
| Standard | Premium |
| Zaawansowane filtrowanie ruchu sieciowego (L3-L7 Stateful Firewall) | Inspekcja ruchu TLS (HTTPS) |
| Kontrola ruchu na podstawie nazw domenowych (FQDN) | Wykrywanie i automatyczne blokowanie prób włamań w czasie rzeczywistym (Intrustion Detection & Prevention System)) |
| Ochrona oparta na bazie Threat Intelligence Microsoftu (blokowanie znanych złośliwych IP i domen) | Filtrowanie pełnych ścieżek URL (nie tylko domen, ale i konkretnych podstron) |
| Przepustowość maksymalnie do 30 Gbps | Przepustowość maksymalnie do 100 Gbps |
Instancjami Azure Firewall możemy również zarządzać masowo, wykorzystując Azure Firewall Manager. Narzędzie to pozwala na tworzenie scentralizowanych polityk bezpieczeństwa (Firewall Policies), które następnie przypisujemy do wielu różnych instancji firewalla jednocześnie. Takie podejście znacznie upraszcza administrację i zapewnia spójność reguł w całej infrastrukturze, choć należy pamiętać, że korzystanie z Firewall Managera wiąże się z dodatkowymi opłatami za każdą zarządzaną politykę.
Zabezpieczanie dostępu do zasobów
Gdy nasza sieć jest już zabezpieczona, musimy skupić się na ochronie samych zasobów uruchamianych w Azure. Kluczową zasadą jest ich uważna konfiguracja i blokowanie dostępu publicznego (rezygnacja z publicznych adresów IP), o ile nie jest to absolutnie wymagane biznesowo. Wszystkie zasoby powinny komunikować się za pomocą Service Endpoints (które zabezpieczają dostęp do usług na poziomie całej podsieci) lub – co jest rozwiązaniem jeszcze bezpieczniejszym – Private Endpoints (które przypisują usługom prywatne adresy IP wewnątrz sieci VNet). Dzięki temu cały ruch do naszych zasobów może być precyzyjnie kontrolowany i filtrowany przez wcześniej skonfigurowany firewall.
Integracja z siecią on-premises
Jeżeli chcemy, aby serwery hostowane on-premises w siedzibie firmy lub nasi pracownicy mogli bezpiecznie łączyć się z zasobami w Azure, musimy skonfigurować połączenie VPN typu Site-to-Site (S2S). Jest to jedna z najbezpieczniejszych form komunikacji między środowiskiem lokalnym a chmurą – cały ruch wewnątrz tunelu VPN jest szyfrowany, a urządzenia łączą się ze sobą przy użyciu prywatnych adresów IP. Aby zestawić takie połączenie, możemy wykorzystać natywną usługę Azure VPN Gateway (pamiętając o dobraniu odpowiedniego wariantu SKU do naszych potrzeb) lub to samo rozwiązanie zewnętrznego dostawcy (np. Fortigate), którego użyliśmy wcześniej do budowy firewalla w Azure.
Kluczowe jest jednak prawidłowe skonfigurowanie routingu wewnętrznego, tak aby wymusić inspekcję ruchu hybrydowego. Cała komunikacja powinna być kierowana według schematu: VPN Gateway ↔ Azure Firewall ↔ sieci Spoke. Dzięki takiemu ustawieniu każda paczka danych przesyłana z biura do naszych aplikacji w chmurze (i z powrotem) musi przejść przez firewall, co pozwala na jej pełne przefiltrowanie i monitorowanie.
Ciągłe monitorowanie bezpieczeństwa
Gdy nasze środowisko jest już bezpiecznie skonfigurowane i zintegrowane z siecią on-premises, pozostaje nam kwestia ciągłego monitoringu pod kątem utrzymania oraz bezpieczeństwa. Do monitorowania dostępności usług możemy wykorzystać natywną usługę Azure Monitor lub systemy typu open-source, takie jak Zabbix.
W przypadku bezpieczeństwa najlepiej sprawdzi się rodzina produktów Microsoft Defender (lub inny system klasy CSPM). Microsoft Defender for Cloud to zestaw narzędzi służący do monitorowania stanu bezpieczeństwa (security posture) naszych środowisk chmurowych. Jest on rozliczany za każdy zarejestrowany zasób i pozwala na objęcie ochroną całej infrastruktury cloud, a nawet systemów on-premises. Defender dostarcza informacji o nowych podatnościach wymagających naszej uwagi oraz o wykrytych próbach ataków (może je też automatycznie blokować). Wszystkie incydenty możemy dokładnie analizować, wspierając się bazą Microsoft Threat Intelligence. Dodatkowo Microsoft Defender może zostać zintegrowany z systemem SIEM, takim jak Microsoft Sentinel lub rozwiązaniem open-source (np. Wazuh), jeżeli chcemy gromadzić wszystkie alerty bezpieczeństwa z całej infrastruktury w jednym miejscu.