Stosowanie zasad Zero Trust do sieci wirtualnej będącej szprychą na platformie Azure
Podsumowanie: Aby zastosować zasady Zero Trust do sieci wirtualnej będącej szprychą na platformie Azure, należy skorzystać z kontroli dostępu opartej na rolach (RBAC), odizolować podsieci i maszyny wirtualne (grupy zasobów, sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji), zabezpieczyć ruch i zasoby w sieci wirtualnej i aplikacjach maszyn wirtualnych oraz włączyć zaawansowane wykrywanie zagrożeń, alerty i ochronę.
Ten artykuł pomaga zastosować zasady zerowego zaufania do sieci wirtualnej będącej szprychą dla obciążeń IaaS na platformie Azure w następujący sposób:
| Zasada zerowego zaufania | Definicja | Met by |
|---|---|---|
| Jawną weryfikację | Zawsze uwierzytelniaj się i autoryzuj na podstawie wszystkich dostępnych punktów danych. | Użyj grup zabezpieczeń aplikacji, aby sprawdzić, czy poszczególne karty sieciowe mają uprawnienia do komunikacji za pośrednictwem określonych kanałów. |
| Używanie dostępu z jak najmniejszą liczbą uprawnień | Ogranicz dostęp użytkowników za pomocą zasad just in time i Just-Enough-Access (JIT/JEA), zasad adaptacyjnych opartych na ryzyku i ochrony danych. | Nie włączaj domyślnie dostępu 3389/RDP w żadnym kanale. Użyj prawidłowych uprawnień roli dla kontekstu szprychy. |
| Zakładanie naruszeń zabezpieczeń | Zminimalizuj promień wybuchu i dostęp segmentu. Zweryfikuj kompleksowe szyfrowanie i korzystaj z analizy, aby uzyskać widoczność, zwiększyć wykrywanie zagrożeń i poprawić ochronę. | Ogranicz niepotrzebną komunikację między zasobami. Upewnij się, że możesz zalogować się do sieciowych grup zabezpieczeń i że masz odpowiedni wgląd w nietypowy ruch. Śledzenie zmian w sieciowych grupach zabezpieczeń. |
Ten artykuł jest częścią serii artykułów, które pokazują, jak zastosować zasady zerowego zaufania w środowisku platformy Azure, które obejmuje sieć wirtualną będącej szprychą hostująca obciążenie oparte na maszynie wirtualnej. Aby uzyskać więcej informacji, zobacz Artykuł Apply Zero Trust principles to Azure IaaS overview (Stosowanie zasad zero trustu do usługi Azure IaaS — omówienie).
Architektura odwołań
Na poniższym diagramie przedstawiono wspólną architekturę referencyjną dla obciążeń opartych na usłudze IaaS.
Na diagramie:
- Sieć wirtualna będące szprychą zawiera składniki obsługujące aplikację IaaS składającą się z maszyn wirtualnych.
- Aplikacja IaaS to aplikacja trójwarstwowa składająca się z dwóch maszyn wirtualnych dla każdej warstwy: frontonu, aplikacji i danych.
- Każda warstwa jest zawarta w dedykowanej podsieci z dedykowaną sieciową grupą zabezpieczeń.
- Każda rola maszyny wirtualnej jest przypisywana do grupy zabezpieczeń aplikacji odpowiadającej jej roli.
- Dostęp do aplikacji jest udostępniany za pośrednictwem usługi Application Gateway zawartej we własnej podsieci.
Aplikacja przedstawiona w architekturze referencyjnej jest zgodna ze stylem architektury N-warstwowej
Na poniższym diagramie przedstawiono składniki grupy zasobów dla sieci wirtualnej będącej szprychą w subskrypcji platformy Azure niezależnie od subskrypcji dla sieci wirtualnej piasty.
Na diagramie wszystkie składniki sieci wirtualnej będącej szprychą znajdują się w dedykowanej grupie zasobów:
- Jedna sieć wirtualna
- Jedna brama aplikacja systemu Azure (App GW), w tym zapora aplikacji internetowej (WAF)
- Trzy sieciowe grupy zabezpieczeń, po jednym dla każdej warstwy aplikacji
- Trzy grupy zabezpieczeń aplikacji, po jednym dla każdej warstwy aplikacji
Co znajduje się w tym artykule
Zasady zero trust są stosowane w całej architekturze z poziomu dzierżawy i katalogu w dół do przypisania maszyn wirtualnych do grup zabezpieczeń aplikacji. W poniższej tabeli opisano zalecenia dotyczące zabezpieczania tej architektury.
| Krok | Zadanie | Stosowane zasady zerowego zaufania |
|---|---|---|
| 1 | Użyj kontroli dostępu opartej na rolach (RBAC) firmy Microsoft lub skonfiguruj role niestandardowe dla zasobów sieciowych. | Używanie dostępu z jak najmniejszą liczbą uprawnień |
| 2 | Izolowanie infrastruktury do własnej grupy zasobów. | Zakładanie naruszeń zabezpieczeń |
| 3 | Utwórz sieciową grupę zabezpieczeń dla każdej podsieci. | Użyj najmniej uprzywilejowanego dostępu Zakładanie naruszeń zabezpieczeń |
| 100 | Utwórz grupę zabezpieczeń aplikacji dla każdej roli maszyny wirtualnej. | Weryfikowanie jawnie Użyj najmniej uprzywilejowanego dostępu Zakładanie naruszeń zabezpieczeń |
| 5 | Zabezpieczanie ruchu i zasobów w sieci wirtualnej: |
Weryfikowanie jawnie Użyj najmniej uprzywilejowanego dostępu Zakładanie naruszeń zabezpieczeń |
| 6 | Bezpieczny dostęp do sieci wirtualnej i aplikacji. | Użyj najmniej uprzywilejowanego dostępu Zakładanie naruszeń zabezpieczeń |
| 7 | Włącz zaawansowane wykrywanie zagrożeń, alerty i ochronę. | Zakładanie naruszeń zabezpieczeń |
Krok 1. Używanie kontroli dostępu opartej na rolach firmy Microsoft lub konfigurowanie ról niestandardowych dla zasobów sieciowych
Wbudowane role kontroli dostępu opartej na rolach firmy Microsoft można używać dla współautorów sieci. Jednak innym podejściem jest użycie ról niestandardowych. Menedżerowie sieci szprych nie potrzebują pełnego dostępu do zasobów sieciowych przyznanych przez rolę Współautor sieci RBAC firmy Microsoft, ale potrzebują większej liczby uprawnień niż inne typowe role. Możesz użyć roli niestandardowej, aby ograniczyć zakres dostępu do tego, co jest potrzebne.
Jednym z prostych sposobów wdrożenia tej funkcji jest wdrożenie ról niestandardowych znajdujących się w architekturze referencyjnej strefy docelowej platformy Azure.
Określoną rolą jest rola niestandardowa Zarządzanie siecią ma następujące uprawnienia:
- Odczytywanie wszystkich elementów w zakresie
- Wszelkie akcje u dostawcy sieci
- Wszelkie akcje u dostawcy pomocy technicznej
- Wszelkie akcje u dostawcy zasobów
Tę rolę można utworzyć przy użyciu skryptów dla ról niestandardowych lub za pośrednictwem identyfikatora Entra firmy Microsoft z procesem opisanym w temacie Role niestandardowe platformy Azure — Kontrola dostępu oparta na rolach platformy Azure.
Krok 2. Izolowanie infrastruktury do własnej grupy zasobów
Przez izolowanie zasobów sieciowych z zasobów obliczeniowych, danych lub magazynu zmniejsza prawdopodobieństwo wystąpienia krwawień uprawnień. Ponadto dzięki upewnieniu się, że wszystkie powiązane zasoby znajdują się w jednej grupie zasobów, można wykonać jedno przypisanie zabezpieczeń i lepiej zarządzać rejestrowaniem i monitorowaniem tych zasobów.
Zamiast mieć zasoby sieciowe szprych dostępne w wielu kontekstach w udostępnionej grupie zasobów, utwórz dla niej dedykowaną grupę zasobów. Architektura referencyjna obsługiwana w tym artykule ilustruje tę koncepcję.
Na rysunku zasoby i składniki w architekturze referencyjnej są podzielone na dedykowane grupy zasobów dla maszyn wirtualnych, kont magazynu, zasobów sieci wirtualnej piasty i zasobów sieci wirtualnej będącej szprychą.
Za pomocą dedykowanej grupy zasobów można przypisać rolę niestandardową przy użyciu następującego procesu: Samouczek: udzielanie użytkownikowi dostępu do zasobów platformy Azure przy użyciu witryny Azure Portal — RBAC platformy Azure.
Dodatkowe zalecenia:
- Odwołanie do grupy zabezpieczeń roli zamiast nazwanych osób.
- Zarządzanie dostępem do grupy zabezpieczeń za pomocą wzorców zarządzania tożsamościami przedsiębiorstwa.
Jeśli nie używasz zasad wymuszających przekazywanie dzienników w grupach zasobów, skonfiguruj je w dzienniku aktywności dla grupy zasobów: Przejdź do obszaru Dziennik > aktywności Eksportuj dziennik aktywności, a następnie wybierz pozycję + Dodaj ustawienie diagnostyczne.
Na ekranie Ustawienia diagnostyczne wybierz wszystkie kategorie dzienników (szczególnie zabezpieczenia) i wyślij je do odpowiednich źródeł rejestrowania, takich jak obszar roboczy usługi Log Analytics w celu obserwowania, lub konto magazynu na potrzeby długoterminowego przechowywania.
Demokratyzacja subskrypcji
Chociaż nie jest to bezpośrednio związane z siecią, należy zaplanować kontrolę dostępu opartą na rolach subskrypcji w podobny sposób. Oprócz izolowania zasobów logicznie przez grupę zasobów należy również odizolować subskrypcję na podstawie obszarów biznesowych i właścicieli portfela. Subskrypcja jako jednostka zarządzania powinna być wąsko ograniczona.
Aby uzyskać więcej informacji na temat demokratyzacji subskrypcji, zobacz Zasady projektowania strefy docelowej platformy Azure — Cloud Adoption Framework.
Możesz skonfigurować diagnostykę z kategorii Zabezpieczenia ustawienia diagnostycznego w usłudze Azure Monitor, jak pokazano tutaj.
Zobacz Ustawienia diagnostyczne, aby dowiedzieć się, jak przeglądać te dzienniki i otrzymywać alerty.
Krok 3. Tworzenie sieciowej grupy zabezpieczeń dla każdej podsieci
Sieciowe grupy zabezpieczeń platformy Azure służą do filtrowania ruchu sieciowego między zasobami platformy Azure w sieci wirtualnej platformy Azure. Zaleca się zastosowanie sieciowej grupy zabezpieczeń do każdej podsieci, która jest domyślnie wymuszana za pomocą zasad platformy Azure podczas wdrażania stref docelowych platformy Azure. Sieciowa grupa zabezpieczeń zawiera reguły zabezpieczeń, które zezwalają na lub blokują przychodzący ruch sieciowy lub wychodzący ruch sieciowy dla kilku typów zasobów platformy Azure. Dla każdej reguły można określić źródło i obiekt docelowy, port i protokół.
W przypadku wielowarstwowej aplikacji opartej na maszynie wirtualnej zaleca się utworzenie dedykowanej sieciowej grupy zabezpieczeń (sieciowej grupy zabezpieczeń na poniższej ilustracji) dla każdej podsieci, która hostuje rolę maszyny wirtualnej.
Na diagramie:
- Każda warstwa aplikacji jest hostowana w dedykowanej podsieci, takiej jak warstwa frontonu, warstwa aplikacji i warstwa danych.
- Sieciowa grupa zabezpieczeń jest skonfigurowana dla każdej z tych podsieci.
Skonfigurowanie sieciowych grup zabezpieczeń w inny sposób niż pokazano na rysunku może spowodować niepoprawną konfigurację niektórych lub wszystkich sieciowych grup zabezpieczeń i może powodować problemy podczas rozwiązywania problemów. Może to również utrudnić monitorowanie i rejestrowanie.
Utwórz sieciową grupę zabezpieczeń przy użyciu tego procesu: tworzenie, zmienianie lub usuwanie sieciowej grupy zabezpieczeń platformy Azure
Zobacz sieciowe grupy zabezpieczeń, aby dowiedzieć się, jak można ich używać do zabezpieczania środowiska.
Krok 4. Tworzenie grupy zabezpieczeń aplikacji dla każdej roli maszyny wirtualnej
Grupy zabezpieczeń aplikacji umożliwiają skonfigurowanie zabezpieczeń sieci jako naturalnego rozszerzenia struktury aplikacji, co pozwala na grupowanie maszyn wirtualnych i definiowanie zasad zabezpieczeń sieci na podstawie tych grup. Możesz ponownie używać zasad zabezpieczeń na dużą skalę bez ręcznej obsługi jawnych adresów IP. Platforma obsługuje złożoność jawnych adresów IP i wiele zestawów reguł, co pozwala skupić się na logice biznesowej.
W ramach obciążenia zidentyfikuj określone role maszyny wirtualnej. Następnie utwórz grupę zabezpieczeń aplikacji dla każdej roli. W architekturze referencyjnej są reprezentowane trzy grupy zabezpieczeń aplikacji.
Na diagramie:
- Trzy grupy zabezpieczeń aplikacji są tworzone w celu obsługi tej aplikacji, po jednej dla każdej warstwy: frontonu, aplikacji i danych.
- Każda maszyna wirtualna jest przypisywana do odpowiedniej grupy zabezpieczeń aplikacji dla jej roli (czerwony tekst na diagramie).
Aby uzyskać więcej informacji na temat grup zabezpieczeń aplikacji i sposobu przypisywania ich do maszyn wirtualnych, zobacz Omówienie grup zabezpieczeń aplikacji platformy Azure.
Uwaga
Jeśli używasz modułów równoważenia obciążenia, użycie adresu IP modułu równoważenia obciążenia w sieciowych grup zabezpieczeń jest wymagane, ponieważ grupy zabezpieczeń aplikacji nie mogą określać zakresu modułu równoważenia obciążenia.
Krok 5. Zabezpieczanie ruchu i zasobów w sieci wirtualnej
W tej sekcji omówiono następujące zalecenia:
- Wdrażanie reguł odmowy punktu odniesienia dla sieciowych grup zabezpieczeń
- Wdrażanie reguł specyficznych dla aplikacji dla grup zabezpieczeń aplikacji
- Planowanie ruchu związanego z zarządzaniem w sieci wirtualnej
- Wdrażanie rejestrowania przepływu sieciowej grupy zabezpieczeń
Wdrażanie reguł odmowy punktu odniesienia dla sieciowych grup zabezpieczeń
Kluczowym elementem zerowego zaufania jest użycie najmniejszego wymaganego poziomu dostępu. Domyślnie sieciowe grupy zabezpieczeń mają dozwolone reguły. Dodając punkt odniesienia reguł odmowy, można wymusić najniższy poziom dostępu.
Po aprowizacji utwórz regułę odmowy we wszystkich regułach ruchu przychodzącego i wychodzącego z priorytetem 4096. Jest to ostatni dostępny priorytet niestandardowy, co oznacza, że nadal masz pozostały zakres konfigurowania akcji Zezwalaj.
W sieciowej grupie zabezpieczeń przejdź do pozycji Reguły zabezpieczeń dla ruchu wychodzącego i wybierz pozycję Dodaj. Wypełnij następujące informacje:
- Źródło: dowolne
- Zakresy portów źródłowych: *
- Miejsce docelowe: Dowolne
- Usługa: Niestandardowa
- Zakresy portów docelowych: *
- Protokół: dowolny
- Akcja: Odmów
- Priorytet: 4096
- Nazwa: DenyAllOutbound
- Opis: odrzuca cały ruch wychodzący, chyba że jest to dozwolone.
Oto przykład.
Powtórz ten proces przy użyciu reguł ruchu przychodzącego, dostosowując odpowiednio nazwę i opis. Zauważysz, że na karcie Reguły zabezpieczeń dla ruchu przychodzącego znajduje się znak ostrzegawczy reguły, jak pokazano tutaj.
Jeśli klikniesz regułę i przewiniesz ją do dołu, zobaczysz więcej szczegółów, jak pokazano tutaj.
Ten komunikat zawiera następujące dwa ostrzeżenia:
- Usługi Azure Load Balancers nie będą domyślnie mogły uzyskiwać dostępu do zasobów przy użyciu tej sieciowej grupy zabezpieczeń.
- Inne zasoby w tej sieci wirtualnej domyślnie nie będą mogły uzyskiwać dostępu do zasobów przy użyciu tej sieciowej grupy zabezpieczeń.
W naszym celu w zerowym zaufaniu tak powinno być. Oznacza to, że tylko dlatego, że coś znajduje się w tej sieci wirtualnej, nie oznacza, że ma natychmiastowy dostęp do zasobów. Dla każdego wzorca ruchu należy jawnie utworzyć regułę zezwalającą na tę regułę i należy to zrobić z najmniejszą ilością uprawnień. W związku z tym, jeśli masz określone połączenia wychodzące do zarządzania, takie jak kontrolery domeny usług domena usługi Active Directory (AD DS), prywatne maszyny wirtualne DNS lub do określonych zewnętrznych witryn internetowych, muszą być kontrolowane tutaj.
Alternatywne reguły odmowy
Jeśli używasz usługi Azure Firewall do zarządzania połączeniami wychodzącymi, zamiast wykonywać odmowę ruchu wychodzącego, możesz pozostawić wszystkie otwarte wychodzące. W ramach implementacji usługi Azure Firewall skonfigurujesz tabelę tras, która wysyła trasę domyślną (0.0.0.0.0/0) do zapory, która obsługuje ruch poza siecią wirtualną.
Następnie można utworzyć odmowę całego ruchu wychodzącego sieci wirtualnej lub zamiast tego zezwolić na wszystkie wychodzące (ale zabezpieczać elementy przy użyciu reguł ruchu przychodzącego).
Przeczytaj więcej na temat usługi Azure Firewall i tabel tras, aby dowiedzieć się, jak można ich używać w celu dalszego zwiększania bezpieczeństwa środowiska.
Reguły zarządzania maszynami wirtualnymi
Aby skonfigurować maszyny wirtualne z włączoną funkcją Microsoft Entra Login, Anti-Malware i automatycznymi aktualizacjami, należy zezwolić na następujące połączenia wychodzące. Wiele z nich jest przez nazwę FQDN, co oznacza, że usługa Azure Firewall jest wymagana dla reguł nazwy FQDN lub utworzysz bardziej złożony plan. Zalecana jest usługa Azure Firewall.
Ostrzeżenie
Zamiast tego możemy chcieć przenieść je do sieci koncentratora.
Połączenia wychodzące to:
- Na porcie 443:
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Na porcie 80:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- Na porcie 123:
- time.windows.com
- Na porcie 1688:
- Azkms.core.windows.net
Wdrażanie reguł specyficznych dla aplikacji dla grup zabezpieczeń aplikacji
Zdefiniuj wzorce ruchu z najmniejszą ilością uprawnień i tylko po jawnie dozwolonych ścieżkach. Oto przykładowy diagram użycia grup zabezpieczeń aplikacji do definiowania wzorców ruchu sieciowego w sieciowych grup zabezpieczeń dla sieci wirtualnej będącej szprychą, która jest używana wraz z siecią wirtualną piasty. Jest to zalecana konfiguracja.
Innym przykładem jest konfiguracja autonomicznej sieci wirtualnej będącej szprychą, w której zapora aplikacji internetowej znajduje się w podsieci usługi Application Gateway sieci wirtualnej będącej szprychą.
Potrzebne są następujące reguły sieciowej grupy zabezpieczeń:
- Zezwalanie na ruch internetowy do podsieci bramy aplikacji (HTTPS 443).
- Zezwalanie na ruch z podsieci bramy aplikacji do maszyn wirtualnych warstwy frontonu (HTTPS 433).
- Zezwalanie na ruch z maszyn wirtualnych warstwy frontonu do modułu równoważenia obciążenia warstwy aplikacji (HTTPS 443).
- Zezwalanie na ruch z modułu równoważenia obciążenia warstwy aplikacji do maszyn wirtualnych warstwy aplikacji (HTTPS 443).
- Zezwalanie na ruch z maszyn wirtualnych warstwy aplikacji do modułu równoważenia obciążenia warstwy danych (SQL 1433).
- Zezwalanie na ruch z modułu równoważenia obciążenia warstwy danych do maszyn wirtualnych warstwy danych (SQL 1433).
- Zezwalanie na ruch między maszynami wirtualnymi warstwy danych (SQL 1433)
Najpierw skonfiguruj wzorzec SQL, a następnie powtórz proces z pozostałymi warstwami. W poniższych sekcjach przedstawiono konfiguracje reguł, które ograniczają ruch sieciowy dla pojedynczej warstwy aplikacji.
Reguła 5 — zezwalanie na ruch z maszyn wirtualnych warstwy aplikacji do modułu równoważenia obciążenia warstwy danych (SQL 1433)
W sieciowej grupie zabezpieczeń podsieci warstwy aplikacji przejdź do pozycji Reguły zabezpieczeń dla ruchu przychodzącego i wybierz pozycję Dodaj. Wypełnij listę następującymi elementami:
- Źródło: Grupa zabezpieczeń aplikacji
- Źródłowe grupy zabezpieczeń aplikacji: wybierz grupę zabezpieczeń aplikacji warstwy biznesowej
- Zakresy portów źródłowych: 1433 (Czasami ruch źródłowy może pochodzić z różnych portów i jeśli ten wzorzec występuje, można dodać zakresy portów źródłowych do * w celu zezwolenia na dowolny port źródłowy. Port docelowy jest bardziej znaczący, a niektóre zalecenia są zawsze używane * dla portu źródłowego)
- Miejsce docelowe: adresy IP
- Docelowe adresy IP/zakresy CIDR: jawny adres IP modułu równoważenia obciążenia
- W tym miejscu należy użyć jawnego adresu IP, ponieważ nie można skojarzyć modułu równoważenia obciążenia z grupą zabezpieczeń aplikacji.
- Możesz zaplanować schemat adresu IP lub wdrożyć moduł równoważenia obciążenia i odwołać się do przypisanego adresu IP.
- Usługa: MS SQL
- Zakresy portów docelowych: jest on automatycznie wypełniany dla portu 1433
- Protokół: jest on automatycznie wybierany dla protokołu TCP
- Akcja: Zezwalaj
- Priorytet: wartość z zakresu od 100 do 4096. Możesz zacząć od 105.
- Nazwa: Allow-App-Tier-to-Data-LB-Inbound
- Opis: Umożliwia dostęp przychodzący z modułu równoważenia obciążenia warstwy danych do maszyn wirtualnych warstwy aplikacji.
Po zakończeniu zauważysz, że istnieje niebieska ikona alertów informacyjnych dotyczących reguły. Kliknięcie reguły powoduje następujący komunikat:
- "Reguły korzystające z grup zabezpieczeń aplikacji mogą być stosowane tylko wtedy, gdy grupy zabezpieczeń aplikacji są skojarzone z interfejsami sieciowymi w tej samej sieci wirtualnej".
Oto przykład.
Reguła ma zastosowanie tylko wtedy, gdy ta grupa zabezpieczeń aplikacji jest używana w tej sieci.
Na koniec w tej samej sieciowej grupie zabezpieczeń przejdź do pozycji Reguły zabezpieczeń dla ruchu wychodzącego i wybierz pozycję Dodaj. Wypełnij listę podobną do przykładu, zmieniając wartość Ruchu przychodzącego na Wychodzący.
Reguła 6 — zezwalanie na ruch z modułu równoważenia obciążenia warstwy danych do maszyn wirtualnych warstwy danych (SQL 1433)
W sieciowej grupie zabezpieczeń podsieci warstwy danych przejdź do pozycji Reguły zabezpieczeń dla ruchu przychodzącego i wybierz pozycję Dodaj. Wypełnij listę następującymi elementami:
- Źródło: adres IP
- Źródłowy adres IP: adres IP modułu równoważenia obciążenia
- Zakresy portów źródłowych: 1433
- Miejsce docelowe: Grupa zabezpieczeń aplikacji
- Docelowe grupy zabezpieczeń aplikacji: wybierz grupę zabezpieczeń aplikacji warstwy danych
- Usługa: MS SQL
- Zakresy portów docelowych: jest on automatycznie wypełniany dla portu 1433.
- Protokół: Jest to automatycznie wybierane dla protokołu TCP.
- Akcja: Zezwalaj
- Priorytet: wartość z zakresu od 100 do 4096. Możesz zacząć od 105.
- Nazwa: Allow-SQL-LB-to-SQL-VMs-Inbound
- Opis: Umożliwia dostęp przychodzący do maszyn wirtualnych warstwy danych SQL z modułu równoważenia obciążenia warstwy danych.
W tej samej sieciowej grupie zabezpieczeń przejdź do pozycji Reguły zabezpieczeń ruchu wychodzącego i wybierz pozycję Dodaj. Wypełnij listę tak jak w przykładzie, zmieniając wartość Ruchu przychodzącego na Wychodzący.
Reguła 7 — zezwalanie na ruch między maszynami wirtualnymi warstwy danych (SQL 1433)
W sieciowej grupie zabezpieczeń podsieci warstwy danych przejdź do pozycji Reguły zabezpieczeń dla ruchu przychodzącego i wybierz pozycję Dodaj. Wypełnij listę następującymi elementami:
- Źródło: Grupa zabezpieczeń aplikacji
- Docelowe grupy zabezpieczeń aplikacji: wybierz grupę zabezpieczeń aplikacji warstwy danych
- Zakresy portów źródłowych: 1433
- Miejsce docelowe: Grupy zabezpieczeń aplikacji
- Docelowe grupy zabezpieczeń aplikacji: wybierz grupę zabezpieczeń aplikacji warstwy danych
- Usługa: MS SQL
- Zakresy portów docelowych: jest on automatycznie wypełniany dla portu 1433.
- Protokół: Jest to automatycznie wybierane dla protokołu TCP.
- Akcja: Zezwalaj
- Priorytet: wartość z zakresu od 100 do 4096. Możesz zacząć od 105.
- Nazwa: Allow-SQL-VM-to-SQL-VM-Inbound
- Opis: Umożliwia dostęp przychodzący między maszynami wirtualnymi warstwy danych opartymi na języku SQL.
W tej samej sieciowej grupie zabezpieczeń przejdź do pozycji Reguły zabezpieczeń ruchu wychodzącego i wybierz pozycję Dodaj. Wypełnij listę jako poprzednią listę, zmieniając wartość Ruchu przychodzącego na Wychodzący.
W przypadku tych trzech reguł zdefiniowano wzorzec łączności Zero Trust dla pojedynczej warstwy aplikacji. Ten proces można powtórzyć zgodnie z wymaganiami dla dodatkowych przepływów.
Planowanie ruchu związanego z zarządzaniem w sieci wirtualnej
Oprócz ruchu specyficznego dla aplikacji należy zaplanować ruch związany z zarządzaniem. Jednak ruch zarządzania zazwyczaj pochodzi poza siecią wirtualną szprychy. Wymagane są dodatkowe reguły. Najpierw musisz zrozumieć określone porty i źródła, z których będzie pochodzić ruch zarządzania. Ogólnie rzecz biorąc, cały ruch zarządzania powinien przepływać z zapory lub innego urządzenia WUS znajdującego się w sieci piasty dla szprychy.
Zapoznaj się z pełną architekturą referencyjną w artykule Apply Zero Trust principles to Azure IaaS overview (Stosowanie zasad zero trustu do usługi Azure IaaS — omówienie ).
Różni się to w zależności od konkretnych potrzeb związanych z zarządzaniem. Jednak reguły na urządzeniach zapory i regułach w sieciowej grupie zabezpieczeń powinny być używane do jawnego zezwalania na połączenia po stronie sieci platformy i po stronie sieci obciążenia.
Wdrażanie rejestrowania przepływu sieciowej grupy zabezpieczeń
Nawet jeśli sieciowa grupa zabezpieczeń blokuje niepotrzebny ruch, nie oznacza, że cele są spełnione. Nadal musisz obserwować ruch występujący poza wyraźnymi wzorcami, aby wiedzieć, czy występuje atak.
Aby włączyć rejestrowanie przepływu sieciowej grupy zabezpieczeń, możesz wykonać czynności opisane w samouczku : Rejestrowanie przepływu ruchu sieciowego do i z maszyny wirtualnej względem istniejącej utworzonej sieciowej grupy zabezpieczeń.
Uwaga
- Konto magazynu powinno postępować zgodnie ze wskazówkami dotyczącymi konta magazynu Zero Trust.
- Dostęp do dzienników powinien być ograniczony zgodnie z potrzebami.
- Powinny one również przepływać do usług Log Analytics i Sentinel zgodnie z potrzebami.
Ochrona przychodzącego ruchu internetowego przy użyciu dostawcy tożsamości
Oprócz kontrolek w sieci wirtualnej będącej szprychą można również użyć usługi Azure Firewall, aby zastosować dodatkową inspekcję. Chociaż funkcja Zapora aplikacji internetowej dla usług Azure Front Door i Application Gateway sprawdza ruch pod kątem typowych ataków internetowych, użycie usługi Azure Firewall może zapewnić wyższy poziom inspekcji.
Aby użyć każdego dostępnego sygnału i zachować centralny wgląd w ruch sieciowy, zaleca się kierowanie ruchu z usługi Application Gateway do usługi Azure Firewall. Następnie może sprawdzić ruch pod kątem dodatkowych sygnałów i przechwycić zachowanie w dziennikach. Więcej informacji na temat tej konfiguracji można przeczytać w artykule Zero-trust network for web applications with Azure Firewall and Application Gateway (Sieć zerowa zaufania dla aplikacji internetowych za pomocą usługi Azure Firewall i usługi Application Gateway). Aby uzyskać więcej wskazówek dotyczących sposobu konfigurowania tego zachowania, zobacz Konfigurowanie usługi Azure Firewall — wersja Premium dla zera zaufania.
Krok 6. Zabezpieczanie dostępu do sieci wirtualnej i aplikacji
Zabezpieczanie dostępu do sieci wirtualnej i aplikacji obejmuje:
- Zabezpieczanie ruchu w środowisku platformy Azure do aplikacji.
- Korzystanie z uwierzytelniania wieloskładnikowego i zasad dostępu warunkowego w celu uzyskania dostępu użytkownika do aplikacji.
Na poniższym diagramie przedstawiono oba te tryby dostępu w architekturze referencyjnej.
Zabezpieczanie ruchu w środowisku platformy Azure dla sieci wirtualnej i aplikacji
Znaczna część pracy ruchu zabezpieczeń w środowisku platformy Azure została już ukończona. Bezpieczne połączenia między zasobami magazynu i maszynami wirtualnymi są konfigurowane w sekcji Stosowanie zasad zerowego zaufania do usługi Azure Storage.
Aby zabezpieczyć dostęp z zasobów centrum do sieci wirtualnej, zobacz Stosowanie zasad Zero Trust do sieci wirtualnej koncentratora na platformie Azure.
Korzystanie z uwierzytelniania wieloskładnikowego i zasad dostępu warunkowego w celu uzyskania dostępu użytkownika do aplikacji
Artykuł Stosowanie zasad Zero Trust do maszyn wirtualnych zaleca, aby chronić żądania dostępu bezpośrednio do maszyn wirtualnych przy użyciu uwierzytelniania wieloskładnikowego i dostępu warunkowego. Te żądania są najprawdopodobniej od administratorów i deweloperów. Następnym krokiem jest zabezpieczenie dostępu do aplikacji przy użyciu uwierzytelniania wieloskładnikowego i dostępu warunkowego. Dotyczy to wszystkich użytkowników, którzy uzyskują dostęp do aplikacji.
Najpierw, jeśli aplikacja nie jest jeszcze zintegrowana z identyfikatorem Entra firmy Microsoft, zobacz Typy aplikacji dla Platforma tożsamości Microsoft.
Następnie dodaj aplikację do zakresu zasad dostępu do tożsamości i urządzeń.
Podczas konfigurowania uwierzytelniania wieloskładnikowego przy użyciu dostępu warunkowego i powiązanych zasad należy użyć zalecanych zasad ustawionych dla modelu Zero Trust jako przewodnika. Obejmuje to zasady "punkt wyjścia", które nie wymagają zarządzania urządzeniami. W idealnym przypadku urządzenia, które uzyskują dostęp do maszyn wirtualnych, są zarządzane i można zaimplementować poziom "Enterprise", który jest zalecany dla modelu Zero Trust. Aby uzyskać więcej informacji, zobacz Common Zero Trust identity and device access policies (Common Zero Trust identity and device access policies).
Na poniższym diagramie przedstawiono zalecane zasady dla modelu Zero Trust.
Krok 7. Włączanie zaawansowanego wykrywania zagrożeń i ochrony
Sieć wirtualna będącej szprychą utworzona na platformie Azure może być już chroniona przez usługę Microsoft Defender dla Chmury (MDC), ponieważ inne zasoby ze środowiska biznesowego IT działającego na platformie Azure lub lokalnie mogą być również chronione.
Jak wspomniano w innych artykułach z tej serii, Microsoft Defender dla Chmury to narzędzie do zarządzania stanem zabezpieczeń w chmurze (CSPM) i ochrony obciążeń w chmurze (CWP), które oferuje Rekomendacje zabezpieczeń zabezpieczeń, alerty i zaawansowane funkcje, takie jak adaptacyjne wzmacnianie zabezpieczeń sieci, aby ułatwić postęp w podróży zabezpieczeń w chmurze. Aby lepiej wizualizować miejsca, w których Defender dla Chmury mieści się w większym środowisku zabezpieczeń firmy Microsoft, zobacz Microsoft Cybersecurity Reference Architectures (Architektury referencyjne cyberbezpieczeństwa firmy Microsoft).
W tym artykule nie omówiono szczegółowo Microsoft Defender dla Chmury, ale ważne jest, aby zrozumieć, że Microsoft Defender dla Chmury działa na podstawie zasad platformy Azure i dzienników pozyskanych w obszarze roboczym usługi Log Analytics. Po włączeniu subskrypcji z siecią wirtualną szprychy i skojarzonymi zasobami będzie można zobaczyć zalecenia, aby poprawić stan zabezpieczeń. Te Rekomendacje można filtrować dalej, stosując taktykę MITRE, grupę zasobów itp. Rozważ ustalenie priorytetów rozwiązania Rekomendacje, które mają większy wpływ na wskaźnik bezpieczeństwa organizacji.
Oto przykład w portalu Microsoft Defender dla Chmury.
Jeśli zdecydujesz się dołączyć jeden z planów Defender dla Chmury, które oferują zaawansowane zabezpieczenia obciążenia, obejmuje adaptacyjne wzmacnianie zabezpieczeń sieci Rekomendacje w celu poprawy istniejących reguł sieciowej grupy zabezpieczeń. Oto przykład.
Możesz zaakceptować zalecenie, wybierając pozycję Wymuś, co powoduje utworzenie nowej reguły sieciowej grupy zabezpieczeń lub zmodyfikowanie istniejącej.
Zalecane szkolenie
- Zabezpieczanie zasobów platformy Azure przy użyciu kontroli dostępu opartej na rolach (RBAC) platformy Azure
- Konfigurowanie usługi Azure Monitor i zarządzanie nią
- Konfigurowanie sieciowych grup zabezpieczeń
- Projektowanie i implementowanie zabezpieczeń sieci
- Zabezpieczanie dostępu do aplikacji przy użyciu usług tożsamości platformy Azure
Aby uzyskać więcej szkoleń dotyczących zabezpieczeń na platformie Azure, zobacz następujące zasoby w katalogu firmy Microsoft:
Zabezpieczenia na platformie Azure | Microsoft Learn
Następne kroki
Zapoznaj się z następującymi dodatkowymi artykułami dotyczącymi stosowania zasad zero trust do platformy Azure:
- Omówienie usługi IaaS platformy Azure
- Azure Virtual Desktop
- Azure Virtual WAN
- Aplikacje IaaS w usługach Amazon Web Services
- Microsoft Sentinel i Microsoft Defender XDR
Ilustracje techniczne
Ten plakat zawiera jednostronicowy, błyskawiczny widok składników usługi Azure IaaS jako architektur referencyjnych i logicznych, wraz z krokami zapewniającymi, że te składniki mają zastosowane zasady "nigdy nie ufaj, zawsze weryfikują".
| Element | opis |
|---|---|
 Pdf | Visio Zaktualizowano: marzec 2024 r. |
Użyj tej ilustracji razem z tym artykułem: Stosowanie zasad zero trustu do przeglądu usługi IaaS platformy Azure Powiązane przewodniki dotyczące rozwiązań |
Ten plakat zawiera architektury referencyjne i logiczne oraz szczegółowe konfiguracje oddzielnych składników platformy Zero Trust dla usługi Azure IaaS. Użyj stron tego plakatu dla oddzielnych działów IT lub specjalizacji lub, z wersją programu Microsoft Visio pliku, dostosuj diagramy dla infrastruktury.
| Element | opis |
|---|---|
 Pdf | Visio Zaktualizowano: marzec 2024 r. |
Skorzystaj z tych diagramów razem z artykułami, które zaczynają się tutaj: Stosowanie zasad zero trustu do przeglądu usługi IaaS platformy Azure Powiązane przewodniki dotyczące rozwiązań |
Aby uzyskać dodatkowe ilustracje techniczne, kliknij tutaj.
Informacje
- Obsługa proaktywnych zabezpieczeń za pomocą rozwiązania Zero Trust
- Zabezpieczanie sieci za pomocą zera trustu
- Sieć o zerowym zaufaniu dla aplikacji internetowych z usługami Azure Firewall i Application Gateway — Centrum architektury platformy Azure
- Zasady strefy docelowej platformy Azure
- Common Zero Trust identity and device policies (Typowe zasady tożsamości i urządzeń z zerowym zaufaniem)
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla