Beveiligingsgebeurtenissen vormen het activiteitenlogboek van je Organisatie: elke aanmelding, wijziging van rechten, tegoedmutatie en configuratiewijziging — inclusief wie het deed, vanaf waar en wanneer. Voor institutionele teams is dit het overzicht dat compliance-vragen beantwoordt, interne audits ondersteunt en afwijkingen vroegtijdig signaleert.
Beveiligingsgebeurtenissen omvatten alle activiteiten binnen de hele Organisatie:
Categorie | Voorbeeldgebeurtenissen |
|---|---|
Aanmelding en sessie | Aangemeld, afgemeld, mislukte aanmeldpogingen, 2FA-verificaties en -wijzigingen |
Apparaten | Apparaat gekoppeld, apparaat vertrouwd, apparaat goedgekeurd, apparaat ingetrokken |
Tegoedmutaties | Opname aangevraagd, tegoeden gestort, overboeking gestart en voltooid |
Adressen | Opnameadres toegevoegd, bijgewerkt, verwijderd |
Team | Rollen aangemaakt, bijgewerkt, verwijderd; rollen toegewezen aan en verwijderd van leden |
API-sleutels | API-key aangemaakt, bijgewerkt, verwijderd |
Accounts | Account aangemaakt, toegevoegd aan of verwijderd uit de Organisatie |
Goedkeuringen | Goedkeuringsverzoek aangemaakt, beslissing over goedkeuring ingediend, voor elke workflow |
Beleid | Beleid bijgewerkt, beleid vergrendeld, beleid ontgrendeld |
Mislukte aanmeldpogingen worden samen met succesvolle pogingen geregistreerd. Een reeks mislukte aanmeldingen vanaf een onbekende locatie is precies het signaal dat dit overzicht je laat zien.
Elke gebeurtenis beantwoordt de vragen die een auditor of incidentresponder als eerste stelt:
Kolom | Wat dit laat zien |
|---|---|
Actie | Wat er is gebeurd, in heldere taal: ingelogd, opname aangevraagd, API Key aangemaakt |
Actor | Wie de actie heeft uitgevoerd: het Lid of de API Key die de handeling heeft gestart |
OS | Het besturingssysteem van het apparaat waarmee de actie werd uitgevoerd |
Browser | De browser of applicatie waarmee de actie werd uitgevoerd |
Locatie & IP-adres | De geografische herkomst en het IP-adres van het verzoek |
Aanvraag-ID | Voor beheerde handelingen: het goedkeuringsverzoek dat de actie heeft geautoriseerd |
Datum | Tijdstip van de actie |
Gebeurtenissen vanuit een gebruikerssessie bevatten de volledige context: OS, Browser, Locatie & IP-adres. Gebeurtenissen die het systeem namens een gebruiker uitvoert, bevatten in plaats daarvan de Request ID. De sessiecontext staat bij de goedkeuringsgebeurtenissen van dat verzoek.
Wanneer een beheerde handeling wordt uitgevoerd, bevatten de bijbehorende beveiligingsgebeurtenissen de ID van het bijbehorende goedkeuringsverzoek. Via de Request ID open je het verzoek en zie je wie het heeft ingediend, wie heeft goedgekeurd, wie heeft afgewezen en wanneer elke beslissing is genomen.
Zo is de auditcyclus volledig gesloten. Voor elke geldbeweging of administratieve wijziging kun je de volledige keten reconstrueren: de actie, het onderliggende verzoek en wie akkoord heeft gegeven – zonder de applicatie te verlaten.
Directe handelingen – inloggen, apparaatwijzigingen en wijzigingen in inloggegevens – worden als gebeurtenissen vastgelegd zonder Request ID, omdat ze by design geen goedkeuring vereisen.
Wie beveiligingsgebeurtenissen kan inzien, volgt hetzelfde toegangsmodel als de rest: zichtbaarheid is onderdeel van de relevante workflowniveaus in het Workflowprofiel van een lid.
Periodieke toegangscontrole. Filter op rol- en beleidswijzigingen in de controleperiode. Elke wijziging is via de Request ID gekoppeld aan het bijbehorende goedkeuringsverzoek, zodat je de wijziging en de autorisatie in één overzicht ziet.
Incidentonderzoek. Mislukte aanmeldingen en onbekende locaties vallen direct op in de kolom Locatie & IP. Filter op lid om de volledige activiteit van een sessie te reconstrueren.
Reconciliatie. Fondsbewegingsgebeurtenissen bevatten hun Request ID, zodat je financieel team grootboekposten kan koppelen aan de verzoeken en goedkeuringen die eraan ten grondslag lagen.
De kolommen Actor, OS, Browser en Locatie & IP laten zien wie de actie heeft uitgevoerd en vanaf welke locatie. Is de actor een lid, neem dan rechtstreeks contact met diegene op. Als de activiteit echt niet herkend wordt – een onbekende locatie of apparaat – behandel dit dan als een mogelijke inbreuk: deactiveer het lid of trek de betrokken API key in, en neem contact op met Support.
Alleen beheerde bewerkingen bevatten een Request ID. Directe bewerkingen – aanmeldingen, apparaatwijzigingen en wijzigingen van inloggegevens – worden bewust afgerond zonder goedkeuringsverzoek, waardoor de kolom voor deze gebeurtenissen leeg blijft.
Gebeurtenissen die door het systeem namens een gebruiker zijn uitgevoerd – bijvoorbeeld wijzigingen die worden toegepast nadat een verzoek is goedgekeurd – hebben geen eigen gebruikerssessie. Volg de Request ID naar het goedkeuringsverzoek: de gebeurtenissen voor het starten en beoordelen van het verzoek bevatten de gebruikerscontext van de betrokken personen.