Een miljoen paspoorten online: waarom dit lek geen verrassing is

We zijn voorbij het punt dat datalekken met paspoortgegevens uitzonderingen zijn. Het nieuws dat een miljoen gescande paspoorten, identiteitskaarten en rijbewijzen onbeveiligd op een server stonden, is geen incident. Het is een patroon. En dat patroon herhaalt zich elke keer dat een organisatie denkt dat een afgeschermde SharePoint-map, een 'tijdelijke' S3-bucket of een Elasticsearch-cluster zonder authenticatie wel veilig genoeg is.

Laatst zat ik met een CIO van een ZBO die me vertelde dat ze hun paspoortkopieën netjes hadden opgeslagen in een omgeving 'waar alleen geautoriseerde medewerkers bij kunnen'. Toen ik vroeg of die omgeving ook logging had op toegang tot individuele documenten, viel het even stil. "We vertrouwen op de authenticatie van de share", zei hij. Dat is geen beveiliging, dat is wensdenken. En precies dat wensdenken zag je terug in het datalek dat deze week op Hacker News voorbijkwam: een open database met een miljoen identiteitsdocumenten, zonder wachtwoord, zonder encryptie, zonder enige toegangscontrole. 201 upvotes. De community reageerde niet eens verbaasd, alleen vermoeid.

Wat er precies uitlekte

De details zijn schaars, maar het patroon is bekend. Een beveiligingsonderzoeker ontdekte een publiek toegankelijke server waarop een miljoen scans van paspoorten, ID-kaarten en rijbewijzen stonden. Geen authenticatie, geen IP-whitelisting, geen versleuteling. De documenten waren vermoedelijk afkomstig van een Know Your Customer (KYC)-proces, waarbij organisaties identiteitsbewijzen verzamelen en digitaliseren. Denk aan banken, telecomproviders, autoverhuurbedrijven, maar ook aan uitvoeringsorganisaties van de overheid die met BSN's en paspoortkopieën werken.

Het technische falen is bijna altijd hetzelfde: een S3-bucket of Elasticsearch-index die per ongeluk op 'public' staat, een MongoDB-instantie zonder authenticatie, of een verkeerd geconfigureerde reverse proxy die de interne API aan het internet blootstelt. In dit geval lijkt het te gaan om een Elasticsearch-cluster die via Shodan te vinden was. Een simpele query als port:9200 "paspoort" levert schrikbarend veel resultaten op, ook in Nederland. Probeer het zelf maar eens, uiteraard zonder op de data te klikken, want dat is al snel onrechtmatig.

Waarom dit jouw organisatie raakt

Als je bij een gemeente, ZBO of zorginstelling werkt, denk je misschien: "Wij hebben onze zaakjes op orde." Maar de praktijk is weerbarstig. Bij een recente DPIA voor een middelgrote gemeente ontdekten we dat er 14 verschillende systemen waren waarin kopieën van identiteitsbewijzen werden opgeslagen. Van het burgerservicenummer tot de klantcontact-app, van de scanstraat tot de mailbox van de afdeling Vergunningen. In geen enkel systeem was logging op documentniveau ingeregeld. In drie systemen was de toegangscontrole terug te herleiden tot een enkel domeingebruikersaccount dat door tientallen medewerkers werd gedeeld.

Dit is geen uitzondering. Het is de standaard.

De BIO2 en NIS2 eisen meer dan een vinkje

De Baseline Informatiebeveiliging Overheid (BIO2) is sinds 2024 van kracht en stelt concrete eisen aan de beveiliging van informatiesystemen. Voor paspoortkopieën, die vallen onder bijzondere persoonsgegevens, geldt het hoogste beveiligingsniveau. Dat betekent onder meer:

• Encryptie van data at rest én in transit (BIO2 §8.3.1 en §8.3.2). Een S3-bucket met default encryption 'none' is dus per definitie een BIO2-overtreding.
• Toegangscontrole op basis van need-to-know (BIO2 §9.1.1). Een gedeeld serviceaccount met leesrechten op alle documenten voldoet niet.
• Logging en monitoring van toegang tot bijzondere persoonsgegevens (BIO2 §12.4.1). Zonder document-level logging kun je niet aantonen wie wanneer welk paspoort heeft ingezien.

Onder de NIS2-richtlijn, die sinds 2025 ook voor veel overheidsorganisaties geldt, komt daar nog een meldplicht bij voor significante incidenten, binnen 24 uur. Een open Elasticsearch-cluster met een miljoen identiteitsdocumenten valt daar duidelijk onder.