Zagadnienia dotyczące zabezpieczeń obciążeń o znaczeniu krytycznym na platformie Azure

Zabezpieczenia są jedną z podstawowych zasad projektowania, a także kluczową dziedziną projektowania, która musi być traktowana jako pierwszy problem klasy w procesie architektury o znaczeniu krytycznym.

Biorąc pod uwagę, że głównym celem projektu o znaczeniu krytycznym jest maksymalizacja niezawodności, dzięki czemu aplikacja pozostaje wydajna i dostępna, zagadnienia dotyczące zabezpieczeń i rekomendacje stosowane w tym obszarze projektu koncentrują się na ograniczeniu zagrożeń z pojemnością, aby wpłynąć na dostępność i utrudnić ogólną niezawodność. Na przykład pomyślne ataki typu "odmowa usługi" (DDoS) są znane z katastrofalnego wpływu na dostępność i wydajność. W jaki sposób aplikacja ogranicza te wektory ataków, takie jak SlowLoris, wpłynie na ogólną niezawodność. W związku z tym aplikacja musi być w pełni chroniona przed zagrożeniami, które mają na celu bezpośrednie lub pośrednio naruszenie niezawodności aplikacji, aby mieć charakter prawdziwie krytyczny.

Należy również pamiętać, że często występują znaczące kompromisy związane ze wzmocnionym stanem zabezpieczeń, szczególnie w odniesieniu do wydajności, elastyczności operacyjnej i w niektórych przypadkach niezawodności. Na przykład włączenie wbudowanych wirtualnych urządzeń sieciowych (NVA) dla funkcji zapory nowej generacji (NGFW), takich jak głęboka inspekcja pakietów, wprowadzi znaczną karę wydajności, dodatkową złożoność operacyjną i ryzyko niezawodności, jeśli skalowalność i operacje odzyskiwania nie są ściśle dopasowane do tej aplikacji. Dlatego ważne jest, aby dodatkowe składniki zabezpieczeń i praktyki mające na celu ograniczenie kluczowych wektorów zagrożeń zostały również zaprojektowane tak, aby obsługiwały cel niezawodności aplikacji, co stanowi kluczowy aspekt zaleceń i zagadnień przedstawionych w tej sekcji.

Ważne

Ten artykuł jest częścią serii obciążeń o znaczeniu krytycznym dla platformy Azure Well-Architected . Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tego, co to jest obciążenie o znaczeniu krytycznym?

Implementacje referencyjne są częścią projektu open source dostępnego w usłudze GitHub. Zasoby kodu przyjmują model Zero Trust do struktury i kierowania podejściem do projektowania i implementacji zabezpieczeń.

Wyrównanie do modelu Zero Trust

Model Zero Trust firmy Microsoft zapewnia proaktywne i zintegrowane podejście do stosowania zabezpieczeń we wszystkich warstwach aplikacji. Wytyczne dotyczące Zero Trust dążą do jawnego i ciągłego weryfikowania każdej transakcji, aserowania najmniejszych uprawnień, używania analizy i zaawansowanego wykrywania w celu reagowania na zagrożenia niemal w czasie rzeczywistym. Ostatecznie koncentruje się na wyeliminowaniu zaufania wewnątrz i poza obwodami aplikacji, wymuszając weryfikację dla niczego, co próbuje nawiązać połączenie z systemem.

Zagadnienia dotyczące projektowania

Podczas oceniania stanu zabezpieczeń aplikacji zacznij od tych pytań jako podstawy dla każdego zagadnienia.

• Ciągłe testowanie zabezpieczeń w celu zweryfikowania środków zaradczych pod kątem kluczowych luk w zabezpieczeniach.

  • Czy testy zabezpieczeń są wykonywane w ramach zautomatyzowanych procesów ciągłej integracji/ciągłego wdrażania?
  • Jeśli nie, jak często są wykonywane konkretne testy zabezpieczeń?
  • Czy wyniki testów są mierzone względem żądanego stanu zabezpieczeń i modelu zagrożeń?

• Poziom zabezpieczeń we wszystkich środowiskach niższych.

  • Czy wszystkie środowiska w cyklu projektowania mają taki sam stan zabezpieczeń jak środowisko produkcyjne?

• Ciągłość uwierzytelniania i autoryzacji w przypadku awarii.

  • Jeśli usługi uwierzytelniania lub autoryzacji są tymczasowo niedostępne, czy aplikacja będzie mogła nadal działać?

• Automatyczna zgodność z zabezpieczeniami i korygowanie.

  • Czy można wykryć zmiany w ustawieniach zabezpieczeń kluczy?
  • Czy odpowiedzi na korygowanie niezgodnych zmian są zautomatyzowane?

• Skanowanie wpisów tajnych w celu wykrywania wpisów tajnych przed zatwierdzaniem kodu w celu zapobiegania wyciekom wpisów tajnych za pośrednictwem repozytoriów kodu źródłowego.

  • Czy uwierzytelnianie usług jest możliwe bez konieczności posiadania poświadczeń w ramach kodu?

• Zabezpieczanie łańcucha dostaw oprogramowania.

  • Czy istnieje możliwość śledzenia typowych luk w zabezpieczeniach i ekspozycji (CVE) w ramach zależności używanych pakietów?
  • Czy istnieje zautomatyzowany proces aktualizowania zależności pakietu?

• Cykle życia klucza ochrony danych.

  • Czy klucze zarządzane przez usługę mogą być używane do ochrony integralności danych?
  • Jeśli wymagane są klucze zarządzane przez klienta, jaki jest bezpieczny i niezawodny cykl życia kluczy?

• Narzędzia ciągłej integracji/ciągłego wdrażania powinny wymagać Microsoft Entra jednostek usługi z wystarczającym dostępem na poziomie subskrypcji w celu ułatwienia dostępu płaszczyzny kontroli dla wdrożeń zasobów platformy Azure do wszystkich subskrypcji środowiska.

  • Gdy zasoby aplikacji są zablokowane w sieciach prywatnych, istnieje prywatna ścieżka łączności płaszczyzny danych, dzięki czemu narzędzia ciągłej integracji/ciągłego wdrażania mogą wykonywać wdrożenia i konserwację na poziomie aplikacji.
    • Wprowadza to dodatkową złożoność i wymaga sekwencji w procesie wdrażania za pośrednictwem wymaganych prywatnych agentów kompilacji.

Zalecenia dotyczące projektowania

• Użyj Azure Policy, aby wymusić konfiguracje zabezpieczeń i niezawodności dla wszystkich usług, zapewniając, że wszelkie odchylenia są korygowane lub zabronione przez płaszczyznę sterowania w czasie konfiguracji, pomagając ograniczyć zagrożenia związane ze scenariuszami "złośliwego administratora".

• Użyj Microsoft Entra Privileged Identity Management (PIM) w ramach subskrypcji produkcyjnych, aby odwołać trwały dostęp płaszczyzny kontroli do środowisk produkcyjnych. Znacznie zmniejszy to ryzyko wynikające z scenariuszy "złośliwego administratora" poprzez dodatkowe "kontrole i salda".

• Użyj tożsamości zarządzanych platformy Azure dla wszystkich usług, które obsługują tę funkcję, ponieważ ułatwia usuwanie poświadczeń z kodu aplikacji i usuwa obciążenie operacyjne zarządzania tożsamościami na potrzeby komunikacji między usługami.

• Użyj Microsoft Entra kontroli dostępu opartej na rolach (RBAC) na potrzeby autoryzacji płaszczyzny danych ze wszystkimi usługami, które obsługują tę funkcję.

• Użyj bibliotek uwierzytelniania Platforma tożsamości Microsoft pierwszej firmy w kodzie aplikacji, aby zintegrować się z Tożsamość Microsoft Entra.

• Rozważ użycie bezpiecznego buforowania tokenów, aby umożliwić obniżenie wydajności, ale dostępne środowisko, jeśli wybrana platforma tożsamości jest niedostępna lub jest dostępna tylko częściowo na potrzeby autoryzacji aplikacji.

  • Jeśli dostawca nie może wydać nowych tokenów dostępu, ale nadal weryfikuje istniejące, aplikacje i usługi zależne mogą działać bez problemów, dopóki tokeny nie wygaśnie.
  • Buforowanie tokenów jest zwykle obsługiwane automatycznie przez biblioteki uwierzytelniania (takie jak BIBLIOTEKA MSAL).

• Użyj potoków infrastruktury jako kodu (IaC) i zautomatyzowanych potoków ciągłej integracji/ciągłego wdrażania, aby napędzać aktualizacje wszystkich składników aplikacji, w tym w warunkach awarii.

  • Upewnij się, że połączenia usług ciągłej integracji/ciągłego wdrażania są chronione jako krytyczne informacje poufne i nie powinny być bezpośrednio dostępne dla żadnego zespołu usług.
  • Zastosuj szczegółową kontrolę dostępu opartej na rolach do produkcyjnych potoków ciągłego wdrażania, aby ograniczyć ryzyko "złośliwego administratora".
  • Rozważ użycie ręcznych bram zatwierdzania w potokach wdrażania produkcyjnego, aby dodatkowo ograniczyć ryzyko "złośliwego administratora" i zapewnić dodatkową pewność techniczną dla wszystkich zmian produkcyjnych.
    • Dodatkowe bramy bezpieczeństwa mogą być kompromisowe pod względem elastyczności i powinny być starannie oceniane, biorąc pod uwagę, jak elastyczność może być utrzymywana nawet w przypadku bram ręcznych.

• Zdefiniuj odpowiedni stan zabezpieczeń dla wszystkich niższych środowisk, aby zapewnić ograniczenie kluczowych luk w zabezpieczeniach.

  • Nie należy stosować tego samego stanu zabezpieczeń co produkcja, szczególnie w odniesieniu do eksfiltracji danych, chyba że wymagania prawne przewidują konieczność wykonania tej czynności, ponieważ znacznie naruszy to elastyczność deweloperów.

• Włącz Microsoft Defender dla chmury (wcześniej znanej jako Azure Security Center) dla wszystkich subskrypcji zawierających zasoby dla obciążenia o znaczeniu krytycznym.

  • Użyj Azure Policy, aby wymusić zgodność.
  • Włącz usługę Azure Defender dla wszystkich usług, które obsługują tę funkcję.

• Przejmij metodyki DevSecOps i zaimplementuj testowanie zabezpieczeń w potokach ciągłej integracji/ciągłego wdrażania.

  • Wyniki testów powinny być mierzone pod kątem zgodnego stanu zabezpieczeń w celu informowania o zatwierdzeniach wydań, czy to zautomatyzowanych, czy ręcznych.
  • Zastosuj testy zabezpieczeń w ramach procesu produkcyjnego ciągłego wdrażania dla każdej wersji.
    • Jeśli testowanie zabezpieczeń każdego wydania zagraża elastyczności operacyjnej, upewnij się, że zastosowano odpowiedni cykl testowania zabezpieczeń.

• Włącz skanowanie wpisów tajnych i skanowanie zależności w repozytorium kodu źródłowego.

Threat Modeling

Modelowanie zagrożeń zapewnia oparte na ryzyku podejście do projektowania zabezpieczeń przy użyciu zidentyfikowanych potencjalnych zagrożeń w celu opracowania odpowiednich środków zaradczych zabezpieczeń. Istnieje wiele możliwych zagrożeń z różnym prawdopodobieństwem wystąpienia, a w wielu przypadkach zagrożenia mogą łączyć się w nieoczekiwane, nieprzewidywalne, a nawet chaotyczne sposoby. Ta złożoność i niepewność polega na tym, że tradycyjne podejścia do zabezpieczeń oparte na technologii są w dużej mierze nieodpowiednie dla aplikacji w chmurze o znaczeniu krytycznym. Spodziewaj się, że proces modelowania zagrożeń dla aplikacji o znaczeniu krytycznym będzie złożony i nieprzyjaśniający.

Aby ułatwić poruszanie się po tych wyzwaniach, należy zastosować szczegółowe podejście do ochrony warstwowej w celu definiowania i implementowania środków zaradczych wyrównujących dla wymodelowanych zagrożeń, biorąc pod uwagę następujące warstwy obronne.

1. Platforma Azure z podstawowymi możliwościami zabezpieczeń i mechanizmami kontroli.
2. Architektura aplikacji i projekt zabezpieczeń.
3. Funkcje zabezpieczeń wbudowane, włączone i wdrażalne stosowane do zabezpieczania zasobów platformy Azure.
4. Kod aplikacji i logika zabezpieczeń.
5. Procesy operacyjne i metodyka DevSecOps.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure należy pamiętać, że dodatkowa warstwa ograniczania zagrożeń za pośrednictwem aprowizacji scentralizowanych funkcji zabezpieczeń jest zapewniana przez implementację strefy docelowej.

Zagadnienia dotyczące projektowania

Funkcja STRIDE zapewnia uproszczoną strukturę ryzyka umożliwiającą ocenę zagrożeń bezpieczeństwa w kluczowych wektorach zagrożeń.

• Sfałszowana tożsamość: personifikacja osób z uprawnieniami. Na przykład osoba atakująca personifikując innego użytkownika przy użyciu ich —
  • Tożsamość
  • Authentication
• Manipulowanie danymi wejściowymi: modyfikacja danych wejściowych wysyłanych do aplikacji lub naruszenie granic zaufania w celu zmodyfikowania kodu aplikacji. Na przykład osoba atakująca używająca iniekcji SQL do usuwania danych w tabeli bazy danych.
  • Integralność danych
  • Walidacja
  • Lista bloków/lista dozwolonych
• Odrzucanie akcji: zdolność do odpierania już podjętych akcji oraz zdolności aplikacji do zbierania dowodów i napędzania odpowiedzialności. Na przykład usunięcie danych krytycznych bez możliwości śledzenia złośliwych administratorów.
  • Inspekcja/rejestrowanie
  • Podpisywanie
• Ujawnienie informacji: uzyskiwanie dostępu do informacji ograniczonych. Przykładem może być uzyskanie przez osobę atakującą dostępu do pliku z ograniczeniami.
  • Szyfrowanie
  • Eksfiltracja danych
  • Ataki typu man-in-the-middle
• Odmowa usługi: zakłócenia działania złośliwych aplikacji w celu obniżenia wydajności środowiska użytkownika. Na przykład atak botnetu DDoS, taki jak Slowloris.
  • Atak DDoS
  • Botnety
  • Możliwości usługi CDN i zapory aplikacji internetowej
• Podniesienie uprawnień: uzyskiwanie uprzywilejowanego dostępu do aplikacji za pośrednictwem luk w autoryzacji. Na przykład osoba atakująca manipuluje ciągiem adresu URL w celu uzyskania dostępu do poufnych informacji.
  • Zdalne wykonywanie kodu
  • Autoryzacja
  • Izolacja

Zalecenia dotyczące projektowania

• Przydziel budżet inżynieryjny w każdym przebiegu, aby ocenić potencjalne nowe zagrożenia i wdrożyć środki zaradcze.

• Należy zastosować świadome wysiłki w celu zapewnienia, że środki zaradcze bezpieczeństwa są przechwytywane w ramach typowych kryteriów inżynieryjnych w celu zapewnienia spójności we wszystkich zespołach usług aplikacji.

• Zacznij od usługi według modelowania zagrożeń na poziomie usługi i ujednolicania modelu, konsolidując model wątków na poziomie aplikacji.

Ochrona przed włamaniami do sieci

Zapobieganie nieautoryzowanemu dostępowi do aplikacji o krytycznym znaczeniu i uwzględnianie danych jest niezbędne do utrzymania dostępności i ochrony integralności danych.

Zagadnienia dotyczące projektowania

• Zero Trust przyjmuje stan naruszenia i sprawdza każde żądanie tak, jakby pochodziło z niekontrolowanych sieci.

  • Zaawansowana implementacja sieci zerowej zaufania wykorzystuje mikro segmentację i rozproszone obwody ruchu przychodzącego/wychodzącego.

• Usługi PaaS platformy Azure są zwykle dostępne za pośrednictwem publicznych punktów końcowych. Platforma Azure zapewnia możliwości zabezpieczania publicznych punktów końcowych, a nawet zapewnia ich całkowicie prywatne.

  • Azure Private Link/prywatne punkty końcowe zapewniają dedykowany dostęp do zasobu PaaS platformy Azure przy użyciu prywatnych adresów IP i łączności sieciowej prywatnej.
  • Virtual Network Punkty końcowe usługi zapewniają dostęp na poziomie usługi z wybranych podsieci do wybranych usług PaaS.
  • Virtual Network Iniekcja zapewnia dedykowane wdrożenia prywatne dla obsługiwanych usług, takich jak App Service za pośrednictwem App Service Environment.
    • Ruch płaszczyzny zarządzania nadal przepływa przez publiczne adresy IP.

• W przypadku obsługiwanych usług Azure Private Link przy użyciu prywatnych punktów końcowych platformy Azure adresuje ryzyko eksfiltracji danych skojarzone z punktami końcowymi usługi, takie jak złośliwy administrator zapisu danych do zasobu zewnętrznego.

• W przypadku ograniczania dostępu sieciowego do usług PaaS platformy Azure przy użyciu prywatnych punktów końcowych lub punktów końcowych usługi bezpieczny kanał sieciowy będzie wymagany do potoków wdrażania w celu uzyskania dostępu zarówno do płaszczyzny sterowania platformy Azure, jak i płaszczyzny danych zasobów platformy Azure w celu wdrożenia aplikacji i zarządzania nią.

  • Prywatni agenci kompilacji hostowani samodzielnie wdrożeni w sieci prywatnej, ponieważ zasób platformy Azure może służyć jako serwer proxy do wykonywania funkcji ciągłej integracji/ciągłego wdrażania za pośrednictwem połączenia prywatnego. Oddzielna sieć wirtualna powinna być używana dla agentów kompilacji.
    • Wymagana jest łączność z prywatnymi agentami kompilacji z narzędzi ciągłej integracji/ciągłego wdrażania.
  • Alternatywną metodą jest zmodyfikowanie reguł zapory dla zasobu on-the-fly w potoku, aby zezwolić na połączenie z publicznego adresu IP agenta usługi Azure DevOps, a zapora zostanie usunięta po zakończeniu zadania.
    • Jednak takie podejście dotyczy tylko podzestawu usług platformy Azure. Na przykład nie jest to możliwe w przypadku prywatnych klastrów usługi AKS.
  • Do wykonywania zadań deweloperskich i administracyjnych w polach przesiadkowych usługi aplikacji można użyć.

• Ukończenie zadań administracyjnych i konserwacji jest kolejnym scenariuszem wymagającym łączności z płaszczyzną danych zasobów platformy Azure.

• Usługa Connections z odpowiednią jednostką usługi Microsoft Entra może służyć w usłudze Azure DevOps do stosowania kontroli dostępu opartej na rolach za pośrednictwem Tożsamość Microsoft Entra.

• Tagi usług można zastosować do sieciowych grup zabezpieczeń w celu ułatwienia łączności z usługami PaaS platformy Azure.

• Grupy zabezpieczeń aplikacji nie obejmują wielu sieci wirtualnych.

• Przechwytywanie pakietów na platformie Azure Network Watcher jest ograniczone do maksymalnego okresu pięciu godzin.

Zalecenia dotyczące projektowania

• Ogranicz dostęp do sieci publicznej do bezwzględnego minimum wymaganego dla aplikacji, aby spełnić swój cel biznesowy w celu zmniejszenia zewnętrznej powierzchni ataków.

  • Użyj Azure Private Link, aby ustanowić prywatne punkty końcowe dla zasobów platformy Azure, które wymagają bezpiecznej integracji z siecią.
  • Użyj hostowanych prywatnych agentów kompilacji do narzędzi ciągłej integracji/ciągłego wdrażania, aby wdrożyć i skonfigurować zasoby platformy Azure chronione przez Azure Private Link.
    • Agenci hostowani przez firmę Microsoft nie będą mogli bezpośrednio łączyć się z zasobami zintegrowanymi z siecią.

• Podczas pracy z prywatnymi agentami kompilacji nigdy nie otwieraj portu RDP lub SSH bezpośrednio do Internetu.

  • Użyj usługi Azure Bastion, aby zapewnić bezpieczny dostęp do usługi Azure Virtual Machines i wykonywać zadania administracyjne w usłudze Azure PaaS za pośrednictwem Internetu.

• Użyj planu ochrony przed atakami DDoS w warstwie Standardowa, aby zabezpieczyć wszystkie publiczne adresy IP w aplikacji.

• Użyj usługi Azure Front Door z zasadami zapory aplikacji internetowej, aby dostarczać i chronić globalne aplikacje HTTP/S obejmujące wiele regionów świadczenia usługi Azure.

  • Użyj walidacji identyfikatora nagłówka, aby zablokować punkty końcowe aplikacji publicznej, aby akceptowały tylko ruch pochodzący z wystąpienia usługi Azure Front Door.

• Jeśli dodatkowe wymagania dotyczące zabezpieczeń sieci wbudowanej, takie jak głęboka inspekcja pakietów lub inspekcja protokołu TLS, należy zagwarantować użycie Azure Firewall Premium lub wirtualnego urządzenia sieciowego (WUS), upewnij się, że jest on skonfigurowany pod kątem maksymalnej wysokiej dostępności i nadmiarowości.

• Jeśli istnieją wymagania dotyczące przechwytywania pakietów, użyj pakietów Network Watcher do przechwytywania pomimo ograniczonego okna przechwytywania.

• Użyj sieciowych grup zabezpieczeń i grup zabezpieczeń aplikacji do mikro segmentowania ruchu aplikacji.

  • Unikaj używania urządzenia zabezpieczeń do filtrowania przepływów ruchu wewnątrz aplikacji.
  • Rozważ użycie Azure Policy, aby wymusić określone reguły sieciowej grupy zabezpieczeń są zawsze skojarzone z podsieciami aplikacji.

• Włącz dzienniki przepływu sieciowej grupy zabezpieczeń i przekaż je do analizy ruchu, aby uzyskać wgląd w przepływy ruchu wewnętrznego i zewnętrznego.

• Użyj Azure Private Link/prywatnych punktów końcowych, jeśli są dostępne, aby zabezpieczyć dostęp do usług PaaS platformy Azure w projekcie aplikacji. Aby uzyskać informacje na temat usług platformy Azure, które obsługują Private Link, zobacz Azure Private Link dostępność.

• Jeśli prywatny punkt końcowy nie jest dostępny, a ryzyko eksfiltracji danych jest dopuszczalne, użyj Virtual Network punktów końcowych usługi, aby zabezpieczyć dostęp do usług PaaS platformy Azure z poziomu sieci wirtualnej.

  • Nie włączaj punktów końcowych usługi sieci wirtualnej domyślnie we wszystkich podsieciach, ponieważ spowoduje to wprowadzenie znaczących kanałów eksfiltracji danych.

• W przypadku scenariuszy aplikacji hybrydowych uzyskaj dostęp do usług PaaS platformy Azure ze środowiska lokalnego za pośrednictwem usługi ExpressRoute z prywatną komunikacją równorzędną.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure należy pamiętać, że łączność sieciowa z lokalnymi centrami danych jest zapewniana przez implementację strefy docelowej. Jedną z metod jest użycie usługi ExpressRoute skonfigurowanej z prywatną komunikacją równorzędną.

Ochrona integralności danych

Szyfrowanie jest ważnym krokiem w kierunku zapewnienia integralności danych i ostatecznie jest jednym z najważniejszych funkcji zabezpieczeń, które można zastosować w celu ograniczenia szerokiej gamy zagrożeń. W tej sekcji przedstawiono kluczowe zagadnienia i zalecenia związane z szyfrowaniem i zarządzaniem kluczami w celu zabezpieczenia danych bez naruszania niezawodności aplikacji.

Zagadnienia dotyczące projektowania

• Usługa Azure Key Vault ma limity transakcji dla kluczy i wpisów tajnych z ograniczeniem przepustowości zastosowanym w magazynie w określonym okresie.

• Usługa Azure Key Vault zapewnia granicę zabezpieczeń, ponieważ uprawnienia dostępu do kluczy, wpisów tajnych i certyfikatów są stosowane na poziomie magazynu.

  • Key Vault przypisania zasad dostępu przyznają uprawnienia oddzielnie kluczom, wpisom tajnym lub certyfikatom.
    • Szczegółowe uprawnienia na poziomie obiektu do określonego klucza, wpisu tajnego lub certyfikatu są teraz możliwe.

• Po zmianie przypisania roli istnieje opóźnienie do 10 minut (600 sekund) dla roli do zastosowania.

  • Istnieje limit 2000 przypisań ról platformy Azure na subskrypcję.

• Usługa Azure Key Vault podstawowych sprzętowych modułów zabezpieczeń (HSM) ma walidację ze standardem FIPS 140.

  • Dedykowany zarządzany moduł HSM platformy Azure Key Vault jest dostępny w scenariuszach wymagających zgodności ze standardem FIPS 140-2 poziom 3.

• Usługa Azure Key Vault zapewnia wysoką dostępność i nadmiarowość w celu zapewnienia dostępności i zapobiegania utracie danych.

• Podczas pracy w trybie failover w regionie może upłynąć kilka minut, aby usługa Key Vault mogła przejść w tryb failover.

  • Podczas pracy w trybie failover Key Vault będzie w trybie tylko do odczytu, więc nie będzie możliwe zmienianie właściwości magazynu kluczy, takich jak konfiguracje zapory i ustawienia.

• Jeśli łącze prywatne jest używane do nawiązywania połączenia z usługą Azure Key Vault, może upłynąć do 20 minut, aby połączenie zostało ponownie nawiązane podczas regionalnego przejścia w tryb failover.

• Kopia zapasowa tworzy migawkę wpisu tajnego, klucza lub certyfikatu jako zaszyfrowanego obiektu blob, którego nie można odszyfrować poza platformą Azure. Aby uzyskać dane użyteczne z obiektu blob, należy je przywrócić do Key Vault w ramach tej samej subskrypcji platformy Azure i lokalizacji geograficznej platformy Azure.

  • Wpisy tajne mogą być odnawiane podczas tworzenia kopii zapasowej, co powoduje niezgodność.

• W przypadku kluczy zarządzanych przez usługę platforma Azure będzie wykonywać funkcje zarządzania kluczami, takie jak rotacja, co zmniejsza zakres operacji aplikacji.

• Mechanizmy kontroli regulacyjnej mogą określać korzystanie z kluczy zarządzanych przez klienta na potrzeby funkcji szyfrowania usług.

• W przypadku ruchu między centrami danych platformy Azure szyfrowanie warstwy łącza danych MACsec jest używane na podstawowym sprzęcie sieciowym w celu zabezpieczenia danych przesyłanych poza granicami fizycznymi, które nie są kontrolowane przez firmę Microsoft ani w imieniu firmy Microsoft.

Zalecenia dotyczące projektowania

• Użyj kluczy zarządzanych przez usługę do ochrony danych, jeśli to możliwe, usuwając konieczność zarządzania kluczami szyfrowania i obsługi zadań operacyjnych, takich jak rotacja kluczy.

  • Używaj kluczy zarządzanych przez klienta tylko wtedy, gdy istnieje jasne wymaganie prawne.

• Użyj usługi Azure Key Vault jako bezpiecznego repozytorium dla wszystkich wpisów tajnych, certyfikatów i kluczy, jeśli należy rozważyć dodatkowe mechanizmy szyfrowania lub klucze zarządzane przez klienta.

  • Aprowizuj usługę Azure Key Vault za pomocą zasad usuwania nietrwałego i przeczyszczania, aby umożliwić ochronę przechowywania usuniętych obiektów.
  • Użyj jednostki SKU platformy Azure Key Vault obsługiwanej przez moduł HSM dla środowisk produkcyjnych aplikacji.

• Wdróż oddzielne wystąpienie usługi Azure Key Vault w ramach każdego regionalnego sygnatury wdrażania, zapewniając izolację błędów i korzyści z wydajności dzięki lokalizacji, a także nawigowanie po limitach skalowania narzuconych przez pojedyncze wystąpienie Key Vault.

  • Użyj dedykowanego wystąpienia usługi Azure Key Vault dla zasobów globalnych aplikacji.

• Postępuj zgodnie z modelem najniższych uprawnień, ograniczając autoryzację do trwałego usuwania wpisów tajnych, kluczy i certyfikatów do wyspecjalizowanych ról niestandardowych Microsoft Entra.

• Upewnij się, że kopie zapasowe kluczy szyfrowania i certyfikatów przechowywanych w Key Vault są tworzone, zapewniając kopię w trybie offline w mało prawdopodobnym przypadku, Key Vault staje się niedostępna.

• Użyj certyfikatów Key Vault do zarządzania zakupami certyfikatów i podpisywaniem.

• Ustanów zautomatyzowany proces rotacji kluczy i certyfikatów.

  • Automatyzowanie procesu zarządzania certyfikatami i odnawiania za pomocą publicznych urzędów certyfikacji w celu ułatwienia administrowania.
    • Ustaw alerty i powiadomienia, aby uzupełnić automatyczne odnawianie certyfikatów.

• Monitorowanie użycia klucza, certyfikatu i wpisu tajnego.

  • Zdefiniuj alerty dotyczące nieoczekiwanego użycia w usłudze Azure Monitor.

Utrzymywanie ładu dzięki zasadom

Konwencje zabezpieczeń są ostatecznie skuteczne tylko wtedy, gdy są spójne i całościowo wymuszane we wszystkich usługach i zespołach aplikacji. Azure Policy zapewnia strukturę wymuszania punktów odniesienia zabezpieczeń i niezawodności, zapewniając ciągłą zgodność z typowymi kryteriami inżynieryjnymi dla aplikacji o znaczeniu krytycznym. Dokładniej mówiąc, Azure Policy stanowi kluczową część płaszczyzny sterowania usługi Azure Resource Manager (ARM), uzupełniając kontrolę dostępu opartą na rolach przez ograniczenie akcji, które mogą wykonywać autoryzowani użytkownicy, i może służyć do wymuszania ważnych konwencji zabezpieczeń i niezawodności w ramach używanych usług platformy.

W tej sekcji zapoznasz się z kluczowymi zagadnieniami i zaleceniami dotyczącymi używania ładu opartego na Azure Policy dla aplikacji o krytycznym znaczeniu, dzięki czemu konwencje zabezpieczeń i niezawodności są stale wymuszane.

Zagadnienia dotyczące projektowania

• Azure Policy zapewnia mechanizm zapewniania zgodności przez wymuszanie konwencji zabezpieczeń i niezawodności, takich jak korzystanie z prywatnych punktów końcowych lub korzystanie z Strefy dostępności.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure należy pamiętać, że wymuszanie scentralizowanych przypisań zasad odniesienia prawdopodobnie zostanie zastosowane w implementacji dla grup zarządzania strefami docelowymi i subskrypcji.

• Azure Policy może służyć do napędzania zautomatyzowanych działań zarządzania, takich jak aprowizowanie i konfiguracja.

  • Rejestracja dostawcy zasobów.
  • Walidacja i zatwierdzanie poszczególnych konfiguracji zasobów platformy Azure.

• Azure Policy zakres przypisania określa pokrycie, a lokalizacja definicji Azure Policy informuje o ponownym użyciu zasad niestandardowych.

• Azure Policy ma kilka limitów, takich jak liczba definicji w określonym zakresie.

• Wykonanie zasad Deploy If Not Exist (DINE) może potrwać kilka minut.

• Azure Policy zapewnia krytyczne dane wejściowe do raportowania zgodności i inspekcji zabezpieczeń.

Zalecenia dotyczące projektowania

• Mapuj wymagania dotyczące przepisów i zgodności na definicje Azure Policy.

  • Jeśli na przykład istnieją wymagania dotyczące przechowywania danych, należy zastosować zasady w celu ograniczenia dostępnych regionów wdrażania.

• Zdefiniuj typowe kryteria inżynieryjne służące do przechwytywania bezpiecznych i niezawodnych definicji konfiguracji dla wszystkich używanych usług platformy Azure, zapewniając, że te kryteria są mapowane na Azure Policy przypisania w celu wymuszania zgodności.

  • Na przykład zastosuj Azure Policy, aby wymusić użycie Strefy dostępności dla wszystkich odpowiednich usług, zapewniając niezawodne konfiguracje wdrożenia wewnątrz regionu.

Implementacja referencyjna o znaczeniu krytycznym zawiera szeroką gamę zasad skoncentrowanych na zabezpieczeniach i niezawodności w celu zdefiniowania i wymuszania przykładowych typowych kryteriów inżynieryjnych.

• Monitorowanie dryfu konfiguracji usługi względem typowych kryteriów inżynierii przy użyciu Azure Policy.

W przypadku scenariuszy o znaczeniu krytycznym dla wielu subskrypcji produkcyjnych w ramach dedykowanej grupy zarządzania należy określić priorytety przypisań w zakresie grupy zarządzania.

• Używaj wbudowanych zasad, jeśli to możliwe, aby zminimalizować nakłady operacyjne związane z utrzymywaniem niestandardowych definicji zasad.

• Jeśli definicje zasad niestandardowych są wymagane, upewnij się, że definicje są wdrażane w odpowiednim zakresie grupy zarządzania, aby umożliwić ponowne użycie w ramach obejmujących subskrypcji środowiska, aby umożliwić ponowne użycie zasad w środowiskach produkcyjnych i niższych.

  • Podczas dopasowywania planu działania aplikacji do planów działania platformy Azure użyj dostępnych zasobów firmy Microsoft, aby dowiedzieć się, czy krytyczne definicje niestandardowe mogą być włączone jako wbudowane definicje.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure rozważ wdrożenie niestandardowych definicji Azure Policy w zakresie pośredniej głównej grupy zarządzania firmy, aby umożliwić ponowne użycie wszystkich aplikacji w szerszej infrastrukturze platformy Azure. W środowisku strefy docelowej niektóre scentralizowane zasady zabezpieczeń zostaną domyślnie zastosowane w wyższych zakresach grupy zarządzania w celu wymuszania zgodności zabezpieczeń w całej infrastrukturze platformy Azure. Na przykład zasady platformy Azure powinny być stosowane do automatycznego wdrażania konfiguracji oprogramowania za pomocą rozszerzeń maszyn wirtualnych i wymuszania zgodnej konfiguracji podstawowej maszyny wirtualnej.

• Użyj Azure Policy, aby wymusić spójny schemat tagowania w aplikacji.
  • Zidentyfikuj wymagane tagi platformy Azure i użyj trybu zasad dołączania, aby wymusić użycie.

Jeśli aplikacja jest subskrybowana do pomocy technicznej firmy Microsoft Mission-Critical, upewnij się, że zastosowany schemat tagowania zapewnia znaczący kontekst, aby wzbogacić środowisko pomocy technicznej o głębokie zrozumienie aplikacji.

• Eksportuj dzienniki aktywności Microsoft Entra do globalnego obszaru roboczego usługi Log Analytics używanego przez aplikację.
  • Upewnij się, że dzienniki aktywności platformy Azure są archiwizowane w ramach globalnego konta magazynu wraz z danymi operacyjnymi na potrzeby długoterminowego przechowywania.

W strefie docelowej platformy Azure dzienniki aktywności Microsoft Entra zostaną również pozyskane do scentralizowanego obszaru roboczego usługi Log Analytics platformy. Należy ją ocenić w tym przypadku, jeśli Tożsamość Microsoft Entra są nadal wymagane w globalnym obszarze roboczym usługi Log Analytics.

• Integrowanie zarządzania informacjami i zdarzeniami zabezpieczeń za pomocą Microsoft Defender for Cloud (wcześniej znanej jako Azure Security Center).

Zagadnienia specyficzne dla IaaS podczas korzystania z Virtual Machines

W scenariuszach, w których wymagane jest użycie Virtual Machines IaaS, należy wziąć pod uwagę pewne szczegóły.

Zagadnienia dotyczące projektowania

• Obrazy nie są aktualizowane automatycznie po wdrożeniu.
• Aktualizacje nie są instalowane automatycznie do uruchamiania maszyn wirtualnych.
• Obrazy i poszczególne maszyny wirtualne zwykle nie są wzmacniane poza urządzeniem.

Zalecenia dotyczące projektowania

• Nie zezwalaj na bezpośredni dostęp za pośrednictwem publicznego Internetu, aby Virtual Machines, zapewniając dostęp do protokołów SSH, RDP lub innych. Zawsze używaj usługi Azure Bastion i serwerów przesiadkowych z ograniczonym dostępem do małej grupy użytkowników.
• Ogranicz bezpośrednią łączność z Internetem przy użyciu sieciowych grup zabezpieczeń, zapory platformy Azure lub bram aplikacji (poziom 7), aby filtrować i ograniczać ruch wychodzący.
• W przypadku aplikacji wielowarstwowych należy rozważyć użycie różnych podsieci i użyć sieciowych grup zabezpieczeń w celu ograniczenia dostępu między nimi.
• Określanie priorytetów użycia uwierzytelniania za pomocą klucza publicznego, jeśli jest to możliwe. Przechowywanie wpisów tajnych w bezpiecznym miejscu, na przykład azure Key Vault.
• Ochrona maszyn wirtualnych przy użyciu uwierzytelniania i kontroli dostępu.
• Zastosuj te same praktyki zabezpieczeń, jak opisano w scenariuszach aplikacji o znaczeniu krytycznym.

Postępuj zgodnie z powyższym opisem i zastosuj rozwiązania zabezpieczeń dla scenariuszy aplikacji o znaczeniu krytycznym, jak opisano powyżej, a także najlepsze rozwiązania dotyczące zabezpieczeń obciążeń IaaS na platformie Azure.

Następny krok

Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi procedur operacyjnych dla scenariuszy aplikacji o znaczeniu krytycznym.

Procedury operacyjne