Bezpieczeństwo sieci

Zabezpieczenia sieci chroni obciążenia w chmurze przed zagrożeniami, takimi jak nieautoryzowany dostęp, naruszenia zabezpieczeń danych i zakłócenia usług, kontrolując ruch na wielu granicach. W przeciwieństwie do tradycyjnych obrony skoncentrowanych na perymetrze, nowoczesne środowiska chmurowe wymagają strategii obrony w głąb z segmentacją, łącznością prywatną i ochroną brzegową w celu ochrony dynamicznych powierzchni ataku, w tym uwidocznionych usług, ścieżek ruchu lateralnego i kanałów dowodzenia i kontroli. Organizacje wdrażające kompleksowe mechanizmy kontroli sieci utrzymują domyślnie bezpieczne środowiska, podczas gdy organizacje zaniedbujące te mechanizmy muszą się zmierzyć z nieograniczonym ruchem bocznym i długotrwałym narażeniem na zagrożenia.

Poniżej przedstawiono trzy podstawowe filary domeny zabezpieczeń sieci.

Zabezpieczanie granic sieci: Wymuszanie rygorystycznych mechanizmów kontroli na krawędziach sieci i między segmentami za pomocą wielowarstwowej ochrony w głębi systemu, w tym zapór DDoS, zapór aplikacji internetowych i łączności prywatnej, zgodnie z zasadą najniższych uprawnień do domyślnego odmowy nieautoryzowanego ruchu.

Powiązane kontrolki:

• NS-2: Zabezpieczanie usług w chmurze za pomocą kontrolek sieci
• NS-3: Wdrażanie zapory na brzegu sieci przedsiębiorstwa
• NS-5: Wdrażanie ochrony przed atakami DDOS
• NS-6: Wdrażanie zapory aplikacji internetowej
• NS-9: Łączenie sieci lokalnej lub chmurowej prywatnie

Zastosuj izolację sieci: Podziel sieci na segmenty izolowane dopasowane do strategii segmentacji przedsiębiorstwa i poziomów ryzyka, aby ograniczyć rozprzestrzenianie się zagrożeń, zmniejszyć obszar ataków i zapobiec nieautoryzowanemu ruchowi bocznemu.

Powiązane kontrolki:

• NS-1: Ustanawianie granic segmentacji sieci

Monitorowanie i reagowanie: Utrzymywanie ciągłego wglądu w aktywność sieci poprzez kompleksowe monitorowanie, wykrywanie nieautoryzowanego dostępu i zabezpieczenia protokołu w celu szybkiego identyfikowania podejrzanych zachowań, naruszeń zasad i aktywnych zagrożeń.

Powiązane kontrolki:

• NS-4: Wdrażanie systemów wykrywania włamań/zapobiegania włamaniom (IDS/IPS)
• NS-8: Wykrywanie i wyłączanie niezabezpieczonych usług i protokołów
• NS-10: Zapewnianie zabezpieczeń systemu nazw domen (DNS)

NS-1: Ustanawianie granic segmentacji sieci

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: NS-1.

Zasada zabezpieczeń

Segmentacja sieci obejmuje podzielenie sieci na mniejsze, izolowane segmenty w celu kontrolowania i ograniczania przepływu ruchu między zasobami chmury w celu zmniejszenia promienia wybuchu.

Zaprojektuj segmentację sieci, aby upewnić się, że wdrożenie sieci wirtualnej jest zgodne ze strategią segmentacji przedsiębiorstwa i różnymi poziomami ryzyka. Wspólna strategia segmentacji obejmuje:

• Oddzielić Corpnet za pomocą sieci aplikacji
• Oddzielne sieci aplikacji
• Oddzielne sieci środowiska produkcyjnego i testowego

Zapoznaj się z Azure Well-Architected Framework, aby dowiedzieć się więcej o kluczowych strategiach segmentacji sieci.

• Strategia segmentacji platformy Azure

Ryzyko w celu ograniczenia ryzyka

Bez granic segmentacji sieci organizacje stoją w obliczu nieograniczonego ruchu bocznego, dzięki czemu osoby atakujące mogą przechodzić przez infrastrukturę sieciową i naruszać zasoby o wysokiej wartości.

• Narażenie na płaską sieć: Brak segmentacji umożliwia nieograniczone przenoszenie boczne, dzięki czemu przeciwnicy mogą naruszyć zasoby o wysokiej wartości przez przechodzenie przez topologię sieci bez partycji.
• Ścieżki eskalacji uprawnień: Nieodpowiednie granice zezwalają na nieautoryzowane wektory dostępu, ułatwiając eskalację uprawnień użytkownika za pośrednictwem dostępu do poufnych podsieci i obciążeń.
• Propagacja złośliwego oprogramowania: Niewystarczająca segmentacja umożliwia szybkie rozprzestrzenianie się złośliwego kodu, takiego jak oprogramowanie wymuszające okup między połączonymi węzłami, wzmacnianie obszaru ataków i wpływu operacyjnego.
• Ślepota ruchu wschodnio-zachodniego: Nieograniczony ruch między segmentami utrudnia wykrywanie anomalii i reagowanie na zdarzenia, zmniejszając wgląd w wewnętrzne ruchy zagrożeń i komplikując analizę kryminalistyczną.

MITRE ATT&CK

• Dostęp początkowy (TA0001): nieautoryzowany dostęp do sieci i uwidocznionych usług (np. T1190 — Exploit Public-Facing Application).
• Ruch poprzeczny (TA0008): atak przez przemieszczanie poprzez sieci wirtualne (VNets) i ruch między podsieciami bez restrykcji (np. T1021 — usługi zdalne).
• Eksfiltracja (TA0010): eksfiltracja danych przez ruch wychodzący bez ograniczeń dla nieautoryzowanych transferów danych do serwerów zewnętrznych (np. T1041 — Eksfiltracja przez kanał C2).
• Sterowanie i kontrola (TA0011): propagacja złośliwego oprogramowania przez komunikację ze złośliwymi adresami IP lub domenami za pośrednictwem reguł zapory i analizy zagrożeń (np. T1071 — Application Layer Protocol).

NS-1.1: Tworzenie segmentacji przy użyciu sieci wirtualnej i podsieci

Izolacja sieci wirtualnej ustanawia podstawowe granice zabezpieczeń w środowiskach chmury, umożliwiając organizacjom oddzielenie obciążeń według poziomu zaufania, jednostki organizacyjnej lub grupowania aplikacji. Takie podejście zapobiega nieograniczonemu ruchowi bocznemu i zmniejsza promień wybuchu w przypadku wystąpienia naruszeń, dostosowując architekturę sieci do strategii segmentacji przedsiębiorstwa i zasad zerowego zaufania.

Zaimplementuj segmentację sieci wirtualnej, tworząc izolowane granice i podziały sieci:

• Projektowanie topologii sieci wirtualnej na podstawie strategii segmentacji: Utwórz sieci wirtualne dopasowane do stref zaufania, jednostek organizacyjnych lub grup aplikacji zdefiniowanych w strategii segmentacji przedsiębiorstwa, zapewniając, że każda sieć wirtualna reprezentuje odrębną granicę zabezpieczeń.

• Izolowanie obciążeń o wysokim ryzyku: Identyfikowanie obciążeń wymagających ścisłej izolacji (np. produkcyjnych baz danych, systemów przetwarzania płatności) i wdrażanie ich w dedykowanych, izolowanych sieciach wirtualnych w celu zminimalizowania narażenia i zapobiegania zanieczyszczeniu krzyżowemu.

• Utwórz podsieci na potrzeby szczegółowego segmentacji: W ramach każdej sieci wirtualnej utwórz odrębne podsieci nienakładające się, aby dodatkowo podzielić sieć na podstawie warstw aplikacji (np. warstwy sieci Web, warstwy aplikacji, warstwy bazy danych) lub wymagań funkcjonalnych, umożliwiając bardziej precyzyjną kontrolę ruchu i mikrosegmentację.

NS-1.2: Ograniczanie ruchu sieciowego przy użyciu sieciowej grupy zabezpieczeń

Sieciowe grupy zabezpieczeń wymuszają filtrowanie ruchu na poziomie podsieci i interfejsu sieciowego, umożliwiając precyzyjną kontrolę nad przepływami komunikacji między segmentami sieci i sieciami zewnętrznymi. Implementując politykę odmowy domyślnej z jawnymi regułami zezwalania, organizacje zapewniają, że tylko autoryzowany ruch przechodzi przez granice sieci, uniemożliwiając nieautoryzowany dostęp i zmniejszając powierzchnię ataku.

Zaimplementuj ograniczenie ruchu sieciowego przy użyciu reguł sieciowej grupy zabezpieczeń:

• Identyfikowanie wymagań dotyczących komunikacji: Przeanalizuj zasoby w każdej sieci wirtualnej, aby zrozumieć potrzeby komunikacji ruchu północno-południowego (zewnętrznego) i wschodnio-zachodniego (wewnętrznego), dokumentując wymagane porty, protokoły, adresy źródłowe i adresy docelowe dla uzasadnionych funkcji biznesowych.

• Zdefiniuj jawne reguły zezwalania i odmowy: W przypadku dobrze zdefiniowanych aplikacji (np. architektur trójwarstwowych) użyj podejścia "odmów domyślnie, zezwól na wyjątek", aby utworzyć reguły sieciowej grupy zabezpieczeń na podstawie portu, protokołu, źródłowego adresu IP i docelowego adresu IP, jawnie zezwalając tylko na niezbędny ruch, jednocześnie odmawiając wszystkich innych komunikacji.

• Użyj grup zabezpieczeń aplikacji dla złożonych scenariuszy: Gdy wiele aplikacji i punktów końcowych współdziała, upraszcza zarządzanie regułami sieciowej grupy zabezpieczeń przy użyciu grup zabezpieczeń aplikacji (ASG) do logicznego grupowania zasobów (np. serwerów sieci Web, serwerów baz danych), a następnie zdefiniuj reguły sieciowej grupy zabezpieczeń na podstawie tych grup, a nie jawnych adresów IP, zwiększając łatwość konserwacji i zmniejszając złożoność konfiguracji.

• Monitorowanie i optymalizowanie za pomocą dzienników przepływu: Włącz rejestrowanie przepływu sieci wirtualnej, aby monitorować ruch dozwolony lub blokowany przez reguły grup zabezpieczeń sieciowych (NSG), identyfikując często odrzucany ruch, który może wskazywać na błędną konfigurację, lub często dozwolony ruch, który może sugerować możliwość optymalizacji reguł i zmniejszać zbędne rejestrowanie.

Przykład implementacji

Organizacja musi zabezpieczyć aplikację wielowarstwową z oddzielnymi środowiskami produkcyjnymi, deweloperskimi i testowymi, jednocześnie uniemożliwiając nieautoryzowane przenoszenie boczne i dostęp zewnętrzny.

Wyzwanie: Organizacja miała aplikację trójwarstwową (internetową, aplikację, bazę danych) ze wszystkimi zasobami w jednym dużym segmencie sieci, umożliwiając nieograniczoną komunikację między wszystkimi warstwami i środowiskami. Spowodowało to znaczne ryzyko bezpieczeństwa, w tym potencjalne przemieszczanie się pomiędzy środowiskiem produkcyjnym i nieprodukcyjnym, nieograniczony dostęp do Internetu z serwerów baz danych oraz niemożność izolowania obciążeń o wysokim ryzyku.

Podejście do rozwiązania:

• Segmentacja sieci wirtualnej według środowiska: Utworzono oddzielne sieci wirtualne dla środowiska produkcyjnego (10.0.0.0/16), środowiska programistycznego (10.1.0.0/16) i środowiska testowego (10.2.0.0/16), ustanawiając granice izolacji sieci, które uniemożliwiają dostęp między środowiskami i ograniczają zasięg potencjalnych naruszeń.
• Segmentacja podsieci według warstwy: W ramach produkcyjnej sieci wirtualnej utworzono odrębne nienakładające się podsieci dla każdej warstwy aplikacji — warstwa internetowa (10.0.1.0/24), warstwa aplikacji (10.0.2.0/24) i warstwa bazy danych (10.0.3.0/24) — umożliwiając szczegółową kontrolę ruchu między warstwami.
• Reguły sieciowej grupy zabezpieczeń dla kontroli ruchu północno-południowego: Skonfigurowano reguły sieciowej grupy zabezpieczeń, aby blokować cały ruch przychodzący z Internetu (0.0.0.0/0) do podsieci wewnętrznych i ograniczyć wychodzący dostęp do Internetu tylko do zaufanych miejsc docelowych, przy czym określone reguły zezwalają tylko na niezbędne połączenia zewnętrzne dla warstwy sieci Web, blokując jednocześnie cały dostęp do Internetu z warstwy bazy danych.
• Reguły NSG dla kontroli ruchu pomiędzy warstwami: Zastosowano zasady domyślnego blokowania z wyraźnym zezwoleniem na ruch między warstwami — warstwa web zezwalała na ruch wychodzący do warstwy aplikacyjnej tylko na wymaganych portach, warstwa aplikacyjna zezwalała na ruch wychodzący do warstwy bazy danych tylko na porcie 1433 (SQL), a warstwa bazy danych odrzucała wszystkie inne ruchy przychodzące z wyjątkiem ruchu z podsieci warstwy aplikacyjnej.
• Dostęp do zarządzania zdalnego: Ograniczone porty zarządzania zdalnego (RDP 3389/TCP, SSH 22/TCP) do akceptowania połączeń tylko z zaufanej podsieci hosta bastionu (10.0.0.0/26), eliminując bezpośredni dostęp do Internetu do interfejsów zarządzania.

Wynik: Organizacja wyeliminowała nieograniczony ruch poprzeczny między warstwami aplikacji i środowiskami, znacznie zmniejszyła obszar ataków przez usunięcie bezpośredniego dostępu do Internetu z systemów zaplecza i ustanowiono wymuszone granice sieci zgodne z zasadami zerowego zaufania. Dzienniki przepływu umożliwiają ciągłe monitorowanie dozwolonego i odrzuconego ruchu na potrzeby ciągłej optymalizacji i walidacji stanu zabezpieczeń.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-7, SC-32, AC-4, CM-7
• PCI-DSS 4: 1.2.1, 1.3.1, 1.4.1
• Kontrolki CIS w wersji 8.1: 12.1, 12.2, 12.6
• NIST CSF v2.0: PR.IR-01, PR.AC-05
• ISO 27001:2022: A.8.20, A.8.21
• SOC 2: CC6.1, CC6.6

NS-2: Zabezpieczanie usług natywnych dla chmury za pomocą kontrolek sieci

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: NS-2.

Zasada zabezpieczeń

Użyj funkcji natywnych usługi, aby zabezpieczyć dostęp sieciowy do zasobów, aby uniknąć i zmniejszyć narażenie zasobów na niezaufaną sieć. Do tych funkcji należą:

• Ustanów prywatne punkty dostępu dla zasobów, aby uniknąć narażenia na ruch sieciowy przechodzący przez sieć publiczną.
• Wdróż zasób w sieciach wirtualnych, w których można ograniczyć sieć wirtualną do ustanowienia prywatnego punktu dostępu dla usługi.
• Skonfiguruj zapory natywne dla usługi, aby ograniczyć ruch przychodzący lub wyłączyć dostęp do sieci publicznej.

Uwaga: oprócz podstawowej kontroli dostępu do sieci i filtrowania ruchu należy również używać funkcji wykrywania zagrożeń do monitorowania usług, takich jak DNS (NS-10), aby wykryć możliwe eksfiltrację danych.

Ryzyko w celu ograniczenia ryzyka

Aktorzy zagrożeń wykorzystują publicznie uwidocznione usługi w chmurze do przeprowadzania eksfiltracji danych, ataków warstwy aplikacji i przechwytywania ruchu.

• Eksfiltracja danych za pośrednictwem publicznych punktów końcowych: Osoby atakujące wykorzystują publicznie dostępne konta magazynu, bazy danych lub interfejsy API do eksfiltrowania poufnych danych przez ustanowienie nieautoryzowanych połączeń z uwidocznionych punktów końcowych, pomijając mechanizmy kontroli segmentacji sieci i włączając kradzież danych na dużą skalę.
• Ataki w warstwie aplikacji na publiczne punkty końcowe: Ataki typu "rozproszona odmowa usługi" (DDoS), wstrzyknięcie kodu SQL i inne aplikacje wykorzystują publiczne uwidocznione usługi internetowe, interfejsy API i bazy danych, przytłaczające zasoby lub luki w zabezpieczeniach wykorzystujące luki w zabezpieczeniach w celu spowodowania zakłóceń w działaniu usługi lub naruszenia zabezpieczeń danych.
• Ataki typu man-in-the-middle: Osoby atakujące przechwytują ruch przepływający przez sieci publiczne do usług publicznie dostępnych, przechwytując poświadczenia, tokeny sesji lub dane poufne przesyłane bez odpowiedniego szyfrowania lub łączności prywatnej, co umożliwia przejęcie konta bądź kradzież danych.

MITRE ATT&CK

• Dostęp początkowy (TA0001): nieautoryzowany dostęp wynikający z publicznego ujawnienia usług w chmurze w Internecie (np. usługi przechowywania w chmurze, usługi baz danych), wykorzystanie atakujące publiczne punkty końcowe (np. T1190 — Wykorzystanie aplikacji o publicznym dostępie).
• Eksfiltracja (TA0010): eksfiltracja danych przez kierowanie ruchu za pośrednictwem prywatnych połączeń sieci wirtualnej, co zmniejsza ryzyko wycieku danych do serwerów zewnętrznych (np. T1041 — Eksfiltracja za pośrednictwem kanału C2).
• Ruch poprzeczny (TA0008): atakujący przemieszcza się między usługami w sieciach wirtualnych, uzyskując nieautoryzowany dostęp między zasobami w chmurze (np. T1021 — usługi zdalne).

NS-2.1 Użyj usługi Private Link do połączenia z usługą

Łączność prywatna eliminuje publiczne narażenie na internet dla usług w chmurze poprzez ustanowienie bezpośrednich ścieżek sieciowych w ramach infrastruktury wirtualnej. Usługa Private Link tworzy prywatne punkty końcowe z dedykowanymi adresami IP wewnątrz sieci wirtualnych, zapewniając, że ruch do usług w chmurze nigdy nie przechodzi przez publiczny Internet przy zachowaniu wzorców dostępu opartych na systemie DNS. Takie podejście znacznie zmniejsza obszar ataków i zapobiega eksfiltracji danych za pośrednictwem publicznie dostępnych punktów końcowych.

Zaimplementuj łączność prywatną dla usług w chmurze, wykonując następujące kroki:

• Wdrażanie prywatnych punktów końcowych dla obsługiwanych usług: Tworzenie prywatnych punktów końcowych w sieci wirtualnej dla zasobów platformy Azure obsługujących usługę Private Link (np. Azure Storage, Azure SQL Database, Azure Key Vault), ustanawianie prywatnych adresów IP (np. 10.0.2.4) dostępnych tylko z sieci wirtualnej.

• Konfigurowanie prywatnych stref DNS: Utwórz prywatne strefy DNS na platformie Azure, aby zastąpić publiczne rozwiązywanie nazw DNS, zapewniając, że nazwy domen w pełni kwalifikowane (FQDN), takie jak mystorageaccount1.blob.core.windows.net, są rozwiązywane w prywatne adresy IP w Twojej sieci VNet zamiast w publiczne punkty końcowe, dzięki czemu aplikacje korzystające z dostępu opartego na FQDN mają zapewnioną bezproblemową łączność.

• Wyłącz dostęp publiczny: Skonfiguruj ustawienia na poziomie usługi, aby całkowicie wyłączyć dostęp do sieci publicznej po wdrożeniu prywatnych punktów końcowych, zapewniając, że cały ruch przepływa wyłącznie za pośrednictwem łączności prywatnej bez powrotu do publicznych punktów końcowych.

Nuta: Niektóre usługi platformy Azure mogą również zezwalać na prywatną komunikację za pośrednictwem funkcji punktu końcowego usługi , chociaż usługa Azure Private Link jest zalecana do bezpiecznego i prywatnego dostępu do usług hostowanych na platformie Azure. W przypadku wdrożeń, takich jak usługi internetowe hostowane na maszynach wirtualnych platformy Azure, unikaj przypisywania publicznych adresów IP bezpośrednio do maszyn wirtualnych, chyba że są to zdecydowanie uzasadnione; Zamiast tego użyj usługi Azure Application Gateway lub Azure Load Balancer jako frontonu na potrzeby dostępu do usługi.

NS-2.2 Wdrażanie usługi w sieci wirtualnej

Integracja sieci wirtualnej umożliwia usługom w chmurze działanie w granicach sieci prywatnej, ustanawianie bezpośredniej łączności z zasobami hostowanymi przez sieć wirtualną bez publicznej ekspozycji na Internet. Wdrażając usługi w sieciach wirtualnych, organizacje uzyskują szczegółową kontrolę nad ruchem sieciowym za pośrednictwem grup zabezpieczeń i tabel tras przy zachowaniu izolacji usług przed zagrożeniami zewnętrznymi.

Wdróż usługi za pomocą integracji z VNet, gdzie jest dostępna.

• Wdrażanie usług w sieciach wirtualnych: W przypadku usług obsługujących integrację z siecią wirtualną (np. Azure App Service, Azure Functions, Azure Container Instances), skonfiguruj wdrożenie w nowych lub istniejących sieciach wirtualnych, określając odpowiednie podsieci dostosowane do strategii segmentacji i włączając prywatną komunikację z innymi zasobami sieci wirtualnej.

• Konfigurowanie mechanizmów kontroli zabezpieczeń sieci: Zastosuj reguły sieciowej grupy zabezpieczeń do podsieci usługi w celu ograniczenia ruchu przychodzącego i wychodzącego, implementując dostęp z najmniejszymi uprawnieniami, zezwalając na komunikację tylko z określonymi miejscami docelowymi (np. podsieciami bazy danych, punktami końcowymi magazynu) podczas odmowy całego innego ruchu.

NS-2.3 Konfigurowanie zapory natywnej usługi

Zapory na poziomie usługi zapewniają ochronę w głębi systemu, ograniczając dostęp do sieci na poziomie zasobów, uzupełniając mechanizmy kontroli warstwy sieciowej granicami zabezpieczeń specyficznymi dla aplikacji. Te natywne możliwości zapory umożliwiają organizacjom ograniczenie narażenia na określone zakresy adresów IP lub sieci wirtualne, jednocześnie całkowicie wyłączając dostęp publiczny w razie potrzeby, zmniejszając obszar ataków bez konieczności wprowadzania złożonych zmian topologii sieci.

Konfigurowanie zapór usługi w celu ograniczenia dostępu:

• Włączanie funkcji zapory usługi: W przypadku usług obsługujących zapory natywne (np. Azure Storage, Azure SQL Database, Azure Key Vault) włącz funkcję zapory podczas tworzenia zasobów lub istniejących zasobów, aby kontrolować, które sieci mogą uzyskiwać dostęp do usługi.

• Zdefiniuj reguły oparte na adresach IP lub sieci wirtualnej: Skonfiguruj reguły zapory, aby zezwolić na dostęp tylko z określonych zakresów publicznych adresów IP (np. sieci firmowych) lub określonych podsieci sieci wirtualnych platformy Azure, implementując dostęp z najmniejszymi uprawnieniami, odmawiając wszystkich innych źródeł.

• Wyłącz dostęp publiczny, jeśli to możliwe: Jeśli usługi wymagają dostępu tylko z sieci prywatnych, użyj opcji przełącznika, aby całkowicie wyłączyć dostęp do sieci publicznej, zapewniając, że usługa jest niedostępna z Internetu niezależnie od reguł opartych na adresach IP.

NS-2.4 Użyj obwodu zabezpieczeń sieci na potrzeby izolacji zasobów PaaS

Obwód zabezpieczeń sieci ustanawia granicę sieci logicznej wokół wielu zasobów PaaS, umożliwiając bezpieczną komunikację między usługami w ramach jawnego zaufanego obwodu, zapobiegając nieautoryzowanej eksfiltracji danych. W przeciwieństwie do mechanizmów kontroli poszczególnych zasobów obwód zabezpieczeń sieci zapewnia ujednoliconą granicę zabezpieczeń, umożliwiając komunikację wewnątrz obwodową bez reguł dostępu indywidualnego, blokując domyślnie dostęp zewnętrzny.

Zaimplementuj obwód zabezpieczeń sieci, aby zabezpieczyć zasoby PaaS:

• Tworzenie i kojarzenie zasobów: Ustanów obwód zabezpieczeń sieci i dodaj obsługiwane zasoby PaaS (Azure Storage, SQL Database, Key Vault, Event Hubs, Cosmos DB) za pomocą skojarzeń zasobów, umożliwiając komunikację wewnątrz obwodową, w której skojarzone zasoby mogą swobodnie komunikować się.

• Konfigurowanie trybów dostępu i reguł: Zacznij od trybu przejścia, aby zrozumieć wzorce dostępu przed przejściem do trybu wymuszonego w celu uzyskania maksymalnej ochrony. Zdefiniuj jawne reguły dostępu przychodzącego i wychodzącego przy użyciu adresów IP, subskrypcji lub nazw FQDN w celu kontrolowania ruchu poza obwodem przy zachowaniu stanu odmowy domyślnej.

• Włącz monitorowanie i integrację usługi Private Link: Skonfiguruj dzienniki diagnostyczne w celu przechwytywania prób dostępu i naruszeń zasad. Ruch prywatnego punktu końcowego jest automatycznie dozwolony w perymetrze, uzupełniając łączność między sieciami wirtualnymi za pomocą kontroli eksfiltracji danych na poziomie perymetru.

Przykład implementacji

Organizacja musiała zabezpieczyć zasoby baz danych zaplecza serwera i magazynu przy jednoczesnym umożliwieniu dostępu usługom aplikacji bez udostępniania zasobów publicznemu internetowi.

Wyzwanie: Organizacja miała konta usługi Azure SQL Database i Azure Storage z domyślnymi publicznymi punktami końcowymi, umożliwiając im dostęp z Internetu i tworząc znaczące zagrożenia eksfiltracji danych. Usługi aplikacji zostały wdrożone z publicznymi adresami IP i brakowało integracji z siecią wirtualną, uniemożliwiając kontrolę dostępu opartą na sieci prywatnej. Zapory na poziomie usługi nie zostały skonfigurowane, umożliwiając nieograniczony dostęp z dowolnego źródła po pomyślnym uwierzytelnieniu.

Podejście do rozwiązania:

• Punkty końcowe Private Link dla usług PaaS: Wdrożone prywatne punkty końcowe dla usługi Azure SQL Database (przypisany prywatny adres IP 10.0.2.4) i konto usługi Azure Storage (przypisany prywatny adres IP 10.0.2.5) w dedykowanej podsieci prywatnego punktu końcowego (10.0.2.0/24), ustanawiając łączność prywatną, kierując ruch przez sieć szkieletową platformy Azure bez narażenia na Internet.
• Prywatne strefy DNS do rozpoznawania nazw: Utworzono prywatne strefy DNS platformy Azure , aby zastąpić publiczne rozpoznawanie nazw DNS, zapewniając, że nazwy FQDN aplikacji (np. mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) rozpoznają prywatne adresy IP w sieci wirtualnej, a nie publiczne punkty końcowe, zapewniając bezproblemową łączność dla aplikacji korzystających z dostępu opartego na nazwie FQDN.
• Integracja z siecią wirtualną dla usług aplikacji: Skonfigurowano integrację sieci wirtualnej dla usługi Azure App Service, wdrażając aplikację w podsieci aplikacji (10.0.1.0/24), aby umożliwić bezpośrednią komunikację z prywatnymi punktami końcowymi bez konieczności używania publicznych adresów IP lub routingu internetowego.
• Zapory natywne dla usługi: Włączono zapory na poziomie usługi w Azure Storage w celu ograniczenia dostępu do określonych podsieci sieci wirtualnej (podsieć aplikacji 10.0.1.0/24) i zaufanych usług firmy Microsoft, przy jednoczesnym całkowitym wyłączeniu dostępu do sieci publicznej na poziomie usługi Azure SQL Database, aby wymusić łączność wyłącznie prywatną.
• Reguły sieciowej grupy zabezpieczeń dotyczące ochrony w głębi systemu: Zastosowano reguły sieciowej grupy zabezpieczeń do podsieci aplikacji zezwalającej na ruch wychodzący tylko do podsieci prywatnego punktu końcowego (10.0.2.0/24) na wymaganych portach (443 dla usługi Storage, 1433 dla programu SQL), wdrażając kontrolę dostępu z najmniejszymi uprawnieniami, która uzupełnia zabezpieczenia na poziomie usługi.

Wynik: Organizacja wyeliminowała publiczne narażenie na internet dla zasobów zaplecza, znacznie zmniejszając ryzyko eksfiltracji danych i powierzchnię ataków. Łączność prywatna zapewniała, że cały ruch między aplikacjami i usługami danych pozostał w sieci szkieletowej platformy Azure bez przechodzenia przez publiczny Internet, a warstwowe kontrolki (Private Link, strefy DNS, zapory usług, sieciowe grupy zabezpieczeń) zapewniły ochronę w głąb zgodnie z zasadami zerowego zaufania.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-7(4), SC-7(5), AC-4(21)
• PCI-DSS 4: 1.3.1, 1.3.2, 1.4.2
• Kontrolki CIS w wersji 8.1: 12.4, 12.7
• NIST CSF v2.0: PR.AC-05, PR.DS-05
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6

NS-3: Wdrażanie zapory na brzegu sieci przedsiębiorstwa

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: NS-3.

Zasada zabezpieczeń

Zapora na brzegu sieci umożliwia zaawansowane filtrowanie ruchu sieciowego do i z sieci zewnętrznych, takich jak Internet i między segmentami sieci wewnętrznej.

Co najmniej zasady zapory powinny obejmować następujące elementy:

• Blokuj znane złe adresy IP i witryny.
• Ogranicz protokoły wysokiego ryzyka, takie jak protokoły zdalnego zarządzania i protokoły intranetowe w sieciach brzegowych, aby zapobiec nieautoryzowanemu dostępowi lub penetracji sieci.
• Wymuszaj reguły aplikacji, aby zezwalać tylko na zatwierdzone zewnętrzne miejsca docelowe i blokować nieautoryzowane lub ryzykowne witryny.

Ryzyko w celu ograniczenia ryzyka

Atakujący wykorzystują ujawnione luki w zabezpieczeniach w publicznych lub niezaufanych sieciach poprzez dostępne protokoły, złośliwe domeny i słabe mechanizmy kontroli sieci.

• Nieautoryzowany dostęp za pośrednictwem uwidocznionych protokołów: Publicznie dostępne protokoły, takie jak RDP (TCP 3389) lub SMB (TCP 445), umożliwiają osobom atakującym uzyskanie nieautoryzowanego wpisu, naruszenie integralności systemu poprzez luki w zabezpieczeniach, takie jak ataki siłowe lub ataki ukierunkowane na CVE.
• Złośliwe oprogramowanie i wyłudzanie informacji za pośrednictwem złośliwych domen/adresów IP: Złośliwe domeny i adresy IP ułatwiają dostarczanie złośliwego oprogramowania lub kampanie wyłudzające informacje, zagrażając punktom końcowym i poufnym danym poprzez ataki poleceń i kontroli lub inżynierii społecznej.
• Eksfiltracja danych przez nieograniczony ruch wychodzący: Niekontrolowany ruch wychodzący do niezatwierdzonych miejsc docelowych umożliwia przeciwnikom eksfiltrację poufnych danych, ryzykując naruszenia zabezpieczeń i zgodności za pośrednictwem ukrytych kanałów, takich jak żądania HTTPS POST.
• Ruch poprzeczny ze względu na słabą segmentację: Niewystarczająca segmentacja sieci umożliwia osobie atakującej przestawienie się wewnętrznie, wykorzystanie ruchu między segmentami (np. SMB, Kerberos) w celu propagowania z naruszonych systemów.
• Zagrożenia związane z niezaufanymi aplikacjami/adresami URL: Dostęp do ryzykownych lub niezaufanych adresów URL i aplikacji zwiększa wystawienie na ataki, podnosząc ryzyko incydentów i naruszenia norm prawnych.

MITRE ATT&CK

• Dostęp początkowy (TA0001): nieautoryzowany dostęp do protokołów wysokiego ryzyka (np. RDP/TCP 3389, SSH/TCP 22) lub złośliwych domen (np. T1190 — Wykorzystanie Public-Facing aplikacji).
• Command and Control (TA0011): złośliwe oprogramowanie łączące się ze złośliwymi adresami IP/domenami (np. T1071 — Application Layer Protocol).
• Eksfiltracja (TA0010): nieautoryzowane transfery danych za pośrednictwem ruchu wychodzącego do niezatwierdzonych miejsc docelowych (np. T1041 — Eksfiltracja za pośrednictwem kanału C2).
• Ruch poprzeczny (TA0008): hamuje wewnętrzne pivotowanie przez niefiltrowany ruch między segmentami (np. SMB/TCP 445, Kerberos/TCP 88) (np. T1021 — Usługi Zdalne).

NS-3.1 Przygotowanie do wdrożenia zapory Azure

Wdrożenie usługi Azure Firewall wymaga odpowiedniej topologii sieci umożliwiającej scentralizowaną inspekcję ruchu w granicach sieci. Architektury typu hub-and-spoke umieszczają zaporę sieciową w rdzeniu sieci, przekierowując cały ruch po szprychach przez centralny punkt kontroli, podczas gdy trasy zdefiniowane przez użytkownika zapewniają, że przepływ ruchu jest zgodny z zamierzonymi ścieżkami. To przygotowanie ustanawia podstawę kompleksowej ochrony krawędzi i filtrowania między segmentami.

Przygotowanie infrastruktury sieciowej do wdrożenia usługi Azure Firewall:

• Skonfiguruj topologię sieci wirtualnej typu hub/spoke: Wdróż usługę Azure Firewall w sieci wirtualnej hub w celu centralnego zarządzania i zabezpieczania ruchu w wielu sieciach wirtualnych typu spoke, które hostują obciążenia aplikacyjne, tworząc pojedynczy punkt egzekwowania zasad bezpieczeństwa sieciowego.

• Dołącz do sieci wirtualnych spoke: Użyj połączenia równorzędnego VNet do połączenia każdej sieci wirtualnej spoke z siecią wirtualną piasty, w której wdrożono usługę Azure Firewall, umożliwiając komunikację między spoke za pośrednictwem piasty przy zachowaniu izolacji sieci.

• Konfigurowanie tras zdefiniowanych przez użytkownika (UDR): Utwórz tabele tras kierujące ruch sieciowy z sieci wirtualnych typu spoke za pośrednictwem usługi Azure Firewall w sieci centralnej, w tym trasy dla ruchu wychodzącego do Internetu (0.0.0.0/0) i opcjonalnie ruchu między szprychami, jeśli komunikacja między szprychami wymaga inspekcji.

NS-3.2 Wdrażanie usługi Azure Firewall przy użyciu odpowiednich zasad

Usługa Azure Firewall zapewnia stanowe filtrowanie ruchu w warstwie aplikacji za pomocą scentralizowanego zarządzania zasadami w segmentach sieci przedsiębiorstwa. Łącząc reguły sieciowe, reguły aplikacji i analizę zagrożeń, zapory sprawdzają przepływy ruchu w wielu warstwach, podczas gdy filtrowanie adresów URL i inspekcja protokołu TLS umożliwiają szczegółową kontrolę nad komunikacją HTTP/HTTPS. Odpowiedni projekt zasad równoważy wymagania dotyczące zabezpieczeń z potrzebami operacyjnymi za pomocą hierarchii reguł ustrukturyzowanych i filtrowania opartego na kategoriach.

Wdrażanie i konfigurowanie usługi Azure Firewall przy użyciu kompleksowych zasad:

• Wdrażanie usługi Azure Firewall w sieci wirtualnej koncentratora: Wdróż usługę Azure Firewall (warstwa Standardowa lub Premium na podstawie wymaganych funkcji) w sieci wirtualnej koncentratora, przypisując zarówno publiczne adresy IP dla ruchu do internetu, jak i prywatne adresy IP na potrzeby wewnętrzny routing z sieci wirtualnych podległych.

• Utwórz zasady zapory z regułami filtrowania: Zdefiniuj zasady usługi Azure Firewall zawierające reguły sieciowe (filtrowanie oparte na adresach IP/portach), reguły aplikacji (filtrowanie oparte na nazwie FQDN) i reguły analizy zagrożeń, organizując reguły w kolekcje na podstawie wymagań dotyczących zabezpieczeń (np. zezwalaj na usługi krytyczne dla działania firmy, blokuj złośliwe adresy IP, odmawiaj ryzykownych kategorii).

• Skonfiguruj filtrowanie adresów URL dla ruchu HTTP/HTTPS: Zaimplementuj reguły aplikacji oparte na nazwie FQDN , aby zezwalać na określone domeny (np. zezwalać na *.microsoft.com, odmawiać *.torrent) i skonfigurować filtrowanie oparte na kategorii , aby blokować całe kategorie witryn internetowych (np. Hacking, Social Media) przy jednoczesnym zezwalaniu na kategorie związane z pracą.

• Włącz inspekcję protokołu TLS na potrzeby zaawansowanego filtrowania: W przypadku wdrożeń w warstwie Premium włącz inspekcję protokołu TLS , przekazując certyfikaty do usługi Azure Key Vault, umożliwiając zaporze odszyfrowywanie, inspekcję i ponowne szyfrowanie ruchu HTTPS w celu dokładniejszego filtrowania adresów URL i wykrywania zagrożeń poza inspekcją opartą na sieci SNI.

Przykład implementacji

Organizacja z wieloma obciążeniami roboczymi aplikacji w różnych sieciach wirtualnych typu 'spoke' wymagała scentralizowanej inspekcji bezpieczeństwa sieci dla całego ruchu powiązanego z Internetem i komunikacji między sieciami 'spoke', oraz uniemożliwienia dostępu do złośliwych domen i nieautoryzowanych kategorii witryn internetowych.

Wyzwanie: Organizacja miała obciążenia wdrożone w oddzielnych sieciach VNets typu spoke z bezpośrednim dostępem do Internetu, co prowadzi do niespójnych zasad zabezpieczeń i braku możliwości centralnego sprawdzania ruchu. Każda szprycha miała własne reguły sieciowej grupy zabezpieczeń, co prowadzi do rozbieżności polityki i luk w zabezpieczeniach. Nie było wglądu w połączenia wychodzące z potencjalnie złośliwymi domenami, brak możliwości blokowania ryzykownych kategorii witryn internetowych (mediów społecznościowych, udostępniania plików) i bez inspekcji zawartości ruchu HTTPS. Ruch między węzłami swobodnie przepływał bez kontroli, umożliwiając potencjalne przemieszczanie boczne po naruszeniu integralności systemu.

Podejście do rozwiązania:

• Topologia gwiaździsta ze scentralizowaną zaporą: Wdrożono Azure Firewall Premium w centralnej sieci wirtualnej (10.0.0.0/16) z dedykowaną podsiecią AzureFirewallSubnet (10.0.1.0/26, prywatny adres IP zapory 10.0.1.4), ustanawiając jeden punkt egzekwowania dla inspekcji ruchu sieciowego i zarządzania zasadami.
• Peering VNet dla łączności ramion: Użyto peeringu VNet do łączenia sieci wirtualnej będącej ramieniem aplikacji (10.1.0.0/16) i sieci wirtualnej będącej ramieniem bazy danych (10.2.0.0/16) z siecią wirtualną piasty, co umożliwia scentralizowany routing ruchu przez zaporę.
• Trasy zdefiniowane przez użytkownika do kierowania ruchem: Utworzono tabele tras w każdej sieci wirtualnej typu spoke, które przekierowują cały ruch skierowany do Internetu (0.0.0.0/0) i ruch między sieciami typu spoke do prywatnego IP Azure Firewall (10.0.1.4), wymuszając, aby cały ruch wychodzący przechodził przez centralny punkt inspekcji.
• Zasady zapory z filtrowaniem wielowarstwowym: Zdefiniowano kompleksowe zasady usługi Azure Firewall, w tym reguły sieciowe (zezwalać na używanie protokołu DNS UDP/53 w usłudze Azure DNS, domyślnie odrzucać wszystkie inne protokoły), reguły aplikacyjne (zezwalać na używanie nazw FQDN kluczowych dla działalności firmy, takich jak *.microsoft.com, odmawiać dostępu do domen udostępniania plików, takich jak *.torrent), oraz reguły inteligencji zagrożeń (blokować znane złośliwe adresy IP z kanałów informacyjnych zagrożeń Microsoft Defender).
• Filtrowanie adresów URL i blokowanie oparte na kategorii: Zaimplementowano reguły aplikacji oparte na nazwie FQDN na potrzeby precyzyjnej kontroli domeny i filtrowania opartego na kategorii w celu blokowania całych kategorii witryn internetowych (Hacking, Social Media, Hazard) przy jednoczesnym zezwalaniu na kategorie związane z pracą (Business/Economy, Technology/Internet), wymuszając akceptowalne zasady użytkowania na brzegu sieci.
• Inspekcja protokołu TLS dla ruchu HTTPS: Włączono inspekcję protokołu TLS z certyfikatami przechowywanymi w usłudze Azure Key Vault, umożliwiając zaporze odszyfrowywanie, inspekcję i ponowne szyfrowanie ruchu HTTPS w celu uzyskania dokładniejszego filtrowania adresów URL i wykrywania zagrożeń poza inspekcją opartą na sieci SNI, a jednocześnie wykluczanie poufnych domen bankowych z odszyfrowywania zgodnie z wymaganiami dotyczącymi zgodności.

Wynik: Organizacja ustanowiła scentralizowany wgląd i kontrolę nad całym ruchem do Internetu i ruchem inter-segmentowym, eliminując odchylenie od zasad oraz luki w zabezpieczeniach. Inspekcja protokołu TLS umożliwiała wykrywanie zagrożeń ukrytych w zaszyfrowanym ruchu HTTPS, podczas gdy filtrowanie oparte na kategoriach znacznie zmniejszyło narażenie na ryzykowną zawartość internetową. Architektura hub-and-spoke zapewnia skalowalną, spójną postawę zabezpieczeń we wszystkich obciążeniach z jednolitą polityką zarządzania i kompleksową ochroną przed zagrożeniami.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), AC-4, SI-4(4)
• PCI-DSS 4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
• CIS Controls w wersji 8.1: 9.2, 9.3, 13.1
• NIST CSF v2.0: PR.AC-05, PR.PT-04, DE.CM-01
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6, CC7.2

NS-4: Wdrażanie systemów wykrywania włamań/zapobiegania włamaniom (IDS/IPS)

Zasada zabezpieczeń

Użyj systemów wykrywania włamań i zapobiegania włamaniom (IDS/IPS), aby analizować ruch sieciowy i dane przesyłane do i z obciążenia lub sieci wirtualnych. Upewnij się, że usługa IDS/IPS jest zawsze dostrojona w celu zapewnienia wysokiej jakości alertów w rozwiązaniu SIEM.

Uwaga: Aby uzyskać bardziej szczegółowe funkcje wykrywania i zapobiegania na poziomie hosta, należy użyć hostowych systemów IDS/IPS lub rozwiązania EDR (Endpoint Detection and Response) w połączeniu z sieciowymi systemami IDS/IPS.

Ryzyko w celu ograniczenia ryzyka

Przeciwnicy wykorzystują luki w zabezpieczeniach protokołów, aplikacji i ruchu wewnętrznego w celu wykonywania złośliwych działań.

• Luki w zabezpieczeniach protokołu: Luki w zabezpieczeniach protokołów, takich jak RDP (TCP 3389) lub HTTP/HTTPS (TCP 80/443), umożliwiają nieautoryzowany dostęp lub naruszenie systemu za pośrednictwem luk w zabezpieczeniach, takich jak ataki ukierunkowane na CVE.
• Komunikacja poleceń i kontroli (C2): Złośliwe serwery ustanawiają kontrolę nad zagrożonymi urządzeniami za pośrednictwem zapytań DNS lub wywołań zwrotnych opartych na adresach IP, ułatwiając trwałe wykorzystywanie lub propagację złośliwego oprogramowania.
• Luki w zabezpieczeniach aplikacji: Ataki, takie jak wstrzykiwanie SQL, skrypty między witrynami (XSS) lub przepełnienie buforu, które celują w luki aplikacji, mogą prowadzić do kradzieży danych lub wykonania dowolnego kodu.
• Ruch poprzeczny: Nietypowy ruch wewnętrzny, taki jak enumeracja SMB (TCP 445) lub nadużycie biletu Kerberos (TCP 88), sygnalizuje, że osoba atakująca manewruje w sieci.
• Eksfiltracja danych: Nieautoryzowane transfery danych są przesyłane za pośrednictwem zaszyfrowanych kanałów (np. HTTPS POST) lub ruchu wychodzącego o dużej ilości przy użyciu zaciemnienia w celu uniknięcia wykrycia.

MITRE ATT&CK

• Dostęp początkowy (TA0001): nieautoryzowane włamania za pośrednictwem luk w zabezpieczeniach sieciowych (np. T1190 — Exploit Public-Facing Application).
• Wykonywanie (TA0002): wykonanie złośliwego kodu wynikającego z wykorzystania luk w zabezpieczeniach lub ładunków C2 (np. T1059 — interpreter poleceń i skryptów).
• Sterowanie i kontrola (TA0011): komunikacja złośliwego oprogramowania C2 przy użyciu zapytań DNS lub wywołań zwrotnych opartych na adresach IP (np. T1071 — Application Layer Protocol).
• Ruch poprzeczny (TA0008): nietypowy ruch wewnętrzny (np. wyliczenie SMB) wskazuje na przestawienie (np. T1021 — usługi zdalne).
• Eksfiltracja (TA0010): nieautoryzowane transfery danych za pośrednictwem zaszyfrowanych lub zaciemnionych kanałów (np. T1041 — Eksfiltracja za pośrednictwem kanału C2).

NS-4.1 Wdrożenie Azure Firewall Premium dla IDPS

Systemy wykrywania i zapobiegania włamaniom zapewniają identyfikację zagrożeń opartą na sygnaturach przez dopasowanie wzorców ruchu sieciowego przed znanymi sygnaturami ataków, umożliwiając blokowanie prób wykorzystania luk w zabezpieczeniach i złośliwej komunikacji w czasie rzeczywistym. Funkcja IDPS usługi Azure Firewall Premium oferuje stale aktualizowane biblioteki sygnatur obejmujące eksploity, złośliwe oprogramowanie, dowodzenie i kontrolę oraz kategorie wyłudzania informacji, jednocześnie obsługując tryby tylko alertów i zapobiegania. Prawidłowy wybór podpisów i dostrajanie zapewnia wysoką dokładność wykrywania przy jednoczesnej redukcji liczby fałszywych alarmów.

Wdrażanie i konfigurowanie systemu wykrywania i zapobiegania włamaniom (IDPS) z pomocą usługi Azure Firewall Premium:

• Wdrażanie usługi Azure Firewall — wersja Premium: Wdróż usługę Azure Firewall Premium z zasadami Premium w sieci wirtualnej centrum, aby włączyć funkcje idPS wraz z innymi zaawansowanymi funkcjami, takimi jak inspekcja protokołu TLS i filtrowanie adresów URL.

• Wybierz reguły sygnatur IDPS: Wybierz reguły sygnatur IDPS z biblioteki podpisów na podstawie priorytetów zagrożeń, począwszy od podpisów o wysokiej ważności w krytycznych kategoriach, takich jak "Złośliwe oprogramowanie", "Luki" i "Wyłudzanie informacji", które są zgodne z profilem zagrożenia i tolerancją ryzyka w organizacji.

• Konfigurowanie trybu IDPS: Ustaw tryb IDPS na tryb alertu początkowo na potrzeby testowania i dostrajania w celu obserwowania dopasowań podpisów bez blokowania ruchu, a następnie przejdź do trybu alertów i odmowy dla środowisk produkcyjnych, aby aktywnie zapobiegać wykrytym zagrożeniom przy zachowaniu alertów na potrzeby monitorowania zabezpieczeń.

• Dostosuj podpisy: Dostosuj poszczególne reguły sygnatur na podstawie doświadczenia operacyjnego, wyłączając lub równocześnie obniżając priorytet podpisów generujących nadmierne wyniki fałszywie dodatnie, zapewniając jednocześnie, że sygnatury o wysokim priorytecie pozostają aktywne, optymalizując stosunek sygnału do szumu dla zespołów ds. operacji zabezpieczeń.

Przykład implementacji

Organizacja musiała chronić infrastrukturę krytyczną przed znanymi exploitami i atakami zero-day, zachowując wgląd w aktywność zagrożeń, bez zakłócania legalnej działalności biznesowej.

Wyzwanie: Organizacja obsługiwała wielowarstwową aplikację internetową przetwarzaną transakcje finansowe bez wykrywania zagrożeń opartego na podpisie poza podstawowymi regułami zapory. Zespoły ds. zabezpieczeń nie miały wglądu w próby wykorzystania luk w zabezpieczeniach na serwerach aplikacji, nie miały możliwości wykrywania komunikacji typu command-and-control oraz otrzymywały fałszywe alarmy z ogólnych rozwiązań IDS wymagających gruntownego dostrajania.

Rozwiązanie:

• Azure Firewall Premium z systemem IDPS: Wdrożono Azure Firewall Premium w sieci wirtualnej koncentratora, umożliwiając funkcjonalność IDPS wraz z inspekcją TLS i filtrowaniem adresów URL, ustanawiając scentralizowane wykrywanie zagrożeń oparte na podpisach dla całego ruchu w sieciach typu szprycha.

• Wybór reguły sygnatur: Wybrane sygnatury IDPS o wysokiej surowości z kategorii krytycznych, w tym Złośliwe Oprogramowanie (Cobalt Strike, Metasploit, ransomware C2), Exploits (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), Phishing (zbieranie poświadczeń) oraz wzorce poleceń i kontroli.

• Tryb alertu i strojenie: Skonfigurowano IDPS w trybie alertu na potrzeby testowania początkowego, aby obserwować dopasowania sygnatur bez blokowania ruchu, analizować alerty w celu identyfikowania fałszywych wyników dodatnich z wiarygodnych narzędzi DevOps i wywołań API od partnerów. Następnie utworzono wyjątki dla podpisów znanych dobrych scenariuszy, zachowując aktywne sygnatury CVE o wysokim priorytecie.

• Przejście w tryb zapobiegania: Przejście IDPS do trybu alertu i odmowy dla produkcji po weryfikacji, aktywnie blokując wykryte zagrożenia, w tym próby wykorzystania luki PaperCut, ataki Log4Shell oraz komunikację C2.

• Integracja usługi Sentinel: Skonfigurowano dzienniki diagnostyczne w usłudze Log Analytics, utworzono reguły analizy usługi Sentinel korelujące wykrycia idPS ze zdarzeniami uwierzytelniania i ustanowiono automatyczne tworzenie zdarzeń dla alertów o wysokiej ważności.

Wynik: Próby wykorzystania zostały pomyślnie zablokowane uniemożliwiające zdalne wykonywanie kodu. Krytyczne wykorzystanie luk w zabezpieczeniach zostało wyeliminowane przed wystąpieniem naruszenia zabezpieczeń. Fałszywie dodatnie wskaźniki znacznie spadły przy zachowaniu kompleksowego pokrycia CVE. Zespoły ds. zabezpieczeń osiągnęły szybki przegląd alertów i reagowanie na zdarzenia, ustanawiając ciągłą widoczność zagrożeń z możliwością działania w celu proaktywnej ochrony.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
• PCI-DSS 4: 11.4.1, 11.4.2, 1.4.1
• Kontrole CIS w wersji 8.1: 13.2, 13.6, 13.7
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. CM-07
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2

NS-5: Wdrażanie ochrony przed atakami DDOS

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: NS-5.

Zasada zabezpieczeń

Wdróż ochronę przed atakami DDoS w różnych warstwach, aby skutecznie ograniczyć ataki ukierunkowane na różne usługi i protokoły zarówno w warstwach sieci, jak i aplikacji.

Ryzyko w celu ograniczenia ryzyka

Podmioty zagrożeń atakują sieci, serwery lub aplikacje przy użyciu przytłaczającego złośliwego ruchu w celu spowodowania zakłóceń w działaniu usługi.

• Ataki wolumetryczne (powodzie sieciowe): Osoby atakujące zalewają interfejsy sieciowe z masowymi woluminami ruchu (np. milionami pakietów na sekundę), aby wyczerpać przepustowość, pojemność przetwarzania routera lub zasoby modułu równoważenia obciążenia, powodując niedostępność usługi. Przykłady obejmują powodzie UDP, powodzie ICMP lub wzmocnione ataki odbicia DNS wykorzystujące protokoły, takie jak NTP lub SSDP.
• Ataki protokołu (wyczerpanie stanu): Osoby atakujące wykorzystują luki w zabezpieczeniach protokołu warstwy 3/4 w celu wyczerpania zasobów stanowych, takich jak tabele połączeń TCP lub stany sesji zapory. Typowe techniki obejmują powodzie TCP SYN, które przeciążają serwery z półwartymi połączeniami lub powodzie ACK przeznaczone dla urządzeń stanowych.
• Ataki warstwy zasobów (przeciążenie aplikacji): Ataki warstwy 7 o ograniczonej skali, takie jak powodzie HTTP GET/POST, atakujące zasoby aplikacji (np. procesor, pamięć lub połączenia baz danych) w celu przeciążenia serwerów WWW lub interfejsów API. Ataki te mają na celu wyczerpanie zasobów obliczeniowych, co powoduje wzrost opóźnienia lub awarie.
• Ataki wzmacniania: Osoby atakujące wykorzystują błędnie skonfigurowane serwery (np. serwery DNS, NTP lub Plex Media na UDP 32414) w celu zwiększenia ruchu, wysyłając zapytania, które generują ogromne odpowiedzi skierowane do sieci docelowej, przeciążając jej pojemność. Przykłady obejmują wzmacnianie DNS lub ataki z odbiciem SSDP.

MITRE ATT&CK

• Wpływ (TA0040): zakłóca dostępność usługi przez powodzie woluminowe (np. UDP/ICMP) lub przeciążenia zasobów (np. powodzie HTTP) w celu odmowy dostępu (np. T1498 — odmowa usługi sieci).
• Tworzenie zasobów (TA0042): wykorzystuje skompromitowane systemy do ataków wzmacniania (np. odbicia DNS/NTP) w celu skalowania wpływu ataku (np. T1584 — kompromitacja infrastruktury).

NS-5.1 Implementowanie ochrony przed atakami DDOS w odpowiedniej warstwie sieciowej

Wdróż ochronę przed atakami DDoS zarówno w warstwach sieci, jak i aplikacji w celu obrony przed atakami specyficznymi dla aplikacji i woluminów. Platforma Azure oferuje wiele warstw ochrony: Ochrona sieciowa DDoS zapewnia kompleksowe pokrycie sieci wirtualnej z obsługą szybkiego reagowania, ochrona IP przed atakami DDoS dla ekonomicznej ochrony poszczególnych adresów IP oraz ochrona warstwy aplikacji za pomocą zapory aplikacyjnej WAF. Skonfiguruj monitorowanie i alerty, aby zweryfikować skuteczność ochrony i zapewnić odporność aplikacji podczas ataków:

• Wdrażanie ochrony DDoS warstwy sieciowej: Wybierz między usługą DDoS Network Protection dla wdrożeń wymagających pełnego pokrycia VNet i szybkiego wsparcia w zakresie badań ataków oraz analizy po ataku albo DDoS IP Protection dla ekonomicznej ochrony ograniczonej liczby adresów IP bez wsparcia szybkiej reakcji.

• Wdrażanie ochrony przed atakami DDoS warstwy aplikacji: Włącz ochronę przed atakami DDoS w usłudze Azure Web Application Firewall (WAF), Application Gateway lub Azure Front Door w celu obrony przed atakami warstwy aplikacji (warstwa 7).

• Konfigurowanie monitorowania i alertów: Skonfiguruj alerty i monitoruj metryki i dzienniki z usługi ochrony przed atakami DDoS oraz aplikacje, aby zapewnić skuteczność ochrony, odporność aplikacji oraz żądaną wydajność podczas ataków i po ich wystąpieniu.

Przykład implementacji

Organizacja handlu elektronicznego potrzebowała kompleksowej ochrony przed atakami DDoS dla aplikacji skierowanych do klienta, które doświadczały coraz częstszych prób ataków wolumetrycznych i w warstwie aplikacji podczas szczytowych sezonów zakupowych.

Wyzwanie: Organizacja obsługiwała globalną platformę handlu elektronicznego z publicznymi aplikacjami internetowymi, interfejsami API i infrastrukturą dostarczania zawartości uwidocznioną w Internecie. Podczas szczytowych zdarzeń platforma doświadczyła wielu ataków DDoS, takich jak: ataki zalewające UDP, ataki zalewające TCP SYN wyczerpujące tabele połączeń modułu równoważenia obciążeń, ataki zalewające HTTP ukierunkowane na API płatności oraz ataki wzmacniania DNS. Bez dedykowanej ochrony przed atakami DDoS te spowodowały awarie usług, co spowodowało utratę przychodów i niezadowolenie klientów.

Rozwiązanie:

• Ochrona sieci przed atakami DDoS: Włączono usługę Azure DDoS Network Protection w produkcyjnych sieciach wirtualnych hostujących aplikacje dostępne dla klientów, zapewniając kompleksową ochronę na poziomie sieci wirtualnej z adaptacyjnym dostrajaniem, automatycznym wykrywaniem ataków w warstwach 3 i 4 oraz ograniczaniem ryzyka w czasie rzeczywistym.

• Ochrona warstwy aplikacji: Wdrożono usługę Azure Application Gateway z zaporą aplikacji internetowych dla aplikacji regionalnych i usługę Azure Front Door z zaporą aplikacji internetowych do globalnej obsługi na brzegu sieci, umożliwiając ochronę przed atakami DDoS warstwy 7, ograniczanie szybkości, wykrywanie powodzi HTTP oraz reguły ochrony przed botami.

• Konfiguracja polityki ochrony: Utworzono plan ochrony DDoS, który łączy wszystkie sieci wirtualne produkcji, skonfigurowano adaptacyjne wzorce ruchu bazowego, włączono ciągłe monitorowanie ruchu i zdefiniowano zasady ochrony obejmujące powodzie UDP, powodzie TCP SYN, powodzie ICMP i ataki na poziomie protokołu.

• Monitorowanie i alerty: Skonfigurowane dzienniki diagnostyczne DDoS wysyłające dane telemetryczne ataku do obszaru roboczego usługi Log Analytics, utworzono alerty usługi Azure Monitor wyzwalające natychmiastowe powiadomienia po wykryciu ataków, ustanowiono skoroszyt usługi Sentinel korelujący ataki DDoS z metrykami wydajności aplikacji i skonfigurowano monitorowanie kondycji aplikacji w usłudze Application Insights podczas ograniczania ryzyka.

• Szybkie reagowanie: Aktywowana szybka odpowiedź DDoS zapewniając bezpośredni dostęp do ekspertów ds. ochrony przed atakami DDoS podczas aktywnych ataków na potrzeby analizy ataków w czasie rzeczywistym, tworzenia niestandardowych strategii ograniczania ryzyka i analizy kryminalistycznej po ataku.

Wynik: Ataki DDoS w szczytowym sezonie zakupów zostały pomyślnie wyeliminowane z powodu zerowych zakłóceń usług. Powodzie woluminowe, powodzie SYN i powodzie HTTP zostały automatycznie zablokowane, utrzymując dostępność platformy. Szybka odpowiedź zapewniała analizę ekspertów pod kątem zaawansowanych ataków. Krytyczne okresy zakupów utrzymywały wysoki czas pracy bez opóźnień transakcji klienta podczas ograniczania ryzyka.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
• PCI-DSS 4: 6.4.2, 11.4.7
• Kontrolki CIS w wersji 8.1: 13.3
• NIST CSF v2.0: PR. PT-05, DE. CM-01
• ISO 27001:2022: A.8.13, A.8.24
• SOC 2: CC6.1, CC7.2

NS-6: Wdrażanie zapory aplikacji internetowej

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: NS-6.

Zasada zabezpieczeń

Wdróż zaporę aplikacji internetowej i skonfiguruj reguły w celu ochrony aplikacji internetowych i interfejsów API przed atakami specyficznymi dla aplikacji, sprawdzając, wykrywając i filtrując złośliwy ruch HTTP/HTTPS.

Ryzyko w celu ograniczenia ryzyka

Osoby atakujące wykorzystują luki w zabezpieczeniach aplikacji internetowych w celu uzyskania nieautoryzowanego dostępu, wykonywania złośliwego kodu, kradzieży poświadczeń lub eksfiltrowania danych.

• Ataki iniekcyjne (np. wstrzyknięcie kodu SQL, wstrzyknięcie polecenia): Osoby atakujące wykorzystują luki w zabezpieczeniach weryfikacji danych wejściowych w celu wstrzyknięcia złośliwego kodu do zapytań lub poleceń aplikacji internetowych, umożliwiając nieautoryzowany dostęp do bazy danych, eksfiltrację danych lub naruszenie systemu. Iniekcja SQL (SQLi) manipuluje zapytaniami zaplecza (np. dołączaniem "OR '1'='1 do formularza logowania), podczas gdy iniekcja poleceń wykonuje dowolne polecenia systemu operacyjnego (np. ; rm -rf / za pomocą pola formularza).
• Naruszenia protokołu HTTP i źle sformułowane żądania: Osoby atakujące wysyłają źle sformułowane żądania HTTP (np. nieprawidłowe nagłówki, przeładowane ładunki lub metody inne niż standardowe, takie jak TRACE), aby wykorzystać luki w zabezpieczeniach serwerów internetowych lub aplikacji, potencjalnie powodując awarie lub nieautoryzowany dostęp. Te ataki dotyczą nieprawidłowo skonfigurowanych serwerów lub nienadzorowanych struktur.
• Ataki oparte na botach (np. wypychanie poświadczeń, złomowanie): Zautomatyzowane boty uruchamiają ataki na wypychanie poświadczeń (np. wymuszanie punktów końcowych logowania za pomocą skradzionych poświadczeń) lub złomowanie poufnej zawartości (np. danych cenowych), przeciążanie serwerów lub naruszanie kont użytkowników. Te ataki wykorzystują słabe uwierzytelnianie lub niechronione interfejsy API.
• Luki w zabezpieczeniach specyficzne dla aplikacji (np. dołączanie plików zdalnych, dołączanie plików lokalnych): Osoby atakujące wykorzystują luki w zabezpieczeniach w celu uwzględnienia złośliwych plików (np. "http://evil.com/shell.php") lub uzyskania dostępu do plików serwera lokalnego (np. .). /.. /etc/passwd) za pośrednictwem manipulowanych parametrów adresu URL lub danych wejściowych formularza, umożliwiając wykonywanie kodu lub ujawnienie danych.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystuje wstrzyknięcie kodu SQL, XSS lub zdalne dołączanie plików w celu uzyskania wpisu (np. T1190 — Exploit Public-Facing Application).
• Wykonanie (TA0002): Wykonuje złośliwy kod za pośrednictwem iniekcji poleceń, RFI lub XSS (np. T1059 — Interpreter poleceń i skryptów).
• Dostęp poświadczeń (TA0006): Kradnie poświadczenia za pośrednictwem XSS lub ataku typu 'credential stuffing' (np. T1539 — Kradzież ciasteczka sesji sieci Web, T1110 — atak brute force).
• Kolekcja (TA0009): Zbiera dane za pośrednictwem iniekcji SQL lub wyciągania danych (np. T1213 — dane z repozytoriów informacji).

NS-6.1 Konfigurowanie zapory aplikacji internetowej platformy Azure przy użyciu odpowiednich reguł

Włącz możliwości zapory aplikacji internetowej (WAF) w usłudze Azure Application Gateway, usłudze Azure Front Door lub usłudze Azure Content Delivery Network (CDN), aby chronić aplikacje i interfejsy API przed atakami internetowymi. Wybierz odpowiednią usługę na podstawie wymagań aplikacji, skonfiguruj zasady zapory sieciowej aplikacji z wbudowanymi i niestandardowymi regułami, ustaw tryb zasad w zależności od poziomu zabezpieczeń i połącz zasady z punktem końcowym usługi:

• Wybierz odpowiednią usługę zapory aplikacji internetowej: Wybierz usługę Azure Application Gateway dla aplikacji hostowanych w sieci wirtualnej, usługę Azure Front Door na potrzeby globalnego dostarczania brzegowego lub usługę Azure CDN dla obciążeń z dużą ilością zawartości na podstawie wymagań aplikacji i architektury.

• Skonfiguruj zasady zapory aplikacji internetowej za pomocą predefiniowanych oraz niestandardowych reguł: Rozpocznij od powszechnie stosowanych wbudowanych zestawów reguł, takich jak OWASP Core Rule Set (CRS 3.2) oraz reguł ochrony botów (Microsoft Bot Manager). Dodaj niestandardowe reguły (np. ograniczenie liczby >100 żądań/min) i wykluczenia, aby zmniejszyć liczbę fałszywych alarmów w oparciu o krajobraz zagrożeń i profil zabezpieczeń aplikacji.

• Ustaw tryb zasad zapory aplikacji internetowej (WAF): Użyj trybu wykrywania początkowo lub w przypadku aplikacji niekrytycznych, aby uniknąć zakłócania legalnego ruchu podczas konfigurowania i optymalizacji reguł. Przełącz się do trybu zapobiegania krytycznym aplikacjom po zweryfikowaniu reguł w celu blokowania złośliwych żądań.

• Skojarz politykę WAF z punktem końcowym usługi: Skojarz politykę WAF z Application Gateway, Front Door lub punktem końcowym CDN, aby upewnić się, że cały ruch HTTP/HTTPS jest kierowany przez WAF do inspekcji.

Przykład implementacji

Organizacja potrzebowała ochrony internetowych aplikacji i interfejsów API skierowanych do klientów przed wstrzyknięciem kodu SQL, atakami XSS i próbami używania skradzionych poświadczeń przez boty, przy zachowaniu wydajności dla uprawnionych użytkowników.

Wyzwanie: Organizacja miała aplikacje internetowe wdrożone globalnie bez ochrony przed lukami w zabezpieczeniach OWASP Top 10, co spowodowało wiele prób iniekcji SQL, ataków opartych na botach przytłaczających punktów końcowych logowania i brak wglądu w złośliwe wzorce ruchu. Aplikacje nie miały kontroli ograniczania szybkości, umożliwiając nadużycie interfejsu API i ataki na wypychanie poświadczeń i nie było żadnego mechanizmu rozróżniania uprawnionych użytkowników od złośliwych botów.

Podejście do rozwiązania:

• Wybór usługi zapory aplikacji internetowej: Wdrożono usługę Azure Application Gateway z zaporą aplikacji internetowych dla aplikacji hostowanych przez sieć wirtualną i usługę Azure Front Door z zaporą aplikacji internetowych dla globalnie rozproszonych aplikacji wymagających ochrony brzegowej i dostępu z małymi opóźnieniami.
• Wbudowane zestawy reguł ochrony: Włączono zestaw reguł OWASP Core (CRS) 3.2 w celu ochrony przed wstrzyknięciem kodu SQL, wykonywaniem skryptów między witrynami (XSS), zdalnym dołączaniem plików i innymi typowymi lukami w zabezpieczeniach sieci Web oraz aktywowano reguły programu Microsoft Bot Manager w celu identyfikowania i blokowania złośliwych botów przy jednoczesnym umożliwieniu legalnym przeszukiwarkom wyszukiwarki i usługom monitorowania.
• Reguły niestandardowe dla określonych zagrożeń: Zaimplementowano reguły ograniczania szybkości blokujące klientów przekraczających 100 żądań na minutę, aby zapobiec nadużyciom interfejsu API i tworzeniu poświadczeń, reguły filtrowania geograficznego blokujące ruch z regionów wysokiego ryzyka, w których usługi są niedostępne, a reguły oparte na reputacji adresów IP blokują żądania ze znanych złośliwych zakresów adresów IP zidentyfikowanych za pośrednictwem kanałów informacyjnych analizy zagrożeń.
• Zarządzanie wykluczeniami: Utworzono docelowe wykluczenia dla uzasadnionych scenariuszy biznesowych, takich jak punkty dostępowe (endpoints) /checkout ze złożonymi danymi wejściowymi formularzy, wyzwalające fałszywe alarmy zgodnie z regułami OWASP, punkty dostępowe /upload obsługujące duże przesyłanie plików oraz punkty dostępowe /api z nietypowymi, ale prawidłowymi wzorcami nagłówków pochodzących z aplikacji mobilnych.
• Przejście z wykrywania do zapobiegania: Uruchomiono zaporę aplikacji internetowej (WAF) w trybie wykrywania na dwa tygodnie, aby zidentyfikować fałszywe alarmy, po czym udoskonalono reguły i wykluczenia na podstawie prawdziwych wzorców ruchu. Następnie przełączono WAF w tryb zapobiegania dla aplikacji produkcyjnych, aby aktywnie blokować zagrożenia, jednocześnie utrzymując ciągłość biznesową.

Wynik: Organizacja wyeliminowała próby wykorzystania kodu SQL i XSS, znacznie zmniejszyła liczbę ataków opartych na botach za pośrednictwem reguł menedżera botów i ustanowiła kompleksowy wgląd w zagrożenia aplikacji internetowej. Mechanizmy kontroli limitowania szybkości zapobiegły nadużyciom interfejsu API i wypychaniu poświadczeń, podczas gdy stopniowe przejście z wykrywania do trybu zapobiegania gwarantowało, że prawdziwi użytkownicy nie doświadczyli żadnych przerw w działaniu usługi.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
• PCI-DSS 4: 6.4.1, 6.4.2, 11.4.7
• Kontrole CIS w wersji 8.1: 13.2, 13.9
• NIST CSF v2.0: PR.AC-05, PR.PT-05, DE.CM-04
• ISO 27001:2022: A.8.20, A.8.22, A.8.25
• SOC 2: CC6.1, CC6.6, CC7.2

NS-7: Centralne i efektywne zarządzanie zabezpieczeniami sieci

Zasada zabezpieczeń

Aby zmniejszyć ryzyko operacyjne i błędną konfigurację w złożonym i rozdrobnionym środowisku sieciowym, użyj natywnych funkcji zarządzania siecią w chmurze, aby scentralizować, uprościć i wymusić spójne konfiguracje zabezpieczeń sieci.

Ryzyko w celu ograniczenia ryzyka

Brak scentralizowanej kontroli powoduje pomijanie lub nieaktualne ustawienia zabezpieczeń, co zwiększa ryzyko wykorzystania.

• Niespójne wymuszanie zasad i błędy konfiguracji: Zdecentralizowane zarządzanie często prowadzi do rozdrobnionych zestawów reguł i luk w zasadach, co ułatwia atakującym odnajdywanie i wykorzystywanie słabych punktów. Błędy konfiguracji są bardziej prawdopodobne, co zwiększa prawdopodobieństwo przypadkowego ujawnienia lub niezamierzonego dostępu.
• Zmniejszona widoczność i opóźniona odpowiedź: Bez ujednoliconego podejścia do zarządzania monitorowanie i reagowanie na zdarzenia stają się wolniejsze i mniej skuteczne. Może to opóźnić wykrywanie złośliwych działań, dzięki czemu osoby atakujące mogą eskalować ataki lub eksfiltrować dane.
• Trudności z zachowaniem zgodności: Nieodpowiednie centralne zarządzanie komplikuje wysiłki mające na celu spójne spełnianie standardów regulacyjnych i branżowych, ryzyko niezgodności i potencjalnych kar.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystywanie błędów konfiguracji lub nieaktualnych ustawień zabezpieczeń w celu uzyskania nieautoryzowanego dostępu (np. T1190 — Exploit Public-Facing Application, T1133 — Zewnętrzne usługi zdalne).
• Unikanie obrony (TA0005): Korzystanie z fragmentowanych zestawów reguł i braku centralnego monitorowania w celu uniknięcia wykrycia (np. T1562: osłabienie obrony).
• Ruch boczny (TA0008): Przemieszczanie się lateralne w sieci za pomocą wykorzystania luk polityki lub nieaktualnej segmentacji (np. T1021 — Usługi zdalne).
• Sterowanie i sterowanie (TA0011): Używanie niemonitorowanych lub nieprawidłowo skonfigurowanych ścieżek sieciowych w celu ustanowienia i obsługi kanałów C2 (np. T1071 — Application Layer Protocol).

NS-7.1 Centralnie i skutecznie zarządzaj zabezpieczeniami sieci

Użyj scentralizowanych narzędzi i ustandaryzowanych rozwiązań platformy Azure, aby uprościć i skalować zarządzanie zabezpieczeniami sieci, zapewniając spójne wymuszanie, zmniejszenie błędnej konfiguracji i ulepszone monitorowanie. Zaimplementuj scentralizowane wymuszanie zasad, standaryzację zarządzania zaporą i routingiem, włącz kompleksowe monitorowanie i analizę oraz zachowaj spójność zasobów dzięki praktykom ładu:

• Zaimplementuj scentralizowane wymuszanie zasad: Użyj usługi Azure Virtual Network Manager (AVNM), aby zdefiniować reguły administratora zabezpieczeń, które są stosowane spójnie w subskrypcjach i regionach. Zachowaj sieciowe grupy zabezpieczeń (NSG) do mikrosegmentacji na poziomie obciążenia. Zastosuj zasady za pośrednictwem grup sieciowych (np. według środowiska: prod, non-prod).

• Standaryzacja zarządzania zaporą i routingiem: Zarządzanie regułami usługi Azure Firewall za pomocą menedżera zapory za pomocą obiektów zasad zapory. Ustandaryzuj korzystanie z grup adresów IP i tagów usługowych zamiast używania nieprzetworzonych adresów IP. Użyj usługi Azure Firewall Premium, gdy wymagana jest inspekcja protokołu TLS, system wykrywania i zapobiegania włamaniom (IDPS), oraz filtrowanie adresów URL. Preferuj bezpieczne koncentratory usługi Virtual WAN lub wspólną topologię hub-and-spoke, aby spójnie wymuszać intencję routingu.

• Włącz kompleksowe monitorowanie i analizę: Użyj dzienników przepływu sieci wirtualnej w wersji 2 (aby zastąpić dzienniki przepływów NSG). Włącz dzienniki diagnostyczne usługi Azure Firewall i zintegruj je z usługą Traffic Analytics, Log Analytics i Microsoft Sentinel. Użyj analizy zasad zapory i liczby trafień reguł, aby wyeliminować nieużywane lub zduplikowane reguły.

• Zachowaj spójność zasobów i ład: Zastosuj konwencje nazewnictwa CAF i obowiązkowe tagi zasobów do wszystkich sieci wirtualnych, sieciowych grup zabezpieczeń, reguł zapory i grup. Użyj adaptacyjnego wzmacniania sieci w usłudze Defender for Cloud, aby dostosować nadmiernie zezwalające reguły.

Przykład implementacji

Przypadek użycia: Platforma płatności w wielu regionach konsoliduje zabezpieczenia sieciowe na dużą skalę

Kontekst: Procesor płatności średniej wielkości działający w regionach Wschodnie USA i Europa Zachodnia z czterema subskrypcjami (Prod, Non-Prod, Shared Services, SecOps) w ramach jednego klienta wymaga segmentacji PCI-DSS, mniejszej liczby incydentów wynikających z dryfu reguł i scentralizowanego monitorowania.

Scentralizowane wymuszanie zasad za pomocą usługi Azure Virtual Network Manager:

• Projekt: Utwórz AVNM na poziomie grupy zarządzania. Zdefiniuj dwie grupy sieciowe: ng-prod i ng-nonprod z członkostwem dynamicznym według tagu subscriptionId. Utwórz reguły Administratora Zabezpieczeń (SAR), aby wymusić organizacyjne zasady bezpieczeństwa, które są ocenie przed grupami zabezpieczeń sieci: Deny-Inbound-Internet-to-Spokes (blokuje niepożądany ruch przychodzący z Internetu do wszystkich podsieci odnóg), Allow-Hub-Infra (pozwala na usługi centrum, takie jak Zapora/Bastion, do odnóg), Allow-Platform-DNS (zezwala na DNS z hubowych serwerów rozpoznawania do odnóg).
• Granice zespołów aplikacji: Obciążenia robocze zachowują NSG (Sieciowe Grupy Zabezpieczeń) do mikrosegmentacji (np. aplikacja webowa do API :443, API do bazy danych :1433) w każdej szprych. Zmiany NSG są zarządzane przez zespoły aplikacyjne; SAR są zarządzane przez zespół ds. zabezpieczeń platformy.
• Wynik: Zabezpieczenia są spójne w obu regionach; zespoły aplikacji nie mogą przypadkowo utworzyć bezpośredniego dostępu do Internetu, nawet jeśli sieciowa grupa zabezpieczeń jest nieprawidłowo skonfigurowana.

Zarządzanie zaporą i routingiem za pomocą programu Firewall Manager i usługi Virtual WAN:

• Projekt: Wdróż bezpieczne koncentratory usługi Virtual WAN w każdym regionie (Wschodnie stany USA, Europa Zachodnia). Dołącz szprychy do najbliższego węzła i włącz regułę routingu, aby cały ruch wychodzący do Internetu był sprawdzany. Użyj Firewall Manager z globalną polityką zapory (warstwa: Premium) i dwiema zasadami podrzędnymi (Prod/Non-Prod) dla nadpisywania konfiguracji środowiska.
• Struktura zasad: Podstawowe (globalne) zasady obejmują funkcję Threat Intelligence ustawioną na Alert + Deny, inspekcję protokołu TLS włączoną dla wychodzącego protokołu HTTPS, system IDPS w trybie zrównoważonym oraz reguły zezwalania na ruch wychodzący przy użyciu tagów usługi (Storage, KeyVault, AzureMonitor) i grup adresów IP dla punktów końcowych partnerów. Polityka dla dzieci w usłudze Prod ma bardziej rygorystyczne filtrowanie adresów URL (blokowanie adresów bez kategorii) oraz listę dozwolonych adresów URL dla bram płatności za pośrednictwem grup adresów IP. Zasady środowisk innych niż produkcyjne mają szerszy dostęp do narzędzi deweloperskich za pośrednictwem tagów usługi (AzureDevOps, AzureContainerRegistry).
• Wynik: Jedno okienko do zarządzania regułami za pomocą zmian propagowanych do obu centrów. Routing jest spójny, a cały ruch wychodzący jest sprawdzany przy użyciu odszyfrowywania protokołu TLS, jeśli jest to dozwolone.

Monitorowanie i analiza za pomocą dzienników przepływów w wersji 2 i usługi Sentinel:

• Konfiguracja telemetrii: Włącz dzienniki przepływu sieci wirtualnej w wersji 2 we wszystkich sieciach wirtualnych i wyślij do centralnego obszaru roboczego usługi Log Analytics w subskrypcji SecOps. Skonfiguruj dzienniki diagnostyczne usługi Azure Firewall (Aplikacja, Sieć, DNS, ThreatIntel, IDPS) w tym samym obszarze roboczym. Włącz analizę ruchu względem obszaru roboczego.
• Pętla optymalizacji: Włącz analizę zasad zapory sieciowej i sprawdź ilość zastosowania reguły co miesiąc. Utwórz skoroszyt Sentinel, który koreluje dzienniki przepływu ruchu sieciowego (ruch północ-południe i wschód-zachód), trafienia dozwolenia/odmowy zapory sieciowej oraz wyzwalane sygnatury IDPS. Zautomatyzuj żądanie zmiany, jeśli reguła ma 0 trafień przez 45 dni (kandydata do usunięcia) lub jeśli reguła odmowy zostanie osiągnięta przez podsieć produkcyjną (możliwe błędne przekierowanie).
• Wynik: Po dwóch cyklach przeglądu 18% reguł zapory i 22 przestarzałych reguł NSG są usuwane, zmniejszając opóźnienie oceny reguł i ryzyko zmian.

Spójność zasobów i ład dzięki usłudze CAF i usłudze Defender for Cloud:

• Standardy: Zastosuj nazewnictwo CAF (np. vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) i obowiązkowe tagi: env, owner, dataClass, costCenter.
• Egzekwowanie: Inicjatywy usługi Azure Policy umożliwiają wymaganie obecności sieciowej grupy zabezpieczeń na każdej podsieci, wymaganie ustawień diagnostycznych na sieciach wirtualnych oraz Azure Firewall do centralnego obszaru roboczego LA, a także odrzucanie tworzenia bez obowiązkowych tagów. Włącz Defender for Cloud — adaptacyjne wzmacnianie zabezpieczeń sieci na wszystkich węzłach sieciowych, z cotygodniowym przeglądem działań w SecOps CAB.
• Wynik: Dryf platformy jest szybko ujawniany; Nadmiernie swobodne reguły są zaostrzane przy użyciu zaleceń opartych na danych usługi Microsoft Defender.

Kryteria sekwencji wdrażania i akceptacji:

• Skonfiguruj zabezpieczone koncentratory vWAN, dołącz połączenia, włącz zamierzenie routingu (tylko połączenia pilotażowe). Kryteria akceptacji: ruch wychodzący szprych pilotażowych przez zaporę; żadne publiczne adresy IP nie są dostępne bezpośrednio.
• Wdróż SARs AVNM w ng-nonprod, sprawdź, czy nie ma usterek, a następnie w ng-prod. Kryteria akceptacji: Syntetyczne sondy potwierdzają, że usługi koncentratora (DNS/Bastion) nadal docierają do ramion; przychodzący Internet nadal jest odrzucany.
• Włącz dzienniki przepływu vNet w wersji 2 oraz wszystkie diagnostyki zapory; zintegrować skoroszyt usługi Sentinel. Kryteria akceptacji: Dashboardy pokazują przepływy, odmowy i trafienia IDPS na region.
• Stosowanie inicjatyw zasad; korygowanie niezgodnych elementów; włącz adaptacyjne wzmacnianie zabezpieczeń. Kryteria akceptacji: zgodność osiąga 95%, stworzenie listy zadań dotyczących elementów zaostrzenia sieciowej grupy zabezpieczeń/zapory.
• Przegląd pierwszej analizy zasad; usuń nieużywane reguły za pośrednictwem okna zmiany. Kryteria akceptacji: liczba reguł zmniejszona o 15% z zerowym wpływem na klienta.

Przykłady elementów Runbook operacyjnych:

• Azure Virtual Network Manager SARs: Odmów przychodzącego Internetu do odgałęzień (priorytet 100), Zezwól na ruch do odgałęzień z infrastruktury hub (priorytet 200: zakresy źródłowe 10.0.0.0/16 hub)
• Struktura zasad zapory: azfw-policy-global-01 (Premium) z kolekcjami reguł Allow-Azure-Platform-ST (tagi usług) i Allow-Partners-IPs (grupy adresów IP: ipg-payment-gws), a także zasady podrzędne azfw-policy-prd-01 i azfw-policy-npd-01
• Diagnostyka: Miejsce docelowe: law-secops-01, Kategorie: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: CM-2, CM-3, CM-6, CA-7, SI-4
• PCI-DSS 4: 1.4.5, 11.5.1, 12.4.1
• Kontrole CIS w wersji 8.1: 4.1, 4.2, 12.4, 13.6
• NIST CSF v2.0: PR.IP-01, DE.CM-01, DE.CM-07
• ISO 27001:2022: A.8.9, A.8.32, A.5.37
• SOC 2: CC6.6, CC7.2, CC8.1

NS-8: Wykrywanie i wyłączanie niezabezpieczonych usług i protokołów

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: NS-8.

Zasada zabezpieczeń

Odnajdywanie i wyłączanie niezabezpieczonych usług i protokołów w warstwie systemu operacyjnego, aplikacji lub pakietu oprogramowania. Wdrażanie mechanizmów kontroli wyrównywającej, jeśli wyłączenie niezabezpieczonych usług i protokołów nie jest możliwe.

Ryzyko w celu ograniczenia ryzyka

Podmioty zagrożeń wykorzystują niezabezpieczone i podatne na zagrożenia usługi i protokoły w celu naruszenia zabezpieczeń systemów i danych.

• Wykorzystanie słabości kryptograficznych: SSL/TLSv1 i słabe szyfry (np. RC4, DES) są narażone na ataki typu MITM (np. POODLE, BEAST), umożliwiając przeciwnikom odszyfrowanie poufnych danych, takich jak tokeny sesji, za pośrednictwem ataków wyroczni paddingu lub ataków wybranego szyfru.
• Nieautoryzowany dostęp poprzez wykorzystanie protokołów: Luki w zabezpieczeniach SSHv1 i SMBv1 (np. CVE-2001-1473, CVE-2017-0144/EternalBlue) umożliwiają zdalne wykonywanie kodu lub nieuwierzytelniony dostęp, umożliwiając utworzenie początkowego przyczółka.
• Kradzież poświadczeń: LM/NTLMv1 i wDigest przechowują słabe skróty lub poświadczenia zwykłego tekstu, podatne na przekazywanie skrótu lub złomowanie pamięci (np. wyodrębnianie danych LSASS przez program Mimikatz).
• Ruch poprzeczny: Niezaszyfrowane sesje i luki w zabezpieczeniach protokołu SMBv1 (np. EternalBlue) umożliwiają propagację złośliwego oprogramowania lub przekazywanie poświadczeń między sieciami.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystanie niezabezpieczonych protokołów, takich jak SSL/TLSv1 lub SSHv1, które są narażone na ataki typu downgrade lub znane exploity, zapobiegając nieautoryzowanemu wejściu (np. T1190 — Eksploatacja aplikacji publicznej).
• Dostęp do poświadczeń (TA0006): Kradzież poświadczeń przez wykorzystanie LM/NTLMv1 i wDigest, które przechowują poświadczenia w formatach odwracalnych lub jako słabe skróty, co udaremnia ataki typu pass-the-hash lub przeszukiwanie pamięci (np. T1003 — zrzut poświadczeń systemu operacyjnego).
• Ruch boczny (TA0008): Uniemożliwia atakującemu wykorzystanie SMBv1, które jest podatne na ataki takie jak EternalBlue, co zapobiega propagacji w sieciach (np. T1021 - usługi zdalne).

NS-8.1 Wykrywanie i wyłączanie niezabezpieczonych usług i protokołów

Użyj wbudowanego skoroszytu protokołu niezabezpieczonego usługi Microsoft Sentinel, aby odnajdywać i ograniczać niezabezpieczone usługi i protokoły w środowisku platformy Azure. Ten skoroszyt identyfikuje użycie protokołów i usług, które nie spełniają odpowiednich standardów zabezpieczeń, takich jak SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, słabe szyfry w protokole Kerberos i niepodpisane powiązania LDAP. Po identyfikacji wyłącz te niezabezpieczone protokoły i usługi. Gdy wyłączenie nie jest możliwe, należy zaimplementować mechanizmy kompensujące w celu zmniejszenia powierzchni ataku.

Odnajdź niezabezpieczone protokoły: Użyj skoroszytu protokołu niezabezpieczonego usługi Microsoft Sentinel, aby zidentyfikować użycie szyfrów SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, słabych szyfrów Kerberos i niepodpisanych powiązań LDAP w środowisku.

Wyłącz niezabezpieczone usługi i protokoły: Wyłącz zidentyfikowane niezabezpieczone usługi i protokoły, które nie spełniają odpowiednich standardów zabezpieczeń, aby wyeliminować luki w zabezpieczeniach.

Implementowanie kontrolek wyrównywujących: Jeśli wyłączenie niezabezpieczonych usług lub protokołów nie jest możliwe z powodu wymagań biznesowych lub ograniczeń technicznych, użyj mechanizmów wyrównujących, takich jak blokowanie dostępu do zasobów za pośrednictwem sieciowych grup zabezpieczeń, usługi Azure Firewall lub zapory aplikacji internetowej platformy Azure w celu zmniejszenia obszaru ataków.

Przykład implementacji

Organizacja opieki zdrowotnej musiała wyeliminować niezabezpieczone protokoły w całym środowisku platformy Azure, aby spełnić wymagania dotyczące zgodności z przepisami HIPAA i zmniejszyć obszar ataków na chronione informacje o zdrowiu.

Wyzwanie: Organizacja obsługiwała infrastrukturę hybrydową ze starszymi aplikacjami wymagającymi łączności z zasobami hostowanymi na platformie Azure. Ocena zabezpieczeń ujawniła powszechne użycie niezabezpieczonych protokołów, w tym SSL/TLSv1.0 na serwerach internetowych obsługujących portale pacjentów, protokół SMBv1 włączony na serwerach plików dla starszego oprogramowania do obrazowania medycznego, uwierzytelnianie LM/NTLMv1 na kontrolerach domeny i serwerach aplikacji, uwierzytelnianie wDigest przechowujące poświadczenia w formacie odwracalnym, niepodpisane powiązania LDAP na kontrolerach usługi i słabe szyfrowanie Kerberos na kontach usług. Organizacja nie miała wglądu w użycie protokołu i miała do czynienia z potencjalnymi naruszeniami zgodności HIPAA.

Rozwiązanie:

• Wdrożenie skoroszytu Insecure Protocol Workbook w usłudze Sentinel: Wdrożono usługę Microsoft Sentinel i zainstalowano Insecure Protocol Workbook z centrum zawartości, połączono źródła danych, w tym dzienniki zdarzeń zabezpieczeń systemu Windows, dzienniki usługi Azure Monitor, dzienniki usługi Active Directory i dzienniki przepływu sieci, aby ustanowić kompleksowy punkt odniesienia dla użycia niezabezpieczonych protokołów w środowisku hybrydowym.

• Odnajdywanie protokołów: Użyto skoroszytu protokołów niezabezpieczonych do identyfikowania użycia protokołu SSL/TLSv1.0 na serwerach WWW, ruchu SMBv1 ze starszych stacji roboczych do obrazowania medycznego, wzorców uwierzytelniania LM/NTLMv1, wDigest włączony na serwerach z systemem Windows, niepodpisanych wiązań LDAP ze starszych aplikacji oraz słabego szyfrowania Kerberos RC4 na kontach usług.

• Systematyczne wyłączanie protokołu: Utworzono etapowy plan naprawczy zatwierdzony przez radę doradczą ds. zmian, wyłączono protokół TLSv1.0/1.1 na serwerach internetowych po potwierdzeniu, że użytkownicy portalu pacjentów korzystali z nowoczesnych przeglądarek obsługujących protokół TLS 1.2 lub nowszy, wyłączono protokół SMBv1 po koordynacji z aktualizacjami oprogramowania dostawcy obrazów medycznych, przełączono kontrolery domeny z NTLMv1 na NTLMv2, wyłączono wDigest za pośrednictwem zasad grupy, wymuszono podpisywanie LDAP na kontrolerach domeny i uaktualniono szyfrowanie konta usługi Kerberos do AES256.

• Kontrole kompensujące dla wyjątków: Zaimplementowano mechanizmy kompensujące oparte na sieci dla systemów wymagających tymczasowej obsługi niezabezpieczonych protokołów, w tym izolowaną sieć VLAN dla starszych stacji roboczych do obrazowania medycznego wymagających protokołu SMBv1, reguły NSG ograniczające ruch SMBv1 wyłącznie do izolowanej sieci VLAN, usługa Azure Firewall odmawiająca ruchu wychodzącego SMBv1 z podsieci produkcyjnych, dedykowany serwer przesiadkowy dla starszych aplikacji HR oraz ulepszone monitorowanie przy użyciu usługi Defender for Endpoint oznaczające użycie protokołu poza zatwierdzonymi podsieciami wyjątków.

• Ciągłe monitorowanie: Ustanowiono ciągłą higienę protokołu za pomocą reguł analitycznych Microsoft Sentinel, które wyzwalają alerty dotyczące nowych niezabezpieczonych połączeń protokołu poza zatwierdzonymi wyjątkami, Azure Policy odmawia wdrożenia bez minimalnego wymagania TLS 1.2, oraz cotygodniowych przeglądów skoroszytu protokołu niezabezpieczonego śledzących postęp naprawy.

Wynik: Słabe połączenia TLS zostały wyeliminowane z portali pacjentów. SMBv1 został wyłączony po uaktualnieniu systemów obrazowania medycznego, eliminując lukę w zabezpieczeniach EternalBlue i osiągając zgodność z HIPAA. NTLMv1 przeniesiono do NTLMv2, zapobiegając atakom typu pass-the-hash. WDigest wyłączony złagodził kradzież poświadczeń. Podpisywanie LDAP zablokowało niepodpisane zapytania. Protokół Kerberos został uaktualniony do AES256, co zmniejsza ryzyko ataków typu kerberoasting. Kontrolki wyrównywujące zawierały starsze systemy z zerowym ruchem bocznym. Osiągnięto pełną zgodność z przepisami HIPAA.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-8, SC-8(1), SC-13, IA-5(1)
• PCI-DSS 4: 2.2.4, 4.2.1, 6.2.4
• Kontrole CIS w wersji 8.1: 4.8, 9.3, 13.4
• pl-PL: NIST CSF v2.0: PR.DS-02, PR.IP-01, DE.CM-04
• ISO 27001:2022: A.8.24, A.8.26, A.5.14
• SOC 2: CC6.1, CC6.7, CC7.1

NS-9: Łączenie sieci lokalnej lub chmurowej prywatnie

Zasada zabezpieczeń

Używaj połączeń prywatnych do bezpiecznej komunikacji między różnymi sieciami, takimi jak centra danych dostawcy usług w chmurze i infrastruktura lokalna w środowisku kolokacji.

Ryzyko w celu ograniczenia ryzyka

Gdy dane są przesyłane za pośrednictwem sieci publicznych, są narażone na przechwytywanie, nieautoryzowany dostęp i manipulowanie.

• Przechwytywanie danych: Gdy dane są przesyłane przez sieci publiczne, takie jak Internet, przechodzą przez wiele routerów, przełączników i dostawców usług, z których każdy może zostać naruszony lub monitorowany przez złośliwych podmiotów. Osoby atakujące mogą wdrażać narzędzia do wąchania pakietów (np. Wireshark) w celu przechwytywania pakietów danych. Jeśli dane są niezaszyfrowane lub słabo zaszyfrowane, poufne informacje — takie jak poświadczenia logowania, szczegóły finansowe lub zastrzeżone dane biznesowe — mogą zostać ujawnione.
• Ataki man-in-the-middle (MitM): W ataku MitM atakujący potajemnie przechwytuje i potencjalnie modyfikuje komunikację między dwiema stronami, które sądzą, że komunikują się bezpośrednio ze sobą. Stanowi to poważne zagrożenie dla poufnych operacji, takich jak transakcje finansowe lub procesy uwierzytelniania.
• Nieautoryzowany dostęp: Publiczne lub niewłaściwie zabezpieczone sieci zwiększają prawdopodobieństwo uzyskania dostępu lub naruszenia przez nieautoryzowanych użytkowników w systemach prywatnych lub zasobach. Osoby atakujące mogą wykorzystać słabe strony sieci, aby uzyskać dostęp do wewnętrznej infrastruktury, która powinna pozostać niedostępna z zewnątrz.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystanie niezaszyfrowanych lub słabo zaszyfrowanych protokołów (np. HTTP lub nieaktualnych wersji protokołu TLS) narażonych na ataki sniffing pakietów lub MitM, umożliwiając nieautoryzowane wejście do systemów (np. T1190 — Exploit Public-Facing Application).
• Dostęp poświadczeń (TA0006): Kradzież poświadczeń za pośrednictwem przechwyconego ruchu sieciowego, wykorzystanie protokołów cleartext (np. Telnet lub FTP) lub słabe szyfrowanie podatne na odszyfrowywanie, ułatwianie nieautoryzowanego dostępu (np. T1040 — Sniffing sieci).
• Ruch boczny (TA0008): Propagacja w sieciach przez wykorzystanie nieprawidłowo skonfigurowanych lub uwidocznionych usług (np. niezaznaczonego protokołu RDP lub SMB), co umożliwia osobom atakującym przestawienie się przy użyciu skradzionych poświadczeń lub luk w zabezpieczeniach (np. T1021 — usługi zdalne).

NS-9.1 Używaj wirtualnej sieci prywatnej (VPN) platformy Azure do uproszczonej łączności typu lokacja-lokacja lub połączenia punkt-lokacja

Użyj wirtualnej sieci prywatnej platformy Azure (VPN), aby utworzyć bezpieczne, zaszyfrowane połączenia między lokacjami lokalnymi lub urządzeniami użytkownika końcowego i sieciami wirtualnymi platformy Azure w scenariuszach uproszczonej łączności. Sieć VPN platformy Azure zapewnia ekonomiczne rozwiązanie do łączności typu lokacja-lokacja (łączenie całych sieci) lub połączenia punkt-lokacja (łączenie poszczególnych urządzeń) bez konieczności używania dedykowanej infrastruktury:

• Wdróż sieć VPN typu lokacja-lokacja: Użyj sieci VPN typu lokacja-lokacja, aby bezpiecznie połączyć sieć lokalną z siecią wirtualną platformy Azure, umożliwiając bezproblemową komunikację między zasobami lokalnymi i obciążeniami platformy Azure.

• Wdróż sieć VPN typu punkt-lokacja: Użyj sieci VPN typu punkt-lokacja, aby umożliwić poszczególnym użytkownikom końcowym (laptopom, stacjom roboczym) bezpieczne łączenie się z siecią wirtualną platformy Azure z lokalizacji zdalnych.

NS-9.2 Użyj usługi Azure ExpressRoute (lub usługi Virtual WAN) dla połączeń o wysokiej wydajności na poziomie przedsiębiorstwa

Użyj usługi Azure ExpressRoute lub usługi Azure Virtual WAN, aby ustanowić prywatne połączenia o wysokiej wydajności i małych opóźnieniach między centrami danych platformy Azure i infrastrukturą lokalną w środowiskach kolokacji. Te rozwiązania klasy korporacyjnej pomijają publiczny Internet, zapewniając dedykowaną przepustowość, przewidywalną wydajność i zwiększone zabezpieczenia obciążeń o znaczeniu krytycznym, które wymagają spójnej łączności:

• Wdróż usługę ExpressRoute na potrzeby dedykowanej łączności prywatnej: Użyj usługi Azure ExpressRoute, aby utworzyć prywatne połączenie między infrastrukturą lokalną a centrami danych platformy Azure za pośrednictwem dostawcy łączności, zapewniając dedykowaną przepustowość i przewidywalne opóźnienie obciążeń przedsiębiorstwa.

• Wdróż wirtualną sieć WAN na potrzeby łączności globalnej: Użyj usługi Azure Virtual WAN, aby utworzyć globalną sieć łączącą wiele lokacji, gałęzi i regionów platformy Azure za pomocą ujednoliconej architektury piasty i szprych ze zintegrowanymi funkcjami zabezpieczeń i routingu.

NS-9.3 Użyj peeringu VNet lub peeringu podsieci do łączenia sieci wirtualnych

Użyj komunikacji równorzędnej sieci wirtualnych lub komunikacji równorzędnej podsieci, aby ustanowić łączność prywatną między sieciami wirtualnymi platformy Azure bez routingu ruchu za pośrednictwem publicznego Internetu. Ruch sieciowy między równorzędnymi sieciami wirtualnymi pozostaje w sieci szkieletowej platformy Azure, zapewniając połączenia o małych opóźnieniach i wysokiej przepustowości bez obciążenia związanego z szyfrowaniem. Wybierz peering podsieciowy, gdy pełna łączność z siecią wirtualną nie jest konieczna, ograniczając ekspozycję tylko do określonych podsieci.

• Wdrażanie komunikacji równorzędnej sieci wirtualnych: Użyj komunikacji równorzędnej sieci wirtualnych, aby połączyć całe sieci wirtualne platformy Azure, umożliwiając zasobom w różnych sieciach wirtualnych komunikację prywatną tak, jakby znajdowały się w tej samej sieci.

Przykład implementacji

Międzynarodowa organizacja usług finansowych potrzebowała bezpiecznej, wysokiej wydajności łączności między lokalnymi centrami danych, oddziałami i zasobami chmury platformy Azure przy jednoczesnym wyeliminowaniu publicznej ekspozycji internetowej na poufne transakcje finansowe.

Wyzwanie: Organizacja obsługiwała wiele lokalnych centrów danych z oddziałami na skalę globalną, wymagając łączności z aplikacjami przenośnymi hostowanymi na platformie Azure, które przetwarzają transakcje finansowe i dane klientów. W początkowej architekturze użyto sieci VPN typu lokacja-lokacja przez Internet, występują nieprzewidywalne opóźnienia, ograniczenia przepustowości w godzinach szczytu handlu, obawy dotyczące bezpieczeństwa dotyczące danych finansowych przechodzących przez publiczny Internet pomimo szyfrowania i wymagań dotyczących zgodności, które nakazują łączność prywatną dla PCI-DSS i RODO. Pracownicy zdalni łączący się za pośrednictwem sieci VPN typu punkt-lokacja napotykali niespójne problemy z wydajnością i uwierzytelnianiem. Aplikacje w różnych regionach świadczenia usługi Azure wymagają komunikacji między regionami o małych opóźnieniach bez routingu za pośrednictwem centrów lokalnych.

Rozwiązanie:

• Usługa ExpressRoute dla podstawowej łączności centrum danych: Wdrożone obwody usługi Azure ExpressRoute w głównych centrach danych za pośrednictwem obiektów kolokacyjnych z dostawcami łączności usługi ExpressRoute, ustanowienie prywatnej łączności warstwy 3 z siecią szkieletową platformy Azure ze stałymi małymi opóźnieniami, usługę ExpressRoute skonfigurowano z równorzędnym peeringiem Microsoft dla usług Azure PaaS i prywatnym peeringiem dla zasobów hostowanych w sieci wirtualnej, zaimplementowano routing BGP z konfiguracją aktywną-aktywną w celu zapewnienia wysokiej dostępności i automatycznego przełączania awaryjnego.

• Sieć VPN typu lokacja-lokacja na potrzeby łączności biur oddziałów: Wdrożono sieć VPN typu lokacja-lokacja dla oddziałów, które nie mają dostępu do lokalizacji współlokacyjnej, tworząc bramę sieci VPN w sieci wirtualnej koncentratora (VNet) z konfiguracją aktywne-aktywne, co zapewnia wysoką dostępność. Skonfigurowano tunele IPsec/IKE z wykorzystaniem silnej kryptografii spełniającej standardy bezpieczeństwa sektora finansowego, zaimplementowano routing BGP na potrzeby dynamicznego wyboru ścieżek, co umożliwia oddziałom łączenie się z najbliższym regionalnym koncentratorem. Ustanowiono nadmiarowe tunele zapewniające łączność podczas okien konserwacyjnych.

• Sieć VPN typu punkt-lokacja dla pracowników zdalnych: Skonfigurowano sieć VPN typu punkt-lokacja z uwierzytelnianiem usługi Azure Active Directory dla pracowników zdalnych wymagających bezpiecznego dostępu do aplikacji hostowanych na platformie Azure, włączono uwierzytelnianie oparte na certyfikatach jako rozwiązanie awaryjne na wypadek braku dostępu do Internetu do usługi Azure AD, adresy IP klientów przypisano z dedykowanej puli, które są kierowane do zasobów sieci wirtualnej platformy Azure za pośrednictwem tras zdefiniowanych przez użytkownika, zaimplementowano protokół OpenVPN dla klientów z systemem macOS/Linux oraz protokół IKEv2/SSTP dla klientów z systemem Windows, co zapewnia szeroką kompatybilność urządzeń, skonfigurowano tunelowanie podzielone, które pozwala na bezpośredni dostęp do Internetu dla ruchu niezwiązanego z firmą, podczas gdy ruch kierowany do platformy Azure przechodzi przez tunel VPN, co optymalizuje przepustowość.

• Wirtualna sieć WAN na potrzeby łączności z globalną siatką: Wdrożono usługę Azure Virtual WAN z bezpiecznymi koncentratorami w wielu regionach zapewniających globalną architekturę tranzytową, połączone obwody usługi ExpressRoute z koncentratorami usługi Virtual WAN, które umożliwiają dowolną łączność między centrami danych i regionami platformy Azure bez routingu za pośrednictwem koncentratorów lokalnych, zintegrowanych połączeń sieci VPN typu lokacja-lokacja z oddziałów do najbliższego koncentratora usługi Virtual WAN z automatyczną optymalizacją routingu, włączono usługę Azure Firewall w każdym koncentratorze usługi Virtual WAN zapewniając scentralizowaną inspekcję zabezpieczeń dla ruchu między oddziałami, centrami danych i sieciami wirtualnymi platformy Azure, skonfigurowano zasady routingu, które implementują globalny routing tranzytowy, co umożliwia oddziałom komunikowanie się z lokalnych centrów danych za pośrednictwem sieci szkieletowej platformy Azure.

• Komunikacja równorzędna sieci wirtualnych dla łączności między regionami platformy Azure: Zaimplementowano komunikację równorzędną sieci wirtualnych łączącą sieci szprych z sieciami wirtualnymi koncentratora usługi Virtual WAN w każdym regionie, włączono globalną komunikację równorzędną dla aplikacji między regionami, zapewniającą niskie opóźnienia za pośrednictwem sieci szkieletowej platformy Azure, skonfigurowano tranzyt bramy, umożliwiając sieciom szprych korzystanie z bram VPN/ExpressRoute koncentratora usługi Virtual WAN bez potrzeby wdrażania dodatkowych bram, co zmniejsza koszty i złożoność. Zaimplementowano sieciowe grupy zabezpieczeń na podsieciach szprych, kontrolujące przepływ ruchu między równorzędnymi sieciami wirtualnymi z najmniejszymi potrzebnymi uprawnieniami.

• Optymalizacja i monitorowanie ruchu: Skonfigurowano obwody usługi ExpressRoute z oznaczeniami QoS priorytetowymi ruchem transakcji finansowych nad transferami danych zbiorczych, włączono Connection Monitor do śledzenia opóźnień, utraty pakietów i dostępności dla obwodów usługi ExpressRoute i połączeń sieci VPN z alertami dla degradacji, zaimplementowano skoroszyty usługi Azure Monitor wizualizujące globalną topologię łączności przedstawiającą aktywne połączenia, wykorzystanie przepustowości i zdarzenia trybu failover, ustalono bazowe wskaźniki akceptowalnej wydajności za pomocą zautomatyzowanych alertów w przypadku naruszeń progu.

Wynik: Łączność prywatna została osiągnięta dla wszystkich transakcji finansowych, spełniając PCI-DSS wymagania. Usługa ExpressRoute zapewniała spójne małe opóźnienia w handlu w czasie rzeczywistym. Usługa Virtual WAN znacznie zmniejszyła opóźnienie między oddziałami i centrami danych. Zdalni pracownicy pomyślnie nawiązali połączenie za pośrednictwem sieci VPN typu punkt-lokacja z ulepszonym uwierzytelnianiem. Global VNet peering umożliwiło wydajne odzyskiwanie po awarii między regionami. Optymalizacja kosztów osiągnięta za pośrednictwem konsolidacji usługi Virtual WAN.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-7, SC-7(4), SC-8
• PCI-DSS 4: 1.2.1, 2.2.7, 4.2.1
• Kontrole CIS w wersji 8.1: 12.8, 13.8
• NIST CSF v2.0: PR.AC-05, PR.DS-02
• ISO 27001:2022: A.8.21, A.8.22, A.5.14
• SOC 2: CC6.6, CC6.7

NS-10: Zapewnianie zabezpieczeń systemu nazw domen (DNS)

Zasada zabezpieczeń

Upewnij się, że konfiguracja zabezpieczeń systemu nazw domen (DNS) chroni przed znanymi zagrożeniami:

• Użyj zaufanych autorytatywnych i cyklicznych usług DNS w środowisku chmury, aby upewnić się, że klient (taki jak systemy operacyjne i aplikacje) otrzyma prawidłowy wynik rozwiązania.
• Oddziel publiczne i prywatne rozpoznawanie nazw DNS, aby proces rozpoznawania nazw DNS dla sieci prywatnej mógł być odizolowany od sieci publicznej.
• Upewnij się, że strategia zabezpieczeń DNS obejmuje również środki zaradcze przed typowymi atakami, takimi jak zwisające ataki DNS, ataki wzmacniania DNS, zatrucie DNS i fałszowanie itd.

Ryzyko w celu ograniczenia ryzyka

Podmioty zagrożeń atakują usługi DNS lub wykorzystują podatne na zagrożenia usługi DNS w celu naruszenia zabezpieczeń aplikacji i przekierowywania ruchu.

• Fałszowanie/zatrucie DNS: Przeciwnicy fałszują odpowiedzi DNS lub uszkadzają pamięci podręczne (np. dzięki atakowi Kaminsky), aby przekierować klientów do złośliwych serwerów, umożliwiając wyłudzanie informacji lub przechwytywanie danych.
• Ataki wzmacniania DNS: Osoby atakujące wykorzystują błędnie skonfigurowane serwery DNS w celu wzmacniania ruchu DDoS (np. zapytania 60-bajtowego, które daje 4000 bajtów odpowiedzi), przytłaczające sieci docelowe.
• Wykorzystanie wiszących rekordów DNS: Wiszące rekordy (np. nieaktualne CNAME) umożliwiają przeciwnikom przejmowanie zlikwidowanych zasobów, przekierowanie ruchu do złośliwych punktów końcowych w celu wyłudzenia informacji lub dostarczenia złośliwego oprogramowania.
• Eksfiltracja danych za pośrednictwem tunelowania DNS: Złośliwi aktorzy kodują dane w zapytaniach DNS (np. data.exfil.evil.com), aby potajemnie eksfiltrować poufne informacje, pomijając zapory.
• Wyłudzanie informacji/dostarczanie złośliwego oprogramowania: Naruszone programy rozpoznawania nazw przekierowują wiarygodne domeny do adresów IP kontrolowanych przez osobę atakującą, dostarczając strony wyłudzające informacje lub złośliwe oprogramowanie do nie podejrzewających klientów.

MITRE ATT&CK

• Komenda i sterowanie (TA0011): Użyj tunelowania DNS, aby zakodować polecenia C2 w zapytaniach (np. data.exfil.evil.com) lub fałszowanie rozwiązań w celu nawiązania połączenia ze złośliwymi serwerami (np. T1071.004 — Protokół warstwy aplikacji: DNS).
• Kolekcja (TA0009): Zbieranie danych przez fałszowanie DNS w celu przekierowania użytkowników do witryn wyłudzających informacje lub eksfiltrowanie danych za pośrednictwem tunelowania (np. T1040 — przechwytywanie ruchu sieci).
• Wpływ (TA0040): Ataki odbicia DNS, wysyłając małe zapytania w celu wygenerowania dużych odpowiedzi, zakłócające dostępność usług (np. T1498.002 — odmowa usługi sieciowej: amplifikacja odbicia).
• Dostęp początkowy (TA0001): Wykorzystanie zwisanych rekordów DNS lub sfałszowanych rozwiązań w celu dostarczania złośliwego oprogramowania/wyłudzania informacji, uzyskiwania dostępu do systemów (np. T1190 — Exploit Public-Facing Application).

NS-10.1 Użyj zaufanej usługi DNS

Użyj zaufanych usług DNS, aby upewnić się, że klienci otrzymują poprawne wyniki rozpoznawania i chronią przed atakami opartymi na systemie DNS. Platforma Azure udostępnia rekursywną usługę DNS pod adresem 168.63.129.16 (zazwyczaj przypisywana za pośrednictwem protokołu DHCP lub wstępnie skonfigurowana) do rozwiązywania nazw DNS dla obciążeń na poziomie systemu operacyjnego lub aplikacji. Alternatywnie należy użyć zaufanych zewnętrznych serwerów DNS. W przypadku organizacji hostujących własne domeny usługa Azure DNS zapewnia niezawodny autorytatywny hosting DNS. Organizacje tworzące niestandardowe serwery DNS powinny przestrzegać wytycznych dotyczących bezpiecznego wdrażania NIST SP 800-81 Rev. 3:

• Użyj cyklicznego systemu DNS platformy Azure lub zaufanego zewnętrznego systemu DNS: Skonfiguruj obciążenia tak, aby korzystały z cyklicznego serwera DNS platformy Azure (168.63.129.16) lub zaufanych zewnętrznych serwerów DNS w systemach operacyjnych maszyn wirtualnych lub ustawieniach DNS aplikacji, aby zapewnić niezawodne rozpoznawanie nazw.

• Zezwalaj na usługę Azure DNS w regułach zapory: Dodaj 168.63.129.16 do listy dozwolonych zapory i grupy zabezpieczeń sieciowych, aby zapewnić prawidłowe działanie DNS dla zasobów platformy Azure.

• Hostuj domeny w usłudze Azure DNS: Użyj usługi Azure DNS do hostowania rozwiązywania domen na potrzeby autorytatywnego DNS, zapewniając niezawodność i skalowalność usługi hostingu DNS (uwaga: usługa Azure DNS nie zapewnia usługi rejestracji domen).

• Postępuj zgodnie z wytycznymi dotyczącymi bezpiecznego wdrażania DNS: W przypadku tworzenia niestandardowych serwerów DNS postępuj zgodnie z przewodnikiem wdrażania NIST SP 800-81 Rev. 3 Secure Domain Name System (DNS), aby zaimplementować najlepsze rozwiązania w zakresie zabezpieczeń.

NS-10.2 Użyj prywatnego systemu DNS w sieci wirtualnej

Użyj prywatnej usługi DNS platformy Azure w celu utworzenia prywatnych stref DNS, w których rozpoznawanie nazw DNS pozostaje w sieci wirtualnej, zapobiegając przechodzeniu zapytań DNS przez sieci publiczne. Jest to niezbędne w przypadku konfiguracji prywatnych punktów końcowych, w których prywatne strefy DNS zastępują publiczne rozpoznawanie nazw DNS w celu kierowania ruchu prywatnego do usług platformy Azure. Niestandardowe rozwiązania DNS mogą dodatkowo ograniczyć rozpoznawanie tylko zaufanych źródeł, zwiększając bezpieczeństwo obciążeń prywatnych:

• Wdróż Azure Private DNS na potrzeby rozpoznawania prywatnego: Użyj Azure Private DNS, aby utworzyć strefy DNS prywatne, które utrzymują rozpoznawanie nazw DNS w sieci wirtualnej, zapewniając, że zapytania te nigdy nie opuszczają granic sieciowych.

• Skonfiguruj prywatną usługę DNS dla prywatnych punktów końcowych: Skonfiguruj prywatne strefy DNS dla prywatnych punktów końcowych, aby zastąpić publiczne rozpoznawanie nazw DNS i upewnić się, że klienci rozpoznają prywatne nazwy FQDN punktu końcowego na prywatne adresy IP w sieci wirtualnej.

• Zaimplementuj niestandardowy system DNS do rozpoznawania z ograniczeniami: Użyj niestandardowych serwerów DNS, aby ograniczyć rozpoznawanie nazw w celu zezwolenia tylko na zaufane źródła rozpoznawania nazw dla klientów, zapewniając dodatkową kontrolę nad zabezpieczeniami rozpoznawania nazw.

NS-10.3 Używanie usługi Defender dla systemu DNS do zaawansowanej ochrony

Usługa Microsoft Defender dla systemu DNS umożliwia wykrywanie i zgłaszanie alertów dotyczących zaawansowanych zagrożeń zabezpieczeń opartych na systemie DNS, w tym eksfiltracji danych za pośrednictwem tunelowania DNS, komunikacji poleceń i kontroli, złośliwych interakcji z domeną (wyłudzanie informacji, wyszukiwanie kryptograficzne) i ataków DNS obejmujących złośliwe programy rozpoznawania nazw. Ochrona usługi Defender for DNS jest teraz uwzględniona w planie usługi Defender for Servers. Ponadto użyj usługi Microsoft Defender for App Service, aby wykryć zwisające rekordy DNS, które mogą włączyć ataki przejęcia poddomeny podczas likwidowania witryn internetowych:

• Włącz ochronę usługi Defender dla systemu DNS: Usługa Microsoft Defender for DNS (uwzględniona w planie usługi Defender for Servers) umożliwia monitorowanie i zgłaszanie alertów dotyczących podejrzanych działań DNS, w tym eksfiltracji danych za pośrednictwem tunelowania DNS, komunikacji poleceń i kontroli złośliwego oprogramowania oraz interakcji ze złośliwymi domenami.

• Monitorowanie złośliwych działań DNS: Skonfiguruj alerty w celu wykrywania komunikacji ze złośliwymi programami rozpoznawania nazw DNS i atakami DNS, które mogą naruszyć bezpieczeństwo obciążenia lub dostępność usługi DNS.

• Wykryj zwisające rekordy DNS: Użyj usługi Microsoft Defender for App Service, aby zidentyfikować zwisające rekordy DNS podczas likwidowania witryn internetowych usługi App Service, zapobiegając atakom przejęcia poddomeny przez zapewnienie usunięcia domen niestandardowych z rejestratorów DNS.

Przykład implementacji

Wyzwanie: Przedsiębiorstwo potrzebowało kompleksowych zabezpieczeń DNS obejmujących zaufane usługi rozpoznawania, prywatną sieć DNS dla zasobów wewnętrznych i zaawansowane wykrywanie zagrożeń w infrastrukturze chmury hybrydowej.

Podejście do rozwiązania:

• Zastosowano rekursywną usługę DNS platformy Azure (168.63.129.16) dla wszystkich obciążeń maszyn wirtualnych Azure z regułami sieciowej grupy zabezpieczeń zezwalającymi na ruch DNS.
• Hostowane strefy autorytatywne w usłudze Azure DNS na potrzeby rozpoznawania domen publicznych za pomocą dystrybucji geograficznej
• Zaimplementowano prywatne strefy DNS platformy Azure na potrzeby rozpoznawania prywatnych punktów końcowych (privatelink.database.windows.net, privatelink.blob.core.windows.net) połączonych z produkcyjnymi sieciami wirtualnymi
• Skonfigurowano Prywatną Integrację DNS, aby zapewnić rozpoznawanie prywatnych FQDN na prywatne adresy IP prywatnych punktów końcowych (np. sqlserver.database.windows.net → 10.0.2.4)
• Włączono Microsoft Defender dla DNS w planie Defender dla serwerów w celu monitorowania tunelowania DNS, komunikacji C2 i złośliwych interakcji z domeną.
• Wdrożono usługę Defender for App Service w celu wykrywania zwisających rekordów DNS podczas likwidowania witryny internetowej

Wynik: Implementacja zabezpieczeń DNS zapewniła niezawodne rozpoznawanie nazw dla obciążeń w chmurze przy zachowaniu prywatności dla zasobów wewnętrznych. Prywatne strefy DNS uniemożliwiły przechodzenie poufnych zapytań przez sieci publiczne, podczas gdy usługa Defender dla systemu DNS zapewniała wgląd w zagrożenia oparte na systemie DNS, w tym próby eksfiltracji danych i działania poleceń i kontroli. Rozwiązanie wyeliminowało ryzyko przejęcia poddomeny poprzez zautomatyzowane wykrywanie nieprzypisanych rekordów DNS podczas zmian w cyklu życia zasobów.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: SC-7, SI-4, SI-4(4), SI-4(5)
• PCI-DSS 4: 11.5.1, 12.10.1
• Kontrolki CIS w wersji 8.1: 8.5, 13.6, 13.8
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. AE-02
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2, CC7.3