familiewapen Mick Beermickbeer.com

manuscript ·

beginselMeten en wegenbronnenverwant

Wie een lek onderzoekt, stuurt het lek niet naar de cloud

Onderzoek naar een datalek mag het lek niet vergroten. Een gelekte dataset hoort in een afgesloten, netwerkloze omgeving onderzocht, niet in een clouddienst waar hij opnieuw kan uitlekken. De methode zelf moet de gegevens beschermen die ze onderzoekt.

De regel, en waarom hij absoluut is

Onderzoek naar een datalek mag het lek niet vergroten. Dat klinkt vanzelfsprekend en toch gaat het geregeld mis. Iemand krijgt een gelekte dataset in handen, wil weten hoe erg het is, en plakt een steekproef in een chatbot of laadt het bestand in een clouddienst om het doorzoekbaar te maken. Op dat moment reist de dataset opnieuw. Hij verlaat de machine van de onderzoeker, gaat over het netwerk, en komt terecht bij een partij die niemand in het onderzoek heeft uitgenodigd. De inbreuk die je wilde vaststellen, heb je zelf herhaald.

Ik hanteer daarom één harde regel. Een gelekte dataset wordt onderzocht in een afgesloten, netwerkloze omgeving. Hij gaat nooit naar een clouddienst en nooit naar een extern taalmodel. De methode zelf moet de gegevens beschermen die ze onderzoekt. Wie dat loslaat, wordt bij het aantonen van een lek zelf een tweede lek.

Waarom de cloud precies de verkeerde plek is

Een clouddienst is ontworpen om data te ontvangen, te verwerken en beschikbaar te houden. Dat is nuttig voor een normale werklast en riskant voor een dataset die per definitie al ergens hoort te zijn waar hij niet mag zijn. Zodra ik gelekte persoonsgegevens naar zo'n dienst upload, gebeuren er dingen buiten mijn zicht. Er worden kopieën gemaakt voor redundantie. Er staan backups op andere locaties. Logbestanden leggen vast wat er langskwam. Bij een taalmodel komt daar de vraag bij of de invoer wordt bewaard of hergebruikt voor training. Ik kan dat vaak niet controleren en zelden terugdraaien.

Dat betekent niet dat die diensten onveilig zijn. Het betekent dat ik de zeggenschap over de dataset uit handen geef op het moment dat ik hem het strakst zou moeten houden. Voor een lek dat draait om personen die er niets aan kunnen doen, is dat de verkeerde afweging. De juridische kant versterkt het praktische bezwaar. Draait de dienst op een Amerikaanse aanbieder, dan speelt de vraag naar jurisdictie mee. Zie In Europa gehost is geen vrijwaring en Waar het pakket landt en wie het kan vorderen zijn twee assen.

De netwerkloze werkbank in de praktijk

De kern van mijn aanpak is een omgeving zonder uitgaande verbinding. Als er geen route naar buiten is, kan er per definitie niets weglekken tijdens het onderzoek. Ik gebruik daarvoor een container die ik expliciet van het netwerk afsluit.

# Container zonder enige netwerkinterface starten.
# De dataset zit in een read-only mount, werkbestanden apart.
docker run --rm -it   --network none   -v /opt/leak/raw:/data:ro   -v /opt/leak/work:/work   onderzoek-image /bin/bash

De vlag --network none geeft de container alleen een loopback-interface. Er is geen weg naar buiten, ook niet per ongeluk via een tool die stiekem iets wil ophalen. De ruwe dataset koppel ik read-only aan, zodat ik hem niet per abuis wijzig. Wie geen container gebruikt, bereikt hetzelfde met een losgekoppelde netwerkkaart of met unshare -n om een proces in een lege netwerknaamruimte te zetten.

Voordat ik iets doe, leg ik de identiteit van het bestand vast. Een hash is mijn ankerpunt. Hij bewijst later dat ik over exact dezelfde bytes praat en niets heb aangepast.

sha256sum /data/dump.csv > /work/dump.sha256

Die hash is het begin van het bewijsspoor. Alles wat ik erna concludeer, hangt aan dit ene bestand met deze ene vingerafdruk.

Doorzoeken zonder de inhoud onnodig te openen

Voor een eerste beeld hoef ik lang niet altijd de gevoelige velden te lezen. Ik wil weten welke soorten gegevens erin zitten en hoeveel. Dat kan met patronen, lokaal, zonder een regel naar buiten te sturen. Een klein script telt voorkomens van herkenbare vormen en laat de onderliggende waarden ongemoeid.

import re, hashlib, pathlib

PATRONEN = {
    "email":    re.compile(rb"[\w.+-]+@[\w-]+\.[\w.-]+"),
    "bsn_9cijf": re.compile(rb"\d{9}"),
    "iban_nl":  re.compile(rb"NL\d{2}[A-Z]{4}\d{10}"),
}

pad = pathlib.Path("/data/dump.csv")
tellingen = {k: 0 for k in PATRONEN}
voorbeeld_hashes = {k: set() for k in PATRONEN}

with pad.open("rb") as f:
    for regel in f:
        for naam, patroon in PATRONEN.items():
            for treffer in patroon.findall(regel):
                tellingen[naam] += 1
                # Bewaar alleen een hash van de gevonden waarde.
                h = hashlib.sha256(treffer).hexdigest()[:16]
                voorbeeld_hashes[naam].add(h)

for naam in PATRONEN:
    print(naam, tellingen[naam], "uniek(≈):", len(voorbeeld_hashes[naam]))

Dit draait volledig in de netwerkloze container. Het geeft me de omvang van het lek per categorie en een ruwe schatting van het aantal unieke waarden, zonder dat ik ook maar één e-mailadres of BSN op mijn scherm hoef te halen. Als ik voor de rapportage toch een concrete waarde moet zien, doe ik dat gericht en bewust, met de hash als verwijzing in mijn aantekeningen. De redenering achter deze scheiding werk ik verder uit in Label elke bevinding op bewijsniveau.

Elke input is vijandig

Ik behandel elke input als vijandig, ook een bestand dat er onschuldig uitziet. Een dump is vaak een export uit een systeem dat ik niet vertrouw, samengesteld door iemand die ik niet ken. Een CSV kan formules bevatten die een spreadsheetprogramma uitvoert. Een archief kan paden bevatten die buiten de doelmap willen schrijven. Een bestandsnaam kan tekens bevatten die een shell verkeerd interpreteert. De netwerkloze omgeving vangt de ernstigste categorie af, want zelfs kwaadaardige inhoud die iets wil terugbellen, komt er niet uit.

Daarnaast open ik bestanden met tools die de inhoud als data behandelen en niet als instructie. Ik lees een CSV met een parser die geen formules evalueert. Ik pak een archief uit met controle op de doelpaden. Deze houding kost weinig en voorkomt de stille fout waarbij het onderzoek zelf het systeem infecteert dat het draait.

Wat het bewijsniveau hier betekent

Dat mijn omgeving netwerkloos was, is een gemeten eigenschap. Ik kan het aantonen met de configuratie van de container en met het feit dat uitgaande verbindingen faalden. Dat er tijdens mijn onderzoek niets is uitgelekt, is daarmee sterk onderbouwd, want de fysieke route ontbrak. Wat ik over de inhoud van het lek concludeer, tellingen per categorie, aantallen, is eveneens gemeten, verankerd aan de hash van het bronbestand.

Wat ik niet kan bewijzen, is dat de dataset vóór mijn onderzoek nergens anders al rondging. Dat valt buiten mijn meting en dat zeg ik er expliciet bij. Mijn methode garandeert één ding hard. Vanaf het moment dat het bestand mijn werkbank raakte, is het niet verder verspreid door mijn toedoen. Voor het onderzoeken van een lek is dat de minimale eis, en het is een eis die je alleen haalt door de cloud bewust buiten de deur te houden.

Zie ook Waar het pakket landt en wie het kan vorderen zijn twee assen, Label elke bevinding op bewijsniveau en In Europa gehost is geen vrijwaring.

bronnen
  1. Eigen werkwijze bij lekonderzoek: lokaal en zonder netwerkgelekte gegevens verlaten de eigen machine niet tijdens de analyse
citeer alsBeer, M. (2026, 10 juli). Wie een lek onderzoekt, stuurt het lek niet naar de cloud. mickbeer.com. https://mickbeer.com/#wie-een-lek-onderzoekt-stuurt-het-lek-niet-naar-de-cloud

lees dit stuk in het manuscript, met alles waar het aan hangt