Pregled migracije v Entri: dokažite umik skrivnosti odjemalca

Delujoča upravljana identiteta ali federirana poverilnica še ne dokazuje, da je nekdanja skrivnost odjemalca umaknjena. Preglejte vse nameščene porabnike in vse poverilnice z geslom, ki jih upravlja organizacija, znotraj opredeljenega obsega. Ločeno zabeležite tri izide: poverilnica umaknjena, migracija izvajalnih okolij zaključena in izjema odprta. Za dokončen zaključek morata biti izpolnjena prva dva pogoja, izpostavljenost zaradi že izdanih žetonov mora biti odpravljena, odprtih izjem pa ne sme biti.

Microsoft priporoča prehod z avtentikacije z gesli ali potrdili na upravljane identitete in federacijo identitet delovnih obremenitev, kjer sta podprti. Gre za obstoječa navodila za migracijo, ne za novo napovedan rok za umik. Spodnja merila so predlog postopka pregleda v tem članku, ne Microsoftov certifikacijski standard. Microsoftova navodila za migracijo

Opredelite obseg in izide

Objekt aplikacije opisuje aplikacijo; storitvena identiteta (service principal) jo predstavlja v posameznem najemniku. Upravljana identiteta je posebna storitvena identiteta, pri kateri razvijalcem ni treba upravljati poverilnic. Te razlike določajo, katere objekte in izvajalna okolja mora pregled zajeti. Pregled identitet delovnih obremenitev

Pred zbiranjem dokazov zapišite trditev: »Za navedene najemnike, objekte aplikacij in storitvene identitete so ob času T umaknjene vse poverilnice z geslom, ki jih upravlja organizacija in so jih navedene namestitve prej lahko uporabljale; vsak navedeni porabnik zdaj uporablja nadomestno metodo Y.« Zajamite produkcijo, predprodukcijska okolja, razporejena opravila, avtomatizacijo, obnovitvene namestitve in vse druge porabnike teh identitet. Za vsakega navedite ciljne vire in pričakovano nadomestno identiteto.

Izide uporabljajte dosledno:

Poverilnica je lahko umaknjena, migracija izvajalnih okolij pa še ni zaključena. Odstranjeno skrivnost lahko na primer še vedno navaja obnovitvena namestitev, ki ob zagonu ne bo delovala. Obratno lahko vsa izvajalna okolja uporabljajo federacijo, neuporabljena veljavna skrivnost pa ostane. Nobeno od teh stanj ne omogoča dokončnega zaključka.

Popišite obe mesti za poverilnice

Preglejte passwordCredentials na objektu aplikacije in vseh ustreznih objektih storitvenih identitet v najemnikih, ki so vključeni v pregled. Izvoz samo iz registracije aplikacije ne zadošča. Microsoft Graph omogoča pregled poverilnic z geslom pri obeh vrstah objektov. Dokumentacija objekta servicePrincipal opisuje zbirko poverilnic na objektu storitvene identitete v posameznem najemniku. Dokumentacija objekta servicePrincipal

Za vsak vnos zabeležite ID najemnika, vrsto in ID objekta, ID aplikacije oziroma odjemalca ter keyId, startDateTime in endDateTime poverilnice. Dodajte odgovorno osebo, porabnike, čas popisa in zapis spremembe. Ta polja določajo identiteto in veljavnost poverilnice; z običajnim popisom ni mogoče pridobiti izvirne vrednosti skrivnosti.

Popis izvedite pred spremembo in po njej. Poverilnice z geslom, ki jih upravlja organizacija, odstranite z objektov, ki jim dejansko pripadajo. Graph ponuja ločeni operaciji application removePassword in servicePrincipal removePassword; obe poverilnico določita s poljem keyId. Operacija za storitveno identiteto je opisana v dokumentaciji servicePrincipal removePassword. Shranite rezultat operacije in poznejši popis, ki potrjuje odsotnost poverilnice. Zaradi urejenosti odstranite tudi pretečene vnose; sam potek veljavnosti ni dokaz odstranitve, ki ga zahteva ta postopek.

Poverilnic upravljanih identitet, za katere skrbi platforma, ne vključujte na ta seznam za brisanje. Objektov storitvenih identitet vrste ManagedIdentity ni mogoče neposredno spreminjati kot običajnih storitvenih identitet aplikacij. Stare poverilnice, ki jih upravlja organizacija, preglejte ločeno od nadomestne identitete. Vrste storitvenih identitet

Dokažite uporabo nadomestne metode

V nadzorovanem oknu za uvedbo izrecno izberite upravljano identiteto ali federacijo. Za preizkus onemogočite druge možnosti v verigi poverilnic in staro rezervno pot. Uporabite izoliranega odjemalca ali podprt mehanizem knjižnice za obhod predpomnilnika. Zahtevajte dokaz, da je avtentikacija res potekala prek izbranega ponudnika; sam ponovni zagon procesa ne zadošča, če ostane drug predpomnilnik.

Pri federaciji povežite nameščeno konfiguracijo ponudnika in metapodatke zaupanja z novo izmenjavo potrditve identitete (assertion). Shranite dokaze brez občutljivih vrednosti: izbrano metodo, izdajatelja, subjekt, občinstvo, čas in identifikatorje zahtev. Pri upravljani identiteti zabeležite izbrano identiteto in dokaz, da je izvajalno okolje uporabilo ponudnika upravljane identitete. Če predpomnjenje na platformi preprečuje dokazovanje nove izdaje žetona, navedite omejitev in zahtevo po sveži avtentikaciji pustite neizpolnjeno. Poročilu nikoli ne prilagajte potrditev identitete ali žetonov za dostop.

Nato to avtentikacijo povežite z identiteto, ki jo je zaznal vir, in uspešno izvedbo zahtevanih operacij. Ista storitvena identiteta se lahko avtenticira s skrivnostjo ali federacijo, zato sam ID aplikacije ne razkrije metode. Tudi uspešen klic vira s starim predpomnjenim žetonom ne preizkusi nadomestne metode. Microsoft opisuje različne tokove uporabe poverilnic in diagnostiko izvora žetona v MSAL. Tokovi uporabe poverilnic odjemalca, odpravljanje težav v MSAL

Avtorizacija na viru ostaja ločeno preverjanje. API-ji z aplikacijskimi dovoljenji morajo preverjati zahtevane vloge. API-ji s seznami za nadzor dostopa (ACL) lahko sprejmejo aplikacijske žetone brez roles, vendar morajo uveljavljati lastna preverjanja avtorizacije. Delegirani obsegi scp ne nadomestijo avtorizacije aplikacije brez uporabnika. Microsoftovi modeli avtorizacije API-jev

Negativni preizkus naj bo ponovljiv

Po postopku v tem članku negativni preizkus izpolni merilo samo, če se ujemajo vsi naslednji dokazi:

1. Potrdite izvor vrednosti. Točno določeno različico skrivnosti iz shrambe, ki jo je uporabljala namestitev, povežite z njenim objektom in keyId na podlagi zapisov o ustvarjanju poverilnice in uvajanju. Če je pred odstranitvijo še mogoče in odobreno, z isto vrednostjo in istim preizkusnim orodjem potrdite uspešno pridobitev novega žetona kot izhodišče. Izbrisane poverilnice ne ustvarjajte znova zaradi preizkusa. Če povezave ali vrednosti ni mogoče pridobiti, označite preizkus kot nedokazan.
2. Preverite zahtevo. Uporabite pravilnega najemnika, ID odjemalca, vir in končno točko za okolje. Pri končni točki v2 pošljite zahtevo v obliki kodiranega obrazca z grant_type=client_credentials, obsegom /.default ciljnega vira in pravilno kodirano vrednostjo skrivnosti. Identifikator poverilnice ni vrednost skrivnosti. Specifikacija zahteve za žeton
3. Po odstranitvi zahtevajte nov žeton. Obidite predpomnilnike žetonov in potrdite, da je zahteva dosegla Entro. Preizkus nujno pošlje staro poverilnico neposredno Entri prek TLS. Preprečite njeno razkritje v zgodovini ukazov, dnevnikih teles zahtev, diagnostičnih sledeh, poročilih, posnetkih zaslona ali zahtevkih.
4. Razvrstite zavrnitev. Zahtevajte zavrnitev zaradi poverilnice, ki je skladna z odstranitvijo ter podprta s skrbniškimi dokazi in preverjeno zahtevo. Sam splošen rezultat invalid_client ne zadošča. Napačen najemnik ali odjemalec, napake kodiranja, manjkajoči parametri, blokada pogojnega dostopa, omrežne napake, omejevanje zahtev in neuspešna avtorizacija na viru ne omogočajo sklepa o umiku.
5. Ohranite povezljivost dokazov. Shranite napako OAuth, diagnostično kodo napake, čas, korelacijski ID, vrnjeni ID zahteve oziroma sledi, metapodatke poverilnice, različico preizkusnega orodja in pregledovalca. Odstranite vrednosti skrivnosti, ohranite pa identifikatorje, potrebne za povezovanje zapisov.

Dejanski odgovor razložite s pomočjo Microsoftovih navodil za odpravljanje težav; diagnostične kode se lahko spremenijo, zato iz njih ne oblikujte trajnega seznama številčnih kod za samodejno potrjevanje zaključka. Odpravljanje težav pri zaupnih odjemalcih

Uspešna izdaja žetona pomeni, da merilo za umik ni izpolnjeno. Tudi zavrnitev zaradi poverilnice brez zanesljivega izvora vrednosti ali dokaza odstranitve ne izpolni dokaznega merila. Če preizkusa ni mogoče varno dokončati, pustite izjemo odprto; uporabne skrivnosti ne hranite nedoločen čas samo zato, da bi pridobili rezultat preizkusa.

Ločite izvedljivo rezervno pot od zgodovinskega gradiva

Preglejte nameščeno konfiguracijo, reference na shrambe skrivnosti, spremenljivke CI/CD, infrastrukturne predloge, razporejevalnike, logiko ponovnih poskusov in navodila za obnovo. Zajamite prednostni vrstni red nastavitev in preglasitve za posamezna okolja. Trenutno neaktivna namestitev, ki še lahko izvede staro pot, je rezervna pot in preprečuje zaključek migracije izvajalnih okolij.

Neaktivna zgodovinska kopija že umaknjene poverilnice je ugotovitev za čiščenje, ne dokaz, da avtentikacija še deluje. Zabeležite njeno mesto, po potrebi omejite dostop in preprečite obnovitev v izvedljivo konfiguracijo. Ne trdite, da pregled repozitorija dokazuje izginotje vseh kopij. Microsoft priporoča pregledovanje skrivnosti in zaščito pred njihovim vnosom ob potiskanju kode kot trajna zaščitna ukrepa. Navodila za migracijo

Obravnavajte že izdane žetone

Brisanja poverilnice ne obravnavajte kot takojšen preklic že izdanih dostopnih žetonov. Microsoft odjemalcem naroča, naj uporabijo vrnjene podatke o veljavnosti, kot je expires_in, namesto da predpostavljajo stalno trajanje. Navodila o veljavnosti žetonov

Za zaključek dokumentirajte zadnji možni čas izdaje in utemeljeno zgornjo mejo veljavnosti za vsak prizadeti vir, pri čemer upoštevajte veljavne nastavitve trajanja in dovoljeno odstopanje ur. Potek enega opaženega žetona ne določa meje za vse še veljavne žetone. Preostalo izpostavljenost označite kot odpravljeno šele po preteku dokumentirane meje ali ko ustrezen ukrep na viru dokazano blokira te žetone. Če ni mogoče potrditi ne enega ne drugega, pustite izjemo odprto. Nadzor podpira te dokaze; poljubno dolgo obdobje brez zaznanih dogodkov jih ne nadomesti.

Pogojni dostop za delovne obremenitve lahko glede na lokacijo ali tveganje blokira upravičene storitvene identitete enonajemniških aplikacij, registrirane v vašem najemniku. Upravljane identitete in večnajemniške aplikacije so izključene. Za ustvarjanje ali spreminjanje teh pravilnikov potrebujete licence Microsoft Entra Workload ID Premium. Storitveno identiteto dodelite neposredno pravilniku. Ti ukrepi ne dokazujejo odstranitve poverilnice. Obseg in licenciranje pogojnega dostopa

CAE za delovne obremenitve trenutno podpira v najemniku registrirane storitvene identitete enonajemniških aplikacij pri dostopu do Microsoft Graph; upravljane identitete, zunanje aplikacije SaaS in večnajemniške aplikacije so izključene. Odjemalec mora navesti cp1 in obravnavati zahteve za dodatne trditve (claims challenges). Dokumentirani dogodki preklica so onemogočitev ali izbris storitvene identitete in visoko tveganje; podprte so tudi spremembe pravilnikov za lokacijo in tveganje. Brisanje skrivnosti ni naveden dogodek preklica. Dokumentacija CAE za delovne obremenitve

Ponazoritveni zapis za zaključek

Spodaj je izmišljen dokazni zapis, ne rezultat pregleda pri stranki. Kratke oznake predstavljajo polne identifikatorje, shranjene v dejanskem zapisu.

Če odkrijete dodatno poverilnico, najemnika ali porabnika, razširite zapis in pred zaključkom ponovite ustrezna preverjanja. Za nerešeno odvisnost določite odgovorno osebo in rok odprave, omejite shranjevanje skrivnosti ter dokumentirajte menjavo in nadzor. Odobritev potrjuje sprejem izjeme; ne spremeni je v zaključen ukrep.

Ta preverjanja so lahko del širšega pregleda varnosti v oblaku (stran v angleščini). Poročilo mora sklep še vedno omejiti na navedene objekte, porabnike, vire in datum dokazov. Ne more dokazati, da skrivnost nikoli ni bila kopirana ali da so nepregledana okolja brez težav.

Pogosta vprašanja

Ali zadošča izbris kopije iz Key Vaulta?

Ne. Potrdite odstranitev z objekta v Entri, ki mu poverilnica pripada, izvedite negativni preizkus te poverilnice in preglejte vse porabnike v obsegu. Čiščenje shrambe, umik poverilnice in migracija izvajalnih okolij so ločena preverjanja.

Ali lahko zaključimo, ko upravljana identiteta ali federacija deluje?

Šele ko sveža avtentikacija dokaže izbrano metodo, vse poverilnice v obsegu izpolnijo postopek umika, noben porabnik nima izvedljive stare rezervne poti in je izpostavljenost zaradi že izdanih žetonov odpravljena. Odobrena izjema preprečuje dokončen zaključek.

Ali neuspešna zahteva dokazuje umik?

Ta postopek izpolni samo pravilno sestavljena nova zahteva s preverjeno staro vrednostjo, pri kateri je zavrnitev zaradi poverilnice povezana z dokazom odstranitve. Druge napake ne omogočajo sklepa o umiku.

Ali stara skrivnost v zgodovini repozitorija preprečuje zaključek?

Neaktivna kopija dokazano umaknjene poverilnice sama po sebi ne preprečuje zaključka. Čiščenje spremljajte ločeno. Veljavna poverilnica ali namestitvena pot, ki lahko naloži staro konfiguracijo, pa zaključek preprečuje.

Nadaljnje branje

• Varnost Active Directory