Single Point of Failure

open source publieke sector digitale autonomie

31 augustus 2025

Recent kwamen er opnieuw pijnlijke datalekken in het nieuws: persoonsgegevens van meer dan 700.000 vrouwen die deelnamen aan bevolkingsonderzoek bleken jarenlang onnodig bewaard, inclusief naam, adres en zelfs BSN. Zulke incidenten laten zien hoe versnipperde administraties privacy en veiligheid ondermijnen. Elk lab en elke onderzoeksgroep beheert zijn eigen bestanden, met eigen routines, eigen risico’s. Juist daarom is de gedachte aan één centrale administratie zo krachtig: een plek waar bewaartermijnen strak geregeld zijn, waar alleen noodzakelijke gegevens staan, en waar unieke codes worden uitgegeven die labs gebruiken zonder de deelnemers zelf te hoeven kennen. Eén punt waar het fout kan gaan–maar ook één punt waar je mitigatie, beveiliging en vertrouwen structureel kunt verankeren.

Een single point of failure wordt meestal als gevaar gezien: één plek waar alles stuk kan gaan. Denk daarbij aan het centraliseren van bijvoorbeeld API calls naar externe providers zoals SMS en AI diensten, of dus het centraliseren van administratie voor medische onderzoeken. Maar diezelfde centralisatie kan ook een voordeel zijn. Een AI-egress gateway is niet alleen een poort die uitval kan veroorzaken, het is ook de plek waar je grip krijgt op gebruik, kosten en compliance. Één plek om wijzigingen door te voeren als de externe dienst iets aanpast. Of, in het kader van digitale autonomie, als een dienst ineens niet meer betrouwbaar is. In plaats van overal verspreid dezelfde fouten en risico’s te hebben, concentreer je de kwetsbaarheid–én de expertise. Het is makkelijker één punt robuust te maken, dan driehonderd losse koppelingen die allemaal hun eigen fouten en leemtes hebben.

Hetzelfde geldt voor administratieve infrastructuur. Een centraal administratiekantoor voor onderzoeksdeelnemers en hun toestemmingen lijkt een logische kwetsbaarheid: wat als die ene database wordt gehackt? Maar tegelijk is het de enige plek waar je consistent kunt borgen dat resultaten alleen onder de juiste voorwaarden worden hergebruikt. In plaats van eindeloos individuele labs en onderzoekers hun eigen administratie te laten doen–en dus overal kleine lekken en afwijkingen te riskeren–bundel je het in één strakke, gecontroleerde laag. Het single point of failure is dan óók het single point of mitigation.

De afweging om dingen centraal of decentraal te organiseren is dus wat mij betreft veel meer een pragmatische dan een ideologische keuze. Als één decentrale partij gegevens van 1 miljoen mensen kan lekken, dan is die schaal zo enorm dat je volgens mij beter kunt kiezen voor centralisatie, met alle bijbehorende mitigatiemogelijkheden en financiële middelen.

Andere aantekeningen

Het gevaar van priming

25 januari 2021

public tech software design algoritmeregister code for nl meetup

Zojuist een erg interessante sessie gehad over de mogelijkheid om een "algoritmeregister" te introduceren. Iedereen heeft daar wel iets van een beeld bij, maar bij nadere verkenning blijkt al snel: wat zit er nou eigenlijk in een "register", en wat valt er eigenlijk allemaal onder de noemer "algoritmes". Op die manier wordt het verzinnen van een oplossing een soort taalfilosofische exercitie.

Lees Het gevaar van priming

pOS feature #1: Happy Highlighter

22 januari 2021

software design hacking open source

Om mezelf wat meer te dwingen de dingen te doen waar ik blij van word, heb ik een nieuwe "life hack" of "persoonlijk O.S." feature. Ik heb me voorgenomen om leuke dingen wat vaker snel en kort te beschrijven in dit soort mini blogjes. Daarbij "nudge" ik mezelf om telkens te checken of ik bezig ben met de dingen waar ik bezig mee wil zijn.

Lees pOS feature #1: Happy Highlighter

Interview over Gegevensboekhouding

10 september 2024

open source publictech

Uiteenlopende wensen en verwachtingen vertalen naar een duidelijk concept voor "Gegevensboekhouding"

Lees Interview over Gegevensboekhouding

Bekijk alle aantekeningen