Del via

Til identitet og videre – en arkitekts synspunkt

  • Artikel

I denne artikel drøfter Alex Shteynberg, Principal Technical Architect hos Microsoft, de vigtigste designstrategier for virksomhedsorganisationer, der bruger Microsoft 365 og andre Microsoft-cloudtjenester.

Om forfatteren

Alex Shteynberg foto.

Jeg er Principal Technical Architect i Microsoft Technology Center i New York. Jeg arbejder hovedsageligt med store kunder og komplekse krav. Mit synspunkt og meninger er baseret på disse interaktioner og gælder muligvis ikke for enhver situation. Men hvis vi efter min erfaring kan hjælpe kunder med de mest komplekse udfordringer, kan vi hjælpe alle kunder.

Jeg arbejder typisk med mere end 100 kunder hvert år. Hver organisation har unikke egenskaber, men det er interessant at se tendenser og fællestræk. En tendens er f.eks. interesse på tværs af brancher for mange kunder. Når alt kommer til alt kan en bankgren også være en kaffebar og et fællescenter.

I min rolle fokuserer jeg på at hjælpe kunderne med at nå frem til den bedste tekniske løsning til at løse deres unikke sæt forretningsmål. Officielt fokuserer jeg på identitet, sikkerhed, beskyttelse af personlige oplysninger og overholdelse af angivne standarder. Jeg elsker det faktum, at disse rører alt, hvad vi gør. Det giver mig mulighed for at blive involveret i de fleste projekter. Denne aktivitet holder mig travlt og nyder denne rolle.

Jeg bor i New York City (den bedste!) og nyder virkelig mangfoldigheden af dens kultur, mad og mennesker (ikke trafik). Jeg elsker at rejse, når jeg kan og håber at se det meste af verden i min levetid. Jeg er i øjeblikket forsker en tur til Afrika for at lære om dyrelivet.

Ledende principper

  • Enkelt er ofte bedre: Du kan gøre (næsten) alt med teknologi, men det betyder ikke, at du skal. Især i sikkerhedsområdet overengineer mange kunder løsninger. Jeg kan godt lide denne video fra Googles Stripe-konference for at understrege dette punkt.
  • Mennesker, proces, teknologi: Design for folk til at forbedre processen, ikke tech først. Der er ingen "perfekte" løsninger. Vi er nødt til at afbalancere forskellige risikofaktorer og beslutninger, der kan være forskellige for hver virksomhed. For mange kunder designer en tilgang, som brugerne senere undgår.
  • Fokuser på 'hvorfor' først og 'hvordan' senere: Vær det irriterende 7-yr gamle barn med en million spørgsmål. Vi kan ikke nå frem til det rigtige svar, hvis vi ikke kender de rigtige spørgsmål at stille. Mange kunder antager, hvordan tingene skal fungere i stedet for at definere forretningsproblemet. Der er altid flere stier, der kan udføres.
  • Lange haler af tidligere bedste praksisser: Anerkender, at de bedste fremgangsmåder ændres med let hastighed. Hvis du kiggede på Microsoft Entra for mere end tre måneder siden, er du sandsynligvis forældet. Alt her kan ændres efter udgivelsen. "Bedste" mulighed i dag er muligvis ikke det samme seks måneder fra nu.

Koncepter for oprindelig plan

Spring ikke denne sektion over. Jeg oplever ofte, at jeg skal gå tilbage til disse artikler, selv for kunder, der har brugt cloudtjenester i årevis. Desværre er sprog ikke et præcist værktøj. Vi bruger ofte det samme ord til at betyde forskellige begreber eller forskellige ord til at betyde det samme begreb. Jeg bruger ofte følgende diagram til at etablere en grundlæggende terminologi og en "hierarkimodel".

Illustration af lejer, abonnement, tjeneste og data.

Når du lærer at svømme, er det bedre at starte i poolen og ikke midt i havet. Jeg forsøger ikke at være teknisk korrekt med dette diagram. Det er en model til at diskutere nogle grundlæggende begreber.

I diagrammet:

  • Tenant = en forekomst af Microsoft Entra ID. Det er øverst i et hierarki eller niveau 1 i diagrammet. Vi kan betragte dette niveau som "grænsen", hvor alt andet forekommer (Microsoft Entra B2B til side). Alle Microsoft Enterprise-cloudtjenester er en del af en af disse lejere. Forbrugertjenester er separate. "Lejer" vises i dokumentationen som Microsoft 365-lejer, Azure-lejer, WVD-lejer osv. Jeg oplever ofte, at disse variationer skaber forvirring hos kunderne.
  • Tjenester/abonnementer, niveau 2 i diagrammet, tilhører én og kun én lejer. De fleste SaaS-tjenester er 1:1 og kan ikke flyttes uden migrering. Azure er anderledes. Du kan flytte fakturering og/eller et abonnement til en anden lejer. Der er mange kunder, der skal flytte Azure-abonnementer. Dette scenarie har forskellige konsekvenser. Objekter, der findes uden for abonnementet, flyttes ikke. Eksempelvis rollebaseret adgangskontrol (Azure RBAC), Microsoft Entra objekter (grupper, apps, politikker osv.) og nogle tjenester (Azure Key Vault, Data Bricks osv.). Overfør ikke tjenester uden et godt forretningsbehov. Nogle scripts, der kan være nyttige i forbindelse med migrering, deles på GitHub.
  • En given tjeneste har normalt en slags "grænse under niveau" eller niveau 3 (L3). Denne grænse er nyttig til at forstå for adskillelse af sikkerhed, politikker, styring osv. Desværre er der ikke noget ensartet navn, som jeg kender til. Nogle eksempler på navne på L3 er: Azure Subscription = resource; Dynamics 365 CE = forekomst; Power BI = arbejdsområde; Power Apps = miljø; og så videre.
  • Niveau 4 er stedet, hvor de faktiske data findes. Dette "datafly" er en kompleks artikel. Nogle tjenester bruger Microsoft Entra ID til RBAC, andre ikke. Jeg vil diskutere det lidt, når vi kommer til delegering artikler.

Nogle andre begreber, som jeg finder, at mange kunder (og Microsoft-medarbejdere) er forvirrede over eller har spørgsmål om, omfatter følgende problemer:

  • Alle kan oprette mange lejere uden omkostninger. Du behøver ikke at have en klargjort tjeneste i den. Jeg har mange. Hvert lejernavn er entydigt i Microsofts verdensomspændende cloudtjeneste (med andre ord kan ikke to lejere have det samme navn). De er alle i formatet TenantName.onmicrosoft.com. Der er også processer, der opretter lejere automatisk (ikke-administrerede lejere). Dette resultat kan f.eks. ske, når en bruger tilmelder sig en virksomhedstjeneste med et maildomæne, der ikke findes i nogen anden lejer.
  • I en administreret lejer kan mange DNS-domæner registreres i den. Dette resultat ændrer ikke det oprindelige lejernavn. Der er i øjeblikket ingen nem måde at omdøbe en lejer på (bortset fra overførsel). Selvom lejernavnet teknisk set ikke er kritisk i disse dage, kan nogle personer føle sig begrænset af denne virkelighed.
  • Du skal reservere et lejernavn til din organisation, selvom du endnu ikke har planer om at udrulle nogen tjenester. Ellers kan nogen tage det fra dig, og der er ingen enkel proces til at tage det tilbage (samme problem som DNS-navne). Jeg hører denne måde alt for ofte fra kunder. Det, dit lejernavn skal være, er også en debatartikel.
  • Hvis du ejer DNS-navneområdet, skal du føje alle disse navneområder til dine lejere. Ellers kan man oprette en ikke-administreret lejer med dette navn, hvilket derefter medfører afbrydelse for at få den administreret.
  • Et DNS-navneområde (f.eks. contoso.com) kan tilhøre én og kun én lejer. Dette krav har konsekvenser for forskellige scenarier (f.eks. deling af et maildomæne under en fusion eller overtagelse osv.). Det er muligt at registrere et DNS-under (f.eks. div.contoso.com) i en anden lejer, men det bør undgås. Ved at registrere et domænenavn på øverste niveau antages det, at alle underdomæner tilhører den samme lejer. I scenarier med flere lejere (som forklaret næste) vil jeg normalt anbefale at bruge et andet domænenavn på øverste niveau (f.eks. contoso.ch eller ch-contoso.com).
  • Hvem skal "eje" en lejer? Jeg ser ofte kunder, der ikke ved, hvem der i øjeblikket ejer deres lejer. Denne mangel på viden er et betydeligt rødt flag. Ring til Microsoft Support HURTIGST MULIGT. Ligesom det er problematisk, når en tjenesteejer (ofte en Exchange-administrator) er udpeget til at administrere en lejer. Lejeren indeholder alle de tjenester, du eventuelt vil have fremover. Lejerejeren skal være en gruppe, der kan træffe beslutning om aktivering af alle cloudtjenester i en organisation. Et andet problem er, når en lejerejergruppe bliver bedt om at administrere alle tjenester. Denne metode skaleres ikke for store organisationer.
  • Der findes ingen sub/super-lejer. Af en eller anden grund bliver denne myte ved at gentage sig selv. Dette koncept gælder også for Azure Active Directory B2C-lejere . Jeg hører for mange gange, "Mit B2C-miljø er i min XYZ-lejer" eller "Hvordan gør jeg flytte min Azure-lejer til min Microsoft 365-lejer?"
  • I dette dokument fokuseres der hovedsageligt på det kommercielle verdensomspændende cloudmiljø, da det er det, de fleste kunder bruger. Det kan nogle gange være nyttigt at vide om nationale cloudmiljøer. Nationale cloudmiljøer har andre konsekvenser at diskutere, som ikke er omfattet af denne diskussion.

Artikler om oprindelig identitet

Der er meget dokumentation om Microsofts identitetsplatform – Microsoft Entra ID. For folk, der lige er begyndt, det ofte føles overvældende. Selv efter at du har lært om det, kan det være en udfordring at holde dig opdateret med konstant innovation og forandring. I mine kundeinteraktioner fungerer jeg ofte som "oversætter" mellem forretningsmål og tilgange af typen "God, Bedre, Bedste" for at løse disse problemer (og menneskelige "klippenoter" for disse artikler). Der er sjældent et perfekt svar, og den "rigtige" beslutning er en balance mellem forskellige risikofaktorer. Næste er nogle af de almindelige spørgsmål og forvirringsområder, jeg har en tendens til at diskutere med kunder.

Klargøring

Microsoft Entra ID løser ikke mangel på styring i din identitetsverden! Identitetsstyring bør være et kritisk element uafhængigt af alle cloudbeslutninger. Kravene til styring ændres over tid, og derfor er det et program og ikke et værktøj.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) vs. noget andet (tredjepart eller brugerdefineret)? Gem dine problemer nu og i fremtiden, og gå med Microsoft Entra Opret forbindelse. Der er alle mulige former for smarts i dette værktøj til at håndtere særlige kundekonfigurationer og igangværende innovationer.

Nogle edge cases, der kan drive mod en mere kompleks arkitektur:

  • Jeg har flere AD skove uden netværksforbindelse mellem dem. Der er en ny indstilling kaldet Klargøring i cloudmiljøet.
  • Jeg har ikke Active Directory, og jeg vil heller ikke installere det. Microsoft Entra Opret forbindelse kan konfigureres til at synkronisere fra LDAP (partner kan være påkrævet).
  • Jeg skal klargøre de samme objekter til flere lejere. Dette scenarie understøttes ikke teknisk, men afhænger af definitionen af "samme".

Skal jeg tilpasse standardsynkroniseringsregler (filterobjekter, ændre attributter, alternativt logon-id osv.)? Undgå det! En identitetsplatform er kun lige så værdifuld som de tjenester, der bruger den. Selvom du kan udføre alle slags nøddeagtig konfigurationer, skal du se på effekten på programmer for at besvare dette spørgsmål. Hvis du filtrerer mailaktiverede objekter, er den globale adresseliste for onlinetjenester ufuldstændig. Hvis programmet er baseret på specifikke attributter, har filtrering af disse attributter uforudsigelige virkninger osv. Det er ikke en beslutning for identitetsteamet.

XYZ SaaS understøtter JIT-klargøring (Just-in-Time), hvorfor skal jeg synkronisere? Se forrige afsnit. Mange programmer har brug for "profiloplysninger" for at kunne bruges. Du kan ikke have en global adresseliste, hvis alle mailaktiverede objekter ikke er tilgængelige. Det samme gælder for brugerklargøring i programmer, der er integreret med Microsoft Entra ID.

Godkendelse

Synkronisering af adgangskodehash (PHS) vs. pass-through authentication (PTA) vs. federation.

Normalt er der en lidenskabelig debat omkring forbundet. Enklere er normalt bedre og derfor bruge PHS, medmindre du har en god grund til ikke at. Det er også muligt at konfigurere forskellige godkendelsesmetoder for forskellige DNS-domæner i den samme lejer.

Nogle kunder muliggør sammenslutning + PHS primært for:

Jeg fører ofte kunderne gennem klientgodkendelsesflowet for at tydeliggøre nogle misforståelser. Resultatet ligner følgende billede, som ikke er så godt som den interaktive proces til at komme dertil.

Eksempel på whiteboardsamtale.

Denne type whiteboardtegning illustrerer, hvor sikkerhedspolitikker anvendes i flowet for en godkendelsesanmodning. I dette eksempel anvendes politikker, der gennemtvinges via AD FS (Active Directory Federation Service), på den første serviceanmodning, men ikke på efterfølgende tjenesteanmodninger. Denne funktionsmåde er mindst én grund til at flytte sikkerhedskontrolelementer til cloudmiljøet så meget som muligt.

Vi har jagtet drømmen om enkeltlogon (SSO) så længe jeg kan huske. Nogle kunder mener, at de kan opnå enkeltlogon ved at vælge den "rigtige" udbyder af STS (Federation). Microsoft Entra ID kan hjælpe betydeligt med at aktivere SSO-egenskaber, men ingen STS er magisk. Der er for mange "ældre" godkendelsesmetoder, der stadig bruges til kritiske programmer. Udvidelse af Microsoft Entra ID med partnerløsninger kan håndtere mange af disse scenarier. SSO er en strategi og en rejse. Du kan ikke komme dertil uden at gå i retning af standarder for applikationer. Relateret til denne artikel er en rejse til adgangskodeløs godkendelse, som heller ikke har et magisk svar.

Multifactor-godkendelse (MFA) er vigtig i dag (her for mere). Føj til it-analyse af brugeradfærd , og du har en løsning, der forhindrer de mest almindelige cyberangreb. Selv forbrugertjenester flytter sig for at kræve MFA. Alligevel mødes jeg stadig med mange kunder, der ikke ønsker at flytte til moderne godkendelsesmetoder . Det største argument, jeg hører, er, at det påvirker brugere og ældre programmer. Nogle gange kan et godt kick hjælpe kunderne med at komme videre – Exchange Online annoncerede ændringer. Der er nu mange Microsoft Entra rapporter, der kan hjælpe kunder med denne overgang.

Tilladelse

Per Wikipedia er "at godkende" at definere en adgangspolitik. Mange ser på det som muligheden for at definere adgangskontrolelementer til et objekt (fil, tjeneste osv.). I den nuværende verden af cybertrusler udvikler dette koncept sig hurtigt til en dynamisk politik, der kan reagere på forskellige trusselsvektorer og hurtigt justere adgangskontrol som svar på dem. Hvis jeg f.eks. tilgår min bankkonto fra en usædvanlig placering, får jeg ekstra bekræftelsestrin. For at nærme os denne virkelighed skal vi ikke kun overveje selve politikken, men økosystemet for trusselsregistrering og signalsammenhængsmetodologier.

Politikprogrammet for Microsoft Entra ID implementeres ved hjælp af politikker for betinget adgang. Dette system afhænger af oplysninger fra andre trusselsregistreringssystemer for at kunne træffe dynamiske beslutninger. En simpel visning kan f.eks. være følgende illustration:

Politikprogram i Microsoft Entra ID.

Hvis du kombinerer alle disse signaler, kan du bruge dynamiske politikker som disse:

  • Hvis der registreres en trussel på din enhed, reduceres din adgang til data kun til internettet, uden at du har mulighed for at downloade.
  • Hvis du downloader en usædvanlig stor mængde data, krypteres og begrænses alt, hvad du downloader.
  • Hvis du tilgår en tjeneste fra en ikke-administreret enhed, er du blokeret fra meget følsomme data, men har tilladelse til at få adgang til ikke-administrerede data uden mulighed for at kopiere dem til en anden placering.

Hvis du er enig i denne udvidede definition af autorisation, skal du implementere yderligere løsninger. Hvilke løsninger, du implementerer, afhænger af, hvor dynamisk politikken skal være, og hvilke trusler du vil prioritere. Eksempler på sådanne systemer er:

Ud over Microsoft Entra ID har forskellige tjenester og applikationer deres egne specifikke godkendelsesmodeller. Nogle af disse modeller gennemgås senere i delegeringsafsnittet.

Revision

Microsoft Entra ID har detaljerede overvågnings- og rapporteringsfunktioner. Disse rapporter er dog typisk ikke den eneste kilde til oplysninger, der er nødvendige for at træffe sikkerhedsbeslutninger. Se mere diskussion om dette emne i afsnittet om delegering.

Der er ingen Exchange

Gå ikke i panik! Exchange frarådes (eller SharePoint osv.). Det er stadig en kernetjeneste. Hvad jeg mener er, at teknologiudbydere i lang tid nu har overgået brugeroplevelser (UX) til at omfatte komponenter i flere tjenester. I Microsoft 365 er et simpelt eksempel "moderne vedhæftede filer", hvor vedhæftede filer i mails gemmes i SharePoint Online eller OneDrive.

Vedhæfter en fil til en mail.

Når du ser på Outlook-klienten, kan du se mange tjenester, der er "forbundet" som en del af denne oplevelse, ikke kun Exchange. Eksempler omfatter Microsoft Entra ID, Microsoft Search, Apps, Profil, overholdelse af angivne standarder og Microsoft 365-grupper.

Outlook-grænseflade med billedforklatter.

Læs om Microsoft Fluid Framework for at få vist en prøveversion af kommende funktioner. Som prøveversion nu kan jeg læse og besvare Teams-samtaler direkte i Outlook. Faktisk er Teams-klienten et af de mere fremtrædende eksempler på denne strategi.

Samlet set bliver det sværere at tegne en klar linje mellem Microsoft 365 og andre tjenester i Microsoft-cloudmiljøer. Jeg ser det som en stor fordel for kunderne, da de kan drage fordel af total innovation på tværs af alt, hvad vi gør, selvom de bruger én komponent. Ret cool og har vidtrækkende konsekvenser for mange kunder.

I dag oplever jeg, at mange kunde-it-grupper er struktureret omkring "produkter". Det er logisk for en verden i det lokale miljø, da du har brug for en ekspert for hvert enkelt produkt. Jeg er dog glad for, at jeg ikke behøver at foretage fejlfinding af en Active Directory- eller Exchange-database igen, da disse tjenester er flyttet til cloudmiljøet. Automatisering (som clouden dybest set er) fjerner visse gentagne manuelle job (se, hvad der skete med fabrikker). Disse opgaver erstattes dog med mere komplekse krav til at forstå interaktion, effekt, forretningsbehov osv. på tværs af tjenester. Hvis du er villig til at lære, er der fantastiske muligheder, der aktiveres af cloudtransformation. Før jeg går i teknologi, taler jeg ofte med kunderne om administration af ændringer i it-færdigheder og teamstrukturer.

Til alle SharePoint-fan-personer og -udviklere skal du holde op med at spørge "Hvordan kan jeg gøre XYZ i SharePoint Online?" Brug Power Automate (eller Flow) til arbejdsprocesser. Det er en meget mere effektiv platform. Brug Azure Bot Framework til at oprette en bedre UX til din liste over 500-K-elementer. Begynd at bruge Microsoft Graph i stedet for CSOM. Microsoft Teams indeholder SharePoint, men også en verden mere. Der er mange andre eksempler, jeg kan liste. Der er et stort og vidunderligt univers derude. Åbn døren, og begynd at udforske.

Den anden fælles effekt er inden for overholdelsesområdet. Denne tilgang på tværs af tjenester ser ud til at forvirre mange politikker for overholdelse af angivne standarder. Jeg ser hele tiden organisationer med teksten "Jeg skal journale al mailkommunikation til et eDiscovery-system". Hvad betyder denne erklæring egentlig, når e-mail ikke længere blot er en mail, men et vindue til andre tjenester? Microsoft 365 har en omfattende tilgang til overholdelse af angivne standarder, men ændring af personer og processer er ofte meget vanskeligere end teknologi.

Der er mange andre mennesker og proceskonsekvenser. Efter min mening er denne faktor et kritisk og underdiskuteret område. Måske mere i en anden artikel.

Indstillinger for lejerstruktur

Enkelt lejer i forhold til flere lejere

Generelt bør de fleste kunder kun have én produktionslejer. Der er mange grunde til, at flere lejere er udfordrende (giv det en Bing-søgning) eller læse dette whitepaper. Samtidig har mange virksomhedskunder, jeg arbejder med, en anden (lille) lejer til it-læring, test og eksperimentering. Azure Lighthouse gør det nemmere at få adgang til Azure på tværs af lejere. Microsoft 365 og mange andre SaaS-tjenester har grænser for scenarier på tværs af lejere. Der er meget at overveje i Microsoft Entra B2B-scenarier.

Mange kunder ender med flere produktionslejere efter en fusion og overtagelse (M&A) og ønsker at konsolidere. I dag er det ikke enkelt og kræver Microsoft Consulting Services (MCS) eller en partner plus tredjepartssoftware. Der er løbende teknisk arbejde med at håndtere forskellige scenarier med kunder med flere lejere i fremtiden.

Nogle kunder vælger at gå med mere end én lejer. Dette bør være en omhyggelig beslutning og næsten altid forretningsårsag drevet! Nogle eksempler omfatter følgende årsager:

  • En holdingtypevirksomhedsstruktur, hvor der ikke kræves nemt samarbejde mellem forskellige enheder, og der er stærke administrative og andre isolationsbehov.
  • Efter en overtagelse træffes der en forretningsbeslutning om at adskille to enheder.
  • Simulering af en kundes miljø, der ikke ændrer kundens produktionsmiljø.
  • Udvikling af software til kunder.

I disse scenarier med flere lejere vil kunder ofte bevare en eller anden konfiguration på tværs af lejere eller rapportere om konfigurationsændringer og drifts. Det betyder ofte, at du skal flytte fra manuelle ændringer til konfiguration som kode. Microsoft Premiere support tilbyder en workshop for disse typer af krav baseret på denne offentlige IP: https://Microsoft365dsc.com.

Multi-Geo

Til Multi-Geo eller ikke til Multi-Geo. Det er spørgsmålet. Med Microsoft 365 Multi-Geo kan du klargøre og gemme inaktive data på de geografiske placeringer, du vælger at opfylde kravene til dataopbevaring . Der er mange misforståelser om denne funktion. Vær opmærksom på følgende punkter:

  • Det giver ikke ydeevnefordele. Det kan gøre ydeevnen værre, hvis netværksdesignet ikke er korrekt. Få enheder "tæt" på Microsoft-netværket, ikke nødvendigvis på dine data.
  • Det er ikke en løsning til overholdelse af GDPR. GDPR fokuserer ikke på datasuverænitet eller lagerplaceringer. Der er andre overholdelsesrammer for datasuverænitet eller lagerplaceringer.
  • Det løser ikke delegering af administration (se nedenfor) eller informationsbarrierer.
  • Det er ikke det samme som flerlejer og kræver flere arbejdsprocesser til klargøring af brugere .
  • Den flytter ikke din lejer (din Microsoft Entra ID) til et andet geografisk område.

Delegering af administration

I de fleste store organisationer er adskillelse af opgaver og rollebaseret adgangskontrol en nødvendig realitet. Jeg undskylder i forvejen. Denne aktivitet er ikke så enkel, som nogle kunder ønsker. Kunder, juridiske krav, overholdelse af angivne standarder og andre krav er forskellige og ofte modstridende over hele verden. Enkelhed og fleksibilitet er ofte på modsatte sider af hinanden. Må ikke få mig forkert, kan vi gøre et bedre stykke arbejde på dette mål. Der har været (og vil være) betydelige forbedringer over tid. Besøg dit lokale Microsoft Technology Center for at finde ud af, hvilken model der passer til dine forretningsbehov, uden at læse 379.230 dokumenter! Her fokuserer jeg på, hvad du skal tænke på, og ikke hvorfor det er på denne måde. Kommer op er fem forskellige områder at planlægge for og nogle af de almindelige spørgsmål, jeg støder på.

Microsoft Entra ID og Microsoft 365 Administration

Der er en lang og voksende liste over indbyggede roller. Hver rolle består af en liste over rolletilladelser, der er grupperet for at tillade, at bestemte handlinger kan udføres. Du kan se disse tilladelser under fanen "Beskrivelse" i hver rolle. Du kan også se en mere læsevenlig version af disse tilladelser i Microsoft 365 Administration Center. Definitionerne for indbyggede roller kan ikke ændres. Generelt grupperer jeg disse roller i tre kategorier:

  • Global administrator: Denne "alle effektive" rolle skal være meget beskyttet, ligesom du ville gøre i andre systemer. Typiske anbefalinger omfatter: ingen permanent tildeling og brug Microsoft Entra Privileged Identity Management (PIM), stærk godkendelse osv. Interessant nok giver denne rolle dig ikke adgang til alt som standard. Jeg oplever typisk forvirring om adgang til overholdelse og Azure-adgang, som drøftes senere. Denne rolle kan dog altid tildele adgang til andre tjenester i lejeren.
  • Specifikke tjenesteadministratorer: Nogle tjenester (Exchange, SharePoint, Power BI osv.) bruger administrationsroller på højt niveau fra Microsoft Entra ID. Denne funktionsmåde er ikke ensartet på tværs af alle tjenester, og der er flere tjenestespecifikke roller, der beskrives senere.
  • Funktionel: Der er en lang (og voksende) liste over roller, der fokuserer på bestemte handlinger (gæsteinvitation osv.). Med jævne mellemrum tilføjes flere af disse roller baseret på kundernes behov.

Det er ikke muligt at delegere alt (selvom afstanden mindskes), hvilket betyder, at rollen Global administrator nogle gange skal bruges. Konfiguration som kode og automatisering bør overvejes i stedet for personmedlemskab af denne rolle.

Bemærk! Microsoft 365 Administration har en mere brugervenlig grænseflade, men har en delmængde af funktioner sammenlignet med den Microsoft Entra administratoroplevelse. Begge portaler bruger de samme Microsoft Entra roller, så ændringer sker på samme sted. Tip! Hvis du vil have en administrationsfokuseret brugergrænseflade til administration af identiteter uden alt Azure-rod, skal du bruge https://aad.portal.azure.com.

Hvad er der i navnet? Angiv ikke forudsætninger ud fra navnet på rollen. Sprog er ikke et præcist værktøj. Målet bør være at definere handlinger, der skal delegeres, før du ser på, hvilke roller der er behov for. Tilføjelse af en person til rollen "Sikkerhedslæser" får dem ikke til at se sikkerhedsindstillinger på tværs af alt.

Muligheden for at oprette brugerdefinerede roller er et almindeligt spørgsmål. Denne funktion er begrænset i Microsoft Entra i dag (som forklaret senere), men vil vokse i egenskaber over tid. Jeg tænker på disse brugerdefinerede roller, som gælder for funktioner i Microsoft Entra ID og spænder muligvis ikke "ned" i hierarkimodellen (som tidligere beskrevet). Når jeg beskæftiger mig med "brugerdefineret", jeg har tendens til at gå tilbage til min principale for "enkel er bedre."

Et andet almindeligt spørgsmål er muligheden for at udvide roller til et undersæt af en mappe. Et eksempel er f.eks. "Helpdesk-administrator kun for brugere i EU". Administrative enheder er beregnet til at håndtere dette scenarie. Som tidligere beskrevet tænker jeg på disse områder som gældende for funktioner i Microsoft Entra ID og strækker sig muligvis ikke over "ned". Visse roller giver ikke mening at omfatte (globale administratorer, tjenesteadministratorer osv.).

I dag kræver alle disse roller direkte medlemskab (eller dynamisk tildeling, hvis du bruger Microsoft Entra PIM). Det betyder, at kunderne skal administrere denne rolle direkte i Microsoft Entra ID, og disse roller kan ikke være baseret på et medlemskab af en sikkerhedsgruppe. Jeg er ikke fan af at oprette scripts til at administrere disse roller, da det ville være nødvendigt at køre med øgede rettigheder. Jeg anbefaler generelt API-integration med processystemer som ServiceNow eller brug af partnerstyringsværktøjer som F.eks. Saviynt. Der er tekniske arbejde i gang for at løse dette problem over tid.

Jeg nævnte Microsoft Entra PIM et par gange. Der er en tilsvarende Microsoft Identity Manager-løsning (MIM) PAM (Privileged Access Management) til kontrolelementer i det lokale miljø. Det kan også være en god idé at se på PAWs (Privileged Access Workstations) og Microsoft Entra ID-håndtering. Der er også forskellige tredjepartsværktøjer, som kan muliggøre just-in-time, just-enough og dynamisk rolle udvidede. Denne funktion er normalt en del af en større diskussion om sikring af et miljø.

Nogle gange kaldes scenarier for at føje en ekstern bruger til en rolle (se det forrige afsnit med flere lejere). Dette resultat fungerer fint. Microsoft Entra B2B er en anden stor og sjov artikel at gå kunderne igennem, måske i en anden artikel.

Microsoft Defender XDR- og Microsoft 365 Purview-overholdelsesportaler

Mail & samarbejdsroller på Microsoft Defender-portalen og *Rollegrupper til Microsoft Purview-løsninger i Microsoft 365 Purview-overholdelsesportalen er en samling af "rollegrupper", som er separate og adskiller sig fra Microsoft Entra roller. Det kan være forvirrende, fordi nogle af disse rollegrupper har samme navn som Microsoft Entra roller (f.eks. Sikkerhedslæser), men de kan have forskellige medlemskaber. Jeg foretrækker at bruge Microsoft Entra roller. Hver rollegruppe består af en eller flere "roller" (se, hvad jeg mener om genbrug af det samme ord?) og har medlemmer fra Microsoft Entra ID, som er mailaktiverede objekter. Du kan også oprette en rollegruppe med samme navn som en rolle, som måske eller måske ikke indeholder den pågældende rolle (undgå denne forvirring).

På en måde er disse tilladelser en udvikling af modellen for Exchange-rollegrupper. Exchange Online har dog sin egen grænseflade til administration af rollegrupper. Nogle rollegrupper i Exchange Online er låst og administreret fra Microsoft Entra ID eller Microsoft Defender XDR- og Microsoft 365 Purview-overholdelsesportalerne, men andre kan have de samme eller lignende navne og administreres i Exchange Online (føjer til forvirringen). Jeg anbefaler, at du undgår at bruge Exchange Online brugergrænseflade, medmindre du har brug for områder til Exchange-administration.

Du kan ikke oprette brugerdefinerede roller. Roller defineres af tjenester, der er oprettet af Microsoft, og fortsætter med at vokse, efterhånden som nye tjenester introduceres. Denne funktionsmåde svarer i konceptet til roller, der er defineret af programmer i Microsoft Entra ID. Når nye tjenester er aktiveret, skal der ofte oprettes nye rollegrupper for at give eller delegere adgang til disse (f.eks. styring af insiderrisiko.

Disse rollegrupper kræver også direkte medlemskab og må ikke indeholde Microsoft Entra grupper. I dag understøttes disse rollegrupper desværre ikke af Microsoft Entra PIM. Ligesom Microsoft Entra roller har jeg en tendens til at anbefale administration af disse rollegrupper via API'er eller et produkt til partnerstyring som F.eks. Saviynt eller andre.

Microsoft Defender portal og microsoft 365 Purview-overholdelsesportalroller spænder over Microsoft 365, og du kan ikke bruge disse rollegrupper til et undersæt af miljøet (ligesom med administrative enheder i Microsoft Entra ID). Mange kunder spørger, hvordan de kan subdelegate. Det kan f.eks. være "kun at oprette en DLP-politik for EU-brugere". Hvis du i dag har rettigheder til en bestemt funktion på Microsoft Defender XDR- og Microsoft 365 Purview-overholdelsesportalerne, har du rettigheder til alt, der er omfattet af denne funktion i lejeren. Mange politikker har dog funktioner til at målrette et undersæt af miljøet (f.eks. "gør disse mærkater kun tilgængelige for disse brugere"). Korrekt styring og kommunikation er en vigtig komponent til at undgå konflikter. Nogle kunder vælger at implementere en "konfiguration som kode"-tilgang til at håndtere underdelegering i portalerne til Microsoft Defender XDR og Microsoft 365 Purview-overholdelse. Nogle specifikke tjenester understøtter subdelegation (se næste afsnit).

Tjenestespecifik

Som tidligere nævnt ønsker mange kunder at opnå en mere detaljeret delegeringsmodel. Et almindeligt eksempel: "Administrer kun XYZ-tjenesten for division X-brugere og -placeringer" (eller en anden dimension). Muligheden for at gøre dette afhænger af hver enkelt tjeneste og er ikke ensartet på tværs af tjenester og funktioner. Desuden kan hver tjeneste have en separat og entydig RBAC-model. I stedet for at diskutere alle disse modeller (hvilket ville tage en evighed), tilføjer jeg relevante links for hver tjeneste. Listen er ikke færdig, men den kan hjælpe dig 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)
    • Tilladelsesfiltrering – (.. /compliance/index.yml)
    • Overholdelsesgræ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/)

Bemærk!

Dette link er til roden i dokumentationen. Der er flere typer tjenester med variationer i administrations-/delegeringsmodellen.

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

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

      Bemærk!

      der er flere typer med variationer i administrations-/delegeringsmodellerne.

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

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

      Bemærk! Sikkerhed og delegering af dataplatforme (som Power BI er en komponent) er et komplekst område.

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

  • Microsoft Defender for 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)

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

Aktivitetslogge

Microsoft 365 har en samlet overvågningslog. Det er en meget detaljeret log, men læs ikke for meget ind i navnet. Den indeholder muligvis ikke alt det, du ønsker eller har brug for til dine behov for sikkerhed og overholdelse af angivne standarder. Nogle kunder er også meget interesseret i Audit (Premium).

Eksempler på Microsoft 365-logfiler, der tilgås via andre API'er, omfatter følgende funktioner:

Det er vigtigt først at identificere alle de logkilder, der er nødvendige for et program til sikkerhed og overholdelse af angivne standarder. Bemærk også, at forskellige logge har forskellige opbevaringsgrænser på stedet.

Fra administratordelegeringsperspektivet har de fleste Microsoft 365-aktivitetslogge ikke en indbygget RBAC-model. Hvis du har tilladelse til at se en log, kan du se alt i den. Et almindeligt eksempel på et kundekrav er: "Jeg vil kun kunne forespørge om aktivitet for EU-brugere" (eller en anden dimension). For at opnå dette krav skal vi overføre logge til en anden tjeneste. I Microsoft-clouden anbefaler vi, at du overfører den til enten Microsoft Sentinel eller Log Analytics.

Diagram på højt niveau:

diagram over logkilder for et sikkerheds- og overholdelsesprogram.

Diagrammet repræsenterer indbyggede funktioner til at sende logge til Event Hubs og/eller Azure Storage og/eller Azure Log Analytics. Det er endnu ikke alle systemer, der er klar til brug. Men der er andre metoder til at sende disse logge til det samme lager. Du kan f.eks. se Beskyttelse af dine Teams med Microsoft Sentinel.

Kombination af alle loggene på én lagerplacering omfatter en ekstra fordel, f.eks. tværgående korrelation, brugerdefinerede opbevaringstider, tilføjelse af data, der er nødvendige for at understøtte RBAC-modellen osv. Når dataene er i dette lagersystem, kan du oprette et Power BI-dashboard (eller en anden type visualisering) med en passende RBAC-model.

Logfiler behøver ikke kun at blive dirigeret til ét sted. Det kan også være en fordel at integrere Microsoft 365-logge med Microsoft Defender for Cloud Apps eller en brugerdefineret RBAC-model i Power BI. Forskellige lagre har forskellige fordele og målgrupper.

Det er værd at nævne, at der er et omfattende indbygget analysesystem til sikkerhed, trusler, sårbarheder osv. i en tjeneste kaldet Microsoft Defender XDR.

Mange store kunder vil overføre disse logdata til et tredjepartssystem (f.eks. SIEM). Der er forskellige tilgange til dette resultat, men generelt er Azure Event Hubs og Graph gode udgangspunkter.

Azure

Jeg bliver ofte spurgt, om der er en måde at adskille roller med mange rettigheder mellem Microsoft Entra ID, Azure og SaaS (f.eks. Global administrator for Microsoft 365, men ikke Azure). Ikke rigtig. Arkitektur med flere lejere er nødvendig, hvis fuldstændig administrativ adskillelse er påkrævet, men det medfører betydelig kompleksitet (som beskrevet tidligere). Alle disse tjenester er en del af den samme sikkerheds-/identitetsgrænse (som vist i hierarkimodellen).

Det er vigtigt at forstå relationer mellem forskellige tjenester i den samme lejer. Jeg arbejder sammen med mange kunder, der bygger forretningsløsninger, der spænder over Azure, Microsoft 365 og Power Platform (og ofte også cloudtjenester i det lokale miljø og tredjepartscloudtjenester). Et almindeligt eksempel:

  1. Jeg vil samarbejde om et sæt dokumenter/billeder/osv. (Microsoft 365)
  2. Send hver enkelt af dem via en godkendelsesproces (Power Platform)
  3. Når alle komponenter er godkendt, skal du samle disse elementer i en samlet eller samlet leverance (Azure) Microsoft Graph API er din bedste ven her. Ikke umuligt, men betydeligt mere komplekst at designe en løsning, der strækker sig over flere lejere.

Azure Role-Based Access Control (RBAC) muliggør detaljeret adgangsstyring for Azure. Ved hjælp af RBAC kan du administrere adgang til ressourcer ved at tildele brugerne færrest tilladelser til at udføre deres job. Detaljer er ikke omfattet af dette dokument, men du kan finde flere oplysninger om RBAC under Hvad er rollebaseret adgangskontrol i Azure? RBAC er vigtig, men kun en del af overvejelserne om styring af Azure. Cloud Adoption Framework er et godt udgangspunkt for at få mere at vide. Jeg kan godt lide, hvordan min ven, Andres Ravinet, guider kunderne trinvist gennem forskellige komponenter for at beslutte sig for tilgangen. Visning på højt niveau for forskellige elementer (ikke så god som processen til at få vist den faktiske kundemodel) er noget i stil med dette:

Overordnet visning af Azure-komponenter til uddelegeret administration.

Som du kan se ovenfor, bør mange andre tjenester betragtes som en del af designet (f.eks. Azure-politikker, Azure Blueprints, administrationsgrupper osv.).

Konklusion

Denne artikel startede som en kort oversigt, endte længere end forventet. Jeg håber, at du nu er klar til at gå i dybden med at oprette delegeringsmodel for din organisation. Denne samtale er meget almindelig med kunder. Der er ingen model, der fungerer for alle. Venter på et par planlagte forbedringer fra Microsoft-teknikere, før vi dokumenterer almindelige mønstre, som vi ser på tværs af kunder. I mellemtiden kan du samarbejde med dit Microsoft-kontoteam om at arrangere et besøg i det nærmeste Microsoft Technology Center. Vi ses der!