För identitet och vidarestöld – en arkitekts byggnad

  • Artikel
  • 13 minuter för att läsa

I den här artikeln beskriver Alex Shteynberg, Principal Technical Architect 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 principal Technical Architect på Microsoft Technology Center i NewYork. Jag arbetar oftast med stora kunder och komplexa krav. Min familj och mina åsikter baseras på dessa interaktioner och gäller kanske inte i alla situationer. Men om vi kan hjälpa kunder med de mest komplexa utmaningarna kan vi hjälpa alla kunder.

Jag arbetar normalt med fler än 100 kunder per år. Varje organisation har unika egenskaper, men det är intressant att se trender och vanliga behov. En trend är till exempel branschledande intresse för många kunder. En bankkontor kan ju också vara ett café och ett community center.

I min roll fokuserar jag på att hjälpa kunder att ta fram den bästa tekniska lösningen för att hantera sina unika affärsmål. Officiellt fokuserar jag på identitet, säkerhet, sekretess och efterlevnad. Jag gillar att dessa rör vid allt vi gör. Det ger mig möjlighet att vara engagerad i de flesta projekt. Det håller mig upptagen och gillar den här rollen.

Jag bor i New York (den bästa!) och tycker om dess kultur, mat och människor (inte trafik). Jag älskar att resa när jag kan och hoppas att se det mesta av världen under min livslängd. Jag för närvarande efterforskningar en resa till Afrika för att lära mig mer om djurliv.

Vägledande principer

  • Enkelt är ofta bättre: Du kan göra (nästan) allt med teknik, men det betyder inte att du ska göra det. Särskilt när det gäller säkerhetsutrymmet måste många kunder ha överengineer-lösningar. Jag gillar den här videon från Googles Stripe-konferens till att understryka det här.
  • Personer, processer, teknik: Design för att förbättra processen, inte tech först. Det finns inga "perfekta" lösningar. Vi behöver balansera olika riskfaktorer och beslut kommer att vara olika för varje företag. För många kunder utformar en metod som deras användare senare undviker.
  • Fokusera på "varför" först och "hur" senare: Var den irriterande 7-åring som har en miljon frågor. Vi kan inte få fram rätt svar om vi inte känner till rätt frågor att ställa. Många kunder gör antaganden om hur det måste fungera i stället för att definiera affärsproblemet. Det finns alltid flera sökvägar som kan användas.
  • Long tail of past best practices: Recognize that best practices are changing at light speed. Om du har tittat på Azure AD för mer än tre månader sedan är du förmodligen in gammal. Allt här kan komma att ändras efter publicering. Alternativet "Bäst" idag kanske inte är samma för sex månader från och med nu.

Grundbegrepp

Hoppa inte över det här avsnittet. Jag tycker ofta att jag måste gå tillbaka till de här avsnitten, även för kunder som har använt molntjänster i många år. Språket är tyvärr inte ett exakt verktyg. Vi använder ofta samma ord för att betyda olika begrepp eller olika ord för att betyda samma koncept. Jag använder ofta det här diagrammet nedan för att fastställa viss baslinjeterminologi och "hierarkimodell".

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


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

I diagrammet:

  • Klientorganisation = en instans av Azure AD. Den är högst upp i en hierarki eller på Nivå 1 i diagrammet. Vi kan betrakta det somden" gräns " där allt annat förekommer(undan Azure AD B2B). Alla Microsofts molntjänster för företag ingår i någon av dessa klientorganisationar. Konsumenttjänsterna är separata. "Klient" visas i dokumentationen Office 365, Azure-klientorganisation, WVD-klientorganisation och så vidare. Jag tycker ofta att de här varianterna är förvirrande för kunderna.
  • Tjänster/prenumerationer, nivå 2 i diagrammet, tillhör en och bara en klientorganisation. De flesta SaaS-tjänster är 1:1 och kan inte flytta utan migrering. Azure är annorlunda, 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 har sina olika konsekvenser. Objekt som finns utanför prenumerationen flyttas inte (till exempel rollbaserad åtkomstkontroll eller Azure RBAC och Azure AD-objekt, inklusive grupper, appar, principer och så vidare). Dessutom en del tjänster (till exempel Azure Key Vault, Data Bricks och så vidare). Migrera inte tjänster utan att ha behov av bra affärer. Vissa skript som kan vara användbara för migreringen delas på GitHub.
  • En viss tjänst har vanligtvis någon typ av "undernivågräns" eller Nivå 3 (L3). Det är användbart för att separering av säkerhet, policyer, styrning och så vidare. Tyvärr finns det inget enhetligt namn som jag känner till. Namnen på L3 är till exempel: Azure-prenumeration = resurs; Dynamics 365 CE = instans; Power BI = arbetsyta; Power Apps = miljöoch så vidare.
  • På nivå 4 finns de verkliga data. Det här "dataplan" är ett komplext ämne. Vissa tjänster använder Azure AD för RBAC, andra använder inte tjänsten. Jag ska diskutera det lite när vi kommer till delegeringsavsnitt.

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

  • Alla kan skapa flera klientorganisationar utan kostnad. Du behöver inte tillhandahålla en tjänst i den. Jag har många. Varje klientorganisations namn är unikt i Microsofts globala molntjänst (med andra ord kan inte två klientorganisationar ha samma namn). Alla är i samma format som TenantName.onmicrosoft.com. Det finns även processer som skapar klientorganisation automatiskt(ohanterade klientorganisationar). Det här 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. Detta ä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 innehavarnamnet tekniskt sett inte är kritiskt i dessa dagar kan vissa se det som begränsat.
  • Du bör reservera ett klientnamn för organisationen ä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 den (samma problem som DNS-namn). Jag hör det här sättet för ofta från kunder. Namnet på din innehavare bör vara en ämnesartikel.
  • Om du har DNS-namnområden ska du lägga till alla dessa i klientorganisationen. Annars kan en ohanterad klientorganisation med det här namnet skapa störningar, vilket skulle kunna göra att den hanteras.
  • DNS-namnområde (till exempel contoso.com) kan tillhöra en och endast en klientorganisation. Detta har sina konsekvenser för olika scenarier (t.ex. delning av en e-postdomän vid samgående eller förvärv och så vidare). Det finns ett sätt att registrera en DNS-under (till exempel div.contoso.com) i en annan klientorganisation, men det bör undvikas. Genom att registrera ett toppnivådomännamn antas alla underdomäner tillhöra samma klientorganisation. I scenarier med flera innehavare (se nedan) rekommenderar jag normalt att du använder ett annat domännamn på den översta nivån (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. Det här är en stor röd flagga. Kontakta Microsoft support så fort som möjligt. Lika problematiskt är när en tjänstägare (ofta en Exchange administratör) är utsedd att hantera en klientorganisation. Klientorganisationen kommer att innehålla alla tjänster som du kanske vill använda i framtiden. Klientorganisationens ägare bör vara en grupp som kan fatta beslut om att aktivera alla molntjänster i en organisation. Ett annat problem är när en innehavarägaregrupp ombeds att hantera alla tjänster. Det här ska inte skalas för stora organisationer.
  • Det finns inget koncept för en under-/superklientorganisation. Av någon anledning upprepas den här myten hela tiden. Det här gäller även Azure AD B2C-klientorganisationen. Jag hör för många gånger "Min B2C-miljö är i min XYZ-klientorganisation" eller "Hur flyttar jag min Azure-klientorganisation till min Office 365 klient?"
  • Det här dokumentet fokuserar huvudsakligen på det kommersiella globala molnet eftersom det är det som de flesta kunder använder. Ibland kan det vara bra att känna till moln i en suverän del. Självständig moln har ytterligare konsekvenser för att diskutera vilka som inte kan diskuteras i den här diskussionen.

Grundläggande identitetsavsnitt

Det finns mycket dokumentation om Microsofts identitetsplattform – Azure Active Directory (Azure AD). För dem som precis har börjat känns det ofta överväldigande. Det kan vara svårt att hålla dig upp med konstanta innovationer och förändringar även efter att du har lärt dig mer om det. I mina kundinteraktion tycker jag ofta att jag fungerar som "översättare" mellan affärsmål och "Bra, bättre, bäst" metoder för att hantera dessa (och mänskliga "klippanteckningar" för dessa ämnen). Det finns sällan ett perfekt svar och "rätt" beslut är en balans mellan olika riskfaktorer. Nedan följer några vanliga frågor och förvirringsområden som jag brukar diskutera med kunder.

Etablering

Azure AD löser inte brist på styrning i din identitets värld! Identitetsstyrning bör vara ett viktigt element oberoende av eventuella molnbeslut. Styrningskraven ändras med tiden, vilket är anledningen till att det är ett program och inte ett verktyg.

Azure AD Anslut jämfört med Microsoft Identity Manager (MIM) jämfört med något annat (tredje part eller anpassat)? Nu och i framtiden kan du få problem med Azure AD Anslut. Det finns alla slags smartar i det här verktyget för att hantera kundkonfigurationer och kontinuerliga innovationer.

Vissa gränsfall som kan vara på väg mot en mer komplex arkitektur:

  • Jag har flera AD-skogar utan nätverksanslutning mellan dessa. Det finns ett nytt alternativ som kallas molnetablering.
  • Jag har inte Active Directory, och jag vill inte heller installera det. Azure AD Anslut kan konfigureras för synkronisering från LDAP (partner kan krävas).
  • Jag behöver etablera samma objekt för flera innehavare. Det här stöds inte tekniskt men beror på definitionen av "samma".

Ska jag anpassa standardsynkroniseringsregler(filtreraobjekt, ändra attribut, alternativa inloggnings-IDoch så vidare)? Undvik det! En identitetsplattform är lika värdefull som de tjänster som använder den. Du kan göra alla slags nyttiga konfigurationer, men för att besvara den här frågan måste du titta på hur programmen påverkas. Om du filtrerar e-postaktiverade objekt kommer gal-adress för onlinetjänster att vara ofullständig. om programmet använder specifika attribut kan filtrering av dem ha oförutsägbar effekt. och så vidare. Det är inte ett identitetsteams beslut.

XYZ SaaS har stöd för JIT-etablering (Just-in-Time), varför behöver jag synkronisera? Se ovan. Många program behöver profilinformation för funktioner. Du kan inte ha en GAL om alla e-postaktiverade objekt inte är tillgängliga. Detsamma gäller användaretablering i program som är integrerade med Azure AD.

Autentisering

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

Det finns oftast en starkt engagerade diskussioner kring federation. Enklare är oftast bättre och därför bör du använda PHS om du inte har goda skäl att inte göra det. Det går även att konfigurera olika autentiseringsmetoder för olika DNS-domäner i samma klientorganisation.

Vissa kunder aktiverar federation + PHS huvudsakligen för:

Jag vägleder ofta kunder genom kundautentiseringsflödet för att förtydliga vissa missförefattningar. Resultatet ser ut som i bilden nedan, vilket inte är lika bra som den interaktiva processen att komma dit.

Exempel på whiteboard-konversation.

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

Vi har jagat drömn om enkel inloggning (SSO) så länge jag kan komma ihåg. Vissa kunder tror att de kan uppnå detta genom att välja rätt federationsleverantör (STS). Azure AD kan hjälpa dig att avsevärt aktivera SSO-funktioner, men ingen STS är magiska. Det finns för många "äldre" autentiseringsmetoder som fortfarande används för viktiga program. Många av de scenarierna kan åtgärdas om du utökar Azure AD med partnerlösningar. SSO är en strategi och en resa. Du kan inte komma dit utan att gå över till standarder för program. Relaterat till det här avsnittet är en resa mot lösenordslös autentisering, som också inte har ett magiska svar.

Multifaktorautentisering (MFA) är nödvändigt idag(här för mer information). Lägg till användarbeteendeanalyser och du har en lösning som förhindrar de vanligaste cyberattackerna. Även konsumenttjänsterna flyttas och kräver MFA. Men jag har fortfarande ett möte med många kunder som inte vill gå över till moderna autentiseringsmetoder. Det viktigaste argumentet jag hör är att det påverkar användare och äldre program. Ibland kan en bra start hjälpa kunderna att gå vidare – om Exchange Online meddelas ändringar. Nu finns det många Azure AD-rapporter som kan hjälpa kunderna med övergången.

Auktorisering

Per Wikipedia"att auktorisera" är 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 nuvarande världen med cyberhot utvecklas det här begreppet snabbt till en dynamisk princip som kan reagera på olika hotvektorer och snabbt justera åtkomstkontroller som svar på dessa. Om jag till exempel öppnar mitt bankkonto från en ovanlig plats får jag ytterligare bekräftelsesteg. För att kunna ta hand om det behöver vi inte bara överväga själva principen utan även ekosystemet för identifiering av hot och signalrelationsmetoder.

Principmotorn i Azure AD implementeras med hjälp av villkorsstyrda åtkomstprinciper. Det här systemet är beroende av information från andra identifieringssystem för hot för att kunna fatta dynamiska beslut. En enkel vy skulle se ut ungefär så här:

Policymotorn i Azure AD.

Om du kombinerar alla dessa signaler möjliggörs dynamiska principer som dessa:

  • Om ett hot upptäcks på din enhet kommer din åtkomst till data begränsas till webben utan att du kan ladda ned den.
  • Om du laddar ned en ovanligt stor mängd data krypteras och begränsas allt du laddar ned.
  • Om du använder en tjänst från en ohanterad enhet blockeras du från mycket känsliga data men får tillgång till icke-begränsade data utan möjlighet att kopiera dem till en annan plats.

Om du godkänner den utökade auktoriseringsdefinitionen måste du implementera ytterligare lösningar. Vilka lösningar du implementerar beror på hur dynamiskt du vill att principen ska vara och vilka hot du vill prioritera. Några exempel på sådana system är:

Utöver Azure AD har naturligtvis olika tjänster och program egna specifika auktoriseringsmodeller. En del av dem tas upp senare i delegeringsavsnittet.

Granskning

Azure AD har detaljerade funktioner för granskning och rapportering. Det är dock oftast inte den enda informationskällan som behövs för att fatta säkerhetsbeslut. Mer information finns i delegeringsavsnittet.

Det finns inga Exchange

Ingen panik! Det innebär inte Exchange (eller föråldrade SharePoint och så vidare). Det är fortfarande en kärntjänst. Det jag menar är att teknikleverantörer under en längre tid har gått över användarupplevelser (UX) till att omfatta komponenter i flera tjänster. I Microsoft 365 är ett enkelt exempel "modernabifogade filer " där bifogade filer i e-postmeddelanden lagras i SharePoint Online eller OneDrive för företag.

Bifoga en fil i ett e-postmeddelande.

När du tittar på Outlook kan du se många tjänster som är "anslutna" som en del av den här upplevelsen, inte bara Exchange. Det omfattar Azure AD, Microsoft Search, appar, profil, efterlevnad och Office 365 grupper.

Outlook gränssnitt med bildtext.

Läs mer Microsoft Fluid Framework om hur du förhandsgranskar kommande funktioner. I förhandsgranskningsläge nu kan jag läsa och svara på Teams konversationer direkt i Outlook. Faktum är att Teams är ett av de mest framträdande exemplen på den här strategi.

Generellt sett blir det svårare att rita en tydlig linje mellan Office 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 den totala innovationen i allt vi gör även om de använder en komponent. Ganska coolt och har betydande 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 helt nöjd över att jag inte behöver felsöka en Active Directory- eller Exchange-databas igen när de här tjänsterna har flyttats till molnet. Automation (vilken molnlösning det är) tar bort vissa återkommande manuella jobb (se vad som har hänt med faktorn). De ersätts dock med mer komplexa krav för att förstå interaktion mellan tjänster, påverkan, affärsbehov och så vidare. Om du vill lära dig finnsdet stora möjligheter som aktiveras genom molnomvandling. Innan jag hoppar in i teknik pratar jag ofta med kunderna om att hantera förändring av IT-kunskaper och teamstrukturer.

Sluta fråga SharePoint "How can I do XYZ in SharePoint online" till alla som gillar användare och utvecklare. Det Power Automate (eller Flow) för arbetsflödet, det är en mycket mer kraftfull plattform. Använd Azure Bot Framework för att skapa en bättre UX för objektlistan på 500 K. 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 ta med. Det finns ett enormt och fantastiskt universum. Öppna dörren och börja utforska.

Andra vanliga konsekvenser ligger i efterlevnadsområdet. Den här metoden för tvärtjänster verkar totalt förvirra många efterlevnadsprinciper. Organisationer med statusen "Jag behöver journalför all e-postkommunikation till ett e-dataidentifieringssystem". Vad innebär detta egentligen när e-post inte längre bara är e-post utan ett fönster in i andra tjänster? Office 365 helhetssyn för efterlevnad, mendet är ofta mycket svårare än teknik att ändra personer och processer.

Det finns många andra personer och processkonsekvenser. Enligt min mening är det här ett kritiskt och under diskuteras område. Kanske mer i en annan artikel.

Alternativ för klientorganisationsstruktur

Enskild klientorganisation kontra flera innehavare

I allmänhet bör de flesta kunder bara ha en produktionsklient. Det finns många anledningar till varför flera klientorganisationar är svåra (ge det en Bing sökning)eller läs det här informationsbladet. Samtidigt har många företagskunder som jag arbetar med en annan (liten) klientorganisation för IT-utbildning, testning och experimentarbete. Azure-åtkomst mellan klientorganisationen blir enklare med Azure-fyren. Office 365 och många andra SaaS-tjänster har begränsningar för scenarier mellan klientorganisationen. Det finns mycket att tänka på i Azure AD B2B-scenarier.

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

Vissa kunder väljer att använda fler än en klientorganisation. Det bör vara ett mycket noga beslut och nästan alltid verksamhetsberoende! Några exempel är följande:

  • En företagsstruktur av typen holding där enkelt samarbete mellan olika enheter inte krävs och det finns starka behov av administrativ och annan avgränsning.
  • Efter ett företagsköp görs ett beslut om att hålla två enheter separerade.
  • Simulering av en kundmiljö som inte ändrar kundens produktionsmiljö.
  • Utveckling av programvara för kunder.

I de här scenarierna med flera innehavare vill kunder ofta behålla samma konfiguration för flera klientorganisationener eller rapportera om konfigurationsändringar och drift. Det innebär ofta att flytta från manuella ändringar till konfiguration som kod. Microsoft Premier-supporten erbjuder en utgångspunkt för dessa typer av krav baserade på denna offentliga IP: https://Microsoft365dsc.com .

Multi-Geo

Om du vill använda Multi-Geo eller inte Multi-Geo är det frågan. Med Office 365 Multi-Geo kan du tillhandahålla och lagra data i vila på de geoplatser som du har valt att uppfylla krav för datalagring. Det finns många missuppfattningar om den här funktionen. Tänk på följande:

  • Den ger inte några prestandafördelar. Det kan leda till sämre prestanda om inte nätverksdesignen fungerar som den ska. Få enheter "stäng" till Microsoft-nätverket, inte nödvändigtvis dina data.
  • Det är inte en lösning för GDPR:s efterlevnad. GDPR fokuserar inte på data eller lagringsplatser. Det finns andra ramverk för efterlevnad för detta.
  • Den löser inte delegering av administration (se nedan) eller informationsbarriärer.
  • Det är inte detsamma som flerklientorganisationen och kräver ytterligare arbetsflöden för användaretablering.
  • Din klientorganisation (din Azure AD) flyttas inte till en annan geografi.

Delegering av administration

I de flesta stora organisationer är uppdelningen av uppgifter och rollbaserad åtkomstkontroll (RBAC) nödvändig. Jag ska be om ursäkt i förväg. Det är inte så enkelt som vissa kunder vill att det ska vara. Kund-, juridiska krav, efterlevnadskrav och andra krav är olika och kan ibland vara i konflikt över hela världen. Enkelhet och flexibilitet är ofta på motsatt sidor av varandra. Det går inte att få mig att tro att vi kan göra ett bättre jobb. Det har gjorts (och kommer att) betydande förbättringar med tiden. Besök ditt lokala Microsoft Technology Center för att ta fram den modell som passar dina företagskrav utan att läsa 379230-dokument! Här fokuserar jag på vad du ska tänka på och inte varför det är så här. Nedan finns fem olika områden att planera för och några av de vanligaste frågorna som jag har stött på.

Azure AD och Microsoft 365 administrationscenter

Det finns en lång och växande lista med inbyggda roller. Varje roll består av en lista över rollbehörigheter som grupperats för att tillåta att särskilda åtgärder utförs. De här behörigheterna visas på fliken Beskrivning i varje roll. Alternativt kan du se en mer läsbar version av dessa i Microsoft 365 Admin Center. Definitionerna för inbyggda roller kan inte ändras. I allmänhet grupperar jag dessa i tre kategorier:

  • Global administratör: Den här "all kraftfulla" rollen bör skyddas i hög grad på samma sätt som i andra system. Vanliga rekommendationer är: ingen permanent tilldelning och använd Azure AD Privileged Identity Management (PIM), stark autentisering och så vidare. På ett intressant sätt ger den här rollen dig inte tillgång till allt som standard. Jag brukar se förvirring vad gäller åtkomst till efterlevnad och Azure-åtkomst, vilket 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 administratörsroller på hög nivå från Azure AD. Det är inte konsekvent i alla tjänster och det finns fler tjänstespecifika roller som diskuteras senare.
  • Funktionellt: Det finns en lång (och växande) lista med roller som fokuserar på specifika åtgärder (gäst inbjudna och så vidare). Med jämna mellanrum läggs fler av dem till utifrån kundens behov.

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

Obs! Administrationscenter för Microsoft 365 har ett mer användarvänligt gränssnitt men har en delmängd av funktionerna jämfört med administrationsupplevelsen i Azure AD. Båda portalerna använder samma Azure AD-roller, så ändringar sker på samma plats. Tips: Om du vill ha ett användargränssnitt med identitetshantering som är fokuserad administratör utan all Azure-röra kan du använda https://aad.portal.azure.com .

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

Möjligheten att skapa anpassade roller är en vanlig fråga. Det är begränsat i Azure AD idag (se nedan) men kommer att växa med tiden. Jag ser dessa som tillämpliga funktioner i Azure AD och kanske inte omfattar hierarkimodellen "nedåt" (diskuteras ovan). När jag tar itu med "anpassad" brukar jag gå tillbaka till mitt huvudnamn , "enkelt är bättre".

En annan vanlig fråga är möjligheten att begränsa roller till en delmängd av en katalog. Ett exempel är "Supportadministratör för endast användare inom EU". Administrativa enheter (AU) är avsedda att åtgärda detta. Som ovan ser jag dessa som tillämpliga funktioner i Azure AD och kanske inte spänner över "nedåt". Vissa roller är förstås inte meningsfulla att använda (globala administratörer, tjänstadministratörer och så vidare).

I dag kräver alla de här rollerna direkt medlemskap (eller dynamisk tilldelning om du använder Azure AD PIM). Det innebär att kunder måste hantera dessa direkt i Azure AD och dessa kan inte baseras på ett medlemskap i säkerhetsgrupper. Jag gillar inte att skapa skript för att hantera dem 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. Teknikarbetet kommer att åtgärdas med tiden.

Jag nämnde Azure AD PIM några gånger. Det finns en Microsoft Identity Manager (MIM) behörighetshantering (PAM) för lokala kontroller. Du kanske också vill titta på Paws (Privileged Access Arbetsstationer) och Azure AD-identitetsstyrning. Det finns även olika verktyg från tredje part som kan aktivera precis i tid, precis tillräckligt många och dynamisk rollhöjd. Det här är vanligtvis en del av en större diskussion om att skydda en miljö.

Ibland anropas scenarier för att lägga till en extern användare till en roll (se avsnittet med flera innehavare ovan). Det här fungerar alldeles utmärkt. Azure AD B2B är ett annat stort och roligt ämne som kunderna kan gå igenom, kanske i en annan artikel.

Säkerhets- och efterlevnadscenter (SCC)

Behörigheter i säkerhets- Office 365 säkerhets- & är en samling "rollgrupper", som är separata och skiljer sig från Azure AD-roller. Det kan vara förvirrande eftersom vissa av dessa rollgrupper har samma namn som Azure AD-roller (till exempel Säkerhetsläsare), men de kan ha olika medlemskap. Jag föredrar användningen av Azure AD-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 Azure AD, som är e-postaktiverade objekt. Du kan också skapa en rollgrupp med samma namn som en roll, som kanske innehåller eller inte innehåller den rollen (undvik den här förvirringen).

Det här är i en mening en vidareutveckling Exchange modellen för rollgrupper. Men Exchange Online ett eget gränssnitt för grupphantering. Vissa rollgrupper i Exchange Online är låsta och hanteras från Azure AD eller Säkerhets- och efterlevnadscenter för &, men andra kan ha samma eller liknande namn och hanteras i Exchange Online (vilket bidrar till förvirringen). Jag rekommenderar att du undviker att Exchange Online användargränssnittet såvida du inte behöver omfattningar Exchange hantering.

Du kan inte skapa anpassade roller. Roller definieras av tjänster som skapas av Microsoft och växer i och med att nya tjänster införs. Det här fungerar ungefär som roller som definieras av program i Azure AD. När nya tjänster är aktiverade behöver ofta nya rollgrupper skapas för att bevilja eller delegera åtkomst till dessa (till exempel insiderriskhantering).

De här rollgrupperna kräver direkt medlemskap och får inte innehålla Azure AD-grupper. Idag stöds tyvärr inte de här rollgrupperna av Azure AD PIM. Precis som med Azure AD-roller brukar jag rekommendera hantering av dessa via API:er eller en produkt för partnerstyrning, till exempel Saviynt.

Roller & kompatibilitetscenter omfattar hela Microsoft 365 och du kan inte begränsa rollgrupperna till en delmängd av miljön (på samma sätt som med administrativa enheter i Azure AD). Många kunder frågar hur de kan underta bort. Till exempel "skapa en DLP-princip endast för EU-användare". Om du i dag har rättigheter till en specifik funktion i Säkerhets- och & efterlevnadscenter har du rättigheter till allt som omfattas av den här funktionen i klientorganisationen. Men många principer har funktioner för att rikta en delmängd av miljön (till exempel "gör de här etiketterna endast tillgängliga 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 metod som "konfiguration som kod" för att hantera underdelegering i säkerhets- & efterlevnadscenter. Vissa specifika tjänster har stöd för underdelegering (se nedan).

Det är värt att notera att kontroller som hanteras via säkerhets- och efterlevnadscentret för & (protection.office.com) håller på att migreras till två separata administratörsportaler: security.microsoft.com och compliance.microsoft.com. Ändra är den enda konstanten!

Tjänstspecifik

Som vi nämnt tidigare 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 för alla tjänster och funktioner. Dessutom kan varje tjänst ha en separat och unik RBAC-modell. I stället för att diskutera allt detta (det tar evigheter) lägger jag till relevanta länkar för varje tjänst. Det här är inte en fullständig lista, men det hjälper dig att 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)
    • Advanced eDiscovery – (.. /compliance/overview-ediscovery-20.md)

  • Yammer - (/yammer/manage-yammer-users/manage-yammer-admins)

  • Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)

  • Dynamics 365 – (/dynamics365/)

    Obs! Den här länken finns i roten till dokumentationen. Det finns flera typer av tjänster med variationer i modellen för administratörer/delegering.

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

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

      Obs! Det finns flera typer med variationer i modeller för administratörer/delegering.

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

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

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

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

  • Microsoft Defender för slutpunkt – (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

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

  • Microsoft Defender för molnappar – (/cloud-app-security/manage-admins)

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

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

Aktivitetsloggar

Office 365 har en enhetlig granskningslogg. Det är en mycket detaljerad logg, men läs inte för mycket i namnet. Den kanske inte innehåller allt du behöver eller behöver för dina säkerhets- och efterlevnadsbehov. Dessutom är vissa kunder intresserade av Avancerad granskning.

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

Det är viktigt att först identifiera alla loggkällor som behövs för ett säkerhets- och efterlevnadsprogram. Observera även att olika loggar har olika begränsningar för lagring på rad.

Ur administratörsdelegeringsperspektiv har Microsoft 365 de flesta 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 kunna fråga aktivitet endast 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.

Översiktsdiagram:

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

Diagrammet ovan representerar inbyggda funktioner för att skicka loggar till Händelsehubben och/eller Azure Storage och/eller Azure Log Analytics. Alla system har inte den här inbyggda ännu. Men det finns andra metoder för att skicka loggarna till samma lagringsplats. Se till exempel Skydda din Teams med Microsoft Sentinel.

Om du kombinerar alla loggar till en lagringsplats innebär det ytterligare fördelar, till exempel korskorrelationer, anpassade kvarhållningstider, utfyllning med 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 Office 365 loggar med Microsoft Defender för molnappar eller en anpassad RBAC-modell i Power BI. Olika lagringsplatsen har olika fördelar och målgrupper.

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

Många stora kunder vill överföra dessa loggdata till ett tredjepartssystem (till exempel SIEM). Det finns olika metoder för detta, men i allmänhet är Azure Event Hub Graph en bra utgångspunkt.

Azure

Jag får ofta frågan om det finns något sätt att separera roller med hög behörighet mellan Azure AD, Azure och SaaS (till exempel: Global administratör för Office 365 men inte Azure). Inte riktigt. Arkitektur med flera klientorganisationar krävs om fullständig administrativ avgränsning krävs, men det ökar komplexiteten (se ovan). Alla dessa tjänster är en del av samma säkerhets- och identitetsgräns (titta på hierarkimodellen ovan).

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

  1. Jag vill samarbeta i en uppsättning dokument/bilder/osv.(Office 365)
  2. Skicka var och en av dem genom en godkännandeprocess (Power Platform)
  3. När alla komponenter har godkänts sätter du ihop dem till en enhetlig slutbar produkt (Azure) Microsoft Graph API är din bästa vän för dessa. Inte omöjligt, men betydligt mer komplicerat med att utforma en lösning som spänner över flera klientorganisationar.

Azure Role-Based Access Control (RBAC) ger enkel åtkomsthantering för Azure. Med RBAC kan du hantera åtkomst till resurser genom att bevilja användare de längsta behörigheter som behövs för att utföra deras jobb. Informationen är inte begränsad till 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 hanteringsöverväganden för Azure. Cloud Adoption Framework är en bra utgångspunkt för mer information. Jag gillar hur min vän Andres Ochres Förserkunderna steg för steg genom olika komponenter för att bestämma vilken metod jag ska använda. Vyn på hög nivå för olika element (inte lika bra som processen för att komma åt faktiska kundmodeller) ser ut ungefär så här:

Vy på hög nivå av Azure-komponenter för delegerad administration.

Som du ser ovanifrån bör många andra tjänster ses som en del av designen (till exempel: Azure-principer, Azure Blueprints, Hanteringsgrupperoch så vidare).

Sammanfattning

Från början som en kort sammanfattning, avslutades längre än förväntat. Jag hoppas att du nu är redo att ta dig in i en djup förståelse av hur du skapar delegeringsmodeller 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 Microsoft-teknik innan vi dokumenterar vanliga mönster som vi ser för kunder. Under tiden kan du samarbeta med Microsoft-kontoteamet för att ordna ett besök på närmaste Microsoft Technology Center. Vi ser dig!