Delen via

Naar identiteit en verder: het standpunt van één architect

  • Artikel

In dit artikel bespreekt Alex Shteynberg, Principal Technical Architect bij Microsoft, de belangrijkste ontwerpstrategieën voor bedrijfsorganisaties die Microsoft 365 en andere Microsoft-cloudservices gebruiken.

Over de auteur

Alex Shteynberg foto.

Ik ben principal technical architect bij het Microsoft Technology Center in New York. Ik werk voornamelijk met grote klanten en complexe eisen. Mijn standpunt en meningen zijn gebaseerd op deze interacties en zijn mogelijk niet van toepassing op elke situatie. Mijn ervaring is echter dat als we klanten kunnen helpen met de meest complexe uitdagingen, we alle klanten kunnen helpen.

Ik werk meestal met meer dan 100 klanten per jaar. Hoewel elke organisatie unieke kenmerken heeft, is het interessant om trends en overeenkomsten te zien. Een trend is bijvoorbeeld brancheoverschrijdende interesse voor veel klanten. Een bankfiliaal kan immers ook een café en een buurthuis zijn.

In mijn rol richt ik me op het helpen van klanten bij het bereiken van de beste technische oplossing om te komen tot hun unieke set bedrijfsdoelen. Officieel richt ik me op identiteit, beveiliging, privacy en naleving. Ik vind het geweldig dat deze alles raken wat we doen. Het geeft me de kans om betrokken te zijn bij de meeste projecten. Deze activiteit houdt me bezig en geniet van deze rol.

Ik woon in New York City (de beste!) en geniet echt van de diversiteit van de cultuur, het eten en de mensen (niet het verkeer). Ik hou van reizen wanneer ik kan en hoop het grootste deel van de wereld in mijn leven te zien. Ik onderzoek momenteel een reis naar Afrika om meer te weten te komen over wilde dieren.

Richtsnoeren

  • Eenvoudig is vaak beter: Je kunt (bijna) alles doen met technologie, maar dat betekent niet dat je dat moet doen. Vooral op het gebied van beveiliging overstuurden veel klanten oplossingen. Ik vind deze video van de Stripe-conferentie van Google leuk om dit punt te onderstrepen.
  • Mensen, proces, technologie: ontwerp voor mensen om het proces te verbeteren, niet tech first. Er zijn geen "perfecte" oplossingen. We moeten verschillende risicofactoren en beslissingen afwegen die voor elk bedrijf anders kunnen zijn. Te veel klanten ontwerpen een benadering die hun gebruikers later vermijden.
  • Richt u eerst op 'waarom' en 'hoe' later: Wees de irritante 7-jarige jongen met een miljoen vragen. We kunnen niet tot het juiste antwoord komen als we de juiste vragen niet weten. Veel klanten maken veronderstellingen over hoe dingen moeten werken in plaats van het bedrijfsprobleem te definiëren. Er zijn altijd meerdere paden die kunnen worden genomen.
  • Lange staart van aanbevolen procedures uit het verleden: erken dat best practices met lichte snelheid veranderen. Als je Microsoft Entra meer dan drie maanden geleden hebt bekeken, ben je waarschijnlijk verouderd. Alles hier kan na publicatie worden gewijzigd. De optie 'Beste' is mogelijk niet hetzelfde over zes maanden.

Basislijnconcepten

Sla deze sectie niet over. Ik vind vaak dat ik terug moet naar deze artikelen, zelfs voor klanten die al jaren gebruikmaken van cloudservices. Helaas is taal geen nauwkeurig hulpmiddel. We gebruiken vaak hetzelfde woord om verschillende concepten of verschillende woorden te bedoelen om hetzelfde concept te betekenen. Ik gebruik vaak het volgende diagram om basislijnterminologie en 'hiërarchiemodel' vast te stellen.

Afbeelding van tenant, abonnement, service en gegevens.

Als je leert zwemmen, is het beter om in het zwembad te beginnen en niet in het midden van de oceaan. Ik probeer niet technisch nauwkeurig te zijn met dit diagram. Het is een model om enkele basisconcepten te bespreken.

In het diagram:

  • Tenant = een exemplaar van Microsoft Entra ID. Het bevindt zich bovenaan een hiërarchie of niveau 1 in het diagram. We kunnen dit niveau beschouwen als de "grens" waar al het andere gebeurt (Microsoft Entra B2B terzijde). Alle Microsoft Enterprise-cloudservices maken deel uit van een van deze tenants. Consumentenservices zijn gescheiden. 'Tenant' wordt in de documentatie weergegeven als Microsoft 365-tenant, Azure-tenant, WVD-tenant, enzovoort. Ik vind vaak dat deze variaties verwarring veroorzaken bij klanten.
  • Services/abonnementen, niveau 2 in het diagram, behoren tot slechts één tenant. De meeste SaaS-services zijn 1:1 en kunnen niet worden verplaatst zonder migratie. Azure is anders. U kunt facturering en/of een abonnement verplaatsen naar een andere tenant. Er zijn veel klanten die Azure-abonnementen moeten verplaatsen. Dit scenario heeft verschillende gevolgen. Objecten die zich buiten het abonnement bevinden, worden niet verplaatst. Bijvoorbeeld op rollen gebaseerd toegangsbeheer (Azure RBAC), Microsoft Entra objecten (groepen, apps, beleidsregels, enzovoort) en sommige services (Azure Key Vault, Data Bricks, enzovoort). Migreer geen services zonder een goede bedrijfsbehoefte. Sommige scripts die nuttig kunnen zijn voor migratie, worden gedeeld op GitHub.
  • Een bepaalde service heeft meestal een soort 'subniveau'-grens, of niveau 3 (L3). Deze grens is handig om te begrijpen voor scheiding van beveiliging, beleid, governance, enzovoort. Helaas is er geen uniforme naam die ik ken. Enkele voorbeelden van namen voor L3 zijn: Azure-abonnement = resource; Dynamics 365 CE = exemplaar; Power BI = werkruimte; Power Apps = omgeving; enzovoort.
  • Niveau 4 is waar de werkelijke gegevens zich bevinden. Dit 'gegevensvlak' is een complex artikel. Sommige services gebruiken Microsoft Entra ID voor RBAC, andere niet. Ik zal het een beetje bespreken als we bij delegeringsartikelen komen.

Enkele andere concepten waarover veel klanten (en Microsoft-werknemers) in de war zijn of waarover ik vragen heb, zijn onder andere de volgende problemen:

  • Iedereen kan gratis veel tenants maken. U hebt geen service nodig die erin is ingericht. Ik heb er tientallen. Elke tenantnaam is uniek in de wereldwijde cloudservice van Microsoft (met andere woorden, geen twee tenants kunnen dezelfde naam hebben). Ze hebben allemaal de indeling TenantName.onmicrosoft.com. Er zijn ook processen waarmee tenants automatisch worden gemaakt (onbeheerde tenants). Dit resultaat kan bijvoorbeeld optreden wanneer een gebruiker zich registreert voor een bedrijfsservice met een e-maildomein dat niet bestaat in een andere tenant.
  • In een beheerde tenant kunnen veel DNS-domeinen erin worden geregistreerd. Met dit resultaat wordt de oorspronkelijke tenantnaam niet gewijzigd. Er is momenteel geen eenvoudige manier om de naam van een tenant te wijzigen (behalve migratie). Hoewel de naam van de tenant technisch gezien niet kritiek is, kunnen sommige mensen zich beperkt voelen door deze realiteit.
  • U moet een tenantnaam voor uw organisatie reserveren, zelfs als u nog geen services wilt implementeren. Anders kan iemand het van u overnemen en is er geen eenvoudige procedure om het terug te nemen (hetzelfde probleem als DNS-namen). Ik hoor dit te vaak van klanten. Wat uw tenantnaam moet zijn, is ook een discussieartikel.
  • Als u eigenaar bent van een DNS-naamruimte, moet u al deze naamruimten toevoegen aan uw tenants. Anders kan een onbeheerde tenant met deze naam worden gemaakt, waardoor deze wordt beheerd.
  • Een DNS-naamruimte (bijvoorbeeld contoso.com) kan tot slechts één tenant behoren. Deze vereiste heeft gevolgen voor verschillende scenario's (bijvoorbeeld het delen van een e-maildomein tijdens een fusie of overname, enzovoort). Er is een manier om een DNS-sub (zoals div.contoso.com) te registreren in een andere tenant, maar dat moet worden vermeden. Door een domeinnaam op het hoogste niveau te registreren, worden alle subdomeinen verondersteld deel uit te maken van dezelfde tenant. In scenario's met meerdere tenants (zoals hierna wordt uitgelegd) raad ik normaal gesproken aan een andere domeinnaam op het hoogste niveau te gebruiken (zoals contoso.ch of ch-contoso.com).
  • Wie moet 'eigenaar' zijn van een tenant? Ik zie vaak klanten die niet weten wie momenteel eigenaar is van hun tenant. Dit gebrek aan kennis is een belangrijke rode vlag. Bel zo snel mogelijk met Microsoft-ondersteuning. Net zo problematisch is het wanneer een service-eigenaar (vaak een Exchange-beheerder) is aangewezen om een tenant te beheren. De tenant bevat alle services die u in de toekomst mogelijk wilt gebruiken. De tenanteigenaar moet een groep zijn die kan beslissen over het inschakelen van alle cloudservices in een organisatie. Een ander probleem is wanneer een tenanteigenaargroep wordt gevraagd om alle services te beheren. Deze methode kan niet worden geschaald voor grote organisaties.
  • Er is geen concept van een sub-/supertenant. Om de een of andere reden herhaalt deze mythe zich steeds. Dit concept is ook van toepassing op Azure Active Directory B2C-tenants . Ik hoor te vaak: 'Mijn B2C-omgeving bevindt zich in mijn XYZ-tenant' of 'Hoe kan ik mijn Azure-tenant verplaatsen naar mijn Microsoft 365-tenant?'
  • Dit document richt zich voornamelijk op de commerciële wereldwijde cloud, omdat dat is wat de meeste klanten gebruiken. Het is soms handig om te weten over onafhankelijke clouds. Soevereine clouds hebben andere implicaties die buiten het bereik van deze discussie vallen.

Artikelen over basislijnidentiteit

Er is veel documentatie over het identiteitsplatform van Microsoft: Microsoft Entra ID. Voor mensen die net beginnen, voelt het vaak overweldigend. Zelfs nadat u er meer over hebt geleerd, kan het bijhouden van constante innovatie en verandering een uitdaging zijn. In de interactie met mijn klanten ben ik vaak 'vertaler' tussen bedrijfsdoelen en 'Good, Better, Best' benaderingen om deze problemen aan te pakken (en menselijke 'klifnotities' voor deze artikelen). Er is zelden een perfect antwoord en de 'juiste' beslissing is een balans van verschillende risicofactoren. Hierna volgen enkele van de veelgestelde vragen en verwarringsgebieden die ik vaak met klanten bespreek.

Provisioning

Microsoft Entra ID lost het gebrek aan governance in je identiteitswereld niet op! Identiteitsgovernance moet een essentieel element zijn, onafhankelijk van beslissingen in de cloud. Governancevereisten veranderen na verloop van tijd, daarom is het een programma en geen hulpprogramma.

Microsoft Entra Connect versus Microsoft Identity Manager (MIM) versus iets anders (derden of aangepast)? Bespaar uzelf nu en in de toekomst problemen en ga aan de slag met Microsoft Entra Connect. Er zijn allerlei slimme functies in deze tool om eigenaardige klantconfiguraties en doorlopende innovaties aan te pakken.

Enkele edge-cases die mogelijk een complexere architectuur in de weg staan:

  • Ik heb meerdere AD-forests zonder netwerkverbinding tussen deze forests. Er is een nieuwe optie met de naam Cloudinrichting.
  • Ik heb geen Active Directory en ik wil het ook niet installeren. Microsoft Entra Connect kan worden geconfigureerd voor synchronisatie vanuit LDAP (mogelijk is een partner vereist).
  • Ik moet dezelfde objecten inrichten voor meerdere tenants. Dit scenario wordt technisch niet ondersteund, maar is afhankelijk van de definitie van 'hetzelfde'.

Moet ik standaardsynchronisatieregels aanpassen (filterobjecten, kenmerken wijzigen, alternatieve aanmeldings-id, enzovoort)? Vermijd het! Een identiteitsplatform is slechts zo waardevol als de services die het gebruiken. Hoewel u allerlei nutty configuraties kunt uitvoeren, moet u om deze vraag te beantwoorden kijken naar het effect op toepassingen. Als u objecten met e-mail filtert, is de gal voor onlineservices onvolledig. Als de toepassing afhankelijk is van specifieke kenmerken, heeft het filteren op deze kenmerken onvoorspelbare effecten, enzovoort. Het is geen identiteitsteambeslissing.

XYZ SaaS biedt ondersteuning voor Just-In-Time (JIT)-inrichting. Waarom moet ik synchroniseren? Zie de vorige alinea. Veel toepassingen hebben profielgegevens nodig voor functionaliteit. U kunt geen gal hebben als niet alle objecten met e-mail beschikbaar zijn. Hetzelfde geldt voor het inrichten van gebruikers in toepassingen die zijn geïntegreerd met Microsoft Entra ID.

Verificatie

Wachtwoord-hashsynchronisatie (PHS) versus passthrough-verificatie (PTA) versus federatie.

Meestal is er een gepassioneerd debat over federatie. Eenvoudiger is meestal beter en gebruik daarom PHS tenzij u een goede reden hebt om dit niet te doen. Het is ook mogelijk om verschillende verificatiemethoden te configureren voor verschillende DNS-domeinen in dezelfde tenant.

Sommige klanten schakelen federatie + PHS voornamelijk in voor:

Ik begeleid klanten vaak door de clientverificatiestroom om enkele misvattingen te verduidelijken. Het resultaat lijkt op de volgende afbeelding, die niet zo goed is als het interactieve proces om er te komen.

Voorbeeld van whiteboardgesprek.

Dit type whiteboardtekening laat zien waar beveiligingsbeleid wordt toegepast binnen de stroom van een verificatieaanvraag. In dit voorbeeld worden beleidsregels die worden afgedwongen via Active Directory Federation Service (AD FS) toegepast op de eerste serviceaanvraag, maar niet op volgende serviceaanvragen. Dit gedrag is ten minste één reden om beveiligingsbesturingselementen zoveel mogelijk naar de cloud te verplaatsen.

De droom van eenmalige aanmelding (SSO) is al zo lang als ik me kan herinneren. Sommige klanten denken dat ze eenmalige aanmelding kunnen bereiken door de 'juiste' federatieprovider (STS) te kiezen. Microsoft Entra ID kan aanzienlijk helpen om SSO-mogelijkheden in te schakelen, maar geen STS is magisch. Er zijn te veel verouderde verificatiemethoden die nog steeds worden gebruikt voor kritieke toepassingen. Veel van deze scenario's kunnen worden aangepakt door Microsoft Entra ID uit te breiden met partneroplossingen. Eenmalige aanmelding is een strategie en een traject. U kunt er niet komen zonder over te stappen op standaarden voor toepassingen. Gerelateerd aan dit artikel is een reis naar verificatie zonder wachtwoord , die ook geen magisch antwoord heeft.

Meervoudige verificatie (MFA) is vandaag essentieel (hier voor meer). Voeg daar analyse van gebruikersgedrag aan toe en u hebt een oplossing die de meest voorkomende cyberaanvallen voorkomt. Zelfs voor consumentenservices is MFA vereist. Toch ontmoet ik nog steeds veel klanten die niet willen overstappen op moderne verificatiemethoden . Het grootste argument dat ik hoor, is dat het van invloed is op gebruikers en verouderde toepassingen. Soms kan een goede kick klanten helpen om verder te gaan Exchange Online aangekondigde wijzigingen. Er zijn nu veel Microsoft Entra rapporten beschikbaar om klanten te helpen bij deze overgang.

Vergunning

Volgens Wikipedia is 'autoriseren' het definiëren van een toegangsbeleid. Veel mensen zien het als de mogelijkheid om toegangsbeheer voor een object (bestand, service, enzovoort) te definiëren. In de huidige wereld van cyberbedreigingen ontwikkelt dit concept zich snel tot een dynamisch beleid dat kan reageren op verschillende bedreigingsvectoren en snel toegangsbeheer kan aanpassen als reactie hierop. Als ik bijvoorbeeld vanaf een ongebruikelijke locatie toegang heb tot mijn bankrekening, krijg ik extra bevestigingsstappen. Om deze realiteit te benaderen, moeten we niet alleen rekening houden met het beleid zelf, maar ook met het ecosysteem van methodologieën voor detectie van bedreigingen en signaalcorrelatie.

De beleidsengine van Microsoft Entra ID wordt geïmplementeerd met behulp van beleid voor voorwaardelijke toegang. Dit systeem is afhankelijk van informatie van andere detectiesystemen voor bedreigingen om dynamische beslissingen te nemen. Een eenvoudige weergave lijkt op de volgende afbeelding:

Beleidsengine in Microsoft Entra ID.

Als u al deze signalen combineert, kunt u dynamische beleidsregels zoals deze gebruiken:

  • Als er een bedreiging wordt gedetecteerd op uw apparaat, wordt uw toegang tot gegevens beperkt tot internet zonder de mogelijkheid om te downloaden.
  • Als u een ongebruikelijk grote hoeveelheid gegevens downloadt, wordt alles wat u downloadt versleuteld en beperkt.
  • Als u toegang hebt tot een service vanaf een onbeheerd apparaat, wordt u geblokkeerd voor zeer gevoelige gegevens, maar hebt u toegang tot niet-beperkt gegevens zonder dat u deze naar een andere locatie kunt kopiëren.

Als u akkoord gaat met deze uitgebreide definitie van autorisatie, moet u aanvullende oplossingen implementeren. Welke oplossingen u implementeert, is afhankelijk van hoe dynamisch het beleid moet zijn en welke bedreigingen u prioriteit wilt geven. Enkele voorbeelden van dergelijke systemen zijn:

Naast Microsoft Entra ID hebben verschillende services en toepassingen hun eigen specifieke autorisatiemodellen. Sommige van deze modellen worden verderop in de delegatiesectie besproken.

Audit

Microsoft Entra ID beschikt over gedetailleerde controle- en rapportagemogelijkheden. Deze rapporten zijn echter meestal niet de enige bron van informatie die nodig is om beveiligingsbeslissingen te nemen. Zie de sectie delegatie voor meer informatie over dit onderwerp.

Er is geen exchange

Geen paniek! Exchange wordt niet afgeschaft (of SharePoint, enzovoort). Het is nog steeds een kernservice. Wat ik bedoel is dat technologieproviders al geruime tijd gebruikerservaringen (UX) overzetten naar onderdelen van meerdere services. In Microsoft 365 is een eenvoudig voorbeeld 'moderne bijlagen' waarbij bijlagen bij e-mail worden opgeslagen in SharePoint Online of OneDrive.

Een bestand bijvoegen bij een e-mailbericht.

Als u de Outlook-client bekijkt, ziet u veel services die 'verbonden' zijn als onderdeel van deze ervaring, niet alleen Exchange. Voorbeelden zijn Microsoft Entra ID, Microsoft Search, Apps, Profiel, naleving en Microsoft 365-groepen.

Outlook-interface met bijschriften.

Lees meer over Microsoft Vloeiend Framework voor een preview van toekomstige mogelijkheden. In preview kan ik Teams-gesprekken nu rechtstreeks in Outlook lezen en beantwoorden. De Teams-client is zelfs een van de meest prominente voorbeelden van deze strategie.

Over het algemeen wordt het steeds moeilijker om een duidelijke lijn te trekken tussen Microsoft 365 en andere services in Microsoft-clouds. Ik zie het als een groot voordeel voor klanten, omdat ze kunnen profiteren van totale innovatie in alles wat we doen, zelfs als ze één onderdeel gebruiken. Behoorlijk cool en heeft verreikende gevolgen voor veel klanten.

Tegenwoordig vind ik dat veel IT-groepen van klanten zijn gestructureerd rond 'producten'. Het is logisch voor een on-premises wereld, omdat u voor elk specifiek product een expert nodig hebt. Ik ben echter blij dat ik nooit meer fouten hoef op te sporen in een Active Directory- of Exchange-database omdat deze services zijn verplaatst naar de cloud. Automatisering (wat de cloud in feite is) verwijdert bepaalde terugkerende handmatige taken (kijk wat er met factory's is gebeurd). Deze taken worden echter vervangen door complexere vereisten om inzicht te krijgen in interactie tussen services, het effect, de bedrijfsbehoeften, enzovoort. Als u bereid bent om te leren, zijn er geweldige kansen mogelijk door cloudtransformatie. Voordat ik in de technologie duik, praat ik vaak met klanten over het beheren van veranderingen in IT-vaardigheden en teamstructuren.

Aan alle SharePoint-fans en -ontwikkelaars kunt u niet meer vragen: 'Hoe kan ik XYZ doen in SharePoint Online?' Gebruik Power Automate (of Flow) voor werkstromen, het is een veel krachtiger platform. Gebruik Azure Bot Framework om een betere UX te maken voor uw 500-K-itemlijst. Begin met het gebruik van Microsoft Graph in plaats van CSOM. Microsoft Teams bevat SharePoint, maar ook een wereld meer. Er zijn veel andere voorbeelden die ik kan vermelden. Er is een enorm en prachtig universum daarbuiten. Open de deur en begin met verkennen.

Het andere veelvoorkomende effect is op het nalevingsgebied. Deze benadering voor meerdere services lijkt veel nalevingsbeleid volledig te verwarren. Ik zie steeds organisaties die aangeven: 'Ik moet alle e-mailcommunicatie in een eDiscovery-systeem registreren.' Wat betekent deze instructie eigenlijk als e-mail niet langer alleen e-mail is, maar een venster op andere services? Microsoft 365 heeft een uitgebreide benadering voor naleving, maar het veranderen van mensen en processen is vaak veel moeilijker dan technologie.

Er zijn veel andere mensen en proces implicaties. Naar mijn mening is dit een kritiek en onderbelicht gebied. Misschien meer in een ander artikel.

Opties voor tenantstructuur

Eén tenant versus meerdere tenants

Over het algemeen moeten de meeste klanten slechts één productietenant hebben. Er zijn veel redenen waarom meerdere tenants lastig zijn (geef het een Bing-zoekopdracht) of lees dit technisch document. Tegelijkertijd hebben veel zakelijke klanten waarmee ik werk een andere (kleine) tenant voor IT-leren, testen en experimenteren. Azure-toegang voor meerdere tenants wordt eenvoudiger gemaakt met Azure Lighthouse. Microsoft 365 en vele andere SaaS-services hebben limieten voor scenario's tussen tenants. Er is veel om rekening mee te houden in Microsoft Entra B2B-scenario's.

Veel klanten hebben na een fusie en overname meerdere productietenants (M&A) en willen consolideren. Dat is tegenwoordig niet eenvoudig en vereist Microsoft Consulting Services (MCS) of een partner plus software van derden. Er wordt voortdurend aan engineering gewerkt om in de toekomst verschillende scenario's met klanten met meerdere tenants aan te pakken.

Sommige klanten kiezen ervoor om met meer dan één tenant te gaan. Dit moet een zorgvuldige beslissing zijn en bijna altijd bedrijfsredensen zijn! Enkele voorbeelden zijn de volgende redenen:

  • Een bedrijfsstructuur van het type holding waar eenvoudige samenwerking tussen verschillende entiteiten niet vereist is en er sterke administratieve en andere isolatiebehoeften zijn.
  • Na een overname wordt een zakelijke beslissing genomen om twee entiteiten gescheiden te houden.
  • Simulatie van de omgeving van een klant die de productieomgeving van de klant niet wijzigt.
  • Ontwikkeling van software voor klanten.

In deze scenario's met meerdere tenants willen klanten vaak bepaalde configuraties hetzelfde houden in tenants of willen ze rapporteren over configuratiewijzigingen en afwijkingen. Dit betekent vaak dat u moet overstappen van handmatige wijzigingen naar configuratie als code. Microsoft Premiere-ondersteuning biedt een workshop voor deze typen vereisten op basis van dit openbare IP-adres: https://Microsoft365dsc.com.

Multi-Geo

Naar Multi-Geo of niet naar Multi-Geo. Dat is de vraag. Met Microsoft 365 Multi-Geo kunt u data-at-rest inrichten en opslaan in de geografische locaties die u kiest om te voldoen aan de vereisten voor gegevenslocatie . Er zijn veel misvattingen over deze mogelijkheid. Houd rekening met de volgende punten:

  • Het biedt geen prestatievoordelen. Dit kan de prestaties slechter maken als het netwerkontwerp niet juist is. Haal apparaten 'dicht' bij het Microsoft-netwerk, niet noodzakelijkerwijs bij uw gegevens.
  • Het is geen oplossing voor AVG-naleving. DE AVG is niet gericht op gegevenssoevereine of opslaglocaties. Er zijn andere nalevingsframeworks voor gegevenssoevereine of opslaglocaties.
  • Het lost geen beheerdelegering (zie hieronder) of informatiebarrières op.
  • Dit is niet hetzelfde als multitenant en vereist meer werkstromen voor het inrichten van gebruikers .
  • Uw tenant (uw Microsoft Entra ID) wordt niet verplaatst naar een andere geografie.

Delegering van beheer

In de meeste grote organisaties is scheiding van taken en op rollen gebaseerd toegangsbeheer (RBAC) een noodzakelijke realiteit. Ik verontschuldig me van tevoren. Deze activiteit is niet zo eenvoudig als sommige klanten willen. Klant-, juridische, nalevings- en andere vereisten zijn verschillend en soms conflicterend over de hele wereld. Eenvoud en flexibiliteit staan vaak tegenover elkaar. Begrijp me niet verkeerd, we kunnen het beter doen met dit doel. Er zijn (en zullen) in de loop van de tijd aanzienlijke verbeteringen zijn aangebracht. Ga naar uw lokale Microsoft Technology Center om het model uit te werken dat past bij uw bedrijfsvereisten zonder 379.230 documenten te lezen. Hier richt ik me op wat je moet denken en niet waarom het zo is. Er komen vijf verschillende gebieden die u moet plannen en enkele van de veelgestelde vragen die ik tegenkom.

Microsoft Entra ID- en Microsoft 365-beheercentrums

Er is een lange en groeiende lijst met ingebouwde rollen. Elke rol bestaat uit een lijst met rolmachtigingen die zijn gegroepeerd om specifieke acties uit te voeren. U kunt deze machtigingen zien op het tabblad Beschrijving binnen elke rol. U kunt ook een meer menselijke leesbare versie van deze machtigingen zien in het Microsoft 365-beheer Center. De definities voor ingebouwde rollen kunnen niet worden gewijzigd. Over het algemeen groepeer ik deze rollen in drie categorieën:

  • Globale beheerder: Deze 'krachtige' rol moet in hoge mate worden beveiligd, net als in andere systemen. Typische aanbevelingen zijn: geen permanente toewijzing en gebruik Microsoft Entra Privileged Identity Management (PIM), sterke verificatie, enzovoort. Interessant is dat u met deze rol niet standaard toegang hebt tot alles. Normaal gesproken zie ik verwarring over nalevingstoegang en Azure-toegang, die later wordt besproken. Met deze rol kan echter altijd toegang tot andere services in de tenant worden toegewezen.
  • Specifieke servicebeheerders: Sommige services (Exchange, SharePoint, Power BI, enzovoort) gebruiken beheerrollen op hoog niveau van Microsoft Entra ID. Dit gedrag is niet consistent voor alle services en er worden later meer servicespecifieke rollen besproken.
  • Functioneel: er is een lange (en groeiende) lijst met rollen die zijn gericht op specifieke bewerkingen (gastnodigers, enzovoort). Periodiek worden meer van deze rollen toegevoegd op basis van de behoeften van de klant.

Het is niet mogelijk om alles te delegeren (hoewel de kloof afneemt), wat betekent dat de rol van globale beheerder soms moet worden gebruikt. Configuratie als code en automatisering moeten worden overwogen in plaats van personen die lid zijn van deze rol.

Opmerking: de Microsoft 365-beheercentrum heeft een gebruiksvriendelijkere interface, maar heeft een subset van mogelijkheden in vergelijking met de Microsoft Entra beheerderservaring. Beide portals gebruiken dezelfde Microsoft Entra rollen, dus wijzigingen worden op dezelfde plaats uitgevoerd. Tip: als u een beheerinterface wilt die is gericht op identiteitsbeheer zonder alle Azure-onbelangrijke e-mail, gebruikt https://aad.portal.azure.comu .

Wat staat er in de naam? Maak geen veronderstellingen op basis van de naam van de rol. Taal is geen nauwkeurig hulpmiddel. Het doel moet zijn om bewerkingen te definiëren die moeten worden gedelegeerd voordat wordt gekeken welke rollen nodig zijn. Als u iemand toevoegt aan de rol Beveiligingslezer, ziet deze niet overal beveiligingsinstellingen.

De mogelijkheid om aangepaste rollen te maken is een veelvoorkomende vraag. Deze mogelijkheid is momenteel beperkt in Microsoft Entra (zoals later wordt uitgelegd), maar zal in de loop van de tijd toenemen. Ik denk dat deze aangepaste rollen van toepassing zijn op functies in Microsoft Entra ID en mogelijk niet 'omlaag' het hiërarchiemodel beslaan (zoals eerder besproken). Wanneer ik te maken heb met 'aangepast', ga ik terug naar mijn principal van 'eenvoudig is beter'.

Een andere veelvoorkomende vraag is de mogelijkheid om rollen te bepalen voor een subset van een directory. Een voorbeeld hiervan is 'Helpdeskbeheerder voor gebruikers in de EU alleen'. Beheereenheden zijn bedoeld om dit scenario aan te pakken. Zoals eerder beschreven, denk ik dat deze bereiken van toepassing zijn op functies in Microsoft Entra ID en mogelijk niet 'omlaag'. Bepaalde rollen zijn niet logisch voor het bereik (globale beheerders, servicebeheerders, enzovoort).

Tegenwoordig is voor al deze rollen direct lidmaatschap vereist (of dynamische toewijzing als u Microsoft Entra PIM gebruikt). Dit betekent dat klanten deze rol rechtstreeks in Microsoft Entra ID moeten beheren en dat deze rollen niet kunnen worden gebaseerd op lidmaatschap van een beveiligingsgroep. Ik ben geen fan van het maken van scripts om deze rollen te beheren, omdat deze moet worden uitgevoerd met verhoogde rechten. Over het algemeen raad ik API-integratie aan met processystemen zoals ServiceNow of het gebruik van hulpprogramma's voor partnergovernance, zoals Saviynt. Er wordt technisch gewerkt om dit probleem in de loop van de tijd op te lossen.

Ik heb Microsoft Entra PIM een paar keer genoemd. Er is een overeenkomstige MICROSOFT IDENTITY MANAGER (MIM) Privileged Access Management(PAM)-oplossing voor on-premises besturingselementen. U kunt ook Privileged Access Workstations (PAW's) en Microsoft Entra ID-governance bekijken. Er zijn ook verschillende hulpprogramma's van derden, waarmee just-in-time, just-enough en dynamische rolverhoging kunnen worden ingeschakeld. Deze mogelijkheid maakt meestal deel uit van een grotere discussie over het beveiligen van een omgeving.

Soms wordt in scenario's het toevoegen van een externe gebruiker aan een rol aangeroepen (zie de vorige sectie met meerdere tenants). Dit resultaat werkt prima. Microsoft Entra B2B is een ander groot en leuk artikel om klanten doorheen te leiden, misschien in een ander artikel.

Microsoft Defender XDR- en Microsoft 365 Purview-complianceportals

Email & Samenwerkingsrollen in de Microsoft Defender portal en *Rolgroepen voor Microsoft Purview-oplossingen in de Microsoft 365 Purview-complianceportal zijn een verzameling 'rolgroepen', die los staan van Microsoft Entra rollen. Dit kan verwarrend zijn omdat sommige van deze rolgroepen dezelfde naam hebben als Microsoft Entra rollen (bijvoorbeeld Beveiligingslezer), maar ze kunnen een ander lidmaatschap hebben. Ik geef de voorkeur aan het gebruik van Microsoft Entra rollen. Elke rolgroep bestaat uit een of meer 'rollen' (zie wat ik bedoel over het opnieuw gebruiken van hetzelfde woord?) en leden van Microsoft Entra ID. Dit zijn objecten waarvoor e-mail is ingeschakeld. U kunt ook een rollengroep maken met dezelfde naam als een rol, die al dan niet die rol bevat (vermijd deze verwarring).

In zekere zin zijn deze machtigingen een evolutie van het Exchange-model voor rolgroepen. Exchange Online heeft echter een eigen interface voor het beheer van rollengroepen. Sommige rolgroepen in Exchange Online worden vergrendeld en beheerd vanuit Microsoft Entra ID of de Microsoft Defender XDR- en Microsoft 365 Purview-complianceportals, maar andere kunnen dezelfde of vergelijkbare namen hebben en worden beheerd in Exchange Online (dit maakt de verwarring nog groter). Ik raad u aan de gebruikersinterface Exchange Online te gebruiken, tenzij u bereiken nodig hebt voor Exchange-beheer.

U kunt geen aangepaste rollen maken. Rollen worden gedefinieerd door services die door Microsoft zijn gemaakt en blijven groeien naarmate er nieuwe services worden geïntroduceerd. Dit gedrag is qua concept vergelijkbaar met rollen die zijn gedefinieerd door toepassingen in Microsoft Entra ID. Wanneer nieuwe services zijn ingeschakeld, moeten er vaak nieuwe rolgroepen worden gemaakt om deze toegang te verlenen of te delegeren (bijvoorbeeld intern risicobeheer).

Deze rolgroepen vereisen ook direct lidmaatschap en mogen geen Microsoft Entra groepen bevatten. Helaas worden deze rollengroepen momenteel niet ondersteund door Microsoft Entra PIM. Net als Microsoft Entra rollen adviseer ik het beheer van deze rolgroepen via API's of een partnergovernanceproduct zoals Saviynt of andere.

Microsoft Defender portal- en Microsoft 365 Purview-complianceportalrollen microsoft 365 omvatten en u deze rolgroepen niet kunt toepassen op een subset van de omgeving (zoals u wel kunt met beheereenheden in Microsoft Entra ID). Veel klanten vragen hoe ze kunnen subdeleren. Bijvoorbeeld: 'maak alleen een DLP-beleid voor EU-gebruikers'. Als u momenteel rechten hebt voor een specifieke functie in de Microsoft Defender XDR en Microsoft 365 Purview-complianceportals, hebt u rechten op alles wat door deze functie in de tenant wordt gedekt. Veel beleidsregels hebben echter mogelijkheden voor een subset van de omgeving (bijvoorbeeld 'deze labels alleen beschikbaar maken voor deze gebruikers'). Goede governance en communicatie zijn een belangrijk onderdeel om conflicten te voorkomen. Sommige klanten kiezen ervoor om een 'configuratie als code'-benadering te implementeren om subdelegatie te adresseren in de Microsoft Defender XDR- en Microsoft 365 Purview-complianceportals. Sommige specifieke services ondersteunen subdelegatie (zie de volgende sectie).

Servicespecifiek

Zoals eerder vermeld, zijn veel klanten op zoek naar een gedetailleerder delegeringsmodel. Een veelvoorkomend voorbeeld: 'XYZ-service alleen beheren voor Division X-gebruikers en -locaties' (of een andere dimensie). De mogelijkheid om dit te doen, is afhankelijk van elke service en is niet consistent tussen services en mogelijkheden. Bovendien kan elke service een afzonderlijk en uniek RBAC-model hebben. In plaats van al deze modellen te bespreken (wat eeuwig zou duren), voeg ik relevante koppelingen toe voor elke service. Deze lijst is niet volledig, maar kan u wel aan de slag helpen.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /compliance/index.yml)
    • Machtigingsfiltering - (.. /compliance/index.yml)
    • Nalevingsgrenzen - (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) - (.. /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/)

Opmerking

Deze koppeling is naar de hoofdmap van de documentatie. Er zijn meerdere typen services met variaties in het beheer-/delegeringsmodel.

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

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

      Opmerking

      er zijn meerdere typen met variaties in de beheer-/delegeringsmodellen.

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

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

      Opmerking: beveiliging en delegering van gegevensplatforms (power BI is een onderdeel) is een complex gebied.

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

  • Microsoft Defender voor Eindpunt - (/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)

  • Informatiebarrières - (.. /compliance/information-barriers.md)

Activiteitenlogboeken

Microsoft 365 heeft een geïntegreerd auditlogboek. Het is een zeer gedetailleerd logboek, maar lees niet te veel in de naam. Het bevat mogelijk niet alles wat u wilt of nodig hebt voor uw beveiligings- en nalevingsbehoeften. Ook zijn sommige klanten erg geïnteresseerd in Audit (Premium).

Voorbeelden van Microsoft 365-logboeken die worden geopend via andere API's, zijn de volgende functies:

Het is belangrijk om eerst alle logboekbronnen te identificeren die nodig zijn voor een beveiligings- en nalevingsprogramma. Houd er ook rekening mee dat verschillende logboeken verschillende on-line bewaarlimieten hebben.

Vanuit het perspectief van beheerdersdelegering hebben de meeste Microsoft 365-activiteitenlogboeken geen ingebouwd RBAC-model. Als u gemachtigd bent om een logboek te zien, kunt u alles in het logboek zien. Een veelvoorkomend voorbeeld van een klantvereiste is: 'Ik wil alleen een query kunnen uitvoeren op activiteiten voor EU-gebruikers' (of een andere dimensie). Om aan deze vereiste te voldoen, moeten we logboeken overdragen naar een andere service. In de Microsoft-cloud raden we u aan deze over te dragen naar Microsoft Sentinel of Log Analytics.

Diagram op hoog niveau:

diagram van logboekbronnen voor een beveiligings- en nalevingsprogramma.

Het diagram bevat ingebouwde mogelijkheden voor het verzenden van logboeken naar Event Hubs en/of Azure Storage en/of Azure Log Analytics. Nog niet alle systemen bevatten deze out-of-the-box. Er zijn echter andere methoden om deze logboeken naar dezelfde opslagplaats te verzenden. Zie Bijvoorbeeld Uw Teams beveiligen met Microsoft Sentinel.

Het combineren van alle logboeken in één opslaglocatie biedt extra voordelen, zoals kruiscorrelaties, aangepaste bewaartijden, uitbreiding met gegevens die nodig zijn om het RBAC-model te ondersteunen, enzovoort. Zodra gegevens zich in dit opslagsysteem bevinden, kunt u een Power BI-dashboard (of een ander type visualisatie) maken met een geschikt RBAC-model.

Logboeken hoeven niet naar slechts één locatie te worden omgeleid. Het kan ook handig zijn om Microsoft 365-logboeken te integreren met Microsoft Defender for Cloud Apps of een aangepast RBAC-model in Power BI. Verschillende opslagplaatsen hebben verschillende voordelen en doelgroepen.

Het is vermeldenswaardig dat er een uitgebreid ingebouwd analysesysteem is voor beveiliging, bedreigingen, beveiligingsproblemen, enzovoort in een service met de naam Microsoft Defender XDR.

Veel grote klanten willen deze logboekgegevens overdragen naar een systeem van derden (bijvoorbeeld SIEM). Er zijn verschillende benaderingen voor dit resultaat, maar over het algemeen zijn Azure Event Hubs en Graph goede uitgangspunten.

Azure

Ik word vaak gevraagd of er een manier is om rollen met hoge bevoegdheden te scheiden tussen Microsoft Entra ID, Azure en SaaS (bijvoorbeeld: Globale beheerder voor Microsoft 365, maar niet azure). Niet echt. Architectuur met meerdere tenants is nodig als volledige beheerscheiding is vereist, maar dat voegt aanzienlijke complexiteit toe (zoals eerder besproken). Al deze services maken deel uit van dezelfde beveiligings-/identiteitsgrens (zoals wordt weergegeven in het hiërarchiemodel).

Het is belangrijk om de relaties tussen verschillende services in dezelfde tenant te begrijpen. Ik werk samen met veel klanten die zakelijke oplossingen bouwen voor Azure, Microsoft 365 en Power Platform (en vaak ook on-premises en cloudservices van derden). Een veelvoorkomend voorbeeld:

  1. Ik wil samenwerken aan een set documenten/afbeeldingen/enzovoort (Microsoft 365)
  2. Elk van hen verzenden via een goedkeuringsproces (Power Platform)
  3. Nadat alle onderdelen zijn goedgekeurd, kunt u deze items samenvoegen tot een of meer geïntegreerde producten (Azure) Microsoft Graph API hier uw beste vriend is. Niet onmogelijk, maar aanzienlijk complexer om een oplossing te ontwerpen die meerdere tenants overspant.

Azure Role-Based Access Control (RBAC) maakt fijnmazig toegangsbeheer voor Azure mogelijk. Met RBAC kunt u de toegang tot resources beheren door gebruikers de minste machtigingen te geven die nodig zijn om hun taken uit te voeren. Details vallen buiten het bereik van dit document, maar zie Wat is op rollen gebaseerd toegangsbeheer (RBAC) in Azure ? voor meer informatie over RBAC. RBAC is belangrijk, maar slechts een deel van de governanceoverwegingen voor Azure. Cloud Adoption Framework is een goed uitgangspunt voor meer informatie. Ik vind het leuk hoe mijn vriend, Andres Ravinet, klanten stap voor stap door verschillende onderdelen leidt om te beslissen over de aanpak. Weergave op hoog niveau voor verschillende elementen (niet zo goed als het proces om tot het werkelijke klantmodel te komen) is ongeveer als volgt:

Weergave op hoog niveau van Azure-onderdelen voor gedelegeerd beheer.

Zoals u kunt zien in de bovenstaande afbeelding, moeten veel andere services worden beschouwd als onderdeel van het ontwerp (bijvoorbeeld Azure-beleid, Azure Blueprints, beheergroepen, enzovoort).

Conclusie

Dit artikel begon als een korte samenvatting, eindigde langer dan ik had verwacht. Ik hoop dat u nu klaar bent om het delegatiemodel voor uw organisatie te maken. Dit gesprek is heel gebruikelijk bij klanten. Er is geen enkel model dat voor iedereen werkt. Wacht op een paar geplande verbeteringen van Microsoft-engineering voordat u algemene patronen documenteert die we bij klanten zien. In de tussentijd kunt u met uw Microsoft-accountteam een bezoek aan het dichtstbijzijnde Microsoft Technology Center regelen. Tot ziens!