Sdílet prostřednictvím

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

Správa identit se zabývá ovládacími prvky pro vytvoření zabezpečeného řízení identit a přístupu pomocí systémů pro správu 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 kódy 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í: Použijte centralizovaný systém identit a ověřování k řízení identit a ověřování vaší organizace pro cloudové a necloudové prostředky.

Doprovodné materiály k Azure: Azure Active Directory (Azure AD) je služba pro správu identit a ověřování v Azure. Ve službě Azure AD byste měli standardizovat řízení identity a ověřování vaší organizace v těchto službách:

  • 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í na prostředcích podnikové sítě a aplikace SaaS třetích stran.
  • Podnikové identity ve službě Active Directory díky synchronizaci do Azure AD za účelem zajištění konzistentní a centrálně spravované strategie identit.

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

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

Implementace Azure a další kontext:

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

AWS podporuje jednoúčelové Sign-On, které vám umožní přemístit identity třetích stran vaší společnosti (jako je Windows Active Directory nebo jiné úložiště identit) s identitami AWS, abyste se vyhnuli vytváření duplicitních účtů pro přístup k prostředkům AWS.

Implementace AWS a další kontext:

Pokyny pro GCP: Systém IAM (Identity and Access Management) společnosti Google Cloud je výchozí služba pro správu identit a ověřování Google Cloud, která se používá pro účty identit Google Cloud. Správa identit gCP a přístupu pomocí služby Google Cloud IAM. Alternativně můžete prostřednictvím služby Google Cloud Identity a Azure Sigle Sign-On (SSO) spravovat identitu a řízení přístupu GCP, abyste se vyhnuli samostatné správě duplicitních účtů v prostředí mutli-cloud.

Google Cloud Identity je zprostředkovatelem identity pro všechny služby Google. Podporuje jedno Sign-On, což umožňuje přemístit identity třetích stran vaší společnosti (jako je 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žívání Google Cloud Directory Sync. Google poskytuje nástroj konektoru, 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 služby Google Cloud Directory Sync můžete nakonfigurovat, které uživatelské účty – včetně uživatelů, skupin a profilů uživatelů, aliasů a dalších – se budou synchronizovat podle plánu mezi místním systémem správy identit a systémem GCP.

Implementace GCP a další kontext:

Zúčastněné strany zabezpečení zákazníků (Další informace):

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

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID kódy 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í systému identit a ověřování jako vysoké priority v praxi cloudového zabezpečení vaší organizace. Mezi běžné bezpečnostní prvky patří:

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

Doprovodné materiály k Azure: Pomocí standardních hodnot zabezpečení azure AD a skóre zabezpečení identity Azure AD vyhodnoťte stav zabezpečení identit Azure AD a opravte mezery 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
  • Povolit politiku k blokování staršího ověřování
  • Ujistěte se, že všichni uživatelé můžou dokončit vícefaktorové ověřování pro zabezpečený přístup.
  • Vyžadovat vícefaktorové ověřování pro administrátorské role
  • Povolení samoobslužného resetování hesla
  • Nevyprší platnost hesel
  • Zapnutí zásad rizik přihlašování
  • Nepovolit uživatelům udělit souhlas s nespravovanými aplikacemi

Pomocí služby Azure AD Identity Protection můžete zjišťovat, zkoumat a opravovat rizika založená na identitách. Pokud chcete podobnou ochranu místní domény Active Directory, použijte Defender for Identity.

Poznámka: Dodržujte publikované osvědčené postupy pro všechny ostatní komponenty identit, včetně vaší místní služby Active Directory a všech funkcí třetích stran a infrastruktury (například operačních systémů, sítí, databází), které je hostují.

Implementace Azure a další kontext:

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

  • Nastavení kořenových uživatelských přístupových klíčů účtu AWS pro nouzový přístup, jak je popsáno v PA-5 (nastavení nouzového přístupu)
  • Dodržování principů nejnižších oprávnění pro přiřazení přístupu
  • Využijte skupiny IAM k použití zásad místo jednotlivých uživatelů.
  • Postupujte podle pokynů pro silné ověřování v IM-6 (Použití ovládacích prvků silného ověřování) pro všechny uživatele.
  • Použijte Zásady řízení služby (Service Control Policy, SCP) a omezení oprávnění organizace AWS.
  • Auditování přístupu ke službám pomocí IAM Access Advisoru
  • Použijte sestavu přihlašovacích údajů IAM k sledování uživatelských účtů a stavu 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ě identity a přístupu používáte Azure AD, postupujte podle standardních hodnot zabezpečení Azure AD.

Implementace AWS a další kontext:

Pokyny pro GCP: K zabezpečení služeb Google Cloud IAM a Cloud Identity pro vaše organizace použijte následující osvědčené postupy zabezpečení:

  • Podle doporučení v PA-5 (Nastavení nouzového přístupu) nastavte účet supersprávce pro nouzový přístup.
  • Vytvořte e-mailovou adresu supersprávce (jako účet supersprávce Google Workspace nebo supersprávce cloudové identity) a tento účet by neměl být specifický pro konkrétního uživatele v případě potřeby nouzového obnovení.
  • Dodržování principu nejmenších oprávnění a oddělení povinností
  • Vyhněte se používání účtu supersprávce pro každodenní aktivity
  • Využijte skupiny identit Google Cloud k použití zásad místo použití zásad pro jednotlivé uživatele.
  • Postupujte podle pokynů pro silné ověřování, jak je popsáno v 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.
  • Omezení přístupu k prostředkům pomocí zásad IAM
  • Řízení a konfigurace omezení prostředků pomocí služby Organization Policy Service
  • 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 ACP a přístupu používáte Azure AD, postupujte podle standardních hodnot zabezpečení Azure AD.

Implementace GCP a další kontext:

Zúčastněné strany 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 kódy ID PCI-DSS v3.2.1
není k dispozici AC-2, AC-3, IA-4, IA-5, IA-9 není k dispozici

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

Doprovodné materiály k Azure: Použijte spravované identity Azure, které se můžou ověřit ve službách a prostředcích Azure, které podporují ověřování Azure AD. Přihlašovací údaje pro spravovanou identitu jsou plně spravovány, rotovány a chráněny platformou, což vám umožňuje vyhnout se pevně zakódovaným přihlašovacím údajům ve zdrojovém kódu nebo konfiguračních souborech.

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

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 zabrání vytváření dlouhodobých přístupových klíčů nebo uživatelského jména a hesla pro aplikace a pevně zakódované přihlašovací údaje ve zdrojovém kódu nebo konfiguračních souborech.

Místo přizpůsobení vlastních oprávnění pro role IAM můžete použít role propojené se službou, které jsou připojené k předem definovaným zásadám oprávnění 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 postupujte podle osvědčených postupů zabezpečení, jako je im-8, omezte vystavení přihlašovacích údajů a tajných kódů, aby se klíče zabezpečily.

Implementace AWS a další kontext:

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

Využijte Funkci Policy Intelligence k pochopení a rozpoznávání podezřelých aktivit pro účty služeb.

Implementace GCP a další kontext:

Zúčastněné strany zabezpečení zákazníků (Další informace):

IM-4: Ověření serveru a služeb

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID kódy ID PCI-DSS v3.2.1
není k dispozici IA-9 není k dispozici

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

Poznámka: Vzájemné ověřování lze použít, když se server i klient navzájem ověřují.

Doprovodné materiály 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 povoleno podporovat ověřování serveru nebo klienta. Vaše klientská aplikace by měla být také navržená k ověření identity serveru nebo klienta (ověřením certifikátu serveru vydaného důvěryhodnou certifikační autoritou) ve fázi handshake.

Poznámka: Služby, jako je 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 povoleno podporovat ověřování serveru nebo klienta. Vaše klientská aplikace by měla být také navržená k ověření identity serveru nebo klienta (ověřením certifikátu serveru vydaného důvěryhodnou certifikační autoritou) ve fázi handshake.

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

Implementace AWS a další kontext:

Pokyny pro GCP: Mnoho služeb GCP ve výchozím nastavení podporuje ověřování TLS. U služeb, které tento protokol ve výchozím nastavení nepodporují nebo podporují zakázání protokolu TLS, se ujistěte, že je vždy povoleno podporovat ověřování serveru nebo klienta. Vaše klientská aplikace by měla být také navržená k ověření identity serveru nebo klienta (ověřením certifikátu serveru vydaného důvěryhodnou certifikační autoritou) ve fázi 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:

Zúčastněné strany 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 kódy ID PCI-DSS v3.2.1
12.5 IA-4, IA-2, IA-8 není k dispozici

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

Pokyny k Azure: Použití 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, portálu), cloudových aplikací a místních aplikací.

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

Implementace Azure a další kontext:

Pokyny k AWS: Použijte AWS Cognito ke správě přístupu k vašim aplikacím zaměřeným na zákazníky prostřednictvím jednotného přihlašování (SSO), které zákazníkům umožní propojit své identity třetích stran od různých zprostředkovatelů identity.

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

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

Implementace AWS a další kontext:

Pokyny pro GCP: Použijte Google Cloud Identity k správě přístupu k aplikaci zaměřené na zákazníky prostřednictvím Google Cloud Identity Single Sign-On, což snižuje potřebu duplicitních účtů. Identita cloudu Google poskytuje správu identit a přístupu ke GCP (v rovině správy, včetně Rozhraní příkazového řádku Google Cloud, přístupu ke konzole), cloudových aplikací a místních aplikací.

Identita cloudu Google také podporuje jednotné přihlašování pro podnikové identity, jako jsou podnikové identity 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:

Zúčastněné strany 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 kódy 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 kontrolní mechanismy silného ověřování (silné ověřování bez hesel nebo vícefaktorové ověřování) s centralizovaným systémem správy identit a ověřování pro veškerý přístup k prostředkům. Ověřování založené na samotných přihlašovacích údajích hesla se považuje za zastaralé, protože je nezabezpečené a nevystupuje na oblíbené metody útoku.

Při nasazování silného ověřování nejprve nakonfigurujte správce a privilegované uživatele, aby se zajistila nejvyšší úroveň metody silného ověřování, rychle následovaná zavedením příslušných zásad silného ověřování pro všechny uživatele.

Poznámka: Pokud je pro starší aplikace a scénáře vyžadováno starší ověřování založené na heslech, ujistěte se, že jsou dodrženy osvědčené postupy zabezpečení hesel, jako jsou požadavky na složitost.

Doprovodné materiály k Azure: Azure AD podporuje silné ověřování prostřednictvím metod bez hesel 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. Při ověřování bez hesla jsou k dispozici tři možnosti: Windows Hello pro firmy, přihlášení k telefonu v aplikaci Microsoft Authenticator a klíče zabezpečení FIDO2. Zákazníci navíc můžou používat místní metody ověřování, jako jsou čipové karty.
  • Vícefaktorové ověřování: Azure MFA se dá vynutit pro všechny uživatele, vybrat uživatele 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 doporučení microsoft Defenderu pro správu identit cloudu 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í založené na heslech, mějte na paměti, že cloudové účty (uživatelské účty vytvořené přímo v Azure) mají výchozí zásady základního hesla. A hybridní účty (uživatelské účty, které pocházejí z místní služby 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 během počátečního nastavení služby zakázat nebo změnit.

Implementace Azure a další kontext:

Pokyny pro AWS: AWS IAM podporuje silné ověřování prostřednictvím vícefaktorového ověřování (MFA). Vícefaktorové ověřování je možné vynutit pro všechny uživatele, vybrat uživatele 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 AWS používáte Azure AD, projděte si pokyny k 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 během počátečního nastavení služby zakázat nebo změnit.

Implementace AWS a další kontext:

Pokyny pro GCP: Google Cloud Identity 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 pro všechny uživatele, vybrat uživatele 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 službě Google Cloud používáte Azure AD, projděte si pokyny k Azure.

Pomocí Identity-Aware Proxy vytvořte centrální autorizační vrstvu pro aplikace, ke které přistupuje protokol HTTPS, takže můžete použít model řízení přístupu na úrovni aplikace místo toho, abyste se museli spoléhat na brány firewall na úrovni sítě.

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 během počátečního nastavení služby zakázat nebo změnit.

Implementace GCP a další kontext:

Zúčastněné strany 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 kódy ID PCI-DSS v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Princip zabezpečení: Explicitně ověřte důvěryhodné signály, které umožní nebo zamítnou přístup uživatelů k prostředkům jako součást modelu přístupu nulové důvěryhodnosti. 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živatelů nebo skupin, umístění atd.

Pokyny k Azure: Použití podmíněného přístupu Azure AD 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í. Podmíněný přístup Azure AD umožňuje vynucovat ří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 podmíněný přístup Azure AD 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 pro správu
  • Vyžadování vícefaktorového ověřování pro úlohy správy Azure
  • Blokování přihlášení pro uživatele, kteří se pokoušejí používat starší ověřovací protokoly
  • Vyžadování důvěryhodných umístění pro registraci služby Azure AD Multi-Factor Authentication
  • Blokování nebo povolení přístupu z určitý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: Granulární řízení relací ověřování lze také implementovat 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, například 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 i 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 (SCP), seznamy řízení přístupu (ACL) a zásady relací.

Implementace AWS a další kontext:

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

Podmínky se zadají v vazbách rolí zásad 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 časové razítko nebo cílovou IP adresu.

Implementace GCP a další kontext:

Zúčastněné strany zabezpečení zákazníků (Další informace):

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

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID kódy ID PCI-DSS v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Princip zabezpečení: Zajistěte, aby vývojáři aplikací bezpečně zpracovávali 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: Často se to řídí a vynucuje prostřednictvím zabezpečeného životního cyklu vývoje softwaru (SDLC) a procesu zabezpečení DevOps.

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

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

  • Implementujte Skener přihlašovacích údajů Azure DevOps, který identifikuje 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 bezpečně přistupovat ke službě Azure Key Vault pomocí spravovaných identit. Viz ovládací prvky ochrany dat související s používáním služby Azure Key Vault pro správu tajných kódů.

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ě obměňují a vyprázdní, když se už nepoužívají.

Implementace Azure a další kontext:

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

Ke statické analýze kódu můžete použít CodeGuru Reviewer, který dokáže rozpoznat tajné kódy pevně zakódované ve zdrojovém kódu.

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

  • Implementujte Skener přihlašovacích údajů Azure DevOps, který identifikuje 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 automatickou obměnu tajných kódů pro podporované služby. U tajných kódů, které nelze automaticky otočit, se ujistěte, že se pravidelně obměňují a vyprázdní, když se už nepoužívají.

Implementace AWS a další kontext:

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

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

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

  • Implementujte Skener přihlašovacích údajů Azure DevOps, který identifikuje 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: Jako osvědčený postup nastavte plány obměny tajemství uložených v Secret Manageru.

Implementace GCP a další kontext:

Zúčastněné strany zabezpečení zákazníků (Další informace):

IM-9: Zabezpečení přístupu uživatelů k existujícím aplikacím

ID ovládacích prvků CIS v8 NIST SP 800-53 r4 ID kódy ID PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 není k dispozici

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 například zprostředkovatel zabezpečení přístupu ke cloudu (CASB), proxy aplikací, jednotné přihlašování (SSO), které řídí přístup k těmto aplikacím, a to za účelem následujících výhod:

  • 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 starších aktivit aplikací
  • Detekce a prevence přenosu citlivých dat

Doprovodné materiály k Azure: Chraňte své místní a ne nativní cloudové aplikace pomocí starší verze ověřování tím, že je připojíte k:

  • Proxy aplikací Azure AD a konfigurace ověřování založeného na hlavičkách pro umožnění jednotného přihlašování (SSO) k aplikacím pro vzdálené uživatele, přičemž se explicitně ověřuje důvěryhodnost jak vzdálených uživatelů, tak zařízení pomocí podmíněného přístupu Azure AD. V případě potřeby použijte řešení třetí strany Software-Defined Perimeter (SDP), které může poskytovat obdobné funkce.
  • Microsoft Defender for Cloud Apps, která obsluhuje službu CASB (Cloud Access Security Broker), která monitoruje a blokuje přístup uživatelů k neschválené aplikacím SaaS třetích stran.
  • Vaše stávající kontrolery 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í pouze základní řízení přístupu a omezené monitorování relací.

Implementace Azure a další kontext:

Doprovodné materiály k AWS: Postupujte podle pokynů Azure k ochraně místních a ne nativních cloudových aplikací s využitím staršího ověřování tím, že je připojíte k:

  • Proxy aplikací Azure AD a konfigurace založená na hlavičkách pro povolení jednotného přihlašování (SSO) pro přístup k aplikacím vzdálených uživatelů, přičemž se pomocí podmíněného přístupu Azure AD výslovně ověřuje důvěryhodnost jak vzdálených uživatelů, tak i zařízení. V případě potřeby použijte řešení Software-Defined hraniční sítě (SDP) třetí strany, které může nabízet podobné funkce.
  • Microsoft Defender for Cloud Apps, který slouží jako služba CASB (Cloud Access Security Broker), která monitoruje a blokuje přístup uživatelů k neschválené aplikacím SaaS třetích stran.
  • Vaše stávající kontrolery 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í pouze 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 Proxy Identity-Aware Google Cloud (IAP). Protokol 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í Software-Defined hraniční sítě (SDP) třetích stran, které může nabízet podobné funkce.

Máte také možnost 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é 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í pouze základní řízení přístupu a omezené monitorování relací.

Implementace GCP a další kontext:

Zúčastněné strany zabezpečení zákazníků (Další informace):