Správa přístupu ke standardnímu clusteru AKS pro PCI-DSS 3.2.1 (část 6 z 9)

Tento článek popisuje aspekty clusteru Azure Kubernetes Service (AKS), který je nakonfigurovaný v souladu se standardem PCI-DSS 3.2.1 ( Payment Card Industry Data Security Standard).

Tento článek je součástí série článků. Přečtěte si úvod.

Kubernetes má nativní řízení přístupu na základě role (RBAC), které spravuje oprávnění k rozhraní Kubernetes API. Pro prostředky Kubernetes existuje několik předdefinovaných rolí s konkrétními oprávněními nebo akcemi. Azure Kubernetes Service (AKS) podporuje tyto předdefinované role a vlastní role pro podrobné řízení. Tyto akce je možné autorizovat (nebo odepřít) uživateli prostřednictvím RBAC Kubernetes.

Tato architektura a implementace nejsou navržené tak, aby poskytovaly kontroly fyzického přístupu k místním prostředkům nebo datovým centrům. Jednou z výhod hostování cde v Azure na rozdíl od platformy na hraničních zařízeních nebo v datacentru je to, že omezení fyzického přístupu se většinou zpracovává prostřednictvím zabezpečení datacentra Azure. Ve správě fyzického hardwaru nejsou pro organizaci žádné zodpovědnosti.

Implementace měr silného řízení přístupu

Požadavek 7 – Omezení přístupu k datům držitelů karet podle obchodních potřeb

Podpora funkcí AKS

AKS je plně integrován s Microsoft Entra ID jako zprostředkovatel identity.

Pro Kubernetes nemusíte spravovat samostatné identity uživatelů a přihlašovací údaje. Můžete přidat uživatele Microsoft Entra pro RBAC Kubernetes. Tato integrace umožňuje provádět přiřazení rolí uživatelům Microsoft Entra. Microsoft Entra RBAC podporuje definice rolí, jako je prohlížeč, zapisovač, správce služeb, správce clusteru jako předdefinované role. Můžete také vytvořit vlastní role pro podrobnější řízení.

Azure RBAC je ve výchozím nastavení nastavený tak, aby odepřel všechny prostředky, takže k prostředku nelze získat přístup bez udělených oprávnění. AKS omezuje přístup SSH k pracovním uzlům AKS a používá zásady sítě AKS k řízení přístupu k úlohám v podech.

Další informace najdete v tématu Použití Azure RBAC pro autorizaci Kubernetes a zabezpečení clusteru pomocí Azure Policy.

Vaše odpovědnosti

Požadavek	Odpovědnost
Požadavek 7.1	Omezte přístup k systémovým komponentám a datům držitelů karet jenom na jednotlivce, jejichž úloha vyžaduje takový přístup.
Požadavek 7.2	Vytvořte systém řízení přístupu pro systémové komponenty, které omezují přístup na základě potřeby uživatele a je nastaven na "odepřít vše", pokud to výslovně není povoleno.
Požadavek 7.3	Ujistěte se, že zásady zabezpečení a provozní postupy pro omezení přístupu k datům držitelů karet jsou zdokumentované, používané a známé všem ovlivněným stranám.

Požadavek 7.1

Omezte přístup k systémovým komponentám a datům držitelů karet jenom na jednotlivce, jejichž úloha vyžaduje takový přístup.

Vaše odpovědnosti

Tady je několik aspektů:

• Ujistěte se, že vaše implementace odpovídá požadavkům organizace a požadavkům na dodržování předpisů týkajících se správy identit.
• Minimalizujte stálá oprávnění zejména pro účty s kritickým dopadem.
• Dodržujte zásadu přístupu s nejnižšími oprávněními. Zadejte dostatečný přístup k dokončení úkolu.

Požadavek 7.1.1

Definujte potřeby přístupu pro každou roli, včetně:

• Systémové komponenty a datové prostředky, ke kterým každá role potřebuje přístup pro svou funkci úlohy
• Požadovaná úroveň oprávnění (například uživatel, správce atd.) pro přístup k prostředkům.

Vaše odpovědnosti

Definujte role na základě úloh a zodpovědností požadovaných pro komponenty v oboru a jejich interakci s prostředky Azure. Můžete začít s širokými kategoriemi, například:

• Rozsah podle skupin pro správu, předplatných nebo skupin prostředků Azure
• Azure Policy pro úlohu nebo předplatné
• Operace s kontejnery
• Správa tajných kódů
• Kanály sestavení a nasazení

I když definice rolí a zodpovědností v těchto oblastech může být přidružená ke struktuře týmu, zaměřte se na požadavek úlohy. Kdo je například zodpovědný za udržování zabezpečení, izolace, nasazení a pozorovatelnosti. Zde je uvedeno několik příkladů:

• Rozhodnutí o zabezpečení aplikací, řízení přístupu na základě role Kubernetes, zásadách sítě, zásadách Azure a komunikaci s dalšími službami
• Konfigurace a údržba služby Azure Firewall, firewallu webových aplikací (WAF), skupin zabezpečení sítě (NSG) a konfigurace DNS
• Monitorování a náprava zabezpečení serveru, opravy, konfigurace a zabezpečení koncových bodů
• Nastavte směr použití RBAC, Microsoft Defenderu pro cloud, strategie ochrany Správa istratoru a Azure Policy pro řízení prostředků Azure.
• Tým pro monitorování incidentů a reakce. Zkoumání a náprava incidentů zabezpečení v informacích o zabezpečení a správě událostí (SIEM) nebo v programu Microsoft Defender for Cloud

Potom definici formalizujte určením úrovně přístupu, která se vyžaduje pro roli s ohledem na úlohu a infrastrukturu. Tady je jednoduchá definice ilustrativních účelů.

Role	Odpovědnosti	Úrovně přístupu
Vlastníci aplikací	Definujte a upřednostňování funkcí v souladu s obchodními výsledky. Rozumí tomu, jak funkce ovlivňují rozsah úloh dodržování předpisů, a vyrovnávají ochranu a vlastnictví zákaznických dat s obchodními cíli.	Čtení přístupu k protokolům a metrikám vygenerovaným aplikací Nepotřebují oprávnění pro přístup k úloze nebo clusteru.
Vývojáři aplikací	Vyvíjejte aplikaci. Veškerý kód aplikace podléhá trénování a branám kvality, které dodržují procesy dodržování předpisů, ověření identity a správy verzí. Může spravovat kanály buildu, ale obvykle ne kanály nasazení.	Čtení přístupu k oborům názvů Kubernetes a prostředkům Azure, které jsou v oboru úlohy. Žádný přístup k zápisu pro nasazení nebo úpravu stavu systému.
Operátory aplikací (nebo SRE)	Máte hluboké znalosti základu kódu, pozorovatelnosti a operací. Proveďte třídění a řešení potíží s živým webem. Spolu s vývojáři aplikací můžete zlepšit dostupnost, škálovatelnost a výkon aplikace. Spravujte kanál nasazení "poslední míle" a spravujte kanály buildu.	Vysoce privilegované v rámci aplikace, která zahrnuje související obory názvů Kubernetes a prostředky Azure. Pravděpodobně mají trvalý přístup k částem clusteru Kubernetes.
Vlastníci infrastruktury	Navrhujte nákladově efektivní architekturu, včetně jejího připojení a funkčnosti komponent. Rozsah může zahrnovat cloudové a místní služby. Rozhodněte se o možnostech uchovávání dat, funkcí provozní kontinuity a dalších.	Přístup k protokolům platformy a datům nákladového centra V rámci clusteru není vyžadován žádný přístup.
Operátory infrastruktury (nebo SRE)	Operace související s clusterem a závislými službami Sestavte, nasaďte a spusťte kanál pro cluster, ve kterém je úloha nasazená. Nastavte fondy uzlů a očekávané požadavky na změnu velikosti a škálování. Monitorujte stav infrastruktury hostování kontejneru a závislých služeb.	Přístup pro čtení k oborům názvů úloh Vysoce privilegovaný přístup ke clusteru.
Zásady, vlastníci zabezpečení	Máte zkušenosti s dodržováním předpisů nebo zabezpečením. Definujte zásady, které chrání zabezpečení a dodržování právních předpisů zaměstnanců společnosti, jejích aktiv a zákazníků společnosti. Spolupracuje se všemi ostatními rolemi, aby se zajistilo, že se zásady použijí a auditují v každé fázi.	Čtení přístupu k úloze a clusteru Také přístup k datům protokolu a auditu.
Síťové operátory	Přidělování virtuálních sítí a podsítí pro celou organizaci Konfigurace a údržba služby Azure Firewall, WAF, NSG a konfigurace DNS	Vysoce privilegované v síťové vrstvě. V clusteru není žádné oprávnění k zápisu.

Požadavek 7.1.2

Omezte přístup k ID privilegovaných uživatelů na nejnižší oprávnění potřebná k provádění odpovědnosti za úlohy.

Vaše odpovědnosti

Na základě funkcí úloh se snažte minimalizovat přístup, aniž by to způsobilo přerušení. Tady jsou některé osvědčené postupy:

• Identita by měla mít dostatečný přístup k dokončení úkolu.
• Minimalizujte stálá oprávnění, zejména u identit s kritickým dopadem, které mají přístup k komponentám v oboru.
• Pokud je to možné, přidejte další omezení. Jedním ze způsobů je poskytnutí podmíněného přístupu na základě kritérií přístupu.
• Proveďte pravidelnou kontrolu a audit uživatelů a skupin, kteří mají přístup k vašim předplatným, a to i pro čtení. Vyhněte se pozvání externích identit.

Požadavek 7.1.3

Přiřaďte přístup na základě klasifikace a funkce jednotlivých pracovníků.

Vaše odpovědnosti

Určete oprávnění na základě jasně přiřazených pracovních povinností jednotlivce. Vyhněte se parametrům, jako je systém nebo výdrž zaměstnance. Udělení přístupových práv jednomu uživateli nebo skupině

Zde je uvedeno několik příkladů.

Klasifikace úloh	Role
Vlastník produktu definuje rozsah úloh a určuje prioritu funkcí. Vyrovnává ochranu a vlastnictví zákaznických dat s obchodními cíli. Potřebuje přístup k sestavám, nákladovým centru nebo řídicím panelům Azure. Pro oprávnění na úrovni clusteru nebo clusteru není potřeba žádný přístup.	Vlastníci aplikací
Softwarový inženýr navrhuje, vyvíjí a kontejnerizuje kód aplikace. Skupina s trvalými oprávněními ke čtení v rámci definovaných oborů v Rámci Azure (například application Přehledy) a obory názvů úloh. Tyto obory a oprávnění se můžou lišit mezi předprodukčním a produkčním prostředím.	Vývojář aplikací
Technik spolehlivosti lokality provede třídění živého webu, spravuje kanály a nastavuje infrastrukturu aplikací. Seskupte A s úplným řízením v rámci přidělených oborů názvů. Nepožadují se požadovaná oprávnění. Skupina B pro každodenní operace v úloze Může mít oprávnění k umístění v rámci přidělených oborů názvů, ale nejsou vysoce privilegovaná.	Operátory aplikací
Operátor clusteru navrhne a nasadí do platformy spolehlivý a zabezpečený cluster AKS. Zodpovídá za udržování doby vydržování clusteru. Seskupte A s úplným řízením v rámci přidělených oborů názvů. Nepožadují se požadovaná oprávnění. Skupina B pro každodenní operace v úloze Může mít oprávnění k umístění v rámci přidělených oborů názvů, ale nejsou vysoce privilegovaná.	Operátory infrastruktury
Síťový inženýr přiděluje podnikové virtuální sítě a podsítě, místní připojení ke cloudu a zabezpečení sítě.	Operátory infrastruktury

Požadavek 7.1.4

Vyžadovat zdokumentované schválení autorizovanými stranami, které určují požadovaná oprávnění.

Vaše odpovědnosti

Uchvácený proces schvalování změn v rolích a oprávněních, včetně počátečního přiřazení oprávnění. Ujistěte se, že jsou tato schválení zdokumentovaná a dostupná pro kontrolu.

Požadavek 7.2

Vytvořte systém řízení přístupu pro systémové komponenty, které omezují přístup na základě potřeby uživatele a je nastaven na "odepřít vše", pokud to výslovně není povoleno.

Vaše odpovědnosti

Po splnění následujícího požadavku 7.1 byste měli posoudit role a zodpovědnosti, které platí pro vaši organizaci a úlohy. Všechny komponenty v architektuře, které jsou v oboru, musí mít omezený přístup. To zahrnuje uzly AKS, které spouštějí úlohy, úložiště dat, síťový přístup a všechny ostatní služby, které se účastní zpracování dat držitelů karet (CHD).

Na základě rolí a zodpovědností přiřaďte role k řízení přístupu na základě role (RBAC) infrastruktury. Tento mechanismus může být:

• Kubernetes RBAC je nativní autorizační model Kubernetes, který řídí přístup k řídicí rovině Kubernetes, vystavený prostřednictvím serveru rozhraní KUBERNEtes API. Tato sada oprávnění definuje, co můžete dělat se serverem rozhraní API. Můžete například uživateli odepřít oprávnění k vytvoření nebo dokonce výpisu podů.
• Azure RBAC je autorizační model založený na ID Microsoftu Entra, který řídí přístup k řídicí rovině Azure. Toto je přidružení tenanta Microsoft Entra k vašemu předplatnému Azure. Pomocí Azure RBAC můžete udělit oprávnění k vytváření prostředků Azure, jako jsou sítě, cluster AKS a spravované identity.

Předpokládejme, že potřebujete udělit oprávnění operátorům clusteru (namapované na roli operátora infrastruktury). Všechny osoby, které mají přiřazenou odpovědnost operátora infrastruktury, patří do skupiny Microsoft Entra. Jak je uvedeno ve verzi 7.1.1, tato role vyžaduje v clusteru nejvyšší oprávnění. Kubernetes má předdefinované role RBAC, například cluster-admin, které splňují tyto požadavky. Skupinu Microsoft Entra pro operátora cluster-admin infrastruktury budete muset svázat vytvořením vazeb rolí. Existují dva přístupy. Můžete zvolit předdefinované role. Nebo pokud předdefinované role nevyhovují vašim požadavkům (například můžou být příliš permissivní), vytvořte pro vazby vlastní role.

Referenční implementace ukazuje předchozí příklad pomocí nativního řízení přístupu na základě role Kubernetes. Stejné přidružení je možné provést pomocí Azure RBAC. Další informace najdete v tématu Řízení přístupu k prostředkům clusteru pomocí řízení přístupu na základě role Kubernetes a identit Microsoft Entra ve službě Azure Kubernetes Service.

Můžete zvolit obor oprávnění na úrovni clusteru nebo na úrovni oboru názvů. Pro role s vymezenými odpovědnostmi, jako jsou například operátory aplikací, jsou oprávnění přiřazena na úrovni oboru názvů pro danou úlohu.

Kromě toho role také potřebují oprávnění Azure RBAC, aby mohly provádět své úkoly. Operátor clusteru například potřebuje přístup ke službě Azure Monitor prostřednictvím portálu. Proto musí mít role operátora infrastruktury odpovídající přiřazení RBAC.

Kromě lidí a jejich rolí mají prostředky Azure a dokonce i pody v clusteru spravované identity. Tyto identity potřebují sadu oprávnění prostřednictvím Azure RBAC a musí být úzce vymezeny na základě očekávaných úloh. Například Aplikace Azure Gateway musí mít oprávnění k získání tajných kódů (certifikátů TLS) ze služby Azure Key Vault. Nesmí mít oprávnění k úpravě tajných kódů.

Tady jsou některé osvědčené postupy:

• Udržujte si pečlivou dokumentaci o jednotlivých rolích a přiřazených oprávněních. Mějte přehled o tom, která oprávnění jsou JIT a která stojí.

• Monitorujte role pro změny, jako jsou změny přiřazení nebo definice rolí. Vytvořte upozornění na změny, i když se očekává, že získají přehled o záměrech za změnami.

Požadavek 7.2.1

Pokrytí všech systémových komponent

Vaše odpovědnosti

Tady je několik osvědčených postupů pro zachování měr řízení přístupu:

• Nemáte přístup. Zvažte použití členství ve skupině AD za běhu. Tato funkce vyžaduje Microsoft Entra Privileged Identity Management.

• Nastavte zásady podmíněného přístupu v Microsoft Entra ID pro váš cluster. Tím se dále omezí přístup k řídicí rovině Kubernetes. Pomocí zásad podmíněného přístupu můžete vyžadovat vícefaktorové ověřování, omezit ověřování na zařízení spravovaná vaším tenantem Microsoft Entra nebo blokovat nestandardní pokusy o přihlášení. Tyto zásady použijte u skupin Microsoft Entra, které jsou mapované na role Kubernetes s vysokými oprávněními.

  Poznámka

  Možnosti technologie JIT i podmíněného přístupu vyžadují Microsoft Entra ID P1 nebo P2.

• V ideálním případě zakažte přístup SSH k uzlům clusteru. Tato referenční implementace negeneruje podrobnosti připojení SSH pro tento účel.

• Ke všem dalším výpočetním prostředkům, jako jsou jump boxy, musí přistupovat autorizovaní uživatelé. Nevytvádřujte obecná přihlášení dostupná pro celý tým.

Požadavek 7.2.2

Přiřazení oprávnění jednotlivcům na základě klasifikace a funkce úlohy.

Vaše odpovědnosti

Na základě verze 7.1.3 bude do operací clusteru zapojeno mnoho rolí. Kromě standardních rolí prostředků Azure budete muset definovat rozsah a proces přístupu.

Představte si například roli operátora clusteru. Měly by mít jasně definovaný playbook pro aktivity třídění clusterů. Jak se liší přístup od týmu úloh? V závislosti na vaší organizaci můžou být stejné. Tady je několik bodů, které je potřeba vzít v úvahu:

• Jak mají získat přístup ke clusteru?
• Které zdroje mají povolený přístup?
• Jaká oprávnění mají mít v clusteru?
• Kdy jsou tato oprávnění přiřazená?

Ujistěte se, že definice jsou popsané v dokumentaci k zásadám správného řízení, zásadám a školicím materiálům týkajícím se operátora úloh a operátora clusteru.

Požadavek 7.2.3

Výchozí nastavení "odepřít vše".

Vaše odpovědnosti

Při spuštění konfigurace začněte zásadami nulové důvěryhodnosti. Podle potřeby proveďte výjimky a podrobně je zdokumentujte.

• Kubernetes RBAC implementuje ve výchozím nastavení odepření . Nepřepisujte přidáním vysoce permisivních vazeb rolí clusteru, které inverzní k nastavení odepření všech nastavení.

• Azure RBAC také ve výchozím nastavení implementuje odepření . Nepřepište přidáním přiřazení RBAC, která inverzní k nastavení zamítnutí.

• Všechny služby Azure, Azure Key Vault a Azure Container Registry ve výchozím nastavení zakazují veškerá oprávnění.

• Všechny přístupové body pro správu, například jump box, by měly odepřít veškerý přístup v počáteční konfiguraci. Všechna zvýšená oprávnění musí být definována explicitně pro všechna pravidla odepření.

Požadavek 7.3

Ujistěte se, že zásady zabezpečení a provozní postupy pro omezení přístupu k datům držitelů karet jsou zdokumentované, používané a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je důležité udržovat důkladnou dokumentaci k procesům a zásadám. To zahrnuje zásady RBAC v Azure a Kubernetes a zásady zásad správného řízení organizace. Lidé provoz regulovaných prostředí musí být poučeny, informovány a incentivizovány, aby podporovaly záruky zabezpečení. To je zvlášť důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.

Požadavek 8 – Identifikace a ověření přístupu k systémovým komponentám

Podpora funkcí AKS

Díky integraci AKS a Microsoft Entra můžete využít možnosti správy a autorizace ID, včetně správy přístupu, správy objektů identifikátorů a dalších. Další informace najdete v tématu Integrace Microsoft Entra spravované službou AKS.

Vaše odpovědnosti

Požadavek	Odpovědnost
Požadavek 8.1	Definujte a implementujte zásady a postupy, které zajistí správnou správu identifikace uživatelů pro uživatele, kteří nejsou spotřebiteli a správci, a to následujícím způsobem:
Požadavek 8.2	Kromě přiřazení jedinečného ID zajistěte správnou správu ověřování uživatelů pro uživatele a správce na všech systémových komponentách pomocí alespoň jedné z následujících metod pro ověření všech uživatelů:
Požadavek 8.3	Pomocí vícefaktorového ověřování zabezpečte veškerý přístup pro správu bez konzoly a veškerý vzdálený přístup ke službě CDE.
Požadavek 8.4	Zdokumentujte a sdělte ověřovací postupy a zásady a postupy všem uživatelům, včetně:
Požadavek 8.5	Nepoužívejte skupiny, sdílené ani obecné ID, hesla ani jiné metody ověřování následujícím způsobem:
Požadavek 8.6	Pokud se používají jiné mechanismy ověřování (například fyzické nebo logické tokeny zabezpečení, čipové karty, certifikáty atd.), musí být použití těchto mechanismů přiřazeno následujícím způsobem:
Požadavek 8.7	Veškerý přístup k jakékoli databázi obsahující data držitelů karet (včetně přístupu aplikací, správců a všech ostatních uživatelů) je omezený následujícím způsobem:
Požadavek 8.8	Ujistěte se, že zásady zabezpečení a provozní postupy pro identifikaci a ověřování jsou zdokumentované, používané a známé všem postiženým stranám.

Požadavek 8.1

Definujte a implementujte zásady a postupy, které zajistí správnou správu identifikace uživatelů pro uživatele, kteří nejsou spotřebiteli a správci, a to následujícím způsobem:

• 8.1.1 Před povolením přístupu k systémovým komponentám nebo datům držitelů karet přiřaďte všem uživatelům jedinečné ID.
• 8.1.2 Řízení přidání, odstranění a úpravy ID uživatelů, přihlašovacích údajů a dalších objektů identifikátorů.
• 8.1.3 Okamžitě odvolat přístup pro všechny ukončené uživatele.
• 8.1.4 Odeberte nebo zakažte neaktivní uživatelské účty do 90 dnů.
• 8.1.5 Spravujte ID používaná třetími stranami pro přístup, podporu nebo údržbu systémových komponent prostřednictvím vzdáleného přístupu následujícím způsobem:
  • Povoleno pouze během potřebného časového období a zakázaného, pokud se nepoužívá.
  • Monitorováno při použití.
• 8.1.6 Omezte opakované pokusy o přístup uzamčením ID uživatele po více než šesti pokusech.
• 8.1.7 Nastavte dobu uzamčení na minimálně 30 minut nebo dokud správce nezavolí ID uživatele.
• 8.1.8 Pokud byla relace nečinná déle než 15 minut, je nutné, aby se uživatel znovu ověřil, aby znovu aktivoval terminál nebo relaci.

Vaše odpovědnosti

Tady jsou celkové aspekty tohoto požadavku:

PLATÍ PRO: 8.1.1, 8.1.2, 8.1.3

Nesdílejte ani znovu nepoužívejte identity pro funkčně odlišné části cde. Například nepoužívejte týmový účet pro přístup k datům nebo prostředkům clusteru. Ujistěte se, že dokumentace k identitě nemá jasné informace o tom, že nepoužíváte sdílené účty.

Tento objekt zabezpečení identity můžete rozšířit na přiřazení spravovaných identit v Azure. Nesdílejte uživatelem spravované identity napříč prostředky Azure. Každému prostředku Azure přiřaďte vlastní spravovanou identitu. Podobně platí, že pokud používáte ID úloh Microsoft Entra v clusteru AKS, ujistěte se, že každá komponenta ve vaší úloze obdrží vlastní identitu místo použití identity, která je široká v rozsahu. Nikdy nepoužívejte stejnou spravovanou identitu v předprodukčním i produkčním prostředí.

Možnosti identit a přístupu pro Azure Kubernetes Service (AKS)

PLATÍ PRO: 8.1.2, 8.1.3, 8.1.4

Jako úložiště identit použijte ID Microsoft Entra. Vzhledem k tomu, že cluster a všechny prostředky Azure používají ID Microsoft Entra, automatické zakázání nebo odvolání přístupu k MICROSOFT Entra ID se použije u všech prostředků. Pokud existují nějaké komponenty, které nejsou podporovány přímo pomocí Microsoft Entra ID, ujistěte se, že máte proces pro odebrání přístupu. Například přihlašovací údaje SSH pro přístup k jump boxu můžou potřebovat explicitní odebrání, pokud už uživatel není platný.

PLATÍ PRO: 8.1.5

Využijte výhod Microsoft Entra business-to-business (B2B), která je navržená k hostování účtů třetích stran, jako jsou dodavatelé, partneři, jako jsou uživatelé typu host. Udělte odpovídající úroveň přístupu pomocí podmíněných zásad pro ochranu podnikových dat. Tyto účty musí mít minimální stálá oprávnění a povinná data vypršení platnosti. Další informace naleznete v tématu Co je přístup uživatele typu host v Microsoft Entra B2B.

Vaše organizace by měla mít jasný a zdokumentovaný model dodavatele a podobný přístup.

PLATÍ PRO: 8.1.6, 8.1.7, 8.1.8

Vaše odpovědnosti

Microsoft Entra ID poskytuje inteligentní funkci uzamčení pro uzamčení uživatelů po neúspěšných pokusech o přihlášení. Doporučený způsob implementace uzamčení je se zásadami podmíněného přístupu Microsoft Entra.

Implementujte uzamčení komponent, které podporují podobné funkce, ale nejsou podporovány id Microsoft Entra (například počítače s podporou SSH, například jump box). Tím se zajistí, že uzamčení je povolené, aby se zabránilo zneužití pokusů o pomalý přístup nebo jejich zneužití.

Uzly AKS nejsou navržené tak, aby byly běžně přístupné. Zablokujte přímé připojení SSH nebo Vzdálenou plochu k uzlům clusteru. Přístup SSH by se měl považovat pouze za součást pokročilého řešení potíží. Přístup by se měl pečlivě monitorovat a okamžitě se vrátit po dokončení konkrétní události. Pokud to uděláte, mějte na paměti, že jakékoli změny na úrovni uzlu můžou způsobit, že váš cluster nebude podporovat.

Požadavek 8.2

Kromě přiřazení jedinečného ID zajistěte správnou správu ověřování uživatelů pro uživatele a správce ve všech systémových komponentách pomocí alespoň jedné z následujících metod pro ověření všech uživatelů: Něco, co víte, například heslo nebo přístupové heslo, něco, co máte, například tokenové zařízení nebo čipová karta, Něco, co jste, jako biometrické údaje.

• 8.2.1 Pomocí silné kryptografie vykreslujte všechny ověřovací přihlašovací údaje (například hesla nebo fráze) nečitelné během přenosu a ukládání na všech systémových komponentách.
• 8.2.2 Před úpravou přihlašovacích údajů ověřování ověřte identitu uživatele , například resetování hesla, zřizování nových tokenů nebo generování nových klíčů.
• 8.2.3 Hesla a fráze musí splňovat následující:
  • Vyžaduje minimální délku nejméně sedmi znaků.
  • Obsahuje číselné i abecední znaky.
• 8.2.4 Změňte uživatelská hesla/přístupová hesla alespoň jednou za 90 dní.
• 8.2.5 Nepovolte, aby jednotlivec odeslal nové heslo nebo frázi, která je stejná jako některá z posledních čtyř hesel nebo frází, které použil.
• 8.2.6 Nastavení hesel a frází pro první použití a po resetování jedinečné hodnoty pro každého uživatele a okamžitě po prvním použití se změní.

Vaše odpovědnosti

Nastavte zásady podmíněného přístupu v Microsoft Entra ID pro váš cluster. Tím se dále omezí přístup k řídicí rovině Kubernetes.

Několik z předchozí sady požadavků je automaticky zpracováno id Microsoft Entra. Zde je uvedeno několik příkladů:

• Zabezpečení hesel

  Microsoft Entra ID poskytuje funkce, které vynucuje použití silných hesel. Například slabá hesla, která patří do globálního seznamu zakázaných hesel, jsou blokovaná. To není dostatečná ochrana. Zvažte přidání funkce Microsoft Entra Password Protection pro vytvoření seznamu zákazů specifických pro organizaci. Zásady hesel se použijí ve výchozím nastavení. Některé zásady nelze upravit a pokrýt některé z předchozích požadavků. Patří sem vypršení platnosti hesla a povolené znaky. Úplný seznam najdete v tématu Zásady hesel Microsoft Entra. Zvažte použití pokročilých funkcí, které je možné vynutit pomocí zásad podmíněného přístupu, jako jsou ty, které vycházejí z rizika uživatele, které detekují únik párů uživatelských jmen a hesel. Další informace najdete v tématu Podmíněný přístup: Podmíněný přístup založený na riziku uživatele.

  Poznámka

  Důrazně doporučujeme zvážit možnosti bez hesla. Další informace naleznete v tématu Plánování nasazení ověřování bez hesla v Microsoft Entra ID.

• Ověření identity uživatele

  Pomocí zásad podmíněného přístupu rizik přihlašování můžete zjistit, jestli žádost o ověření vydala žádající identita. Požadavek se ověřuje vůči zdrojům analýzy hrozeb. Patří sem anomálie hesla spray a IP adresy. Další informace najdete v tématu Podmíněný přístup: Podmíněný přístup založený na riziku přihlášení.

Je možné, že máte komponenty, které nepoužívají ID Microsoft Entra, například přístup k přeskakovacím polím s protokolem SSH. V takových případech použijte šifrování veřejného klíče s minimálně velikostí klíče RSA 2048. Vždy zadejte heslo. Máte proces ověření, který sleduje známé schválené veřejné klíče. Systémy, které používají přístup k veřejnému klíči, nesmí být přístupné na internetu. Místo toho by veškerý přístup SSH měl být povolený prostřednictvím zprostředkující služby, jako je Azure Bastion, aby se snížil dopad úniku privátního klíče. Zakažte přímý přístup k heslu a použijte alternativní řešení bez hesla.

Požadavek 8.3

Pomocí vícefaktorového ověřování zabezpečte veškerý přístup pro správu bez konzoly a veškerý vzdálený přístup ke službě CDE. Poznámka: Vícefaktorové ověřování vyžaduje, aby se pro ověřování používaly minimálně dvě ze tří metod ověřování (viz požadavek 8.2 pro popis metod ověřování). Použití jednoho faktoru dvakrát (například použití dvou samostatných hesel) se nepovažuje za vícefaktorové ověřování.

Vaše odpovědnosti

Pomocí zásad podmíněného přístupu vynucujte vícefaktorové ověřování, konkrétně u účtů pro správu. Tyto zásady se doporučují pro několik předdefinovaných rolí. Tyto zásady použijte u skupin Microsoft Entra, které jsou mapované na role Kubernetes s vysokými oprávněními.

Tyto zásady je možné dále posílit pomocí dalších zásad. Zde je uvedeno několik příkladů:

• Ověřování můžete omezit na zařízení spravovaná vaším tenantem Microsoft Entra.
• Pokud přístup pochází ze sítě mimo síť clusteru, můžete vynutit vícefaktorové ověřování.

Další informace naleznete v tématu:

• Podmíněný přístup: Vyžadovat vícefaktorové ověřování pro správce
• Postupy: Vyžadování spravovaných zařízení pro přístup ke cloudovým aplikacím pomocí podmíněného přístupu
• Postupy: Vyžadování vícefaktorového ověřování pro přístup z nedůvěryhodných sítí pomocí podmíněného přístupu

Požadavek 8.4

Zdokumentujte a sdělte ověřovací postupy a zásady a postupy všem uživatelům, včetně:

• Pokyny k výběru přihlašovacích údajů silného ověřování
• Pokyny k ochraně přihlašovacích údajů pro ověřování uživatelů
• Pokyny k opakovanému použití dříve použitých hesel
• Pokyny ke změně hesel, pokud by mohlo dojít k ohrožení hesla.

Vaše odpovědnosti

Udržujte dokumentaci o vynucených zásadách. V rámci školení k onboardingu identit poskytují pokyny k postupům resetování hesel a osvědčeným postupům organizace při ochraně prostředků.

Požadavek 8.5

Nepoužívejte skupiny, sdílené ani obecné ID, hesla ani jiné metody ověřování následujícím způsobem:

• Obecná ID uživatelů jsou zakázaná nebo odebraná.
• Id sdílených uživatelů neexistují pro správu systému a další důležité funkce.
• Sdílená a obecná ID uživatelů se nepoužívají ke správě žádných systémových komponent.

Vaše odpovědnosti

Nesdílejte ani znovu nepoužívejte identity pro funkčně odlišné části clusteru nebo podů. Například nepoužívejte týmový účet pro přístup k datům nebo prostředkům clusteru. Ujistěte se, že dokumentace k identitě nemá jasné informace o tom, že nepoužíváte sdílené účty.

Zakažte uživatele root v CDE. Zakažte používání místních účtů Kubernetes, aby uživatelé nemohli používat integrovaný --admin přístup ke clusterům v rámci CDE.

Požadavek 8.6

Pokud se používají jiné mechanismy ověřování (například fyzické nebo logické tokeny zabezpečení, čipové karty, certifikáty atd.), musí být použití těchto mechanismů přiřazeno následujícím způsobem:

• Mechanismy ověřování musí být přiřazeny k jednotlivým účtům a nesdílely se mezi více účty.
• Fyzické a/nebo logické ovládací prvky musí být zavedeny, aby se zajistilo, že k získání přístupu může tento mechanismus použít pouze zamýšlený účet.

Vaše odpovědnosti

Ujistěte se, že je veškerý přístup ke službě CDE poskytnutý u identit jednotlivých uživatelů a že je rozšířený na všechny fyzické nebo virtuální tokeny. To zahrnuje veškerý přístup VPN k síti CDE a zajišťuje, aby podnikový přístup typu point-to-site (pokud existuje) jako součást tohoto toku ověřování používal certifikáty pro jednotlivé uživatele.

Požadavek 8.7

Veškerý přístup k jakékoli databázi obsahující data držitelů karet (včetně přístupu aplikací, správců a všech ostatních uživatelů) je omezený následujícím způsobem:

• Přístup všech uživatelů k databázím, dotazy uživatelů a akce uživatelů v databázích jsou prostřednictvím programových metod.
• Pouze správci databáze mají možnost přímý přístup k databázím nebo dotazování na databáze.
• ID aplikací pro databázové aplikace můžou používat jenom aplikace (a ne jednotlivé uživatele nebo jiné procesy, které nejsou aplikacemi).

Vaše odpovědnosti

Poskytnutí přístupu na základě rolí a zodpovědností Lidé může používat svoji identitu, ale přístup musí být omezený na základě potřeby s minimálními trvalými oprávněními. Lidé by nikdy neměly používat identity aplikací a identity přístupu k databázím nesmí být nikdy sdíleny.

Pokud je to možné, získejte přístup k databázi z aplikací prostřednictvím spravované identity. Jinak omezte vystavení připojovací řetězec a přihlašovacích údajů. Tajné kódy Kubernetes používejte k ukládání citlivých informací místo jejich umístění, kde jsou snadno zjištěny, jako je definice podu. Dalším způsobem je ukládání a načítání tajných kódů do a ze spravovaného úložiště, jako je Azure Key Vault. U spravovaných identit povolených v clusteru AKS se musí ověřit v key Vaultu, aby získal přístup.

Požadavek 8.8

Ujistěte se, že zásady zabezpečení a provozní postupy pro identifikaci a ověřování jsou zdokumentované, používané a známé všem postiženým stranám.

Vaše odpovědnosti

Je důležité udržovat důkladnou dokumentaci k procesům a zásadám. Udržujte dokumentaci o vynucených zásadách. V rámci školení k onboardingu identit poskytují pokyny k postupům resetování hesel a osvědčeným postupům organizace při ochraně prostředků. Lidé provoz regulovaných prostředí musí být poučeny, informovány a incentivizovány, aby podporovaly záruky zabezpečení. To je zvlášť důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.

Požadavek 9 – Omezení fyzického přístupu k datům držitelů karet

Podpora funkcí AKS

Pro tento požadavek nejsou k dispozici žádné použitelné funkce AKS.

Vaše odpovědnosti

Tato architektura a implementace nejsou navržené tak, aby poskytovaly kontroly fyzického přístupu k místním prostředkům nebo datovým centrům. Důležité informace najdete v pokynech v oficiální normě PCI-DSS 3.2.1.

Tady je několik návrhů pro použití technických ovládacích prvků:

• Pokud chcete minimalizovat přístup, vylaďte časové limity relací v jakémkoli přístupu ke konzole pro správu, jako jsou jump boxy v CDE.

• Vylaďte zásady podmíněného přístupu, abyste minimalizovali hodnotu TTL v přístupových tokenech Azure z přístupových bodů, jako je azure Portal. Informace najdete v těchto článcích:

  • Konfigurace správy relací ověřování pomocí podmíněného přístupu
  • Konfigurovatelné životnosti tokenů – Microsoft Identity Platform

• V případě služby CDE hostované v cloudu neexistují žádné zodpovědnosti za správu fyzického přístupu a hardwaru. Závisí na fyzických a logických ovládacích prvcích podnikové sítě.

• Minimalizujte export záloh CHD do místních cílů. Pomocí řešení hostovaných v Azure omezte fyzický přístup k zálohám.

• Minimalizujte zálohy do místního prostředí. Pokud je to potřeba, mějte na paměti, že místní cíl bude v rozsahu auditování.

Další kroky

Sledujte a monitorujte veškerý přístup k síťovým prostředkům a datům držitelů karet. Pravidelně testujte systémy a procesy zabezpečení.