Säkerhetshändelser är organisationens aktivitetslogg: varje inloggning, behörighetsändring, medelsrörelse och konfigurationsändring – med information om vem som utförde åtgärden, varifrån och när. För institutionella team är det här vyn som besvarar efterlevnadsfrågor, stöder interna revisioner och fångar avvikelser tidigt.
Säkerhetshändelser täcker aktivitet i hela organisationen:
Kategori | Exempelhändelser |
|---|---|
Inloggning och session | Inloggad, utloggad, misslyckade inloggningsförsök, 2FA-utmaningar och ändringar |
Enheter | Enhet länkad, enhet tillförlitlig, enhet godkänd, enhet återkallad |
Medelsrörelser | Uttag begärt, medel insatta, överföring initierad och slutförd |
Adresser | Uttagsadress tillagd, uppdaterad, borttagen |
Team | Roller skapade, uppdaterade, borttagna; roller tilldelade och borttagna från medlemmar |
API-nycklar | API-nyckel skapad, uppdaterad, borttagen |
Konton | Konto skapat, tillagt i eller borttaget från organisationen |
Godkännanden | Godkännandeförfrågan skapad, godkännandebeslut skickat, i alla arbetsflöden |
policyer | Policy uppdaterad, policy låst, policy upplåst |
Misslyckade inloggningsförsök registreras tillsammans med lyckade. En serie misslyckade inloggningar från en okänd plats är precis den signal den här vyn finns till för att visa dig.
Varje händelse besvarar de frågor en revisor eller incidenthanterare ställer först:
Kolumn | Vad det berättar |
|---|---|
Åtgärd | Vad som hände, i klartext: inloggad, uttag begärt, API-nyckel skapad |
Aktör | Vem som utförde åtgärden – medlemmen eller API-nyckeln som initierade den |
OS | Operativsystemet på enheten bakom åtgärden |
Webbläsare | Webbläsaren eller klienten som åtgärden kom från |
Plats och IP-adress | Förfrågans geografiska ursprung och IP-adress |
Begäran-ID | För styrda åtgärder: den godkännandeförfrågan som auktoriserade åtgärden |
Datum | När det inträffade |
Händelser som genereras av en kunds session innehåller hela klientkontexten – OS, webbläsare, plats och IP-adress. Händelser som systemet utför för kundens räkning innehåller i stället Request ID: klientkontexten finns på godkännandehändelserna för den förfrågan.
När en styrd åtgärd körs innehåller dess säkerhetshändelser ID:t för den godkännandeförfrågan som ligger bakom. Via Request ID kan du öppna förfrågan och se vem som initierade den, vem som godkände, vem som avvisade och när varje beslut fattades.
Det sluts revisionskedjan. För alla medelsrörelser eller administrativa ändringar kan du rekonstruera hela kedjan: åtgärden, förfrågan bakom den och de personer som godkände – utan att lämna produkten.
Direkta åtgärder – inloggningar, enhetsändringar och inloggningsuppgifter – registreras som händelser utan Request ID, eftersom de per design slutförs utan godkännande.
Vilka som kan se säkerhetshändelser styrs av samma åtkomstmodell som allt annat: synligheten definieras av de relevanta arbetsflödesnivåerna i en medlems arbetsflödesprofil.
Periodisk åtkomstgranskning. Filtrera på roll- och policyändringar under granskningsperioden. Varje ändring är kopplad till sin godkännandeförfrågan via Request ID, vilket ger dig ändringen och dess auktorisering i en vy.
Incidenttriage. Misslyckade inloggningar och okända platser syns tydligt i kolumnen Plats och IP. Filtrera på medlem för att rekonstruera en sessions fullständiga aktivitet.
Avstämning. Händelser för fondförflyttningar innehåller sitt Request ID, så att ekonomiteamet kan matcha huvudboksposter mot de förfrågningar och godkännanden som genererade dem.
Kolumnerna Aktör, OS, Webbläsare och Plats och IP visar vem som utförde åtgärden och varifrån. Om aktören är en medlem, kontakta den personen direkt. Om aktiviteten är okänd – en obekant plats eller enhet – behandla det som ett potentiellt intrång: inaktivera medlemmen eller återkalla berörd API-nyckel och kontakta supporten.
Endast styrda åtgärder har ett Request ID. Direkta åtgärder – inloggningar, enhetsändringar och uppgiftsändringar – slutförs utan godkännandeförfrågan per design, så kolumnen är tom för dem.
Händelser som systemet utför för en kunds räkning – till exempel ändringar som tillämpas efter att en förfrågan godkänts – har ingen egen kundsession. Följ Request ID till godkännandeförfrågan: händelserna för att starta och granska förfrågan innehåller klientkontexten för berörda personer.