Self-hosted is geen garantie voor veilig, het is een verantwoordelijkheid

De plek waar je data volgens de soevereiniteitsbeweging het veiligst staat, in eigen beheer, lekte in mei zo'n 367.000 eigen records. Niet bij een Amerikaanse hyperscaler, maar bij Nextcloud zelf: de Duitse open-source leverancier die half ondernemend Nederland en een rits overheden omarmen als het soevereine alternatief voor Microsoft 365. De oorzaak was geen geraffineerde inbraak en geen zero-day. Het was een Elasticsearch-database die zonder wachtwoord aan het open internet hing.

Dat is precies het misverstand dat ik eruit wil halen. Self-hosted en soeverein worden verkocht als hét veilige antwoord op cloudrisico en vendor lock-in. Maar zelf hosten maakt je data niet automatisch veiliger. Het verschuift alleen wie verantwoordelijk is voor de beveiliging: van de leverancier naar jou. Een verkeerd ingestelde database in je eigen serverrack lekt precies zo hard als eentje in de cloud.

Wat er lekte, en waarom het schuurt

Het ging om bijna 8 gigabyte aan interne bestanden, publiek benaderbaar voor iedereen die het adres kende. Facturen met namen en adressen van klanten. Contracten met gebruikersaantallen. Complete e-mails als losse bestanden. En, het pijnlijkst, installatiescripts met databasewachtwoorden die hard in de code stonden. Onder de blootgestelde domeinen zaten hostingpartijen en zelfs een Duits deelstaatministerie. Zo reikte een interne slordigheid meteen tot in de systemen van klanten.

Nextcloud benadrukt terecht dat de fout in de eigen hostinginfrastructuur zat, niet in de software, en dat servers van klanten buiten schot bleven. Dat klopt, en het is eerlijk om te noemen. Maar het maakt het punt eerder scherper dan zachter. Dit is de leverancier wiens hele belofte is dat je data in eigen beheer veiliger staat. Als zelfs zij een database open laten staan, wat zegt dat dan over de aanname dat 'in eigen beheer' en 'veilig' hetzelfde zijn?

Ze zijn niet hetzelfde. Zelf hosten geeft je controle over waar je data staat en bij wie ze niet staat. Het geeft je geen enkele garantie dat die data goed is afgeschermd. Dat is een aparte vraag, en het lek laat zien hoe makkelijk je hem overslaat.

Zelf hosten verplaatst het risico, het lost het niet op

Het patroon achter dit lek is het saaiste en tegelijk het meest voorkomende in de beveiliging. Geen kraak, maar een instelling die niemand naliep. In de Verizon-datalekrapporten zit al jaren in het merendeel van de inbraken een menselijke fout of manipulatie, niet een briljante exploit. Een open poort, een te ruime permissie, een wachtwoord dat in een script bleef staan.

En dit ene lek is geen uitschieter. Onbeveiligde databases die zonder wachtwoord aan het internet hangen, zijn een vaste categorie: onderzoekers vinden ze doorlopend, simpelweg door het internet af te zoeken op open poorten. Een misconfiguratie hoeft niet door een aanvaller gevonden te worden om een lek te zijn. Het feit dat de deur openstaat, is het lek al. Nextcloud is dus niet de uitzondering die de regel bevestigt; het is de regel, met een naam eraan die het pijnlijk maakt.

Die fouten verdwijnen niet als je van de cloud naar je eigen hardware verhuist. Ze verhuizen mee. Wat achterblijft, zijn de vangnetten. Bij een grote cloudleverancier staat een database standaard dicht, waarschuwt een dienst je als je een bucket per ongeluk openzet, en draait er een team dat de hele dag scant op precies dit soort blootstellingen. Dat team is niet gratis en niet neutraal, maar het is er wel.

Zet je hetzelfde systeem in eigen beheer, dan koop je die waakhond niet mee. De verantwoordelijkheid voor de configuratie ligt nu bij jou, of bij de partij die voor jou host. En 'verantwoordelijk' is een groot woord voor iets wat in de praktijk vaak neerkomt op: niemand keek er meer naar nadat het één keer werkte. Precies daar gaat het mis. Niet in de technologie, maar in de aandacht eromheen.

Wat soevereiniteit dan wél oplevert

Begrijp me goed: ik ben geen tegenstander van zelf hosten. Ik bouw zelf geregeld self-hosted, juist omdat het vendor lock-in en jurisdictierisico wegneemt. Als je data niet op een Amerikaanse server onder de Cloud Act staat, ben je een hele categorie zorgen kwijt. Als je leverancier morgen de prijs verdubbelt of de stekker uit een dienst trekt, raakt jou dat niet. Dat zijn echte voordelen, en ze zijn het waard. Ik wijs mensen ook zelf de weg naar een soevereine werkplek met Nextcloud en Linux als vervanging van Microsoft 365. Dit lek verandert dat advies niet. Het zet er een voorwaarde bij.

Maar het zijn voordelen op de as van controle, niet op de as van veiligheid. Digitale soevereiniteit is in de kern risicobeheer: je verkleint je afhankelijkheid en je zeggenschapsrisico. Beveiliging is een ander risico, met een eigen rekening. Controle nemen betekent ook de plicht nemen om die controle goed in te vullen. Wie het eerste doet en het tweede overslaat, heeft de leverancier weggestuurd en het huiswerk laten liggen.

Dat huiswerk is niet exotisch. Het zijn de saaie basislagen: staat er geen database open, staan er geen wachtwoorden in scripts, zijn de rechten strak, wordt er bijgewerkt en geback-upt. Dezelfde vijf lagen die je ook zonder eigen securityafdeling zelf kunt nalopen. Niet spannend, wel bepalend. Het Nextcloud-lek is geen argument tegen soevereiniteit. Het is een argument tegen soevereiniteit zonder discipline.

Om eerlijk te zijn: de cloud is ook geen kluis

De sterkste tegenwerping op mijn punt is simpel: de cloud lekt óók. Grote providers en hun klanten halen met enige regelmaat het nieuws met blootgestelde buckets en gestolen sleutels, en bij hen lever je bovendien de controle en de jurisdictie in die self-hosted je juist teruggeeft. Waarom dan de zelf-hoster de les lezen en de hyperscaler niet? Dat is een terecht punt, en ik ga er niet omheen: 'in de cloud' is net zo min een synoniem voor 'veilig' als 'in eigen beheer' dat is.

En precies daar zit de draai. De vraag die je veiligheid bepaalt, is niet wáár je data staat. Het is wíe de configuratie bewaakt en of dat georganiseerd is. In de cloud koop je een deel van die bewaking mee, of je het nu wilt of niet. Zelf hosten haalt dat weg en gaat ervan uit dat jij het overneemt. Doe je dat bewust, met mensen en een ritme dat de basis controleert, dan is self-hosted uitstekend te verdedigen. Doe je het niet, dan heb je het slechtste van twee werelden: de bescherming van een groot securityteam ingeruild, en de discipline om het zelf te doen nooit opgebouwd.

De vraag die telt

Soevereiniteit is geen eigenschap die je koopt door zelf te hosten. Het is een verantwoordelijkheid die je organiseert. Het aantrekkelijke aan 'eigen beheer' is het gevoel van grip, en dat gevoel is verraderlijk, want grip zonder onderhoud is precies hoe een database maandenlang open blijft staan zonder dat iemand het merkt.

Stel jezelf bij elke self-hosted keuze dus niet alleen de vraag of je de controle wilt. Vraag ook wie die controle daadwerkelijk uitoefent. Wie loopt de configuratie na, hoe vaak, en hoe weet je op dit moment zeker dat er nergens een database of een wachtwoord onbeschermd openstaat? Kun je die vraag niet beantwoorden, dan heb je je data niet in eigen beheer. Je hebt hem alleen zonder toezicht neergezet.