Audit logging

Wat is audit logging?

Audit logging is een functionaliteit binnen het Skryv platform waardoor elke Skryv applicatie logs bijhoudt over welke gebruiker op welk moment welke informatie binnen welk dossier raadpleegt. We houden deze log informatie bij in de database en stellen deze ter beschikking via een aparte datasource. Deze kan je eenvoudig ontsluiten op vraag van een DPO of auditeur. De audit logging functionaliteit vervult een belangrijke vereiste in het kader van bescherming van persoonlijke gegevens (GDPR-wetgeving).

Welk info wordt precies gelogd?

Elk record is een specifieke interactie van een gebruiker met het dossier (interne raadplegingen) of een externe opvraging (connector calls).

Inschakelen en instellen van audit logging

Standaard staat de audit logging functionaliteit uit. Voeg twee applicatie eigenschappen toe om deze functionaliteit te activeren binnen je Skryv applicatie. Beiden zijn default false.

• skryv.audit.persisted.enabled: logging inschakelen.

• skryv.audit.persisted.detail.enabled: alle details van de externe call bijhouden.

Voeg vervolgens volgende Spring applicatie eigenschappen toe om de audit datasource te activeren en te configureren.

• spring.audit-datasource.url: connection string.

• spring.audit-datasource.username: gebruikersnaam.

• spring.audit-datasource.password: wachtwoord.

• spring.audit-datasource.hikari: verdere instellingen voor de connectie.

Externe calls naar Magda

De audit logging covert naast interne dossierraadplegingen standaard ook elke externe call naar een authentieke databron via Magda.

Opmerkingen:

• Timing: de connectorcode schrijft de log-entry vóór de effectieve call vertrekt. Dit is een afspraak die de aanroepende code volgt, niet iets dat de audit-module zelf afdwingt. Een gefaalde call laat toch een rij achter. Een call die na drie retries slaagt, laat drie rijen achter.

• Fail-open gedrag: als het schrijven van de log zelf faalt, gaat de externe call gewoon door. Dit gedrag zit in de audit-module zelf, dus elke aanroeper krijgt het automatisch.

• Context-formaat: de context wordt steeds als tekst weggeschreven, ongeacht of het om een SOAP- of een REST-dienst gaat.

• Dossier ID: deze is null bij calls zonder dossiercontext (eBox, DOSIS, mobility …).

• Gebruiker: user_id is bij connector-calls steeds de sentinel-waarde SYSTEM, nooit een echte gebruiker.

De onderliggende audit-loglogica zit in een losstaande module, die standaard mee geïnjecteerd wordt in elke MAGDA-connector. Voor eigen (custom) connectoren is dit optioneel: je kan er zelf voor kiezen om deze module ook daar te injecteren.

Herbruikbare methode

Voor Skryv applicaties met zelfgeschreven outbound connectoren stelt het platform een herbruikbare methode ter beschikking. Dit is een losstaande module zonder afhankelijkheid van platform-services, connectoren kunnen de service altijd injecteren (geen optional-check nodig dankzij een no-op implementatie als logging uit staat), en MAGDA dient als referentie-voorbeeld voor andere connectoren. Standaard wordt deze module mee geïnjecteerd in de MAGDA-connector. In een eigen (custom) connector moet je dit zelf instellen.

Stap 1: voeg de dependency toe aan de pom.xml van je custom connector

<dependency>
    <groupId>com.skryv.backend</groupId>
    <artifactId>audit</artifactId>
</dependency>

Dit is dezelfde dependency die de MAGDA-connector zelf gebruikt. Er is geen automatische koppeling voor elke connector: je voegt deze zelf toe aan je eigen connectorproject.

Stap 2: configureer een ConnectorAuditEntries voor je resource type

Elke connector houdt hiervan één instantie bij, meestal als static veld, gekoppeld aan het resource type waaronder de rijen in de audit-tabel gegroepeerd worden:

private static final ConnectorAuditEntries AUDIT_ENTRIES =
        ConnectorAuditEntries.forResourceType("MIJN_CONNECTOR");

Stap 3: injecteer AuditService in je connector

Gewone constructor injection. Je hoeft geen Optional-check of feature-flag-check te schrijven: als audit logging uitstaat, injecteert Spring automatisch de no-op-variant.

@RequiredArgsConstructor
public class MijnConnector {

    private static final ConnectorAuditEntries AUDIT_ENTRIES =
            ConnectorAuditEntries.forResourceType("MIJN_CONNECTOR");

    private final AuditService auditService;

    // ...
}

Stap 4 : bouw de entry en log vóór je de externe call maakt

public MijnResponse haalGegevensOp(String identifier, String dossierId) {
    String endpoint = "https://voorbeeld.be/api/v1/gegevens/" + identifier;

    AuditEntry entry = AUDIT_ENTRIES.forEndpoint(endpoint, dossierId);
    Supplier<byte[]> context = AUDIT_ENTRIES.context(
            new ConnectorAuditEntries.CallDetail(endpoint, "GET", "haalGegevensOp", identifier));

    auditService.logActionOnResource(entry, context);

    return restClient.get(endpoint, MijnResponse.class);
}

Opmerkingen om mee te geven:

• forEndpoint verwacht een endpoint zonder query parameters, die kunnen persoonsgegevens bevatten (bijvoorbeeld een INSZ) en horen niet in resource_id.

• De context-supplier is lazy: de bytes worden pas geproduceerd op het moment dat ze effectief weggeschreven worden. Staat detail-logging uit, dan wordt deze supplier nooit aangeroepen.

• De volgorde (loggen vóór de call) is een conventie die je zelf in je connectorcode volgt. De audit-module dwingt dit niet af.

Legal logging

Legal logging is de bestaande, wettelijk verplichte logging van events rond persoonsgegevens. Denk aan batchverwerking van diploma's, of Magda-verbindingen met het rijksregister (GivePerson, GiveFamilyComposition …).

Wat wordt bijgehouden?

Legal logging maakt drie extra databasetabellen aan:

Het type van een log-entry is één van:

Activeren en instellen legal logger

Om de connector te kunnen gebruiken, voeg je deze eerst als maven dependency toe aan het pom.xml bestand van je applicatie. Deze haalt de code voor de connector op bij het maken van de build voor je app.

<dependency>
   <groupId>com.skryv.connectors</groupId>
   <artifactId>logger</artifactId>
</dependency>

Instellen de legal logger gebeurt via de applicatie eigenschappen.

Verschil met de nieuwe audit logging

• Legal logging houdt een gehashte SSIN bij van de persoon waarover de vraag gaat (aboutWhom). De nieuwe audit logging doet dat bewust niet (resource_id bevat nooit een identificeerbaar gegeven van de betrokkene).

• Een connector krijgt legal logging niet automatisch: je voegt de dependency toe, registreert LegalLoggerConfig.class in de applicatiecontext, voorziet Flyway-changesets, en implementeert zelf een mapping in de business-laag van de connector die logData(...) aanroept. Bij de nieuwe audit logging is dat laatste stuk (mapping schrijven per connector) niet nodig (ConnectorAuditEntries doet dat generiek).

• Legal logging is niet fail-open, audit logging wel.

• De eenvoudige logData(...)-gemaksmethode logt altijd hardcoded SUCCESS.