Zarządzanie dostępem klastra bazowego usługi AKS dla standardu PCI-DSS 3.2.1 (część 6 z 9)

W tym artykule opisano zagadnienia dotyczące klastra usługi Azure Kubernetes Service (AKS), który jest skonfigurowany zgodnie z standardem Payment Card Industry Data Security Standard (PCI-DSS 3.2.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 wykonywanie przypisań ról do użytkowników firmy Microsoft Entra. Funkcja RBAC firmy Microsoft obsługuje definicje ról, takie jak osoba przeglądająca, zapis, administrator usługi, administrator klastra jako wbudowane role. Ponadto można tworzyć role niestandardowe w celu uzyskania bardziej szczegółowej kontroli.

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 udzielonych 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 kubernetes i zabezpieczania klastra za pomocą usługi Azure Policy).

Twoje obowiązki

Wymaganie	Odpowiedzialność
Wymaganie 7.1	Ogranicz dostęp do składników systemowych i danych posiadaczy kart tylko tym osobom, których zadanie wymaga takiego dostępu.
Wymaganie 7.2	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.
Wymaganie 7.3	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.

Wymaganie 7.1

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

Oto kilka zagadnień:

• Upewnij się, że implementacja jest zgodna z wymaganiami organizacji i 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

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 osoba odpowiedzialna za utrzymanie bezpieczeństwa, izolacji, wdrażania i możliwości obserwacji. Oto kilka przykładów:

• Decyzje dotyczące zabezpieczeń aplikacji, kontroli dostępu opartej na rolach platformy Kubernetes, zasad sieciowych, zasad platformy Azure i komunikacji z innymi usługami.
• Konfiguracja i konserwacja usługi Azure Firewall, zapory aplikacji internetowej (WAF), sieciowych grup zabezpieczeń i konfiguracji DNS.
• Monitoruj i koryguj zabezpieczenia serwera, stosowanie poprawek, konfigurację i zabezpieczenia punktu końcowego.
• Ustaw kierunek użycia kontroli dostępu opartej na rolach, Microsoft Defender dla Chmury, strategii ochrony administratora i usługi Azure Policy, aby zarządzać zasobami platformy Azure.
• Zespół ds. monitorowania i reagowania na zdarzenia. Zbadaj i koryguj zdarzenia zabezpieczeń w zarządzaniu informacjami i zdarzeniami zabezpieczeń (SIEM) 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. Oto prosta definicja ilustracyjna.

Rola	Zakres odpowiedzialności	Poziomy dostępu
Właściciele aplikacji	Definiowanie i określanie priorytetów funkcji dostosowanych do wyników biznesowych. Rozumieją, w jaki sposób funkcje wpływają na zakres zgodności obciążenia, oraz równoważą ochronę danych klientów i własność przy użyciu celów biznesowych.	Odczyt dostępu do dzienników i metryk emitowanych przez aplikację. Nie potrzebują uprawnień dostępu do obciążenia ani klastra.
Deweloperzy aplikacji	Opracowywanie aplikacji. Cały kod aplikacji podlega szkoleniu i bramom jakości podtrzymujących zgodność, zaświadczanie i procesy zarządzania wydaniami. Może zarządzać potokami kompilacji, ale zwykle nie potokami wdrażania.	Odczyt dostępu do przestrzeni nazw platformy Kubernetes i zasobów platformy Azure, które znajdują się w zakresie obciążenia. Brak dostępu do zapisu na potrzeby wdrażania ani modyfikowania żadnego stanu systemu.
Operatory aplikacji (lub SRE)	Zapoznaj się z bazą kodu, obserwacją i operacjami. Czy klasyfikacja na żywo witryny i rozwiązywanie problemów. Wraz z deweloperami aplikacji zwiększ dostępność, skalowalność i wydajność aplikacji. Zarządzanie potokiem wdrażania "ostatniej mili" i zarządzanie potokami kompilacji.	Wysoce uprzywilejowane w zakresie aplikacji, która obejmuje powiązane przestrzenie nazw kubernetes i zasoby platformy Azure. Prawdopodobnie masz stały dostęp do części klastra Kubernetes.
Właściciele infrastruktury	Projektowanie ekonomicznej architektury, w tym jej łączności i funkcjonalności składników. Zakres może obejmować usługi w chmurze i lokalne. Wybieranie możliwości przechowywania danych, funkcji ciągłości działania i innych.	Dostęp do dzienników platformy i danych centrum kosztów. W klastrze nie jest wymagany żaden dostęp.
Operatory infrastruktury (lub SRE)	Operacje związane z klastrem i usługami zależniami. Kompilowanie, wdrażanie i uruchamianie potoku dla klastra, w którym jest wdrażane obciążenie. Ustaw docelowe pule węzłów oraz oczekiwane wymagania dotyczące rozmiaru i skalowania. Monitorowanie kondycji infrastruktury hostingu kontenerów i usług zależnych.	Dostęp do odczytu do przestrzeni nazw obciążeń. Wysoce uprzywilejowany dostęp dla klastra.
Zasady, właściciele zabezpieczeń	Posiadaj wiedzę na temat zgodności z zabezpieczeniami lub regulacjami. Zdefiniuj zasady, które chronią zgodność z zabezpieczeniami i przepisami pracowników firmy, jej zasobów i klientów firmy. Współpracuje ze wszystkimi innymi rolami, aby upewnić się, że zasady są stosowane i poddawane inspekcji w każdej fazie.	Odczyt dostępu do obciążenia i klastra. Dostęp również do danych dzienników i inspekcji.
Operatory sieciowe	Alokacja sieci wirtualnej i podsieci dla całego przedsiębiorstwa. Konfiguracja i konserwacja usługi Azure Firewall, zapory aplikacji internetowej, sieciowych grup zabezpieczeń i konfiguracji DNS.	Wysoce uprzywilejowane w warstwie sieci. Brak uprawnień do zapisu w klastrze.

Wymaganie 7.1.2

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ń. Oto kilka najlepszych rozwiązań:

• Tożsamość powinna mieć wystarczający dostęp do wykonania zadania.
• 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

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ładów.

Klasyfikacja zadań	Rola
Właściciel produktu definiuje zakres obciążenia i określa priorytety funkcji. Równoważy ochronę danych klientów i własność przy użyciu celów biznesowych. Wymaga dostępu do raportów, centrum kosztów lub pulpitów nawigacyjnych platformy Azure. W przypadku uprawnień na poziomie klastra lub klastra nie jest wymagany żaden dostęp.	Właściciele aplikacji
Inżynier oprogramowania projektuje, opracowuje i konteneryzuje kod aplikacji. Grupa ze stałymi uprawnieniami do odczytu w zdefiniowanych zakresach na platformie Azure (na przykład application insights) i przestrzeniami nazw obciążeń. Te zakresy i uprawnienia mogą być różne między środowiskami przedprodukcyjnymi i produkcyjnymi.	Deweloper aplikacji
Inżynier niezawodności lokacji wykonuje klasyfikację lokacji na żywo, zarządza potokami i konfiguruje infrastrukturę aplikacji. Grupuj A z pełną kontrolą w przydzielonych przestrzeniach nazw. Uprawnienia stałe nie są wymagane. Grupa B dla codziennych operacji na obciążeniu. Może mieć uprawnienia stałe w przydzielonych przestrzeniach nazw, ale nie są wysoce uprzywilejowane.	Operatory aplikacji
Operator klastra projektuje i wdraża niezawodny i bezpieczny klaster usługi AKS na platformie. Odpowiedzialny za utrzymywanie czasu pracy klastra. Grupuj A z pełną kontrolą w przydzielonych przestrzeniach nazw. Uprawnienia stałe nie są wymagane. Grupa B dla codziennych operacji na obciążeniu. Może mieć uprawnienia stałe w przydzielonych przestrzeniach nazw, ale nie są wysoce uprzywilejowane.	Operatorzy infrastruktury
Inżynier sieci przydziela sieć wirtualną i podsieci w całym przedsiębiorstwie, lokalnie do łączności w chmurze i zabezpieczeń sieci.	Operatorzy infrastruktury

Wymaganie 7.1.4

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

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 kontroli dostępu opartej na rolach (RBAC) infrastruktury. Ten mechanizm może być:

• Kontrola dostępu oparta na rolach platformy Kubernetes to natywny model autoryzacji Kubernetes, który kontroluje dostęp do płaszczyzny sterowania Kubernetes uwidocznione 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 to 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. Istnieją dwa podejścia. Możesz wybrać wbudowane role. Lub jeśli wbudowane role nie spełniają Twoich wymagań (na przykład mogą być nadmiernie permissive), utwórz 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.

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 zasoby platformy Azure, a nawet zasobniki 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.

Oto kilka najlepszych rozwiązań:

• Zachowaj skrupulatną dokumentację dotyczącą każdej roli i przypisanych uprawnień. Zachowaj jasne rozróżnienie dotyczące uprawnień JIT i które stoją.

• Monitoruj role pod kątem zmian, takich jak zmiany przypisania lub definicje ról. Twórz alerty dotyczące zmian, nawet jeśli oczekuje się, że uzyskają wgląd w intencje związane ze zmianami.

Wymaganie 7.2.1

Pokrycie wszystkich składników systemu

Twoje obowiązki

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

• 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

  Wybór technologii JIT i dostępu warunkowego wymaga identyfikatora P1 lub P2 firmy Microsoft.

• Najlepiej wyłączyć 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

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

Domyślne ustawienie "deny-all".

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 odwrotnie odrzucają wszystkie ustawienia.

• 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 są odwrotne dla ustawienia odmowy wszystkich.

• Wszystkie usługi platformy Azure, usługa Azure Key Vault i usługa Azure Container Registry domyślnie odrzucają wszystkie zestawy uprawnień.

• Wszystkie punkty dostępu administracyjnego, takie jak serwer przesiadkowy, powinny blokować cały dostęp w początkowej konfiguracji. Wszystkie podniesione uprawnienia muszą być zdefiniowane jawnie w celu odmowy wszystkich reguł.

Wymaganie 7.3

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 identyfikatorami 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	Odpowiedzialność
Wymaganie 8.1	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:
Wymaganie 8.2	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:
Wymaganie 8.3	Zabezpieczanie wszystkich indywidualnych dostępu administracyjnego bez konsoli i wszystkich zdalnych dostępu do usługi CDE przy użyciu uwierzytelniania wieloskładnikowego.
Wymaganie 8.4	Dokumentowanie i komunikowanie procedur uwierzytelniania oraz zasad i procedur dla wszystkich użytkowników, w tym:
Wymaganie 8.5	Nie używaj grup, udostępnionych ani ogólnych identyfikatorów, haseł ani innych metod uwierzytelniania w następujący sposób:
Wymaganie 8.6	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:
Wymaganie 8.7	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:
Wymaganie 8.8	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.

Wymaganie 8.1

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:

• 8.1.1 Przypisz wszystkim użytkownikom unikatowy identyfikator przed zezwoleniem im na dostęp do składników systemowych lub danych posiadaczy kart.
• 8.1.2 Kontrolowanie dodawania, usuwania i modyfikowania identyfikatorów użytkowników, poświadczeń i innych obiektów identyfikatorów.
• 8.1.3 Natychmiastowe odwoływanie dostępu dla wszystkich zakończonych użytkowników.
• 8.1.4 Usuń/wyłącz nieaktywne konta użytkowników w ciągu 90 dni.
• 8.1.5 Zarządzanie identyfikatorami używanymi przez inne firmy do uzyskiwania dostępu, obsługi lub obsługi składników systemu za pośrednictwem dostępu zdalnego w następujący sposób:
  • Włączone tylko w okresie wymaganym i wyłączonym, gdy nie jest używany.
  • Monitorowane w przypadku użycia.
• 8.1.6 Ogranicz powtarzające się próby dostępu, blokując identyfikator użytkownika po nie więcej niż sześciu próbach.
• 8.1.7 Ustaw czas trwania blokady na co najmniej 30 minut lub do momentu włączenia przez administratora identyfikatora użytkownika.
• 8.1.8 Jeśli sesja była bezczynna przez ponad 15 minut, wymagaj od użytkownika ponownego uwierzytelnienia w celu ponownego aktywowania terminalu lub sesji.

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, gdy używasz Tożsamość obciążeń Microsoft Entra 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 używaj tej samej tożsamości zarządzanej w środowisku przedprodukcyjnym i produkcyjnym.

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 odwołanie dostępu do identyfikatora Entra firmy Microsoft jest stosowane automatycznie do wszystkich zasobów. Jeśli istnieją jakiekolwiek składniki, które nie są bezpośrednio wspierane przez microsoft Entra ID, 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

Skorzystaj z usługi Microsoft Entra business-to-business (B2B), która jest przeznaczona do hostowania kont innych firm, takich jak dostawcy, 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 Co to jest dostęp użytkowników-gości w usłudze Microsoft Entra B2B.

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

DOTYCZY: 8.1.6, 8.1.7, 8.1.8

Twoje obowiązki

Microsoft Entra ID udostępnia funkcję inteligentnego blokowania w celu blokowania 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 za pomocą 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 protokół SSH lub pulpit zdalny 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

Oprócz przypisania unikatowego identyfikatora upewnij się, że prawidłowe zarządzanie uwierzytelnianiem użytkowników nieużytkowników i administratorów we wszystkich składnikach systemu polega na użyciu co najmniej jednej z następujących metod uwierzytelniania wszystkich użytkowników: coś, co wiesz, takie jak hasło lub hasło, coś, co masz, takie jak urządzenie tokenowe lub karta inteligentna, coś, co masz, coś, co masz na przykład biometryczne.

• 8.2.1 Przy użyciu silnej kryptografii renderuj wszystkie poświadczenia uwierzytelniania (takie jak hasła/frazy) nie do odczytania podczas transmisji i przechowywania we wszystkich składnikach systemu.
• 8.2.2 Sprawdź tożsamość użytkownika przed zmodyfikowaniem jakichkolwiek poświadczeń uwierzytelniania — na przykład wykonywanie resetowania haseł, aprowizowanie nowych tokenów lub generowanie nowych kluczy.
• 8.2.3 Hasła/frazy muszą spełniać następujące wymagania:
  • Wymagaj minimalnej długości co najmniej siedmiu znaków.
  • Zawiera zarówno znaki liczbowe, jak i alfabetyczne.
• 8.2.4 Zmień hasła użytkownika co najmniej raz na 90 dni.
• 8.2.5 Nie zezwalaj użytkownikowi na przesłanie nowego hasła/frazy, która jest taka sama jak dowolne z czterech ostatnich haseł/fraz, których użyła.
• 8.2.6 Ustaw hasła/frazy po raz pierwszy i po zresetowaniu do unikatowej wartości dla każdego użytkownika i zmień je natychmiast po pierwszym użyciu.

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. Rozważ dodanie funkcji ochrony haseł firmy Microsoft w celu utworzenia listy zakazów specyficznych dla organizacji. 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ż użycie zaawansowanych funkcji, które można wymusić za pomocą zasad dostępu warunkowego, takich jak te oparte na ryzyku użytkownika, które wykryły wyciekły nazwy użytkownika i pary haseł. Aby uzyskać więcej informacji, zobacz Dostęp warunkowy: dostęp warunkowy oparty na ryzyku użytkownika.

  Uwaga

  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 za pośrednictwem pośrednika, takiego jak usługa Azure Bastion, aby zmniejszyć wpływ wycieku klucza prywatnego. Wyłącz bezpośredni dostęp do haseł i użyj alternatywnego rozwiązania bez hasła.

Wymaganie 8.3

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 można dodatkowo wzmocnić dzięki dodatkowym zasadom. Oto kilka przykładów:

• 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
• Instrukcje: wymaganie urządzeń zarządzanych na potrzeby dostępu do aplikacji w chmurze przy użyciu dostępu warunkowego
• Instrukcje: wymaganie uwierzytelniania wieloskładnikowego w celu uzyskania dostępu z niezaufanych sieci przy użyciu dostępu warunkowego

Wymaganie 8.4

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

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

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 jest on 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

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 bazy 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, takiego 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

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 wziąć pod uwagę uwagi, zapoznaj się ze wskazówkami w oficjalnym standardzie PCI-DSS 3.2.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:

  • Skonfiguruj zarządzanie sesją uwierzytelniania z użyciem dostępu warunkowego
  • Konfigurowalne okresy istnienia tokenu — Platforma 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.

Następne kroki

Śledź i monitoruj cały dostęp do zasobów sieciowych i danych karty. Regularnie testuj systemy zabezpieczeń i procesy.