Aspekty ochrany dat
Následující diagram znázorňuje, jak služby ukládají a načítají data objektů Microsoft Entra prostřednictvím autorizační vrstvy řízení přístupu na základě role (RBAC). Tato vrstva volá vrstvu přístupu k datům interního adresáře a zajišťuje, aby byla povolena žádost uživatele o data:
Microsoft Entra Internal Interfaces Access: Komunikace mezi službami s jinými služby Microsoft, jako je Microsoft 365, používají rozhraní Microsoft Entra ID, která autorizuje volající služby pomocí klientských certifikátů.
Přístup k externím rozhraním Microsoft Entra: Externí rozhraní Microsoft Entra pomáhá zabránit úniku dat pomocí RBAC. Když objekt zabezpečení, například uživatel, vytvoří žádost o přístup ke čtení informací prostřednictvím rozhraní Microsoft Entra ID, musí být k žádosti připojen token zabezpečení. Token obsahuje deklarace identity týkající se objektu zabezpečení, který požadavek vytváří.
Tokeny zabezpečení vydává ověřovací služba Microsoft Entra. Informace o existenci, povoleném stavu a roli uživatele používají autorizační systém k rozhodnutí, jestli je požadovaný přístup k cílovému tenantovi autorizovaný pro tohoto uživatele v této relaci.
Přístup k aplikacím: Vzhledem k tomu, že aplikace mají přístup k aplikačním programovacím rozhraním (API) bez kontextu uživatele, kontrola přístupu obsahuje informace o aplikaci uživatele a rozsahu požadovaného přístupu, například jen pro čtení, čtení a zápis atd. Mnoho aplikací používá OpenID Connect nebo Open Authorization (OAuth) k získání tokenů pro přístup k adresáři jménem uživatele. Tyto aplikace musí mít explicitně udělený přístup k adresáři nebo neobdrží token ze služby Ověřování Microsoft Entra a přistupují k datům z uděleného oboru.
Auditování: Přístup je auditován. Například autorizované akce, jako je vytvoření uživatele a resetování hesla, vytvoří záznam auditu, který může správce tenanta použít ke správě úsilí o dodržování předpisů nebo šetření. Správci tenantů můžou generovat sestavy auditu pomocí rozhraní MICROSOFT Entra Audit API.
Další informace: Protokoly auditu v Microsoft Entra ID
Izolace tenanta: Vynucení zabezpečení v prostředí Microsoft Entra s více tenanty pomáhá dosáhnout dvou primárních cílů:
- Zabránění úniku dat a přístupu mezi tenanty: Data patřící do tenanta 1 nemůžou získat uživatelé v tenantovi 2 bez explicitní autorizace tenanta 1.
- Izolace přístupu k prostředkům mezi tenanty: Operace prováděné tenantem 1 nemají vliv na přístup k prostředkům tenanta 2.
Izolace tenanta
Následující informace popisují izolaci tenanta.
- Služba zabezpečuje tenanty pomocí zásad RBAC k zajištění izolace dat.
- Pokud chcete povolit přístup k tenantovi, musí být objekt zabezpečení, například uživatel nebo aplikace, schopný ověřit pomocí ID Microsoft Entra, aby získal kontext a má explicitní oprávnění definovaná v tenantovi. Pokud objekt zabezpečení není v tenantovi autorizovaný, výsledný token nebude přenášet oprávnění a systém RBAC odmítne požadavky v tomto kontextu.
- RBAC zajišťuje, že přístup k tenantovi provádí objekt zabezpečení autorizovaný v tenantovi. Přístup mezi tenanty je možný, když správce tenanta vytvoří ve stejném tenantovi reprezentaci objektu zabezpečení (například zřízení uživatelského účtu typu host pomocí spolupráce B2B) nebo když správce tenanta vytvoří zásadu pro povolení vztahu důvěryhodnosti s jiným tenantem. Například zásady přístupu mezi tenanty pro povolení B2B Direct Connect. Každý tenant je hranice izolace; existence v jednom tenantovi se neshoduje s jiným tenantem, pokud to správce nepochybuje.
- Data Microsoft Entra pro více tenantů se ukládají na stejném fyzickém serveru a jednotce pro daný oddíl. Izolace je zajištěna, protože přístup k datům je chráněný autorizačním systémem RBAC.
- Aplikace zákazníka nemá přístup k ID Microsoft Entra bez nutnosti ověřování. Žádost je odmítnuta, pokud není doprovázena přihlašovacími údaji v rámci počátečního procesu vyjednávání připojení. Tato dynamická brání neoprávněnému přístupu k tenantovi sousedními tenanty. Zprostředkuje se federovaný vztah důvěryhodnosti pouze token přihlašovacích údajů uživatele nebo token SAML (Security Assertion Markup Language). Proto je ověřeno ID Microsoft Entra na základě sdílených klíčů nakonfigurovaných vlastníkem aplikace.
- Vzhledem k tomu, že neexistuje žádná komponenta aplikace, která by se spustila z Core Storu, není možné, aby jeden tenant vynutil porušení integrity sousedního tenanta.
Zabezpečení dat
Šifrování během přenosu: Aby bylo zajištěno zabezpečení dat, data adresáře v ID Microsoft Entra se při přenosu mezi datovými centry v jednotce škálování šifrují a šifrují. Data jsou šifrovaná a nešifrovaná vrstvou Microsoft Entra Core Store, která se nachází v zabezpečených oblastech hostování serverů přidružených datacenter Microsoftu.
Webové služby přístupné zákazníkům jsou zabezpečené protokolem TLS (Transport Layer Security).
Tajné úložiště: Back-end služby Microsoft Entra používá šifrování k ukládání citlivých materiálů pro použití služeb, jako jsou certifikáty, klíče, přihlašovací údaje a hodnoty hash pomocí proprietární technologie Microsoftu. Využité úložiště závisí na službě, operaci, rozsahu tajného kódu (v celém uživateli nebo v rámci tenanta) a dalších požadavcích.
Tato úložiště provozuje skupina zaměřená na zabezpečení prostřednictvím zavedené automatizace a pracovních postupů, včetně žádostí o certifikát, obnovení, odvolání a zničení.
Auditování aktivit souvisí s těmito úložišti, pracovními postupy a procesy a neexistuje žádný trvalý přístup. Access je založený na žádostech a schválení a po omezenou dobu.
Další informace o šifrování neaktivních uložených tajných kódů najdete v následující tabulce.
Algoritmy: Následující tabulka uvádí minimální kryptografické algoritmy používané komponentami Microsoft Entra. Jako cloudová služba Microsoft znovu posuzuje a vylepšuje kryptografii na základě zjištění výzkumu zabezpečení, interních kontrol zabezpečení, klíčové síly proti vývoji hardwaru atd.
| Data nebo scénář | Kryptografický algoritmus |
|---|---|
| Hesla k synchronizaci hodnot hash hesel v cloudovém účtu |
Hash: Funkce odvozování klíče hesla 2 (PBKDF2) pomocí ověřovacího kódu založeného na hodnotě hash (HMAC)-SHA256 @ 1 000 iterací |
| Adresář při přenosu mezi datovými centry | AES-256-CTS-HMAC-SHA1-96 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
| Tok přihlašovacích údajů uživatele předávacího ověřování | Další informace o páru veřejného a privátního klíče RSA 2048: Podrobné informace o zabezpečení předávacího ověřování Microsoft Entra |
| Samoobslužné resetování hesla zpětný zápis hesla pomocí Microsoft Entra Connect: Cloud k místní komunikaci | Pár privátních a veřejných klíčů RSA 2048 AES_GCM (256bitový klíč, 96bitová velikost IV) |
| Samoobslužné resetování hesla: Odpovědi na bezpečnostní otázky | SHA256 |
| Certifikáty SSL pro publikované aplikace Proxy aplikací Microsoft Entra |
256bitová verze AES-GCM |
| Šifrování na úrovni disku | XTS-AES 128 |
| Bezproblémové zřizování přihlašovacích údajů účtu účtu služby jednotného přihlašování (SSO) – software pro zřizování aplikací jako služby (SaaS) |
AES-CBC 128bitová verze |
| Spravované identity pro prostředky Azure | 256bitová verze AES-GCM |
| Aplikace Microsoft Authenticator: Přihlášení bez hesla k Microsoft Entra ID | Asymetrický klíč RSA 2048 bitů |
| Aplikace Microsoft Authenticator: Zálohování a obnovení metadat podnikových účtů | AES-256 |
Zdroje informací
- Dokumenty důvěryhodnosti služeb Microsoftu
- Centrum zabezpečení Microsoft Azure
- Obnovení z odstranění v MICROSOFT Entra ID
Další kroky
- MICROSOFT Entra ID a rezidence dat
- Důležité informace o provozu dat
- Aspekty ochrany dat (tady jste)