RAČUN NI OSEBA

Septembra 2026 je Microsoft opisal več vdorov v oblačna okolja, pri katerih so nenavadnim prijavam sledile spremembe načinov preverjanja pristnosti, dejavnosti prek Microsoft Grapha, dostopi do SharePointa in OneDrivea ter zbiranje elektronske pošte. Posamezen dogodek pri tem ni povedal dovolj. Pomembno je bilo zaporedje in povezovanje zapisov iz različnih delov okolja. [1]

Tak primer pokaže težavo, ki jo pri vsakdanjem branju dnevnikov zlahka spregledamo. Če je ob dogodku zapisano uporabniško ime, ga hitro prevedemo v stavek, da je dejanje izvedel njegov lastnik. Sistem pa je v resnici zabeležil uporabo določene digitalne identitete v določenem tehničnem kontekstu. Kdo je bil dejansko za njo, je v nekaterih primerih mogoče ugotoviti zelo zanesljivo, v drugih pa je treba pogledati precej dlje od enega polja v dnevniku.

Pri običajnem delu te razlike skoraj ne opazimo. Uporabnik se prijavi, opravi delo in se odjavi, tehnična sled pa se smiselno ujema z njegovim ravnanjem. Šele incident, nenavadna sprememba ali sporno dejanje pokažejo, koliko različnih pomenov smo dotlej združevali v preprosto besedo »uporabnik«.

Kaj sistem pravzaprav prepozna

Digitalna identiteta informacijskemu sistemu omogoča, da razlikuje med subjekti, jim dodeljuje pravice in njihovo dejavnost povezuje z revizijskimi zapisi. Pri uporabniškem računu je ta identiteta praviloma organizacijsko povezana s konkretno osebo, vendar povezava med obema ni isto kot neposredno opazovanje človekovega ravnanja.

NIST SP 800-63-4 področje digitalne identitete razdeli na več povezanih procesov, med drugim preverjanje identitete, vpis, upravljanje authenticatorjev, avtentikacijo in federacijo. SP 800-63B-4 se podrobneje osredotoča na avtentikacijo ter na vprašanje, ali claimant zadovoljivo dokaže uporabo authenticatorja, povezanega z določenim subscriberjem. [3][4]

Pri preiskavi se zato hitro pomešajo tri različna vprašanja. Prvo je, kako je bila identiteta preverjena. Drugo je, kaj je bilo tej identiteti dovoljeno narediti. Tretje pa je, komu ali čemu lahko ob upoštevanju vseh razpoložljivih podatkov pripišemo konkretno dejavnost.

Prvemu vprašanju pravimo avtentikacija, drugemu avtorizacija. Izraz atribucija v tem članku uporabljamo za tretje vprašanje, torej za analitični sklep o izvoru dejavnosti. Ne gre za posebno normativno kategorijo iz NIST SP 800-63, ampak za način, kako ločimo tehnično ugotovitev o identiteti od širšega sklepa o izvajalcu.

Uspešna avtentikacija je zato pomemben dokaz, vendar sama ne odgovori na vsa poznejša vprašanja. Med osebo in končno operacijo so lahko authenticator, seja, žeton, aplikacija in storitev. Pri običajnem delu ta veriga ostane skoraj nevidna. Pri incidentu je lahko prav eden od teh členov razlog, da je začetni sklep o izvajalcu napačen.

Ko isto identiteto uporablja nekdo drug

Microsoftov septembrski primer je uporaben, ker kompromitacije ne prikazuje kot en sam nenavaden login. Začetnim dogodkom so sledile spremembe avtentikacijskih metod, uporaba oblačnih funkcij in dostopi do različnih podatkovnih virov. Microsoft pri lovu na takšne aktivnosti zato priporoča korelacijo identitetnih dogodkov in dejavnosti v posameznih oblačnih storitvah. [1]

Po kompromitaciji lahko napadalec uporablja identiteto, ki ima povsem veljavna dovoljenja. Ciljni sistem pri tem ne potrebuje napačnega ali okvarjenega dnevnika. Zabeleži lahko točno tisto, kar je videl: uporabo določene identitete, aplikacije in dovoljenja. Težava nastane, če tehnični zapis brez dodatnega preverjanja neposredno pripišemo osebi, ki ji račun sicer pripada.

Pri pomembnejšem dogodku je zato smiselno pogledati tudi dejavnost pred njim. Sprememba registriranega authenticatorja, neobičajen način prijave, nova aplikacija, izdaja ali uporaba žetona ter poznejši dostop do drugih storitev lahko skupaj pojasnijo nekaj, česar en sam audit zapis ne more.

Podobno previdnost zahtevajo omrežni in napravni podatki. IP-naslov, naprava ali odjemalska aplikacija so lahko zelo koristni pri povezovanju dogodkov, vendar vsak od teh podatkov opisuje samo del poti. Tudi Microsoft v aktualni analizi opozarja, da se lahko posamezni IP-naslovi in domene hitro spreminjajo, zato večjo težo dobijo ponavljajoči se vzorci dejavnosti. [1]

To ne zmanjšuje vrednosti posameznega indikatorja. Njegov pomen postane jasnejši, ko vemo, kaj dejansko predstavlja. Znana naprava, pričakovan način avtentikacije in običajna aplikacija lahko skupaj podprejo eno razlago; nova metoda preverjanja pristnosti, neznan odjemalec in nenavadna dejavnost pa drugo.

Včasih za identiteto sploh ni človeka

Sodobna okolja ne poznajo samo uporabniških identitet. Aplikacije, storitve in oblačni viri imajo lahko lastne principale, ki izvajajo dejanja brez neposredne prijave fizične osebe. Microsoft Entra zato ločeno vodi prijave uporabnikov, service principalov in managed identities. [5][6][7]

Pri service principalu lahko aplikacija ali storitev uporablja lastno poverilnico, na primer certifikat ali client secret. Managed identity pa omogoča, da Azure vir pridobi žeton in dostopa do drugega vira, pri čemer Azure upravlja potrebne poverilnice. Pri takih dogodkih vprašanje »kateri uporabnik je to naredil« že v izhodišču ni vedno pravilno zastavljeno.

Bolj uporabno je vprašati, kateri principal je izvedel operacijo, kateri proces ga je uporabil in kaj je ta proces sprožilo. Človek je lahko na začetku verige, lahko pa operacijo sproži poslovna logika, načrtovana naloga ali druga avtomatizacija.

Microsoftova septembrska matrika groženj za oblačne spletne aplikacije pokaže tudi nasprotno možnost. Če napadalec prevzame aplikacijo in pride do žetona njene workload identity, lahko nadaljnji dostop poteka z dovoljenji legitimne identitete aplikacije. [2] Ciljna storitev tako vidi principal, ki res obstaja in res ima določene pravice, čeprav je razlog njegove uporabe drugačen od pričakovanega. Zapis, da je operacijo izvedla aplikacija, je zato lahko tehnično pravilen in še vedno ne pojasni vzroka. Enako velja za uporabniški račun. Revizijska sled pove, kateri subjekt je bil povezan z dejanjem, preiskava pa mora po potrebi pokazati še pot, po kateri je do dejanja prišlo.

NIST SP 800-63-4 pri tem ni primeren kot neposredni normativni vir za vse vrste strojnih identitet. Dokument se osredotoča predvsem na digitalno identiteto uporabnikov in izrecno ne pokriva nekaterih področij, kot sta machine-to-machine authentication in dostop do API- jev v imenu subjektov. [3] Za service principale in managed identities je zato smiselno uporabiti dokumentacijo platforme, ki te mehanizme dejansko izvaja.

Od posameznega zapisa do dokazne poti

Microsoft Entra podatke o prijavi razporeja v praktične sklope, ki pomagajo odgovoriti na vprašanja kdo, kako in kaj. Poleg identitete so lahko pomembni način avtentikacije, uporabljena aplikacija, ciljni vir ter identifikatorji, s katerimi je mogoče povezovati sorodne dogodke. [5]

Prav tu se vidi, zakaj en sam atribut pri zahtevnejši preiskavi hitro postane premalo. Uporabniško ime pove nekaj o digitalni identiteti, aplikacija o poti dostopa, ciljni vir o tem, kam je bila zahteva usmerjena, drugi identifikatorji pa lahko pomagajo povezati dogodke v skupno sejo ali transakcijo.

Tudi korelacijski podatki imajo svoje omejitve. Microsoft na primer pri correlation ID pojasnjuje, da povezuje prijave iz iste prijavne seje, vendar temelji na parametrih, ki jih posreduje odjemalec, zato njegove pravilnosti ni mogoče vedno zagotoviti. Request ID in identifikator žetona omogočata dodatno povezovanje, vendar tudi njun pomen ostaja tehnično določen. [5]

To je uporabno mikroforenzično pravilo tudi zunaj identitetnih sistemov. Podatek je lahko povsem veljaven in hkrati precej ožji, kot se zdi na prvi pogled. Bolj ko razumemo način njegovega nastanka, natančneje lahko določimo, kaj z njim smemo dokazovati.

Pri pomembnem dogodku zato ni cilj zbrati čim več polj iz čim več dnevnikov. Koristneje je sestaviti dovolj povezano sled, da lahko preverimo glavne možne razlage. Vrsta identitete, način avtentikacije, aplikacija, seja ali žeton, ciljni vir, spremembe identitetnih nastavitev in časovno povezani dogodki v drugih sistemih imajo največjo vrednost prav v medsebojni povezavi.

Če imamo samo en audit zapis, lahko zanesljivo poročamo o tem zapisu. Ko ga povežemo s prijavnimi dogodki, spremembami authenticatorjev, uporabo aplikacij in dejavnostjo v drugih storitvah, lahko utemeljeno razširimo tudi sklep. Dokazna podlaga in zaključek morata rasti skupaj.

Koliko gotovosti je dovolj

V tehničnih poročilih so stavki, kot je »uporabnik je spremenil nastavitev«, priročni in pogosto tudi pravilni. Problem nastane, kadar je takšna formulacija bolj določna od podatkov, na katerih temelji.

Pri običajnem uporabniškem dogodku se lahko identitetni, napravni, omrežni in aplikacijski podatki med seboj dobro ujemajo. V takem primeru je lahko povezava s konkretno osebo zelo močna. Če je bil račun kompromitiran ali gre za service principal oziroma managed identity, pa ima isti jezik lahko povsem drugačen pomen.

Dobra analiza zato ne poskuša vsakega dogodka pretvoriti v osebno atribucijo. Njen namen je ugotoviti, kaj je mogoče zanesljivo potrditi, katera razlaga je najbolje podprta in kje ostaja negotovost. V enem primeru bodo podatki dovoljevali zelo odločen sklep. V drugem bo strokovno pravilneje zapisati, da je bila operacija izvedena v kontekstu določene identitete, medtem ko razpoložljivi podatki ne zadoščajo za zanesljivo določitev fizične osebe, ki jo je sprožila. Takšna formulacija ni izmikanje odgovoru. Ohrani razliko med tem, kar je bilo dejansko opaženo, in tem, kar iz opaženega sklepamo.

Med računom in človekom ostane sled

Digitalne identitete so temelj upravljanja dostopa. Brez njih ne bi mogli določati pravic, vzpostavljati sej, uporabljati aplikacijskih storitev ali ustvarjati uporabne revizijske sledi. Prav zato imajo zapisi o identitetah veliko dokazno vrednost.

Težava se pojavi, ko tehničnemu identifikatorju pripišemo več, kot lahko sam pove. Uporabniški račun, IP-naslov, naprava, aplikacija, žeton in časovni zapis opisujejo različne dele istega dogodka. Posamezno so lahko zelo uporabni, njihova prava pojasnjevalna moč pa nastane šele, ko lahko pokažemo povezave med njimi.

Pri običajnem dogodku je ta pot kratka in predvidljiva. Incident jo lahko podaljša za več korakov: spremembo avtentikacijske metode, prevzeto sejo, novo aplikacijo, zlorabljeno workload identity ali drug mehanizem, zaradi katerega legitimna identiteta začne predstavljati dejavnost, ki je njen lastnik ni nameraval.

Revizijski zapis zato ni manj vreden, ker ne odgovori na vse. Njegova vrednost je največja takrat, ko ga beremo natančno. Pove, kaj je sistem zaznal in s katerim principalom je dogodek povezal. Kdo ali kaj je to identiteto v konkretnem primeru dejansko uporabilo, mora po potrebi pokazati širša dokazna pot.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZPri atribuciji je treba ločiti identiteto, avtentikacijo, avtorizacijo in dejanskega izvajalca; en audit zapis je pogosto le en člen dokazne verige.

RAZISKAVE0

DOKUMENTACIJA7

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-09-11

Viri

1. 01ADVISORYMicrosoft
   Microsoft Security Research. Passkey-themed social engineering leads to identity and cloud compromise, 9. september 2026. Aktualna analiza kompromitacij oblačnih identitet, sprememb avtentikacijskih metod, dejavnosti prek Microsoft Grapha ter dostopov do SharePointa, OneDrivea in elektronske pošte.
2. 02ADVISORYMicrosoft
   Microsoft Security Research. Threat matrix: Mapping threats across cloud web applications, 9. september 2026. Obravnava napadalne poti čez aplikacije, runtime okolje, workload identities in povezane oblačne vire.
3. 03STANDARDNational Institute of Standards and Technology (NIST)
   National Institute of Standards and Technology. NIST SP 800-63- 4: Digital Identity Guidelines, julij 2025. Vir je uporabljen za razmejitev preverjanja identitete, vpisa, authenticatorjev, avtentikacije in federacije ter za določitev meja področja uporabe smernic.
4. 04STANDARDNational Institute of Standards and Technology (NIST)
   National Institute of Standards and Technology. NIST SP 800- 63B-4: Digital Identity Guidelines – Authentication and Authenticator Management, julij 2025. Vir je uporabljen za razlago avtentikacije in upravljanja authenticatorjev, ne kot standard za digitalnoforenzično atribucijo fizične osebe.
5. 05PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn. Learn about the sign-in log activity details. Dokumentacija opisuje podatke o identiteti, načinu prijave, ciljnem viru ter uporabo correlation ID, request ID in identifikatorjev žetonov pri analizi prijav.
6. 06PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn. Service principal sign-in logs. Dokumentacija opisuje prijave aplikacij in storitev, pri katerih ni neposredno udeležen uporabnik, ter uporabo lastnih poverilnic aplikacije.
7. 07PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn. Managed identity sign-in logs. Dokumentacija opisuje dejavnost Azure virov, ki uporabljajo managed identity in pri katerih Azure upravlja potrebne poverilnice.