Identitásra és azon túl – Egy építész nézőpontja

  • Cikk

Ebben a cikkben Alex Shteynberg, a Microsoft vezető műszaki tervezője ismerteti a Microsoft 365-öt és más Microsoft-felhőszolgáltatásokat alkalmazó nagyvállalati szervezetek legfontosabb tervezési stratégiáit.

A szerzőről

Alex Shteynberg fényképe.

Műszaki vezető tervező vagyok a New York-i Microsoft Technológiai Központban. Többnyire nagy ügyfelekkel és összetett követelményekkel dolgozom. Az én álláspontom és a vélemények ezeken az interakciókon alapulnak, és nem feltétlenül vonatkoznak minden helyzetre. Tapasztalataim szerint azonban, ha segíthetünk az ügyfeleknek a legösszetettebb kihívásokkal kapcsolatban, minden ügyfélnek tudunk segíteni.

Általában évente több mint 100 ügyféllel dolgozom. Bár minden szervezet egyedi jellemzőkkel rendelkezik, érdekes látni a trendeket és a gyakoriságokat. Az egyik trend például az iparágközi érdeklődés sok ügyfél számára. Elvégre a bankfiók is lehet kávézó és közösségi központ.

Az én szerepkörömben arra összpontosítok, hogy segítsem az ügyfeleket abban, hogy a legjobb műszaki megoldáshoz jussanak el az egyedi üzleti céljaik elérése érdekében. Hivatalosan az identitásra, a biztonságra, az adatvédelemre és a megfelelőségre összpontosítok. Imádom, hogy ezek mindent érintenek, amit csinálunk. Ez lehetőséget ad arra, hogy részt vegyek a legtöbb projektben. Ez a tevékenység lefoglal és élvezi ezt a szerepkört.

Élek New York City (a legjobb!), és nagyon élvezem a sokszínűség a kultúra, az élelmiszer, és az emberek (nem a forgalom). Szeretek utazni, amikor csak lehet, és remélem, hogy a világ nagy része az életemben. Jelenleg egy afrikai utat kutatok, hogy megismerhessem a vadvilágot.

Alapelvek

  • Az egyszerűség gyakran jobb: A technológiával bármit megtehet (szinte), de ez nem jelenti azt, hogy önnek kellene. Különösen a biztonsági területen, sok ügyfél túlterjeszkedő megoldásokat. Tetszik ez a videó a Google Stripe konferencia aláhúzni ezt a pontot.
  • Kapcsolatok, folyamat, technológia: Tervezés az emberek számára, hogy javítják a folyamatot, nem pedig a tech előbb. Nincsenek "tökéletes" megoldások. Ki kell egyensúlyozni a különböző kockázati tényezőket és döntéseket, amelyek az egyes vállalatoknál eltérőek lehetnek. Túl sok ügyfél tervez olyan megközelítést, amelyet a felhasználók később elkerülnek.
  • Összpontosítson a "miért" első és a "hogyan" később: Legyen az idegesítő 7-yr öreg gyerek egy millió kérdés. Nem tudjuk a megfelelő választ kapni, ha nem tudjuk a megfelelő kérdéseket feltenni. Sok ügyfél feltételezi, hogy hogyan kell működnie a dolgoknak az üzleti probléma meghatározása helyett. Mindig több elérési út is megadható.
  • A múltbeli ajánlott eljárások hosszú farka: Ismerje fel, hogy az ajánlott eljárások fénysebességen változnak. Ha több mint három hónappal ezelőtt megnézte Microsoft Entra, valószínűleg elavult. Itt minden változhat a közzététel után. Lehet, hogy a "legjobb" lehetőség ma nem ugyanaz a hat hónap múlva.

Alapfogalmak

Ne hagyja ki ezt a szakaszt. Gyakran tapasztalom, hogy vissza kell lépnem ezekre a cikkekre, még azoknak az ügyfeleknek is, akik már évek óta használnak felhőszolgáltatásokat. Sajnos a nyelv nem egy pontos eszköz. Gyakran ugyanazt a szót használjuk különböző fogalmak vagy különböző szavak kifejezésére, hogy ugyanazt a fogalmat értsük. Gyakran használom az alábbi diagramot alapszintű terminológia és "hierarchiamodell" kialakításához.

A bérlő, az előfizetés, a szolgáltatás és az adatok ábrája.

Ha megtanul úszni, jobb, ha a medencében kezdődik, és nem az óceán közepén. Nem akarok technikailag pontos lenni ezzel a diagrammal. Ez egy modell, amely néhány alapfogalmat tárgyal.

A diagramon:

  • Tenant = a Microsoft Entra ID egy példánya. A hierarchia "tetején" vagy a diagram 1. szintjén található. Ezt a szintet "határnak" tekinthetjük, ahol minden más történik (Microsoft Entra B2B félre). A Microsoft nagyvállalati felhőszolgáltatásai ezen bérlők egyikének részét képezik. A fogyasztói szolgáltatások különállóak. A "Bérlő" a dokumentációban Microsoft 365-bérlőként, Azure-bérlőként, WVD-bérlőként stb. jelenik meg. Gyakran tapasztalom, hogy ezek a változatok zavart okoznak az ügyfelek számára.
  • A diagram 2. szintű szolgáltatásai/előfizetései egy és csak egy bérlőhöz tartoznak. A legtöbb SaaS-szolgáltatás 1:1-et használ, és migrálás nélkül nem tud mozogni. Az Azure eltérő, a számlázást és/vagy az előfizetést áthelyezheti egy másik bérlőre. Számos ügyfélnek át kell helyeznie az Azure-előfizetéseket. Ez a forgatókönyv különböző következményekkel jár. Az előfizetésen kívül található objektumok nem lesznek áthelyezve. Például szerepköralapú hozzáférés-vezérlés (Azure RBAC), Microsoft Entra objektumok (csoportok, alkalmazások, szabályzatok stb.) és egyes szolgáltatások (Azure Key Vault, Data Bricks stb.). Ne telepítse át a szolgáltatásokat megfelelő üzleti igény nélkül. A migráláshoz hasznos szkriptek némelyike meg van osztva a GitHubon.
  • Egy adott szolgáltatás általában valamilyen "alszintű" határt vagy 3. szintet (L3) jelöl. Ez a határ a biztonság, a szabályzatok, a szabályozás stb. elkülönítése szempontjából hasznos. Sajnos nincs egységes név, amellyel én is tudok. Néhány példa az L3-ra: Azure-előfizetés = erőforrás; Dynamics 365 CE = példány; Power BI = munkaterület; Power Apps = környezet; és így tovább.
  • A 4. szint a tényleges adatok helye. Ez az "adatsík" egy összetett cikk. Egyes szolgáltatások Microsoft Entra ID használnak az RBAC-hez, mások nem. A delegálással kapcsolatos cikkeket egy kicsit megvitatom.

Néhány más fogalom, amelyet sok ügyfélnek (és a Microsoft-alkalmazottaknak) találok, összekeverednek, vagy kérdéseik vannak a következő problémákkal kapcsolatban:

  • Bárki létrehozhat számos bérlőt díjmentesen. Nincs szükség benne kiépített szolgáltatásra. Több tucat van. Minden bérlőnév egyedi a Microsoft globális felhőszolgáltatásában (vagyis egyetlen bérlőnek sem lehet ugyanaz a neve). Mindegyik TenantName.onmicrosoft.com formátumban van. Vannak olyan folyamatok is, amelyek automatikusan létrehozzák a bérlőket (nem felügyelt bérlők). Ez az eredmény például akkor fordulhat elő, ha egy felhasználó olyan e-mail-tartománnyal regisztrál egy vállalati szolgáltatásra, amely nem létezik egyetlen másik bérlőben sem.
  • Egy felügyelt bérlőben számos DNS-tartomány regisztrálható benne. Ez az eredmény nem módosítja az eredeti bérlő nevét. A bérlők átnevezése jelenleg nem egyszerű (a migráláson kívül). Bár a bérlő neve manapság technikailag nem kritikus fontosságú, előfordulhat, hogy egyes felhasználók számára korlátozott ez a valóság.
  • A bérlő nevét akkor is érdemes lefoglalnia a szervezet számára, ha még nem tervezi a szolgáltatások üzembe helyezését. Ellenkező esetben valaki el tudja venni Öntől, és nincs egyszerű folyamat a visszavételére (ugyanaz a probléma, mint a DNS-nevek). Túl gyakran hallom ezt az utat az ügyfelektől. A bérlő nevének egy vitacikknek is meg kell lennie.
  • Ha ön a DNS-névtér tulajdonosa, vegye fel ezeket a névtereket a bérlői fiókba. Ellenkező esetben létrehozhat egy nem felügyelt bérlőt ezzel a névvel, ami fennakadást okoz a felügyeletében.
  • Egy DNS-névtér (például contoso.com) egy és csak egy bérlőhöz tartozhat. Ez a követelmény hatással van a különböző forgatókönyvekre (például egy e-mail-tartomány egyesítés vagy felvásárlás során történő megosztására stb.). A DNS-alhálózatok (például div.contoso.com) regisztrálhatók egy másik bérlőben, de ezt el kell kerülni. A legfelső szintű tartománynév regisztrálásával a rendszer feltételezi, hogy minden altartomány ugyanahhoz a bérlőhöz tartozik. Több-bérlős forgatókönyvekben (a következő magyarázat szerint) általában egy másik legfelső szintű tartománynevet (például contoso.ch vagy ch-contoso.com) javasolnék.
  • Kinek kell "birtokolnia" egy bérlőt? Gyakran látok olyan ügyfeleket, akik nem tudják, hogy jelenleg ki a bérlőjük. Ez a tudáshiány jelentős piros zászló. Hívja fel a Microsoft ügyfélszolgálatát. Ugyanolyan problémás, ha egy bérlő kezelésére szolgáltatástulajdonost (gyakran Exchange-rendszergazdát) jelölnek ki. A bérlő az összes olyan szolgáltatást tartalmazza, amelyet a jövőben esetleg használni szeretne. A bérlő tulajdonosának olyan csoportnak kell lennie, amely eldöntheti, hogy engedélyezi-e a szervezet összes felhőszolgáltatását. Egy másik probléma az, amikor egy bérlőtulajdonosi csoportot kérnek fel az összes szolgáltatás kezelésére. Ez a módszer nem méretezhető nagy szervezetek számára.
  • Az al-/szuperbérlők fogalma nem létezik. Valamilyen okból ez a mítosz folyamatosan ismétli önmagát. Ez a fogalom az Azure Active Directory B2C-bérlőkre is vonatkozik. Túl sokszor hallom a következőt: "A B2C-környezet az XYZ-bérlőmben van", vagy "Hogyan áthelyezni az Azure-bérlőmet a Microsoft 365-bérlőmbe?"
  • Ez a dokumentum elsősorban a kereskedelmi célú globális felhővel foglalkozik, mivel a legtöbb ügyfél ezt használja. Néha hasznos lehet megismerni a szuverén felhőket. A szuverén felhők más következményekkel is járnak, hogy megvitassák, melyek nem tartoznak a vita tárgyát képező kérdések közé.

Alapkonfigurációs identitással kapcsolatos cikkek

A Microsoft identitásplatformjáról számos dokumentáció áll rendelkezésre – Microsoft Entra ID. Azoknak, akik csak most kezdik, gyakran nyomasztónak érzi magát. A folyamatos innováció és változás fenntartása még a megismerése után is kihívást jelenthet. Az ügyfelek közötti interakciók során gyakran "fordítóként" szolgálok az üzleti célok és a "Jó, jobb, legjobb" megközelítések között ezeknek az aggodalmaknak a kezelésére (és az emberi "sziklajegyzetek" ezekhez a cikkekhez). Ritkán van tökéletes válasz, és a "helyes" döntés a különböző kockázati tényezők egyensúlya. A következőkben néhány gyakori kérdést és zavarral kapcsolatos területet ismertetem az ügyfelekkel.

Kiépítés

Microsoft Entra ID nem oldja meg az identitás világában a szabályozás hiányát! Az identitáskezelésnek kritikus fontosságú elemnek kell lennie, függetlenül a felhővel kapcsolatos döntésekétől. A szabályozási követelmények idővel változnak, ezért nem eszköz, hanem program.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) vs. valami más (külső vagy egyéni)? Mentse a problémákat most és a jövőben, és lépjen a Microsoft Entra Connecthez. Ebben az eszközben mindenféle intelligens megoldás létezik a sajátos ügyfélkonfigurációk és a folyamatban lévő innovációk kezelésére.

Néhány peremhálózati eset, amely egy összetettebb architektúra felé vezethet:

  • Több AD-erdőm van közöttük hálózati kapcsolat nélkül. Van egy új lehetőség , a Cloud Provisioning.
  • Nem rendelkezem Active Directoryval, és nem is szeretném telepíteni. Microsoft Entra Connect konfigurálható az LDAP-ból történő szinkronizálásra (előfordulhat, hogy partnerre van szükség).
  • Ugyanazokat az objektumokat több bérlő számára kell kiépíteni. Ez a forgatókönyv technikailag nem támogatott, de az "azonos" definíciójától függ.

Testre szabhatom az alapértelmezett szinkronizálási szabályokat (objektumok szűrése, attribútumok módosítása, másodlagos bejelentkezési azonosító stb.)? Kerülje el! Az identitásplatformok csak annyira értékesek, mint az azt használó szolgáltatások. Bár mindenféle őrült konfigurációt elvégezhet, a kérdés megválaszolásához meg kell vizsgálnia az alkalmazásokra gyakorolt hatást. Ha a levelezési objektumokat szűri, akkor a online szolgáltatások GAL-címe hiányos; ha az alkalmazás adott attribútumokra támaszkodik, az attribútumokra való szűrésnek kiszámíthatatlan hatása van, és így tovább. Ez nem egy identitáskezelési csapat döntése.

Az XYZ SaaS támogatja az igény szerinti (JIT) kiépítést. Miért van szükség szinkronizálásra? Lásd az előző bekezdést. Számos alkalmazásnak "profil" információra van szüksége a funkciókhoz. Nem rendelkezhet globális címjegyzékvel, ha az összes levelezési objektum nem érhető el. Ugyanez vonatkozik a Microsoft Entra ID integrált alkalmazásokban történő felhasználóátadásra is.

Hitelesítés

Jelszókivonat-szinkronizálás (PHS) és átmenő hitelesítés (PTA) és összevonás.

Általában szenvedélyes vita folyik a szövetségről. Egyszerűbb általában jobb, és ezért használja PHS, ha van egy jó oka, hogy ne. Különböző hitelesítési módszereket is konfigurálhat ugyanazon bérlő különböző DNS-tartományaihoz.

Egyes ügyfelek elsősorban a következő célokra engedélyezik az összevonást és a PHS-t:

Gyakran végigvezetem az ügyfeleket az ügyfél-hitelesítési folyamaton, hogy tisztázzak néhány tévhitet. Az eredmény az alábbi képhez hasonlóan néz ki, amely nem olyan jó, mint az interaktív odajutás folyamata.

Példa rajztáblás beszélgetésre.

Ez a rajztábla-rajztípus bemutatja, hogy a rendszer hol alkalmazza a biztonsági szabályzatokat a hitelesítési kérések folyamatán belül. Ebben a példában az Active Directory összevonási szolgáltatáson (AD FS) keresztül kényszerített szabályzatok az első szolgáltatáskérésre lesznek alkalmazva, a későbbi szolgáltatáskérésekre azonban nem. Ez a viselkedés legalább egy ok arra, hogy a biztonsági vezérlőket a lehető legnagyobb mértékben a felhőbe helyezze át.

Már üldözi az álmát egyszeri bejelentkezés (SSO) mindaddig, amíg emlékszem. Egyes ügyfelek úgy vélik, hogy a "megfelelő" összevonási (STS) szolgáltató kiválasztásával érhetik el az egyszeri bejelentkezést. Microsoft Entra ID jelentősen segíthet az egyszeri bejelentkezési képességek engedélyezésében, de az STS nem varázslatos. Túl sok "örökölt" hitelesítési módszer van még használatban a kritikus alkalmazásokhoz. A Microsoft Entra ID partnermegoldásokkal való kiterjesztése számos ilyen forgatókönyvet képes kezelni. Az egyszeri bejelentkezés egy stratégia és egy folyamat. Nem érheti el anélkül, hogy az alkalmazásokra vonatkozó szabványokra lépne. Ehhez a cikkhez kapcsolódik a jelszó nélküli hitelesítés folyamata, amely szintén nem rendelkezik varázslatos választ.

A többtényezős hitelesítés (MFA) ma nélkülözhetetlen (itt továbbiakért). Adjon hozzá felhasználói viselkedéselemzést , és van egy megoldása, amely megakadályozza a leggyakoribb kibertámadásokat. Még a fogyasztói szolgáltatások is áttérnek az MFA megkövetelésére. Mégis sok olyan ügyféllel találkozom, akik nem szeretnének modern hitelesítési módszerekre váltani. A legnagyobb érv, amit hallottam, hogy hatással van a felhasználókra és a régi alkalmazásokra. Néha egy jó rúgás segíthet az ügyfeleknek a mozgásban – Exchange Online bejelentett változások. Számos Microsoft Entra jelentés érhető el, amelyek segítenek az ügyfeleknek az átállásban.

Engedélyezési

A Wikipédiánként az "engedélyezés" egy hozzáférési szabályzat definiálása. Sokan úgy tekintenek rá, mint egy objektum (fájl, szolgáltatás stb.) hozzáférési vezérlőinek meghatározására. A kiberfenyegetések jelenlegi világában ez a koncepció gyorsan fejlődik egy dinamikus politikával, amely reagálhat a különböző fenyegetésvektorokra, és gyorsan módosíthatja a hozzáférés-vezérlést azokra reagálva. Ha például szokatlan helyről férek hozzá a bankszámlámhoz, további megerősítési lépéseket kapok. Ahhoz, hogy ezt a valóságot megközelítsük, nem csak magát a politikát kell figyelembe vennünk, hanem a fenyegetésészlelési és jel-korrelációs módszerek ökoszisztémáját is.

A Microsoft Entra ID házirendmotorja feltételes hozzáférési szabályzatokkal van implementálva. Ez a rendszer más fenyegetésészlelési rendszerektől származó információktól függ, hogy dinamikus döntéseket hozhassanak. Egy egyszerű nézet az alábbi ábrához hasonló:

Szabályzatmotor a Microsoft Entra ID.

Az összes jel kombinálása lehetővé teszi az alábbihoz hasonló dinamikus szabályzatok használatát:

  • Ha fenyegetést észlel az eszközön, az adatokhoz való hozzáférése csak a letöltési képesség nélkül lesz elérhető a weben.
  • Ha szokatlanul nagy mennyiségű adatot tölt le, a letöltött adatok titkosítottak és korlátozottak lesznek.
  • Ha nem felügyelt eszközről fér hozzá egy szolgáltatáshoz, a rendszer letiltja a szigorúan bizalmas adatok használatát, de nem korlátozott adatokhoz férhet hozzá anélkül, hogy máshová másolná azokat.

Ha egyetért ezzel a kibővített engedélyezési definícióval, további megoldásokat kell implementálnia. A implementálandó megoldások attól függenek, hogy milyen dinamikus legyen a szabályzat, és milyen fenyegetéseket szeretne rangsorolni. Néhány példa az ilyen rendszerekre:

A Microsoft Entra ID mellett a különböző szolgáltatások és alkalmazások saját egyedi engedélyezési modellekkel is rendelkeznek. E modellek némelyikét a delegálás szakasz későbbi részében tárgyaljuk.

Ellenőrzési

Microsoft Entra ID részletes naplózási és jelentéskészítési képességekkel rendelkezik. Ezek a jelentések azonban általában nem az egyetlen információforrás, amely a biztonsági döntések meghozatalához szükséges. Erről a témáról a delegálási szakaszban talál további információt.

Nincs Exchange

Ne pánikoljanak! Az Exchange nem elavult (vagy a SharePoint stb.). Ez még mindig egy alapvető szolgáltatás. Úgy értem, hogy a technológiai szolgáltatók már jó ideje átállnak a felhasználói élményre (UX), hogy több szolgáltatás összetevőit is magukban foglalják. A Microsoft 365-ben egy egyszerű példa a "modern mellékletek", ahol az e-mailek mellékletei a SharePoint Online-ban vagy a OneDrive-on vannak tárolva.

Fájl csatolása e-mailhez.

Az Outlook-ügyfélre tekintve számos olyan szolgáltatást láthat, amely "csatlakoztatva" van ennek a felületnek a részeként, nem csak az Exchange-et. Ilyenek például a Microsoft Entra ID, a Microsoft Search, az Alkalmazások, a Profil, a Megfelelőség és a Microsoft 365-csoportok.

Outlook-felület ábrafeliratokkal.

További információ a Microsoft dinamikus keretrendszer a közelgő képességek előzetes verziójáról. Az előzetes verzióban közvetlenül az Outlookban olvashatom és válaszolhatom meg a Teams-beszélgetéseket. Valójában a Teams-ügyfél az egyik legkiválóbb példa erre a stratégiára.

Összességében egyre nehezebb egyértelmű vonalat rajzolni a Microsoft 365 és a Microsoft-felhők más szolgáltatásai között. Úgy vélem, hogy ez egy nagy előny az ügyfelek számára, mivel ők is élvezhetik a teljes innováció minden csinálunk, még akkor is, ha használnak egy összetevőt. Nagyon jó, és messzemenő következményekkel jár sok ügyfél számára.

Ma azt tapasztalom, hogy sok ügyfél informatikai csoportja "termékek" köré van strukturálva. Ez logikus egy helyszíni világ számára, mivel minden egyes termékhez szakértőre van szükség. Örülök azonban, hogy nem kell újra hibakeresést végezni egy Active Directory- vagy Exchange-adatbázison, mivel ezek a szolgáltatások átkerültek a felhőbe. Az automatizálás (amely alapvetően a felhő) eltávolít bizonyos ismétlődő manuális feladatokat (nézze meg, mi történt a gyárakban). Ezeket a feladatokat azonban összetettebb követelmények váltják fel a szolgáltatások közötti interakció, a hatás, az üzleti igények stb. megismerése érdekében. Ha hajlandó tanulni, a felhőátalakítás számos nagyszerű lehetőséget kínál. Mielőtt belevágnék a technológiába, gyakran beszélek az ügyfelekkel az informatikai készségek és a csapatstruktúrák változásának kezeléséről.

A SharePoint minden rajongója és fejlesztője számára ne tegye fel a következő kérdést: "Hogyan végezhetem el az XYZ-t a SharePoint Online-ban?" A Power Automate (vagy Flow) használata munkafolyamatokhoz, sokkal hatékonyabb platform. Az Azure Bot Framework használatával jobb felhasználói felület hozható létre az 500 K-os elemek listájához. Kezdje el használni a Microsoft Graphot a CSOM helyett. A Microsoft Teams tartalmazza a SharePointot, de a világot is. Sok más példát is felsorolhatok. Egy hatalmas és csodálatos univerzum van odakint. Nyissa ki az ajtót, és kezdjen el felfedezni.

A másik gyakori hatás a megfelelőségi területen van. Úgy tűnik, hogy ez a szolgáltatások közötti megközelítés teljesen összezavar sok megfelelőségi szabályzatot. Folyton olyan szervezeteket látok, amelyek a "Minden e-mail-kommunikációt naplóznom kell egy elektronikus adatfeltárási rendszerbe". Mit jelent ez az állítás, ha az e-mail már nem csak e-mail, hanem egy ablak más szolgáltatások? A Microsoft 365 átfogó megfelelőségi megközelítéssel rendelkezik, de a személyek és folyamatok módosítása gyakran sokkal nehezebb, mint a technológia.

Sok más személy és a folyamat következményei. Véleményem szerint ez a tényező kritikus és megvitatatlan terület. Talán többet egy másik cikkben.

Bérlőstruktúra-beállítások

Egybérlős és több-bérlős

Általánosságban elmondható, hogy a legtöbb ügyfélnek csak egy éles bérlője lehet. Számos oka lehet annak, hogy több bérlő is kihívást jelent ( Bing-keresést kell keresnie), vagy elolvashatja ezt a tanulmányt. Ugyanakkor számos nagyvállalati ügyfél, akivel együtt dolgozom, egy másik (kicsi) bérlővel rendelkezik az informatikai tanuláshoz, teszteléshez és kísérletezéshez. Az Azure Lighthouse megkönnyíti a bérlők közötti Azure-hozzáférést. A Microsoft 365 és számos más SaaS-szolgáltatás korlátozza a bérlők közötti forgatókönyveket. A Microsoft Entra B2B-forgatókönyvekben sok szempontot figyelembe kell venni.

Sok ügyfél több termelési bérlővel rendelkezik egy fúzió és felvásárlás (M&A) után, és konszolidálni szeretne. Ez ma nem egyszerű, és a Microsoft Consulting Servicest (MCS) vagy egy partnert és egy külső szoftvert igényelne. A jövőben folyamatosan dolgozunk a több-bérlős ügyfelek különböző forgatókönyveinek megoldásán.

Egyes ügyfelek egynél több bérlőt választanak. Ez legyen egy gondos döntés, és szinte mindig üzleti ok vezérelt! Néhány példa a következő okokra:

  • Egy holding típusú vállalati struktúra, ahol nincs szükség egyszerű együttműködésre a különböző entitások között, és erős adminisztratív és egyéb elkülönítési igények vannak.
  • Az akvizíciót követően üzleti döntés születik két entitás elkülönítése érdekében.
  • Az ügyfél környezetének szimulációja, amely nem módosítja az ügyfél éles környezetét.
  • Szoftverek fejlesztése az ügyfelek számára.

Ezekben a több-bérlős forgatókönyvekben az ügyfelek gyakran meg szeretnék tartani bizonyos konfigurációkat a bérlők között, vagy jelentést szeretnének készíteni a konfiguráció változásairól és eltéréseiről. Ez gyakran azt jelenti, hogy a manuális módosításokról a konfigurációra kódként kell áttérni. A Microsoft Premiere támogatása workshopot kínál az ilyen típusú követelményekhez ezen nyilvános IP-cím alapján: https://Microsoft365dsc.com.

Multi-Geo

Multi-Geo vagy nem Multi-Geo. Ez a kérdés. A Microsoft 365 Multi-Geo segítségével inaktív adatokat építhet ki és tárolhat az adattárolási követelményeknek megfelelő földrajzi helyeken. Ezzel a funkcióval kapcsolatban számos tévhit van. Tartsa szem előtt a következő szempontokat:

  • Nem nyújt teljesítménybeli előnyöket. Ronthatja a teljesítményt, ha a hálózat kialakítása nem megfelelő. Az eszközök "közel" lesznek a Microsoft-hálózathoz, nem feltétlenül az adatokhoz.
  • Ez nem megoldás a GDPR-megfelelőségre. A GDPR nem az adatok szuverenitására vagy a tárolási helyekre összpontosít. Más megfelelőségi keretrendszerek is léteznek az adatok szuverenitásához vagy a tárolási helyekhez.
  • Nem oldja meg a felügyelet delegálását (lásd alább) vagy az információs akadályokat.
  • Ez nem ugyanaz, mint a több-bérlős, és több felhasználóátadási munkafolyamatot igényel.
  • Nem helyezi át a bérlőt (a Microsoft Entra ID) egy másik földrajzi régióba.

Felügyelet delegálása

A legtöbb nagy szervezet esetében a feladatok elkülönítése és a szerepköralapú hozzáférés-vezérlés (RBAC) szükséges valóság. Előre bocsánatot kérek. Ez a tevékenység nem olyan egyszerű, mint néhány ügyfél szeretné. Az ügyfél, a jogi, a megfelelőségi és egyéb követelmények eltérőek, és néha ütköznek a világon. Az egyszerűség és a rugalmasság gyakran egymás ellentétes oldalán van. Ne érts félre, jobb munkát végezhetünk ezen a célon. Az idők során jelentős fejlesztések történtek (és lesznek is). Látogasson el a helyi Microsoft Technológiai központba , és dolgozzon ki egy olyan modellt, amely megfelel az üzleti igényeinek, és nem olvassa el a 379 230 dokumentumot! Itt arra koncentrálok, amire gondolsz, és nem arra, hogy miért így van. Jön fel öt különböző területeket tervezni, és néhány gyakori kérdéseket találkozom.

Microsoft Entra ID és Microsoft 365 Felügyeleti központok

A beépített szerepkörök hosszú és egyre bővülő listája van. Az egyes szerepkörök a szerepkörengedélyek listáját alkotják, amelyek egy csoportba rendezve lehetővé teszik bizonyos műveletek végrehajtását. Ezeket az engedélyeket a "Leírás" lapon tekintheti meg az egyes szerepkörökben. Az engedélyek emberibb olvashatóbb verzióját is megtekintheti a Microsoft 365 Felügyeleti központ Centerben. A beépített szerepkörök definíciói nem módosíthatók. Ezeket a szerepköröket általában három kategóriába csoportosítom:

  • globális rendszergazda: Ezt a "minden erős" szerepkört magas szintű védelemmel kell ellátni, ahogyan más rendszerekben tenné. A tipikus javaslatok közé tartozik a következők: nincs állandó hozzárendelés, és Microsoft Entra Privileged Identity Management (PIM) használata; erős hitelesítés stb. Érdekes, hogy ez a szerepkör alapértelmezés szerint nem biztosít hozzáférést mindenhez. Általában zavart tapasztalok a megfelelőségi hozzáféréssel és az Azure-hozzáféréssel kapcsolatban, amelyekről később lesz szó. Ez a szerepkör azonban bármikor hozzárendelhet hozzáférést a bérlő más szolgáltatásaihoz.
  • Adott szolgáltatás-rendszergazdák: Egyes szolgáltatások (Exchange, SharePoint, Power BI stb.) magas szintű felügyeleti szerepköröket használnak Microsoft Entra ID. Ez a viselkedés nem minden szolgáltatásban konzisztens, és a későbbiekben további szolgáltatásspecifikus szerepkörökről lesz szó.
  • Funkcionális: A szerepkörök hosszú (és egyre bővülő) listája az adott műveletekre (vendégmeghívó stb.) összpontosít. Ezek közül a szerepkörök közül rendszeresen több kerül hozzáadásra az ügyféligények alapján.

Nem lehet mindent delegálni (bár a különbség csökken), ami azt jelenti, hogy néha a globális rendszergazdai szerepkört kell használni. A konfigurációt kódként és automatizálásként kell figyelembe venni a szerepkörhöz tartozó személyek helyett.

Megjegyzés: A Microsoft 365 Felügyeleti központ felhasználóbarátabb felülettel rendelkezik, de a Microsoft Entra rendszergazdai felületéhez képest a képességek egy részhalmazával rendelkezik. Mindkét portál ugyanazt a Microsoft Entra szerepkört használja, így a módosítások ugyanazon a helyen történnek. Tipp: Ha identitáskezelésre összpontosító rendszergazdai felhasználói felületet szeretne használni az Azure zsúfoltságának teljes körű kihasználása nélkül, használja a következőt https://aad.portal.azure.com: .

Mi szerepel a névben? Ne tegyen feltételezéseket a szerepkör nevéből. A nyelv nem egy pontos eszköz. A cél az, hogy meghatározza azokat a műveleteket, amelyeket delegálni kell, mielőtt megnézi, milyen szerepkörökre van szükség. Ha felvesz valakit a "Biztonsági olvasó" szerepkörbe, azzal nem mindenben látja a biztonsági beállításokat.

Az egyéni szerepkörök létrehozásának lehetősége gyakori kérdés. Ez a képesség jelenleg Microsoft Entra korlátozott (amint azt később ismertetjük), de idővel egyre több képesség áll rendelkezésre. Úgy gondolom, ezek az egyéni szerepkörök alkalmazható függvények Microsoft Entra ID, és lehet, hogy nem terjed ki "lefelé" a hierarchia modell (ahogy korábban említettük). Amikor a "custom" szóval foglalkozom, általában visszatérek az "egyszerű jobb" szóhoz.

Egy másik gyakori kérdés a szerepkörök hatókörének meghatározása egy címtár egy részhalmazára. Az egyik példa a következőhöz hasonló: "Segélyszolgálati rendszergazda csak az EU felhasználói számára". A felügyeleti egységek ennek a forgatókönyvnek a kezelésére szolgálnak. Ahogy korábban említettük, úgy gondolom, ezek a hatókörök alkalmazhatók a függvények Microsoft Entra ID, és lehet, hogy nem terjed ki a "lefelé". Bizonyos szerepkörök hatókörének nincs értelme (globális rendszergazdák, szolgáltatás-rendszergazdák stb.).

Napjainkban ezek a szerepkörök közvetlen tagságot igényelnek (vagy dinamikus hozzárendelést, ha Microsoft Entra PIM-et használ). Ez azt jelenti, hogy az ügyfeleknek ezeket a szerepköröket közvetlenül a Microsoft Entra ID kell kezelniük, és ezek a szerepkörök nem alapulhatnak biztonságicsoport-tagságon. Nem rajongok azért, hogy szkripteket hozzak létre ezeknek a szerepköröknek a kezeléséhez, mivel emelt szintű jogosultságokkal kellene futniuk. Általában olyan folyamatrendszerekkel való API-integrációt ajánlok, mint a ServiceNow, vagy olyan partnerirányítási eszközök használata, mint a Saviynt. Mérnöki munka folyik a probléma megoldásán az idő múlásával.

Néhányszor említettem Microsoft Entra PIM-et. Létezik egy megfelelő Microsoft Identity Manager (MIM) Privileged Access Management (PAM) megoldás a helyszíni vezérlőkhöz. Érdemes lehet áttekinteni a Privileged Access Workstations (EMELT munkaállomások) és a Microsoft Entra ID-kezelés is. Különböző külső eszközök is léteznek, amelyek igény szerinti, igény szerinti és dinamikus szerepkörszint-emelést tesznek lehetővé. Ez a képesség általában a környezet védelméről szóló nagyobb vita része.

Néha előfordul, hogy külső felhasználó szerepkörhöz való hozzáadására van lehetőség (lásd az előző több-bérlős szakaszt). Ez az eredmény jól működik. Microsoft Entra B2B egy másik nagy és szórakoztató cikk, amely végigvezeti az ügyfeleket, talán egy másik cikkben.

Microsoft Defender XDR és Microsoft 365 Purview megfelelőségi portálok

Email & Microsoft Defender portálon az együttműködési szerepkörök és a Microsoft 365 Purview megfelelőségi portálján található *Microsoft Purview-megoldások szerepkörcsoportjai "szerepkörcsoportok" gyűjteményei, amelyek elkülönülnek Microsoft Entra szerepköröktől. Ez zavaró lehet, mert ezen szerepkörcsoportok némelyike ugyanazzal a névvel rendelkezik, mint Microsoft Entra szerepkörök (például a Biztonsági olvasó), de eltérő tagsággal rendelkezhetnek. Inkább Microsoft Entra szerepköröket használok. Minden szerepkörcsoport egy vagy több "szerepkörből" áll (lásd, hogy mire gondolok ugyanarra a szóra?), és tagjai vannak Microsoft Entra ID, amelyek e-mail-kompatibilis objektumok. Emellett létrehozhat egy szerepkörcsoportot ugyanazzal a névvel, mint egy szerepkör, amely esetleg nem tartalmazza ezt a szerepkört (elkerülheti ezt a félreértést).

Bizonyos értelemben ezek az engedélyek az Exchange-szerepkörcsoportok modelljének fejlődését képezik. A Exchange Online azonban saját szerepkörcsoport-felügyeleti felülettel rendelkezik. A Exchange Online egyes szerepkörcsoportjai zárolva vannak, és a Microsoft Entra ID vagy a Microsoft Defender XDR és a Microsoft 365 Purview megfelelőségi portáljairól vannak zárolva és felügyelve, mások azonban azonos vagy hasonló nevűek lehetnek, és Exchange Online kezelik őket (a félreértések elkerülése érdekében). Azt javaslom, hogy kerülje a Exchange Online felhasználói felület használatát, kivéve, ha hatókörökre van szüksége az Exchange-felügyelethez.

Egyéni szerepkörök nem hozhatók létre. A szerepköröket a Microsoft által létrehozott szolgáltatások határozzák meg, és az új szolgáltatások bevezetésekor tovább növekednek. Ez a viselkedés a Microsoft Entra ID alkalmazások által meghatározott szerepkörökhöz hasonló. Ha új szolgáltatások vannak engedélyezve, gyakran új szerepkörcsoportokat kell létrehozni ahhoz, hogy hozzáférést lehessen biztosítani vagy delegálni ezekhez (például belső kockázatkezeléshez).

Ezek a szerepkörcsoportok közvetlen tagságot is igényelnek, és nem tartalmazhatnak Microsoft Entra csoportokat. Sajnos ezeket a szerepkörcsoportokat jelenleg nem támogatja Microsoft Entra PIM. A Microsoft Entra szerepkörökhöz hasonlóan általában ajánlom ezeknek a szerepkörcsoportoknak a kezelését API-kkal vagy egy olyan partnerirányítási termékkel, mint a Saviynt vagy más.

Microsoft Defender portál és a Microsoft 365 Purview megfelelőségi portál szerepkörei a Microsoft 365-öt is lefedik, és ezeket a szerepkörcsoportokat nem lehet a környezet egy részhalmazára korlátozni (ahogyan a Microsoft Entra ID felügyeleti egységeivel is megteheti). Sok ügyfél megkérdezi, hogyan lehet leépíteni. Például: "DLP-szabályzat létrehozása csak az EU-felhasználók számára". Ha jelenleg a Microsoft Defender XDR és a Microsoft 365 Purview megfelelőségi portálja egy adott funkciójához rendelkezik jogosultságokkal, a bérlőben minden olyan funkcióhoz rendelkezik jogosultságokkal, amelyre ez a funkció vonatkozik. Számos szabályzat azonban rendelkezik a környezet egy részhalmazának megcélzására szolgáló képességekkel (például "ezeket a címkéket csak ezeknek a felhasználóknak tegye elérhetővé"). A megfelelő irányítás és kommunikáció kulcsfontosságú az ütközések elkerülése érdekében. Egyes ügyfelek úgy döntenek, hogy implementálnak egy "konfiguráció mint kód" megközelítést az aldelegálás kezeléséhez a Microsoft Defender XDR és a Microsoft 365 Purview megfelelőségi portálján. Egyes szolgáltatások támogatják az aldelegálást (lásd a következő szakaszt).

Szolgáltatásspecifikus

Ahogy korábban említettem, sok ügyfél szeretne részletesebb delegálási modellt elérni. Egy gyakori példa: "Csak az X részleg felhasználóinak és helyeinek XYZ-szolgáltatásának kezelése" (vagy valamilyen más dimenzió). Ennek lehetősége az egyes szolgáltatásoktól függ, és nem konzisztens a szolgáltatások és képességek között. Emellett minden szolgáltatás külön és egyedi RBAC-modellel rendelkezhet. Ahelyett, hogy megvitatnák ezeket a modelleket (ami örökké tart), minden szolgáltatáshoz releváns hivatkozásokat adok hozzá. Ez a lista még nem fejeződött be, de ez segíthet az első lépésekben.

  • Exchange Online – (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online – (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams – (/microsoftteams/itadmin-readiness)
  • Feltárás – (.. /compliance/index.yml)
    • Engedélyszűrés – (.. /compliance/index.yml)
    • Megfelelőségi határok – (.. /compliance/set-up-compliance-boundaries.md)
    • Elektronikus adatok feltárása (prémium) – (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage – (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Megjegyzés:

Ez a hivatkozás a dokumentáció gyökerére mutató hivatkozás. A rendszergazdai/delegálási modellben többféle szolgáltatástípus létezik.

  • Power Platform – (/power-platform/admin/admin-documentation)

    • Power Apps – (/power-platform/admin/wp-security)

      Megjegyzés:

      A felügyeleti/delegálási modellekben többféle típus létezik.

    • Power Automate – (/power-automate/environments-overview-admin)

    • Power BI – (/power-bi/service-admin-governance)

      Megjegyzés: Az adatplatform biztonsága és delegálása (amely a Power BI egyik összetevője) összetett terület.

  • Intune – (/mem/intune/fundamentals/role-based-access-control)

  • Végponthoz készült Microsoft Defender – (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps – (/cloud-app-security/manage-admins)

  • Stream – (/stream/assign-administrator-user-role)

  • Információkorlátok – (.. /compliance/information-barriers.md)

Tevékenységnaplók

A Microsoft 365 egységes auditnaplóval rendelkezik. Ez egy nagyon részletes napló, de ne olvasson túl sokat a névbe. Előfordulhat, hogy nem tartalmaz mindent, amire szüksége van a biztonsági és megfelelőségi igényekhez. Emellett egyes ügyfeleket nagyon érdekli a naplózás (Prémium) is.

A más API-kon keresztül elért Microsoft 365-naplók például a következő funkciókat tartalmazzák:

Fontos, hogy először azonosítsa a biztonsági és megfelelőségi programokhoz szükséges összes naplóforrást. Azt is vegye figyelembe, hogy a különböző naplók különböző on-line adatmegőrzési korlátokkal rendelkeznek.

A rendszergazdai delegálás szempontjából a Microsoft 365-tevékenységnaplók többsége nem rendelkezik beépített RBAC-modellel. Ha rendelkezik engedéllyel egy napló megtekintéséhez, akkor mindent megtekinthet benne. Egy gyakori ügyfélkövetelmény például a következő: "Csak az EU-felhasználók számára szeretnék lekérdezési tevékenységet végezni" (vagy valamilyen más dimenzió). A követelmény teljesítéséhez át kell vinnünk a naplókat egy másik szolgáltatásba. A Microsoft-felhőben azt javasoljuk, hogy a Microsoft Sentinelbe vagy a Log Analyticsbe továbbadja.

Magas szintű diagram:

egy biztonsági és megfelelőségi program naplóforrásainak ábrája.

A diagram beépített képességeket ábrázol, amelyekkel naplókat küldhet az Event Hubsnak és/vagy az Azure Storage-nak és/vagy az Azure Log Analyticsnek. Még nem minden rendszer tartalmazza ezt a beépített rendszert. Vannak azonban más módszerek is, amelyek ezeket a naplókat ugyanarra az adattárra küldik. Lásd például a Teams védelme a Microsoft Sentinellel című témakört.

Az összes napló egyetlen tárolási helyre való kombinálása további előnyöket is tartalmaz, például a keresztkorrelációkat, az egyéni megőrzési időt, az RBAC-modell támogatásához szükséges adatok kiegészítését stb. Miután az adatok ebbe a tárolórendszerbe kerülnek, létrehozhat egy Power BI-irányítópultot (vagy más típusú vizualizációt) egy megfelelő RBAC-modellel.

A naplókat nem kell csak egy helyre irányítani. Hasznos lehet a Microsoft 365-naplók integrálása Microsoft Defender for Cloud Apps vagy egyéni RBAC-modellel a Power BI-ban. A különböző adattárak különböző előnyökkel és célközönségekkel rendelkeznek.

Érdemes megemlíteni, hogy a Microsoft Defender XDR nevű szolgáltatásban számos beépített elemzési rendszer áll rendelkezésre a biztonság, a fenyegetések, a biztonsági rések és így tovább.

Sok nagy ügyfél szeretné átadni ezeket a naplóadatokat egy külső rendszernek (például SIEM). Ennek az eredménynek különböző megközelítései vannak, de a Azure Event Hubs és a Graph általában jó kiindulási pont.

Azure

Gyakran megkérdezik, hogy van-e mód a magas jogosultságú szerepkörök elkülönítésére a Microsoft Entra ID, az Azure és az SaaS között (például: a Microsoft 365 globális rendszergazdája, de nem az Azure). Nem igazán. A több-bérlős architektúrára akkor van szükség, ha teljes felügyeleti elkülönítésre van szükség, de ez jelentős összetettséggel jár (ahogy azt korábban említettem). Ezek a szolgáltatások ugyanahhoz a biztonsági/identitáshatárhoz tartoznak (ahogy a hierarchiamodellben látható).

Fontos megérteni az azonos bérlőben található különböző szolgáltatások közötti kapcsolatokat. Számos ügyféllel dolgozom együtt, akik olyan üzleti megoldásokat készítenek, amelyek az Azure-ra, a Microsoft 365-re és a Power Platformra (és gyakran helyszíni és külső felhőszolgáltatásokra) is kiterjednek. Egy gyakori példa:

  1. Dokumentumokon/képeken/stb. (Microsoft 365) szeretnék együttműködni
  2. Mindegyik elküldése jóváhagyási folyamaton keresztül (Power Platform)
  3. Az összes összetevő jóváhagyása után állítsa össze ezeket az elemeket egy egységes termék(ek)be (Azure) a Microsoft Graph API a legjobb barátja. Nem lehetetlen, de sokkal összetettebb egy több bérlőre kiterjedő megoldás tervezése.

Az Azure Role-Based Access Control (RBAC) részletes hozzáférés-kezelést tesz lehetővé az Azure-ban. Az RBAC használatával úgy kezelheti az erőforrásokhoz való hozzáférést, hogy megadja a felhasználók számára a munkájuk elvégzéséhez szükséges legkevesebb engedélyt. A részletek nem tartoznak a dokumentum hatókörébe, de az RBAC-vel kapcsolatos további információkért lásd: Mi a szerepköralapú hozzáférés-vezérlés (RBAC) az Azure-ban? Az RBAC fontos, de az Azure szabályozási szempontjainak csak egy része. felhőadaptálási keretrendszer remek kiindulási pont a további információkhoz. Tetszik, hogy a barátom, Andres Ravinet lépésről lépésre végigvezeti az ügyfeleket a különböző összetevőkön, hogy eldöntsék a megközelítést. A különböző elemek magas szintű nézete (nem olyan jó, mint a tényleges ügyfélmodellhez való eljutás folyamata) az alábbihoz hasonló:

Az Azure-összetevők magas szintű nézete a delegált felügyelethez.

Ahogy a fenti képen látható, sok más szolgáltatást is figyelembe kell venni a tervezés részeként (például: Azure-szabályzatok, Azure Blueprints, Felügyeleti csoportok stb.).

Következtetés

Ez a cikk rövid összefoglalásként indult, és a vártnál tovább végződött. Remélem, készen áll arra, hogy részletesen megtekintse, hogyan hozhat létre delegálási modellt a szervezet számára. Ez a beszélgetés nagyon gyakori az ügyfelekkel. Egyetlen modell sem működik mindenki számára. Várjon néhány tervezett fejlesztésre a Microsoft mérnöki csapatától, mielőtt dokumentálja az ügyfelek közötti gyakori mintákat. Addig is a Microsoft-fiókért felelős csapatával együttműködve megszervezheti a legközelebbi Microsoft Technológiai Központ látogatását. Találkozunk ott!