Zalecenia dotyczące sieci i łączności

Artykuł
11/15/2023

Dotyczy tego zalecenia listy kontrolnej zabezpieczeń usługi Azure Well-Architected Framework:

SE:05	Izoluj, filtruj i steruj ruchem sieciowym zarówno w przepływach przychodzących, jak i wychodzących. Stosowanie ochrony w głębi systemu za pomocą zlokalizowanych mechanizmów kontroli sieci we wszystkich dostępnych granicach sieci w ruchu wschód-zachód i północ-południe.

W tym przewodniku opisano zalecenia dotyczące projektowania sieci. Koncentruje się on na mechanizmach kontroli zabezpieczeń, które mogą filtrować, blokować i wykrywać przeciwników przekraczających granice sieci w różnych głębiach architektury.

Mechanizmy kontroli tożsamości można wzmocnić, implementując miary kontroli dostępu opartej na sieci. Oprócz kontroli dostępu opartej na tożsamościach zabezpieczenia sieci mają wysoki priorytet w zakresie ochrony zasobów. Odpowiednie mechanizmy kontroli zabezpieczeń sieci mogą zapewnić szczegółowy element ochrony, który może pomóc wykrywać i zawierać zagrożenia oraz zapobiegać uzyskiwaniu dostępu do obciążenia przez osoby atakujące.

Definicje

Okres	Definicja
Ruch wschodnio-zachodni	Ruch sieciowy, który porusza się w ramach zaufanej granicy.
Przepływ ruchu wychodzącego	Ruch obciążeń wychodzących.
Sieć wroga	Sieć, która nie jest wdrożona w ramach obciążenia. Sieć wroga jest uważana za wektor zagrożenia.
Przepływ ruchu przychodzącego	Ruch przychodzący obciążenia.
Filtrowanie sieci	Mechanizm, który zezwala na ruch sieciowy lub blokuje go na podstawie określonych reguł.
Segmentacja sieci lub izolacja	Strategia dzieląca sieć na małe, izolowane segmenty z mechanizmami kontroli zabezpieczeń stosowanymi na granicach. Ta technika pomaga chronić zasoby przed wrogimi sieciami, takimi jak Internet.
Przekształcanie sieci	Mechanizm, który wycisza pakiety sieciowe, aby je zasłonić.
Ruch północno-południowy	Ruch sieciowy, który przechodzi z zaufanej granicy do sieci zewnętrznych, które są potencjalnie wrogie i na odwrót.

Kluczowe strategie projektowania

Zabezpieczenia sieciowe używają zaciemnienia w celu ochrony zasobów obciążeń przed wrogimi sieciami. Zasoby, które znajdują się za granicą sieci, są ukryte, dopóki kontrolki granic nie oznaczą ruchu jako bezpiecznego do przodu. Projekt zabezpieczeń sieci opiera się na trzech głównych strategiach:

Segment. Ta technika izoluje ruch w oddzielnych sieciach przez dodanie granic. Na przykład ruch do i z warstwy aplikacji przekazuje granicę do komunikacji z innymi warstwami, które mają różne wymagania dotyczące zabezpieczeń. Warstwy segmentacji zdysekwują podejście do ochrony w głębi systemu.

Najważniejszą granicą zabezpieczeń jest krawędź sieci między aplikacją a sieciami publicznymi. Ważne jest, aby jasno zdefiniować ten obwód, aby ustanowić granicę dla izolowania wrogich sieci. Kontrolki na tej krawędzi muszą być wysoce skuteczne, ponieważ granica ta jest pierwszą linią obrony.

Sieci wirtualne zapewniają granicę logiczną. Zgodnie z projektem sieć wirtualna nie może komunikować się z inną siecią wirtualną, chyba że granica została celowo przerwana przez komunikację równorzędną. Twoja architektura powinna korzystać z tej silnej, zapewnianej przez platformę miary zabezpieczeń.

Można również użyć innych granic logicznych, takich jak wyrzeźbione podsieci w sieci wirtualnej. Zaletą podsieci jest to, że można ich używać do grupowania zasobów, które znajdują się w granicach izolacji i mają podobne zabezpieczenia. Następnie można skonfigurować kontrolki na granicy, aby filtrować ruch.
Filtruj. Ta strategia pomaga zapewnić, że ruch, który przechodzi przez granicę, jest oczekiwany, dozwolony i bezpieczny. Z perspektywy Zero-Trust filtrowanie jawnie weryfikuje wszystkie dostępne punkty danych na poziomie sieci. Możesz umieścić reguły na granicy, aby sprawdzić określone warunki.

Na przykład na poziomie nagłówka reguły mogą sprawdzić, czy ruch pochodzi z oczekiwanej lokalizacji lub ma oczekiwany wolumin. Ale te kontrole nie są wystarczające. Nawet jeśli ruch wykazuje oczekiwane cechy, ładunek może nie być bezpieczny. Sprawdzanie poprawności może ujawnić atak polegający na wstrzyknięciu kodu SQL.
Przekształć. Zmutuj pakiety na granicy jako środek zabezpieczeń. Na przykład można usunąć nagłówki HTTP, aby wyeliminować ryzyko narażenia. Możesz też wyłączyć protokół Transport Layer Security (TLS) w jednym momencie i ponownie opublikować go na innym przeskoku przy użyciu certyfikatu, który jest zarządzany bardziej rygorystycznie.

Klasyfikowanie przepływów ruchu

Pierwszym krokiem klasyfikowania przepływów jest zbadanie schematu architektury obciążenia. Na podstawie schematu określ intencję i charakterystykę przepływu w odniesieniu do funkcjonalnych aspektów narzędziowych i operacyjnych obciążenia. Aby sklasyfikować przepływ, skorzystaj z następujących pytań:

Jeśli obciążenie musi komunikować się z sieciami zewnętrznymi, jaki powinien być wymagany poziom bliskości tych sieci?
Jakie są cechy sieciowe przepływu, takie jak oczekiwany protokół i źródło i kształt pakietów? Czy istnieją jakiekolwiek wymagania dotyczące zgodności na poziomie sieci?

Istnieje wiele sposobów klasyfikowania przepływów ruchu. W poniższych sekcjach omówiono często używane kryteria.

Widoczność z sieci zewnętrznych

Publiczne. Obciążenie jest dostępne publicznie, jeśli jego aplikacja i inne składniki są dostępne z publicznego Internetu. Aplikacja jest uwidaczniona za pośrednictwem co najmniej jednego publicznego adresu IP i publicznych serwerów systemu nazw domen (DNS).
Prywatne. Obciążenie jest prywatne, jeśli można uzyskać do niego dostęp tylko za pośrednictwem sieci prywatnej, takiej jak wirtualna sieć prywatna (VPN). Jest on udostępniany tylko za pośrednictwem co najmniej jednego prywatnego adresu IP i potencjalnie za pośrednictwem prywatnego serwera DNS.

W sieci prywatnej nie ma zasięgu wzroku od publicznego Internetu do obciążenia. W przypadku bramy można użyć modułu równoważenia obciążenia lub zapory. Te opcje mogą zapewnić bezpieczeństwo.

Nawet w przypadku obciążeń publicznych staraj się zachować jak najwięcej obciążeń prywatnych. Takie podejście wymusza przechodzenie pakietów przez granicę prywatną po odebraniu ich z sieci publicznej. Brama w tej ścieżce może działać jako punkt przejścia, działając jako zwrotny serwer proxy.

Kierunek ruchu

Ruch przychodzący. Ruch przychodzący jest ruchem przychodzącym, który przepływa do obciążenia lub jego składników. Aby ułatwić zabezpieczanie ruchu przychodzącego, zastosuj poprzedni zestaw kluczowych strategii. Określ, jakie źródło ruchu jest i czy jest oczekiwane, dozwolone i bezpieczne. Osoby atakujące, które skanują zakresy adresów IP dostawcy chmury publicznej, mogą pomyślnie przeniknąć do obrony, jeśli nie zaewidencjonujesz ruchu przychodzącego ani nie zaimplementujesz podstawowych środków zabezpieczeń sieci.
Ruch wychodzący. Ruch wychodzący to ruch wychodzący, który przepływa z dala od obciążenia lub jego składników. Aby sprawdzić ruch wychodzący, określ, gdzie jest kierowany ruch i czy miejsce docelowe jest oczekiwane, dozwolone i bezpieczne. Miejsce docelowe może być złośliwe lub skojarzone z ryzykiem eksfiltracji danych.

Możesz również określić poziom ekspozycji, biorąc pod uwagę bliskość obciążenia z publicznym Internetem. Na przykład platforma aplikacji zwykle obsługuje publiczne adresy IP. Składnik obciążenia jest twarzą rozwiązania.

Zakres wpływu

Północ-południe. Ruch przepływający między siecią obciążenia a sieciami zewnętrznymi jest ruchem północno-południowym. Ten ruch przekracza krawędź sieci. Sieci zewnętrzne mogą być publicznym Internetem, siecią firmową lub dowolną inną siecią poza zakresem kontroli.

Ruch przychodzący i wychodzący mogą być ruchami północno-południowymi.

Rozważmy na przykład przepływ ruchu wychodzącego topologii sieci piasty i szprych. Możesz zdefiniować krawędź sieciową obciążenia, aby koncentrator był siecią zewnętrzną. W takim przypadku ruch wychodzący z sieci wirtualnej szprychy jest ruchem północno-południowym. Jeśli jednak uważasz, że sieć piasty w obrębie kontroli, ruch północno-południowy jest rozszerzony do zapory w centrum, ponieważ następny przeskok jest Internetem, który jest potencjalnie wrogi.
Wschód-zachód. Ruch, który przepływa w sieci obciążenia, to ruch wschodnio-zachodni. Ten typ ruchu powoduje, że składniki w obciążeniu komunikują się ze sobą. Przykładem jest ruch między warstwami aplikacji n-warstwowej. W mikrousługach komunikacja między usługami to ruch wschodnio-zachodni.

Aby zapewnić ochronę w głębi systemu, zachowaj kompleksową kontrolę nad zabezpieczeniami, które są uwzględniane w każdym przeskoku lub które są używane w przypadku pakietów między segmentami wewnętrznymi. Różne poziomy ryzyka wymagają różnych metod korygowania ryzyka.

Powyższy diagram ilustruje ochronę sieci w głębi chmury prywatnej. Na tym diagramie granica między przestrzeniami publicznych i prywatnych adresów IP jest znacznie mniejsza od obciążenia niż na diagramie chmury publicznej. Wiele warstw oddziela wdrożenia platformy Azure od publicznej przestrzeni adresów IP.

Uwaga

Tożsamość jest zawsze podstawowym obwodem. Zarządzanie dostępem musi być stosowane do przepływów sieciowych. Użyj tożsamości zarządzanych, gdy używasz kontroli dostępu opartej na rolach (RBAC) platformy Azure między składnikami sieci.

Po sklasyfikowaniu przepływów wykonaj ćwiczenie segmentacji, aby zidentyfikować punkty iniekcji zapory na ścieżkach komunikacyjnych segmentów sieci. Podczas projektowania ochrony sieci w głębi wszystkich segmentów i wszystkich typów ruchu należy założyć naruszenie we wszystkich punktach. Użyj kombinacji różnych zlokalizowanych kontrolek sieci na wszystkich dostępnych granicach. Aby uzyskać więcej informacji, zobacz Strategie segmentacji.

Stosowanie zapór na brzegu

Ruch brzegowy w Internecie jest ruchem północno-południowym i obejmuje ruch przychodzący i wychodzący. Aby wykrywać lub blokować zagrożenia, strategia brzegowa musi ograniczyć jak najwięcej ataków do i z Internetu.

W przypadku ruchu wychodzącego wyślij cały ruch związany z Internetem za pośrednictwem jednej zapory , która zapewnia ulepszony nadzór, ład i kontrolę ruchu. W przypadku ruchu przychodzącego wymuś cały ruch z Internetu, aby przejść przez wirtualne urządzenie sieciowe (WUS) lub zaporę aplikacji internetowej.

Zapory są zwykle pojedynczymitonami, które są wdrażane w poszczególnych regionach w organizacji. W rezultacie są one udostępniane między obciążeniami i należą do zespołu centralnego. Upewnij się, że wszystkie używane urządzenia WUS są skonfigurowane do obsługi potrzeb obciążenia.
Zalecamy jak najwięcej użycia natywnych kontrolek platformy Azure.

Oprócz kontrolek natywnych można również rozważyć wirtualne urządzenia WUS partnera, które udostępniają zaawansowane lub wyspecjalizowane funkcje. Zapora partnerów i produkty dostawcy zapory aplikacji internetowej są dostępne w Azure Marketplace.

Decyzja o używaniu funkcji natywnych w przeciwieństwie do rozwiązań partnerskich powinna być oparta na doświadczeniu i wymaganiach organizacji.

Kompromis: Możliwości partnerów często zapewniają zaawansowane funkcje, które mogą chronić przed wyrafinowanymi, ale zazwyczaj nietypowymi atakami. Konfiguracja rozwiązań partnerskich może być złożona i krucha, ponieważ te rozwiązania nie integrują się z kontrolerami sieci szkieletowej chmury. Z perspektywy kosztów preferowana jest natywna kontrola, ponieważ jest tańsza niż rozwiązania partnerskie.

Wszelkie opcje technologiczne, które należy wziąć pod uwagę, powinny zapewnić mechanizmy kontroli zabezpieczeń i monitorowanie przepływów ruchu przychodzącego i wychodzącego. Aby wyświetlić opcje dostępne dla platformy Azure, zobacz sekcję Zabezpieczenia usługi Edge w tym artykule.

Projektowanie zabezpieczeń sieci wirtualnej i podsieci

Głównym celem chmury prywatnej jest zaciemnianie zasobów z publicznego Internetu. Istnieje kilka sposobów osiągnięcia tego celu:

Przejdź do prywatnych przestrzeni adresów IP, które można wykonać za pomocą sieci wirtualnych. Zminimalizuj linię wzroku sieci nawet w ramach własnych sieci prywatnych.
Zminimalizuj liczbę publicznych wpisów DNS używanych do uwidocznienia mniejszego obciążenia.
Dodaj kontrolkę przepływu ruchu przychodzącego i wychodzącego. Nie zezwalaj na ruch, który nie jest zaufany.

Strategia segmentacji

Aby zminimalizować widoczność sieci, należy podzielić sieć i rozpocząć od kontroli sieci z najmniejszymi uprawnieniami. Jeśli segment nie jest routingiem, nie można uzyskać do niego dostępu. Poszerzanie zakresu w celu uwzględnienia tylko segmentów, które muszą komunikować się ze sobą za pośrednictwem dostępu do sieci.

Sieci wirtualne można segmentować, tworząc podsieci. Kryteria podziału powinny być celowe. Podczas sortowania usług wewnątrz podsieci upewnij się, że te usługi będą widzieć się nawzajem.

Segmentację można opierać na wielu czynnikach. Można na przykład umieścić różne warstwy aplikacji w dedykowanych segmentach. Innym podejściem jest zaplanowanie podsieci na podstawie typowych ról i funkcji korzystających z dobrze znanych protokołów.

Aby uzyskać więcej informacji, zobacz Strategie segmentacji.

Zapory podsieci

Ważne jest, aby sprawdzić ruch przychodzący i wychodzący każdej podsieci. Skorzystaj z trzech głównych strategii omówionych wcześniej w tym artykule w temacie Kluczowe strategie projektowania. Sprawdź, czy przepływ jest oczekiwany, dozwolony i bezpieczny. Aby zweryfikować te informacje, zdefiniuj reguły zapory oparte na protokole, źródle i miejscu docelowym ruchu.

Na platformie Azure należy ustawić reguły zapory w sieciowych grupach zabezpieczeń. Aby uzyskać więcej informacji, zobacz sekcję Sieciowe grupy zabezpieczeń w tym artykule.

Przykładowy projekt podsieci można znaleźć w temacie Azure Virtual Network podsieci.

Używanie kontrolek na poziomie składnika

Po zminimalizowaniu widoczności sieci zamapuj zasoby platformy Azure z perspektywy sieci i oceń przepływy. Możliwe są następujące typy przepływów:

Planowany ruch lub celowa komunikacja między usługami zgodnie z projektem architektury. Na przykład masz zaplanowany ruch, gdy architektura zaleca, aby Azure Functions ściąga komunikaty z Azure Service Bus.
Ruch zarządzania lub komunikacja wykonywana w ramach funkcjonalności usługi. Ten ruch nie jest częścią projektu i nie masz kontroli nad nim. Przykładem ruchu zarządzanego jest komunikacja między usługami platformy Azure w architekturze a płaszczyzną zarządzania platformy Azure.

Rozróżnianie ruchu planowanego i zarządzania pomaga w tworzeniu zlokalizowanych lub na poziomie usług kontrolek. Dobrze zrozumieć źródło i miejsce docelowe na każdym przeskoku. Szczególnie dowiedz się, jak jest uwidoczniona płaszczyzna danych.

Jako punkt wyjścia określ, czy każda usługa jest uwidoczniona w Internecie. Jeśli tak jest, zaplanuj, jak ograniczyć dostęp. Jeśli tak nie jest, umieść ją w sieci wirtualnej.

Zapory usług

Jeśli oczekujesz, że usługa zostanie udostępniona w Internecie, skorzystaj z zapory na poziomie usługi dostępnej dla większości zasobów platformy Azure. W przypadku korzystania z tej zapory można ustawić reguły na podstawie wzorców dostępu. Aby uzyskać więcej informacji, zobacz sekcję Zapory usług platformy Azure w tym artykule.

Uwaga

Jeśli składnik nie jest usługą, użyj zapory opartej na hoście oprócz zapór na poziomie sieci. Maszyna wirtualna to przykład składnika, który nie jest usługą.

Łączność z usługami PaaS (Platform as a Service)

Rozważ użycie prywatnych punktów końcowych, aby zapewnić bezpieczny dostęp do usług PaaS. Prywatny punkt końcowy ma przypisany prywatny adres IP z sieci wirtualnej. Punkt końcowy umożliwia innym zasobom w sieci komunikowanie się z usługą PaaS za pośrednictwem prywatnego adresu IP.

Komunikacja z usługą PaaS jest osiągana przy użyciu publicznego adresu IP usługi i rekordu DNS. Ta komunikacja odbywa się za pośrednictwem Internetu. Możesz ustawić, że komunikacja jest prywatna.

Tunel z usługi PaaS do jednej z podsieci tworzy kanał prywatny. Cała komunikacja odbywa się z prywatnego adresu IP składnika do prywatnego punktu końcowego w tej podsieci, który następnie komunikuje się z usługą PaaS.

W tym przykładzie obraz po lewej stronie przedstawia przepływ dla publicznie uwidocznionych punktów końcowych. Po prawej stronie ten przepływ jest zabezpieczony przy użyciu prywatnych punktów końcowych.

Aby uzyskać więcej informacji, zobacz sekcję Prywatne punkty końcowe w tym artykule.

Uwaga

Zalecamy używanie prywatnych punktów końcowych w połączeniu z zaporami usług. Zapora usługi blokuje przychodzący ruch internetowy, a następnie udostępnia usługę prywatnie użytkownikom wewnętrznym korzystającym z prywatnego punktu końcowego.

Inną zaletą korzystania z prywatnych punktów końcowych jest to, że nie trzeba otwierać portów w zaporze dla ruchu wychodzącego. Prywatne punkty końcowe blokują cały ruch wychodzący na porcie dla publicznego Internetu. Łączność jest ograniczona do zasobów w sieci.

Kompromis: Azure Private Link to płatna usługa, która ma mierniki dla przetwarzanych danych przychodzących i wychodzących. Opłaty są również naliczane za prywatne punkty końcowe.

Ochrona przed atakami typu "rozproszona odmowa usługi" (DDoS)

Atak DDoS próbuje wyczerpać zasoby aplikacji, aby aplikacja jest niedostępna dla uprawnionych użytkowników. Ataki DDoS mogą dotyczyć dowolnego punktu końcowego, który jest publicznie dostępny za pośrednictwem Internetu.

Atak DDoS jest zwykle ogromnym, szeroko rozpowszechnionym geograficznie nadużyciem zasobów systemu, które utrudniają określenie i zablokowanie źródła.

Aby uzyskać pomoc techniczna platformy Azure w celu ochrony przed tymi atakami, zobacz sekcję Azure DDoS Protection w tym artykule.

Ułatwienia platformy Azure

Poniższe usługi platformy Azure umożliwiają dodanie możliwości ochrony w sieci.

Azure Virtual Network

Virtual Network pomaga zasobom platformy Azure bezpiecznie komunikować się ze sobą, Internetem i sieciami lokalnymi.

Domyślnie wszystkie zasoby w sieci wirtualnej mogą angażować się w komunikację wychodzącą z Internetem. Jednak komunikacja przychodząca jest domyślnie ograniczona.

Virtual Network oferuje funkcje filtrowania ruchu. Dostęp można ograniczyć na poziomie sieci wirtualnej przy użyciu trasy zdefiniowanej przez użytkownika i składnika zapory. Na poziomie podsieci można filtrować ruch przy użyciu sieciowych grup zabezpieczeń.

Zabezpieczenia usługi Edge

Domyślnie ruch przychodzący i wychodzący przepływają przez publiczne adresy IP. W zależności od usługi lub topologii można ustawić te adresy lub przypisywać je na platformie Azure. Inne możliwości ruchu przychodzącego i wychodzącego obejmują przekazywanie ruchu przez moduł równoważenia obciążenia lub bramę translatora adresów sieciowych (NAT). Jednak te usługi są przeznaczone do dystrybucji ruchu i niekoniecznie na potrzeby zabezpieczeń.

Zalecane są następujące opcje technologiczne:

Azure Firewall. Można użyć Azure Firewall na brzegu sieci i w popularnych topologiach sieci, takich jak sieci piasta-szprycha i wirtualne sieci WAN. Zazwyczaj wdrażasz Azure Firewall jako zaporę ruchu wychodzącego, która działa jako ostateczna brama zabezpieczeń przed przejściem ruchu do Internetu. Azure Firewall może kierować ruch korzystający z protokołów innych niż HTTP i innych niż HTTPS, takich jak Protokół RDP (Remote Desktop Protocol), Secure Shell Protocol (SSH) i Protokół TRANSFERU plików (FTP). Zestaw funkcji Azure Firewall obejmuje:
- Translacja docelowych adresów sieciowych (DNAT) lub przekazywanie portów.
- Wykrywanie nieautoryzowanego wykrywania i zapobiegania włamaniom (IDPS) do wykrywania podpisów.
- Reguły sieciowe silnej warstwy 3, warstwy 4 i w pełni kwalifikowanej nazwy domeny (FQDN).
Uwaga

Większość organizacji ma wymuszone zasady tunelowania, które wymuszają przepływ ruchu przez urządzenie WUS.

Jeśli nie używasz topologii wirtualnej sieci WAN, musisz wdrożyć trasę zdefiniowaną przez użytkownika z adresem NextHopTypeInternet IP prywatnego urządzenia WUS. Trasy zdefiniowane przez użytkownika są stosowane na poziomie podsieci. Domyślnie ruch między podsieciami nie przepływa przez urządzenie WUS.

Można również użyć Azure Firewall jednocześnie dla ruchu przychodzącego. Może kierować ruch HTTP i HTTPS. W jednostkach SKU wyższego poziomu Azure Firewall oferuje zakończenie protokołu TLS, dzięki czemu można zaimplementować inspekcje na poziomie ładunku.

Zalecane są następujące rozwiązania:
- Włącz ustawienia diagnostyczne w Azure Firewall, aby zbierać dzienniki przepływu ruchu, dzienniki dostawcy tożsamości i dzienniki żądań DNS.
- Jak to możliwe, należy jak najodpowidniej w regułach.
- Gdzie jest to praktyczne, unikaj tagów usługi FQDN. Jednak w przypadku ich używania użyj wariantu regionalnego, który umożliwia komunikację ze wszystkimi punktami końcowymi usługi.
- Użyj grup adresów IP, aby zdefiniować źródła, które muszą współdzielić te same reguły w ciągu życia grupy adresów IP. Grupy adresów IP powinny odzwierciedlać strategię segmentacji.
- Zastąpuj regułę infrastruktury FQDN tylko wtedy, gdy obciążenie wymaga bezwzględnej kontroli ruchu wychodzącego. Zastąpienie tej reguły wiąże się z kompromisem niezawodności, ponieważ wymagania dotyczące platformy Azure zmieniają się w usługach.
Kompromis: Azure Firewall może mieć wpływ na wydajność. Kolejność reguł, ilość, inspekcja protokołu TLS i inne czynniki mogą powodować znaczne opóźnienie.

Może to również mieć wpływ na niezawodność obciążenia. Może to spowodować wyczerpanie portów translacji adresów sieciowych (SNAT). Aby rozwiązać ten problem, dodaj publiczne adresy IP zgodnie z potrzebami.

Ryzyko: w przypadku ruchu wychodzącego platforma Azure przypisuje publiczny adres IP. To przypisanie może mieć wpływ na zewnętrzną bramę zabezpieczeń.
Azure Web Application Firewall. Ta usługa obsługuje filtrowanie przychodzące i dotyczy tylko ruchu HTTP i HTTPS.

Oferuje podstawowe zabezpieczenia typowych ataków, takich jak zagrożenia, które program Open Worldwide Application Security Project (OWASP) identyfikuje w dokumencie OWASP Top 10. Usługa Azure Web Application Firewall udostępnia również inne funkcje zabezpieczeń, które koncentrują się na warstwie 7, takie jak ograniczanie szybkości, reguły iniekcji SQL i wykonywanie skryptów między lokacjami.

W przypadku usługi Azure Web Application Firewall jest wymagane zakończenie protokołu TLS, ponieważ większość kontroli jest oparta na ładunkach.

Usługę Azure Web Application Firewall można zintegrować z routerami, takimi jak Azure Application Gateway lub Azure Front Door. Implementacje Web Application Firewall platformy Azure dla tego rodzaju routerów mogą się różnić.

Azure Firewall i azure Web Application Firewall nie są wzajemnie wykluczające się wyborami. W przypadku rozwiązania zabezpieczeń brzegowego dostępne są różne opcje. Aby zapoznać się z przykładami, zobacz Zapora i Application Gateway dla sieci wirtualnych.

Grupy zabezpieczeń sieci

Sieciowa grupa zabezpieczeń to zapora warstwy 3 i 4, która jest stosowana na poziomie podsieci lub karty sieciowej. Sieciowe grupy zabezpieczeń nie są domyślnie tworzone ani stosowane.

Reguły sieciowej grupy zabezpieczeń działają jako zapora , aby zatrzymać ruch przepływujący do i wychodzący w obwodzie podsieci. Sieciowa grupa zabezpieczeń ma domyślny zestaw reguł, który jest nadmiernie permissive. Na przykład reguły domyślne nie ustawiają zapory z perspektywy ruchu wychodzącego. W przypadku ruchu przychodzącego ruch przychodzący nie jest dozwolony.

Aby utworzyć reguły, zacznij od domyślnego zestawu reguł:

W przypadku ruchu przychodzącego lub ruchu przychodzącego :
- Dozwolony jest ruch sieci wirtualnej z bezpośrednich, równorzędnych i źródeł bramy sieci VPN.
- Azure Load Balancer sondy kondycji są dozwolone.
- Cały inny ruch jest blokowany.
W przypadku ruchu wychodzącego lub wychodzącego:
- Dozwolony jest ruch sieci wirtualnej do bezpośrednich, równorzędnych i docelowych bram sieci VPN.
- Ruch do Internetu jest dozwolony.
- Cały inny ruch jest blokowany.

Następnie należy wziąć pod uwagę następujące pięć czynników:

Protokół
Źródłowy adres IP
Port źródłowy
Docelowy adres IP
Port docelowy

Brak obsługi nazwy FQDN ogranicza funkcjonalność sieciowej grupy zabezpieczeń. Musisz podać określone zakresy adresów IP dla obciążenia i trudno je zachować.

Jednak w przypadku usług platformy Azure można użyć tagów usługi do podsumowania zakresów źródłowych i docelowych adresów IP. Zaletą zabezpieczeń tagów usługi jest to, że są nieprzezroczyste dla użytkownika, a odpowiedzialność jest odciążona na platformie Azure. Możesz również przypisać grupę zabezpieczeń aplikacji jako typ docelowy, aby kierować ruch do. Ten typ nazwanej grupy zawiera zasoby, które mają podobne potrzeby dostępu przychodzącego lub wychodzącego.

Ryzyko: zakresy tagów usług są bardzo szerokie, aby pomieścić najszerszą możliwą gamę klientów. Aktualizacje do tagów usługi opóźnić zmiany w usłudze.

Na powyższym obrazie sieciowe grupy zabezpieczeń są stosowane w karcie sieciowej. Ruch internetowy i ruch między podsieciami są odrzucane. Sieciowe grupy zabezpieczeń są stosowane z tagiem VirtualNetwork . W takim przypadku podsieci sieci równorzędnych mają bezpośrednią linię wzroku. Szeroka definicja tagu VirtualNetwork może mieć znaczący wpływ na bezpieczeństwo.

Jeśli używasz tagów usługi, użyj wersji regionalnych, jeśli to możliwe, na przykład Storage.WestUS zamiast Storage. Stosując to podejście, należy ograniczyć zakres do wszystkich punktów końcowych w określonym regionie.

Niektóre tagi są przeznaczone wyłącznie dla ruchu przychodzącego lub wychodzącego . Inne są przeznaczone dla obu typów. Tagi przychodzące zwykle zezwalają na ruch ze wszystkich obciążeń hostingu, takich jak , lub z platformy Azure do obsługi środowisk uruchomieniowych usług, takich jak AzureFrontDoor.BackendLogicAppsManagement. Podobnie tagi ruchu wychodzącego zezwalają na ruch do wszystkich obciążeń hostowania lub z platformy Azure w celu obsługi środowisk uruchomieniowych usługi.

Jak najwięcej zakresów reguł. W poniższym przykładzie reguła jest ustawiona na określone wartości. Wszelkie inne typy ruchu są odrzucane.

Informacje	Przykład
Protokół	Transmission Control Protocol (TCP), UDP
Źródłowy adres IP	Zezwalaj na ruch przychodzący do podsieci ze <źródłowego zakresu> adresów IP: 4575/UDP
Port źródłowy	Zezwalaj na ruch przychodzący do podsieci z <tagu> usługi: 443/TCP
Docelowy adres IP	Zezwalaj na ruch wychodzący z podsieci do <docelowego zakresu adresów> IP: 443/TCP
Port docelowy	Zezwalaj na ruch wychodzący z podsieci do <tagu> usługi: 443/TCP

Podsumowując:

Należy dokładnie określić podczas tworzenia reguł. Zezwalaj tylko na ruch, który jest niezbędny do działania aplikacji. Odmów wszystkiego innego. Takie podejście ogranicza widoczność sieci do przepływów sieci potrzebnych do obsługi działania obciążenia. Obsługa większej liczby przepływów sieci niż to konieczne prowadzi do niepotrzebnych wektorów ataków i rozszerza obszar powierzchni.

Ograniczenie ruchu nie oznacza, że dozwolone przepływy wykraczają poza zakres ataku. Ponieważ sieciowe grupy zabezpieczeń działają w warstwach 3 i 4 w stosie Open SystemsConnect (OSI), zawierają tylko informacje o kształcie i kierunku. Jeśli na przykład obciążenie musi zezwalać na ruch DNS do Internetu, należy użyć sieciowej grupy zabezpieczeń .Internet:53:UDP W takim przypadku osoba atakująca może być w stanie eksfiltrować dane za pośrednictwem protokołu UDP na porcie 53 do innego usługi.
Dowiedz się, że sieciowe grupy zabezpieczeń mogą się nieznacznie różnić od siebie. Łatwo przeoczyć intencję różnic. Aby zapewnić szczegółowe filtrowanie, bezpieczniejsze jest utworzenie dodatkowych sieciowych grup zabezpieczeń. Skonfiguruj co najmniej jedną sieciowa grupa zabezpieczeń.
- Dodanie sieciowej grupy zabezpieczeń umożliwia odblokowanie wielu narzędzi diagnostycznych, takich jak dzienniki przepływu i analiza ruchu sieciowego.
- Użyj Azure Policy, aby ułatwić kontrolowanie ruchu w podsieciach, które nie mają sieciowych grup zabezpieczeń.
Jeśli podsieć obsługuje sieciowe grupy zabezpieczeń, dodaj grupę, nawet jeśli ma to minimalny wpływ.

Zapory usług platformy Azure

Większość usług platformy Azure oferuje zaporę na poziomie usługi. Ta funkcja sprawdza ruch przychodzący do usługi z określonych zakresów routingu między domenami (CIDR, classless inter-domain routing). Te zapory oferują korzyści:

Zapewniają one podstawowy poziom zabezpieczeń.
Istnieje tolerowany wpływ na wydajność.
Większość usług oferuje te zapory bez dodatkowych kosztów.
Zapory emitują dzienniki za pośrednictwem diagnostyki platformy Azure, co może być przydatne do analizowania wzorców dostępu.

Istnieją jednak również obawy dotyczące zabezpieczeń związane z tymi zaporami i istnieją ograniczenia związane z dostarczaniem parametrów. Jeśli na przykład używasz agentów kompilacji hostowanych przez firmę Microsoft, musisz otworzyć zakres adresów IP dla wszystkich agentów kompilacji hostowanych przez firmę Microsoft. Zakres jest następnie otwarty dla agenta kompilacji, innych dzierżawców i przeciwników, którzy mogą nadużywać twojej usługi.

Jeśli masz wzorce dostępu dla usługi, które można skonfigurować jako zestawy reguł zapory usługi, należy włączyć usługę. Aby ją włączyć, możesz użyć Azure Policy. Upewnij się, że opcja zaufanych usług platformy Azure nie jest domyślnie włączona. Spowoduje to wprowadzenie wszystkich usług zależnych, które znajdują się w zakresie reguł.

Aby uzyskać więcej informacji, zobacz dokumentację produktu poszczególnych usług platformy Azure.

Prywatne punkty końcowe

Private Link umożliwia nadanie wystąpieniu paaS prywatnego adresu IP. Usługa jest wówczas niedostępna przez Internet. Prywatne punkty końcowe nie są obsługiwane dla wszystkich jednostek SKU.

Podczas korzystania z prywatnych punktów końcowych należy pamiętać o następujących zaleceniach:

Skonfiguruj usługi powiązane z sieciami wirtualnymi, aby skontaktować się z usługami PaaS za pośrednictwem prywatnych punktów końcowych, nawet jeśli te usługi PaaS również muszą oferować dostęp publiczny.
Podwyższ poziom użycia sieciowych grup zabezpieczeń dla prywatnych punktów końcowych, aby ograniczyć dostęp do prywatnych adresów IP punktu końcowego.
Zawsze używaj zapór usługi podczas korzystania z prywatnych punktów końcowych.
Jeśli jest to możliwe, jeśli masz usługę dostępną tylko za pośrednictwem prywatnych punktów końcowych, usuń konfigurację DNS dla publicznego punktu końcowego.
Podczas implementowania prywatnych punktów końcowych należy wziąć pod uwagę obawy dotyczące środowiska uruchomieniowego. Należy jednak również rozważyć problemy związane z metodykami DevOps i monitorowaniem.
Użyj Azure Policy, aby wymusić konfigurację zasobów.

Kompromis: Jednostki SKU usługi z prywatnymi punktami końcowymi są kosztowne. Prywatne punkty końcowe mogą komplikować operacje z powodu zaciemnienia sieci. Do architektury należy dodać własnych agentów, pól przesiadkowych, sieci VPN i innych składników.

Zarządzanie systemem DNS może być złożone w typowych topologiach sieci. Może być konieczne wprowadzenie usług przesyłania dalej DNS i innych składników.

Wstrzykiwanie sieci wirtualnej

Aby wdrożyć niektóre usługi platformy Azure w sieci, możesz użyć procesu iniekcji sieci wirtualnej . Przykłady takich usług to Azure App Service, Functions, Azure API Management i Azure Spring Apps. Ten proces izoluje aplikację od Internetu, systemy w sieciach prywatnych i innych usługach platformy Azure. Ruch przychodzący i wychodzący z aplikacji jest dozwolony lub blokowany na podstawie reguł sieciowych.

Azure Bastion

Za pomocą usługi Azure Bastion możesz nawiązać połączenie z maszyną wirtualną przy użyciu przeglądarki i Azure Portal. Usługa Azure Bastion zwiększa bezpieczeństwo połączeń RDP i SSH. Typowy przypadek użycia obejmuje połączenie z urządzeniem przesiadkowym w tej samej sieci wirtualnej lub równorzędnej sieci wirtualnej. Korzystanie z usługi Azure Bastion eliminuje potrzebę posiadania publicznego adresu IP maszyny wirtualnej.

Azure DDoS Protection

Każda właściwość na platformie Azure jest chroniona przez ochronę infrastruktury usługi Azure DDoS bez dodatkowych kosztów i bez dodatkowej konfiguracji. Poziom ochrony jest podstawowy, ale ochrona ma wysokie progi. Nie zapewnia również danych telemetrycznych ani alertów i nie jest ona niezależna od obciążenia.

Jednostki SKU wyższej warstwy ochrony przed atakami DDoS są dostępne, ale nie są bezpłatne. Skala i pojemność globalnie wdrożonej sieci platformy Azure zapewnia ochronę przed typowymi atakami w warstwie sieciowej. Technologie takie jak zawsze włączone monitorowanie ruchu i ograniczanie ryzyka w czasie rzeczywistym zapewniają tę możliwość.

Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure DDoS Protection.

Przykład

Poniżej przedstawiono kilka przykładów, które pokazują użycie kontrolek sieci zalecanych w tym artykule.

Środowisko IT

W tym przykładzie opiera się na środowisku technologii informacyjnej (IT) określonym w punkcie odniesienia zabezpieczeń (SE:01). Takie podejście zapewnia szerokie zrozumienie mechanizmów kontroli sieci stosowanych w różnych obwodach w celu ograniczenia ruchu.

Osoby atakujące w sieci. W ataku sieciowym można rozważyć kilka osób, w tym administratorów, pracowników, klientów klienta i anonimowych osób atakujących.
Dostęp do sieci VPN. Nieprawidłowy aktor może uzyskać dostęp do środowiska lokalnego za pośrednictwem sieci VPN lub środowiska platformy Azure połączonego ze środowiskiem lokalnym za pośrednictwem sieci VPN. Skonfiguruj protokół IPSec, aby umożliwić bezpieczną komunikację.
Publiczny dostęp do aplikacji. Zapora aplikacji internetowej (WAF) przed aplikacją chroni ją w warstwie 7 warstwy OSI sieci.
Dostęp operatora. Należy zabezpieczyć dostęp zdalny za pośrednictwem warstwy OSI sieci 4. Rozważ użycie Azure Firewall z funkcjami dostawcy tożsamości/identyfikatorów.
Ochrona przed atakami DDoS. Ochrona przed atakami DDoS dla całej sieci wirtualnej.
Topologia sieci. Topologia sieci, taka jak piasta-szprycha, jest bezpieczniejsza i optymalizuje koszty. Sieć piasty zapewnia scentralizowaną ochronę zapory dla wszystkich szprych równorzędnych.
Prywatne punkty końcowe: rozważ dodanie publicznie uwidocznionych usług do sieci prywatnej przy użyciu prywatnych punktów końcowych. Te karty sieciowe tworzą kartę sieciową w prywatnej sieci wirtualnej i wiążą się z usługą platformy Azure.
Komunikacja TLS. Ochrona danych przesyłanych przez komunikację za pośrednictwem protokołu TLS.
Sieciowa grupa zabezpieczeń: ochrona segmentów w sieci wirtualnej za pomocą sieciowej grupy zabezpieczeń, bezpłatnego zasobu, który filtruje komunikację przychodzącą i wychodzącą TCP/UDP, biorąc pod uwagę zakresy adresów IP i portów. Częścią sieciowej grupy zabezpieczeń jest grupa zabezpieczeń aplikacji (ASG), która umożliwia tworzenie tagów dla reguł ruchu w celu łatwiejszego zarządzania.
Log Analytics. Zasoby platformy Azure emitują dane telemetryczne pozyskane w usłudze Log Analytics, a następnie używane z rozwiązaniem SIEM, takim jak Microsoft Sentinel do analizy.
Integracja z usługą Microsoft Sentinel. Usługa Log Analytics jest zintegrowana z usługą Microsoft Sentinel i innymi rozwiązaniami, takimi jak Microsoft Defender for Cloud.
Microsoft Defender dla chmury. Microsoft Defender for Cloud oferuje wiele rozwiązań ochrony obciążeń, w tym rekomendacje dotyczące sieci dla danego środowiska.
Analiza ruchu: monitorowanie kontrolek sieci za pomocą analizy ruchu. Jest to konfigurowane za pośrednictwem Network Watcher, części usługi Azure Monitor i agreguje trafienia przychodzące i wychodzące w podsieciach zebranych przez sieciową grupę zabezpieczeń.

Architektura konteneryzowanego obciążenia

Ta przykładowa architektura łączy kontrolki sieci opisane w tym artykule. W przykładzie nie pokazano pełnej architektury. Zamiast tego koncentruje się na kontrolkach ruchu przychodzącego w chmurze prywatnej.

Application Gateway to moduł równoważenia obciążenia ruchu internetowego, którego można użyć do zarządzania ruchem w aplikacjach internetowych. Wdrażasz Application Gateway w dedykowanej podsieci z włączoną kontrolą sieciowej grupy zabezpieczeń i mechanizmami kontroli zapory aplikacji internetowej.

Komunikacja ze wszystkimi usługami PaaS odbywa się za pośrednictwem prywatnych punktów końcowych. Wszystkie punkty końcowe są umieszczane w dedykowanej podsieci. Ochrona przed atakami DDoS pomaga chronić wszystkie publiczne adresy IP skonfigurowane pod kątem ochrony zapory na poziomie podstawowym lub wyższym.

Ruch związany z zarządzaniem jest ograniczony za pośrednictwem usługi Azure Bastion, co pomaga zapewnić bezpieczną i bezproblemową łączność RDP i SSH z maszynami wirtualnymi bezpośrednio z Azure Portal za pośrednictwem protokołu TLS. Agenci kompilacji są umieszczani w sieci wirtualnej, aby mieć widok sieciowy na zasoby obciążenia, takie jak zasoby obliczeniowe, rejestry kontenerów i bazy danych. Takie podejście pomaga zapewnić bezpieczne i izolowane środowisko dla agentów kompilacji, co zwiększa ochronę kodu i artefaktów.

Sieciowe grupy zabezpieczeń na poziomie podsieci zasobów obliczeniowych ograniczają ruch wychodzący. Wymuszone tunelowanie służy do kierowania całego ruchu przez Azure Firewall. Takie podejście pomaga zapewnić bezpieczne i izolowane środowisko dla zasobów obliczeniowych, co zwiększa ochronę danych i aplikacji.

Lista kontrolna zabezpieczeń

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna zabezpieczeń

Zalecenia dotyczące sieci i łączności