Till identitet och bortom – en arkitekts synvinkel

  • Artikel

I den här artikeln diskuterar Alex Shteynberg, teknisk huvudarkitekt på Microsoft, de främsta designstrategierna för företag som inför Microsoft 365 och andra Microsoft-molntjänster.

Om författaren

Alex Shteynberg foto.

Jag är teknisk arkitekt på Microsoft Technology Center i New York. Jag arbetar främst med stora kunder och komplexa krav. Mina synpunkter och åsikter baseras på dessa interaktioner och kanske inte gäller för alla situationer. Men om vi kan hjälpa kunder med de mest komplexa utmaningarna kan vi hjälpa alla kunder.

Jag arbetar vanligtvis med över 100 kunder varje år. Även om varje organisation har unika egenskaper är det intressant att se trender och likheter. En trend är till exempel branschöverskridande intresse för många kunder. En bankavdelning kan trots allt också vara ett kafé och ett samhällscenter.

I min roll fokuserar jag på att hjälpa kunderna att komma fram till den bästa tekniska lösningen för att uppfylla sina unika affärsmål. Officiellt fokuserar jag på identitet, säkerhet, sekretess och efterlevnad. Jag älskar det faktum att dessa rör allt vi gör. Det ger mig en möjlighet att delta i de flesta projekt. Den här aktiviteten håller mig upptagen och njuter av den här rollen.

Jag bor i New York City (det bästa!) och njuter verkligen av mångfalden i dess kultur, mat och människor (inte trafik). Jag älskar att resa när jag kan och hoppas att se större delen av världen i min livstid. Jag undersöker för närvarande en resa till Afrika för att lära mig om vilda djur.

Riktlinjer

  • Enkelt är ofta bättre: Du kan göra (nästan) vad som helst med teknik, men det betyder inte att du borde. Särskilt på säkerhetsområdet överdriver många kunder lösningar. Jag gillar den här videon från Googles Stripe-konferens för att understryka denna punkt.
  • Personer, process, teknik: Design för människor att förbättra processen, inte teknik först. Det finns inga "perfekta" lösningar. Vi måste balansera olika riskfaktorer och beslut som kan vara olika för varje företag. För många kunder utformar en metod som användarna senare undviker.
  • Fokusera på "varför" först och "hur" senare: Var den irriterande 7-yr gamla ungen med en miljon frågor. Vi kan inte komma fram till rätt svar om vi inte vet rätt frågor att ställa. Många kunder gör antaganden om hur saker och ting behöver fungera i stället för att definiera affärsproblemet. Det finns alltid flera sökvägar som kan tas.
  • Lång svans av tidigare metodtips: Se att metodtipsen ändras med lätt hastighet. Om du tittade på Microsoft Entra för mer än tre månader sedan är du förmodligen inaktuell. Allt här kan komma att ändras efter publiceringen. "Bästa" alternativet idag kanske inte är samma sex månader från och med nu.

Grundläggande begrepp

Hoppa inte över det här avsnittet. Jag tycker ofta att jag måste gå tillbaka till dessa artiklar, även för kunder som har använt molntjänster i flera år. Tyvärr är språket inte ett exakt verktyg. Vi använder ofta samma ord för att betyda olika begrepp eller olika ord för att betyda samma begrepp. Jag använder ofta följande diagram för att etablera viss baslinjeterminologi och "hierarkimodell".

Bild av klientorganisation, prenumeration, tjänst och data.

När du lär dig att simma är det bättre att börja i poolen och inte mitt i havet. Jag försöker inte vara tekniskt korrekt med det här diagrammet. Det är en modell för att diskutera några grundläggande begrepp.

I diagrammet:

  • Klientorganisation = en instans av Microsoft Entra ID. Den är "överst" i en hierarki eller nivå 1 i diagrammet. Vi kan betrakta den här nivån som "gränsen" där allt annat sker (Microsoft Entra B2B åt sidan). Alla Microsoft Enterprise-molntjänster ingår i en av dessa klientorganisationer. Konsumenttjänster är separata. "Klient" visas i dokumentationen som Microsoft 365-klientorganisation, Azure-klientorganisation, WVD-klient och så vidare. Jag tycker ofta att dessa variationer orsakar förvirring för kunderna.
  • Tjänster/prenumerationer, nivå 2 i diagrammet, tillhör en och endast en klientorganisation. De flesta SaaS-tjänster är 1:1 och kan inte flyttas utan migrering. Azure skiljer sig åt. Du kan flytta fakturering och/eller en prenumeration till en annan klientorganisation. Det finns många kunder som behöver flytta Azure-prenumerationer. Det här scenariot har olika konsekvenser. Objekt som finns utanför prenumerationen flyttas inte. Till exempel rollbaserad åtkomstkontroll (Azure RBAC), Microsoft Entra-objekt (grupper, appar, principer osv.) och vissa tjänster (Azure Key Vault, Data Bricks osv.). Migrera inte tjänster utan ett bra affärsbehov. Vissa skript som kan vara användbara för migrering delas på GitHub.
  • En viss tjänst har vanligtvis någon form av "undernivågräns" eller nivå 3 (L3). Den här gränsen är användbar för att förstå uppdelningen av säkerhet, principer, styrning och så vidare. Tyvärr finns det inget enhetligt namn som jag känner till. Några exempelnamn för L3 är: Azure Subscription = resource; Dynamics 365 CE = instans; Power BI = arbetsyta; Power Apps = miljö; och så vidare.
  • Nivå 4 är där de faktiska data finns. Det här "dataplanet" är en komplex artikel. Vissa tjänster använder Microsoft Entra ID för RBAC, andra inte. Jag ska diskutera det lite när vi kommer till delegeringsartiklar.

Några andra begrepp som jag tycker att många kunder (och Microsoft-anställda) är förvirrade över eller har frågor om inkluderar följande problem:

  • Vem som helst kan skapa många klienter utan kostnad. Du behöver inte ha någon etablerad tjänst i den. Jag har dussintals. Varje klientnamn är unikt i Microsofts globala molntjänst (med andra ord kan inga två klienter ha samma namn). De är alla i formatet TenantName.onmicrosoft.com. Det finns också processer som skapar klienter automatiskt (ohanterade klientorganisationer). Det här resultatet kan till exempel inträffa när en användare registrerar sig för en företagstjänst med en e-postdomän som inte finns i någon annan klientorganisation.
  • I en hanterad klientorganisation kan många DNS-domäner registreras i den. Det här resultatet ändrar inte det ursprungliga klientnamnet. Det finns för närvarande inget enkelt sätt att byta namn på en klientorganisation (förutom migrering). Även om klientorganisationens namn tekniskt sett inte är kritiskt i dag kan vissa personer känna sig begränsade av den här verkligheten.
  • Du bör reservera ett klientnamn för din organisation även om du ännu inte planerar att distribuera några tjänster. Annars kan någon ta det från dig och det finns ingen enkel process för att ta tillbaka det (samma problem som DNS-namn). Jag hör det här sättet alltför ofta från kunder. Vad ditt klientnamn ska vara är också en debattartikel.
  • Om du äger DNS-namnområdet bör du lägga till alla dessa namnområden i dina klienter. Annars kan man skapa en ohanterad klientorganisation med det här namnet, vilket sedan orsakar störningar för att göra den hanterad.
  • Ett DNS-namnområde (till exempel contoso.com) kan tillhöra en och endast en klientorganisation. Det här kravet påverkar olika scenarier (till exempel delning av en e-postdomän under en sammanslagning eller ett förvärv osv.). Det finns ett sätt att registrera en DNS-underordnad (till exempel div.contoso.com) i en annan klientorganisation, men det bör undvikas. Genom att registrera ett domännamn på den översta nivån antas alla underdomäner tillhöra samma klientorganisation. I scenarier med flera klientorganisationer (enligt beskrivningen nedan) rekommenderar jag normalt att du använder ett annat domännamn på toppnivå (till exempel contoso.ch eller ch-contoso.com).
  • Vem ska "äga" en klientorganisation? Jag ser ofta kunder som inte vet vem som för närvarande äger deras klientorganisation. Denna brist på kunskap är en betydande röd flagga. Kontakta Microsoft Support ASAP. Lika problematiskt är när en tjänstägare (ofta en Exchange-administratör) har utsetts att hantera en klientorganisation. Klientorganisationen innehåller alla tjänster som du kanske vill ha i framtiden. Innehavarägaren ska vara en grupp som kan fatta beslut om aktivering av alla molntjänster i en organisation. Ett annat problem är när en klientorganisationsägargrupp uppmanas att hantera alla tjänster. Den här metoden skalas inte för stora organisationer.
  • Det finns inget koncept för en under-/superklientorganisation. Av någon anledning upprepar sig denna myt hela tiden. Det här konceptet gäller även för Azure Active Directory B2C-klientorganisationer . Jag hör för många gånger, "Min B2C-miljö finns i min XYZ-klientorganisation" eller "Hur gör jag för att flytta min Azure-klient till min Microsoft 365-klient?"
  • Det här dokumentet fokuserar främst på det kommersiella molnet över hela världen, eftersom det är vad de flesta kunder använder. Ibland är det bra att känna till nationella moln. Nationella moln har andra konsekvenser att diskutera som ligger utanför omfånget för den här diskussionen.

Baslinjeidentitetsartiklar

Det finns mycket dokumentation om Microsofts identitetsplattform – Microsoft Entra ID. För människor som precis har börjat känns det ofta överväldigande. Även när du har lärt dig om det kan det vara svårt att hålla jämna steg med ständig innovation och förändring. I mina kundinteraktioner finner jag mig ofta fungera som "översättare" mellan affärsmål och "Bra, bättre, bästa" metoder för att ta itu med dessa problem (och mänskliga "cliff notes" för dessa artiklar). Det finns sällan ett perfekt svar och "rätt" beslut är en balans mellan olika riskfaktorer. Härnäst är några av de vanliga frågor och förvirringsområden som jag tenderar att diskutera med kunder.

Etableringen

Microsoft Entra ID löser inte på grund av bristande styrning i din identitetsvärld! Identitetsstyrning bör vara ett kritiskt element oberoende av eventuella molnbeslut. Styrningskraven ändras med tiden, vilket är anledningen till att det är ett program och inte ett verktyg.

Microsoft Entra Connect jämfört med Microsoft Identity Manager (MIM) jämfört med något annat (tredje part eller anpassad)? Spara problem nu och i framtiden och gå med Microsoft Entra Connect. Det finns alla typer av smarta lösningar i det här verktyget för att hantera märkliga kundkonfigurationer och pågående innovationer.

Vissa gränsfall som kan drivas mot en mer komplex arkitektur:

  • Jag har flera AD-skogar utan nätverksanslutning mellan dem. Det finns ett nytt alternativ med namnet Cloud Provisioning.
  • Jag har inte Active Directory, och jag vill inte heller installera det. Microsoft Entra Connect kan konfigureras för synkronisering från LDAP (partner kan krävas).
  • Jag måste etablera samma objekt till flera klienter. Det här scenariot stöds inte tekniskt men beror på definitionen av "samma".

Ska jag anpassa standardsynkroniseringsregler (filterobjekt, ändringsattribut, alternativt inloggnings-ID och så vidare)? Undvik det! En identitetsplattform är bara lika värdefull som de tjänster som använder den. Du kan göra alla typer av nötkonfigurationer, men för att besvara den här frågan måste du titta på effekten på program. Om du filtrerar e-postaktiverade objekt är GAL för onlinetjänster ofullständig. Om programmet förlitar sig på specifika attribut har filtrering på dessa attribut oförutsägbara effekter och så vidare. Det är inte ett identitetsteamsbeslut.

XYZ SaaS stöder JIT-etablering (Just-in-Time), varför kräver du att jag synkroniserar? Se föregående stycke. Många program behöver "profilinformation" för funktioner. Du kan inte ha en GAL om alla e-postaktiverade objekt inte är tillgängliga. Samma sak gäller för användaretablering i program som är integrerade med Microsoft Entra ID.

Autentisering

Synkronisering av lösenordshash (PHS) jämfört med direktautentisering (PTA) jämfört med federation.

Vanligtvis är det en passionerad debatt kring federation. Enklare är vanligtvis bättre och därför använder PHS om du inte har en bra anledning att inte göra det. Det går också att konfigurera olika autentiseringsmetoder för olika DNS-domäner i samma klientorganisation.

Vissa kunder aktiverar federation + PHS främst för:

Jag vägleder ofta kunder genom flödet för klientautentisering för att klargöra vissa missuppfattningar. Resultatet ser ut som följande bild, som inte är lika bra som den interaktiva processen för att komma dit.

Exempel på whiteboard-konversation.

Den här typen av whiteboard-ritning visar var säkerhetsprinciper tillämpas i flödet för en autentiseringsbegäran. I det här exemplet tillämpas principer som tillämpas via Active Directory Federation Service (AD FS) på den första tjänstbegäran, men inte efterföljande tjänstbegäranden. Det här beteendet är minst en anledning till att flytta säkerhetskontroller till molnet så mycket som möjligt.

Vi har jagat drömmen om enkel inloggning (SSO) så länge jag kan minnas. Vissa kunder tror att de kan uppnå enkel inloggning genom att välja "rätt" federationsprovider (STS). Microsoft Entra ID kan bidra avsevärt till att möjliggöra SSO-funktioner, men ingen STS är magisk. Det finns för många "äldre" autentiseringsmetoder som fortfarande används för kritiska program. Att utöka Microsoft Entra ID med partnerlösningar kan hantera många av dessa scenarier. Enkel inloggning är en strategi och en resa. Du kan inte komma dit utan att gå mot standarder för program. Relaterad till den här artikeln är en resa till lösenordslös autentisering, som inte heller har ett magiskt svar.

Multifaktorautentisering (MFA) är viktigt idag (här för mer). Lägg till analys av användarbeteende och du har en lösning som förhindrar de vanligaste cyberattackerna. Även konsumenttjänster flyttar för att kräva MFA. Ändå träffar jag fortfarande många kunder som inte vill övergå till moderna autentiseringsmetoder . Det största argumentet jag hör är att det påverkar användare och äldre program. Ibland kan en bra kick hjälpa kunderna att gå vidare – Exchange Online tillkännagivna ändringarna. Många Microsoft Entra rapporter är nu tillgängliga för att hjälpa kunder med den här övergången.

Tillstånd

Enligt Wikipedia är "att auktorisera" att definiera en åtkomstprincip. Många ser det som möjligheten att definiera åtkomstkontroller till ett objekt (fil, tjänst och så vidare). I den aktuella världen av cyberhot utvecklas det här konceptet snabbt till en dynamisk policy som kan reagera på olika hotvektorer och snabbt justera åtkomstkontroller som svar på dem. Om jag till exempel kommer åt mitt bankkonto från en ovanlig plats får jag extra bekräftelsesteg. För att hantera den här verkligheten måste vi inte bara ta hänsyn till själva policyn utan även ekosystemet för metoder för hotidentifiering och signalkorrelation.

Principmotorn för Microsoft Entra ID implementeras med hjälp av principer för villkorsstyrd åtkomst. Det här systemet är beroende av information från andra hotidentifieringssystem för att fatta dynamiska beslut. En enkel vy skulle likna följande bild:

Principmotor i Microsoft Entra ID.

Genom att kombinera alla dessa signaler tillsammans kan du använda dynamiska principer som dessa:

  • Om ett hot identifieras på enheten begränsas din åtkomst till data till webben endast utan möjlighet att ladda ned.
  • Om du laddar ned en ovanligt stor mängd data krypteras och begränsas allt du laddar ned.
  • Om du får åtkomst till en tjänst från en ohanterad enhet blockeras du från mycket känsliga data men får åtkomst till icke-begränsad data utan möjlighet att kopiera den till en annan plats.

Om du håller med om den här utökade definitionen av auktorisering måste du implementera ytterligare lösningar. Vilka lösningar du implementerar beror på hur dynamisk du vill att principen ska vara och vilka hot du vill prioritera. Några exempel på sådana system är:

Förutom Microsoft Entra ID har olika tjänster och program sina egna specifika auktoriseringsmodeller. Några av dessa modeller beskrivs senare i delegeringsavsnittet.

Granskning

Microsoft Entra ID har detaljerade gransknings- och rapporteringsfunktioner. Dessa rapporter är dock vanligtvis inte den enda informationskällan som behövs för att fatta säkerhetsbeslut. Mer information om det här ämnet finns i delegeringsavsnittet.

Det finns inget utbyte

Få inte panik! Exchange är inte inaktuellt (eller SharePoint och så vidare). Det är fortfarande en kärntjänst. Vad jag menar är att teknikleverantörer under ganska lång tid nu har övergått till användarupplevelser (UX) för att omfatta komponenter i flera tjänster. I Microsoft 365 är ett enkelt exempel "moderna bifogade filer" där bilagor till e-post lagras i SharePoint Online eller OneDrive.

Koppla en fil till ett e-postmeddelande.

När du tittar på Outlook-klienten kan du se många tjänster som är "anslutna" som en del av den här upplevelsen, inte bara Exchange. Exempel är Microsoft Entra ID, Microsoft Search, Appar, Profil, efterlevnad och Microsoft 365-grupper.

Outlook-gränssnitt med pratbubblar.

Läs mer om Microsoft Fluid Framework för förhandsversion av kommande funktioner. I förhandsversionen nu kan jag läsa och svara på Teams-konversationer direkt i Outlook. Faktum är att Teams-klienten är ett av de mer framträdande exemplen på den här strategin.

Sammantaget blir det svårare att dra en tydlig linje mellan Microsoft 365 och andra tjänster i Microsoft-moln. Jag ser det som en stor fördel för kunderna eftersom de kan dra nytta av total innovation i allt vi gör även om de använder en komponent. Ganska cool och har långtgående konsekvenser för många kunder.

Idag tycker jag att många kund-IT-grupper är strukturerade kring "produkter". Det är logiskt för en lokal värld eftersom du behöver en expert för varje specifik produkt. Men jag är glad att jag inte behöver felsöka en Active Directory- eller Exchange-databas igen eftersom dessa tjänster har flyttat till molnet. Automation (som molnet i princip är) tar bort vissa repetitiva manuella jobb (se vad som hände med fabriker). Dessa uppgifter ersätts dock med mer komplexa krav för att förstå interaktion mellan tjänster, effekt, affärsbehov och så vidare. Om du är villig att lära dig finns det stora möjligheter som möjliggörs av molnomvandling. Innan jag börjar med teknik pratar jag ofta med kunder om att hantera förändringar i IT-färdigheter och teamstrukturer.

Sluta fråga "Hur kan jag göra XYZ i SharePoint Online" för alla SharePoint-användare och utvecklare? Använd Power Automate (eller Flow) för arbetsflöde, det är en mycket kraftfullare plattform. Använd Azure Bot Framework för att skapa ett bättre UX för din 500-K-objektlista. Börja använda Microsoft Graph i stället för CSOM. Microsoft Teams innehåller SharePoint men också en värld mer. Det finns många andra exempel som jag kan lista. Det finns ett stort och underbart universum där ute. Öppna dörren och börja utforska.

Den andra vanliga effekten är i efterlevnadsområdet. Den här metoden för flera tjänster verkar helt förvirra många efterlevnadsprinciper. Jag ser fortfarande organisationer som säger: "Jag måste journalföra all e-postkommunikation till ett eDiscovery-system." Vad betyder den här instruktionen egentligen när e-post inte längre bara är e-post utan ett fönster till andra tjänster? Microsoft 365 har en omfattande metod för efterlevnad, men att ändra personer och processer är ofta mycket svårare än teknik.

Det finns många andra människor och processkonsekvenser. Enligt min mening är denna faktor ett kritiskt och underdiskuterad område. Kanske mer i en annan artikel.

Alternativ för klientstruktur

Enskild klient jämfört med flera klientorganisationer

I allmänhet bör de flesta kunder bara ha en produktionsklientorganisation. Det finns många anledningar till varför flera klienter är utmanande (ge det en Bing-sökning) eller läsa det här faktabladet. Samtidigt har många företagskunder som jag arbetar med en annan (liten) klientorganisation för IT-utbildning, testning och experimentering. Azure-åtkomst mellan klientorganisationer blir enklare med Azure Lighthouse. Microsoft 365 och många andra SaaS-tjänster har gränser för scenarier mellan klienter. Det finns mycket att tänka på i Microsoft Entra B2B-scenarier.

Många kunder får flera produktionsklienter efter en sammanslagning och ett förvärv (M&A) och vill konsolidera. Idag är det inte enkelt och kräver Microsoft Consulting Services (MCS) eller en partner plus programvara från tredje part. Det finns ett pågående ingenjörsarbete för att hantera olika scenarier med kunder med flera klientorganisationer i framtiden.

Vissa kunder väljer att gå med fler än en klientorganisation. Detta bör vara ett noggrant beslut och nästan alltid affärsorsaksdriven! Några exempel är följande:

  • En företagsstruktur av holdingtyp där enkelt samarbete mellan olika entiteter inte krävs och det finns starka administrativa och andra isoleringsbehov.
  • Efter ett förvärv fattas ett affärsbeslut om att hålla två entiteter åtskilda.
  • Simulering av en kunds miljö som inte ändrar kundens produktionsmiljö.
  • Utveckling av programvara för kunder.

I dessa scenarier med flera klientorganisationer vill kunderna ofta behålla en viss konfiguration på samma sätt mellan klienter, eller rapportera om konfigurationsändringar och driftsavvikelser. Det innebär ofta att du går från manuella ändringar till konfiguration som kod. Microsoft Premiere-supporten erbjuder en workshop för dessa typer av krav baserat på den här offentliga IP-adressen: https://Microsoft365dsc.com.

Multi-Geo

Till Multi-Geo eller inte till Multi-Geo. Det är frågan. Med Microsoft 365 Multi-Geo kan du etablera och lagra vilande data på de geo-platser som du väljer för att uppfylla kraven på datahemvist . Det finns många missuppfattningar om den här funktionen. Tänk på följande:

  • Det ger inte prestandafördelar. Det kan försämra prestandan om nätverksdesignen inte är korrekt. Hämta enheter "nära" Microsoft-nätverket, inte nödvändigtvis till dina data.
  • Det är inte en lösning för GDPR-efterlevnad. GDPR fokuserar inte på datasuveränitet eller lagringsplatser. Det finns andra efterlevnadsramverk för datasuveränitet eller lagringsplatser.
  • Det löser inte delegering av administration (se nedan) eller informationsbarriärer.
  • Det är inte samma sak som flera klientorganisationer och kräver fler arbetsflöden för användaretablering .
  • Den flyttar inte din klientorganisation (din Microsoft Entra ID) till ett annat geografiskt område.

Delegering av administration

I de flesta stora organisationer är uppdelning av uppgifter och rollbaserad åtkomstkontroll (RBAC) en nödvändig verklighet. Jag ber om ursäkt i förväg. Den här aktiviteten är inte så enkel som vissa kunder vill att den ska vara. Kund-, juridik-, efterlevnads- och andra krav är olika och ibland motstridiga runt om i världen. Enkelhet och flexibilitet finns ofta på motsatta sidor av varandra. Missförstå mig inte, vi kan göra ett bättre jobb med det här målet. Det har skett (och kommer att bli) betydande förbättringar över tid. Besök ditt lokala Microsoft Technology Center för att ta reda på vilken modell som passar dina affärsbehov utan att läsa 379 230 dokument! Här fokuserar jag på vad du bör tänka på och inte varför det är så här. På gång finns fem olika områden att planera för och några av de vanliga frågor jag stöter på.

administrationscenter för Microsoft Entra ID och Microsoft 365

Det finns en lång och växande lista över inbyggda roller. Varje roll består av en lista över rollbehörigheter grupperade tillsammans så att specifika åtgärder kan utföras. Du kan se dessa behörigheter på fliken "Beskrivning" i varje roll. Du kan också se en mer läsbar version av dessa behörigheter i Microsoft 365 Admin Center. Det går inte att ändra definitionerna för inbyggda roller. I allmänhet grupperar jag dessa roller i tre kategorier:

  • Global administratör: Den här "alla kraftfulla" rollen bör skyddas mycket precis som i andra system. Vanliga rekommendationer är: ingen permanent tilldelning och användning Microsoft Entra Privileged Identity Management (PIM), stark autentisering och så vidare. Intressant nog ger den här rollen inte åtkomst till allt som standard. Vanligtvis ser jag förvirring kring åtkomst till efterlevnad och Azure-åtkomst, som diskuteras senare. Den här rollen kan dock alltid tilldela åtkomst till andra tjänster i klientorganisationen.
  • Specifika tjänstadministratörer: Vissa tjänster (Exchange, SharePoint, Power BI och så vidare) använder administrationsroller på hög nivå från Microsoft Entra ID. Det här beteendet är inte konsekvent i alla tjänster och det finns fler tjänstspecifika roller som diskuteras senare.
  • Funktion: Det finns en lång (och växande) lista över roller som fokuserar på specifika åtgärder (gäst inbjudare och så vidare). Med jämna mellanrum läggs fler av dessa roller till baserat på kundernas behov.

Det går inte att delegera allt (även om klyftan minskar), vilket innebär att den globala administratörsrollen måste användas ibland. Konfiguration som kod och automatisering bör övervägas i stället för personer som är medlemmar i den här rollen.

Obs! Administrationscenter för Microsoft 365 har ett mer användarvänligt gränssnitt men har en delmängd funktioner jämfört med Microsoft Entra administratörsupplevelse. Båda portalerna använder samma Microsoft Entra roller, så ändringar sker på samma plats. Tips: Om du vill ha ett identitetshanteringsfokuserat administratörsgränssnitt utan all Azure-oreda använder du https://aad.portal.azure.com.

Vad finns i namnet? Gör inte antaganden från namnet på rollen. Språket är inte ett exakt verktyg. Målet bör vara att definiera åtgärder som måste delegeras innan du tittar på vilka roller som behövs. Att lägga till någon i rollen "Säkerhetsläsare" gör inte att de ser säkerhetsinställningar för allt.

Möjligheten att skapa anpassade roller är en vanlig fråga. Den här funktionen är begränsad i Microsoft Entra idag (vilket förklaras senare), men kommer att växa i funktioner över tid. Jag tänker på dessa anpassade roller som tillämpliga för funktioner i Microsoft Entra ID och kanske inte sträcker sig över "nedåt" hierarkimodellen (som tidigare diskuterats). När jag hanterar "anpassad" tenderar jag att gå tillbaka till mitt huvudnamn för "enkel är bättre".

En annan vanlig fråga är möjligheten att omfångsroller till en delmängd av en katalog. Ett exempel är något i stil med "Supportadministratör endast för användare i EU". Administrativa enheter är avsedda att hantera det här scenariot. Som tidigare beskrivits tänker jag på dessa omfång som tillämpliga för funktioner i Microsoft Entra ID och kanske inte sträcker sig över "nedåt". Vissa roller är inte meningsfulla för omfånget (globala administratörer, tjänstadministratörer och så vidare).

I dag kräver alla dessa roller direkt medlemskap (eller dynamisk tilldelning om du använder Microsoft Entra PIM). Det innebär att kunder måste hantera den här rollen direkt i Microsoft Entra ID, och dessa roller kan inte baseras på ett medlemskap i en säkerhetsgrupp. Jag är inte ett fan av att skapa skript för att hantera dessa roller eftersom det skulle behöva köras med förhöjda rättigheter. Jag rekommenderar vanligtvis API-integrering med processsystem som ServiceNow eller partnerstyrningsverktyg som Saviynt. Det pågår ingenjörsarbete för att lösa det här problemet över tid.

Jag nämnde Microsoft Entra PIM några gånger. Det finns en motsvarande Microsoft Identity Manager (MIM) Privileged Access Management (PAM) lösning för lokala kontroller. Du kanske också vill titta på Arbetsstationer för privilegierad åtkomst (PAW) och Microsoft Entra ID Governance. Det finns även olika verktyg från tredje part som kan aktivera just-in-time, precis-enough och dynamisk rollhöjning. Den här funktionen är vanligtvis en del av en större diskussion för att skydda en miljö.

Ibland anropas scenarier för att lägga till en extern användare i en roll (se föregående avsnitt för flera klientorganisationer). Det här resultatet fungerar bra. Microsoft Entra B2B är en annan stor och rolig artikel att gå igenom, kanske i en annan artikel.

Microsoft Defender XDR- och Microsoft 365 Purview-efterlevnadsportaler

Email & Samarbetsroller i Microsoft Defender-portalen och *Rollgrupper för Microsoft Purview-lösningar i Microsoft 365 Purview-efterlevnadsportalen är en samling "rollgrupper" som är separata och skiljer sig från Microsoft Entra roller. Detta kan vara förvirrande eftersom vissa av dessa rollgrupper har samma namn som Microsoft Entra roller (till exempel Säkerhetsläsare), men de kan ha olika medlemskap. Jag föredrar att använda Microsoft Entra roller. Varje rollgrupp består av en eller flera "roller" (se vad jag menar med att återanvända samma ord?) och har medlemmar från Microsoft Entra ID, som är e-postaktiverade objekt. Du kan också skapa en rollgrupp med samma namn som en roll, som kanske eller kanske inte innehåller den rollen (undvik den här förvirringen).

På sätt och vis är dessa behörigheter en utveckling av exchange-modellen för rollgrupper. Men Exchange Online har ett eget gränssnitt för rollgruppshantering. Vissa rollgrupper i Exchange Online låses och hanteras från Microsoft Entra ID eller Microsoft Defender XDR- och Microsoft 365 Purview-efterlevnadsportaler, men andra kan ha samma eller liknande namn och hanteras i Exchange Online (vilket ökar förvirringen). Jag rekommenderar att du undviker att använda Exchange Online användargränssnitt om du inte behöver omfång för Exchange-hantering.

Du kan inte skapa anpassade roller. Roller definieras av tjänster som skapats av Microsoft och fortsätter att växa när nya tjänster introduceras. Det här beteendet liknar roller som definieras av program i Microsoft Entra ID. När nya tjänster aktiveras måste ofta nya rollgrupper skapas för att bevilja eller delegera åtkomst till dessa (till exempel hantering av insiderrisk.

Dessa rollgrupper kräver också direkt medlemskap och får inte innehålla Microsoft Entra grupper. Tyvärr stöds dessa rollgrupper i dag inte av Microsoft Entra PIM. Precis som Microsoft Entra roller rekommenderar jag hantering av dessa rollgrupper via API:er eller en partnerstyrningsprodukt som Saviynt eller andra.

Microsoft Defender portal- och Microsoft 365 Purview-efterlevnadsportalroller sträcker sig över Microsoft 365 och du kan inte begränsa dessa rollgrupper till en delmängd av miljön (precis som med administrativa enheter i Microsoft Entra ID). Många kunder frågar hur de kan underdeldela. Till exempel "skapa en DLP-princip endast för EU-användare". Om du idag har rättigheter till en specifik funktion i Microsoft Defender XDR och Microsoft 365 Purview-efterlevnadsportaler har du rättigheter till allt som omfattas av den här funktionen i klientorganisationen. Många principer har dock funktioner för att rikta in sig på en delmängd av miljön (till exempel "gör dessa etiketter tillgängliga endast för dessa användare"). Korrekt styrning och kommunikation är en viktig komponent för att undvika konflikter. Vissa kunder väljer att implementera en "konfiguration som kod"-metod för att hantera underdelegering i Microsoft Defender XDR- och Microsoft 365 Purview-efterlevnadsportalerna. Vissa specifika tjänster stöder underdelegation (se nästa avsnitt).

Tjänstspecifik

Som tidigare nämnts vill många kunder uppnå en mer detaljerad delegeringsmodell. Ett vanligt exempel: "Hantera XYZ-tjänsten endast för Division X-användare och platser" (eller någon annan dimension). Möjligheten att göra detta beror på varje tjänst och är inte konsekvent mellan tjänster och funktioner. Dessutom kan varje tjänst ha en separat och unik RBAC-modell. I stället för att diskutera alla dessa modeller (vilket skulle ta för alltid) lägger jag till relevanta länkar för varje tjänst. Den här listan är inte fullständig, men du kan komma igång.

  • Exchange Online – (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online – (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams – (/microsoftteams/itadmin-readiness)
  • eDiscovery – (.. /compliance/index.yml)
    • Behörighetsfiltrering – (.. /compliance/index.yml)
    • Efterlevnadsgränser – (.. /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/)

Obs!

Den här länken är till roten för dokumentationen. Det finns flera typer av tjänster med variationer i administratörs-/delegeringsmodellen.

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

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

      Obs!

      det finns flera typer med variationer i administratörs-/delegeringsmodellerna.

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

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

      Obs! Dataplattformens säkerhet och delegering (som Power BI är en komponent) är ett komplext område.

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

  • Microsoft Defender för Endpoint – (/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)

  • Informationsbarriärer – (.. /compliance/information-barriers.md)

Aktivitetsloggar

Microsoft 365 har en enhetlig granskningslogg. Det är en mycket detaljerad logg, men läs inte in för mycket i namnet. Den kanske inte innehåller allt du vill ha eller behöver för dina säkerhets- och efterlevnadsbehov. Vissa kunder är också mycket intresserade av Granskning (Premium)..

Exempel på Microsoft 365-loggar som nås via andra API:er är följande funktioner:

Det är viktigt att först identifiera alla loggkällor som behövs för ett säkerhets- och efterlevnadsprogram. Observera också att olika loggar har olika begränsningar för on-line-kvarhållning.

Från administratörsdelegeringsperspektivet har de flesta Microsoft 365-aktivitetsloggar inte någon inbyggd RBAC-modell. Om du har behörighet att se en logg kan du se allt i den. Ett vanligt exempel på ett kundkrav är: "Jag vill bara kunna fråga efter aktivitet för EU-användare" (eller någon annan dimension). För att uppnå det här kravet måste vi överföra loggar till en annan tjänst. I Microsoft-molnet rekommenderar vi att du överför den till antingen Microsoft Sentinel eller Log Analytics.

Diagram på hög nivå:

diagram över loggkällor för ett säkerhets- och efterlevnadsprogram.

Diagrammet representerar inbyggda funktioner för att skicka loggar till Event Hubs och/eller Azure Storage och/eller Azure Log Analytics. Alla system har inte den här färdiga metoden ännu. Men det finns andra sätt att skicka loggarna till samma lagringsplats. Se till exempel Skydda dina Teams med Microsoft Sentinel.

Om du kombinerar alla loggar till en lagringsplats ingår ytterligare fördelar, till exempel korskorrelationer, anpassade kvarhållningstider, förhöjda data som behövs för att stödja RBAC-modellen och så vidare. När data finns i det här lagringssystemet kan du skapa en Power BI-instrumentpanel (eller en annan typ av visualisering) med en lämplig RBAC-modell.

Loggar behöver inte dirigeras till en enda plats. Det kan också vara bra att integrera Microsoft 365-loggar med Microsoft Defender for Cloud Apps eller en anpassad RBAC-modell i Power BI. Olika lagringsplatser har olika fördelar och målgrupper.

Det är värt att nämna att det finns ett omfattande inbyggt analyssystem för säkerhet, hot, sårbarheter och så vidare i en tjänst som heter Microsoft Defender XDR.

Många stora kunder vill överföra loggdata till ett system från tredje part (till exempel SIEM). Det finns olika metoder för det här resultatet, men i allmänhet är Azure Event Hubs och Graph bra utgångspunkter.

Azure

Jag får ofta frågan om det finns ett sätt att separera roller med hög behörighet mellan Microsoft Entra ID, Azure och SaaS (t.ex. global administratör för Microsoft 365 men inte Azure). Inte riktigt. Arkitektur för flera klientorganisationer krävs om fullständig administrativ separation krävs, men det ger betydande komplexitet (som vi nämnde tidigare). Alla dessa tjänster ingår i samma säkerhets-/identitetsgräns (som visas i hierarkimodellen).

Det är viktigt att förstå relationer mellan olika tjänster i samma klientorganisation. Jag arbetar med många kunder som skapar affärslösningar som omfattar Azure, Microsoft 365 och Power Platform (och ofta även lokala molntjänster och molntjänster från tredje part). Ett vanligt exempel:

  1. Jag vill samarbeta kring en uppsättning dokument/bilder/etc (Microsoft 365)
  2. Skicka var och en av dem via en godkännandeprocess (Power Platform)
  3. När alla komponenter har godkänts monterar du dessa objekt i en enhetlig slutprodukt (Azure) Microsoft Graph API är din bästa vän här. Inte omöjligt, men betydligt mer komplext att utforma en lösning som sträcker sig över flera klienter.

Azure Role-Based Access Control (RBAC) möjliggör detaljerad åtkomsthantering för Azure. Med hjälp av RBAC kan du hantera åtkomst till resurser genom att ge användarna de minsta behörigheter som krävs för att utföra sina jobb. Information ligger utanför omfånget för det här dokumentet, men mer information om RBAC finns i Vad är rollbaserad åtkomstkontroll (RBAC) i Azure? RBAC är viktigt men bara en del av styrningsövervägandena för Azure. Cloud Adoption Framework är en bra utgångspunkt för att lära dig mer. Jag gillar hur min vän , Andres Ravinet, vägleder kunderna steg för steg genom olika komponenter för att bestämma sig för tillvägagångssättet. Vyn på hög nivå för olika element (inte lika bra som processen för att komma till den faktiska kundmodellen) är ungefär så här:

Översikt över Azure-komponenter för delegerad administration.

Som du ser i bilden ovan bör många andra tjänster betraktas som en del av designen (till exempel Azure-principer, Azure-skisser, hanteringsgrupper och så vidare).

Sammanfattning

Den här artikeln började som en kort sammanfattning, hamnade längre än jag förväntade mig. Jag hoppas att du nu är redo att ge dig in i en djup inblick i hur du skapar en delegeringsmodell för din organisation. Den här konversationen är mycket vanlig med kunder. Det finns ingen modell som fungerar för alla. Väntar på några planerade förbättringar från Microsofts teknikteknik innan vi dokumenterar vanliga mönster som vi ser mellan kunder. Under tiden kan du arbeta med ditt Microsoft-kontoteam för att ordna ett besök på närmaste Microsoft Technology Center. Vi ses där!