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

Tento článek popisuje požadavky pro cluster Azure Kubernetes Service (AKS), který je nakonfigurovaný v souladu se standardem PCI-DSS v oboru zabezpečení dat v odvětví platebních karet (PCI-DSS 3.2.1).

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. Existuje několik předdefinovaných rolí s konkrétními oprávněními nebo akcemi v Kubernetesch prostředcích. Služba Azure Kubernetes Service (AKS) podporuje tyto předdefinované role a vlastní role pro podrobné řízení. Tyto akce můžou být autorizovány (nebo odepřeny) uživateli prostřednictvím Kubernetes RBAC.

Tato architektura a implementace není navržená tak, aby poskytovala ovládací prvky fyzického přístupu k místním prostředkům nebo datovým centrům. Jednou z výhod hostování své CDE v Azure, na rozdíl od vaší platformy na hranici nebo ve vašem datacentru, je to, že omezení fyzického přístupu se většinou zpracovává prostřednictvím zabezpečení datacenter Azure. Pro organizaci se správou fyzického hardwaru neexistují žádné zodpovědnosti.

Implementace silných měr řízení přístupu

Požadavek 7 — Omezení přístupu k datům držitelů IT, kteří potřebují znát firmu

Podpora funkcí AKS

AKS je plně integrovaná s Azure Active Directory (Azure AD) jako poskytovatel identity.

Nemusíte spravovat samostatné identity uživatelů a přihlašovací údaje pro Kubernetes. Můžete přidat uživatele Azure AD pro Kubernetes RBAC. Tato integrace umožňuje provádět přiřazení rolí pro uživatele Azure AD. Služba Azure AD RBAC podporuje definice rolí, jako je například prohlížeč, zapisovač, Správce služby, Správce clusteru jako předdefinované role. Můžete také vytvořit vlastní role pro podrobnější řízení.

Ve výchozím nastavení je služba Azure RBAC nastavena na hodnotu Odepřít vše, 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 luskech.

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

Vaše odpovědnosti

Požadavek	Zodpovědní
Požadavek 7,1	Omezte přístup k systémovým součástem a datům držitele jenom na ty jednotlivce, jejichž úloha vyžaduje takový přístup.
Požadavek 7,2	Navažte systém řízení přístupu pro součásti systémů, které omezují přístup na základě potřeby uživatele, a je nastavená na Odepřít vše, pokud není výslovně povolené.
Požadavek 7,3	Zajistěte, aby zásady zabezpečení a provozní postupy pro omezení přístupu k datům držitele byly dokumentovány, používány a byly známy všem postiženým stranám.

Požadavek 8 — Identifikace a ověření přístupu k součástem systému

Podpora funkcí AKS

Kvůli integraci AKS a Azure AD můžete využívat možnosti správy ID a autorizace, včetně správy přístupu, správy objektů identifikátorů a dalších. další informace najdete v tématu integrace Azure Active Directory spravovaném v AKS.

Vaše odpovědnosti

Požadavek	Zodpovědní
Požadavek 8,1	Definujte a Implementujte zásady a postupy, abyste zajistili správnou správu identifikace uživatelů pro uživatele, kteří nejsou spotřebiteli a správci, na všech součástech systému následujícím způsobem:
Požadavek 8,2	Kromě přiřazení jedinečného IDENTIFIKÁTORu Zajistěte správnou správu ověřování uživatelů pro uživatele, kteří nejsou uživateli a správci, na všech součástech systému, a to tak, že k ověřování všech uživatelů použijete aspoň jednu z následujících metod:
Požadavek 8,3	Zabezpečte veškerý jednotlivý přístup správců bez konzoly a veškerý vzdálený přístup k CDE pomocí Multi-Factor Authentication.
Požadavek 8,4	Zdokumentujte a zasílají postupy a zásady ověřování a postupy pro všechny uživatele, včetně těchto:
Požadavek 8,5	Nepoužívejte skupiny, sdílená ani obecná ID, hesla nebo jiné metody ověřování, a to následujícím způsobem:
Požadavek 8,6	V případě použití jiných ověřovacích mechanismů (například fyzických nebo logických tokenů zabezpečení, čipových karet, certifikátů atd.) je nutné tyto mechanismy přiřadit následujícím způsobem:
Požadavek 8,7	Veškerý přístup k jakékoli databázi obsahující data držitele (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 popsány, jsou používány a jsou známy všem postiženým stranám.

Požadavek 9 — Omezení fyzického přístupu na data držitele

Požadavek 7,1

Omezte přístup k systémovým součástem a datům držitele jenom na ty jednotlivce, jejichž úloha vyžaduje takový přístup.

Vaše odpovědnosti

Tady je několik důležitých informací:

• Ujistěte se, že vaše implementace je zarovnána s požadavky organizace a s požadavky na dodržování předpisů týkající se správy identit.
• Minimalizujte stálá oprávnění zvlášť pro účty s kritickým dopadem.
• Postupujte podle principu přístupu s nejnižšími oprávněními. Poskytněte jenom dostatečný přístup k dokončení úkolu.

Požadavek 7.1.1

Definujte pro každou roli přístupová oprávnění, včetně:

• Systémové součásti a datové prostředky, které každá role potřebuje k přístupu ke své pracovní funkci
• 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ě úkolů a zodpovědností, které jsou potřebné pro komponenty v oboru, a jejich interakci s prostředky Azure. Můžete začít s mnoha kategoriemi, jako jsou:

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

I když definice rolí a odpovědností kolem těchto oblastí může být přidružena k vaší týmové struktuře, zaměřte se na požadavky na zatížení. Například, kdo zodpovídá za údržbu zabezpečení, izolace, nasazení a pozorování. Tady je několik příkladů:

• Rozhodnutí o zabezpečení aplikací, Kubernetes RBAC, zásadách sítě, zásadách Azure a komunikaci s dalšími službami.
• Konfigurace a údržba Azure Firewall, Firewall webových aplikací (WAF), skupin zabezpečení sítě (skupin zabezpečení sítě) a konfigurace DNS.
• Monitorujte a opravte zabezpečení serveru, opravy, konfiguraci a zabezpečení koncového bodu.
• Nastavte směr pro použití RBAC, Azure Security Center, strategii ochrany správců a Azure Policy, abyste mohli řídit prostředky Azure.
• Tým pro sledování incidentů a odpovědi. Prozkoumejte a napravte incidenty zabezpečení v informacích o zabezpečení a správě událostí (SIEM) nebo Azure Security Center.

Pak formalizovat definici tím, že určíte, jakou úroveň přístupu je potřeba pro roli v souvislosti s úlohou a infrastrukturou. Zde je jednoduchá definice pro ilustrativní účely.

Role	Odpovědnost	Úrovně přístupu
Vlastníci aplikace	Definujte a určete prioritu funkcí, které odpovídají obchodním výsledkům. Rozumíte tomu, jak funkce ovlivňují rozsah dodržování předpisů pro úlohy, a vyrovnávat ochranu zákaznických dat a vlastnictví s obchodními záměry.	Přístup pro čtení k protokolům a metrikám, které vysílá aplikace Nepotřebují oprávnění pro přístup k zatížení nebo clusteru.
Vývojáři aplikací	Vývoj aplikace. Veškerý kód aplikace podléhá školicím a kvalitním procesům, které jsou schopné uchovávat požadavky, ověřování a správu verzí. Může spravovat kanály sestavení, ale obvykle ne kanály nasazení.	Přístup pro čtení k oborům názvů Kubernetes a prostředkům Azure, které jsou v rozsahu úlohy. Neexistuje žádný přístup pro zápis pro nasazení nebo úpravu žádného stavu systému.
Operátory pro aplikace (nebo SRE)	Důkladné porozumění základnímu kódu, pozorovateli a operacím. Udělejte si řešení potíží živě a na pracovišti. Společně s vývojáři aplikací Zvyšte dostupnost, škálovatelnost a výkon aplikace. Spravujte kanál nasazení "poslední míle" a pomůžou vám spravovat kanály sestavení.	Vysoce privilegované v rámci rozsahu aplikace, která zahrnuje související obory názvů Kubernetes a prostředky Azure. Pravděpodobně má stálý přístup k částem clusteru Kubernetes.
Vlastníci infrastruktury	Navrhněte nákladově efektivní architekturu, včetně jejího připojení a funkcí komponent. Obor může zahrnovat cloudové a místní služby. Rozhodněte se o možnosti uchovávání dat, funkce pro provozní kontinuitu a další.	Přístup k protokolům platforem a datům nákladového centra V rámci clusteru není vyžadován přístup.
Operátory infrastruktury (nebo SRE)	Operace související s clusterem a závislými službami. Sestavte, nasaďte a sestavte kanál pro cluster, ve kterém je nasazení úlohy nasazeno. Nastavte cílové fondy uzlů a očekávané požadavky na velikost 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ů úlohy. Vysoce privilegovaný přístup ke clusteru.
Zásady, vlastníci zabezpečení	Musí mít zkušenosti s dodržováním předpisů pro zabezpečení nebo předpisy. Definujte zásady, které chrání zabezpečení a dodržování předpisů pro zaměstnance společnosti, jejich prostředky a zákazníky ze společnosti. Spolupracuje se všemi ostatními rolemi, aby bylo zajištěno, že zásady budou aplikovány a auditovány přes každou fázi.	Přístup pro čtení k zatížení a clusteru. Přístup k datům protokolů a auditu.
Síťové operátory	Přidělení virtuální sítě a podsítí na podnikové úrovni. Konfigurace a údržba konfigurace Azure Firewall, WAF, skupin zabezpečení sítě a DNS.	Vysoce privilegované v síťové vrstvě. V rámci clusteru nemáte oprávnění k zápisu.

Požadavek 7.1.2

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

Vaše odpovědnosti

Na základě funkcí úlohy se snažte přistoupit k minimalizaci přístupu, aniž by došlo k přerušení. Tady jsou některé osvědčené postupy:

• Identita by měla mít jenom dostatečný přístup k dokončení úkolu.
• Minimalizujte stálá oprávnění, zejména v případě nepostradatelných identit, které mají přístup k součástem v rámci oboru.
• Přidejte další omezení tam, kde je to možné. Jedním ze způsobů je poskytnout podmíněný přístup na základě kritérií přístupu.
• Proveďte pravidelnou kontrolu a audit uživatelů a skupin s přístupem k předplatným, a to i pro přístup pro čtení. Vyhněte se pozvání externích identit.

7.1.3 požadavku

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

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 třeba systém nebo tenure zaměstnance. Udělení přístupových práv jednomu uživateli nebo skupině.

Tady je několik příkladů.

Klasifikace úlohy	Role
Vlastník produktu definuje rozsah úloh a určuje prioritu funkcí. Vyrovnává ochranu zákaznických dat a vlastnictví s obchodními záměry. Potřebuje přístup k sestavám, nákladovém centru nebo řídicím panelům Azure. Pro oprávnění v clusteru nebo na úrovni clusteru není potřebný přístup.	Vlastníci aplikace
Návrh softwarového inženýra , vyvíjí a kontejnerizuje kód aplikace. skupina se stálými oprávněními pro čtení v rámci definovaných oborů v rámci Azure (například Application Insights) a obory názvů úloh. Tyto obory a oprávnění se mohou lišit mezi předprodukčním a produkčním prostředím.	Vývojář aplikace
Inženýr pro spolehlivost webu zajišťuje třídění na pracovišti, spravuje kanály a nastavuje aplikační infrastrukturu. Skupina A s úplným řízením v rámci svých přidělených oborů názvů. Nevyžadují se stálá oprávnění. Skupina B pro každodenní operace na pracovním vytížení. Může mít stálá oprávnění v rámci svých přidělených oborů názvů, ale nejsou vysoce privilegované.	Operátory aplikace
Operátor clusteru navrhuje a nasadí spolehlivý a zabezpečený cluster AKS pro platformu. Zodpovídá za udržování doby provozu clusteru. Skupina A s úplným řízením v rámci svých přidělených oborů názvů. Nevyžadují se stálá oprávnění. Skupina B pro každodenní operace na pracovním vytížení. Může mít stálá oprávnění v rámci svých přidělených oborů názvů, ale nejsou vysoce privilegované.	Operátoři infrastruktury
Síťový inženýr přiděluje podnikovou virtuální síť a podsítě, místní připojení k cloudu a zabezpečení sítě.	Operátoři infrastruktury

7.1.4 požadavku

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

Vaše odpovědnosti

Mít ověřovaný proces pro schvalování změn rolí a oprávnění, včetně prvotního přiřazení oprávnění. Ujistěte se, že jsou tato schválení popsána a k dispozici pro kontrolu.

Požadavek 7,2

Navažte systém řízení přístupu pro součásti systémů, které omezují přístup na základě potřeby uživatele, a je nastavená na Odepřít vše, pokud není výslovně povolené.

Vaše odpovědnosti

Po splnění tohoto požadavku 7,1byste měli vyhodnocovat role a zodpovědnosti, které platí pro vaši organizaci a úlohu. Všechny součásti v architektuře, které jsou v oboru, musí mít omezený přístup. To zahrnuje AKS uzly, které spouštějí úlohy, úložiště dat, přístup k síti a všechny další služby, které se účastní zpracování dat držitele karty (CHD).

V závislosti na rolích a zodpovědnostech 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 rovině řízení Kubernetes, která je vystavena prostřednictvím serveru rozhraní Kubernetes API. Tato sada oprávnění definuje, co můžete se serverem API dělat. Uživateli můžete například odepřít oprávnění k vytvoření nebo dokonce výpisu lusků.
• Azure RBAC je autorizační model založený na službě Azure AD, který řídí přístup k rovině ovládacího prvku Azure. Toto je přidružení vašeho tenanta Azure AD 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šichni lidé, kteří mají přiřazené povinnosti operátora infrastruktury, patří do skupiny Azure AD. Jak je zavedeno v 7.1.1, tato role vyžaduje nejvyšší oprávnění v clusteru. Kubernetes má předdefinované role RBAC, jako je cluster-admin , které tyto požadavky splňují. Vytvořením vazeb rolí budete muset vytvořit vazbu skupiny Azure AD pro operátora cluster-admin infrastruktury. Existují dva přístupy. Můžete zvolit předdefinované role. Nebo pokud předdefinované role nesplňuje vaše požadavky (například můžou být příliš permisivní), vytvořte pro své vazby vlastní role.

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

Obor oprávnění můžete zvolit na úrovni clusteru nebo na úrovni oboru názvů. Pro role, které mají vymezené zodpovědnosti, jako jsou například operátory aplikací, jsou oprávnění přiřazena na úrovni oboru názvů pro úlohu.

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

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

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

• Udržujte si pečlivou dokumentaci k jednotlivým rolím a přiřazeným oprávněním. Udržujte jasný rozdíl v tom, která oprávnění jsou JIT a která stojí.

• Monitorujte změny rolí, například změny přiřazení nebo definice rolí. Vytvářejte upozornění na změny i v případě, že by měly získat přehled o záměrech změn.

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 udržování obchodních opatření pro řízení přístupu:

• Nemáte stálý přístup. Zvažte použití členství ve skupině ADza běhu. Tato funkce vyžaduje azure AD Privileged Identity Management.

• Nastavte zásady podmíněného přístupu ve službě Azure AD pro váš cluster. Tím se dále zaknou omezení přístupu k řídicí rovině Kubernetes. Se zásadami 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 Azure AD nebo zablokovat ne typické pokusy o přihlášení. Tyto zásady použijte u skupin Azure AD, které jsou namapované na role Kubernetes s vysokými oprávněními.

  Poznámka

  Volba technologie JIT i technologie podmíněného přístupu vyžaduje Azure AD Premium.

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

• K dalším výpočetním prostředkům, jako jsou jump boxy, musí mít přístup autorizovaní uživatelé. Nevytvářejte obecná přihlášení dostupná celému týmu.

Požadavek 7.2.2

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

Vaše odpovědnosti

Na základě 7.1.3 bude mít clusterový provoz 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 hodnocení clusterů. Jak se liší tento přístup od týmu úloh? V závislosti na vaší organizaci mohou být stejné. Tady je několik bodů ke zvážení:

• Jak by měli přistupovat ke clusteru?
• Ke kterým zdrojům je povolený přístup?
• Jaká oprávnění by měla mít v clusteru?
• Kdy jsou tato oprávnění přiřazená?

Ujistěte se, že definice jsou zdokumentované v dokumentaci k zásadám správného řízení, zásadách a školicích materiálech kolem operátora úloh a operátora clusteru.

Požadavek 7.2.3

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

Vaše odpovědnosti

Když spustíte konfiguraci, začněte zásadami nulové důvěryhodnosti. Proveďte výjimky podle potřeby a podrobně je zdokumentovat.

• Kubernetes RBAC ve výchozím nastavení implementuje odepření všech. Nepřepisujete přidáním vysoce řazených vazeb rolí clusteru, které přechádují nastavení Odepřít vše.

• Azure RBAC také ve výchozím nastavení implementuje možnost Odepřít vše. Nepopisujete přidáním přiřazení RBAC, která inverzní nastavení Odepřít vše.

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

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

Požadavek 7.3

Zajistěte, aby zásady zabezpečení a provozní postupy pro omezení přístupu k datům držitelů karet byly zdokumentovány, používat a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je velmi důležité udržovat důkladnou dokumentaci týkající se procesů a zásad. To zahrnuje zásady RBAC pro Azure a Kubernetes a zásady správného řízení organizace. Lidé provozující regulovaná prostředí musí být pouční, informovaní a podnícení, aby podpořili záruky zabezpečení. To je zvláště důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.

---

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 uživateli a správci, na všech součástech systému následujícím způsobem:

• 8.1.1 Přiřazení jedinečného ID všem uživatelům před tím, než jim umožníte přístup k systémovým součástem nebo datům držitelů karet
• 8.1.2 Přidávání, odstraňování a úpravy ID uživatelů, přihlašovacích údajů a dalších objektů identifikátorů
• 8.1.3 Okamžité odvolání přístupu pro všechny ukončené uživatele
• 8.1.4 Odebrání nebo zakázání neaktivních uživatelských účtů během 90 dnů
• 8.1.5 Správa ID používaných třetími stranami pro přístup k systémovým komponentům, jejich podpoře nebo údržbě prostřednictvím vzdáleného přístupu:
  • Povoleno pouze během potřebného časového období a zakázaného, pokud se nepou3/4í.
  • Monitorováno, když se používá.
• 8.1.6 Omezení opakovaných pokusů o přístup uzamčením ID uživatele po ne více než šesti pokusech.
• 8.1.7 Nastavení doby uzamčení na minimálně 30 minut nebo do doby, než správce povolí ID uživatele
• 8.1.8 Pokud je relace nečinná déle než 15 minut, požaduje opětovné ověření uživatele, aby znovu aktivovali 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 opakovaně nepoužívejte identity pro funkčně odlišné části CDE. Nepoužívejte například týmový účet pro přístup k datům nebo prostředkům clusteru. Ujistěte se, že dokumentace k identitě obsahuje jasnou informace o tom, že se sdílené účty nepou ít.

Rozšiřte tento objekt identity na přiřazení spravovaných identit v Azure. Nesdílejte uživatelsky spravované identity napříč prostředky Azure. Přiřaďte každý prostředek Azure vlastní spravovanou identitu. Podobně platí, že pokud používáte identitu Azure AD pod v clusteru AKS, ujistěte se, že každá součást v úloze obdrží svou vlastní identitu, a ne celou identitu, která je široká v oboru. Nikdy nepoužívejte stejnou spravovanou identitu v předprodukčním a 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

Použijte Azure AD jako úložiště identit. Vzhledem k tomu, že cluster a všechny prostředky Azure využívají službu Azure AD, zakazování nebo odvolávání přístupu ke službě Azure AD se aplikuje na všechny prostředky automaticky. Pokud máte nějaké součásti, které nejsou přímo zálohované službou Azure AD, ujistěte se, že máte proces odebrání přístupu. Například přihlašovací údaje SSH pro přístup k poli odkazů můžou potřebovat explicitní odebrání, pokud už uživatel není platný.

PLATÍ PRO: 8.1.5

Využijte výhod služby Azure AD Business-to-Business (B2B), která je navržená pro hostování účtů třetích stran, jako jsou například dodavatelé a partneři, jako uživatelé typu Host. Udělte odpovídající úroveň přístupu pomocí podmíněných zásad k ochraně podnikových dat. Tyto účty musí mít minimální oprávnění a povinná data vypršení platnosti. další informace najdete v tématu co je přístup uživatelů typu host v Azure Active Directory B2B.

Vaše organizace by měla mít jasný a dokumentovaný vzor pro dodavatele a podobný přístup.

PLATÍ PRO: 8.1.6, 8.1.7, 8.1.8

Vaše odpovědnosti

Azure AD poskytuje funkci inteligentního zámku pro zamčení uživatelů po neúspěšných pokusech o přihlášení. Doporučený způsob implementace uzamčení je pomocí zásad podmíněného přístupu Azure AD.

Implementujte uzamčení pro součásti, které podporují podobné funkce, ale nejsou zálohovány pomocí služby Azure AD (například počítače s podporou SSH, jako je například pole s odkazem). Tím se zajistí, že se povolí uzamčení, aby se zabránilo zneužití nebo pomalému přístupu.

Uzly AKS nejsou navržené tak, aby byly běžně dostupné. Zablokujte uzly clusteru přímo přes SSH nebo z vzdálené plochy. Přístup SSH by měl být považován za součást řešení potíží s pokročilým řešením. Přístup by měl být pečlivě monitorovaný a po dokončení konkrétní události se zobrazí výzva zpětně. Pokud to uděláte, uvědomte si, že jakékoli změny na úrovni uzlu můžou způsobit nepodporu vašeho clusteru.

Požadavek 8,2

Kromě přiřazování jedinečného IDENTIFIKÁTORu Zajistěte správnou správu uživatelů a správců uživatelů na všech součástech systému, a to tak, že k ověřování všech uživatelů použijete aspoň jednu z následujících metod: něco, co znáte, například heslo nebo heslo, něco, co máte, jako je třeba zařízení s tokenem nebo čipová karta, něco, co jste sami. například biometrika.

• 8.2.1 pomocí silné kryptografie vykreslí všechna přihlašovací pověření (například hesla/fráze), která jsou během přenosu a ukládání na všechny součásti systému nečitelná.
• 8.2.2 ověří identitu uživatele před úpravou přihlašovacích údajů pro ověření, například provedení resetování hesla, zřizování nových tokenů nebo generování nových klíčů.
• hesla 8.2.3/fráze musí splňovat následující požadavky:
  • Vyžaduje minimální délku alespoň sedm znaků.
  • Obsahují číselné i abecední znaky.
• 8.2.4 mění hesla uživatelů nebo přístupová hesla alespoň jednou za 90 dní.
• 8.2.5 neumožňuje osobě odeslat nové heslo nebo frázi, která je stejná jako jakékoli poslední čtyři hesla nebo fráze, které použil.
• 8.2.6 nastaví hesla/fráze pro první použití a po resetování na jedinečnou hodnotu pro každého uživatele a ihned po prvním použití se změní.

Vaše odpovědnosti

Nastavte zásady podmíněného přístupu ve službě Azure AD pro svůj cluster. Tím další jsou omezení přístupu k rovině ovládacího prvku Kubernetes.

Některé z předchozích sad požadavků jsou automaticky zpracovávány službou Azure AD. Tady je několik příkladů:

• Zabezpečení hesla

  Azure AD nabízí funkce, které vynutily používání silných hesel. Například slabá hesla, která patří do seznamu globálních zakázaných hesel, jsou blokovaná. To není dostatečná ochrana. Zvažte přidání funkce Ochrana heslem Azure AD a vytvořte seznam zákazů pro konkrétní organizaci. Ve výchozím nastavení se uplatní zásady pro hesla. Některé zásady nelze upravovat a pokrývají některé předchozí sady požadavků. Mezi ně patří vypršení platnosti hesla a povolené znaky. Úplný seznam najdete v tématu zásady hesel Azure AD. Zvažte použití pokročilých funkcí, které je možné vyhodnotit pomocí zásad podmíněného přístupu, jako jsou ty, které jsou založené na riziku uživatele a zjišťují nevrácené páry uživatelského jména a hesla. Další informace najdete v tématu podmíněný přístup: podmíněný přístup na základě rizika uživatele.

  Poznámka

  Důrazně doporučujeme vzít v úvahu možnosti nepoužívatelné hesla. Další informace najdete v tématu Plánování nasazení ověřování bez hesla v Azure Active Directory.

• Ověření identity uživatele

  Zásady podmíněného přístupu pro rizika přihlášení můžete použít k detekci, jestli byla žádost o ověření vydaná žádající identitou. Požadavek se ověří u zdrojů analýzy hrozeb. Mezi ně patří zarozprašovače hesel a anomálie IP adres. Další informace najdete v tématu podmíněný přístup: podmíněný přístup na základě rizik přihlašování.

Můžete mít komponenty, které nepoužívají službu Azure AD, například přístup k polím s odkazy pomocí SSH. V takových případech použijte šifrování pomocí veřejného klíče s minimálně RSA 2048 velikostí klíče. Vždy zadejte heslo. Poznáte proces ověření, který sleduje známé schválené veřejné klíče. Systémy, které používají přístup k veřejným klíčům nesmí, budou přístupné pro Internet. Místo toho by měl být veškerý přístup přes SSH povolen prostřednictvím zprostředkovatele, jako je Azure bastionu, aby se snížil dopad nevracení privátního klíče. Zakažte přímý přístup k heslům a použijte alternativní řešení s neheslem.

Požadavek 8,3

Zabezpečte veškerý jednotlivý přístup správců bez konzoly a veškerý vzdálený přístup k CDE pomocí Multi-Factor Authentication. Poznámka: Multi-Factor Authentication vyžaduje, aby se pro ověřování používala minimálně dvě ze tří metod ověřování (viz článek požadavek 8,2 pro popisy metod ověřování). Použití jednoho faktoru dvakrát (například pomocí dvou oddělených hesel) se nepovažuje za službu Multi-Factor Authentication.

Vaše odpovědnosti

Zásady podmíněného přístupu můžete použít k prosazování vícefaktorového ověřování, konkrétně u účtů pro správu. Tyto zásady jsou doporučovány na několika předdefinovaných rolích. Tyto zásady použijte pro skupiny Azure AD, které jsou namapované na Kubernetes role s vysokou úrovní oprávnění.

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

• Můžete omezit ověřování na zařízení, která spravuje váš tenant služby Azure AD.
• Pokud přístup pochází ze sítě mimo síť s clustery, můžete vyhovět vícefaktorového ověřování.

Další informace naleznete v tématu:

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

Požadavek 8,4

Zdokumentujte a zasílají postupy a zásady ověřování a postupy pro všechny uživatele, včetně těchto:

• Pokyny k výběru přihlašovacích údajů silného ověřování
• Pokyny, jak by uživatelé měli chránit přihlašovací údaje pro ověřování
• Pokyny k opakovanému použití dřív použitých hesel
• Pokyny pro změnu hesel v případě podezření na ohrožení hesla

Vaše odpovědnosti

Udržujte dokumentaci k vynutilým zásadám. Jako součást školení k registraci vaší identity poskytněte pokyny pro postupy resetování hesel a organizace osvědčené postupy pro ochranu prostředků.

Požadavek 8,5

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

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

Vaše odpovědnosti

Nesdílejte ani znovu nepoužívejte identity pro funkčně různé části clusteru nebo lusky. Nepoužívejte například týmový účet pro přístup k datům nebo prostředkům clusteru. Ujistěte se, že je v dokumentaci identity jasné, že nepoužívají sdílené účty.

V CDE zakažte uživatele root. Zakažte použití místních účtů Kubernetes, aby uživatelé nemůžou používat integrovaný --admin přístup k clusterům v rámci CDE.

Požadavek 8,6

V případě použití jiných ověřovacích mechanismů (například fyzických nebo logických tokenů zabezpečení, čipových karet, certifikátů atd.) je nutné tyto mechanismy přiřadit následujícím způsobem:

• Mechanismy ověřování musí být přiřazené k individuálnímu účtu a nesmí se sdílet mezi více účty.
• Aby bylo možné získat přístup, musí být k dispozici fyzické a/nebo logické ovládací prvky, aby byl tento mechanismus použit pouze k zamýšlenému účtu.

Vaše odpovědnosti

Zajistěte, aby byl veškerý přístup k CDE poskytnutý pro identity vázané na uživatele a aby se tento klíč rozšířil na fyzické nebo virtuální tokeny. To zahrnuje jakýkoli přístup k síti VPN do sítě CDE, který zajišťuje, že podniková připojení typu Point-to-Site (pokud existuje) v rámci tohoto toku ověřování používají certifikáty vázané na uživatele.

Požadavek 8,7

Veškerý přístup k jakékoli databázi obsahující data držitele (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 uživatelským dotazům na uživatelské dotazy a akce uživatelů v databázích jsou prostřednictvím programových metod.
• Možnost přímého přístupu k databázím a dotazování databází mají jenom správci databáze.
• ID aplikací pro databázové aplikace můžou používat jenom aplikace (a ne jednotlivé nebo jiné procesy mimo aplikaci).

Vaše odpovědnosti

Poskytněte přístup na základě rolí a odpovědností. Lidé můžou používat svoji identitu, ale přístup musí být omezený na základě potřeby, ale s minimálními oprávněními. Lidé nikdy neměli používat identity aplikací a identity přístupu k databázi nikdy nesmí být sdílené.

Pokud je to možné, přístup k databázi z aplikací prostřednictvím spravované identity. V opačném případě omezte vystavení připojovacích řetězců a přihlašovacích údajů. Pomocí tajných klíčů Kubernetes můžete ukládat citlivé informace místo jejich umístění tam, kde jsou snadno zjištěna, například definice pod. Dalším způsobem je ukládání a načítání tajných kódů do a ze spravovaného úložiště, například Azure Key Vault. U spravovaných identit, které jsou povolené v clusteru AKS, se musí sám ověřit proti Key Vault získat přístup.

Požadavek 8,8

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

Vaše odpovědnosti

Je důležité, abyste zachovali důkladnou dokumentaci k procesům a zásadám. Udržujte dokumentaci k vynutilým zásadám. Jako součást školení k registraci vaší identity poskytněte pokyny pro postupy resetování hesel a organizace osvědčené postupy pro ochranu prostředků. Provozní prostředí, která jsou na něm podporovaná, se musí informovat, informovat a motivovaní, aby podporovaly bezpečnostní záruky. To je důležité hlavně pro uživatele, kteří jsou součástí procesu schvalování z perspektivy zásad.

Požadavek 9

Omezení fyzického přístupu na data držitele

Vaše odpovědnosti

Tato architektura a implementace není navržená tak, aby poskytovala ovládací prvky fyzického přístupu k místním prostředkům nebo datovým centrům. Informace najdete v pokynech v oficiálním standardu PCI-DSS 3.2.1.

Zde jsou některé návrhy pro použití technických ovládacích prvků:

• Vyladění časových limitů relace v jakémkoli přístupu ke konzole pro správu, jako jsou pole s odkazy v CDE, pro minimalizaci přístupu.

• Vyladěním zásad podmíněného přístupu minimalizujete hodnotu TTL pro přístupové tokeny Azure z přístupových bodů, jako je například 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

• Pro CDE v cloudu nejsou žádné zodpovědnost za správu fyzického přístupu a hardwaru. Spoléhá se na fyzické a logické ovládací prvky podnikové sítě.

• Minimalizujte export CHDch záloh do místních cílů. K omezení fyzického přístupu k zálohám použijte řešení hostovaná v Azure.

• Minimalizujte zálohování do místního prostředí. Pokud je to potřeba, pamatujte na to, že místní cíl bude v oboru pro audit.

Další kroky

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