Säkerhetshändelser

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.

  1. Gå till Säkerhet i din organisation.
  2. Filtrera efter Medlem, Händelsetyp eller Datumintervall.
  3. För händelser kopplade till en styrd åtgärd följer du Request ID till godkännandeförfrågan och granskningshistoriken.
  4. Använd Export för att ladda ned det filtrerade resultatet för offlinegranskning eller arkivering.

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.

Felsökning

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.

Behöver du mer hjälp?