Share via

Stosowanie zasad Zero Trust do sieci wirtualnej będącej szprychą za pomocą usług Azure PaaS

  • Artykuł

Ten artykuł pomaga zastosować zasady modelu zabezpieczeń Zero Trust do obciążenia PaaS przy użyciu sieci wirtualnych platformy Azure i prywatnych punktów końcowych 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 funkcji wykrywania zagrożeń w usłudze Azure Firewall i aplikacja systemu Azure Gateway, aby zweryfikować ruch i sprawdzić, czy ruch jest akceptowalny.
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. Zmniejsz ruch przychodzący do usług platformy Azure i wychodzący z usług platformy Azure do sieci prywatnej. Użyj sieciowych grup zabezpieczeń, aby zezwolić tylko na określony ruch przychodzący z sieci wirtualnej. Użyj centralnego wystąpienia usługi Azure Firewall, aby udzielić dostępu ruchu innego niż sieć wirtualna do usługi platformy Azure.
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 logujesz się z sieciowych grup zabezpieczeń i że masz odpowiedni wgląd w nietypowy ruch. Śledzenie zmian w sieciowych grupach zabezpieczeń.

Aby uzyskać więcej informacji na temat stosowania zasad zero trust w środowisku IaaS platformy Azure, zobacz Omówienie zasad Zastosuj zero trust do usługi Azure IaaS.

Autonomiczna sieć typu Zero Trust lub szprycha dla usług PaaS platformy Azure

Wiele usług PaaS zawiera własne, natywne dla usługi funkcje kontroli ruchu przychodzącego i ruchu wychodzącego. Za pomocą tych kontrolek można zabezpieczyć dostęp sieciowy do zasobów usługi PaaS bez konieczności infrastruktury, takiej jak sieci wirtualne. Na przykład:

  • Usługa Azure SQL Database ma własną zaporę, która może służyć do zezwalania na określone adresy IP klienta, które muszą uzyskiwać dostęp do serwera bazy danych.
  • Konta usługi Azure Storage mają opcję konfiguracji zezwala na połączenia z określonej sieci wirtualnej lub blokowanie dostępu do sieci publicznej.
  • usługa aplikacja systemu Azure obsługuje ograniczenia dostępu w celu zdefiniowania listy dozwolonych/odmowy uporządkowanych priorytetami, która kontroluje dostęp sieciowy do aplikacji.

Jednak w przypadku implementacji z przewodnikiem Zero Trust te natywne mechanizmy kontroli dostępu często nie są wystarczające. Powoduje to rozproszenie kontroli dostępu i rejestrowania, które może zwiększyć zarządzanie i zmniejszyć widoczność.

Ponadto usługi PaaS mogą używać w pełni kwalifikowanych nazw domen (FQDN), które rozpoznają dynamicznie przypisany publiczny adres IP przydzielony z puli publicznych adresów IP w określonym regionie dla typu usługi. W związku z tym nie będzie można zezwolić na ruch z lub do określonej usługi PaaS przy użyciu ich publicznego adresu IP, co może ulec zmianie.

Firma Microsoft zaleca używanie prywatnych punktów końcowych. Prywatny punkt końcowy to interfejs sieci wirtualnej, który używa prywatnego adresu IP z sieci wirtualnej. Ten interfejs sieciowy zapewnia prywatne i bezpieczne połączenie z usługą obsługiwaną przez usługę Azure Private Link. Włączenie prywatnego punktu końcowego umożliwia przełączenie usługi do sieci wirtualnej.

W zależności od scenariusza rozwiązania nadal może być potrzebny publiczny dostęp przychodzący do usług PaaS. Jednak jeśli nie zrobisz, firma Microsoft zaleca, aby cały ruch pozostał prywatny, aby wyeliminować potencjalne zagrożenia bezpieczeństwa.

Ten przewodnik zawiera instrukcje dotyczące konkretnej architektury referencyjnej, ale zasady i metody mogą być stosowane do innych architektur zgodnie z potrzebami.

Architektura odwołań

Na poniższym diagramie przedstawiono wspólną architekturę referencyjną dla obciążeń opartych na usłudze PaaS.

Diagram architektury referencyjnej dla obciążeń opartych na usłudze PaaS.

Na diagramie:

  • Sieć wirtualna szprych zawiera składniki obsługujące aplikację PaaS.
  • Aplikacja PaaS to dwuwarstwowa aplikacja korzystająca z usług aplikacja systemu Azure dla aplikacji internetowej/frontonu oraz usługi Azure SQL Database dla relacyjnych baz danych.
  • Każda warstwa jest zawarta w dedykowanej podsieci dla ruchu przychodzącego z dedykowaną sieciową grupą zabezpieczeń.
  • Warstwa internetowa zawiera dedykowaną podsieć dla ruchu wychodzącego.
  • Dostęp do aplikacji jest udostępniany za pośrednictwem usługi Application Gateway zawartej we własnej podsieci.

Na poniższym diagramie przedstawiono logiczną architekturę tych składników w ramach subskrypcji platformy Azure.

Diagram składników w ramach subskrypcji platformy Azure.

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ń (nazwane "sieciową grupą zabezpieczeń" na diagramie) dla warstw bazy danych, aplikacji i frontonu
  • Dwie grupy zabezpieczeń aplikacji (nazwane za pomocą grupy asg" na diagramie)
  • Dwa prywatne punkty końcowe

Ponadto zasoby dla sieci wirtualnej koncentratora są wdrażane w odpowiedniej subskrypcji łączności.

Co znajduje się w tym artykule

Zasady zerowego zaufania są stosowane w całej architekturze, od 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
1 Skorzystaj z kontroli dostępu opartej na rolach firmy Microsoft lub skonfiguruj role niestandardowe dla zasobów sieciowych.
2 Izolowanie infrastruktury do własnej grupy zasobów.
3 Utwórz sieciową grupę zabezpieczeń dla każdej podsieci.
100 Zabezpieczanie ruchu i zasobów w sieci wirtualnej:
  • Wdrażanie reguł odmowy punktu odniesienia dla sieciowych grup zabezpieczeń.
  • Planowanie ruchu zarządzania do sieci wirtualnej.
  • Wdrażanie rejestrowania przepływu sieciowej grupy zabezpieczeń.
5 Zabezpieczanie ruchu przychodzącego i ruchu wychodzącego dla usług PaaS platformy Azure.
6 Bezpieczny dostęp do sieci wirtualnej i aplikacji.
7 Włącz zaawansowane wykrywanie zagrożeń, alerty i ochronę.

W tym przewodniku założono, że masz już usługę aplikacja systemu Azure i usługę Azure SQL Database wdrożoną we własnych grupach zasobów.

Krok 1. Korzystanie z kontroli dostępu opartej na rolach firmy Microsoft lub konfigurowanie ról niestandardowych dla zasobów sieciowych

Możesz skorzystać z wbudowanych ról kontroli dostępu opartej na rolach firmy Microsoft dla współautorów sieci. Jednak innym podejściem jest wykorzystanie ról niestandardowych. Menedżerowie sieci wirtualnej będącej 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. Rola niestandardowa może służyć do określania zakresu dostępu tylko 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ą, która może być używana, jest rola niestandardowa Zarządzanie siecią , która 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 w repozytorium GitHub architektury referencyjnej strefy docelowej platformy Azure lub utworzyć za pomocą identyfikatora entra firmy Microsoft z rolami niestandardowymi 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 dedykowaną grupę zasobów. Na poniższym diagramie architektury przedstawiono tę konfigurację.

Diagram izolowania infrastruktury do własnej grupy zasobów.

Na diagramie zasoby i składniki w architekturze referencyjnej są podzielone na dedykowane grupy zasobów dla usług aplikacji, baz danych Azure SQL Database, 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 samouczka Udzielanie użytkownikowi dostępu do zasobów platformy Azure przy użyciu witryny Azure Portal .

Dodatkowe zalecenia:

  • Odwołanie do grupy zabezpieczeń roli zamiast nazwanych osób.
  • Zarządzanie dostępem do grupy zabezpieczeń za pomocą praktyk 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:

  1. Znajdź grupę zasobów w witrynie Azure Portal.
  2. Przejdź do obszaru Dziennik aktywności —> Eksportuj dzienniki aktywności, a następnie wybierz pozycję + Dodaj ustawienie diagnostyczne.
  3. 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. Oto przykład:

Przykład ustawienia diagnostycznego.

Zobacz Ustawienia diagnostyczne, aby dowiedzieć się, jak przeglądać te dzienniki i otrzymywać alerty.

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, zobacz zasady projektowania strefy docelowej platformy Azure.

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. Jest to domyślnie wymuszane 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łowe i docelowe adresy IP, protokół (taki jak TCP lub UDP) i port.

W przypadku aplikacji wielowarstwowych zaleca się utworzenie dedykowanej sieciowej grupy zabezpieczeń ("NSG" na poniższym diagramie) dla każdej podsieci, która hostuje składnik sieci.

Diagram dedykowanych sieciowych grup zabezpieczeń dla każdej podsieci.

Na diagramie:

  • Każda warstwa aplikacji ma dedykowaną podsieć ruchu przychodzącego, taką jak jedna dla warstwy internetowej, a druga dla warstwy danych.
  • aplikacja systemu Azure Services ma dedykowaną podsieć ruchu wychodzącego dla określonej usługi aplikacji.
  • Sieciowa grupa zabezpieczeń jest skonfigurowana dla każdej z tych podsieci.

Skonfigurowanie sieciowych grup zabezpieczeń w inny sposób niż na diagramie 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.

Zobacz Tworzenie, zmienianie lub usuwanie sieciowej grupy zabezpieczeń platformy Azure w celu zarządzania ustawieniami sieciowych grup zabezpieczeń.

Przeczytaj więcej na temat sieciowych grup zabezpieczeń, aby dowiedzieć się, jak można ich używać do zabezpieczania środowisk.

Krok 4. Zabezpieczanie ruchu i zasobów w sieci wirtualnej

W tej sekcji opisano następujące zalecenia:

  • Wdrażanie reguł odmowy punktu odniesienia dla sieciowych grup zabezpieczeń
  • Wdrażanie reguł specyficznych dla 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ą reguły zezwalania . 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 zezwalania.

W tym celu 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.

Przykład reguł zabezpieczeń dla ruchu wychodzącego.

Powtórz ten proces przy użyciu reguł ruchu przychodzącego, dostosowując odpowiednio nazwę i opis.

Karta Reguły zabezpieczeń dla ruchu przychodzącego wyświetla znak ostrzegawczy reguły. Oto przykład.

Przykład reguł zabezpieczeń dla ruchu przychodzącego.

Kliknij regułę i przewiń do dołu, aby wyświetlić więcej szczegółów. Oto przykład:

Przykład szczegółów reguły.

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 będzie mieć natychmiastowy dostęp do zasobów. Dla każdego wzorca ruchu utwórz regułę jawnie zezwalającą na tę regułę i należy to zrobić z najmniejszą ilością uprawnień.

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 określone zewnętrzne witryny internetowe, muszą być kontrolowane tutaj.

Alternatywne reguły odmowy

Uwaga

Zalecenia w tej sekcji dotyczą tylko podsieci web-egress.

Jeśli używasz usługi Azure Firewall do zarządzania połączeniami wychodzącym, zamiast wykonywać polecenia deny-outbound-all, możesz utworzyć alternatywne reguły dla połączeń wychodzących. 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. Będzie to obsługiwać ruch poza siecią wirtualną.

Następnie można utworzyć regułę odmowy dla wszystkich ruchu wychodzącego sieci wirtualnej lub zezwalać na wszystkie reguły ruchu wychodzącego, ale zabezpieczać elementy przy użyciu reguł ruchu przychodzącego.

Zobacz Tabele usługi Azure Firewall i routingu , aby dowiedzieć się, jak można ich używać w celu dalszego zwiększania bezpieczeństwa środowiska.

Wdrażanie reguł specyficznych dla aplikacji

Zdefiniuj wzorce ruchu z najmniejszą ilością uprawnień i tylko po jawnie dozwolonych ścieżkach. Używając podsieci jako źródeł, zdefiniuj wzorce sieciowe w sieciowych grupach zabezpieczeń. Oto przykład.

Diagram wzorców sieciowych w sieciowych grupach zabezpieczeń.

Użyj procedury Zarządzanie sieciowymi grupami zabezpieczeń: Utwórz proces reguł zabezpieczeń, aby dodać reguły do sieciowych grup zabezpieczeń.

Aby zabezpieczyć ten scenariusz, dodaj następujące reguły:

Sieciowa grupa zabezpieczeń dla podsieci Kierunek Źródło Szczegóły źródła Port źródłowy Element docelowy Szczegóły miejsca docelowego Usługa Nazwa sieciowej grupy zabezpieczeń Opis sieciowej grupy zabezpieczeń
Podsieć usługi App Service Przychodzący Adresy IP Zakres prywatnych adresów IP podsieci usługi Application Gateway 443 Adresy IP Jawny adres IP prywatnego punktu końcowego usługi App Service MS SQL AllowGWtoAppInbound Zezwala na dostęp przychodzący do usługi App Service z usługi Application Gateway.
Podsieć integracji usługi App Service Wychodzący Adresy IP Zakres adresów IP podsieci integracji usługi App Service 1433 Adresy IP Jawny adres IP prywatnego punktu końcowego bazy danych SQL DB MS SQL AllowApptoSQLDBOutbound Zezwala na dostęp wychodzący do prywatnego punktu końcowego SQL z podsieci integracji usługi App Service.
Podsieć usługi Azure SQL Przychodzący Adresy IP Zakres adresów IP podsieci integracji usługi App Service 1433 Adresy IP Jawny adres IP prywatnego punktu końcowego bazy danych SQL DB MS SQL AllowApptoSQLDBInbound Zezwala na dostęp przychodzący do prywatnego punktu końcowego SQL z podsieci integracji usługi App Service.

Uwaga

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 "*", aby zezwolić na dowolny port źródłowy. Port docelowy jest bardziej znaczący, a niektóre zalecenia mają zawsze używać wartości "*" dla portu źródłowego.

Uwaga

W przypadku priorytetu użyj wartości z zakresu od 100 do 4000. Możesz rozpocząć od 105.

Jest to dodatek do reguł sieciowej grupy zabezpieczeń w podsieci usługi Application Gateway.

W przypadku tych 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 zaplanuj ruch związany z zarządzaniem. Jednak ze względu na to, że ruch zarządzania zazwyczaj pochodzi poza siecią wirtualną szprych, wymagane są więcej reguł. Najpierw zapoznaj się z określonymi portami i źródłami, z których będzie pochodzić ruch zarządzania. Zazwyczaj cały ruch zarządzania powinien przepływać z zapory lub innego wirtualnego urządzenia sieciowego (WUS) znajdującego się w sieci piasty dla szprychy.

Aby uzyskać pełną architekturę referencyjną, zobacz Apply Zero Trust principles to Azure IaaS overview (Stosowanie zasad zero trustu do usługi Azure IaaS — omówienie ).

Konfiguracja będzie się różnić w zależności od konkretnych potrzeb związanych z zarządzaniem. Należy jednak używać reguł na urządzeniach zapory i regułach w sieciowej grupie zabezpieczeń, aby jawnie zezwalać na połączenia zarówno po stronie sieci platformy, jak i sieci obciążeń.

Planowanie wdrożeń

Ponieważ usługi aplikacji i bazy danych korzystają teraz z sieci prywatnych, zaplanuj sposób działania wdrożeń kodu i danych w tych zasobach. Dodaj reguły, aby zezwolić prywatnym serwerom kompilacji na dostęp do tych punktów końcowych.

Wdrażanie rejestrowania przepływu sieciowej grupy zabezpieczeń

Nawet jeśli sieciowa grupa zabezpieczeń blokuje niepotrzebny ruch, nie oznacza to, że cele są spełnione. Aby wykryć atak, nadal trzeba obserwować ruch, który występuje poza jawnymi wzorcami.

Ruch do prywatnych punktów końcowych nie jest rejestrowany, ale jeśli w podsieciach zostaną wdrożone inne usługi, ten dziennik pomoże wykryć działania.

Aby włączyć rejestrowanie przepływu sieciowej grupy zabezpieczeń, wykonaj czynności opisane w artykule Samouczek: Rejestrowanie przepływu ruchu sieciowego do i z maszyny wirtualnej dla istniejącej sieciowej grupy zabezpieczeń dla prywatnych punktów końcowych.

Uwaga

Pamiętaj o tych zaleceniach:

  • W razie potrzeby należy ograniczyć dostęp do dzienników.

  • Dzienniki powinny przepływać do usług Log Analytics i Microsoft Sentinel zgodnie z potrzebami.

Krok 5. Zabezpieczanie ruchu przychodzącego i wychodzącego dla usług PaaS platformy Azure

Ta sekcja zawiera dwa kroki niezbędne do zabezpieczenia ruchu przychodzącego i ruchu wychodzącego dla usług PaaS:

  • Wdróż prywatne punkty końcowe na potrzeby ruchu przychodzącego do usług.
  • Wdróż integrację z siecią wirtualną, aby umożliwić usłudze Application Service rozmowę z siecią wirtualną.

Ponadto należy również rozważyć konfigurację DNS, aby umożliwić rozpoznawanie nazw.

Wdrażanie prywatnych punktów końcowych dla ruchu przychodzącego

Chociaż wiele usług umożliwia tworzenie prywatnych punktów końcowych z bloku specyficznego dla zasobu w witrynie Azure Portal, bardziej spójne środowisko polega na utworzeniu prywatnego punktu końcowego na podstawie własnego tworzenia zasobów. W tym celu należy już wdrożyć zasoby. Po wdrożeniu możesz utworzyć prywatny punkt końcowy.

Podczas wdrażania prywatnych punktów końcowych skonfiguruj je w następujący sposób:

  • Umieść je w określonej grupie zasobów zawierającej zasoby nadrzędne, aby zachować zasoby o podobnym cyklu życia i zapewnić centralny dostęp.
  • Umieść je w odpowiedniej podsieci w sieci wirtualnej na podstawie ich roli.
  • W przypadku usługi aplikacja systemu Azure można skonfigurować prywatne punkty końcowe zarówno dla normalnego frontonu, jak i punktu końcowego SCM, który jest używany do wdrożeń i zarządzania.

Ponadto w ramach tego wdrożenia należy upewnić się, że zapora specyficzna dla usługi ma blokować ruch przychodzący. Spowoduje to zablokowanie wszelkich prób publicznego ruchu przychodzącego.

W przypadku bazy danych Azure SQL Database zarządzaj regułami zapory adresów IP na poziomie serwera. Upewnij się, że opcja Dostęp do sieci publicznej jest ustawiona na wartość Wyłącz z panelu sieci w witrynie Azure Portal.

W przypadku usługi aplikacja systemu Azure dodanie prywatnego punktu końcowego ustawia zaporę na poziomie usługi w celu domyślnego blokowania dostępu przychodzącego. Aby uzyskać więcej informacji, zobacz Using Private Endpoints for App Service apps (Używanie prywatnych punktów końcowych dla aplikacji usługi App Service).

Wdrażanie integracji z siecią wirtualną na potrzeby ruchu wychodzącego

Oprócz prywatnych punktów końcowych dla ruchu przychodzącego włącz integrację z siecią wirtualną. Każdy plan usługi App Service może mieć włączoną integrację z siecią wirtualną i przydziela całą podsieć dla usługi App Service. Aby uzyskać więcej informacji, zobacz Integrowanie aplikacji z siecią wirtualną platformy Azure.

Aby skonfigurować usługę App Service, zobacz Włączanie integracji sieci wirtualnej w usłudze aplikacja systemu Azure Service. Upewnij się, że umieszczasz ją w podsieci wyznaczonej do ruchu wychodzącego.

Zagadnienia dotyczące systemu DNS

W ramach korzystania z prywatnych punktów końcowych włącz rozpoznawanie nazw FQDN zasobów na nowe prywatne adresy IP. Aby uzyskać instrukcje implementacji tej funkcji na różne sposoby, zobacz Konfiguracja DNS prywatnego punktu końcowego.

Uwaga

Rozpoznawanie nazw DNS musi dotyczyć całego ruchu. Zasoby w tej samej sieci wirtualnej nie będą mogły rozpoznać, chyba że używają poprawnych stref DNS.

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 (MFA) i zasad dostępu warunkowego na potrzeby dostępu użytkowników do aplikacji.

Na poniższym diagramie przedstawiono oba tryby dostępu w architekturze referencyjnej.

Diagram trybów 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. Zobacz Stosowanie zasad zerowego zaufania do usługi Azure Storage , aby skonfigurować bezpieczne połączenia między zasobami magazynu a maszynami wirtualnymi.

Zobacz Stosowanie zasad zero trustu do sieci wirtualnej piasty na platformie Azure , aby zabezpieczyć dostęp z zasobów centrum do sieci wirtualnej.

Korzystanie z uwierzytelniania wieloskładnikowego i zasad dostępu warunkowego na potrzeby dostępu użytkowników do aplikacji

Artykuł Apply Zero Trust principles to virtual machines (Stosowanie zasad zerowego zaufania do maszyn wirtualnych) zaleca, jak chronić żądania dostępu bezpośrednio do maszyn wirtualnych za pomocą 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 za pomocą 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 użyj zalecanych zasad ustawionych dla opcji Zero Trust jako przewodnik. Obejmuje to zasady punktu początkowego, 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 przedsiębiorstwa , 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.

Diagram zalecanych zasad dostępu do tożsamości i urządzeń dla programu Zero Trust.

Krok 7. Włączanie zaawansowanego wykrywania zagrożeń i ochrony

Sieć wirtualna szprych oparta na platformie Azure może być chroniona przez Microsoft Defender dla Chmury, 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, Defender dla Chmury to narzędzie do zarządzania stanem zabezpieczeń w chmurze (CSPM) i ochrony obciążeń w chmurze (CWP), które oferuje zalecenia dotyczące zabezpieczeń, alerty i zaawansowane funkcje, takie jak adaptacyjne wzmacnianie zabezpieczeń sieci, aby ułatwić Ci postęp w podróży zabezpieczeń w chmurze.

W tym artykule nie opisano Defender dla Chmury szczegółowo, ale należy pamiętać, że 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 możesz zobaczyć zalecenia, aby poprawić stan zabezpieczeń. Te zalecenia można filtrować dalej według taktyki MITRE, grupy zasobów i innych. Rozważ ustalenie priorytetów, aby rozwiązać problemy z zaleceniami, które mają większy wpływ na wskaźnik bezpieczeństwa organizacji. Oto przykład.

Przykład zaleceń Microsoft Defender dla Chmury.

Istnieją Defender dla Chmury plany, które oferują zaawansowane zabezpieczenia obciążeń, które obejmują adaptacyjne zalecenia dotyczące wzmacniania zabezpieczeń sieci w celu poprawy istniejących reguł sieciowej grupy zabezpieczeń. Oto przykład.

Przykład zaleceń dotyczących wzmacniania zabezpieczeń sieci.

Możesz zaakceptować zalecenie, wybierając pozycję Wymuś, co spowoduje utworzenie nowej reguły sieciowej grupy zabezpieczeń lub zmodyfikowanie istniejącej.

Następne kroki

Zapoznaj się z następującymi dodatkowymi artykułami dotyczącymi stosowania zasad zero trust do platformy Azure:

Informacje