Řízení zabezpečení: Správa identit

  • Článek

Správa identit zahrnuje ovládací prvky pro vytvoření zabezpečené identity a řízení přístupu pomocí systémů správy identit a přístupu, včetně použití jednotného přihlašování, silného ověřování, spravovaných identit (a instančních objektů) pro aplikace, podmíněného přístupu a monitorování anomálií účtů.

IM-1: Použití centralizovaného systému identit a ověřování

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Princip zabezpečení: K řízení identit a ověřování pro cloudové a necloudové prostředky vaší organizace použijte centralizovaný systém identit a ověřování.

Pokyny k Azure: Azure Active Directory (Azure AD) je služba pro správu identit a ověřování v Azure. Měli byste standardizovat Azure AD, aby se řídila identita a ověřování vaší organizace v:

  • Cloudové prostředky Microsoftu, jako jsou Azure Storage, Azure Virtual Machines (Linux a Windows), Azure Key Vault, PaaS a aplikace SaaS.
  • Prostředky vaší organizace, jako jsou aplikace v Azure, aplikace třetích stran běžící v prostředcích podnikové sítě a aplikace SaaS třetích stran.
  • Vaše podnikové identity ve službě Active Directory prostřednictvím synchronizace do Azure AD, aby byla zajištěna konzistentní a centrálně spravovaná strategie identit.

U služeb Azure, které se používají, nepoužívejte místní metody ověřování a k centralizaci ověřování služeb použijte Azure Active Directory.

Poznámka: Jakmile to bude technicky možné, měli byste migrovat aplikace založené na místní Active Directory do Azure AD. Může se jednat o konfiguraci Azure AD Enterprise Directory, Business to Business nebo business-to-consumer.

Implementace Azure a další kontext:

Pokyny pro AWS: AWS IAM (Správa identit a přístupu) je výchozí služba AWS pro správu identit a ověřování. K řízení identity AWS a správy přístupu použijte AWS IAM. Alternativně můžete prostřednictvím AWS a Azure Single Sign-On (SSO) použít také Azure AD ke správě identit a řízení přístupu AWS, abyste se vyhnuli správě duplicitních účtů samostatně na dvou cloudových platformách.

AWS podporuje jednu Sign-On, která umožňuje přemístit identity třetích stran vaší společnosti (například Windows Active Directory nebo jiná úložiště identit) s identitami AWS, aby se zabránilo vytváření duplicitních účtů pro přístup k prostředkům AWS.

Implementace AWS a další kontext:

Pokyny ke GCP: Systém IAM (Identity and Access Management) v Google Cloudu je výchozí služba správy identit a ověřování v Google Cloudu, která se používá pro účty Google Cloud Identity. Použijte Google Cloud IAM k řízení vaší GCP identity a správy přístupu. Alternativně můžete prostřednictvím google cloudových identit a Sign-On Azure Sigle (SSO) použít také Azure AD ke správě identit a řízení přístupu GCP, abyste se vyhnuli správě duplicitních účtů samostatně v prostředí s několika cloudy.

Cloudová identita Google je zprostředkovatel identity pro všechny služby Google. Podporuje jednu Sign-On, která umožňuje přemístit identity třetích stran vaší společnosti (například Windows Active Directory nebo jiná úložiště identit) s identitami Google Cloud, abyste se vyhnuli vytváření duplicitních účtů pro přístup k prostředkům GCP.

Poznámka: Použití služby Google Cloud Directory Sync. Společnost Google poskytuje konektorový nástroj, který se integruje s většinou podnikových systémů pro správu LDAP a synchronizuje identity podle plánu. Konfigurací účtu cloudové identity a synchronizací adresáře Google Cloud Můžete nakonfigurovat, které z vašich uživatelských účtů – včetně uživatelů, skupin a profilů uživatelů, aliasů a dalších – se budou podle plánu synchronizovat mezi místním systémem pro správu identit a systémem GCP.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace):

IM-2: Ochrana identit a systémů ověřování

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Princip zabezpečení: Zabezpečení identity a ověřovacího systému je vysokou prioritou v praxi cloudového zabezpečení vaší organizace. Mezi běžné bezpečnostní prvky patří:

  • Omezení privilegovaných rolí a účtů
  • Vyžadovat silné ověřování pro veškerý privilegovaný přístup
  • Monitorování a audit vysoce rizikových aktivit

Pokyny k Azure: Pomocí standardních hodnot zabezpečení Azure AD a skóre zabezpečení Azure AD Identity vyhodnoťte stav zabezpečení Azure AD identity a opravte nedostatky v zabezpečení a konfiguraci. Skóre zabezpečení identity Azure AD vyhodnocuje Azure AD pro následující konfigurace:

  • Použití omezených rolí pro správu
  • Zapnutí zásad rizik uživatelů
  • Určení více než jednoho globálního správce
  • Povolení zásad pro blokování starší verze ověřování
  • Zajistěte, aby všichni uživatelé mohli dokončit vícefaktorové ověřování pro zabezpečený přístup.
  • Vyžadování vícefaktorového ověřování pro role pro správu
  • Povolení samoobslužného resetování hesel
  • Nevypršet platnost hesel
  • Zapnutí zásad rizik přihlašování
  • Nepovolit uživatelům udělovat souhlas nespravovaným aplikacím

Pomocí služby Azure AD Identity Protection můžete zjišťovat, prošetřovat a opravovat rizika založená na identitách. Pokud chcete podobně chránit místní Active Directory doménu, použijte Defender for Identity.

Poznámka: Postupujte podle publikovaných osvědčených postupů pro všechny ostatní komponenty identit, včetně místní Active Directory a funkcí třetích stran, a infrastruktury (jako jsou operační systémy, sítě a databáze), které je hostují.

Implementace Azure a další kontext:

Pokyny pro AWS: K zabezpečení AWS IAM použijte následující osvědčené postupy zabezpečení:

  • Nastavení přístupových klíčů uživatele root účtu AWS pro nouzový přístup, jak je popsáno v tématu PA-5 (Nastavení nouzového přístupu)
  • Při přiřazování přístupu dodržujte principy nejnižších oprávnění.
  • Využijte skupiny IAM k použití zásad místo jednotlivých uživatelů.
  • Postupujte podle pokynů k silnému ověřování v IM-6 (Použití ovládacích prvků silného ověřování) pro všechny uživatele
  • Použití zásad řízení služeb (Service Control Policy) a hranic oprávnění AWS Organizations
  • Použití IAM Access Advisoru k auditování přístupu ke službě
  • Použití sestavy přihlašovacích údajů IAM ke sledování stavu uživatelských účtů a přihlašovacích údajů

Poznámka: Pokud máte jiné systémy identit a ověřování, postupujte podle publikovaných osvědčených postupů, například pokud ke správě identit a přístupu AWS používáte Azure AD, postupujte podle Azure AD standardních hodnot zabezpečení.

Implementace AWS a další kontext:

Pokyny ke GCP: Při zabezpečení pro služby Google Cloud IAM a Cloud Identity pro vaši organizaci využijte následující osvědčené postupy zabezpečení:

  • Nastavte účet supersprávce pro nouzový přístup podle doporučení v PA-5 (Nastavení nouzového přístupu).
  • Vytvořte e-mailovou adresu supersprávce (jako účet supersprávce Google Workspace nebo Cloud Identity) a v případě potřeby nouzového obnovení by tento účet neměl být specifický pro konkrétního uživatele.
  • Dodržujte zásady nejnižších privilegií a oddělení povinností.
  • Nepoužívejte účet supersprávce pro každodenní aktivity
  • Využijte skupiny Google Cloud Identity k aplikování zásad místo použití zásad na jednotlivé uživatele.
  • Postupujte podle pokynů k silnému ověřování, jak je popsáno v tématu IM-6 (Použití ovládacích prvků silného ověřování) pro všechny uživatele se zvýšenými oprávněními.
  • Použití zásad IAM k omezení přístupu k prostředkům
  • Použití služby Organization Policy Service k řízení a konfiguraci omezení prostředků
  • Použití protokolování auditu IAM v protokolech auditu cloudu ke kontrole privilegovaných aktivit

Poznámka: Pokud máte jiné systémy identit a ověřování, postupujte podle publikovaných osvědčených postupů, například pokud ke správě identity a přístupu GCP používáte Azure AD, postupujte podle Azure AD standardních hodnot zabezpečení.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace):

IM-3: Zabezpečená a automatická správa identit aplikací

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
– AC-2, AC-3, IA-4, IA-5, IA-9 –

Princip zabezpečení: Místo vytváření lidských účtů pro aplikace pro přístup k prostředkům a spouštění kódu používejte spravované identity aplikací. Identity spravovaných aplikací poskytují výhody, jako je snížení rizika odhalení přihlašovacích údajů. Automatizujte obměnu přihlašovacích údajů, abyste zajistili zabezpečení identit.

Pokyny k Azure: Použijte spravované identity Azure, které se můžou ověřovat ve službách a prostředcích Azure, které podporují ověřování Azure AD. Přihlašovací údaje spravované identity jsou plně spravované, obměňované a chráněné platformou, takže se vyhnete pevně zakódovaným přihlašovacím údajům ve zdrojovém kódu nebo konfiguračních souborech.

U služeb, které nepodporují spravované identity, použijte Azure AD k vytvoření instančního objektu s omezenými oprávněními na úrovni prostředku. Doporučujeme nakonfigurovat instanční objekty s přihlašovacími údaji certifikátu a vrátit se k tajným klíčům klienta pro ověření.

Implementace Azure a další kontext:

Pokyny pro AWS: Místo vytváření uživatelských účtů pro prostředky, které tuto funkci podporují, používejte role AWS IAM. Role IAM spravuje platforma v back-endu a přihlašovací údaje jsou dočasné a automaticky se obměňují. Tím se vyhnete vytváření dlouhodobých přístupových klíčů nebo uživatelského jména a hesla pro aplikace a pevně zakódovaných přihlašovacích údajů ve zdrojovém kódu nebo konfiguračních souborech.

Místo přizpůsobení vlastních oprávnění rolí IAM můžete použít role propojené se službou, které jsou připojené k předdefinovaným zásadám oprávnění pro přístup mezi službami AWS.

Poznámka: U služeb, které nepodporují role IAM, používejte přístupové klíče, ale dodržujte osvědčené postupy zabezpečení, jako je IM-8: Zabezpečte své klíče omezením vystavení přihlašovacích údajů a tajných kódů.

Implementace AWS a další kontext:

Pokyny ke GCP: Místo vytváření účtů spravovaných uživatelem pro prostředky, které tuto funkci podporují, používejte účty služeb spravované Googlem. Účty služby spravované Googlem spravuje platforma v back-endu a klíče účtu služby jsou dočasné a obměňují se automaticky. Tím se vyhnete vytváření dlouhodobých přístupových klíčů nebo uživatelského jména a hesla pro aplikace a pevně zakódovaných přihlašovacích údajů ve zdrojovém kódu nebo konfiguračních souborech.

Pomocí funkce Policy Intelligence můžete porozumět podezřelé aktivitě účtů služeb a rozpoznávat je.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace):

IM-4: Ověřování serveru a služeb

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
– IA-9 –

Princip zabezpečení: Ověřte vzdálené servery a služby ze strany klienta, abyste měli jistotu, že se připojujete k důvěryhodnému serveru a službám. Nejběžnějším protokolem ověřování serveru je protokol TLS (Transport Layer Security), kdy klient na straně klienta (často prohlížeč nebo klientské zařízení) ověřuje server ověřením, že certifikát serveru byl vydán důvěryhodnou certifikační autoritou.

Poznámka: Vzájemné ověřování je možné použít při vzájemném ověřování serveru i klienta.

Pokyny k Azure: Mnoho služeb Azure ve výchozím nastavení podporuje ověřování TLS. U služeb, které ve výchozím nastavení nepodporují ověřování TLS nebo podporují zakázání protokolu TLS, se ujistěte, že je vždy povolený, aby podporoval ověřování serveru nebo klienta. Klientská aplikace by také měla být navržená tak, aby ověřoval identitu serveru nebo klienta (ověřením certifikátu serveru vystaveného důvěryhodnou certifikační autoritou) ve fázi metody handshake.

Poznámka: Služby jako API Management a brána rozhraní API podporují vzájemné ověřování TLS.

Implementace Azure a další kontext:

Pokyny pro AWS: Mnoho služeb AWS ve výchozím nastavení podporuje ověřování TLS. U služeb, které ve výchozím nastavení nepodporují ověřování TLS nebo podporují zakázání protokolu TLS, se ujistěte, že je vždy povolený, aby podporoval ověřování serveru nebo klienta. Klientská aplikace by také měla být navržená tak, aby ověřoval identitu serveru nebo klienta (ověřením certifikátu serveru vystaveného důvěryhodnou certifikační autoritou) ve fázi metody handshake.

Poznámka: Služby, jako je brána rozhraní API, podporují vzájemné ověřování TLS.

Implementace AWS a další kontext:

Pokyny ke GCP: Mnoho služeb GCP ve výchozím nastavení podporuje ověřování TLS. U služeb, které tuto možnost ve výchozím nastavení nepodporují nebo podporují zakázání protokolu TLS, se ujistěte, že je vždy povolený pro podporu ověřování serveru nebo klienta. Klientská aplikace by také měla být navržená tak, aby ověřoval identitu serveru nebo klienta (ověřením certifikátu serveru vystaveného důvěryhodnou certifikační autoritou) ve fázi metody handshake.

Poznámka: Služby, jako je cloudové vyrovnávání zatížení, podporují vzájemné ověřování TLS.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace):

IM-5: Použití jednotného přihlašování (SSO) pro přístup k aplikacím

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
12.5 IA-4, IA-2, IA-8 –

Princip zabezpečení: Použití jednotného přihlašování (SSO) ke zjednodušení uživatelského prostředí pro ověřování v prostředcích, včetně aplikací a dat napříč cloudovými službami a místními prostředími.

Pokyny k Azure: Použijte Azure AD pro přístup k aplikacím úloh (přístup zákazníkům) prostřednictvím jednotného přihlašování (SSO) Azure AD, což snižuje potřebu duplicitních účtů. Azure AD poskytuje správu identit a přístupu k prostředkům Azure (v rovině správy, včetně rozhraní příkazového řádku, PowerShellu a portálu), cloudovým aplikacím a místním aplikacím.

Azure AD také podporuje jednotné přihlašování pro podnikové identity, jako jsou identity podnikových uživatelů, a také externí identity uživatelů od důvěryhodných třetích stran a veřejných uživatelů.

Implementace Azure a další kontext:

Pokyny pro AWS: Využijte AWS Cognito ke správě přístupu k úlohám aplikací pro zákazníky prostřednictvím jednotného přihlašování (SSO), aby zákazníci mohli přemíst své identity třetích stran od různých zprostředkovatelů identity.

Pokud chcete získat přístup pomocí jednotného přihlašování k nativním prostředkům AWS (včetně přístupu ke konzole AWS nebo správy služeb a přístupu na úrovni roviny dat), použijte AWS Sigle Sign-On, abyste snížili potřebu duplicitních účtů.

Jednotné přihlašování AWS také umožňuje přemostění podnikových identit (jako jsou identity z Azure Active Directory) s identitami AWS a také s identitami externích uživatelů od důvěryhodných třetích stran a veřejných uživatelů.

Implementace AWS a další kontext:

Pokyny ke GCP: Použijte cloudovou identitu Google ke správě přístupu k aplikacím, které mají zákazníky, a to prostřednictvím jednotného přihlašování ke cloudové identitě Google, což snižuje potřebu duplicitních účtů. Cloudová identita Google poskytuje správu identit a přístupu pro GCP (v rovině správy včetně Google Cloud CLI, přístupu ke konzole), cloudových aplikací a místních aplikací.

Cloudová identita Google také podporuje jednotné přihlašování pro podnikové identity, jako jsou identity podnikových uživatelů z Azure AD nebo Active Directory, a také externí identity uživatelů od důvěryhodných třetích stran a veřejných uživatelů. Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace):

IM-6: Použití ovládacích prvků silného ověřování

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Princip zabezpečení: Vynucujte silné ověřování (silné ověřování bez hesla nebo vícefaktorové ověřování) s centralizovaným systémem pro správu identit a ověřování pro veškerý přístup k prostředkům. Ověřování založené pouze na přihlašovacích údajích hesla se považuje za starší, protože je nezabezpečené a neobstojí s oblíbenými metodami útoku.

Při nasazování silného ověřování nejprve nakonfigurujte správce a privilegované uživatele, abyste zajistili nejvyšší úroveň metody silného ověřování, a pak rychle zavést příslušné zásady silného ověřování pro všechny uživatele.

Poznámka: Pokud starší verze aplikací a scénářů vyžaduje ověřování pomocí hesla, zajistěte, aby se dodržovaly osvědčené postupy zabezpečení hesel, jako jsou požadavky na složitost.

Pokyny k Azure: Azure AD podporuje silné ověřování prostřednictvím metod bez hesla a vícefaktorového ověřování (MFA).

  • Ověřování bez hesla: Jako výchozí metodu ověřování používejte ověřování bez hesla. V ověřování bez hesla jsou k dispozici tři možnosti: Windows Hello pro firmy, přihlášení pomocí telefonu pomocí aplikace Microsoft Authenticator a klíče zabezpečení FIDO2. Kromě toho můžou zákazníci používat místní metody ověřování, jako jsou čipové karty.
  • Vícefaktorové ověřování: Azure MFA je možné vynutit u všech uživatelů, vybraných uživatelů nebo na úrovni jednotlivých uživatelů na základě podmínek přihlášení a rizikových faktorů. Povolte Azure MFA a postupujte podle Microsoft Defender doporučení ke správě cloudových identit a přístupu pro nastavení vícefaktorového ověřování.

Pokud se pro ověřování Azure AD stále používá starší verze ověřování pomocí hesla, mějte na paměti, že výhradně cloudové účty (uživatelské účty vytvořené přímo v Azure) mají výchozí základní zásady hesel. A hybridní účty (uživatelské účty, které pocházejí z místní Active Directory) se řídí místními zásadami hesel.

U aplikací a služeb třetích stran, které můžou mít výchozí ID a hesla, byste je měli zakázat nebo změnit během počátečního nastavení služby.

Implementace Azure a další kontext:

Pokyny pro AWS: AWS IAM podporuje ovládací prvky silného ověřování prostřednictvím vícefaktorového ověřování (MFA). Vícefaktorové ověřování je možné vynutit u všech uživatelů, vybraných uživatelů nebo na úrovni jednotlivých uživatelů na základě definovaných podmínek.

Pokud používáte podnikové účty z adresáře třetí strany (například Windows Active Directory) s identitami AWS, postupujte podle příslušných pokynů k zabezpečení a vynucujte silné ověřování. Pokud ke správě přístupu k AWS používáte Azure AD, projděte si pokyny k tomuto ovládacímu prvku v Azure.

Poznámka: U aplikací třetích stran a služeb AWS, které můžou mít výchozí ID a hesla, byste je měli zakázat nebo změnit během počátečního nastavení služby.

Implementace AWS a další kontext:

Pokyny ke GCP: Cloudová identita Google podporuje ovládací prvky silného ověřování prostřednictvím vícefaktorového ověřování (MFA). Vícefaktorové ověřování je možné vynutit u všech uživatelů, vybraných uživatelů nebo na úrovni jednotlivých uživatelů na základě definovaných podmínek. Pokud chcete chránit účty supersprávce cloudových identit (a pracovních prostorů), zvažte použití klíčů zabezpečení a programu Google Advanced Protection Pro zajištění maximálního zabezpečení.

Pokud používáte podnikové účty z adresáře třetí strany (například Windows Active Directory) s identitami Google Cloud, postupujte podle příslušných pokynů k zabezpečení a vynucujte silné ověřování. Pokud ke správě přístupu ke cloudu Google používáte Azure AD, projděte si pokyny k tomuto ovládacímu prvku v Azure.

K vytvoření vrstvy centrální autorizace pro aplikace, ke které přistupuje protokol HTTPS, použijte Identity-Aware Proxy, abyste místo spoléhání se na brány firewall na úrovni sítě mohli použít model řízení přístupu na úrovni aplikace.

Poznámka: U aplikací třetích stran a služeb GCP, které můžou mít výchozí ID a hesla, byste je měli zakázat nebo změnit během počátečního nastavení služby.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace):

IM-7: Omezení přístupu k prostředkům na základě podmínek

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Princip zabezpečení: V rámci modelu přístupu s nulovou důvěryhodností explicitně ověřte důvěryhodné signály pro povolení nebo odepření přístupu uživatelů k prostředkům. Signály k ověření by měly zahrnovat silné ověřování uživatelského účtu, analýzu chování uživatelského účtu, důvěryhodnost zařízení, členství uživatele nebo skupiny, umístění atd.

Pokyny k Azure: Použití Azure AD podmíněného přístupu k podrobnějšímu řízení přístupu na základě uživatelem definovaných podmínek, jako je vyžadování přihlášení uživatelů z určitých rozsahů IP adres (nebo zařízení) k používání vícefaktorového ověřování. Azure AD podmíněný přístup umožňuje vynutit řízení přístupu v aplikacích vaší organizace na základě určitých podmínek.

Definujte příslušné podmínky a kritéria pro Azure AD podmíněného přístupu v úloze. Zvažte následující běžné případy použití:

  • Vyžadování vícefaktorového ověřování pro uživatele s rolemi správce
  • Vyžadování vícefaktorového ověřování pro úlohy správy Azure
  • Blokování přihlášení uživatelů, kteří se pokoušejí použít starší ověřovací protokoly
  • Vyžadování důvěryhodných umístění pro registraci vícefaktorového ověřování Azure AD
  • Blokování nebo udělení přístupu z konkrétních umístění
  • Blokování rizikového chování při přihlašování
  • Vyžadování zařízení spravovaných organizací pro konkrétní aplikace

Poznámka: Podrobné ovládací prvky správy relací ověřování je možné implementovat také prostřednictvím zásad podmíněného přístupu Azure AD, jako je frekvence přihlašování a trvalá relace prohlížeče.

Implementace Azure a další kontext:

Pokyny pro AWS: Vytvořte zásady IAM a definujte podmínky pro podrobnější řízení přístupu na základě uživatelem definovaných podmínek, jako je vyžadování přihlášení uživatelů z určitých rozsahů IP adres (nebo zařízení), aby používala vícefaktorové ověřování. Nastavení podmínky může zahrnovat jednu nebo více podmínek a také logiku.

Zásady je možné definovat ze šesti různých dimenzí: zásady založené na identitách, zásady založené na prostředcích, hranice oprávnění, zásady řízení služeb AWS Organizations , Access Control Seznamy (ACL) a zásady relací.

Implementace AWS a další kontext:

Pokyny ke GCP: Vytvořte a definujte podmínky IAM pro podrobnější řízení přístupu na základě atributů na základě uživatelem definovaných podmínek, jako je vyžadování přihlášení uživatelů z určitých rozsahů IP adres (nebo zařízení) k používání vícefaktorového ověřování. Nastavení podmínky může zahrnovat jednu nebo více podmínek a také logiku.

Podmínky se zadává ve vazbách rolí v zásadách povolení prostředku. Atributy podmínky jsou založené na požadovaném prostředku – například na jeho typu nebo názvu – nebo na podrobnostech o požadavku – například na jeho časovém razítku nebo cílové IP adrese.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace) :

IM-8: Omezení odhalení přihlašovacích údajů a tajných kódů

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS verze 3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Princip zabezpečení: Ujistěte se, že vývojáři aplikací bezpečně zpracovávají přihlašovací údaje a tajné kódy:

  • Vyhněte se vkládání přihlašovacích údajů a tajných kódů do kódu a konfiguračních souborů.
  • Použití trezoru klíčů nebo služby zabezpečeného úložiště klíčů k uložení přihlašovacích údajů a tajných kódů
  • Vyhledejte přihlašovací údaje ve zdrojovém kódu.

Poznámka: To se často řídí a vynucuje prostřednictvím zabezpečeného životního cyklu vývoje softwaru (SDLC) a procesu zabezpečení DevOps.

Pokyny pro Azure: Pokud použití spravované identity není možné, ujistěte se, že jsou tajné kódy a přihlašovací údaje uložené v zabezpečených umístěních, jako je Azure Key Vault, a ne vkládejte je do kódu a konfiguračních souborů.

Pokud pro platformu pro správu kódu používáte Azure DevOps a GitHub:

  • Implementujte nástroj Azure DevOps Pro kontrolu přihlašovacích údajů a identifikujte přihlašovací údaje v kódu.
  • Pro GitHub použijte funkci nativní kontroly tajných kódů k identifikaci přihlašovacích údajů nebo jiné formy tajných kódů v kódu.

Klienti, jako jsou Azure Functions, služby Azure Apps a virtuální počítače, můžou používat spravované identity pro zabezpečený přístup k Azure Key Vault. Informace o správě tajných kódů najdete v tématu Ovládací prvky ochrany dat související s používáním Azure Key Vault.

Poznámka: Azure Key Vault poskytuje automatickou obměnu podporovaných služeb. U tajných kódů, které nelze automaticky otočit, se ujistěte, že se pravidelně ručně obměňují a vyprázdní, když se už nepoužívají.

Implementace Azure a další kontext:

Pokyny pro AWS: Pokud není možné použít roli IAM pro přístup k aplikacím, ujistěte se, že jsou tajné kódy a přihlašovací údaje uložené v zabezpečených umístěních, jako je správce tajných klíčů AWS nebo úložiště parametrů správce systémů, a ne vkládejte je do kódu a konfiguračních souborů.

K analýze statického kódu použijte Kontrolor CodeGuru, který dokáže rozpoznat tajné kódy pevně zakódované ve zdrojovém kódu.

Pokud pro platformu pro správu kódu používáte Azure DevOps a GitHub:

  • Implementujte nástroj Azure DevOps Pro kontrolu přihlašovacích údajů a identifikujte přihlašovací údaje v kódu.
  • Pro GitHub použijte funkci nativní kontroly tajných kódů k identifikaci přihlašovacích údajů nebo jiných forem tajných kódů v kódu.

Poznámka: Správce tajných kódů poskytuje pro podporované služby automatickou obměnu tajných kódů. U tajných kódů, které nelze automaticky otočit, se ujistěte, že se pravidelně ručně obměňují a vyprázdní, když se už nepoužívají.

Implementace AWS a další kontext:

Pokyny pro GCP: Pokud není možné použít účet služby spravovaný Googlem pro přístup k aplikacím, ujistěte se, že jsou tajné kódy a přihlašovací údaje uložené v zabezpečených umístěních, jako je Správce tajných kódů Google Cloud, a ne vkládejte je do kódu a konfiguračních souborů.

Pomocí rozšíření Google Cloud Code v integrovaném vývojovém prostředí (IDE), jako je Visual Studio Code, můžete do kódu integrovat tajné kódy spravované pomocí Secret Manageru.

Pokud pro svou platformu pro správu kódu používáte Azure DevOps nebo GitHub:

  • Implementujte nástroj Azure DevOps Pro kontrolu přihlašovacích údajů a identifikujte přihlašovací údaje v kódu.
  • Pro GitHub použijte funkci nativní kontroly tajných kódů k identifikaci přihlašovacích údajů nebo jiných forem tajných kódů v kódu.

Poznámka: Osvědčeným postupem je nastavit plány obměny pro tajné kódy uložené ve Správci tajných klíčů.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace) :

IM-9: Zabezpečený uživatelský přístup k existujícím aplikacím

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID(s) ID PCI-DSS verze 3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 –

Princip zabezpečení: V hybridním prostředí, kde máte místní aplikace nebo ne nativní cloudové aplikace využívající starší ověřování, zvažte řešení, jako je zprostředkovatel zabezpečení přístupu k cloudu (CASB), proxy aplikací nebo jednotné přihlašování( SSO), která řídí přístup k těmto aplikacím s následujícími výhodami:

  • Vynucení centralizovaného silného ověřování
  • Monitorování a řízení rizikových aktivit koncových uživatelů
  • Monitorování a náprava rizikových aktivit starších aplikací
  • Detekce a prevence přenosu citlivých dat

Pokyny pro Azure: Ochrana místních a ne nativních cloudových aplikací pomocí staršího ověřování jejich propojením s:

  • Azure AD proxy aplikací a nakonfigurujte ověřování na základě hlaviček tak, aby vzdálené uživatele umožňovalo přístup k aplikacím pomocí jednotného přihlašování (SSO), a zároveň explicitně ověřuje důvěryhodnost vzdálených uživatelů i zařízení s Azure AD podmíněným přístupem. V případě potřeby použijte řešení SDP (Software-Defined Perimeter) třetí strany, které může nabídnout podobné funkce.
  • Microsoft Defender for Cloud Apps, která slouží službě CASB (Cloud Access Security Broker) k monitorování a blokování přístupu uživatelů k neschváleném aplikacím SaaS třetích stran.
  • Vaše stávající řadiče a sítě pro doručování aplikací třetích stran.

Poznámka: Sítě VPN se běžně používají pro přístup ke starším aplikacím a často mají jenom základní řízení přístupu a omezené monitorování relací.

Implementace Azure a další kontext:

Pokyny pro AWS: Postupujte podle pokynů Azure k ochraně místních i ne nativních cloudových aplikací pomocí staršího ověřování tím, že je připojíte k:

  • Azure AD proxy aplikací a nakonfigurujte na základě hlaviček přístup pomocí jednotného přihlašování k aplikacím vzdáleným uživatelům a zároveň explicitně ověřuje důvěryhodnost vzdálených uživatelů i zařízení s Azure AD podmíněným přístupem. V případě potřeby použijte řešení SDP (Software-Defined Perimeter) třetí strany, které může nabídnout podobné funkce.
  • Microsoft Defender for Cloud Apps, která slouží jako služba CASB (Cloud Access Security Broker) pro monitorování a blokování přístupu uživatelů k neschváleném aplikacím SaaS třetích stran.
  • Vaše stávající řadiče a sítě pro doručování aplikací třetích stran

Poznámka: Sítě VPN se běžně používají pro přístup ke starším aplikacím a často mají jenom základní řízení přístupu a omezené monitorování relací.

Implementace AWS a další kontext:

Pokyny pro GCP: Ke správě přístupu k aplikacím založeným na protokolu HTTP mimo Google Cloud, včetně místních aplikací, použijte Google Cloud Identity-Aware Proxy (IAP). IAP funguje pomocí podepsaných hlaviček nebo rozhraní USERS API ve standardním prostředí App Engine. V případě potřeby použijte řešení SDP (Software-Defined Perimeter) třetí strany, které může nabídnout podobné funkce.

Můžete také použít Microsoft Defender for Cloud Apps, která slouží jako služba CASB (Cloud Access Security Broker) k monitorování a blokování přístupu uživatelů k neschváleném aplikacím SaaS třetích stran.

Poznámka: Sítě VPN se běžně používají pro přístup ke starším aplikacím a často mají jenom základní řízení přístupu a omezené monitorování relací.

Implementace GCP a další kontext:

Účastníci zabezpečení zákazníků (další informace) :