Del via

Til identitet og mer – ett arkitektsynspunkt

  • Artikkel

I denne artikkelen diskuterer Alex Shteynberg, Principal Technical Architect hos Microsoft, de beste designstrategiene for bedriftsorganisasjoner som tar i bruk Microsoft 365 og andre Microsoft-skytjenester.

Om forfatteren

Alex Shteynberg bilde.

Jeg er teknisk arkitekt ved Microsoft Technology Center i New York. Jeg jobber for det meste med store kunder og komplekse krav. Mitt synspunkt og meninger er basert på disse samhandlingene og gjelder kanskje ikke for alle situasjoner. Men etter min erfaring, hvis vi kan hjelpe kunder med de mest komplekse utfordringene, kan vi hjelpe alle kunder.

Jeg jobber vanligvis med 100 + kunder hvert år. Selv om hver organisasjon har unike egenskaper, er det interessant å se trender og fellestrekk. Én trend er for eksempel interesse på tvers av bransjer for mange kunder. Tross alt kan en bankfilial også være en kaffebar og et samfunnssenter.

I min rolle fokuserer jeg på å hjelpe kunder med å komme frem til den beste tekniske løsningen for å håndtere sine unike forretningsmål. Offisielt fokuserer jeg på identitet, sikkerhet, personvern og samsvar. Jeg elsker det faktum at disse berører alt vi gjør. Det gir meg en mulighet til å være involvert i de fleste prosjekter. Denne aktiviteten holder meg opptatt og nyter denne rollen.

Jeg bor i New York City (den beste!) og virkelig nyte mangfoldet av sin kultur, mat og mennesker (ikke trafikk). Jeg elsker å reise når jeg kan og håper å se det meste av verden i mitt liv. Jeg undersøker for tiden en tur til Afrika for å lære om dyrelivet.

Veiledende prinsipper

  • Enkelt er ofte bedre: Du kan gjøre (nesten) alt med teknologi, men det betyr ikke at du bør. Spesielt i sikkerhetsområdet, mange kunder overengineer løsninger. Jeg liker denne videoen fra Googles Stripe-konferanse for å understreke dette punktet.
  • Folk, prosess, teknologi: Utform for personer å forbedre prosessen, ikke teknisk først. Det finnes ingen "perfekte" løsninger. Vi må balansere ulike risikofaktorer og beslutninger som kan være forskjellige for hver bedrift. For mange kunder utformer en tilnærming som brukerne senere unngår.
  • Fokuser på "hvorfor" først og "hvordan" senere: Vær den irriterende 7-årige gamle gutten med en million spørsmål. Vi kan ikke komme frem til det riktige svaret hvis vi ikke vet de riktige spørsmålene å stille. Mange kunder gjør antagelser om hvordan ting må fungere i stedet for å definere forretningsproblemet. Det finnes alltid flere baner som kan utføres.
  • Lang hale av tidligere anbefalte fremgangsmåter: Innser at anbefalte fremgangsmåter endrer seg i lys hastighet. Hvis du så på Microsoft Entra for mer enn tre måneder siden, er du sannsynligvis utdatert. Alt her kan endres etter publisering. «Beste»-alternativet i dag er kanskje ikke det samme seks måneder fra nå.

Opprinnelige konsepter

Ikke hopp over denne inndelingen. Jeg føler ofte at jeg må gå tilbake til disse artiklene, selv for kunder som har brukt skytjenester i årevis. Akk, språk er ikke et nøyaktig verktøy. Vi bruker ofte det samme ordet til å bety forskjellige begreper eller forskjellige ord for å bety det samme konseptet. Jeg bruker ofte diagrammet nedenfor til å etablere en terminologi for grunnlinje og «hierarkimodell».

Illustrasjon av leier, abonnement, tjeneste og data.

Når du lærer å svømme, er det bedre å starte i bassenget og ikke midt i havet. Jeg prøver ikke å være teknisk nøyaktig med dette diagrammet. Det er en modell for å diskutere noen grunnleggende konsepter.

I diagrammet:

  • Tenant = en forekomst av Microsoft Entra ID. Det er øverst i et hierarki, eller nivå 1 i diagrammet. Vi kan vurdere dette nivået som "grensen" der alt annet skjer (Microsoft Entra B2B til side). Alle Skytjenester for Microsoft Enterprise er en del av én av disse tenantene. Forbrukertjenester er separate. «Leier» vises i dokumentasjonen som Microsoft 365-leier, Azure-leier, WVD-leier og så videre. Jeg synes ofte at disse variasjonene skaper forvirring for kundene.
  • Tjenester/abonnementer, nivå 2 i diagrammet, tilhører én og bare én leier. De fleste SaaS-tjenester er 1:1 og kan ikke flyttes uten overføring. Azure er forskjellig, du kan flytte fakturering og/eller et abonnement til en annen leier. Det finnes mange kunder som må flytte Azure-abonnementer. Dette scenarioet har ulike implikasjoner. Objekter som finnes utenfor abonnementet, flyttes ikke. Rollebasert tilgangskontroll (Azure RBAC), Microsoft Entra objekter (grupper, apper, policyer osv.) og noen tjenester (Azure Key Vault, Data Bricks osv.). Ikke overfør tjenester uten et godt forretningsbehov. Noen skript som kan være nyttige for overføring, deles på GitHub.
  • En gitt tjeneste har vanligvis en slags grense for undernivå, eller nivå 3 (L3). Denne grensen er nyttig å forstå for segregering av sikkerhet, politikk, styring og så videre. Dessverre er det ikke noe uniformnavn jeg vet om. Noen eksempler på navn på L3 er: Azure-abonnement = ressurs; Dynamics 365 CE = forekomst; Power BI = arbeidsområde; Power Apps = miljø; og så videre.
  • Nivå 4 er der de faktiske dataene befinner seg. Dette dataplanet er en kompleks artikkel. Noen tjenester bruker Microsoft Entra ID for RBAC, andre er ikke. Jeg diskuterer det litt når vi kommer til delegeringsartikler.

Noen andre konsepter som jeg finner mange kunder (og Microsoft-ansatte) er forvirret om eller har spørsmål om inkluderer følgende problemer:

  • Alle kan opprette mange leiere uten kostnad. Du trenger ikke en tjeneste klargjort i den. Jeg har dusinvis. Hvert leiernavn er unikt i Microsofts verdensomspennende skytjeneste (med andre ord kan ingen leiere ha samme navn). Alle er i formatet TenantName.onmicrosoft.com. Det finnes også prosesser som oppretter leiere automatisk (ikke-administrerte leiere). Dette resultatet kan for eksempel skje når en bruker registrerer seg for en bedriftstjeneste med et e-postdomene som ikke finnes i noen annen leier.
  • I en administrert leier kan mange DNS-domener registreres i den. Dette resultatet endrer ikke det opprinnelige leiernavnet. Det er for øyeblikket ingen enkel måte å gi nytt navn til en leier på (annet enn overføring). Selv om leiernavnet teknisk sett ikke er kritisk i disse dager, kan det hende at noen føler seg begrenset av denne virkeligheten.
  • Du bør reservere et leiernavn for organisasjonen selv om du ennå ikke planlegger å distribuere noen tjenester. Ellers kan noen ta det fra deg, og det er ingen enkel prosess å ta det tilbake (samme problem som DNS-navn). Jeg hører dette altfor ofte fra kunder. Det leiernavnet ditt bør være, er også en debattartikkel.
  • Hvis du eier DNS-navneområdet, bør du legge til alle disse navneområdene i tenantene. Ellers kan man opprette en ikke-administrert leier med dette navnet, noe som deretter forårsaker forstyrrelser for å gjøre den administrert.
  • Et DNS-navneområde (for eksempel contoso.com) kan tilhøre én og bare én leier. Dette kravet har implikasjoner for ulike scenarioer (for eksempel deling av et e-postdomene under en fusjon eller anskaffelse, og så videre). Det finnes en måte å registrere en DNS-del på (for eksempel div.contoso.com) i en annen leier, men det bør unngås. Ved å registrere et domenenavn på øverste nivå antas alle underdomener å tilhøre samme leier. I scenarioer med flere leiere (som forklart nedenfor) anbefaler jeg vanligvis å bruke et annet domenenavn på øverste nivå (for eksempel contoso.ch eller ch-contoso.com).
  • Hvem skal «eie» en leier? Jeg ser ofte kunder som ikke vet hvem som eier leieren sin for øyeblikket. Denne mangelen på kunnskap er et betydelig rødt flagg. Ring Microsoft Kundestøtte SÅ SNART SOM MULIG. Like problematisk er når en tjenesteeier (ofte en Exchange-administrator) er angitt til å administrere en leier. Leieren inneholder alle tjenestene du kanskje vil ha i fremtiden. Leiereieren bør være en gruppe som kan ta beslutninger om aktivering av alle skytjenester i en organisasjon. Et annet problem er når en leiereiergruppe blir bedt om å administrere alle tjenester. Denne metoden skaleres ikke for store organisasjoner.
  • Det finnes ikke noe konsept for en sub-/super-leier. Av en eller annen grunn gjentar denne myten seg selv. Dette konseptet gjelder også for Azure Active Directory B2C-leiere . Jeg hører for mange ganger: «B2C-miljøet mitt er i XYZ-leieren min» eller «Hvordan flytte Azure-leieren til Microsoft 365-leieren?»
  • Dette dokumentet fokuserer for det meste på den kommersielle verdensomspennende skyen, fordi det er det de fleste kunder bruker. Det er noen ganger nyttig å vite om nasjonale skyer. Nasjonale skyer har andre implikasjoner å diskutere som er utenfor omfanget for denne diskusjonen.

Artikler om opprinnelig identitet

Det er mye dokumentasjon om Microsofts identitetsplattform – Microsoft Entra ID. For folk som nettopp har begynt, føles det ofte overveldende. Selv etter at du har lært om det, kan det være utfordrende å holde tritt med konstant innovasjon og endring. I mine kundesamhandlinger fungerer jeg ofte som "oversetter" mellom forretningsmål og "Gode, bedre, beste" tilnærminger for å løse disse bekymringene (og menneskelige "klippenotater" for disse artiklene). Det er sjelden et perfekt svar, og den "riktige" beslutningen er en balanse mellom ulike risikofaktorer. Neste er noen av de vanlige spørsmålene og forvirringsområdene jeg har en tendens til å diskutere med kunder.

Klargjøring

Microsoft Entra ID løser ikke på grunn av manglende styring i identitetsverdenen din! Identitetsstyring bør være et kritisk element uavhengig av eventuelle skybeslutninger. Styringskravene endres over tid, og derfor er det et program og ikke et verktøy.

Microsoft Entra Connect kontra Microsoft Identity Manager (MIM) kontra noe annet (tredjepart eller egendefinert)? Spar problemer nå og i fremtiden, og gå med Microsoft Entra Connect. Det finnes alle slags smarts i dette verktøyet for å løse særegne kundekonfigurasjoner og pågående innovasjoner.

Noen kanttilfeller som kan drive mot en mer kompleks arkitektur:

  • Jeg har flere AD-skoger uten nettverkstilkobling mellom dem. Det finnes et nytt alternativ kalt Skyklargjøring.
  • Jeg har ikke Active Directory, og jeg vil heller ikke installere den. Microsoft Entra Connect kan konfigureres til å synkronisere fra LDAP (partner kan være nødvendig).
  • Jeg må klargjøre de samme objektene til flere leiere. Dette scenarioet støttes ikke teknisk, men avhenger av definisjonen av «samme».

Bør jeg tilpasse standard synkroniseringsregler (filterobjekter, endre attributter, alternativ påloggings-ID og så videre)? Unngå det! En identitetsplattform er bare like verdifull som tjenestene som bruker den. Selv om du kan gjøre alle slags nutty konfigurasjoner, for å svare på dette spørsmålet må du se på effekten på programmer. Hvis du filtrerer e-postaktiverte objekter, er GAL for onlinetjenester ufullstendig. Hvis programmet er avhengig av bestemte attributter, har filtrering på disse attributtene uforutsigbare effekter og så videre. Det er ikke en avgjørelse i identitetsteamet.

XYZ SaaS støtter just-in-time (JIT)-klargjøring. Hvorfor krever du at jeg synkroniserer? Se forrige avsnitt. Mange programmer trenger profilinformasjon for funksjonalitet. Du kan ikke ha en gal hvis alle e-postaktiverte objekter ikke er tilgjengelige. Det samme gjelder for brukerklargjøring i programmer som er integrert med Microsoft Entra ID.

Godkjenning

Synkronisering av hash for passord (PHS) kontra direktegodkjenning (PTA) kontra forbund.

Vanligvis er det en lidenskapelig debatt rundt føderasjonen. Enklere er vanligvis bedre og bruker derfor PHS med mindre du har en god grunn til ikke å gjøre det. Det er også mulig å konfigurere ulike godkjenningsmetoder for ulike DNS-domener i samme leier.

Noen kunder aktiverer forbund + PHS hovedsakelig for:

Jeg veileder ofte kunder gjennom klientgodkjenningsflyten for å klargjøre noen misforståelser. Resultatet ser ut som bildet nedenfor, som ikke er like bra som den interaktive prosessen med å komme dit.

Eksempel på tavlesamtale.

Denne typen tavletegning illustrerer hvor sikkerhetspolicyer brukes i flyten av en godkjenningsforespørsel. I dette eksemplet brukes policyer som håndheves gjennom Active Directory Federation Service (AD FS) på den første serviceforespørselen, men ikke etterfølgende tjenesteforespørsler. Denne virkemåten er minst én grunn til å flytte sikkerhetskontroller til skyen så mye som mulig.

Vi har jaktet på drømmen om enkel pålogging (SSO) så lenge jeg kan huske. Noen kunder tror de kan oppnå enkel pålogging ved å velge den "riktige" forbundsleverandøren (STS). Microsoft Entra ID kan bidra betydelig til å aktivere SSO-funksjoner, men ingen STS er magisk. Det finnes for mange eldre godkjenningsmetoder som fortsatt brukes for kritiske programmer. Hvis du utvider Microsoft Entra ID med partnerløsninger, kan du løse mange av disse scenariene. SSO er en strategi og en reise. Du kan ikke komme dit uten å gå mot standarder for programmer. Relatert til denne artikkelen er en reise til passordløs godkjenning, som heller ikke har et magisk svar.

Godkjenning med flere faktorer (MFA) er viktig i dag (her for mer). Legg til i brukeratferdsanalyse, og du har en løsning som forhindrer de vanligste nettangrepene. Selv forbrukertjenester flytter for å kreve MFA. Likevel møter jeg fortsatt mange kunder som ikke ønsker å flytte til moderne godkjenningstilnærminger . Det største argumentet jeg hører er at det påvirker brukere og eldre programmer. Noen ganger kan et godt spark hjelpe kundene med å gå videre - Exchange Online annonserte endringer. Mange Microsoft Entra rapporter er nå tilgjengelige for å hjelpe kunder med denne overgangen.

Authorization

Per Wikipedia er «å godkjenne» å definere en tilgangspolicy. Mange ser på det som muligheten til å definere tilgangskontroller til et objekt (fil, tjeneste og så videre). I den nåværende verden av cybertrusler utvikler dette konseptet seg raskt til en dynamisk politikk som kan reagere på ulike trusselvektorer og raskt justere tilgangskontrollene som svar på dem. Hvis jeg for eksempel får tilgang til bankkontoen min fra en uvanlig plassering, får jeg ekstra bekreftelsestrinn. For å nærme oss denne virkeligheten må vi vurdere ikke bare selve politikken, men økosystemet for trusseldeteksjon og signalkorrelasjonsmetoder.

Policymotoren for Microsoft Entra ID implementeres ved hjelp av policyer for betinget tilgang. Dette systemet avhenger av informasjon fra andre trusselregistreringssystemer for å ta dynamiske beslutninger. En enkel visning ville være noe sånt som følgende illustrasjon:

Policymotor i Microsoft Entra ID.

Ved å kombinere alle disse signalene sammen kan dynamiske policyer som dette gjøres:

  • Hvis det oppdages en trussel på enheten, blir tilgangen til data bare redusert til nett uten mulighet til å laste ned.
  • Hvis du laster ned et uvanlig høyt volum med data, krypteres og begrenses alt du laster ned.
  • Hvis du får tilgang til en tjeneste fra en uadministrert enhet, blokkeres du fra svært sensitive data, men får tilgang til ikke-registrerte data uten mulighet til å kopiere dem til en annen plassering.

Hvis du er enig i denne utvidede definisjonen av autorisasjon, må du implementere flere løsninger. Hvilke løsninger du implementerer, avhenger av hvor dynamisk du vil at policyen skal være, og hvilke trusler du vil prioritere. Noen eksempler på slike systemer er:

I tillegg til Microsoft Entra ID har ulike tjenester og programmer sine egne spesifikke autorisasjonsmodeller. Noen av disse modellene diskuteres senere i delegeringsdelen.

Tilsynet

Microsoft Entra ID har detaljerte funksjoner for overvåking og rapportering. Disse rapportene er imidlertid vanligvis ikke den eneste informasjonskilden som kreves for å ta sikkerhetsbeslutninger. Se mer diskusjon om dette emnet i delegeringsdelen.

Det finnes ingen Exchange

Ikke få panikk! Exchange blir ikke avskrevet (eller SharePoint og så videre). Det er fortsatt en kjernetjeneste. Det jeg mener er at teknologileverandører i en stund har overført brukeropplevelser (UX) til å omfatte komponenter i flere tjenester. I Microsoft 365 er et enkelt eksempel «moderne vedlegg» der vedlegg til e-post lagres i SharePoint Online eller OneDrive.

Legge ved en fil i en e-postmelding.

Når du ser på Outlook-klienten, kan du se mange tjenester som er «tilkoblet» som en del av denne opplevelsen, ikke bare Exchange. Eksempler er Microsoft Entra ID, Microsoft Søk, Apper, Profil, Samsvar og Microsoft 365-grupper.

Outlook-grensesnitt med bildeavklaringer.

Les om Microsoft Fluid Framework for forhåndsvisning av kommende funksjoner. I forhåndsversjon nå kan jeg lese og svare på Teams-samtaler direkte i Outlook. Teams-klienten er faktisk et av de mer fremtredende eksemplene på denne strategien.

Totalt sett blir det vanskeligere å tegne en klar linje mellom Microsoft 365 og andre tjenester i Microsoft-skyer. Jeg ser det som en stor fordel for kundene siden de kan dra nytte av total innovasjon på tvers av alt vi gjør selv om de bruker en komponent. Ganske kult og har vidtrekkende implikasjoner for mange kunder.

I dag finner jeg at mange IT-grupper for kunder er strukturert rundt «produkter». Det er logisk for en lokal verden siden du trenger en ekspert for hvert produkt. Jeg er imidlertid glad for at jeg ikke trenger å feilsøke en Active Directory- eller Exchange-database igjen, ettersom disse tjenestene har flyttet til skyen. Automatisering (som skyen i utgangspunktet er) fjerner visse gjentakende manuelle jobber (se hva som skjedde med fabrikker). Disse oppgavene erstattes imidlertid med mer komplekse krav for å forstå samhandling på tvers av tjenester, effekt, forretningsbehov og så videre. Hvis du er villig til å lære, er det store muligheter som aktiveres av skytransformasjon. Før jeg hopper inn i teknologi, snakker jeg ofte med kunder om å administrere endringer i IT-ferdigheter og teamstrukturer.

Slutt å spørre «Hvordan kan jeg gjøre XYZ i SharePoint Online?» til alle personer og utviklere i SharePoint Bruk Power Automate (eller Flow) for arbeidsflyt, det er en mye kraftigere plattform. Bruk Azure Bot Framework til å opprette en bedre UX for 500-K-elementlisten. Begynn å bruke Microsoft Graph i stedet for CSOM. Microsoft Teams inkluderer SharePoint, men også en verden mer. Det finnes mange andre eksempler jeg kan vise. Det er et stort og fantastisk univers der ute. Åpne døren og begynn å utforske.

Den andre vanlige effekten er i samsvarsområdet. Denne tilnærmingen på tvers av tjenester ser ut til å fullstendig forvirre mange samsvarspolicyer. Jeg ser stadig organisasjoner som sier : «Jeg må registrere all e-postkommunikasjon til et eDiscovery-system.» Hva betyr denne erklæringen egentlig når e-post ikke lenger bare er e-post, men et vindu til andre tjenester? Microsoft 365 har en omfattende fremgangsmåte for overholdelse, men endring av personer og prosesser er ofte mye vanskeligere enn teknologi.

Det er mange andre mennesker og prosessimplikasjoner. Etter min mening er denne faktoren et kritisk og underutøvd område. Kanskje mer i en annen artikkel.

Alternativer for leierstruktur

Én leier kontra flere leiere

Generelt sett bør de fleste kunder bare ha én produksjonsleier. Det er mange grunner til at flere leiere er utfordrende (gi det et Bing-søk) eller lese denne hvitboken. Samtidig har mange bedriftskunder jeg jobber med, en annen (liten) leier for IT-læring, testing og eksperimentering. Azure-tilgang på tvers av tenanter gjøres enklere med Azure Lighthouse. Microsoft 365 og mange andre SaaS-tjenester har begrensninger for scenarioer på tvers av leiere. Det er mye å tenke på i Microsoft Entra B2B-scenarier.

Mange kunder ender opp med flere produksjonsleietakere etter en sammenslåing og anskaffelse (M&A) og ønsker å konsolidere. I dag er det ikke enkelt og krever Microsoft Consulting Services (MCS) eller en partner pluss tredjepartsprogramvare. Det pågår ingeniørarbeid for å håndtere ulike scenarioer med kunder med flere leiere i fremtiden.

Noen kunder velger å gå med mer enn én leier. Dette bør være en forsiktig beslutning og nesten alltid forretningsmessig grunn drevet! Noen eksempler omfatter følgende årsaker:

  • En firmastruktur for holdingtype der enkelt samarbeid mellom ulike enheter ikke er nødvendig, og det er sterke administrative og andre isoleringsbehov.
  • Etter et oppkjøp tas det en forretningsbeslutning om å holde to enheter atskilt.
  • Simulering av kundens miljø som ikke endrer kundens produksjonsmiljø.
  • Utvikling av programvare for kunder.

I disse scenarioene med flere leiere ønsker kunder ofte å beholde konfigurasjonen på samme måte på tvers av leiere, eller rapportere om konfigurasjonsendringer og -drift. Dette betyr ofte å flytte fra manuelle endringer til konfigurasjon som kode. Microsoft Premiere-støtte tilbyr en workshop for denne typen krav basert på denne offentlige IP-adressen: https://Microsoft365dsc.com.

Multi-Geo

Til Multi-Geo eller ikke til Multi-Geo. Det er spørsmålet. Med Microsoft 365 Multi-Geo kan du klargjøre og lagre inaktive data på de geografiske plasseringene du velger for å oppfylle kravene til datalagring . Det finnes mange misforståelser om denne funksjonen. Husk følgende punkter:

  • Det gir ikke ytelsesfordeler. Det kan gjøre ytelsen verre hvis nettverksutformingen ikke er riktig. Få enheter «nær» Microsoft-nettverket, ikke nødvendigvis til dataene dine.
  • Det er ikke en løsning for GDPR-samsvar. GDPR fokuserer ikke på datasuverenitet eller lagringssteder. Det finnes andre samsvarsrammeverk for datasuverenitet eller lagringssteder.
  • Det løser ikke delegering av administrasjon (se nedenfor) eller informasjonsbarrierer.
  • Det er ikke det samme som flere leiere og krever flere brukerklargjøringsarbeidsflyter .
  • Den flytter ikke leieren (Microsoft Entra ID) til en annen geografi.

Delegering av administrasjon

I de fleste store organisasjoner er fordeling av oppgaver og rollebasert tilgangskontroll (RBAC) en nødvendig virkelighet. Jeg skal be om unnskyldning på forhånd. Denne aktiviteten er ikke så enkel som noen kunder ønsker. Kunde, juridisk, samsvar og andre krav er forskjellige og noen ganger motstridende rundt om i verden. Enkelhet og fleksibilitet er ofte på motsatte sider av hverandre. Ikke ta feil, vi kan gjøre en bedre jobb på dette målet. Det har vært (og vil være) betydelige forbedringer over tid. Gå til det lokale Microsoft Technology Center for å finne ut hvilken modell som passer dine forretningskrav uten å lese 379 230 dokumenter! Her fokuserer jeg på hva du bør tenke på, og ikke hvorfor det er slik. Kommer opp er fem forskjellige områder å planlegge for og noen av de vanlige spørsmålene jeg møter.

administrasjonssentre for Microsoft Entra ID og Microsoft 365

Det finnes en lang og voksende liste over innebygde roller. Hver rolle består av en liste over rolletillatelser gruppert sammen for å tillate at bestemte handlinger utføres. Du kan se disse tillatelsene i Beskrivelse-fanen i hver rolle. Alternativt kan du se en mer lesbar versjon av disse tillatelsene i Microsoft 365 administrasjon Center. Definisjonene for innebygde roller kan ikke endres. Jeg grupperer vanligvis disse rollene i tre kategorier:

  • global administrator: Denne "alle kraftige" rollen bør være svært beskyttet akkurat som du ville gjort i andre systemer. Typiske anbefalinger inkluderer: ingen permanent tildeling og bruk Microsoft Entra Privileged Identity Management (PIM), sterk godkjenning; og så videre. Interessant nok gir ikke denne rollen deg tilgang til alt som standard. Vanligvis ser jeg forvirring om samsvarstilgang og Azure-tilgang, diskutert senere. Denne rollen kan imidlertid alltid tilordne tilgang til andre tjenester i leieren.
  • Bestemte tjenesteadministratorer: Enkelte tjenester (Exchange, SharePoint, Power BI og så videre) bruker administrasjonsroller på høyt nivå fra Microsoft Entra ID. Denne virkemåten er ikke konsekvent på tvers av alle tjenester, og det er flere tjenestespesifikke roller som diskuteres senere.
  • Funksjonell: Det finnes en lang (og voksende) liste over roller som fokuserer på bestemte operasjoner (gjesteinvitasjon og så videre). Med jevne mellomrom legges flere av disse rollene til basert på kundens behov.

Det er ikke mulig å delegere alt (selv om gapet reduseres), noe som betyr at rollen global administrator må brukes noen ganger. Konfigurasjon som kode og automatisering bør vurderes i stedet for personmedlemskap i denne rollen.

Obs! Administrasjonssenter for Microsoft 365 har et mer brukervennlig grensesnitt, men har et delsett av funksjoner sammenlignet med Microsoft Entra administratoropplevelse. Begge portalene bruker samme Microsoft Entra roller, slik at endringer skjer på samme sted. Tips! Hvis du vil ha et brukergrensesnitt for identitetsadministrasjon med fokus på administratorer uten alt Azure-rotet, kan du bruke https://aad.portal.azure.com.

Hva er i navnet? Ikke gjør antagelser fra navnet på rollen. Språk er ikke et nøyaktig verktøy. Målet bør være å definere operasjoner som må delegeres før du ser på hvilke roller som trengs. Hvis du legger til noen i «Sikkerhetsleser»-rollen, ser de ikke sikkerhetsinnstillingene på tvers av alt.

Muligheten til å opprette egendefinerte roller er et vanlig spørsmål. Denne funksjonen er begrenset i Microsoft Entra i dag (som forklart senere), men vil vokse i funksjoner over tid. Jeg tenker på disse egendefinerte rollene som gjeldende for funksjoner i Microsoft Entra ID og kan ikke strekke seg over "ned" hierarkimodellen (som tidligere diskutert). Når jeg håndterer "skikk", har jeg en tendens til å gå tilbake til min rektor av "enkel er bedre."

Et annet vanlig spørsmål er muligheten til å begrense roller til et delsett av en katalog. Ett eksempel er noe sånt som «Bare brukerstøtteadministrator for brukere i EU». Administrative enheter er ment å løse dette scenarioet. Som tidligere beskrevet tenker jeg på disse omfangene som gjeldende for funksjoner i Microsoft Entra ID og kan ikke strekke seg "ned". Enkelte roller gir ikke mening for omfanget (globale administratorer, tjenesteadministratorer og så videre).

I dag krever alle disse rollene direkte medlemskap (eller dynamisk tilordning hvis du bruker Microsoft Entra PIM). Dette betyr at kunder må administrere denne rollen direkte i Microsoft Entra ID, og disse rollene kan ikke baseres på et medlemskap i en sikkerhetsgruppe. Jeg er ikke fan av å lage skript for å administrere disse rollene, da det måtte kjøre med forhøyede rettigheter. Jeg anbefaler vanligvis API-integrering med prosesssystemer som ServiceNow eller bruk av partnerstyringsverktøy som Saviynt. Det pågår ingeniørarbeid for å løse dette problemet over tid.

Jeg nevnte Microsoft Entra PIM et par ganger. Det finnes en tilsvarende Microsoft Identity Manager (MIM) Privileged Access Management (PAM)-løsning for lokale kontroller. Du kan også se på Privileged Access Workstations (PAWs) og Microsoft Entra ID-styring. Det finnes også ulike tredjepartsverktøy, som kan muliggjøre akkurat i tide, akkurat nok og dynamisk rolleheving. Denne funksjonen er vanligvis en del av en større diskusjon for å sikre et miljø.

Noen ganger krever scenarioer å legge til en ekstern bruker i en rolle (se forrige inndeling med flere leiere). Dette resultatet fungerer fint. Microsoft Entra B2B er en annen stor og morsom artikkel for å veilede kundene gjennom, kanskje i en annen artikkel.

samsvarsportaler for Microsoft Defender XDR og Microsoft 365 Purview

E-& samarbeidsroller i Microsoft Defender-portalen og *Rollegrupper for Microsoft Purview-løsninger i Samsvarsportalen for Microsoft 365 Purview er en samling av «rollegrupper», som er separate og forskjellige fra Microsoft Entra roller. Dette kan være forvirrende fordi noen av disse rollegruppene har samme navn som Microsoft Entra roller (for eksempel Sikkerhetsleser), men de kan ha forskjellige medlemskap. Jeg foretrekker bruk av Microsoft Entra roller. Hver rollegruppe består av én eller flere «roller» (se hva jeg mener med å bruke det samme ordet på nytt?) og har medlemmer fra Microsoft Entra ID, som er objekter som er aktivert for e-post. Du kan også opprette en rollegruppe med samme navn som en rolle, som kanskje eller kanskje ikke inneholder denne rollen (unngå denne forvirringen).

På en måte er disse tillatelsene en videreutvikling av Modellen for Exchange-rollegrupper. Exchange Online har imidlertid sitt eget administrasjonsgrensesnitt for rollegrupper. Noen rollegrupper i Exchange Online er låst og administrert fra Microsoft Entra ID eller Microsoft Defender XDR- og Microsoft 365 Purview-samsvarsportaler, men andre kan ha samme eller lignende navn og administreres i Exchange Online (noe som øker forvirringen). Jeg anbefaler at du unngår å bruke Exchange Online brukergrensesnitt med mindre du trenger omfang for Exchange-administrasjon.

Du kan ikke opprette egendefinerte roller. Roller defineres av tjenester som er opprettet av Microsoft, og fortsetter å vokse etter hvert som nye tjenester innføres. Denne virkemåten ligner på roller definert av programmer i Microsoft Entra ID. Når nye tjenester er aktivert, må det ofte opprettes nye rollegrupper for å kunne gi eller delegere tilgang til disse (for eksempel insider risk management.

Disse rollegruppene krever også direkte medlemskap og kan ikke inneholde Microsoft Entra grupper. I dag støttes dessverre ikke disse rollegruppene av Microsoft Entra PIM. Som Microsoft Entra roller, har jeg en tendens til å anbefale administrasjon av disse rollegruppene gjennom API-er eller et partnerstyringsprodukt som Saviynt eller andre.

Microsoft Defender portal og Microsoft 365 Purview-portalroller for samsvar spenner over Microsoft 365, og du kan ikke begrense disse rollegruppene til et delsett av miljøet (som du kan med administrative enheter i Microsoft Entra ID). Mange kunder spør hvordan de kan underdele. For eksempel «opprett en DLP-policy bare for EU-brukere». I dag, hvis du har rettigheter til en bestemt funksjon i Microsoft Defender XDR- og Microsoft 365 Purview-samsvarsportalene, har du rettigheter til alt som dekkes av denne funksjonen i leieren. Mange policyer har imidlertid muligheter til å målrette mot et delsett av miljøet (for eksempel «gjøre disse etikettene tilgjengelige bare for disse brukerne»). Riktig styring og kommunikasjon er en viktig komponent for å unngå konflikter. Noen kunder velger å implementere en «konfigurasjon som kode»-tilnærming for å håndtere underdelegering i Microsoft Defender XDR- og Microsoft 365 Purview-samsvarsportaler. Noen spesifikke tjenester støtter underdelegering (se neste del).

Tjenestespesifikk

Som nevnt tidligere ønsker mange kunder å oppnå en mer detaljert delegeringsmodell. Et vanlig eksempel: «Administrer XYZ-tjenesten bare for divisjon X-brukere og -plasseringer» (eller en annen dimensjon). Muligheten til å gjøre dette avhenger av hver tjeneste og er ikke konsekvent på tvers av tjenester og funksjoner. I tillegg kan hver tjeneste ha en separat og unik RBAC-modell. I stedet for å diskutere alle disse modellene (noe som ville ta evig tid), legger jeg til relevante koblinger for hver tjeneste. Denne listen er ikke fullført, men den kan komme i gang.

  • Exchange Online – (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online – (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams – (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /compliance/index.yml)
    • Tillatelsesfiltrering – (.. /compliance/index.yml)
    • Samsvarsgrenser - (.. /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!

Denne koblingen er roten til dokumentasjonen. Det finnes flere typer tjenester med variasjoner i administrator-/delegeringsmodellen.

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

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

      Obs!

      det finnes flere typer med variasjoner i administrasjons-/delegeringsmodellene.

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

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

      Obs! Sikkerhet og delegering for dataplattform (som Power BI er en komponent) er et komplekst område.

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

  • Microsoft Defender for endepunkt – (/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)

  • Informasjonsbarrierer - (.. /compliance/information-barriers.md)

Aktivitetslogger

Microsoft 365 har en enhetlig overvåkingslogg. Det er en veldig detaljert logg, men ikke les for mye inn i navnet. Det kan hende den ikke inneholder alt du ønsker eller trenger for dine sikkerhets- og samsvarsbehov. Enkelte kunder er også svært interessert i revisjon (Premium).

Eksempler på Microsoft 365-logger som er tilgjengelige via andre API-er inkluderer følgende funksjoner:

Det er viktig å først identifisere alle loggkilder som kreves for et sikkerhets- og samsvarsprogram. Vær også oppmerksom på at ulike logger har ulike begrensninger for oppbevaring på linjen.

Fra administrasjonsdelegeringsperspektivet har de fleste Aktivitetslogger for Microsoft 365 ikke en innebygd RBAC-modell. Hvis du har tillatelse til å se en logg, kan du se alt i den. Et vanlig eksempel på et kundekrav er: «Jeg vil bare kunne spørre etter aktivitet for EU-brukere» (eller en annen dimensjon). For å oppnå dette kravet må vi overføre logger til en annen tjeneste. I Microsoft-skyen anbefaler vi at du overfører den til Microsoft Sentinel eller Log Analytics.

Diagram på høyt nivå:

diagram over loggkilder for et sikkerhets- og samsvarsprogram.

Diagrammet representerer innebygde funksjoner for å sende logger til Event Hubs og/eller Azure Storage og/eller Azure Log Analytics. Ikke alle systemer inkluderer denne out-of-the-box ennå. Men det finnes andre fremgangsmåter for å sende disse loggene til samme repositorium. Se for eksempel Beskytte teamene dine med Microsoft Sentinel.

Kombinasjon av alle loggene til ett lagringssted inkluderer ekstra fordeler, for eksempel krysskorrelasjoner, egendefinerte oppbevaringstider, utvidelse med data som trengs for å støtte RBAC-modellen og så videre. Når dataene er i dette lagringssystemet, kan du opprette et Power BI-instrumentbord (eller en annen type visualisering) med en passende RBAC-modell.

Logger trenger ikke å bli dirigert til bare ett sted. Det kan også være nyttig å integrere Microsoft 365-logger med Microsoft Defender for Cloud Apps eller en egendefinert RBAC-modell i Power BI. Ulike repositorier har ulike fordeler og målgrupper.

Det er verdt å nevne at det finnes et rikt innebygd analysesystem for sikkerhet, trusler, sårbarheter og så videre i en tjeneste kalt Microsoft Defender XDR.

Mange store kunder ønsker å overføre disse loggdataene til et tredjepartssystem (for eksempel SIEM). Det finnes ulike fremgangsmåter for dette resultatet, men generelt er Azure Event Hubs og Graph gode utgangspunkt.

Azure

Jeg blir ofte spurt om det finnes en måte å skille roller med høye rettigheter mellom Microsoft Entra ID, Azure og SaaS (f.eks.: Global administrator for Microsoft 365, men ikke Azure). Ikke egentlig. Arkitektur med flere leiere er nødvendig hvis fullstendig administrativ fordeling er nødvendig, men det gir betydelig kompleksitet (som nevnt tidligere). Alle disse tjenestene er en del av den samme sikkerhets-/identitetsgrensen (som vist i hierarkimodellen).

Det er viktig å forstå relasjoner mellom ulike tjenester i samme leier. Jeg jobber med mange kunder som bygger forretningsløsninger som spenner over Azure, Microsoft 365 og Power Platform (og ofte også lokale og tredjeparts skytjenester). Et vanlig eksempel:

  1. Jeg ønsker å samarbeide på et sett med dokumenter/bilder/etc (Microsoft 365)
  2. Send hver av dem gjennom en godkjenningsprosess (Power Platform)
  3. Når alle komponentene er godkjent, kan du sette sammen disse elementene til en enhetlig leveranse(er) (Azure) Microsoft Graph API er din beste venn her. Ikke umulig, men betydelig mer komplisert å utforme en løsning som spenner over flere leiere.

Azure Role-Based Access Control (RBAC) muliggjør finkornet tilgangsadministrasjon for Azure. Ved hjelp av RBAC kan du administrere tilgang til ressurser ved å gi brukerne færrest tillatelser som kreves for å utføre jobbene sine. Detaljer er utenfor omfanget for dette dokumentet, men hvis du vil ha mer informasjon om RBAC, kan du se Hva er rollebasert tilgangskontroll (RBAC) i Azure? RBAC er viktig, men bare en del av styringshensyn for Azure. Cloud Adoption Framework er et flott utgangspunkt for å lære mer. Jeg liker hvordan min venn , Andres Ravinet, veileder kundene trinn for trinn gjennom ulike komponenter for å bestemme tilnærmingen. Visning på høyt nivå for ulike elementer (ikke så god som prosessen for å komme til faktisk kundemodell) er omtrent slik:

Visning på høyt nivå av Azure-komponenter for delegert administrasjon.

Som du kan se ovenfra, bør mange andre tjenester betraktes som en del av utformingen (for eksempel Azure Policies, Azure Blueprints, Management Groups og så videre).

Konklusjon

Denne artikkelen startet som et kort sammendrag, og endte opp lenger enn jeg forventet. Jeg håper du nå er klar til å gå inn i en grundig oversikt over oppretting av delegeringsmodell for organisasjonen din. Denne samtalen er svært vanlig med kunder. Det finnes ingen modell som fungerer for alle. Venter på noen planlagte forbedringer fra Microsoft Engineering før vi dokumenterer vanlige mønstre vi ser på tvers av kunder. I mellomtiden kan du samarbeide med Microsoft-kontoteamet for å arrangere et besøk til nærmeste Microsoft Technology Center. Vi sees der!