UTCM i graf (beta) 

Det manglende primitive element til lejerstyring

"Nogen ændrede en politik for betinget adgang klokken 2 om natten." 

Den sætning er kedelig, indtil den er den første linje i en hændelsesrapport. 

De fleste organisationer har allerede arbejdsgange for ændringsstyring, godkendelser, supportsager og privilegeret adgang.

Hvad de sjældent har, er et pålideligt, automatiseret svar på et enkelt spørgsmål: 

Hvad der er ændret i vores Microsoft 365-lejer på tværs af alle de steder der betyder noget, siden vi sidst tjekkede? 

I slutningen af ​​januar 2026 introducerede Microsoft en forhåndsvisning af Unified Tenant Configuration Management (UTCM) API'er i Microsoft Graph (/beta). Løftet er ligetil: lav en baseline for din lejerkonfiguration, overvåg den efter en fast tidsplan, og registrer konfigurationsforskydninger på tværs af flere arbejdsbelastninger via én samlet API-overflade.  

Hvis du er CISO, CTO eller en sikkerhedsbevidst rådgiver, er den strategiske værdi ikke "endnu en API". Det er en platformfunktion, der flytter lejerstyring fra håber intet har ændret sig til vide præcis hvad der ændrede sig– og at kunne bevise det. 

Først den uundgåelige virkelighed: det er Graph beta 

Microsoft er tydelig: Graph/beta API'er kan ændres og understøttes ikke til produktionsbrug.  

Det betyder ikke "ignorer det". Det betyder: 

  • Behandl dette som en offentlig forhåndsvisningssignal hvor lejerstyringen er på vej hen. 
  • Brug den til at bygge operationel beredskab (proces, grundlæggende tænkning, monitordesign). 
  • Styr sikkert ind ikke-produktionslejere eller scenarier med begrænset omfang, indtil v1.0 ankommer. 

Hvis du træffer beslutninger for regulerede miljøer, er dette vigtigt: du kan begynde at forme din styringsmodel nu, uden at satse dine produktionskontroller på forhåndsvisningsslutpunkter. 

Hvad UTCM er, kort fortalt 

UTCM giver administratorer API'er til kontrollere og administrere konfigurationsindstillinger på tværs af en enkelt arbejdsbelastning eller flere arbejdsbelastninger i en organisation.

Rent praktisk introducerer UTCM en livscyklus, du kan automatisere: 

  1. Snapshot nuværende konfigurationstilstand (en basiskandidat). 
  2. Definer dette snapshot/denne baseline som den "ønskede" konfiguration. 
  3. Opret en overvåge der revurderer lejeren efter en tidsplan. 
  4. Anmeldelse overvågningsresultater og driver (afvigelser fra ønsket tilstand). 
  5. Afhjælp ved hjælp af de relevante administrationscentre eller andre metoder (UTCM handler primært om synlighed og detektion lige nu).  

Dagens forhåndsvisning understøtter arbejdsbelastninger, herunder Microsoft Defender, Entra, Exchange Online, Intune, Purview og Teams, med mere end 300 ressourcetyper refereret via et publiceret skema.  

1) Autorisation: hvorfor dette ikke er "bare ring til Graph"

UTCM har en specifik forudsætning: Du skal tilføje UTCM-tjenesteprincipalen til din lejer og give den tilladelser. før du bruger lejerkonfigurations-API'erne.

Microsoft beskriver to niveauer af godkendelse:

  • Godkend til Microsoft Graph med en principal, der kan administrere skærme eller starte snapshots. 
  • Konfigurer hvordan skærme kører, fordi Når en monitor udføres, efterligner den en UTCM-specificeret principal.  

Microsoft dokumenterer også en officiel UTCM-tjenesteprincipal ("Unified Tenant Configuration Management") med et specifikt program-ID (under den offentlige prøveversion) og giver trin til at oprette den og tildele approller/tilladelser.

Hvorfor du skal bekymre dig: Dette er en kontrolflade for styring. Hvis dit team konfigurerer den tilfældigt, risikerer du at skabe "endnu en stærk identitet". Hvis du konfigurerer den bevidst, får du et fundament for afvigelsesdetektion, der stemmer overens med minimumsrettigheder, revision og ændringskontrol.

2) Lejerovervågnings-API'er: Driftdetektion som en førsteklasses borger

API'er til lejerovervågning tillad administratorer at:

  • Opret en eller flere skærme 
  • Gennemgå overvågningsresultater 
  • Få oplysninger om alle aktive drifter i lejeren  

Effekten er enkel: Du kan registrere afvigelser fra din ønskede konfiguration uden manuelt at sammenligne administrationscentre, scripts, eksport eller skærmbilleder. 

Det er præcis den slags operationel kapacitet, der reducerer "ukendte ubekendte faktorer" i en cloud-lejer, især når flere teams administrerer Entra, Exchange, Intune, Teams og sikkerheds-/compliance-indstillinger. 

3) Snapshot API'er: baseline lejeren, deklarativt 

snapshot-API'er Lad administratorer udtrække aktuelle konfigurationsindstillinger og bruge dette øjebliksbillede som grundlag for periodisk overvågning.  

Microsofts framing er vigtig: UTCM sigter mod at give en deklarativ repræsentation af lejerkonfiguration – ikke kun nyttigt til afvigelsesdetektion, men også til revisionsmuligheder og fejlfinding.  

Med andre ord: Du indsamler ikke bare data. Du bygger et eksplicit "sådan har vi til hensigt, at lejeren skal konfigureres"-artefakt. 

4) Almindelige anvendelsesscenarier: hvad du kan gøre i dag 

Microsoft viser almindelige UTCM-brugsscenarier, der er knyttet til ressourcer. 

  • Få en baseline og opret et snapshot-job (konfigurationsgrundlinje) 
  • Liste og få drifter (konfigurationDrift) 
  • Opret og administrer skærme (konfigurationsskærm) 
  • Liste og få overvågningsresultater (konfigurationOvervågningsresultat) 
  • Liste/hente/slette snapshot-job (konfigurationsSnapshotJob) 

Hvis du ønsker en oversættelse fra en beslutningstager: 

  • "Kan vi bevise vores lejer matcher vores sikkerhedsgrundlag? 
  • "Kan vi se Hvad ændrede sig, hvornår ændrede det sig, og hvad afveg det fra?” 
  • "Kan vi betjene Lejerkonfiguration som et kontrolleret system, ikke en delt whiteboard?” 

De dele, der afgør, om dette bliver operationelt virkeligt

A) Grænser, der former din overvågningsstrategi 

UTCM's forhåndsvisning har klare begrænsninger: 

  • Op til 30 skærme pr. lejer 
  • Hver skærm kører hver seks timer (ikke konfigurerbar) 
  • En lejer kan overvåge op til 800 konfigurationsressourcer pr. dag på tværs af alle skærme 
  • Opdatering af en baseline for en eksisterende monitor sletter tidligere overvågningsresultater og afvigelser for den pågældende monitor  

Til afdrift:

  • Aktive drifter er stadig tilgængelige til gennemgang 
  • Faste drifter slettes 30 dage efter løsning  

For snapshots:

  • Op til 20,000 ressourcer pr. lejer pr. måned udtrukket på tværs af alle snapshots 
  • Kun 12 snapshot-job synlige ad gangen (slet ældre job for at oprette flere) 
  • Et øjebliksbillede gemmes for syv dage  

Hvorfor det betyder noget Du er tvunget til at være bevidst. Du kan ikke "overvåge alt, altid" uden at designe, hvordan du bruger kvoten. For mange organisationer er det en funktion, ikke en fejl, fordi det får dig til at definere, hvad der virkelig hører hjemme i en baseline. 

B) Hvor dette passer, hvis du brugte Microsoft 365DSC

Mange sikkerheds- og platformteams har benyttet sig af community-værktøjer og -mønstre (især Microsoft365DSC) til at eksportere og sammenligne konfiguration. Microsoft365DSC-projektet beskriver selv UTCM (også kaldet Tenant Configuration Management API'er) som officiel, understøttet retning, idet man bemærker, at fokus i forhåndsvisningen er eksport/snapshot og driftdetektion, med forventede afhjælpningsmuligheder senere.  

Dette er skiftet: styringsmønstre-som-kode, der bevæger sig fra "best-effort scripting" til "platformkapacitet". 

C) Hvordan "god" ser ud for en CISO/CTO 

Værdien er ikke API'en. Værdien er den driftsmodel, du kan bygge op omkring den: 

  • En grundlinje, der repræsenterer dine risikobeslutninger (ikke et generisk benchmark). 
  • Driftdetektion, der føder hændelsesrespons og ændre kontrol. 
  • Revisionsbeviser, der er reproducerbare og mindre afhængige af, "hvem klikkede på hvad". 

Når UTCM når v1.0-modenhed, har det potentiale til at blive en kerneprincip for lejerstyring: opdage afvigelser tidligt, reducere konfigurationsusikkerhed og forkorte tiden mellem "noget ændret" og "vi forstår virkningen". 

Praktiske eksempler (dem der bliver til hændelser) 

Disse er de scenarier, som UTCM er bygget til at fange: 

  • A Betinget adgang Politikændringer uden for din proces → afvigelse registreret. 
  • An Regel om udvekslingstransport er ændret uden godkendt ændring → afdrift registreret. 
  • An Intune-overholdelse eller sikkerhedspolitikken er svækket "midlertidigt" → afdrift registreret. 

Dette er ikke hypotetisk. Drift i lejerkonfiguration er en af ​​de mest almindelige tavse bidragydere til sikkerhedsregressioner i Microsoft 365-miljøer. UTCM gør det til noget målbart. 

Bundlinjen 

UTCM i Graph beta er en forhåndsvisning, men det er også et klart signal: Microsoft er ved at opbygge et samlet, deklarativt konfigurationsstyringslag til flere arbejdsbelastninger til Microsoft 365.  

Hvis du har indflydelse på sikkerhedsstrategien, er det nu, du skal: 

  • Identificér, hvad der hører til i din lejerbaseline, 
  • Definer hvordan drift skal vurderes og kontrolleres, 
  • Og forbered dig på at implementere UTCM, når det når produktionsunderstøttede slutpunkter. 

Fortytwo er i spidsen for udviklingen af ​​muligheder og tjenester omkring ny funktionalitet i Microsoft Universe.

Brug for hjælp eller vil du vide mere? Kontakt os.

Vi ved, at efterspørgslen ikke er efter "flere indstillinger", men efter styret sikkerhed

Rul til top