Zarządzanie tożsamościami i dostępem dla klastra regulowanego usługi AKS dla pci DSS 4.0.1

W tym artykule opisano zagadnienia dotyczące zarządzania tożsamościami i dostępem dla klastra usługi Azure Kubernetes Service (AKS), który jest skonfigurowany zgodnie z standardem Payment Card Industry Data Security Standard (PCI-DSS 4.0.1).

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

Platforma Kubernetes ma natywną kontrolę dostępu opartą na rolach (RBAC), która zarządza uprawnieniami do interfejsu API Kubernetes. Istnieje kilka wbudowanych ról z określonymi uprawnieniami lub akcjami w zasobach platformy Kubernetes. Usługa Azure Kubernetes Service (AKS) obsługuje te wbudowane role i role niestandardowe na potrzeby szczegółowej kontroli. Te akcje mogą być autoryzowane lub blokowane dla użytkownika za pośrednictwem kontroli dostępu opartej na rolach platformy Kubernetes.

Ta architektura i implementacja nie są zaprojektowane w celu zapewnienia kontroli dostępu fizycznego do zasobów lokalnych lub centrów danych. Jedną z zalet hostingu usługi CDE na platformie Azure, w przeciwieństwie do platformy na brzegu lub w centrum danych, jest to, że ograniczenie dostępu fizycznego jest w większości obsługiwane za pośrednictwem zabezpieczeń centrum danych platformy Azure. Nie ma żadnych obowiązków dla organizacji w zarządzaniu sprzętem fizycznym.

Implementowanie silnych środków kontroli dostępu

Wymaganie 7. Ograniczanie dostępu do danych posiadaczy kart przez firmę musi wiedzieć

Obsługa funkcji usługi AKS

Usługa AKS jest w pełni zintegrowana z identyfikatorem Entra firmy Microsoft jako dostawcą tożsamości.

Nie musisz zarządzać oddzielnymi tożsamościami użytkowników i poświadczeniami dla platformy Kubernetes. Możesz dodać użytkowników usługi Microsoft Entra dla kontroli dostępu opartej na rolach platformy Kubernetes. Ta integracja umożliwia przypisywanie ról do użytkowników firmy Microsoft Entra. Korzystając z tożsamości firmy Microsoft Entra, można użyć różnych wbudowanych ról, takich jak osoba przeglądająca, zapis, administrator usługi i administrator klastra. Możesz również utworzyć role niestandardowe, aby uzyskać bardziej szczegółową kontrolę.

Domyślnie kontrola dostępu oparta na rolach platformy Azure jest ustawiona tak, aby nie można było uzyskać dostępu do zasobu bez udzielenia uprawnień. Usługa AKS ogranicza dostęp SSH do węzłów procesu roboczego usługi AKS i używa zasad sieciowych usługi AKS do kontrolowania dostępu do obciążeń w zasobnikach.

Aby uzyskać więcej informacji, zobacz Use Azure RBAC for Kubernetes authorization and Secure your cluster with Azure Policy (Używanie kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji platformy Kubernetes ) i Secure your cluster with Azure Policy (Zabezpieczanie klastra przy użyciu usługi Azure Policy).

Twoje obowiązki

Wymaganie 7.1

PCI DSS 4.0.1 umożliwia dostosowanie podejścia do kontroli dostępu, pod warunkiem, że cele zabezpieczeń są spełnione, a podejście jest w pełni udokumentowane i uzasadnione. Organizacje mogą implementować alternatywne mechanizmy kontroli, jeśli mogą wykazać równoważne lub lepsze wyniki zabezpieczeń.

Ogranicz dostęp do składników systemowych i danych posiadaczy kart tylko tym osobom, których zadanie wymaga takiego dostępu.

Twoje obowiązki

Rozważ następujące najlepsze rozwiązania:

• Upewnij się, że implementacja jest zgodna z wymaganiami organizacji oraz z wymaganiami dotyczącymi zgodności dotyczącymi zarządzania tożsamościami.
• Zminimalizuj stałe uprawnienia, szczególnie w przypadku kont o krytycznym wpływie.
• Przestrzegaj zasady dostępu z najniższymi uprawnieniami. Zapewnij wystarczający dostęp, aby ukończyć zadanie.

Wymaganie 7.1.1

PCI DSS 4.0.1 wyjaśnia potrzebę ciągłego przeglądu i dokumentacji potrzeb dostępu dla każdej roli oraz wymaga regularnego przeglądania i aktualizowania dostępu w miarę zmiany funkcji zadań.

Definiowanie potrzeb dostępu dla każdej roli, w tym:

• Składniki systemu i zasoby danych, do których każda rola musi uzyskać dostęp do funkcji zadania.
• Wymagany poziom uprawnień (na przykład użytkownik, administrator itp.) na potrzeby uzyskiwania dostępu do zasobów.

Twoje obowiązki

Zdefiniuj role na podstawie zadań i obowiązków wymaganych dla składników w zakresie i ich interakcji z zasobami platformy Azure. Możesz zacząć od szerokich kategorii, takich jak:

• Zakres według grup zarządzania, subskrypcji lub grup zasobów platformy Azure.
• Usługa Azure Policy dla obciążenia lub subskrypcji.
• Operacje kontenera.
• Zarządzanie wpisami tajnymi.
• Potoki kompilacji i wdrażania.

Chociaż definicja ról i obowiązków wokół tych obszarów może być skojarzona ze strukturą zespołu, skoncentruj się na wymaganiu obciążenia. Na przykład określ, kto jest odpowiedzialny za utrzymanie bezpieczeństwa, izolacji, wdrażania i możliwości obserwacji. Oto kilka przykładów obowiązków:

• Zdecyduj konfiguracje dotyczące zabezpieczeń aplikacji, kontroli dostępu opartej na rolach platformy Kubernetes, zasad sieciowych, zasad platformy Azure i komunikacji z innymi usługami.
• Konfigurowanie i obsługa usługi Azure Firewall, zapory aplikacji internetowej (WAF), sieciowych grup zabezpieczeń i systemu DNS.
• Monitoruj i koryguj zabezpieczenia serwera, stosowanie poprawek, konfigurację i zabezpieczenia punktu końcowego.
• Ustaw kierunek korzystania z kontroli dostępu opartej na rolach, Microsoft Defender dla Chmury, strategii ochrony administratora i usługi Azure Policy, aby zarządzać zasobami platformy Azure.
• Zidentyfikuj zespół ds. monitorowania i reagowania na zdarzenia. Badanie i korygowanie zdarzeń zabezpieczeń przy użyciu systemu zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takiego jak Microsoft Sentinel lub Microsoft Defender dla Chmury.

Następnie sformalizuj definicję, określając, jaki poziom dostępu jest wymagany dla roli w odniesieniu do obciążenia i infrastruktury. Poniższa tabela zawiera kilka przykładów ról, ich obowiązków i poziomów dostępu, które mogą być wymagane:

Wymaganie 7.1.2

PCI DSS 4.0.1 podkreśla minimalizację stałych uprawnień i zachęca do korzystania z zasad dostępu just in time (JIT) i dostępu warunkowego. Wymagane jest ulepszone monitorowanie i alerty dotyczące uprzywilejowanego dostępu.

Ogranicz dostęp do uprzywilejowanych identyfikatorów użytkowników do najmniejszych uprawnień niezbędnych do wykonywania zadań.

Twoje obowiązki

W oparciu o funkcje zadań staraj się zminimalizować dostęp bez powodowania zakłóceń. Rozważ następujące najlepsze rozwiązania:

• Zmniejsz dostęp wymagany przez każdą tożsamość. Tożsamość powinna mieć wystarczający dostęp, aby ukończyć swoje zadanie.
• Zminimalizuj stałe uprawnienia, szczególnie w przypadku tożsamości o kluczowym znaczeniu, które mają dostęp do składników w zakresie.
• W miarę możliwości dodaj dodatkowe ograniczenia. Jednym ze sposobów jest zapewnienie dostępu warunkowego na podstawie kryteriów dostępu.
• Przeprowadzanie regularnego przeglądu i inspekcji użytkowników i grup, które mają dostęp do subskrypcji, nawet w przypadku dostępu do odczytu. Unikaj zapraszania tożsamości zewnętrznych.

Wymaganie 7.1.3

Przypisania dostępu muszą być stale przeglądane i aktualizowane w celu odzwierciedlenia zmian w funkcjach pracowników lub zadań. PCI DSS 4.0.1 wymaga udokumentowania i uzasadnienia wszystkich przypisań dostępu.

Przypisz dostęp na podstawie klasyfikacji i funkcji poszczególnych pracowników.

Twoje obowiązki

Ustal uprawnienia na podstawie jasno przypisanych obowiązków służbowych danej osoby. Unikaj parametrów, takich jak system lub kadencja pracownika. Nadaj uprawnienia dostępu jednemu użytkownikowi lub grupie.

Oto kilka przykładowych klasyfikacji zadań i skojarzonych z nimi ról:

Wymaganie 7.1.4

PCI DSS 4.0.1 wymaga, aby wszystkie przypisania i zmiany uprawnień zostały zatwierdzone i udokumentowane przez autoryzowane strony oraz że proces zatwierdzania można przeprowadzić inspekcję.

Wymagaj udokumentowania zatwierdzenia przez autoryzowane strony określające wymagane uprawnienia.

Twoje obowiązki

Mają proces zatwierdzania zmian w rolach i uprawnieniach, w tym początkowe przypisywanie uprawnień. Upewnij się, że te zatwierdzenia są udokumentowane i dostępne do inspekcji.

Wymaganie 7.2

PCI DSS 4.0.1 wymaga, aby systemy kontroli dostępu obsługiwały ciągłe monitorowanie i alerty w przypadku nieautoryzowanych prób dostępu oraz że wszystkie zasady kontroli dostępu są regularnie przeglądane i aktualizowane.

Ustanów system kontroli dostępu dla składników systemów, które ograniczają dostęp na podstawie potrzeby znajomości użytkownika i jest ustawiony na "odmów wszystkie", chyba że jest to dozwolone.

Twoje obowiązki

Po wykonaniu wymagań 7.1 należy ocenić role i obowiązki, które mają zastosowanie do organizacji i obciążenia. Wszystkie składniki architektury, które są w zakresie, muszą mieć ograniczony dostęp. Obejmuje to węzły usługi AKS, które uruchamiają obciążenie, magazyn danych, dostęp do sieci i wszystkie inne usługi, które uczestniczą w przetwarzaniu danych posiadacza karty (CHD).

Na podstawie ról i obowiązków przypisz role do mechanizmu kontroli dostępu opartej na rolach (RBAC) infrastruktury, na przykład:

• Kubernetes RBAC: natywny model autoryzacji Kubernetes, który kontroluje dostęp do płaszczyzny sterowania Kubernetes, uwidoczniony za pośrednictwem serwera interfejsu API Kubernetes. Ten zestaw uprawnień definiuje, co można zrobić z serwerem interfejsu API. Możesz na przykład odmówić użytkownikowi uprawnień do tworzenia lub nawet wyświetlania listy zasobników.
• Kontrola dostępu oparta na rolach platformy Azure: model autoryzacji oparty na identyfikatorze entra firmy Microsoft, który kontroluje dostęp do płaszczyzny sterowania platformy Azure. Jest to skojarzenie dzierżawy firmy Microsoft Entra z subskrypcją platformy Azure. Dzięki kontroli dostępu opartej na rolach platformy Azure możesz udzielić uprawnień do tworzenia zasobów platformy Azure, takich jak sieci, klaster usługi AKS i tożsamości zarządzane.

Załóżmy, że musisz przyznać operatorom klastra uprawnienia (mapowane na rolę operatora infrastruktury). Wszystkie osoby, którym przypisano obowiązki operatora infrastruktury, należą do grupy Microsoft Entra. Jak określono w wersji 7.1.1, ta rola wymaga najwyższych uprawnień w klastrze. Platforma Kubernetes ma wbudowane role RBAC, takie jak cluster-admin, które spełniają te wymagania. Należy powiązać grupę Entra firmy Microsoft dla operatora cluster-admin infrastruktury, tworząc powiązania ról, wybierając wbudowane role. Jeśli wbudowane role nie spełniają Twoich wymagań (na przykład mogą być nadmiernie permissive), możesz utworzyć role niestandardowe dla powiązań.

Implementacja referencyjna demonstruje powyższy przykład przy użyciu natywnej kontroli dostępu opartej na rolach platformy Kubernetes. To samo skojarzenie można wykonać za pomocą kontroli dostępu opartej na rolach platformy Azure. Aby uzyskać więcej informacji, zobacz Kontrola dostępu do zasobów klastra przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes i tożsamości firmy Microsoft w usłudze Azure Kubernetes Service (AKS).

Zakres uprawnień można wybrać na poziomie klastra lub na poziomie przestrzeni nazw. W przypadku ról, które mają zakres obowiązków, takich jak operatory aplikacji, uprawnienia są przypisywane na poziomie przestrzeni nazw dla obciążenia.

Ponadto role potrzebują również uprawnień RBAC platformy Azure, aby móc wykonywać swoje zadania. Na przykład operator klastra musi uzyskać dostęp do usługi Azure Monitor za pośrednictwem portalu. Dlatego rola operatora infrastruktury musi mieć odpowiednie przypisanie RBAC.

Oprócz osób i ich ról, zasobów platformy Azure, a nawet zasobników w klastrze, mają tożsamości zarządzane. Te tożsamości wymagają zestawu uprawnień za pośrednictwem kontroli dostępu opartej na rolach platformy Azure i muszą być ściśle ograniczone na podstawie oczekiwanych zadań. Na przykład usługa aplikacja systemu Azure Gateway musi mieć uprawnienia do pobierania wpisów tajnych (certyfikatów TLS) z usługi Azure Key Vault. Nie może mieć uprawnień do modyfikowania wpisów tajnych.

Poniżej przedstawiono niektóre najlepsze rozwiązania dotyczące utrzymania środków kontroli dostępu:

• Zachowaj skrupulatną dokumentację dotyczącą każdej roli i przypisanych uprawnień, a także uzasadnienia. Zachowaj jasne różnice dotyczące uprawnień JIT i które stoją.
• Monitoruj role pod kątem zmian, takich jak zmiany przypisania lub definicje ról. Utwórz alerty dotyczące zmian, nawet jeśli są one oczekiwane, aby uzyskać wgląd w intencje związane ze zmianami.

Wymaganie 7.2.1

PCI DSS 4.0.1 wymaga, aby środki kontroli dostępu obejmowały wszystkie składniki systemu, w tym środowiska chmurowe i hybrydowe, oraz że mechanizmy kontroli są stale monitorowane pod kątem skuteczności.

Twoje obowiązki

Rozważ następujące najlepsze rozwiązania:

• Nie masz stałego dostępu. Rozważ użycie członkostwa w grupie usługi AD just in time. Ta funkcja wymaga usługi Microsoft Entra Privileged Identity Management.

• Skonfiguruj zasady dostępu warunkowego w usłudze Microsoft Entra ID dla klastra. Spowoduje to dalsze ograniczenie dostępu do płaszczyzny sterowania platformy Kubernetes. Dzięki zasadom dostępu warunkowego można wymagać uwierzytelniania wieloskładnikowego, ograniczyć uwierzytelnianie do urządzeń zarządzanych przez dzierżawę firmy Microsoft Entra lub zablokować nietypowe próby logowania. Zastosuj te zasady do grup entra firmy Microsoft, które są mapowane na role kubernetes z wysokimi uprawnieniami.

  Uwaga / Notatka

  Wybór technologii JIT i dostępu warunkowego wymaga licencji microsoft Entra ID P1 lub P2.

• W idealnym przypadku wyłącz dostęp SSH do węzłów klastra. Ta implementacja referencyjna nie generuje szczegółów połączenia SSH w tym celu.

• Dostęp do wszelkich dodatkowych obliczeń, takich jak pola przesiadkowe, muszą uzyskiwać dostęp autoryzowani użytkownicy. Nie twórz ogólnych identyfikatorów logowania dostępnych dla całego zespołu.

Wymaganie 7.2.2

Uprawnienia dostępu muszą być przypisywane i przeglądane na podstawie klasyfikacji i funkcji zadań oraz muszą zostać zaktualizowane w miarę zmiany ról. PCI DSS 4.0.1 wymaga udokumentowania i przeprowadzenia inspekcji tego procesu.

Przypisywanie uprawnień do osób na podstawie klasyfikacji i funkcji zadań.

Twoje obowiązki

Na podstawie wersji 7.1.3 istnieje wiele ról zaangażowanych w operacje klastra. Poza standardowymi rolami zasobów platformy Azure należy zdefiniować zakres i proces dostępu.

Rozważmy na przykład rolę operatora klastra. Powinny one mieć jasno zdefiniowany podręcznik dla działań klasyfikacji klastra. Czym różni się dostęp od zespołu ds. obciążeń? W zależności od organizacji mogą one być takie same. Oto kilka kwestii, które należy wziąć pod uwagę:

• Jak należy uzyskać dostęp do klastra?
• Które źródła są dozwolone w celu uzyskania dostępu?
• Jakie uprawnienia powinny mieć w klastrze?
• Kiedy są przypisane te uprawnienia?

Upewnij się, że definicje są udokumentowane w dokumentacji ładu, zasadach i materiałach szkoleniowych dotyczących operatora obciążenia i operatora klastra.

Wymaganie 7.2.3

Pci DSS 4.0.1 wymaga wymuszania i regularnego sprawdzania poprawności domyślnego ustawienia "odmów wszystkich" za pomocą zautomatyzowanego testowania i monitorowania.

Twoje obowiązki

Po uruchomieniu konfiguracji zacznij od zasad zerowego zaufania. Wprowadź wyjątki zgodnie z potrzebami i udojmij je szczegółowo.

• Kontrola dostępu oparta na rolach platformy Kubernetes domyślnie implementuje odrzucanie wszystkich . Nie przesłoń, dodając wysoce permissywne powiązania ról klastra, które odwracają ustawienie odmów wszystkich.
• Kontrola dostępu oparta na rolach platformy Azure domyślnie implementuje również funkcję odmowy wszystkich. Nie przesłoń, dodając przypisania kontroli dostępu opartej na rolach, które odwracają ustawienie odmów wszystkich.
• Wszystkie usługi platformy Azure, w tym Azure Key Vault i Azure Container Registry, domyślnie odmawiają wszystkich uprawnień.
• Wszystkie punkty dostępu administracyjnego, takie jak serwer przesiadkowy, powinny blokować cały dostęp w początkowej konfiguracji. Aby zastąpić regułę odmów, należy jawnie zdefiniować wszystkie podniesione uprawnienia.

Wymaganie 7.3

PCI DSS 4.0.1 wymaga, aby zasady zabezpieczeń i procedury operacyjne ograniczające dostęp do danych posiadaczy kart były stale przeglądane, aktualizowane i przekazywane wszystkim stronom, których dotyczy problem.

Upewnij się, że zasady zabezpieczeń i procedury operacyjne ograniczające dostęp do danych posiadaczy kart 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. Obejmuje to zasady kontroli dostępu opartej na rolach platformy Azure i platformy Kubernetes oraz zasady ładu organizacyjnego. 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, które są częścią procesu zatwierdzania z perspektywy zasad.

Wymaganie 8. Identyfikowanie i uwierzytelnianie dostępu do składników systemowych

Obsługa funkcji usługi AKS

Ze względu na integrację usług AKS i Microsoft Entra można korzystać z funkcji zarządzania tożsamościami i autoryzacji, w tym zarządzania dostępem, zarządzania obiektami identyfikatorów i innych. Aby uzyskać więcej informacji, zobacz Integracja usługi Microsoft Entra zarządzana przez usługę AKS.

Twoje obowiązki

Wymaganie 8.1

PCI DSS 4.0.1 rozszerza wymagania dotyczące unikatowej identyfikacji i uwierzytelniania, w tym ciągłe monitorowanie kont użytkowników i automatyczne alerty dotyczące podejrzanych działań. Organizacje muszą implementować procesy regularnego przeglądania i usuwania niepotrzebnych kont.

Zdefiniuj i zaimplementuj zasady i procedury w celu zapewnienia prawidłowego zarządzania identyfikacją użytkowników i administratorów innych użytkowników na wszystkich składnikach systemu w następujący sposób:

Twoje obowiązki

Poniżej przedstawiono ogólne zagadnienia dotyczące tego wymagania:

DOTYCZY: 8.1.1, 8.1.2, 8.1.3

Nie udostępniaj ani nie używaj ponownie tożsamości dla funkcjonalnie różnych części usługi CDE. Na przykład nie używaj konta zespołu do uzyskiwania dostępu do danych lub zasobów klastra. Upewnij się, że dokumentacja tożsamości nie korzysta z kont udostępnionych.

Rozszerz tę jednostkę tożsamości na przypisania tożsamości zarządzanej na platformie Azure. Nie udostępniaj tożsamości zarządzanych przez użytkownika w zasobach platformy Azure. Przypisz każdy zasób platformy Azure własną tożsamość zarządzaną. Podobnie w przypadku korzystania z identyfikatora obciążenia entra firmy Microsoft w klastrze usługi AKS upewnij się, że każdy składnik obciążenia otrzymuje własną tożsamość, zamiast korzystać z tożsamości, która ma szeroki zakres. Nigdy nie współużytkuj tej samej tożsamości zarządzanej między środowiskami produkcyjnymi i nieprodukcyjnymi.

Aby uzyskać więcej informacji, zobacz Opcje dostępu i tożsamości dla usługi Azure Kubernetes Service (AKS).

DOTYCZY: 8.1.2, 8.1.3, 8.1.4

Użyj identyfikatora Entra firmy Microsoft jako magazynu tożsamości. Ponieważ klaster i wszystkie zasoby platformy Azure używają identyfikatora Entra firmy Microsoft, wyłączenie lub cofnięcie dostępu podmiotu zabezpieczeń ma zastosowanie do wszystkich zasobów automatycznie. Jeśli istnieją jakiekolwiek składniki, które nie są bezpośrednio wspierane przez identyfikator Entra firmy Microsoft, upewnij się, że masz proces usuwania dostępu. Na przykład poświadczenia SSH na potrzeby uzyskiwania dostępu do serwera przesiadkowego mogą wymagać jawnego usunięcia, jeśli użytkownik nie jest już prawidłowy.

DOTYCZY: 8.1.5

Korzystaj z Tożsamość zewnętrzna Microsoft Entra przeznaczonych do hostowania kont firmowych (B2B) innych firm, takich jak dostawcy i partnerzy, jako użytkownicy-goście. Udziel odpowiedniego poziomu dostępu przy użyciu zasad warunkowych w celu ochrony danych firmowych. Te konta muszą mieć minimalne uprawnienia stałe i obowiązkowe daty wygaśnięcia. Aby uzyskać więcej informacji, zobacz Współpraca B2B z gośćmi zewnętrznymi dla pracowników.

Organizacja powinna mieć jasny i udokumentowany wzorzec dostawcy i podobny dostęp.

DOTYCZY: 8.1.6, 8.1.7, 8.1.8

Identyfikator Entra firmy Microsoft udostępnia funkcję inteligentnej blokady w celu zablokowania użytkowników po nieudanych próbach logowania. Zalecanym sposobem implementacji blokad jest stosowanie zasad dostępu warunkowego firmy Microsoft Entra.

Zaimplementuj blokadę dla składników, które obsługują podobne funkcje, ale nie są obsługiwane przy użyciu identyfikatora Entra firmy Microsoft (na przykład maszyn z obsługą protokołu SSH, takich jak serwer przesiadkowy). Gwarantuje to, że blokady są włączone w celu zapobiegania nadużyciom lub powolnego dostępu.

Węzły usługi AKS nie są przeznaczone do rutynowego uzyskiwania dostępu. Blokuj bezpośredni dostęp za pomocą protokołu SSH lub pulpitu zdalnego do węzłów klastra. Dostęp za pomocą protokołu SSH należy traktować tylko jako część zaawansowanych działań związanych z rozwiązywaniem problemów. Dostęp powinien być ściśle monitorowany i natychmiast przywracany po zakończeniu określonego zdarzenia. Jeśli to zrobisz, należy pamiętać, że wszelkie zmiany na poziomie węzła mogą spowodować brak obsługi klastra.

Wymaganie 8.2

PCI DSS 4.0.1 aktualizuje wymagania dotyczące haseł i uwierzytelniania zgodnie z nowoczesnymi najlepszymi rozwiązaniami w zakresie zabezpieczeń, w tym dłuższymi minimalnymi długościami haseł, wymaganiami dotyczącymi złożoności i obsługą metod uwierzytelniania bez hasła. Wymagane jest rozszerzone monitorowanie zdarzeń uwierzytelniania.

Oprócz przypisywania unikatowego identyfikatora należy zapewnić właściwe zarządzanie uwierzytelnianiem użytkowników i administratorów innych niż odbiorcy we wszystkich składnikach systemu, stosując co najmniej jedną z następujących metod uwierzytelniania wszystkich użytkowników:

• Coś, co wiesz, na przykład hasło lub hasło.
• Coś, co masz, takie jak urządzenie tokenowe lub karta inteligentna.
• Coś, co jesteś, na przykład biometryczne.

Twoje obowiązki

Skonfiguruj zasady dostępu warunkowego w usłudze Microsoft Entra ID dla klastra. Spowoduje to dalsze ograniczenie dostępu do płaszczyzny sterowania platformy Kubernetes.

Kilka z poprzednich zestawów wymagań jest automatycznie obsługiwanych przez identyfikator Entra firmy Microsoft. Oto kilka przykładów:

• Zabezpieczenia haseł

  Identyfikator Entra firmy Microsoft udostępnia funkcje, które wymuszają używanie silnych haseł. Na przykład słabe hasła należące do globalnej listy zakazanych haseł są blokowane. Nie jest to wystarczająca ochrona. Aby utworzyć listę zakazów specyficznych dla organizacji, rozważ dodanie funkcji ochrony haseł firmy Microsoft Entra. Zasady haseł są domyślnie stosowane. Niektórych zasad nie można modyfikować i obejmować niektóre z poprzednich zestawów wymagań. Obejmują one wygaśnięcie hasła i dozwolone znaki. Aby uzyskać pełną listę, zobacz Zasady haseł firmy Microsoft Entra. Rozważ zaawansowane wymuszanie przy użyciu zasad dostępu warunkowego, takich jak te oparte na ryzyku użytkownika, które wykryły wyciekły pary nazw użytkowników i haseł. Aby uzyskać więcej informacji, zobacz Dostęp warunkowy: dostęp warunkowy oparty na ryzyku użytkownika.

  Uwaga / Notatka

  Zdecydowanie zalecamy rozważenie opcji bez hasła. Aby uzyskać więcej informacji, zobacz Planowanie wdrożenia uwierzytelniania bez hasła w usłudze Microsoft Entra ID.

• Weryfikacja tożsamości użytkownika

  Zasady dostępu warunkowego ryzyka logowania można zastosować, aby wykryć, czy żądanie uwierzytelniania zostało wystawione przez żądającą tożsamość. Żądanie jest weryfikowane względem źródeł analizy zagrożeń. Obejmują one anomalie dotyczące sprayu haseł i adresów IP. Aby uzyskać więcej informacji, zobacz Dostęp warunkowy: dostęp warunkowy oparty na ryzyku.

Mogą istnieć składniki, które nie korzystają z identyfikatora Entra firmy Microsoft, takie jak dostęp do pól przesiadkowych za pomocą protokołu SSH. W takich przypadkach należy użyć szyfrowania klucza publicznego z co najmniej rozmiarem klucza RSA 2048. Zawsze określ hasło. Masz proces weryfikacji, który śledzi znane zatwierdzone klucze publiczne. Systemy korzystające z dostępu do kluczy publicznych nie mogą być uwidocznione w Internecie. Zamiast tego cały dostęp SSH powinien być dozwolony tylko za pośrednictwem pośrednika, takiego jak usługa Azure Bastion, w celu zmniejszenia wpływu wycieku klucza prywatnego. Wyłącz bezpośredni dostęp do haseł i użyj alternatywnego rozwiązania bez hasła.

Wymaganie 8.3

PCI DSS 4.0.1 nakazuje uwierzytelnianie wieloskładnikowe (MFA) dla wszystkich dostępu do środowiska danych posiadaczy kart (CDE), w tym użytkowników wewnętrznych. Mechanizmy kontroli uwierzytelniania wieloskładnikowego muszą być stale monitorowane i testowane pod kątem skuteczności.

Zabezpieczanie wszystkich indywidualnych dostępu administracyjnego bez konsoli i wszystkich zdalnych dostępu do usługi CDE przy użyciu uwierzytelniania wieloskładnikowego. Uwaga: Uwierzytelnianie wieloskładnikowe wymaga użycia co najmniej dwóch z trzech metod uwierzytelniania (zobacz Wymaganie 8.2 opisów metod uwierzytelniania). Użycie jednego czynnika dwa razy (na przykład przy użyciu dwóch oddzielnych haseł) nie jest uznawane za uwierzytelnianie wieloskładnikowe.

Twoje obowiązki

Zasady dostępu warunkowego umożliwiają wymuszanie uwierzytelniania wieloskładnikowego, w szczególności na kontach administracyjnych. Te zasady są zalecane w kilku rolach wbudowanych. Zastosuj te zasady do grup entra firmy Microsoft, które są mapowane na role kubernetes z wysokimi uprawnieniami.

Te zasady mogą być dodatkowo wzmocnione dodatkowymi zasadami, takimi jak:

• Uwierzytelnianie można ograniczyć do urządzeń zarządzanych przez dzierżawę firmy Microsoft Entra.
• Jeśli dostęp pochodzi z sieci spoza sieci klastra, możesz wymusić uwierzytelnianie wieloskładnikowe.

Aby uzyskać więcej informacji, zobacz:

• Dostęp warunkowy: wymaganie uwierzytelniania wieloskładnikowego dla administratorów
• Dostęp warunkowy: Wymagaj zgodnych urządzeń
• Dostęp warunkowy: uwierzytelnianie wieloskładnikowe oparte na ryzyku logowania

Wymaganie 8.4

PCI DSS 4.0.1 wymaga, aby procedury uwierzytelniania i zasady były regularnie przeglądane, aktualizowane i przekazywane wszystkim użytkownikom. Szkolenia dotyczące świadomości bezpieczeństwa muszą zawierać wskazówki dotyczące najlepszych rozwiązań uwierzytelniania i pojawiających się zagrożeń.

Dokumentowanie i komunikowanie procedur uwierzytelniania oraz zasad i procedur dla wszystkich użytkowników, w tym:

• Wskazówki dotyczące wybierania poświadczeń silnego uwierzytelniania.
• Wskazówki dotyczące ochrony poświadczeń uwierzytelniania przez użytkowników.
• Instrukcje nieużytowania poprzednio używanych haseł.
• Instrukcje dotyczące zmiany haseł, jeśli istnieje podejrzenie, że hasło może zostać naruszone.

Twoje obowiązki

Zachowaj dokumentację dotyczącą wymuszanych zasad. W ramach szkolenia dotyczącego dołączania tożsamości podaj wskazówki dotyczące procedur resetowania haseł i najlepszych rozwiązań organizacji dotyczących ochrony zasobów.

Wymaganie 8.5

PCI DSS 4.0.1 zabrania używania identyfikatorów grup, udostępnionych lub ogólnych dla wszystkich funkcji administracyjnych lub krytycznych i wymaga ciągłego monitorowania naruszeń.

Nie używaj grup, udostępnionych ani ogólnych identyfikatorów, haseł ani innych metod uwierzytelniania w następujący sposób:

• Ogólne identyfikatory użytkowników są wyłączone lub usuwane.
• Identyfikatory użytkowników udostępnionych nie istnieją w przypadku administrowania systemem i innych funkcji krytycznych.
• Udostępnione i ogólne identyfikatory użytkowników nie są używane do administrowania żadnymi składnikami systemu.

Twoje obowiązki

Nie udostępniaj ani nie używaj ponownie tożsamości dla funkcjonalnie różnych części klastra lub zasobników. Na przykład nie używaj konta zespołu do uzyskiwania dostępu do danych lub zasobów klastra. Upewnij się, że dokumentacja tożsamości nie korzysta z kont udostępnionych.

Wyłącz użytkowników głównych w usłudze CDE. Wyłącz użycie kont lokalnych platformy Kubernetes, aby użytkownicy nie mogli korzystać z wbudowanego --admin dostępu do klastrów w ramach usługi CDE.

Wymaganie 8.6

PCI DSS 4.0.1 wymaga, aby wszystkie mechanizmy uwierzytelniania (takie jak tokeny, karty inteligentne, certyfikaty) zostały przypisane do poszczególnych kont i nie są udostępniane. Aby zapewnić, że tylko zamierzone konto może korzystać z mechanizmu, należy stosować mechanizmy kontroli fizycznej i logicznej.

Jeśli są używane inne mechanizmy uwierzytelniania (na przykład fizyczne lub logiczne tokeny zabezpieczające, karty inteligentne, certyfikaty itp.), należy przypisać następujące mechanizmy:

• Mechanizmy uwierzytelniania muszą być przypisane do pojedynczego konta i nie są współużytkowane przez wiele kont.
• Fizyczne i/lub logiczne kontrolki muszą być spełnione, aby zapewnić, że tylko zamierzone konto może używać tego mechanizmu w celu uzyskania dostępu.

Twoje obowiązki

Upewnij się, że cały dostęp do usługi CDE jest udostępniany w tożsamościach poszczególnych użytkowników i że został rozszerzony na wszystkie tokeny fizyczne lub wirtualne. Obejmuje to dostęp sieci VPN do sieci CDE, zapewniając, że dostęp typu punkt-lokacja przedsiębiorstwa (jeśli istnieje) używa certyfikatów dla poszczególnych użytkowników w ramach tego przepływu uwierzytelniania.

Wymaganie 8.7

PCI DSS 4.0.1 wymaga, aby cały dostęp do baz danych zawierających dane posiadaczy kart był ograniczony i monitorowany, a dostęp aplikacji i użytkowników jest stale sprawdzany pod kątem odpowiedniości.

Cały dostęp do dowolnej bazy danych zawierającej dane karty (w tym dostęp aplikacji, administratorów i wszystkich innych użytkowników) jest ograniczony w następujący sposób:

• Cały dostęp użytkownika do, zapytania użytkowników i akcje użytkownika w bazach danych są za pośrednictwem metod programistycznych.
• Tylko administratorzy baz danych mogą uzyskiwać bezpośredni dostęp do baz danych lub wykonywać względem ich zapytań.
• Identyfikatory aplikacji dla aplikacji baz danych mogą być używane tylko przez aplikacje (a nie przez poszczególnych użytkowników lub inne procesy inne niż aplikacje).

Twoje obowiązki

Zapewnianie dostępu na podstawie ról i obowiązków. Użytkownicy mogą używać swojej tożsamości, ale dostęp musi być ograniczony na zasadzie konieczności znajomości z minimalnymi uprawnieniami stałymi. Użytkownicy nigdy nie powinni używać tożsamości aplikacji, a tożsamości dostępu do bazy danych nigdy nie muszą być udostępniane.

Jeśli to możliwe, uzyskaj dostęp do baz danych z aplikacji za pośrednictwem tożsamości zarządzanej. W przeciwnym razie ogranicz narażenie na parametry połączenia i poświadczenia. Użyj wpisów tajnych platformy Kubernetes, aby przechowywać poufne informacje zamiast przechowywać je w miejscach, w których można je łatwo odnaleźć, takich jak definicja zasobnika. Innym sposobem jest przechowywanie i ładowanie wpisów tajnych do i z zarządzanego magazynu zaprojektowanego pod kątem bezpiecznych danych, takich jak usługa Azure Key Vault. Po włączeniu tożsamości zarządzanych w klastrze usługi AKS musi on uwierzytelniać się w usłudze Key Vault, aby uzyskać dostęp.

Wymaganie 8.8

PCI DSS 4.0.1 wymaga, aby zasady zabezpieczeń i procedury operacyjne dotyczące identyfikacji i uwierzytelniania były stale sprawdzane, aktualizowane i przekazywane wszystkim stronom, których dotyczy problem.

Upewnij się, że zasady zabezpieczeń i procedury operacyjne dotyczące identyfikacji i uwierzytelniania 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. Zachowaj dokumentację dotyczącą wymuszanych zasad. W ramach szkolenia dotyczącego dołączania tożsamości podaj wskazówki dotyczące procedur resetowania haseł i najlepszych rozwiązań organizacji dotyczących ochrony zasobów. 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, które są częścią procesu zatwierdzania z perspektywy zasad.

Wymaganie 9: Ograniczanie fizycznego dostępu do danych posiadaczy kart

Obsługa funkcji usługi AKS

Nie ma żadnych odpowiednich funkcji usługi AKS dla tego wymagania.

Twoje obowiązki

Ta architektura i implementacja nie są zaprojektowane w celu zapewnienia kontroli dostępu fizycznego do zasobów lokalnych lub centrów danych. Aby zapoznać się z zagadnieniami, zapoznaj się ze wskazówkami w oficjalnym standardzie PCI-DSS 4.0.1.

Poniżej przedstawiono kilka sugestii dotyczących stosowania mechanizmów kontroli technicznej:

• Dostrajanie limitów czasu sesji w dowolnym dostępie do konsoli administracyjnej, takich jak pola przesiadkowe w usłudze CDE, aby zminimalizować dostęp.

• Dostosuj zasady dostępu warunkowego, aby zminimalizować czas wygaśnięcia tokenów dostępu platformy Azure z punktów dostępu, takich jak witryna Azure Portal. Aby uzyskać informacje, zobacz następujące artykuły:

  • Konfigurowanie zasad okresu istnienia sesji adaptacyjnej
  • Konfigurowalne okresy istnienia tokenów na platformie tożsamości Microsoft

• W przypadku usługi CDE hostowanej w chmurze nie ma żadnych obowiązków związanych z zarządzaniem dostępem fizycznym i sprzętem. Polegaj na kontrolce fizycznej i logicznej sieci firmowej.

• Zminimalizuj eksportowanie kopii zapasowych CHD do lokalnych miejsc docelowych. Użyj rozwiązań hostowanych na platformie Azure, aby ograniczyć fizyczny dostęp do kopii zapasowych.

• Zminimalizuj kopie zapasowe do środowiska lokalnego. Jeśli jest to wymagane, należy pamiętać, że lokalna lokalizacja docelowa będzie w zakresie inspekcji.

Dalsze kroki

Zaimplementuj rozszerzone wymagania dotyczące uwierzytelniania wieloskładnikowego (MFA) w celu zapewnienia bezpiecznego dostępu do środowiska danych posiadaczy kart.