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 regulowanego środowiska sieciowego. Ł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 i warstwie.

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 obsługa 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). Ta konfiguracja uniemożliwia nieautoryzowany publiczny dostęp 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 kilka opcji wtyczki zasad sieciowych, w tym Calico, Azure Network Policy Management i Cilium. Za pomocą zasad sieci Calico można użyć rozwiązania Kubenet lub azure CNI. W przypadku zarządzania zasadami sieciowymi platformy Azure można używać tylko usługi Azure CNI (a nie kubenet). 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 szablony Bicep, Azure Resource Manager (szablony arm) 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, w tym, że powinny pokazywać czujniki włamań i wszelkie zastosowane kontrolki.

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) może znajdować 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 ponosisz odpowiedzialność za zabezpieczenie usługi CDE za pomocą mechanizmów kontroli sieci w celu blokowania nieautoryzowanego dostępu do sieci, która zawiera usługę 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 jest używana jako router ruchu, a zintegrowana zapora aplikacji internetowej (WAF) służy 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 zewnętrznymi punktami końcowymi. Na przykład klaster może wymagać komunikacji z płaszczyzną sterowania usługi AKS, komunikacją z systemami operacyjnymi i systemami aktualizacji pakietów, a wiele obciążeń współdziała 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 przy użyciu wzajemnego uwierzytelniania TLS (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.

• Obiekty Kubernetes NetworkPolicy służą do kontrolowania komunikacji w klastrze.

  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ą zastosowane restrykcyjne zasady sieciowe. 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 ma zakres zasięgu— od planowania sieci po wszystkie zastosowane konfiguracje. Powinna ona również zawierać szczegółowe informacje na temat własności, z wyraźnymi liniami odpowiedzialności i rolami, które są im odpowiedzialne.

Na przykład dowiedz się, kto jest odpowiedzialny za zapewnienie ładu w zakresie zabezpieczania sieci między platformą Azure a Internetem. W przedsiębiorstwie zespół IT jest zwykle odpowiedzialny za konfigurację i konserwację reguł usługi Azure Firewall, reguł zapory aplikacji internetowych, 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 przykładów, w których można zezwolić 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.

Jeśli wycofano wszystkie obciążenia lub zmieniono konfigurację klastra od poprzedniego przeglądu, ważne jest, aby sprawdzić, czy wszelkie założenia dotyczące wymaganych wyjątków zapory lub reguły sieciowej grupy zabezpieczeń są nadal prawidłowe.

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. Niezaufane sieci obejmują:

• Inne piasty i szprychy, które mogą znajdować się w tej samej infrastrukturze, ale znajdują się poza obwodem obciążenia.
• Publiczny Internet.
• Sieć firmowa.
• Inne sieci wirtualne 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 zabezpieczyć całe środowisko za pomocą sieci wirtualnych, sieciowych grup zabezpieczeń i innych wbudowanych funkcji.

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 sieci wirtualne platformy Azure nie mogą być bezpośrednio dostępne z publicznego Internetu. Cały ruch przychodzący (lub przychodzący) musi przechodzić przez router ruchu pośredniego. Jednak domyślnie wszystkie składniki w sieci mogą uzyskiwać dostęp do publicznych punktów końcowych. To zachowanie można wyłączyć, konfigurując podsieć prywatną lub używając trasy zdefiniowanej przez użytkownika do wysyłania całego ruchu wychodzącego przez zaporę. Ten ruch wychodzący (lub wychodzący) musi być jawnie zabezpieczony, aby zezwolić tylko na bezpieczne szyfry i tls 1.2 lub nowszy.

• zintegrowana zapora aplikacji internetowej bramy aplikacja systemu Azure 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 do skonfigurowanego zaplecza lub zezwalają na nie, a usługa Application Gateway kieruje 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.
  • Żądania sondy kondycji wysyłane 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 na przykład 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 ruchu są również zabezpieczone za pośrednictwem reguł sieciowej grupy zabezpieczeń. Oto kilka przykładów z tej architektury, w których usługa CDE jest chroniona przez odmawianie ruchu:

• Sieciowe grupy zabezpieczeń w podsieciach z pulami węzłów odmawiają dostępu SSH do węzłów. Upewnij się, że masz proces dostępu awaryjnego just in time, zachowując jednocześnie zasadę 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 koncentratora.
• Sieciowe grupy zabezpieczeń w podsieciach, które mają prywatne punkty końcowe do usługi Azure Key Vault i usługi Azure Container Registry, blokują 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 pliki Bicep lub szablony usługi Azure Resource Manager (szablony usługi ARM) zachowują rekord żądanego stanu.

Zasoby wdrażania, takie jak pliki Bicep, 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 prywatne 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 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ą zgodni z procedurami zarządzania użytkownikami, usuwając użytkowników systemu, którzy nie są potrzebni.
• Nie generuj ani nie udostępniaj dostępu klucza SSH do węzłów użytkownikom 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ło zresetowane przez administratora musi zostać zmienione po następnym zalogowaniu użytkownika.

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 testach porównawczych zabezpieczeń w chmurze firmy Microsoft. 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ń w chmurze firmy Microsoft.

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.

Każdy zasobnik obciążenia powinien używać własnej tożsamości. 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. Zapoznaj się na przykład z obrazami pól przesiadkowych i agentów kompilacji i usuń wszystkie składniki, które nie są potrzebne.

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. Aby spełnić to wymaganie, 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.

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ń w chmurze firmy Microsoft. 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 błędom konfiguracji. W tej implementacji referencyjnej istnieją zasady, które uniemożliwiają tworzenie klastrów usługi AKS, które nie są prywatne.

Upewnij się, że wszystkie wyjątki są udokumentowane i regularnie przeglądane.

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 witryny Azure Portal będą mogli uzyskiwać dostęp do swoich konsol usług i hostów 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. Te kroki są szczególnie ważne dla wszystkich osób, 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 koszty i wymaga starannego planowania pojemności. Nie jest to typowe 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