In software-land zijn er veel verschillende geheimen: API-keys, encryptie-keys, wachtwoorden etc. Wie zo'n waarde heeft, mag iets. Dit geld zowel voor systemen die eigen sleutels kunnen hebben, of personenen die zo'n sleutel krijgen.
Elke applicatie die we bouwen heeft er altijd een paar nodig. En die moeten dus ook gecommuniceerd worden. Daarom hebben we afgesproken hoe we ze maken, wie erbij kan, wanneer ze vervangen worden en wat er gebeurt als er iets misgaat.
Zo min mogelijk, van alles. Ons eerste uitgangspunt is minimaliseren: zo min mogelijk geheimen, zo min mogelijk mensen die erbij kunnen, zo min mogelijk plekken waar ze bestaan. Elk extra geheim is iets wat je moet bewaren, bijhouden en ooit vervangen. Delen vermijden we waar het kan.
Nieuwe geheimen maken we daarom niet met de hand. Ze worden gegenereerd: lang, willekeurig en met de sterkte die bij het type past. Een zelfbedacht wachtwoord voelt creatief, maar is dat statistisch gezien zelden. Daarom is gebruik van een password manager bij ons verplicht.
We houden een centraal register bij van onze geheimen. Daar staat per geheim in:
- hoe het heet en waar het voor dient;
- welk systeem het gebruikt;
- wie de eigenaar is en wie erbij kan;
- wanneer het is aangemaakt en voor het laatst is vervangen;
- wanneer dat weer moet gebeuren.
Moet een waarde toch van de ene collega naar de andere, dan gaat dat via een beveiligd kanaal, nooit via ons gewone chatprogramma. En de huisregels uit het personeelshandboek doen gewoon mee: je scherm op slot als je wegloopt.
Geheimen vervangen. Een geheim vervangen noemen we roteren, en we doen het op vaste momenten in plaats van alleen bij ellende. Dat gebeurt volgens een schema dat per type verschilt, en verder: als iemand uit dienst gaat, na een vermoeden of bevestiging dat een waarde is uitgelekt, en na een grote wijziging in een systeem.
Die laatste verdient uitleg. Break-glass-toegang is een noodingang: een manier om ergens binnen te komen als de normale weg niet werkt, met de afspraak dat je hem alleen in uitzonderlijke situaties gebruikt. Zo'n ingang is alleen betrouwbaar als je weet dat hij werkt, dus we testen hem periodiek. En na gebruik wordt het bijbehorende geheim altijd vervangen, zodat de noodingang niet stilletjes een tweede voordeur wordt.
Als er iets uitlekt. Vermoed je dat een geheim is uitgelekt, dan meld je dat meteen bij onze Security Officer. En dan ga je niet zelf aan de slag! Bij beveiligingsincidenten wachten we op het onderzoek, omdat haastig ingrijpen sporen wist die je nodig hebt om te begrijpen wat er is gebeurd. Zo kan het opnieuw opstarten soms onbedoeld logbestanden verwijderen of het probleem "oplossen". Echter is een oplossing alleen nuttig als je precies snapt wat er in de eerste plaats mis ging.
Daarna is de volgorde: impact beperken, de waarde intrekken en vervangen, controleren of alles weer draait, uitzoeken wat er misging en het register bijwerken. Dat laatste lijkt administratie, maar zonder die stap klopt het overzicht precies na een incident niet meer.
Blijven verbeteren. Na een rotatie of een uitgelekt geheim vragen we ons af waarom het kon gebeuren en wat de aanpak sterker maakt, bijvoorbeeld een korter vervangmoment of een extra controle op code en logs. Zo'n verbeterpunt krijgt een eigenaar, zoals beschreven in continu verbeteren.