Identitete, dostop in zaupanje
PRAVICA JE POTEKLA, DOSTOP PA NE
Zakaj iztek časovno omejene skrbniške vloge ni nujno isti trenutek kot konec dejanskega dostopa v ciljni storitvi
Skrbniška vloga je potekla. Privileged Identity Management (PIM) jo prikazuje kot deaktivirano, obdobje odobrenega dostopa se je zaključilo, uporabnik pa ni več med aktivnimi imetniki te dodelitve. Kaj bi se zgodilo, če bi v že odprti seji še enkrat izvedel privilegirano operacijo?
Microsoft v navodilih za aktivacijo vlog Microsoft Entra opozarja na možnost, ki jo je pri varnostnem preverjanju lahko spregledati. PIM ob izteku ali ročni deaktivaciji v nekaj sekundah odstrani aktivno dodelitev, aplikacija pa lahko še vedno uporablja predhodno shranjen podatek o uporabnikovih pravicah. Zaradi tega mu lahko dostop ostane omogočen. Čas, v katerem aplikacija spremembo upošteva, je odvisen od njene zasnove. [1]
Kaj je poteklo in kaj lahko ostane
Časovno omejeni skrbniški dostop ima več stanj. Uporabnik je lahko upravičen do aktivacije (eligible), vendar mora za njeno izvedbo izpolniti določene pogoje: na primer opraviti dodatno preverjanje, podati utemeljitev ali pridobiti odobritev. Upravičenost sama po sebi še ni aktivna dodelitev. Šele uspešna aktivacija ustvari začasno pravico (active), katere trajanje je omejeno z nastavljeno politiko.
Po izteku PIM odstrani aktivno dodelitev. To je dogodek v ravnini upravljanja identitet. Povezana storitev medtem uporabnika ne preverja nujno ob vsakem zahtevku neposredno v isti evidenci. Lahko uporablja lastni predpomnilnik, predhodno sestavljen avtorizacijski kontekst ali podatke iz že izdanega varnostnega dokazila. Katera pot prevlada, določa izvedba konkretne storitve. [1][2]
Vloga PIM pri tem ni vedno enaka. PIM za vloge Microsoft Entra upravlja imeniške skrbniške vloge, ki lahko vplivajo na Microsoft Entra in povezane storitve. PIM za vire Azure začasno upravlja dodelitve vlog Azure RBAC na določenem obsegu, denimo naročnini, skupini virov ali posameznem viru. PIM for Groups pa ureja začasno članstvo oziroma lastništvo skupine, ki lahko posreduje dostop do drugih sistemov. Ti trije primeri ne uporabljajo nujno enake poti do končne avtorizacijske odločitve. [1][2][3]
Pri skupinah lahko nastopi še dodaten korak. Če ima aplikacija konfigurirano zagotavljanje uporabnikov in članstev s protokolom SCIM, aktivacija članstva v PIM sproži posredovanje spremembe v aplikacijo. Microsoft za posamezne faze zagotavljanja navaja časovna okna in omejitve pri obremenitvi, opozarja pa tudi, da je dejanski učinek odvisen od arhitekture ciljne aplikacije. Podatkov o aktivaciji ne smemo brez preverjanja prenesti na deaktivacijo ali na druge vrste vlog. [3]
Obstaja tudi primer, ko se dodelitev sploh ne odstrani. Microsoft Entra ne dovoljuje odstranitve zadnjega aktivnega lastnika skupine. Če bi deaktivacija začasnega lastništva pustila skupino brez aktivnega lastnika, lahko PIM nadaljuje s poskusi deaktivacije, medtem ko lastništvo ostaja veljavno. To ni zakasnela odločitev aplikacije zaradi predpomnilnika, ampak izjemno stanje pri odstranjevanju samega članstva oziroma lastništva. [3]
Med odstranitvijo vloge in naslednjo operacijo
Azure Resource Manager na primer predpomni določene avtorizacijske podatke. Microsoftova dokumentacija za Azure RBAC navaja, da lahko dodelitev ali odstranitev vloge potrebuje do deset minut, preden začne sprememba učinkovati. V opisanih primerih je mogoče osvežitev sprožiti s ponovno prijavo ali pridobitvijo novega dostopnega žetona. Dokumentacija obravnava tudi ločene izjeme, med drugim zakasnitve pri upravljanih identitetah in posebnosti podatkovnih dovoljenj na ravni upravljavskih skupin. [4]
To ni splošen desetminutni rok za vse deaktivacije PIM. Navedba se nanaša na določen model Azure RBAC. Imeniške vloge, aplikacijske vloge in skupinska članstva zahtevajo lastno razlago, saj jih lahko prepoznavajo drugi sistemi in drugi predpomnilniki.
Podobno previdnost zahteva življenjski cikel žetonov. Dostopni žeton lahko vsebuje trditve roles, wids ali groups, vendar pomenijo različne stvari. roles v ustreznem uporabniškem žetonu opisuje vloge ciljne aplikacije, wids imeniške vloge, kadar so vključene, groups pa identifikatorje članstev v skupinah. Njihova prisotnost ni zagotovljena v vsakem žetonu in ne predstavlja celotnega modela dovoljenj vseh storitev. [5]
Veljaven žeton zato ne zagotavlja uspešne privilegirane operacije, prav tako pa odstranitev aktivne vloge PIM sama po sebi ne dokazuje razveljavitve vseh izdanih žetonov, osvežitvenih žetonov ali aplikacijskih sej. Za to bi potrebovali neposredno dokumentacijo oziroma preskus določene storitve. Če storitev uporablja strežniško preverjanje pravic, lahko nova avtorizacijska odločitev zavrne zahtevek tudi z žetonom, ki še ni potekel.
Continuous Access Evaluation (CAE) na tem mestu ni univerzalna rešitev. Microsoft ga opisuje za podprte kombinacije odjemalcev in storitev, ki se odzivajo na določene kritične dogodke ali spremembe pravil Conditional Access. Med dokumentiranimi kritičnimi dogodki so onemogočenje uporabniškega računa, ponastavitev gesla, administratorski preklic osvežitvenih žetonov in nekatere druge spremembe varnostnega stanja. Iztek posamezne aktivacije PIM na tem seznamu ni naveden kot samostojen kritični dogodek. [6]
Preskus, ki se začne brez privilegija
Opazovanje uporabniškega vmesnika ni dovolj. Če je bila administrativna stran odprta pred deaktivacijo, lahko prikazuje že naložene podatke. Preskus mora sprožiti novo operacijo na ciljni storitvi, tako da nastane nova preverljiva avtorizacijska odločitev. Vnaprej moramo opredeliti, kateri API ali funkcija se preverja, kakšno dovoljenje zahteva ter kateri odziv pomeni uspeh oziroma zavrnitev.
Primeren je namenski račun z izoliranim preskusnim virom in nedestruktivno administrativno operacijo. Zanjo mora biti vnaprej preverjeno, da jo izbrana vloga dejansko omogoča, da je brez nje zavrnjena in da njena izvedba ne razkrije občutljivih podatkov. Običajno odpiranje skrbniškega portala ni primerna kontrola, saj sama prijava v vmesnik še ne zahteva vseh privilegijev za upravljanje virov.
T0 — brez aktivne vloge. Namenski račun nima preskušane dodelitve. Pregledamo tudi morebitne neposredne, podedovane in skupinske pravice, ki bi lahko omogočile isto operacijo. Izvedemo začetni zahtevek. Če operacija uspe že v tej fazi, kontrola ni ustrezna in pred nadaljevanjem odpravimo alternativno pot dostopa. Če je zavrnjena, shranimo njen dokumentirani razlog.
T1 — po aktivaciji. Aktiviramo ustrezno vlogo, izpolnimo predpisane pogoje in potrdimo veljavno aktivno dodelitev na pravem obsegu. Isto operacijo ponovimo. Uspešen zahtevek je pomemben zato, ker brez njega kasnejše zavrnitve ne bi mogli prepričljivo povezati z iztekom privilegija. Če operacija kljub aktivaciji ne deluje, najprej raziskujemo ta problem in ne nadaljujemo z navidezno meritvijo deaktivacije.
T2 — po izteku ali ročni deaktivaciji. Ločeno zabeležimo predvideni konec, stanje zahteve in potrditev, da je bila aktivna dodelitev odstranjena. Pri asinhronih postopkih ti trenutki niso nujno isti. Če je odpravljena le zahteva za aktivacijo, sama dodelitev pa ostane, preskušamo drugo stanje od tistega, ki ga opisuje naslov članka.
T3 — nov zahtevek v prvotni seji. Brez namerne odjave ali zamenjave računa pošljemo isti zahtevek in shranimo odgovor ciljne storitve. Zabeležimo tudi, ali je odjemalec medtem samodejno osvežil žeton; odprt uporabniški vmesnik še ne pomeni nespremenjenega dostopnega žetona. Če je operacija po potrjeni odstranitvi dodelitve uspešna, alternativne pravice pa so izključene, je preostali dostop za ta zahtevek neposredno izkazan.
T4 — nov prijavni kontekst. Zahtevek ponovimo po odjavi in novi prijavi oziroma po na drug način zanesljivo vzpostavljenem novem avtorizacijskem kontekstu. Če je v T3 uspešen, v T4 pa zavrnjen, smo dokazali razliko med dvema preverjenima kontekstoma. Nismo pa še dokazali, da je medtem prenehala delovati prvotna seja: zanjo bi potrebovali nov zahtevek ob primerljivem času.
Za merjenje okna preostalega dostopa je treba po T2 pošiljati enakovredne zahtevke v isti seji. Zadnji potrjeno uspešen in prvi poznejši zahtevek, zavrnjen zaradi odsotnosti privilegija, omejita interval, v katerem je dostop prenehal učinkovati. Brez neposredne meritve notranje spremembe ne poznamo natančnega trenutka. Tudi tak rezultat ostaja omejen na preverjeni račun, operacijo, vir, sejo in pot do storitve.
Dva sklopa dnevnikov, dve vrsti dokazov
PIM beleži upravljavske dogodke. Za vloge Microsoft Entra so v revizijskem dnevniku na voljo podatki o aktivacijah, odobritvah in deaktivacijah. Pri sestavljanju časovne osi je pomembna podrobnost: različne faze ene aktivacije lahko zaradi asinhrone obdelave uporabljajo različne identifikatorje CorrelationId. Microsoft za povezovanje dogodkov iste aktivacijske zahteve opisuje roleAssignmentRequestId; naveden je tudi v dodatnih podatkih dogodkov deaktivacije. [7]
Podatek o dodelitvah lahko dodatno preverimo z možnostjo Check access za Azure RBAC, ki vključuje tudi pravice, podedovane z višjih obsegov. Za primerke aktivnih dodelitev imeniških vlog je v Microsoft Graph na voljo zbirka roleAssignmentScheduleInstances. Gre za dokaze o stanju dodelitev, ki jih ne smemo zamenjati z dnevnikom avtorizacije določene operacije. [8][9]
Drugi sklop zato sestavljajo dokazi iz ciljne storitve. Potrebujemo identiteto preskusnega računa, zahtevan vir, natančno operacijo, čas zahtevka, uporabljeni sejni kontekst, identifikator zahtevka, odgovor in — kadar je na voljo — povezani strežniški razlog odločitve. Če storitev podpira revizijske dogodke, ki tak razlog dejansko zabeležijo, so ti posebej dragoceni. Tudi odsotnost zapisa ima različen pomen glede na to, ali storitev beleži vse poskuse, samo uspešne operacije ali zgolj del administrativnih zahtevkov.
Sama koda HTTP ni vedno zadosten dokaz. 401 Unauthorized po standardu HTTP pomeni, da zahtevek nima veljavnih avtentikacijskih podatkov za zahtevani vir, 403 Forbidden pa, da je strežnik zahtevo razumel in je ne želi izpolniti. Toda aplikacija lahko za svojo odločitev uporablja še lastne kode in razlage. Če je T3 zavrnjen zgolj zaradi poteklega žetona, še nismo dokazali, da je storitev ob preverjanju pravic zaznala iztek preskušane vloge. [10]
Dnevnike je treba povezovati tudi časovno. Trenutek dogodka, čas zapisa in čas prevzema v centralno zbirko niso nujno enaki. Pri več virih preverimo časovne pasove, sinhronizacijo ur in semantiko posameznega polja. Zgolj zaporedje prikazanih časovnih žigov brez tega preverjanja lahko ustvari navidezno natančnost.
Predpomnilnik ni edina razlaga
Uspeh po deaktivaciji lahko izvira iz povsem veljavnega drugega pooblastila. Uporabnik morda ohranja neposredno dodelitev na višjem obsegu, članstvo v drugi skupini ali posebno aplikacijsko vlogo. Pri takšni konfiguraciji ciljna storitev ne krši pravil, ko zahtevek sprejme. Neuspešna bi bila naša domneva, da je bila odstranjena edina pot do dovoljenja.
Varnostni pomen morebitnega okna je odvisen od tega, kaj je uporabnik v njem lahko storil. Branje neobčutljive preskusne nastavitve ne predstavlja enakega tveganja kot spreminjanje pravic drugih uporabnikov, varnostnih nastavitev ali produkcijskih podatkov. Ocena mora zato povezati trajanje, obseg in naravo dosegljivih operacij, namesto da bi iz enega časovnega zamika izpeljala enotno stopnjo tveganja.
Dokaz zadnje zavrnjene operacije
Kateri dokaz pokaže, da uporabnik po izteku pravice ne more več izvesti konkretnega privilegiranega dejanja? Najmočnejši razpoložljivi dokaz je ponovljiva, dokumentirana zavrnitev novega zahtevka, ki je bil med aktivacijo uspešen, po potrjeni odstranitvi dodelitve pa ga je ciljna storitev zavrnila zaradi odsotnosti preskušanega dovoljenja. Pri tem morajo biti izločeni drugi možni vzroki zavrnitve, predvsem težave z avtentikacijo, nedostopnost vira ali napačen obseg.
Takšen dokaz ima svoje meje. Zajema preverjeno identiteto, operacijo, vir, prijavni kontekst in trenutek. Ne dokazuje samodejno, da so istočasno prenehale delovati vse druge seje ali da enako ravnajo vse povezane aplikacije. Za širšo trditev so potrebni širši preizkusi in dodatni dnevniki.
Pri upravljanju časovno omejenih privilegijev je zato smiselno poleg začetka in konca aktivne dodelitve spremljati še njen dejanski učinek. Če organizacija zna zabeležiti samo iztek vloge, pozna čas upravljavske spremembe. Kdaj je ciljna storitev prenehala dovoljevati naslednjo privilegirano operacijo, ostaja odprto vprašanje, dokler ga ne preveri na drugi strani zahtevka.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01PRIMARY DOCUMENTATIONMicrosoft LearnActivate a Microsoft Entra role in PIM
Uvod, Important: odstranitev aktivne dodelitve in predpomnjen dostop aplikacije.
Odpri vir ↗ - 02PRIMARY DOCUMENTATIONMicrosoft LearnActivate Azure resource roles in PIM
PIM za vire Azure; aktivacija in deaktivacija vlog.
Odpri vir ↗ - 03PRIMARY DOCUMENTATIONMicrosoft LearnPrivileged Identity Management (PIM) for Groups
PIM for Groups and ownership deactivation; Privileged Identity Management and app provisioning.
Odpri vir ↗ - 04PRIMARY DOCUMENTATIONMicrosoft LearnTroubleshoot Azure RBAC
Role assignment changes are not being detected; posebnosti upravljanih identitet in obsega upravljavskih skupin.
Odpri vir ↗ - 05PRIMARY DOCUMENTATIONMicrosoft LearnAccess token claims reference
Payload claims: roles, wids, groups.
Odpri vir ↗ - 06PRIMARY DOCUMENTATIONMicrosoft LearnContinuous access evaluation
Critical event evaluation; Conditional Access policy evaluation.
Odpri vir ↗ - 07PRIMARY DOCUMENTATIONMicrosoft LearnView audit log report for Microsoft Entra roles in PIM
Correlating events related to the same activation cycle; roleAssignmentRequestId.
Odpri vir ↗ - 08PRIMARY DOCUMENTATIONMicrosoft LearnCheck access for a user to a single Azure resource
Check access for a user; neposredne in podedovane dodelitve.
Odpri vir ↗ - 09PRIMARY DOCUMENTATIONMicrosoft GraphList roleAssignmentScheduleInstances (v1.0)
API za imeniške primerke aktivnih dodelitev vlog.
Odpri vir ↗ - 10STANDARDIETFRFC 9110: HTTP Semantics
Razdelka 15.5.2 in 15.5.4: semantika odgovorov HTTP 401 in 403.
Odpri vir ↗