Sommige beveiligingsproblemen zijn spannend: een hacker die door je firewall breekt, een lek dat het nieuws haalt. Het probleem waar ik het vandaag over heb, is het tegenovergestelde. Het is saai, onzichtbaar, en precies daarom gevaarlijk. Een dagelijkse controle die ik op mijn server heb draaien, meldde op een ochtend dat vijf bestanden met geheimen te ruime leesrechten hadden. Niet spectaculair. Maar wel het soort fout dat een zorgvuldig opgezette scheiding tussen projecten in één klap waardeloos maakt.

Om te snappen waarom, moet ik eerst uitleggen wat die scheiding is. Op één server draai ik projecten voor verschillende bedrijven naast elkaar. Dat is efficiënt, maar het vraagt om strikte muren: het ene project mag absoluut niet bij de gegevens van het andere kunnen. Elk project heeft daarom zijn eigen afgeschermde ruimte. Die muren zijn de hele reden dat je meerdere dingen veilig op één machine kunt draaien. En laat nu net die vijf bestanden een gat in precies die muren hebben geslagen.

Wat er precies mis was#

Een bestand op een server heeft leesrechten die bepalen wie de inhoud mag zien. Grofweg zijn er drie groepen: de eigenaar, een groep, en “iedereen anders”. Die laatste categorie is de gevaarlijke. Een bestand dat leesbaar is voor “iedereen anders” op de machine, is leesbaar voor elk proces en elk project dat op diezelfde machine draait, ongeacht van welk bedrijf dat is.

En precies dat was er aan de hand met vijf van mijn geheimen-bestanden. Ze bevatten stevig spul: een secret waarmee betaalmeldingen worden ondertekend, een wachtwoord voor een boekhoudkoppeling, een sleutel voor een Ai-dienst, een geheim waarmee inloglinks voor klanten worden ondertekend, en toegangstokens voor mijn slimme huis. Stuk voor stuk zaken die je absoluut niet wilt delen. En ze stonden zo ingesteld dat niet alleen ik, maar élk ander project op de server ze kon lezen.

Hoe komt zoiets erin? Niet door een aanval, maar door een saai standaard-instellinkje. Toen ik die bestanden aanmaakte, hanteerde mijn omgeving een standaard die net iets te ruime rechten gaf. Geen bewuste keuze, geen slordigheid op één moment, maar een verkeerde standaard die zich stilletjes herhaalde bij elk nieuw bestand dat ik maakte. Dat is het verraderlijke aan dit soort fouten: ze ontstaan niet, ze sluipen erin.

Niet internet-onveilig, wél multi-user-onveilig#

Nu komt het punt dat ik het belangrijkste vind van dit hele verhaal, want het bepaalt hoe je het risico moet inschatten en hoe je het uitlegt. Deze bestanden waren níét vanaf het internet te bereiken. Niemand kon ze zomaar downloaden via een webadres. In die zin klonk de melding “leesbaar voor iedereen” enger dan het was.

Maar dat betekende niet dat er geen probleem was. Het probleem was van een ander type. Stel dat één van de andere projecten op de server een kwetsbaarheid had, en een aanvaller daarlangs binnenkwam. Dan zou die aanvaller vanuit dat ene gehackte project zomaar de geheimen van álle andere projecten kunnen lezen, want die stonden open voor iedereen op de machine. Eén zwakke plek in project A wordt dan meteen een probleem voor project B, C en D. Precies de situatie die de scheiding tussen projecten had moeten voorkomen.

Ik vat dat verschil zo samen: deze fout was multi-user-onveilig, niet internet-onveilig. Dat onderscheid klinkt als een detail, maar het is cruciaal. Als je tegen een klant of collega zegt “je geheimen waren leesbaar voor iedereen”, dan denkt die aan het internet, aan de hele wereld, en raakt hij in paniek over het verkeerde. Als je zegt “ze waren niet vanaf buiten bereikbaar, maar wél leesbaar voor andere projecten op dezelfde machine, en dat ondermijnt de scheiding die we juist hadden aangebracht”, dan begrijpt hij precies hoe erg het is: serieus, maar geen wereldwijd lek. Goede beveiliging begint bij een eerlijke, precieze inschatting van wie iets echt kon lezen. Niet erger maken dan het is, en niet minder.

De reparatie, en het voorkomen#

De acute fix was letterlijk een kwestie van minuten: de rechten op die vijf bestanden werden aangescherpt zodat alleen de eigenaar ze nog kan lezen. Andere projecten kijken er sindsdien tegen een dichte deur aan. Maar een fix die je met de hand doet, komt terug zodra je de volgende dag weer een bestand aanmaakt. Dus de echte oplossing zat in het voorkomen, en dat is opgebouwd uit een paar lagen.

Ten eerste heb ik de standaard-instelling van mijn omgeving veranderd, zodat nieuwe bestanden voortaan vanzelf de strenge, alleen-voor-de-eigenaar-rechten krijgen. De verkeerde standaard die de fout stilletjes bleef herhalen, is nu een goede standaard die het goede stilletjes blijft doen. Ten tweede heb ik als vaste regel aangenomen dat een bestand met geheimen altijd, zonder uitzondering, alleen voor de eigenaar leesbaar hoort te zijn. Geen “dat komt later wel goed”, maar meteen bij het aanmaken. Ten derde, en dit is de vangnet-laag: er draait nu elke dag automatisch een controle die de hele server afzoekt naar geheimen-bestanden met te ruime rechten en meteen alarm slaat als er eentje opduikt. Precies die controle heeft dit probleem overigens gevonden. Een fout die je automatisch signaleert, kan nooit lang blijven liggen.

Er is nog een gewoonte die hierbij hoort en die ik iedereen zou aanraden: geef een geheim nooit door als zichtbare tekst in een commando of in een bericht. Een wachtwoord dat je als los stukje tekst meestuurt, kan achteraf opduiken in logbestanden of in de lijst van draaiende processen, waar het opnieuw voor te veel ogen zichtbaar wordt. Houd geheimen in afgeschermde bestanden en laat programma’s ze daar zelf uit lezen.

Wat betekent dit voor jouw bedrijf?#

Vrijwel elk bedrijf verzamelt inmiddels een stapeltje digitale geheimen: wachtwoorden voor koppelingen, sleutels voor betaaldiensten, tokens voor allerlei online diensten. Die staan ergens opgeslagen, en de vraag die je jezelf te weinig stelt is niet “kan een hacker hier van buitenaf bij”, maar de veel simpelere vraag: wie kan dit eigenlijk allemaal lezen?

Dat is het denkraam dat ik je wil meegeven. Begin bij die vraag: wie kan dit lezen? Niet bij het spannende hacker-scenario, maar bij de nuchtere inventarisatie van wie er allemaal toegang heeft. Vaak is het antwoord ruimer dan je denkt: meer collega’s, meer systemen, meer diensten dan strikt nodig. Beperk vervolgens die kring tot wie het echt nodig heeft. En zet er een simpele, terugkerende controle op, want een fout die zichzelf elke dag meldt, wordt nooit een stille tijdbom.

En als je iets over een beveiligingskwestie communiceert, doe dat dan precies. “Leesbaar voor iedereen” en “leesbaar voor collega’s op dezelfde machine” zijn twee heel verschillende dingen. Wie het verschil helder uitlegt, voorkomt zowel onnodige paniek als gevaarlijke onderschatting.

Zelf aan de slag#

Een goede eerste stap om grip te krijgen op dit soort dingen is bewust nadenken over wat je waar afschermt, en welke sleutels en secrets een Ai-agent überhaupt in handen krijgt. Mijn gratis 7 stappen om je Ai-agent te beveiligen helpt je die grenzen concreet te trekken.

Wil je laten meekijken naar wie er in jouw bedrijf eigenlijk bij welke geheimen kan, en hoe je dat netjes afschermt zonder je werk onwerkbaar te maken? Kijk dan op de consulting-pagina hoe ik werk.