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:
  • Alkalmazásvédelem iOS- és Android-szabályzatokat, amelyekkel telefonon titkosíthatja az adatokat, és amelyek jobb védelmet nyújtanak az adatoknak. (Alkalmazásvédelem szabályzatok az alkalmazásvédelmet is tartalmazzák.)
  • Munkamenet-szabályzatok, amelyekben az Azure Information Protection segít az adatok védelmében a letöltés során, ha az adatok bizalmasak.
AppProtection Ez a szabályzattípus az alapvédelem újabb kiegészítése.

Examples:
  • Tegyük fel, hogy bármilyen eszközről engedélyezni szeretné az Exchange Online webes elérését. Kizárhatja az Exchange-t az alapszabályzatból, és létrehozhat egy új explicit szabályzatot az Exchange-hozzáféréshez, ahol például csak olvasási hozzáférést engedélyez az Exchange Online-hoz.
  • Tegyük fel, hogy többtényezős hitelesítésre van szükség a Microsoft Endpoint Manager-regisztrációhoz. Kizárhatja az Intune Endpoint Manager-regisztrációt az alapszabályzatból, és hozzáadhat egy alkalmazásvédelmi szabályzatot, amely többtényezős hitelesítést igényel az Endpoint Manager-regisztrációhoz.
AttackSurfaceReduction Az ilyen típusú szabályzat célja a különböző támadások enyhítése.

Examples:
  • Ha egy hozzáférési kísérlet ismeretlen platformról származik, előfordulhat, hogy megkíséreli megkerülni a feltételes hozzáférési szabályzatokat, amelyekben egy adott platformra van szükség. A kockázat csökkentése érdekében letilthatja az ismeretlen platformoktól érkező kéréseket.
  • Tiltsa le az Office 365-szolgáltatásokhoz való hozzáférést az Azure-Rendszergazda istratorokhoz, vagy tiltsa le az alkalmazáshoz való hozzáférést minden felhasználó számára, ha az alkalmazás ismerten rossz.
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:
  • EXO az Exchange Online-hoz
  • SPO a SharePoint Online-hoz

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.

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:

Diagram that shows a Conditional Access deployment model.

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ő:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

További lépések