Feltételes hozzáférési keretrendszer és szabályzatok
Ez a cikk egy olyan keretrendszert biztosít, amely egy személyalapú feltételes hozzáférési architektúra implementálására szolgál, például a feltételes hozzáférés Teljes felügyelet architektúrájában leírtakhoz. Ebben a cikkben a feltételes hozzáférési szabályzatok létrehozásának és elnevezésének részleteit ismertetjük. A szabályzatok létrehozásának is van kiindulópontja.
Ha nem az itt megadotthoz hasonló keretrendszert használ, beleértve az elnevezési szabványt is, a szabályzatokat általában ad-hoc módon hozzák létre a különböző személyek. Ez olyan szabályzatokat eredményezhet, amelyek átfedésben vannak. Ha a szabályzatot létrehozó személy már nem érhető el, mások nehezen tudják a szabályzat célját.
A strukturált keretrendszerek követése megkönnyíti a szabályzatok megértését. Emellett megkönnyíti az összes forgatókönyv lefedését, és elkerüli a nehezen elhárítható ütköző szabályzatokat.
Elnevezési konvenciók
A megfelelően definiált elnevezési konvenciók segítenek Önnek és munkatársainak megérteni a szabályzat célját, ami megkönnyíti a szabályzatkezelést és a hibaelhárítást. Az elnevezési konvenciónak meg kell felelnie a szabályzatok strukturálásához használt keretrendszernek.
Az ajánlott elnevezési szabályzat személyeken, szabályzattípusokon és alkalmazásokon alapul. Így néz ki:
<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Ennek a névnek az összetevői a következők:
Elnevezési összetevő | Leírás/példa |
---|---|
CA-szám | A szabályzattípus hatókörének és sorrendjének gyors azonosítására szolgál. Példa: CA001-CA099. |
Persona | Globális, Rendszergazda s, Internals, Externals, GuestUsers, Guest Rendszergazda s, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
Házirendtípus | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
App | AllApps, O365 (minden Office 365-szolgáltatáshoz), EXO (Exchange Online-hoz). |
Platform | AnyPlatform, Unknown, Windows Telefon, macOS, iOS, Android. |
Vezérlőelem megadása | Block, ADHJ, Compliant, Unmanaged (ahol nem felügyelt van megadva az eszköz állapotfeltételében). |
Leírás | A szabályzat céljának nem kötelező leírása. |
Számozási séma
Az adminisztráció megkönnyítése érdekében ezt a számozási sémát javasoljuk:
Persona csoport | Számkiosztás |
---|---|
CA-Persona-Global | CA001-CA099 |
CA-Persona-Rendszergazda | CA100-CA199 |
CA-Persona-Internals | CA200-CA299 |
CA-Persona-Externals | CA300-CA399 |
CA-Persona-GuestUsers | CA400-CA499 |
CA-Persona-Guest Rendszergazda s | CA500-CA599 |
CA-Persona-M365ServiceAccounts | CA600-CA699 |
CA-Persona-AzureServiceAccounts | CA700-CA799 |
CA-Persona-CorpServiceAccounts | CA800-CA899 |
CA-Persona-WorkloadIdentities | CA900-CA999 |
CA-Persona-Developers | CA1000-CA1099 |
Irányelvtípusok
Ezek az ajánlott szabályzattípusok:
Házirend típusa | Leírás/példák |
---|---|
BaseProtection | Minden egyes személyhez tartozik egy alapkonfigurációs védelem, amelyet ez a szabályzattípus fed le. A felügyelt eszközökön lévő felhasználók esetében ez általában ismert felhasználó és ismert eszköz. Külső vendégek esetén ismert felhasználó- és többtényezős hitelesítés lehet. Az alapvédelem az adott személyhez tartozó összes alkalmazás alapértelmezett szabályzata. Ha egy adott alkalmazásnak eltérő szabályzattal kell rendelkeznie, zárja ki az alkalmazást az alapvédelmi szabályzatból, és adjon hozzá egy explicit szabályzatot, amely csak az adott alkalmazást célozza. Példa: Tegyük fel, hogy az Internals alapvédelmének az a célja, hogy az összes felhőalkalmazáshoz ismert felhasználót és ismert eszközt igényeljen, de bármely eszközről engedélyezni szeretné Webes Outlook. Kizárhatja az Exchange Online-t az alapvédelmi szabályzatból, és hozzáadhat egy külön házirendet az Exchange Online-hoz, ahol ismert eszköz- vagy többtényezős hitelesítésre van szükség. |
IdentityProtection | Az egyes személyek alapvédelmén felül olyan feltételes hozzáférési szabályzatokkal is rendelkezhet, amelyek identitáshoz kapcsolódnak. Példák: Az örökölt hitelesítés letiltása, extra többtényezős hitelesítés megkövetelése magas felhasználói vagy bejelentkezési kockázat esetén, ismert eszköz megkövetelése a többtényezős hitelesítés regisztrációjához. |
DataProtection | Ez a szabályzattípus olyan delta-szabályzatokat jelöl, amelyek az alapvédelemen felül további rétegként védik az adatokat. Példák:
|
AppProtection | Ez a szabályzattípus az alapvédelem újabb kiegészítése. Examples:
|
AttackSurfaceReduction | Az ilyen típusú szabályzat célja a különböző támadások enyhítése. Examples:
|
Megfelelőség | A megfelelőségi szabályzattal megkövetelheti, hogy a felhasználó megtekintse az ügyfélszolgálathoz hozzáférő vendégek használati feltételeit. |
App
Az alábbi táblázat egy szabályzatnév alkalmazásösszetevőjét ismerteti:
Alkalmazás neve | Leírás/példák |
---|---|
AllApps | Az AllApps azt jelzi, hogy az összes felhőalkalmazás a feltételes hozzáférési szabályzatban van megcélzva. Minden végpont lefedve van, beleértve a feltételes hozzáférést támogató és a nem rendelkező végpontokat is. Bizonyos esetekben az összes alkalmazás megcélzása nem működik megfelelően. Javasoljuk, hogy az alapszabályzatban szereplő összes alkalmazást megcélozza, hogy az összes végpontot lefedje ez a szabályzat. A Microsoft Entra-azonosítóban megjelenő új alkalmazások is automatikusan betartják a szabályzatot. |
<AppName> | <Az AppName> egy olyan alkalmazás nevének helyőrzője, amelyet a házirend címez. Ne tegye túl hosszúra a nevet. Példanevek:
|
Platform típusa
Az alábbi táblázat egy szabályzatnév platformösszetevőjét ismerteti:
Platform típusa | Leírás |
---|---|
AnyPlatform | A szabályzat bármilyen platformot céloz meg. Ezt általában a Bármely eszköz kiválasztásával konfigurálhatja. (A feltételes hozzáférési szabályzatokban a rendszer a szóplatformot és az eszköz szót is használja.) |
iOS | A szabályzat az Apple iOS-platformokat célozza meg. |
Android | A szabályzat a Google Android-platformokat célozza meg. |
Ablakok | Ez a szabályzat a Windows platformot célozza meg. |
Linux | Ez a szabályzat a Linux-platformokat célozza meg. |
Windows Telefon | A szabályzat Windows Phone-telefon platformokat céloz meg. |
macOS | A szabályzat a macOS-platformokat célozza meg |
iOSAndroid | A szabályzat iOS- és Android-platformokat is céloz meg. |
Unknown | A szabályzat a korábban nem felsorolt platformokat célozza meg. Ezt általában úgy konfigurálja, hogy az összes eszközt beleszámítva kizárja az összes platformot. |
Vezérlőelem-típusok megadása
Az alábbi táblázat egy szabályzatnév Engedélyezési vezérlő összetevőjét ismerteti:
Megadás típusa | Leírás/példák |
---|---|
Block | A szabályzat letiltja a bejelentkezést |
MFA | A szabályzathoz többtényezős hitelesítés szükséges. |
Megfelelő | A szabályzathoz az Endpoint Manager által meghatározott megfelelő eszköz szükséges, ezért az eszközt az Endpoint Managernek kell felügyelnie. |
CompliantorAADHJ | A szabályzathoz megfelelő eszközre vagy Microsoft Entra hibrid csatlakoztatott eszközre van szükség. A tartományhoz csatlakoztatott szabványos vállalati számítógép hibrid Microsoft Entra-azonosítóval is rendelkezik. A közösen felügyelt vagy a Microsoft Entra-hoz csatlakoztatott mobiltelefonok és Windows 10-számítógépek megfelelőek lehetnek. |
MegfelelőandAADHJ | A szabályzathoz olyan eszközre van szükség, amely megfelel a microsoft Entra hibrid csatlakoztatásának. |
MFAorCompliant | A szabályzat megfelelő eszköz- vagy többtényezős hitelesítést igényel, ha az nem megfelelő. |
MFAandCompliant | A szabályzathoz megfelelő eszköz- és többtényezős hitelesítés szükséges. |
MFAorAADHJ | A szabályzathoz microsoft Entra hibrid csatlakoztatott számítógép vagy többtényezős hitelesítés szükséges, ha az nem Microsoft Entra hibrid csatlakoztatott számítógép. |
MFAandAADHJ | A szabályzathoz a Microsoft Entra hibrid csatlakoztatású számítógép és többtényezős hitelesítés szükséges. |
RequireApprovedClient | A szabályzathoz jóváhagyott ügyfélalkalmazás szükséges. |
AppProtection | A szabályzat alkalmazásvédelmet igényel |
Nem felügyelt | A szabályzat a Microsoft Entra ID által nem ismert eszközöket célozza meg. Ezzel a támogatási típussal például bármely eszközről engedélyezheti az Exchange Online-hoz való hozzáférést. |
Named locations
Javasoljuk, hogy a feltételes hozzáférési szabályzatokban való használatra ezeket a szabványos helyeket határozza meg:
- Megbízható IP-címek/ belső hálózatok. Ezek az IP-alhálózatok olyan helyeket és hálózatokat jelölnek, amelyek fizikai hozzáférésre vonatkozó korlátozásokkal vagy egyéb vezérlőkkel rendelkeznek, például számítógéprendszer-kezelés, hálózati szintű hitelesítés vagy behatolásészlelés. Ezek a helyek biztonságosabbak, így a feltételes hozzáférés kényszerítése enyhíthető. Fontolja meg, hogy az Azure-nak vagy más adatközponti helyeknek (IP-címeknek) szerepelniük kell-e ezen a helyen, vagy saját nevesített helyekkel kell rendelkezniük.
- Citrix-megbízható IP-címek. Ha a Citrix helyszíni, érdemes lehet külön kimenő IPv4-címeket konfigurálni a Citrix-farmokhoz, ha a Citrix-munkamenetek felhőszolgáltatásaihoz kell csatlakoznia. Ebben az esetben szükség esetén kizárhatja ezeket a helyeket a feltételes hozzáférési szabályzatokból.
- Zscaler-helyek, ha vannak. A számítógépeken telepítve van egy ZPA-ügynök, és minden forgalmat továbbít az internetre a Zscaler-felhőbe vagy azon keresztül. Ezért érdemes meghatározni a Zscaler-forrás IP-címeket a feltételes hozzáférésben, és megkövetelni, hogy a nem mobileszközökről érkező összes kérés áthaladjon a Zscaleren.
- Azokat az országokat/régiókat, amelyek lehetővé teszik az üzletmenetet. Hasznos lehet két helycsoportra osztani az országokat/régiókat: az egyik a világ azon területeit jelöli, ahol az alkalmazottak általában dolgoznak, a másik pedig más helyeket jelöl. Ez lehetővé teszi, hogy további vezérlőket alkalmazzon azokra a kérelmekre, amelyek a szervezet szokásos működési területén kívülről származnak.
- Olyan helyek, ahol a többtényezős hitelesítés nehéz vagy lehetetlen lehet. Bizonyos esetekben a többtényezős hitelesítés megkövetelése megnehezítheti az alkalmazottak munkáját. Előfordulhat például, hogy a személyzetnek nincs ideje vagy lehetősége válaszolni a gyakori többtényezős hitelesítéssel kapcsolatos kihívásokra. Vagy egyes helyeken az RF szűrés vagy az elektromos interferencia megnehezítheti a mobileszközök használatát. Általában más vezérlőket használ ezeken a helyeken, vagy ezek megbízhatóak lehetnek.
A helyalapú hozzáférés-vezérlők a kérés forrás IP-címére támaszkodva határozzák meg a felhasználó helyét a kérés időpontjában. Nem könnyű hamisítást végezni a nyilvános interneten, de a hálózati határok által biztosított védelem kevésbé releváns, mint egykor volt. Nem javasoljuk, hogy kizárólag a helyre támaszkodjon a hozzáférés feltételeként. Bizonyos forgatókönyvek esetében azonban ez lehet a legjobban használható vezérlő, például ha egy nem interaktív forgatókönyvben használt helyszíni szolgáltatásfiókból biztosít hozzáférést.
Javasolt feltételes hozzáférési szabályzatok
Létrehoztunk egy táblázatot, amely az ajánlott feltételes hozzáférési szabályzatokat tartalmazza. A számolótáblát itt töltheti le.
Használja a javasolt szabályzatokat kiindulási pontként.
A szabályzatok valószínűleg idővel megváltoznak, hogy alkalmazkodjanak a vállalkozása számára fontos használati esetekhez. Íme néhány példa azokra a forgatókönyvekre, amelyek módosításokat igényelhetnek:
- Csak olvasási hozzáférést valósíthat meg az Exchange Online-hoz az alkalmazottak számára a többtényezős hitelesítésen, az alkalmazásvédelemen és egy jóváhagyott ügyfélalkalmazáson alapuló nem felügyelt eszközök használatával.
- Az adatvédelmet úgy valósíthatja meg, hogy a bizalmas információk ne töltődjenek le az Azure Information Protection által biztosított fokozott védelem nélkül.
- Védelem biztosítása a vendégek másolása és beillesztése ellen.
Jelenleg több előzetes verzió is nyilvános előzetes verzióban érhető el, ezért a feltételes hozzáférési (CA) kezdőszabályzatok javasolt készletének frissítésére számíthat hamarosan.
Útmutató a feltételes hozzáféréshez
Most, hogy már rendelkezik feltételes hozzáférési szabályzatok kezdőkészletével, szabályozott és szakaszos módon kell üzembe helyeznie őket. Javasoljuk, hogy használjon üzembehelyezési modellt.
Íme egy megközelítés:
Az ötlet az, hogy először üzembe kell helyezni a szabályzatokat egy személycsoporton belüli kis számú felhasználóra. Ehhez az üzembe helyezéshez használhat egy Persona Ring 0 nevű Társított Microsoft Entra-csoportot. Miután ellenőrizte, hogy minden működik-e, módosítja a feladatot egy csoportra( Persona Ring 1), amelynek több tagja van, és így tovább.
Ezt követően a szabályzatokat ugyanazzal a köralapú megközelítéssel engedélyezheti, amíg az összes házirend üzembe nem kerül.
Általában manuálisan kezeli a 0. és az 1. gyűrű tagjait. Egy több száz vagy akár több ezer felhasználót tartalmazó 2. vagy 3. körcsoport egy dinamikus csoporttal kezelhető, amely egy adott személy felhasználóinak százalékos arányán alapul.
A gyűrűk üzembehelyezési modell részeként való használata nem csak a kezdeti üzembe helyezéshez szükséges. Akkor is használhatja, ha új szabályzatok vagy meglévő szabályzatok módosítása szükséges.
Az üzembe helyezés befejeztével a feltételes hozzáférés alapelveiben tárgyalt monitorozási vezérlőket is megtervezheti és implementálhatja.
A kezdeti üzembe helyezés automatizálása mellett ci/CD-folyamatokkal is automatizálhatja a házirendek módosítását. Ehhez az automatizáláshoz használhatja a Microsoft365DSC-t.
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerző:
- Claus Jespersen | Főtanácsadó azonosítója
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
További lépések
- Tanulás elérési út: Identitás és hozzáférés megvalósítása és kezelése
- Feltételes hozzáférési szabályzatok
Kapcsolódó erőforrások
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: