Sdílet prostřednictvím

Požadavek Microsoft Entra ID a PCI-DSS 8

  • Článek

Požadavek 8: Identifikace uživatelů a ověřování přístupu k definovaným systémovým komponentám

8.1 Procesy a mechanismy pro identifikaci uživatelů a ověřování přístupu k systémovým komponentám jsou definovány a pochopeny.

Požadavky na definovaný přístup PCI-DSS Microsoft Entra – pokyny a doporučení
8.1.1 Všechny zásady zabezpečení a provozní postupy, které jsou uvedeny v požadavku 8, jsou:
Zdokumentováno
v aktualizovaném stavu
Při použití
známé všem postiženým stranám		 Pokyny a odkazy zde použijte k vytvoření dokumentace pro splnění požadavků na základě konfigurace vašeho prostředí.
8.1.2 Role a odpovědnosti za provádění aktivit v požadavku 8 jsou zdokumentované, přiřazené a srozumitelné. Pokyny a odkazy zde použijte k vytvoření dokumentace pro splnění požadavků na základě konfigurace vašeho prostředí.
Požadavky na definovaný přístup PCI-DSS Microsoft Entra – pokyny a doporučení
8.2.1 Všichni uživatelé mají přiřazené jedinečné ID před povolením přístupu k systémovým komponentám nebo datům držitelů karet. Pro aplikace CDE, které spoléhají na Microsoft Entra ID, je jedinečné ID uživatele atribut hlavní název uživatele (UPN). Microsoft Entra UserPrincipalName population
8.2.2 Skupiny, sdílené nebo obecné účty nebo jiné sdílené přihlašovací údaje pro ověřování se používají pouze v případě potřeby na základě výjimky a jsou spravovány následujícím způsobem:
Použití účtu se zabrání, pokud to není nutné pro mimořádné okolnosti.
Použití je omezené na dobu potřebnou pro výjimečné okolnosti.
Obchodní odůvodnění použití je zdokumentované.
Použití je explicitně schváleno identitou jednotlivých uživatelů správy
před udělením přístupu k účtu.
Každá podniknutá akce je přičítá individuálnímu uživateli.		 Zajistěte, aby prostředí CDE využívající Microsoft Entra ID pro přístup k aplikacím měly procesy, které brání sdíleným účtům. Vytvořte je jako výjimku, která vyžaduje schválení.
U prostředků CDE nasazených v Azure použijte spravované identity pro prostředky Azure k reprezentaci identity úlohy místo vytvoření účtu sdílené služby. Co jsou spravované identity pro prostředky Azure?
Pokud nemůžete používat spravované identity a prostředky, ke které se přistupuje, používají protokol OAuth, použijte instanční objekty k reprezentaci identit úloh. Udělte identitám nejméně privilegovaný přístup prostřednictvím oborů OAuth. Správci můžou omezit přístup a definovat pracovní postupy schvalování, aby je vytvořili. Co jsou identity úloh?
8.2.3 Další požadavek pouze pro poskytovatele služeb: Poskytovatelé služeb se vzdáleným přístupem k místnímu zákazníkovi používají jedinečné ověřovací faktory pro každý zákazník. Microsoft Entra ID má místní konektory, které umožňují hybridní možnosti. Konektory jsou identifikovatelné a používají jedinečně vygenerované přihlašovací údaje. Microsoft Entra Connect Sync: Vysvětlení a přizpůsobení synchronizace synchronizace cloudových synchronizací
podrobné informace
o místní zřizovací architektuře zřizování místních aplikací Microsoft Entra plánování
cloudové personální aplikace pro zřizování uživatelů Microsoft Entra na microsoft Entra User Provisioning
Instalace agentů služby Microsoft Entra Connect Health
8.2.4 Přidání, odstranění a úpravy ID uživatelů, ověřovacích faktorů a dalších objektů identifikátorů se spravují takto:
Autorizováno s odpovídajícím schválením.
Implementováno pouze s oprávněními zadanými pro zdokumentované schválení.		 Microsoft Entra ID má automatizované zřizování uživatelských účtů z personálních systémů. Pomocí této funkce můžete vytvořit životní cyklus. Co je zřizování řízené personálním oddělením?
Microsoft Entra ID má pracovní postupy životního cyklu, které umožňují přizpůsobit logiku pro procesy joineru, moveru a leaveru. Co jsou pracovní postupy životního cyklu?
Microsoft Entra ID má programové rozhraní pro správu metod ověřování pomocí Microsoft Graphu. Některé metody ověřování, jako jsou Windows Hello pro firmy a klíče FIDO2, vyžadují zásah uživatele k registraci. Začínáme s metodami ověřování graphu API
Správci nebo automatizace generují přihlašovací údaje dočasného přístupu pomocí rozhraní Graph API. Tyto přihlašovací údaje použijte pro onboarding bez hesla. Konfigurace dočasného přístupového passu v MICROSOFT Entra ID pro registraci metod ověřování bez hesla
8.2.5 Přístup pro ukončené uživatele je okamžitě odvolán. Pokud chcete odvolat přístup k účtu, zakažte místní účty pro hybridní účty synchronizované z ID Microsoft Entra, zakažte účty v MICROSOFT Entra ID a odvoláte tokeny. Odvolání přístupu uživatelů v Microsoft Entra ID
použít funkci CaE (Continuous Access Evaluation) pro kompatibilní aplikace tak, aby měla obousměrnou konverzaci s Microsoft Entra ID. Aplikace můžou být upozorněny na události, jako je ukončení účtu a odmítnutí tokenů. Průběžné vyhodnocování přístupu
8.2.6 Neaktivní uživatelské účty se odeberou nebo zakáže do 90 dnů od nečinnosti. V případě hybridních účtů správci každých 90 dnů kontrolují aktivitu ve službě Active Directory a Microsoft Entra. V případě ID Microsoft Entra vyhledejte datum posledního přihlášení pomocí Microsoft Graphu. Postupy: Správa neaktivních uživatelských účtů v Microsoft Entra ID
8.2.7 Účty 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 jsou spravovány následujícím způsobem:
Povoleno pouze během potřebného časového období a zakázáno, pokud se nepoužívá.
Použití se monitoruje pro neočekávanou aktivitu.		 ID Microsoft Entra má možnosti externí správy identit.
Použijte řízený životní cyklus hosta se správou nároků. Externí uživatelé jsou onboardovaní v kontextu aplikací, prostředků a přístupových balíčků, které můžete udělit po omezenou dobu a vyžadovat pravidelné kontroly přístupu. Kontroly můžou vést k odebrání nebo zakázání účtu. Řízení přístupu externích uživatelů při správě
nároků v Microsoft Entra ID generuje rizikové události na úrovni uživatele a relace. Naučte se chránit, zjišťovat a reagovat na neočekávané aktivity. Co je riziko?
8.2.8 Pokud byla relace uživatele nečinná déle než 15 minut, je nutné, aby se uživatel znovu ověřil, aby znovu aktivoval terminál nebo relaci. Používejte zásady správy koncových bodů s Intune a Microsoft Endpoint Managerem. Pak pomocí podmíněného přístupu povolte přístup ze vyhovujících zařízení. Pomocí zásad dodržování předpisů můžete nastavit pravidla pro zařízení, která spravujete pomocí Intune
, pokud prostředí CDE spoléhá na objekty zásad skupiny (GPO), nakonfigurujte objekt zásad skupiny tak, aby nastavil časový limit nečinnosti. Nakonfigurujte ID Microsoft Entra tak, aby umožňovalo přístup z hybridních zařízení připojených k Microsoft Entra. Zařízení připojená k hybridní službě Microsoft Entra

8.3 Silné ověřování pro uživatele a správce je vytvořeno a spravováno.

Další informace o metodách ověřování Microsoft Entra, které splňují požadavky PCI, naleznete v tématu: Dodatek k informacím: Multi-Factor Authentication.

Požadavky na definovaný přístup PCI-DSS Microsoft Entra – pokyny a doporučení
8.3.1 Veškerý uživatelský přístup k systémovým komponentám pro uživatele a správce se ověřuje alespoň jedním z následujících ověřovacích faktorů:
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, například biometrický prvek.		 Microsoft Entra ID vyžaduje metody bez hesla, které splňují požadavky
PCI, viz holistické nasazení bez hesla. Plánování nasazení ověřování bez hesla v Microsoft Entra ID
8.3.2 Silná kryptografie se používá k vykreslení všech ověřovacích faktorů nečitelných při přenosu a ukládání na všech součástech systému. Kryptografie používaná rozhraním Microsoft Entra ID je kompatibilní s definicí PCI silné kryptografie. Aspekty ochrany dat Microsoft Entra
8.3.3 Identita uživatele se ověřuje před úpravou jakéhokoli ověřovacího faktoru. Microsoft Entra ID vyžaduje, aby se uživatelé ověřili, aby aktualizovali své metody ověřování pomocí samoobslužné služby, jako je portál mysecurityinfo a samoobslužné resetování hesla (SSPR). Nastavení bezpečnostních údajů z přihlašovací stránky
Společné zásady podmíněného přístupu: Zabezpečení registrace
bezpečnostních údajů společnosti Microsoft Entra samoobslužné resetování
hesla Správci s privilegovanými rolemi můžou upravovat faktory ověřování: globální, heslo, uživatel, ověřování a privilegované ověřování. Nejméně privilegované role podle úlohy v Microsoft Entra ID. Microsoft doporučuje povolit přístup a zásady správného řízení JIT pro privilegovaný přístup pomocí služby Microsoft Entra Privileged Identity Management.
8.3.4 Neplatné pokusy o ověření jsou omezeny:
Uzamčení ID uživatele po více než 10 pokusech.
Nastavení doby uzamčení na minimálně 30 minut nebo do potvrzení identity uživatele.		 Nasaďte Windows Hello pro firmy pro zařízení s Windows, která podporují hardwarové čipy TPM (Trusted Platform Modules) 2.0 nebo vyšší.
U Windows Hello pro firmy se uzamčení vztahuje k zařízení. Gesto, PIN kód nebo biometrický kód odemkne přístup k místnímu čipu TPM. Správci konfigurují chování uzamčení pomocí zásad GPO nebo Intune. Nastavení
zásad skupiny TPM spravují Windows Hello pro firmy na zařízeních v okamžiku, kdy se zařízení registrují pomocí zásad
TPM Intune
, Windows Hello pro firmy funguje pro místní ověřování ve službě Active Directory a cloudových prostředcích v Microsoft Entra ID.
U klíčů zabezpečení FIDO2 souvisí ochrana hrubou silou s klíčem. Gesto, PIN kód nebo biometrický kód odemkne přístup k úložišti místních klíčů. Správci nakonfigurují ID Microsoft Entra tak, aby umožňovalo registraci klíčů zabezpečení FIDO2 od výrobců, kteří odpovídají požadavkům PCI. Povolte přihlášení pomocí přihlašovacího klíče zabezpečení bez hesla v

aplikaci
Microsoft Authenticator pro zmírnění útoků hrubou silou pomocí přihlašování bez hesla aplikace Microsoft Authenticator, povolte porovnávání čísel a další kontext.
ID Microsoft Entra vygeneruje náhodné číslo v ověřovacím toku. Uživatel ho zadá do ověřovací aplikace. Výzva k ověření mobilní aplikace zobrazuje umístění, IP adresu požadavku a aplikaci požadavku. Jak používat porovnávání čísel v oznámeních
vícefaktorového ověřování Jak používat další kontext v oznámeních Microsoft Authenticatoru
8.3.5 Pokud se hesla a přístupová hesla používají jako ověřovací faktory pro splnění požadavku 8.3.1, nastaví se a resetují pro každého uživatele následujícím způsobem:
Nastaví se na jedinečnou hodnotu pro první použití a po resetování.
Vynucené změny okamžitě po prvním použití.		 Nevztahuje se na MICROSOFT Entra ID.
8.3.6 Pokud se hesla a přístupové fráze používají jako ověřovací faktory pro splnění požadavku 8.3.1, splňují následující minimální úroveň složitosti:
Minimální délka 12 znaků (nebo KDYŽ systém nepodporuje 12 znaků, minimální délku osmi znaků).
Obsahuje číselné i abecední znaky.		 Nevztahuje se na MICROSOFT Entra ID.
8.3.7 Jednotlivci nesmějí odesílat nové heslo nebo heslo, které je stejné jako některá z posledních čtyř použitých hesel nebo přístupových hesel. Nevztahuje se na MICROSOFT Entra ID.
8.3.8 Zásady a postupy ověřování jsou zdokumentované a komunikované všem uživatelům, včetně:
Pokyny k výběru silných ověřovacích faktorů.
Pokyny k ochraně ověřovacích faktorů uživatelů
Pokyny k opakovanému použití dříve použitých hesel nebo přístupových hesel
Pokyny ke změně hesel nebo přístupových hesel, pokud existuje podezření nebo znalost, že došlo k ohrožení hesla nebo přístupových hesel a způsobu hlášení incidentu.		 Zdokumentujte zásady a postupy a pak komunikujte s uživateli podle tohoto požadavku. Microsoft poskytuje přizpůsobitelné šablony v Centru stahování.
8.3.9 Pokud se hesla a přístupové fráze používají jako jediný faktor ověřování pro přístup uživatelů (tj. v jakékoli implementaci jednofaktorového ověřování), pak se změní hesla a přístupové fráze alespoň jednou za 90 dnů,
NEBO
stav zabezpečení účtů se dynamicky analyzuje a přístup k prostředkům se automaticky určí v reálném čase.		 Nevztahuje se na MICROSOFT Entra ID.
8.3.10 Další požadavek pouze pro poskytovatele služeb: Pokud se hesla a přístupové fráze používají jako jediný ověřovací faktor pro přístup uživatelů zákazníků k datům držitelů karet (tj. v jakékoli implementaci jednofaktorového ověřování), poskytují se pokyny pro zákazníky, včetně:
Pokyny pro zákazníky k pravidelné změně hesel a přístupových hesel.
Pokyny týkající se toho, kdy a za jakých okolností se mají změnit hesla nebo přístupové fráze.		 Nevztahuje se na MICROSOFT Entra ID.
8.3.10.1 Další požadavek pouze pro poskytovatele služeb: Pokud se hesla a přístupové fráze používají jako jediný faktor ověřování pro uživatelský přístup zákazníka (tj. v jakékoli implementaci jednofaktorového ověřování), pak se
změní hesla a přístupové fráze alespoň jednou za 90 dnů,
NEBO
stav zabezpečení účtů se dynamicky analyzuje a přístup k prostředkům se automaticky určí v reálném čase.		 Nevztahuje se na MICROSOFT Entra ID.
8.3.11 Pokud se používají ověřovací faktory, jako jsou fyzické nebo logické tokeny zabezpečení, čipové karty nebo certifikáty:
Faktory jsou přiřazeny jednotlivým uživatelům a nejsou sdíleny mezi více uživateli.
Fyzické a/nebo logické ovládací prvky zajišťují, že k získání přístupu může tento faktor použít pouze zamýšlený uživatel.		 Pro přihlášení pomocí telefonu používejte metody ověřování bez hesla, jako jsou Windows Hello pro firmy, klíče zabezpečení FIDO2 a aplikace Microsoft Authenticator. Používejte čipové karty založené na veřejných nebo privátních klíčích přidružených k uživatelům, abyste zabránili opakovanému použití.

8.4 Vícefaktorové ověřování (MFA) je implementováno pro zabezpečení přístupu k datovému prostředí držitelů karet (CDE)

Požadavky na definovaný přístup PCI-DSS Microsoft Entra – pokyny a doporučení
8.4.1 Vícefaktorové ověřování se implementuje pro veškerý nekonsoleový přístup do CDE pro pracovníky s přístupem pro správu. Podmíněný přístup použijte k vyžadování silného ověřování pro přístup k prostředkům CDE. Definujte zásady, které mají cílit na roli správy, nebo skupinu zabezpečení představující přístup správce k aplikaci.
Pro přístup pro správu použijte Microsoft Entra Privileged Identity Management (PIM) k povolení aktivace privilegovaných rolí za běhu (JIT). Co je podmíněný přístup?
Šablony
podmíněného přístupu začínají používat PIM
Vícefaktorové ověřování 8.4.2 je implementováno pro veškerý přístup k CDE. Zablokujte přístup ke starším protokolům, které nepodporují silné ověřování. Blokování starší verze ověřování v Microsoft Entra ID pomocí podmíněného přístupu
8.4.3 Vícefaktorové ověřování se implementuje pro veškerý vzdálený přístup k síti pocházející z mimo síť entity, která by mohla získat přístup k síti CDE nebo ovlivnit ho takto:
Veškerý vzdálený přístup všech pracovníků, uživatelů i správců pocházejících z mimo síť entity.
Veškerý vzdálený přístup třetích stran a dodavatelů.		 Integrujte přístupové technologie, jako jsou virtuální privátní síť (VPN), vzdálená plocha a síťové přístupové body, s ID Microsoft Entra pro ověřování a autorizaci. Podmíněný přístup použijte k vyžadování silného ověřování pro přístup k aplikacím vzdáleného přístupu. Šablony podmíněného přístupu

8.5 Systémy vícefaktorového ověřování (MFA) jsou nakonfigurované tak, aby se zabránilo zneužití.

Požadavky na definovaný přístup PCI-DSS Microsoft Entra – pokyny a doporučení
Systémy vícefaktorového ověřování 8.5.1 se implementují takto:
Systém MFA není náchylný k přehrání útoků.
Systémy vícefaktorového ověřování není možné obejít žádným uživatelem, včetně administrativních uživatelů, pokud nejsou výslovně zdokumentované a autorizované správou na základě výjimky, po omezenou dobu.
Používají se aspoň dva různé typy ověřovacích faktorů.
Před udělením přístupu je vyžadován úspěch všech ověřovacích faktorů.		 Doporučené metody ověřování Microsoft Entra využívají neskonče nebo problémy. Tyto metody odporují útokům na přehrání, protože ID Microsoft Entra detekuje přehrání ověřovacích transakcí.
Windows Hello pro firmy, FIDO2 a aplikace Microsoft Authenticator pro přihlášení k telefonu bez hesla používají k identifikaci požadavku a zjišťování pokusů o přehrání. Pro uživatele v CDE používejte přihlašovací údaje bez hesla.
Ověřování na základě certifikátů využívá problémy k detekci pokusů o přehrání.
Úroveň záruky authenticatoru NIST 2 s ID Microsoft Entra
Úroveň záruky authenticatoru NIST 3 s využitím ID Microsoft Entra

8.6 Použití aplikačních a systémových účtů a přidružených ověřovacích faktorů je přísně spravováno.

Požadavky na definovaný přístup PCI-DSS Microsoft Entra – pokyny a doporučení
8.6.1 Pokud se účty používané systémy nebo aplikacemi dají použít k interaktivnímu přihlášení, spravují se následujícím způsobem:
Interaktivní použití se zabrání, pokud nejsou potřeba pro mimořádné okolnosti.
Interaktivní použití je omezené na dobu potřebnou k výjimečným okolnostem.
Obchodní odůvodnění interaktivního použití je zdokumentované.
Interaktivní použití je explicitně schváleno správou.
Před udělením přístupu k účtu se potvrdí identita jednotlivých uživatelů.
Každá podniknutá akce je přičítá individuálnímu uživateli.		 Pro aplikace CDE s moderním ověřováním a pro prostředky CDE nasazené v Azure, které používají moderní ověřování, má Microsoft Entra ID dva typy účtů služby pro aplikace: spravované identity a instanční objekty.
Další informace o zásadách správného řízení účtu služby Microsoft Entra: plánování, zřizování, životní cyklus, monitorování, kontroly přístupu atd. Řízení účtů
služby Microsoft Entra za účelem zabezpečení účtů služeb Microsoft Entra Zabezpečení spravovaných identit v Microsoft Entra ID
Zabezpečení instančních objektů v Microsoft Entra ID
pro cdes s prostředky mimo Azure, které vyžadují přístup, nakonfigurujte federace identit úloh bez správy tajných kódů nebo interaktivního přihlašování. Federace
identit úloh Umožňuje povolit schvalovací a sledovací procesy, které splňují požadavky, orchestrujte pracovní postupy pomocí IT Service Management (ITSM) a databází správy konfigurací (CMDB) Tyto nástroje používají rozhraní MS Graph API k interakci s Microsoft Entra ID a správě účtu služby.
Pro služby CDE, které vyžadují účty služeb kompatibilní s místní Active Directory, použijte účty spravované služby (GMSA) a samostatné účty spravované služby (sMSA), účty počítačů nebo uživatelské účty. Zabezpečení místních účtů služeb
8.6.2 Hesla a přístupové fráze pro všechny účty aplikací a systémů, které je možné použít pro interaktivní přihlášení, nejsou pevně zakódované ve skriptech, souborech konfigurace a vlastností nebo pro vlastní zdrojový kód. Používejte moderní účty služeb, jako jsou spravované identity Azure a instanční objekty, které nevyžadují hesla.
Přihlašovací údaje spravovaných identit Microsoft Entra se zřizují a obměňují v cloudu, což brání používání sdílených tajných kódů, jako jsou hesla a přístupové fráze. Při použití spravovaných identit přiřazených systémem je životní cyklus svázaný se základním životním cyklem prostředků Azure.
Instanční objekty slouží k používání certifikátů jako přihlašovacích údajů, které brání použití sdílených tajných kódů, jako jsou hesla a přístupové fráze. Pokud certifikáty nejsou proveditelné, uložte tajné kódy klienta instančního objektu pomocí služby Azure Key Vault. Osvědčené postupy pro používání služby Azure Key Vault
pro služby CDEs s prostředky mimo Azure, které vyžadují přístup, nakonfigurujte federace identit úloh bez správy tajných kódů nebo interaktivního přihlašování. Federace
identit úloh nasadí podmíněný přístup pro identity úloh pro řízení autorizace na základě umístění nebo úrovně rizika. Podmíněný přístup pro identity
úloh Kromě předchozích pokynů použijte nástroje pro analýzu kódu k detekci pevně zakódovaných tajných kódů v kódech a konfiguračních souborech. Detekce vystavených tajných kódů v pravidlech zabezpečení kódu
8.6.3 Hesla a přístupové fráze pro všechny účty aplikací a systémů jsou chráněna před zneužitím následujícím způsobem:
Hesla a přístupové fráze se pravidelně mění (s frekvencí definovanou v analýze cíleného rizika entity, která se provádí podle všech prvků uvedených v požadavku 12.3.1) a v případě podezření nebo potvrzení ohrožení.
Hesla a přístupové fráze se vytvářejí s dostatečnou složitostí, která odpovídá tomu, jak často entita mění hesla a přístupové fráze.		 Používejte moderní účty služeb, jako jsou spravované identity Azure a instanční objekty, které nevyžadují hesla.
Výjimky, které vyžadují instanční objekty s tajnými kódy, abstraktní životní cyklus tajných kódů pomocí pracovních postupů a automatizace, které nastaví náhodná hesla na instanční objekty, je pravidelně obměňuje a reaguje na rizikové události.
Týmy pro provoz zabezpečení můžou kontrolovat a opravovat sestavy vygenerované microsoftem Entra, jako jsou identity rizikových úloh. Zabezpečení identit úloh pomocí služby Microsoft Entra ID Protection

Další kroky

Požadavky PCI-DSS 3, 4, 9 a 12 se nevztahují na ID Microsoft Entra, proto neexistují žádné odpovídající články. Pokud chcete zobrazit všechny požadavky, přejděte na pcisecuritystandards.org: oficiální web Rady bezpečnostních standardů PCI.

Pokud chcete nakonfigurovat ID Microsoft Entra tak, aby vyhovovalo PCI-DSS, přečtěte si následující články.