Konfigurowanie sieci klastra regulowanego usługi AKS dla standardu PCI-DSS 3.2.1 (część 3 z 9)

W tym artykule opisano zagadnienia dotyczące sieci klastra usługi Azure Kubernetes Service (AKS), który jest skonfigurowany zgodnie ze standardem Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

Ten artykuł jest częścią serii. Przeczytaj wprowadzenie.

Głównym tematem standardu PCI-DSS 3.2.1 jest bezpieczeństwo. Topologia piasty i szprych jest naturalnym wyborem do konfigurowania środowiska regulowanego. Łatwiej jest utworzyć infrastrukturę, która umożliwia bezpieczną komunikację. Kontrolki sieci są umieszczane w sieciach piasty i szprych i są zgodne z modelem zerowym zaufania firmy Microsoft. Kontrolki można dostroić z najniższymi uprawnieniami, aby zabezpieczyć ruch, zapewniając dostęp na podstawie potrzeb. Ponadto można zastosować kilka metod ochrony w głębi systemu, dodając kontrolki na każdym przeskoku sieciowym.

Jeśli hostujesz obciążenie na platformie Kubernetes, nie wystarczy polegać na tradycyjnych konstrukcjach sieci, takich jak reguły zapory. Istnieją również konstrukcje natywne platformy Kubernetes, które kontrolują przepływ ruchu w klastrze NetworkPolicy , takie jak zasób. Zdecydowanie zalecamy zapoznanie się z dokumentacją platformy Kubernetes, aby zrozumieć podstawowe pojęcia dotyczące izolowanych zasobników oraz zasad ruchu przychodzącego i wychodzącego.

Tworzenie i utrzymywanie bezpiecznej sieci i systemów

Wymaganie 1 — instalowanie i utrzymywanie konfiguracji zapory w celu ochrony danych posiadaczy kart.

Obsługa funkcji usługi AKS

Usługa AKS obsługuje wdrażanie klastra w prywatnej sieci wirtualnej jako klaster prywatny. Komunikacja między klastrem a serwerem interfejsu API Kubernetes zarządzanym przez usługę AKS odbywa się za pośrednictwem zaufanej sieci. Za pomocą klastra prywatnego można użyć usługi Azure Virtual Network, sieciowej grupy zabezpieczeń i innych wbudowanych mechanizmów kontroli sieci w celu zabezpieczenia całego środowiska danych karty (CDE). Uniemożliwi to nieautoryzowany dostęp publiczny między Internetem a środowiskiem. Aby uzyskać szczegółowe informacje na temat aprowizacji takiego klastra, zobacz Tworzenie prywatnego klastra usługi Azure Kubernetes Service.

Usługę Azure Firewall można zintegrować z usługą AKS i ograniczyć ruch wychodzący z klastra, który jest kluczowym składnikiem usługi CDE. Konfiguracja jest łatwa dzięki tagowi FQDN usługi AKS. Zalecany proces znajduje się w artykule Używanie usługi Azure Firewall do ochrony wdrożeń usługi Azure Kubernetes Service (AKS).

Klastry AKS wymagają publicznego dostępu do Internetu. Ogranicz ruch wychodzący do Internetu przy użyciu usługi Azure Firewall i sieciowych grup zabezpieczeń w podsieci klastra. Aby uzyskać informacje, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w usłudze Azure Kubernetes Service (AKS).

Usługa AKS opcjonalnie obsługuje możliwość definiowania serwera proxy HTTP, który może być używany do dodatkowej kontroli ruchu wychodzącego i monitorowania klastra. Węzły klastra używają określonej konfiguracji serwera proxy HTTP do routingu ruchu wychodzącego. Ponadto zarejestrowano element MutatingWebhook w celu wstrzyknięcia informacji o serwerze proxy do zasobników w czasie tworzenia, dlatego zaleca się, aby obciążenia mogły dziedziczyć te same informacje o serwerze proxy. Zasobniki mogą zastępować informacje o serwerze proxy, dlatego zaleca się używanie serwera proxy HTTP oprócz usługi Azure Firewall.

Klastry usługi AKS należy utworzyć za pomocą wtyczki NetworkPolicy. W usłudze AKS masz opcję między platformą Azure lub Calico jako wtyczką zasad sieciowych. W przypadku zasad sieci Calico można użyć rozwiązania Kubenet lub Azure CNI. W przypadku usługi Azure Network Policy można używać tylko usługi Azure CNI (a nie Kubenet). Zasady sieciowe dla węzłów systemu Windows są obsługiwane tylko w przypadku calico. Wtyczki usługi Azure i Calico Network Policy są typu open source. Aby uzyskać więcej informacji na temat programu Project Calico, zobacz oficjalny dokument dotyczący kompleksowego rozwiązania PCI, który spełnia wiele poniższych wymagań dotyczących zapory.

Twoje obowiązki

Wymaganie	Odpowiedzialność
Wymaganie 1.1	Ustanów i zaimplementuj standardy konfiguracji zapory i routera.
Wymaganie 1.2	Twórz konfiguracje zapory i routera, które ograniczają połączenia między niezaufanych sieci i wszystkimi składnikami systemowymi w środowisku danych posiadacza kart.
Wymaganie 1.3	Zakaz bezpośredniego dostępu publicznego między Internetem a dowolnym składnikiem systemu w środowisku danych posiadaczy kart.
Wymaganie 1.4	Zainstaluj osobiste oprogramowanie zapory lub równoważne funkcje na dowolnych przenośnych urządzeniach obliczeniowych (w tym firmowych i/lub należących do pracowników), które łączą się z Internetem, gdy znajdują się poza siecią (na przykład laptopy używane przez pracowników), a które są również używane do uzyskiwania dostępu do usługi CDE.
Wymaganie 1.5	Upewnij się, że zasady zabezpieczeń i procedury operacyjne dotyczące zarządzania zaporami są udokumentowane, używane i znane wszystkim stronom, których dotyczy problem.

Wymaganie 1.1

Ustanów i zaimplementuj standardy konfiguracji zapory i routera, które obejmują następujące elementy:

Wymaganie 1.1.1

Formalny proces zatwierdzania i testowania wszystkich połączeń sieciowych oraz zmian konfiguracji zapory i routera.

Twoje obowiązki

Nie implementuj konfiguracji ręcznie, na przykład przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure bezpośrednio. Zalecamy używanie infrastruktury jako kodu (IaC). W przypadku IaC infrastruktura jest zarządzana za pomocą modelu opisowego, który korzysta z systemu przechowywania wersji. Model IaC generuje to samo środowisko za każdym razem, gdy jest stosowany. Typowe przykłady IaC to Azure Resource Manager lub Terraform. Jeśli usługa IaC nie jest opcją, należy dysponować dobrze udokumentowanym procesem śledzenia, implementowania i bezpiecznego wdrażania zmian reguły zapory. Więcej szczegółów znajduje się w części Wymagania 11.2.

Należy użyć kombinacji różnych mechanizmów kontroli sieci, w tym usługi Azure Firewall, sieciowych grup zabezpieczeń i zasobu Kubernetes NetworkPolicy .

Zminimalizuj liczbę osób, które mogą uzyskiwać dostęp do kontrolek sieci i modyfikować je. Zdefiniuj role i jasne obowiązki zespołów. Na przykład zespół ds. sieci organizacji zweryfikuje zmiany zgodnie z zasadami ładu ustawionymi przez zespoły IT. Mieć kontrolowany proces zatwierdzania, który obejmuje osoby i procesy w celu zatwierdzenia zmian w dowolnej konfiguracji sieci. Proces powinien zawierać krok testowania wszystkich kontrolek sieciowych. Zawierają szczegółową dokumentację opisjącą proces.

Wymaganie 1.1.2

Bieżący diagram sieciowy, który identyfikuje wszystkie połączenia między środowiskiem danych karty a innymi sieciami, w tym sieciami bezprzewodowymi

Twoje obowiązki

W ramach dokumentacji zachowaj diagram przepływu sieci, który pokazuje ruch przychodzący i wychodzący z mechanizmami kontroli zabezpieczeń. Obejmuje to przepływ ruchu z innych sieci, w tym dowolną sieć bezprzewodową do sieci CDE. Diagram powinien również przedstawiać przepływy w klastrze. Istnieją pewne specyficzne wymagania dotyczące diagramów. Powinny one pokazywać czujniki włamań. Kontrolki dla

Ten obraz przedstawia diagram sieciowy implementacji referencyjnej.

Pobierz plik programu Visio z tego diagramu.

Rysunek 1.1.2 — Przepływ sieci

Opis tego przepływu znajduje się w poniższych sekcjach.

Jeśli masz usługę Azure Network Watcher, możesz wyświetlić topologię sieci wirtualnej platformy Azure. Wszystkie zasoby można wyświetlić w sieci wirtualnej, zasoby skojarzone z zasobami w sieci wirtualnej oraz relacje między zasobami.

Wymaganie 1.1.3

Bieżący diagram przedstawiający wszystkie przepływy danych karty w systemach i sieciach.

Twoje obowiązki

W ramach dokumentacji dołącz diagram przepływu danych przedstawiający sposób ochrony danych magazynowanych i przesyłanych danych.

Diagram powinien przedstawiać przepływ danych do i z obciążenia oraz informacje przekazywane z jednego zasobu do innego. Upewnij się, że diagram jest aktualny. Dodaj krok w ramach procesu zarządzania zmianami, aby zaktualizować diagram przepływu danych.

Ponieważ ta architektura koncentruje się na infrastrukturze, a nie na obciążeniu, pominięto tutaj ilustracje.

Wymaganie 1.1.4

Wymagania dotyczące zapory w każdym połączeniu internetowym i między dowolną strefą zdemilitaryzowaną (DMZ) i wewnętrzną strefą sieciową.

Twoje obowiązki

Masz wyraźną definicję tego, co definiuje granicę strefy DMZ. Na przykład środowisko danych karty (CDE) znajduje się w strefie DMZ zabezpieczonej przez zaporę, zasady sieciowe i inne kontrolki. Aby uzyskać więcej informacji, zobacz Cloud DMZ.

W przypadku infrastruktury PCI DSS odpowiadasz za zabezpieczenie usługi CDE przy użyciu mechanizmów kontroli sieci w celu blokowania nieautoryzowanego dostępu do sieci i z sieci za pomocą usługi CDE. Należy prawidłowo skonfigurować mechanizmy kontroli sieci pod kątem silnego stanu zabezpieczeń i należy je zastosować do:

• Komunikacja między składnikami kolokowanym w klastrze.
• Komunikacja między obciążeniem a innymi składnikami w zaufanych sieciach.
• Komunikacja między obciążeniem a publicznym Internetem.

Ta architektura używa różnych technologii zapory do inspekcji ruchu przepływającego w obu kierunkach do i z klastra, który hostuje usługę CDE:

• Aplikacja systemu Azure Gateway zintegrowana zapora aplikacji internetowej (WAF) jest używana jako router ruchu i do zabezpieczania ruchu przychodzącego (przychodzącego) do klastra.

• Usługa Azure Firewall służy do zabezpieczania całego ruchu wychodzącego (wychodzącego) z dowolnej sieci i jej podsieci.

  W ramach przetwarzania operacji transakcji lub zarządzania klaster będzie musiał komunikować się z jednostkami zewnętrznymi. Na przykład klaster może wymagać komunikacji z płaszczyzną sterowania usługi AKS, uzyskaniem aktualizacji systemu Windows i pakietem oraz interakcją obciążenia z zewnętrznymi interfejsami API. Niektóre z tych interakcji mogą być za pośrednictwem protokołu HTTP i powinny być traktowane jako wektory ataków. Te wektory są celami ataku typu man-in-the-middle, który może spowodować eksfiltrację danych. Dodanie zapory do ruchu wychodzącego ogranicza to zagrożenie.

  Zalecamy, aby nawet komunikacja między zasobnikami jest szyfrowana przy użyciu protokołu TLS. Ta praktyka jest pokazana w implementacji referencyjnej z użyciem siatki mTLS.

• Sieciowe grupy zabezpieczeń są dodawane do zabezpieczania ruchu między klastrem a innymi składnikami w infrastrukturze. Na przykład w implementacji referencyjnej istnieją sieciowe grupy zabezpieczeń w podsieci z pulami węzłów, które blokują wszelkie próby dostępu SSH. Dozwolony jest tylko ruch z sieci wirtualnej.

  Podczas dodawania składników do architektury rozważ dodanie większej liczby sieciowych grup zabezpieczeń, które zezwalają na typy ruchu lub odmawiają ich na granicach podsieci. Ponieważ każda pula węzłów znajduje się w dedykowanej podsieci, zastosuj bardziej szczegółowe reguły na podstawie oczekiwanych wzorców ruchu obciążenia.

• Kubernetes NetworkPolicy

  Domyślnie nie ma żadnych ograniczeń dotyczących komunikacji między zasobnikami. Należy zastosować komunikację NetworkPolicy w klastrze, zaczynając od sieci zerowej zaufania i otwierając ścieżki zgodnie z potrzebami. Implementacja referencyjna demonstruje sieci zerowe zaufania w a0005-i przestrzeniach nazw i a0005-o . Wszystkie przestrzenie nazw (z wyjątkiem kube-system, gatekeeper-systemi innych przestrzeni nazw udostępnianych przez usługę AKS) mają zastosowanie restrykcyjne NetworkPolicy . Definicja zasad zależy od zasobników uruchomionych w tych przestrzeniach nazw. Upewnij się, że otwierasz ścieżki do gotowości, linii na żywo i sond startowych. Ponadto otwórz ścieżkę do oms-agent , aby można było wysłać metryki na poziomie węzła. Rozważ standaryzację portów między obciążeniami, aby zapewnić spójny i usługę NetworkPolicy Azure Policy dla dozwolonych portów kontenerów.

Wymaganie 1.1.5

Opis grup, ról i obowiązków związanych z zarządzaniem składnikami sieci.

Twoje obowiązki

Należy podać kontrolki przepływów sieciowych i składników. Uzyskana infrastruktura będzie miała kilka segmentów sieci, z których każda ma wiele kontrolek, a każda kontrolka ma cel. Upewnij się, że dokumentacja nie tylko ma zakres zasięgu od planowania sieci do wszystkich konfiguracji, ale także zawiera szczegóły dotyczące własności. Mają jasne linie odpowiedzialności i role, które są za nie odpowiedzialne.

Na przykład dowiedz się, kto jest odpowiedzialny za zapewnienie ładu w zakresie zabezpieczania sieci między platformą Azure i Internetem. W przedsiębiorstwie zespół IT jest odpowiedzialny za konfigurację i konserwację reguł usługi Azure Firewall, zapory aplikacji internetowej ,sieciowych grup zabezpieczeń i innego ruchu między sieciami. Mogą one być również odpowiedzialne za sieć wirtualną i alokację podsieci w całej przedsiębiorstwie oraz planowanie adresów IP.

Na poziomie obciążenia operator klastra jest odpowiedzialny za utrzymanie zerowego zaufania za pośrednictwem zasad sieciowych. Ponadto obowiązki mogą obejmować komunikację z płaszczyzną sterowania platformy Azure, interfejsami API kubernetes i technologiami monitorowania.

Zawsze zacznij od strategii odmów wszystkich. Nadaj uprawnienia tylko wtedy, gdy istnieje potrzeba biznesowa lub uzasadnienie roli.

Wymaganie 1.1.6

Dokumentacja uzasadnienia biznesowego i zatwierdzenia do korzystania ze wszystkich dozwolonych usług, protokołów i portów, łącznie z dokumentacją funkcji zabezpieczeń zaimplementowanych dla tych protokołów uważanych za niezabezpieczone.

Twoje obowiązki

Szczegółowa dokumentacja opisując usługi, protokoły i porty używane w kontrolkach sieci. Odmów wszystkim z wyjątkiem jawnie dozwolonych portów. Dokumentowanie uzasadnienia biznesowego i udokumentowanych funkcji zabezpieczeń, jeśli nie można uniknąć używania niezabezpieczonych protokołów. Poniżej przedstawiono kilka przykładów z implementacji referencyjnej usługi Azure Firewall. Reguły zapory muszą być ograniczone wyłącznie do powiązanych zasobów. Oznacza to, że tylko ruch z określonych źródeł może być kierowany do określonych miejsc docelowych nazw FQDN. Oto kilka przypadków zezwalania na ruch.

Reguła	Protokół:port	Element źródłowy	Element docelowy	Justowanie
Zezwalaj na bezpieczną komunikację między węzłami a płaszczyzną sterowania.	HTTPS:443	Autoryzowane zakresy adresów IP przypisane do pul węzłów klastra	Lista obiektów docelowych FQDN na płaszczyźnie sterowania usługi AKS. Jest on określony za pomocą tagu AzureKubernetesService FQDN.	Węzły muszą mieć dostęp do płaszczyzny sterowania na potrzeby narzędzi do zarządzania, informacji o stanie i konfiguracji oraz informacji o tym, które węzły można skalować.
Zezwalaj na bezpieczną komunikację między platformą Flux i usługą GitHub.	HTTPS:443	Pule węzłów usługi AKS	github.com, api.github.com	Flux to integracja innej firmy, która działa na węzłach. Synchronizuje konfigurację klastra z prywatnym repozytorium GitHub.

Wymaganie 1.1.7

Wymaganie przeglądu reguł zapory i routera ustawia co najmniej co sześć miesięcy.

Twoje obowiązki

Mają procesy co najmniej co sześć miesięcy, aby przejrzeć konfiguracje sieci i reguły o określonym zakresie. Zapewni to, że zabezpieczenia są aktualne i prawidłowe. Upewnij się, że zapoznasz się z tymi konfiguracjami:

• Reguły usługi Azure Firewall.
• Reguły sieciowej grupy zabezpieczeń.
• aplikacja systemu Azure bramy i reguł zapory aplikacji internetowej.
• Natywne zasady sieciowe platformy Kubernetes.
• Kontrolki zapory dla odpowiednich zasobów platformy Azure. Na przykład ta architektura używa reguły w usłudze Azure Container Registry, która zezwala tylko na ruch z prywatnego punktu końcowego.
• Wszystkie inne kontrolki sieciowe dodane do architektury.

Wymaganie 1.2

Twórz konfiguracje zapory i routera, które ograniczają połączenia między niezaufanych sieci i wszystkimi składnikami systemowymi w środowisku danych posiadacza kart.

Twoje obowiązki

W tej architekturze klaster usługi AKS jest kluczowym składnikiem środowiska danych karty (CDE). Zdecydowanie zalecamy wdrożenie klastra jako klastra prywatnego w celu zapewnienia zwiększonych zabezpieczeń. W klastrze prywatnym ruch sieciowy między serwerem interfejsu API Kubernetes zarządzanym przez usługę AKS a pulami węzłów jest prywatny. Serwer interfejsu API jest uwidaczniony za pośrednictwem prywatnego punktu końcowego w sieci klastra.

Można również wybrać klaster publiczny, ale ten projekt nie jest zalecany w przypadku klastrów zawierających obciążenia regulowane. Serwer interfejsu API zostanie uwidoczniony w Internecie. Rekord DNS zawsze będzie można odnaleźć. Dlatego musisz mieć kontrolki, aby interfejs API klastra był chroniony przed dostępem publicznym. Jeśli jest wymagany klaster publiczny, zalecane jest posiadanie ścisłej kontroli za pośrednictwem kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes w połączeniu z funkcją zakresów autoryzowanych adresów IP usługi AKS, aby ograniczyć, kto może uzyskać dostęp do serwera interfejsu API usługi AKS. Jednak to rozwiązanie nie jest zalecane w przypadku klastrów zawierających obciążenia regulowane.

Podczas przetwarzania danych posiadacza karty (CHD) klaster musi wchodzić w interakcje z sieciami, które są uważane za zaufane i niezaufane. W tej architekturze obie sieci piasty i szprych w obwodzie obciążenia PCI-DSS 3.2.1 są uważane za zaufane sieci.

Niezaufane sieci to sieci poza tym obwodem. Ta kategoria obejmuje inne koncentratory i szprychy, które mogą znajdować się w tej samej infrastrukturze, ale znajdują się poza obwodem obciążenia, publicznym Internetem, siecią firmową lub sieciami wirtualnymi na platformie Azure lub innej platformie w chmurze. W tej architekturze sieć wirtualna, która hostuje konstruktora obrazów, jest niezaufany, ponieważ nie ma części do odegrania w obsłudze CHD. Interakcja cdE z takimi sieciami powinna być zabezpieczona zgodnie z wymaganiami. Dzięki temu klastrowi prywatnemu można użyć usługi Azure Virtual Network, sieciowej grupy zabezpieczeń i innych wbudowanych funkcji w celu zabezpieczenia całego środowiska.

Aby uzyskać informacje o klastrach prywatnych, zobacz Tworzenie prywatnego klastra usługi Azure Kubernetes Service.

Wymaganie 1.2.1

Ogranicz ruch przychodzący i wychodzący do tego, co jest niezbędne dla środowiska danych posiadaczy kart, a w szczególności odmów całego innego ruchu.

Twoje obowiązki

Zgodnie z projektem usługa Azure Virtual Network nie może być bezpośrednio osiągnięta przez publiczny Internet. Cały ruch przychodzący (lub przychodzący) musi przechodzić przez router ruchu pośredniego. Jednak wszystkie składniki w sieci mogą uzyskiwać dostęp do publicznych punktów końcowych. Ruch wychodzący (lub wychodzący) musi być jawnie zabezpieczony, zezwalając tylko na bezpieczne szyfrowanie i protokół TLS 1.2 lub nowszy.

• aplikacja systemu Azure zintegrowana zapora aplikacji internetowej bramy przechwytuje cały ruch przychodzący HTTP(S) i kieruje inspekcję ruchu do klastra.

  Ten ruch może pochodzić z zaufanych lub niezaufanych sieci. Usługa Application Gateway jest aprowizowana w podsieci sieci szprych i zabezpieczona przez sieciową grupę zabezpieczeń. W miarę przepływu ruchu reguły zapory aplikacji internetowej zezwalają na ruch lub go odrzucają i kierują ruch do skonfigurowanego zaplecza. Na przykład usługa Application Gateway chroni usługę CDE, odmawiając tego typu ruchu:

  • Cały ruch, który nie jest szyfrowany przy użyciu protokołu TLS.
  • Ruch poza zakresem portów na potrzeby komunikacji płaszczyzny sterowania z infrastruktury platformy Azure.
  • Sondy kondycji żądań wysyłanych przez jednostki inne niż wewnętrzny moduł równoważenia obciążenia w klastrze.

• Usługa Azure Firewall służy do zabezpieczania całego ruchu wychodzącego (wychodzącego) z zaufanych i niezaufanych sieci.

  Usługa Azure Firewall jest aprowizowana w podsieci sieci koncentratora. Aby wymusić usługę Azure Firewall jako pojedynczy punkt ruchu wychodzącego, trasy zdefiniowane przez użytkownika są używane w podsieciach, które mogą generować ruch wychodzący. Obejmuje to podsieci w niezaufanych sieciach, takich jak sieć wirtualna konstruktora obrazów. Po dotarciu do usługi Azure Firewall zastosowano kilka reguł o określonym zakresie, które zezwalają na ruch z określonych źródeł w celu przejścia do określonych miejsc docelowych.

  Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Firewall do ochrony wdrożeń usługi Azure Kubernetes Service (AKS).

• Opcjonalnie można użyć serwera proxy HTTP do monitorowania i zabezpieczania ruchu wychodzącego (wychodzącego) z klastra do zasobów zewnętrznych.

  Oprócz zapory niektóre organizacje mogą chcieć używać serwera proxy HTTP, aby mieć dodatkowe mechanizmy kontroli ruchu wychodzącego. Zalecamy, aby trasy zdefiniowane przez użytkownika nadal przechodziły do zapory i ograniczały ruch wychodzący, aby po prostu przejść do serwera proxy HTTP. W przypadku tej konfiguracji, jeśli zasobnik próbuje przesłonić serwer proxy, zapora nadal może blokować ruch wychodzący.

  Aby uzyskać więcej informacji, zobacz Obsługa serwera proxy HTTP w usłudze Azure Kubernetes Service.

Klaster może wymagać dostępu do innych usług za pośrednictwem publicznego Internetu. Jeśli używasz oprogramowania chroniącego przed złośliwym kodem innej firmy, konieczne będzie pobranie definicji wirusów z serwera za pośrednictwem publicznego Internetu.

Interakcje z punktami końcowymi innych usług platformy Azure są za pośrednictwem sieci szkieletowej platformy Azure. Na przykład w ramach regularnych operacji klaster będzie musiał pobrać certyfikaty z zarządzanego magazynu kluczy, ściągnąć obrazy z rejestru kontenerów itd. Upewnij się, że te interakcje są prywatne i bezpieczne przy użyciu usługi Azure Private Link.

Oprócz reguł zapory i sieci prywatnych przepływy sieciowej grupy zabezpieczeń są również zabezpieczone za pośrednictwem reguł. Oto kilka przykładów z tej architektury, w których usługa CDE jest chroniona przez odmawianie ruchu:

• Sieciowe grupy zabezpieczeń w podsieciach, które mają pule węzłów, odmawiają dostępu do węzłów za pomocą protokołu SSH. Mieć proces dostępu awaryjnego just in time przy zachowaniu zasady odmowy wszystkich.
• Sieciowa grupa zabezpieczeń w podsieci, która ma pole przesiadkowe do uruchamiania narzędzi do zarządzania, odrzuca cały ruch z wyjątkiem usługi Azure Bastion w sieci piasty.
• Sieciowe grupy zabezpieczeń w podsieciach, które mają prywatne punkty końcowe do usług Azure Key Vault i Azure Container Registry, odrzucają cały ruch z wyjątkiem wewnętrznego modułu równoważenia obciążenia i ruchu za pośrednictwem usługi Azure Private Link.

Wymaganie 1.2.2

Zabezpieczanie i synchronizowanie plików konfiguracji routera.

Twoje obowiązki

Mechanizm wykrywania różnicy między rzeczywistym wdrożonym stanem a żądanym stanem. Infrastruktura jako kod (IaC) jest doskonałym wyborem w tym celu. Na przykład szablony usługi Azure Resource Manager mają rekord żądanego stanu.

Zasoby wdrażania, takie jak szablony usługi ARM, muszą być kontrolowane przez źródło, aby mieć historię wszystkich zmian. Zbierz informacje z dzienników aktywności platformy Azure, dzienników potoku wdrażania i dzienników wdrażania platformy Azure. Te źródła pomogą Ci zachować ślad wdrożonych zasobów.

W klastrze kontrole sieciowe, takie jak zasady sieci kubernetes, powinny również postępować zgodnie z przepływem kontrolowanym przez źródło. W tej implementacji platforma Flux jest używana jako operator GitOps. Podczas synchronizowania konfiguracji klastra, takiej jak zasady sieciowe, historia usługi Git połączona z dziennikami flux i interfejsu API może być źródłem historii konfiguracji.

Wymaganie 1.2.3

Zainstaluj zapory obwodowe między wszystkimi sieciami bezprzewodowymi i środowiskiem danych posiadacza kart, a także skonfiguruj te zapory do odmowy lub, jeśli ruch jest niezbędny do celów biznesowych, zezwól tylko na autoryzowany ruch między środowiskiem bezprzewodowym a środowiskiem danych karty.

Twoje obowiązki

Węzły usługi AKS i pule węzłów nie mogą być dostępne z sieci bezprzewodowych. Ponadto żądania do serwera interfejsu API Kubernetes muszą zostać odrzucone. Dostęp do tych składników jest ograniczony do autoryzowanych i zabezpieczonych podsieci.

Ogólnie rzecz biorąc, ogranicz dostęp z ruchu lokalnego do sieci szprychy.

Wymaganie 1.3

Zakaz bezpośredniego dostępu publicznego między Internetem a dowolnym składnikiem systemu w środowisku danych posiadaczy kart.

Twoje obowiązki

Pule węzłów klastra usługi AKS działają w sieci wirtualnej i odizolowane od sieci publicznych, takich jak Internet. Zachowaj izolację, uniemożliwiając skojarzenie publicznych adresów IP z węzłami klastra i stosując reguły sieciowej grupy zabezpieczeń w podsieciach klastra, aby upewnić się, że ruch internetowy jest zablokowany. Aby uzyskać informacje o kontrolowanym dostępie, zobacz sekcję DMZ.

Klaster usługi AKS ma pule węzłów systemowych hostujących zasobniki systemu o krytycznym znaczeniu. Nawet w pulach węzłów użytkownika istnieją zasobniki, które uruchamiają inne usługi, które uczestniczą w operacjach klastra. Na przykład zasobniki mogą uruchamiać narzędzie Flux w celu zsynchronizowania konfiguracji klastra z repozytorium GitHub lub kontrolera ruchu przychodzącego w celu kierowania ruchu do zasobników obciążeń. Niezależnie od typu puli węzłów wszystkie węzły muszą być chronione.

Innym krytycznym składnikiem systemu jest serwer interfejsu API używany do wykonywania natywnych zadań kubernetes, takich jak utrzymywanie stanu klastra i konfiguracji. Zaletą korzystania z klastra prywatnego jest to, że punkt końcowy serwera interfejsu API nie jest domyślnie uwidoczniony. Aby uzyskać informacje o klastrach prywatnych, zobacz Tworzenie prywatnego klastra usługi Azure Kubernetes Service.

Interakcje z innymi punktami końcowymi muszą być również zabezpieczone. Jednym ze sposobów jest ograniczenie komunikacji za pośrednictwem sieci prywatnej. Na przykład klaster ściąga obrazy z usługi Azure Container Registry za pośrednictwem łącza prywatnego.

Wymaganie 1.3.1

Zaimplementuj strefę DMZ, aby ograniczyć ruch przychodzący tylko do składników systemowych, które zapewniają autoryzowane publicznie dostępne usługi, protokoły i porty.

Twoje obowiązki

Oto kilka najlepszych rozwiązań:

• Nie należy konfigurować publicznych adresów IP w węzłach puli węzłów.
• Użyj usługi Azure Policy, aby upewnić się, że platforma Kubernetes nie uwidacznia publicznego modułu równoważenia obciążenia. Ruch w klastrze musi być kierowany przez wewnętrzne moduły równoważenia obciążenia.
• Uwidaczniaj tylko wewnętrzne moduły równoważenia obciążenia do usługi aplikacja systemu Azure Gateway zintegrowanej z zaporą aplikacji internetowej.
• Wszystkie mechanizmy kontroli sieci powinny określać ograniczenia źródła, miejsca docelowego, portu i protokołu, jeśli ma to zastosowanie.
• Nie uwidaczniaj serwera interfejsu API w Internecie. Po uruchomieniu klastra w trybie prywatnym punkt końcowy nie jest uwidoczniony, a komunikacja między pulami węzłów a serwerem interfejsu API odbywa się za pośrednictwem sieci prywatnej.

Użytkownicy mogą zaimplementować sieć obwodową w celu ochrony klastrów usługi AKS. Aby uzyskać informacje, zobacz Cloud DMZ.

Wymaganie 1.3.2

Ogranicz przychodzący ruch internetowy do adresów IP w strefie DMZ.

Twoje obowiązki

W sieci klastra należy mieć sieciową grupę zabezpieczeń w podsieci z wewnętrznym modułem równoważenia obciążenia. Skonfiguruj reguły tak, aby akceptowały tylko ruch z podsieci, która ma bramę aplikacja systemu Azure zintegrowaną z zaporą aplikacji internetowej. W klastrze usługi AKS użyj rozwiązania Kubernetes NetworkPolicies , aby ograniczyć ruch przychodzący do zasobników.

Wymaganie 1.3.3

Zaimplementuj środki chroniące przed fałszowaniem, aby wykrywać i blokować sfałszowane źródłowe adresy IP przed wejściem do sieci.

Obowiązki platformy Azure

Platforma Azure implementuje filtrowanie sieci, aby zapobiec fałszowaniu ruchu i ograniczać ruch przychodzący i wychodzący do zaufanych składników platformy.

Wymaganie 1.3.4

Nie zezwalaj na nieautoryzowany ruch wychodzący ze środowiska danych karty do Internetu.

Twoje obowiązki

Poniżej przedstawiono sposoby blokowania nieautoryzowanego ruchu wychodzącego:

• Wymuszanie całego ruchu wychodzącego (wychodzącego) z klastra usługi AKS w celu przejścia przez usługę Azure Firewall przy użyciu tras zdefiniowanych przez użytkownika (UDR) we wszystkich podsieciach klastra. Obejmuje to podsieci z pulami węzłów systemu i użytkownika.
• Ogranicz ruch wychodzący, dodając sieciowe grupy zabezpieczeń w podsieciach z pulami węzłów.
• Użyj platformy Kubernetes NetworkPolicies , aby ograniczyć ruch wychodzący z zasobników.
• Użyj siatki usług do obsługi dodatkowych zasad. Jeśli na przykład zezwalasz tylko na ruch szyfrowany protokołem TLS między zasobnikami, serwer proxy usługi mesh może obsłużyć weryfikację protokołu TLS. W tym przykładzie pokazano w tej implementacji. Aplikacja Envoy jest wdrażana jako serwer proxy.
• Zapobiegaj dodawaniu publicznych adresów IP do sieci w ramach usługi CDE, chyba że jawnie autoryzowane przez podsieci, takie jak podsieci zapory.
• Oprócz usługi Azure Firewall użyj serwera proxy HTTP, aby ograniczyć ruch wychodzący (wychodzący) z klastra usługi AKS do Internetu.
• Usługa Private Link (AMPLS) usługi Azure Monitor umożliwia wysyłanie dzienników z usługi Container Insights za pośrednictwem bezpiecznego, prywatnego połączenia z usługą Azure Monitor. Omówienie wpływu włączania platformy AMPLS.

Aby uzyskać szczegółowe informacje, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w usłudze Azure Kubernetes Service (AKS).

Wymaganie 1.3.5

Zezwalaj tylko na połączenia "ustanowione" z siecią.

Obowiązki platformy Azure

Platforma Azure implementuje filtrowanie sieci, aby zapobiec fałszowaniu ruchu i ograniczać ruch przychodzący i wychodzący do zaufanych składników platformy. Sieć platformy Azure jest segregowana w celu oddzielenia ruchu klientów od ruchu związanego z zarządzaniem.

Wymaganie 1.3.6

Umieść składniki systemowe, które przechowują dane karty (takie jak baza danych) w wewnętrznej strefie sieciowej, oddzielone od strefy DMZ i innych niezaufanych sieci.

Twoje obowiązki

Uwidaczniaj systemy magazynowania tylko za pośrednictwem sieci prywatnej, na przykład za pomocą usługi Private Link. Ponadto ogranicz dostęp z podsieci puli węzłów, które tego wymagają. Zachowaj stan poza klastrem i we własnej dedykowanej strefie zabezpieczeń.

Wymaganie 1.3.7

Nie ujawniaj prywatnych adresów IP i informacji o routingu do nieautoryzowanych stron.

Twoje obowiązki

Aby spełnić to wymaganie, publiczny klaster usługi AKS nie jest opcją. Klaster prywatny przechowuje rekordy DNS poza publicznym Internetem przy użyciu prywatnej strefy DNS. Jednak nadal istnieje możliwość utworzenia prywatnego klastra usługi AKS z publicznym adresem DNS. Dlatego zaleca się jawne wyłączenie tej funkcji przez ustawienie enablePrivateClusterPublicFQDN , aby false zapobiec ujawnieniu prywatnego adresu IP płaszczyzny sterowania. Rozważ użycie usługi Azure Policy, aby wymusić użycie klastrów prywatnych bez publicznych rekordów DNS.

Ponadto użyj prywatnej strefy DNS do routingu między podsiecią, która ma bramę aplikacja systemu Azure zintegrowaną z zaporą aplikacji internetowej, a podsiecią, która ma wewnętrzny moduł równoważenia obciążenia. Upewnij się, że żadne odpowiedzi HTTP nie zawierają żadnych prywatnych informacji o adresach IP w nagłówkach lub treści. Upewnij się, że dzienniki, które mogą zawierać rekordy IP i DNS, nie są widoczne poza potrzebami operacyjnymi.

Usługa platformy Azure połączona za pośrednictwem usługi Private Link nie ma publicznego rekordu DNS uwidaczniającego adresy IP. Infrastruktura powinna zapewnić optymalne wykorzystanie usługi Private Link.

Wymaganie 1.4

Zainstaluj osobiste oprogramowanie zapory lub równoważne funkcje na dowolnych przenośnych urządzeniach obliczeniowych łączących się z Internetem poza siecią i które są również używane do uzyskiwania dostępu do usługi CDE.

Twoje obowiązki

Klaster prywatny jest zarządzany przez płaszczyznę sterowania usługi AKS. Nie masz bezpośredniego dostępu do węzłów. W przypadku wykonywania zadań administracyjnych należy użyć narzędzi do zarządzania, takich jak kubectl z oddzielnego zasobu obliczeniowego. Opcja polega na użyciu skrzynki przesiadkowej rozciąglonej powietrzem, w której można uruchamiać polecenia. Ponadto ruch przychodzący i wychodzący z pola przesiadkowego musi być ograniczony i bezpieczny. Jeśli sieć VPN jest używana do uzyskiwania dostępu, upewnij się, że maszyna kliencka jest zarządzana przez zasady firmowe, a wszystkie zasady dostępu warunkowego są stosowane.

W tej architekturze ta skrzynka przesiadkowa znajduje się w oddzielnej podsieci w sieci szprych. Dostęp przychodzący do serwera przesiadkowego jest ograniczony przy użyciu sieciowej grupy zabezpieczeń, która zezwala tylko na dostęp za pośrednictwem usługi Azure Bastion za pośrednictwem protokołu SSH.

Aby uruchomić pewne polecenia w polu przesiadkowym, musisz uzyskać dostęp do publicznych punktów końcowych. Na przykład punkty końcowe zarządzane przez płaszczyznę zarządzania platformy Azure. Ruch wychodzący musi być bezpieczny. Podobnie jak w przypadku innych składników w sieci szprych, ruch wychodzący z serwera przesiadkowego jest ograniczony przy użyciu trasy zdefiniowanej przez użytkownika, która wymusza ruch protokołu HTTPs przez usługę Azure Firewall.

Wymaganie 1.5

Upewnij się, że zasady zabezpieczeń i procedury operacyjne dotyczące zarządzania zaporami są udokumentowane, używane i znane wszystkim stronom, których dotyczy problem.

Twoje obowiązki

Ważne jest, aby zachować szczegółową dokumentację dotyczącą procesu i zasad. Jest to szczególnie istotne w przypadku zarządzania regułami usługi Azure Firewall, które segmentuje klaster usługi AKS. Osoby działające w regulowanych środowiskach muszą być wykształcone, świadome i motywowane do wspierania gwarancji bezpieczeństwa. Jest to szczególnie ważne dla osób z kontami, które mają szerokie uprawnienia administracyjne.

Wymaganie 2 — nie używaj wartości domyślnych dostarczonych przez dostawcę dla haseł systemowych i innych parametrów zabezpieczeń.

Twoje obowiązki

Wymaganie	Odpowiedzialność
Wymaganie 2.1	Przed zainstalowaniem systemu w sieci zawsze należy zmienić wartości domyślne dostarczone przez dostawcę i usunąć lub wyłączyć niepotrzebne konta domyślne.
Wymaganie 2.2	Opracowywanie standardów konfiguracji dla wszystkich składników systemu. Upewnij się, że te standardy spełniają wszystkie znane luki w zabezpieczeniach i są zgodne ze standardami wzmacniania zabezpieczeń systemu akceptowanymi przez branżę.
Wymaganie 2.3	Szyfruj cały dostęp administracyjny bez konsoli przy użyciu silnej kryptografii.
Wymaganie 2.4	Zachowaj spis składników systemowych, które znajdują się w zakresie pci DSS.
Wymaganie 2.5	Upewnij się, że zasady zabezpieczeń i procedury operacyjne dotyczące zarządzania wartościami domyślnymi dostawcy i innymi parametrami zabezpieczeń są udokumentowane, używane i znane wszystkim stronom, których dotyczy problem.
Wymaganie 2.6	Dostawcy hostingu współużytkowanego muszą chronić środowisko hostowane w każdej jednostce i dane posiadaczy kart.

Nie używaj wartości domyślnych dostarczonych przez dostawcę dla haseł systemowych i innych parametrów zabezpieczeń

Wymaganie 2.1

Przed zainstalowaniem systemu w sieci zawsze należy zmienić wartości domyślne dostarczone przez dostawcę i usunąć lub wyłączyć niepotrzebne konta domyślne.

Twoje obowiązki

Należy zmienić ustawienia domyślne udostępniane przez dostawców. Ustawienia domyślne są typowymi wektorami ataków i sprawiają, że system jest podatny na ataki. Oto kilka zagadnień:

• Wyłącz dostęp administratora do rejestru kontenerów.
• Upewnij się, że pola przesiadkowe i agenci kompilacji są zgodne z procedurami zarządzania użytkownikami, usuwając wymaganych użytkowników systemu.
• Nie generuj ani nie udostępniaj dostępu klucza SSH do węzłów użytkownikowi administratora. Jeśli jest to konieczne, użyj procesu odzyskiwania platformy Azure, aby uzyskać dostęp just in time.

Obowiązki platformy Azure

Identyfikator Entra firmy Microsoft ma zasady haseł wymuszane na nowych hasłach dostarczonych przez użytkowników. W przypadku zmiany hasła wymagana jest weryfikacja starszego hasła. Hasła resetowania administratora są wymagane do zmiany po kolejnym logowaniu.

Wymaganie 2.1.1

W przypadku środowisk bezprzewodowych podłączonych do środowiska danych karty lub przesyłania danych karty karty, zmień ustawienia domyślne wszystkich dostawców sieci bezprzewodowej podczas instalacji, w tym, ale nie tylko domyślne klucze szyfrowania bezprzewodowego, hasła i snMP ciągi społeczności.

Twoje obowiązki

Ta architektura i implementacja nie są przeznaczone do wykonywania lokalnych lub firmowych transakcji w chmurze za pośrednictwem połączeń bezprzewodowych. Aby wziąć pod uwagę uwagi, zapoznaj się ze wskazówkami w oficjalnym standardzie PCI-DSS 3.2.1.

Wymaganie 2.2

Opracowywanie standardów konfiguracji dla wszystkich składników systemu.

Twoje obowiązki

Zaimplementuj zalecenia w temie porównawczym zabezpieczeń platformy Azure. Zapewnia on pojedynczy, skonsolidowany widok zaleceń dotyczących zabezpieczeń platformy Azure, obejmujący struktury branżowe, takie jak CIS, NIST, PCI-DSS 3.2.1 i inne. Użyj funkcji Microsoft Defender dla Chmury i usługi Azure Policy, aby ułatwić śledzenie standardów. Test porównawczy zabezpieczeń platformy Azure to domyślna inicjatywa Microsoft Defender dla Chmury. Rozważ utworzenie dodatkowych automatycznych kontroli w usługach Azure Policy i Azure Tenant Security Solution (AzTS).

Udokumentuj żądany stan konfiguracji wszystkich składników usługi CDE, szczególnie w przypadku węzłów usługi AKS, skoku, agentów kompilacji i innych składników, które współdziałają z klastrem.

Aby uzyskać więcej informacji, zobacz Test porównawczy zabezpieczeń platformy Azure.

Odpowiedzialność za platformę Azure

Platforma Azure udostępnia standardy konfiguracji zabezpieczeń zgodne ze standardami zabezpieczeń akceptowanymi przez branżę. Standardy są przeglądane co najmniej co roku.

Wymaganie 2.2.1

Zaimplementuj tylko jedną funkcję podstawową na serwer, aby zapobiec funkcjom, które wymagają różnych poziomów zabezpieczeń, z współistnienia na tym samym serwerze. (Na przykład serwery internetowe, serwery bazy danych i system DNS powinny być implementowane na oddzielnych serwerach).

Twoje obowiązki

Kluczową strategią jest zapewnienie wymaganego poziomu segmentacji. Jednym ze sposobów jest wdrożenie składników w zakresie i poza zakresem w oddzielnych klastrach. Dowiedz się, że powoduje to zwiększenie kosztów dodatkowej infrastruktury i nakładu pracy związanego z konserwacją. Innym podejściem jest współlokalzowanie wszystkich składników w udostępnionym klastrze. Użyj strategii segmentacji, aby zachować separację. Na przykład mają oddzielne pule węzłów w klastrze.

W implementacji referencyjnej drugie podejście jest pokazane przy użyciu aplikacji mikrousług wdrożonej w jednym klastrze. Aplikacja ma dwa zestawy usług: jeden zestaw ma zasobniki w zakresie, a drugi jest poza zakresem. Oba zestawy są rozłożone na dwie pule węzłów użytkownika. Dzięki użyciu defektów platformy Kubernetes zasobniki w zakresie i poza zakresem są wdrażane w oddzielnych pulach węzłów i nigdy nie współużytkują maszynę wirtualną węzła.

W przypadku technologii kontenerów ta segmentacja jest domyślnie dostarczana, ponieważ tylko jedno wystąpienie kontenera jest odpowiedzialne za jedną funkcję w systemie.

Obciążenie powinno używać tożsamości zarządzanej przez zasobniki. Nie może dziedziczyć żadnej tożsamości na poziomie klastra ani na poziomie węzła.

Używaj magazynu zewnętrznego zamiast magazynu w węźle (w klastrze), jeśli jest to możliwe. Zachowaj zasobniki klastra zarezerwowane wyłącznie na potrzeby pracy, które muszą być wykonywane w ramach operacji przetwarzania danych posiadacza karty. Przenieś operacje poza zakresem poza klaster. Te wskazówki dotyczą agentów kompilacji, niepowiązanych obciążeń lub działań, takich jak skok wewnątrz klastra.

Wymaganie 2.2.2

Włącz tylko niezbędne usługi, protokoły, demony itp., zgodnie z wymaganiami dla funkcji systemu.

Twoje obowiązki

Przed ich włączeniem przejrzyj funkcje i implikacje. Ustawienia domyślne mogą obejmować funkcje, których nie potrzebujesz, a te funkcje mogą wymagać wglądu w obciążenie. Przykładem są szyfry w domyślnych zasadach PROTOKOŁU SSL dla usługi aplikacja systemu Azure Gateway. Sprawdź, czy zasady są nadmiernie permissive. Zaleceniem jest utworzenie zasad niestandardowych przez wybranie tylko potrzebnych szyfrów.

W przypadku składników, w których masz pełną kontrolę, usuń wszystkie niepotrzebne usługi systemowe z obrazów (na przykład pola przesiadkowe i agenci kompilacji).

W przypadku składników, w których masz wgląd tylko w węzły usługi AKS, należy udokumentować instalację platformy Azure w węzłach. Rozważ użycie metody DaemonSets , aby zapewnić wszelkie dodatkowe inspekcje niezbędne dla tych składników kontrolowanych przez chmurę.

Wymaganie 2.2.3

Zaimplementuj dodatkowe funkcje zabezpieczeń dla wszystkich wymaganych usług, protokołów lub demonów, które są uważane za niezabezpieczone.

Twoje obowiązki

Usługa Application Gateway ma zintegrowaną zaporę aplikacji internetowej i negocjuje uzgadnianie protokołu TLS dla żądania wysłanego do publicznego punktu końcowego, co umożliwia tylko bezpieczne szyfry. Implementacja referencyjna obsługuje tylko protokół TLS 1.2 i zatwierdzone szyfry.

Załóżmy, że masz starsze urządzenie, które musi współdziałać z usługą CDE za pośrednictwem usługi aplikacja systemu Azure Gateway. W tym celu usługa Application Gateway musi włączyć niezabezpieczony protokół. Udokumentowanie tego wyjątku i monitorowanie, czy ten protokół jest używany poza tym starszym urządzeniem. Wyłącz ten protokół natychmiast po zakończeniu tej starszej interakcji.

Ponadto usługa Application Gateway nie może odpowiadać na żądania na porcie 80. Nie wykonuj przekierowań na poziomie aplikacji. Ta implementacja referencyjna ma regułę sieciowej grupy zabezpieczeń, która blokuje ruch na porcie 80. Reguła znajduje się w podsieci z usługą Application Gateway.

Jeśli obciążenie w klastrze nie może być zgodne z zasadami organizacyjnymi dotyczącymi profilów zgodności zabezpieczeń lub innych mechanizmów kontroli (na przykład limitów i przydziałów), upewnij się, że wyjątek został udokumentowany. Należy monitorować, aby upewnić się, że są wykonywane tylko oczekiwane funkcje.

Wymaganie 2.2.4

Skonfiguruj parametry zabezpieczeń systemu, aby zapobiec niewłaściwemu używaniu.

Twoje obowiązki

Wszystkie usługi platformy Azure używane w architekturze muszą być zgodne z zaleceniami dostarczonymi przez test porównawczy zabezpieczeń platformy Azure. Te zalecenia dają punkt wyjścia do wybierania określonych ustawień konfiguracji zabezpieczeń. Porównaj również konfigurację z implementacją bazową dla tej usługi. Aby uzyskać więcej informacji na temat punktów odniesienia zabezpieczeń, zobacz Punkty odniesienia zabezpieczeń dla platformy Azure.

Kontroler wpływu agenta zasad open policy działa w połączeniu z usługą Azure Policy w celu wykrywania błędów konfiguracji w klastrze i zapobiegania im. Załóżmy, że istnieją zasady organizacyjne, które nie zezwalają na publiczne alokacje adresów IP w węzłach. Po wykryciu takiej alokacji jest ona oznaczona pod kątem inspekcji lub odmowy na podstawie akcji określonej w definicji zasad.

Na poziomie infrastruktury można zastosować ograniczenia dotyczące typu i konfiguracji zasobów platformy Azure. Użyj usługi Azure Policy, aby zapobiec tym przypadkom. W tej implementacji referencyjnej istnieją zasady, które uniemożliwiają tworzenie klastrów usługi AKS, które nie są prywatne.

Rutynowo upewnij się, że wszystkie wyjątki są udokumentowane i poddane przeglądowi.

Obowiązki platformy Azure

Platforma Azure zapewnia, że tylko autoryzowany personel może skonfigurować mechanizmy kontroli zabezpieczeń platformy Azure przy użyciu kontroli dostępu wieloskładnikowego i udokumentowanej potrzeby biznesowej.

Wymaganie 2.2.5

Usuń wszystkie niepotrzebne funkcje, takie jak skrypty, sterowniki, funkcje, podsystemy, systemy plików i niepotrzebne serwery internetowe.

Twoje obowiązki

Nie instaluj oprogramowania na serwerach przesiadkowych ani agentów kompilacji, którzy nie uczestniczą w przetwarzaniu transakcji ani nie zapewniają wglądu w wymagania dotyczące zgodności, takie jak agenci zabezpieczeń. To zalecenie dotyczy również jednostek klastra, takich jak DaemonSet i zasobników. Upewnij się, że wszystkie instalacje zostały wykryte i zarejestrowane.

Wymaganie 2.3

Szyfruj cały dostęp administracyjny bez konsoli przy użyciu silnej kryptografii.

Twoje obowiązki

Cały dostęp administracyjny do klastra należy wykonać przy użyciu konsoli programu . Nie ujawniaj płaszczyzny sterowania klastra.

Obowiązki platformy Azure

Platforma Azure zapewnia wymuszanie użycia silnej kryptografii podczas uzyskiwania dostępu do infrastruktury funkcji hypervisor. Gwarantuje to, że klienci korzystający z portalu zarządzania Platformy Microsoft Azure będą mogli uzyskiwać dostęp do swoich konsol usług/IaaS przy użyciu silnej kryptografii.

Wymaganie 2.4

Zachowaj spis składników systemowych, które znajdują się w zakresie pci DSS.

Twoje obowiązki

Wszystkie zasoby platformy Azure używane w architekturze muszą być prawidłowo oznakowane. Tagi pomagają w klasyfikacji danych i wskazują, czy usługa jest w zakresie, czy poza zakresem. Skrupulatne tagowanie umożliwia wykonywanie zapytań dotyczących zasobów, przechowywanie spisu, śledzenie kosztów i ustawianie alertów. Ponadto okresowo należy zachować migawkę tej dokumentacji.

Unikaj tagowania zasobów w zakresie lub poza zakresem na poziomie szczegółowym. W miarę rozwoju rozwiązania zasoby poza zakresem mogą stać się w zakresie, nawet jeśli pośrednio wchodzą w interakcje lub sąsiadują z danymi posiadacza karty. Te zasoby podlegają inspekcji i mogą być częścią reprezentatywnej próbki podczas inspekcji. Rozważ tagowanie na wyższym poziomie na poziomie subskrypcji i klastra.

Aby uzyskać informacje na temat zagadnień związanych z tagowaniem, zobacz Przewodnik po decyzjach dotyczących nazewnictwa zasobów i tagowania.

Tagowanie obiektów w klastrze przez zastosowanie etykiet kubernetes. Dzięki temu można organizować obiekty, wybierać kolekcję obiektów i spis raportów.

Wymaganie 2.5

Upewnij się, że zasady zabezpieczeń i procedury operacyjne dotyczące zarządzania wartościami domyślnymi dostawcy i innymi parametrami zabezpieczeń są udokumentowane, używane i znane wszystkim stronom, których dotyczy problem.

Twoje obowiązki

Ważne jest, aby zachować szczegółową dokumentację procesów i zasad. Personel powinien być szkolony w funkcjach zabezpieczeń i ustawieniach konfiguracji każdego zasobu platformy Azure. Osoby działające w regulowanych środowiskach muszą być wykształcone, świadome i motywowane do wspierania gwarancji bezpieczeństwa. Jest to szczególnie ważne w przypadku kont administratorów, które mają szerokie uprawnienia administracyjne.

Wymaganie 2.6

Dostawcy hostingu współużytkowanego muszą chronić środowisko hostowane w każdej jednostce i dane posiadaczy kart.

Twoje obowiązki

Platforma Azure zapewnia zabezpieczenia dla wszystkich składników środowiska hostowanego, które są współużytkowane. Zdecydowanie zaleca się traktowanie węzłów usługi AKS jako dedykowanego hosta dla tego obciążenia. Oznacza to, że wszystkie obliczenia powinny znajdować się w jednym modelu dzierżawy i nie są współużytkowane z innymi obciążeniami, które mogą działać.

Jeśli wymagana jest pełna izolacja obliczeniowa na poziomie infrastruktury platformy Azure, możesz dodać dedykowany host platformy Azure do klastra usługi Azure Kubernetes Service (AKS). Ta oferta zapewnia serwery fizyczne dedykowane dla obciążenia, dzięki czemu można umieścić węzły usługi AKS bezpośrednio na tych hostach zaaprowizowanych. Ten wybór architektury ma znaczący wpływ na planowanie kosztów i pojemności i nie jest typowy dla większości scenariuszy.

Następne kroki

Ochrona przechowywanych danych karty. Szyfruj przesyłanie danych posiadaczy kart w otwartych sieciach publicznych.

Powiązane zasoby

• Projekt architektury usługi Azure Kubernetes Service (AKS)
• Wprowadzenie klastra regulowanego usługi AKS dla standardu PCI-DSS 3.2.1 (część 1 z 9)
• Architektura klastra regulowanego usługi AKS dla standardu PCI-DSS 3.2.1 (część 2 z 9)
• Architektura linii bazowej dla klastra usługi Azure Kubernetes Service (AKS)
• Punkt odniesienia usługi AKS dla klastrów wieloregionowych