Versleutelen is makkelijk. De sleutel is het werk
Bijna elk systeem versleutelt tegenwoordig standaard. De vraag die overblijft is een andere: waar staat de sleutel, wie kan erbij, en kun je dat over een jaar nog laten zien aan iemand die er niet bij was.
Versleuteling aanzetten is een vinkje. Sleutelbeheer is het echte werk: waar staat de sleutel, wie kan erbij, wie heeft hem gemaakt, en wat gebeurt er als hij weg is.
Een toezichthouder vraagt niet of je versleutelt. Hij vraagt wie bij de sleutel kon en hoe je dat weet. Zonder vastlegging is "we versleutelen alles" geen antwoord.
Voor het grootste deel van de organisaties is sleutelbeheer bij de cloudleverancier voldoende. Waar dat niet zo is — zwaar gereguleerd, of sleutels die aantoonbaar buiten de leverancier moeten staan — komt hardwarematige sleutelopslag in beeld, bijvoorbeeld van Thales.
De verkeerde vraag
"Versleutelen jullie de data?" is een vraag die altijd met ja wordt beantwoord, en daarom niets oplevert. Schijven versleutelen gebeurt standaard, verkeer over het internet is versleuteld, en elke grote clouddienst versleutelt wat je erin zet zonder dat je erom vraagt.
De vraag die wél iets oplevert is: waar staat de sleutel waarmee dat wordt teruggedraaid, en wie kan daarbij. Want versleutelde data waarvan de sleutel naast de kluis ligt, is niet beschermd. Hij is alleen ingewikkelder om te lezen.
Dat verschil is precies waar een audit op landt. Niet op de vraag of er een slot op zit, maar op de vraag wie de sleutel heeft.
De drie plekken waar een sleutel kan staan
In de praktijk kom je drie modellen tegen, en het verschil ertussen is niet technisch maar bestuurlijk.
- De leverancier beheert de sleutel. Dit is de standaard bij clouddiensten. Het werkt, het is goed beveiligd, en je hebt er geen omkijken naar. De keerzijde: je kunt niet aantonen dat de leverancier er zelf niet bij kan, want dat is een eigenschap van hun systeem en niet van jouw beleid.
- Jij levert de sleutel aan de leverancier. Bij Azure en AWS kan dat: je maakt de sleutel zelf en geeft hem in beheer. Je houdt zicht op de levenscyclus en je kunt hem intrekken. De sleutel staat wel nog steeds in hun omgeving.
- De sleutel staat in eigen hardware. Een hardwarematige sleutelmodule bewaart sleutels zo dat ze het apparaat nooit verlaten. Bewerkingen gebeuren ín het apparaat; wat eruit komt is het resultaat, niet de sleutel. Thales is een van de partijen die dit levert, en het is het model waar toezichthouders naar wijzen als de eis is dat een sleutel aantoonbaar buiten de leverancier staat.
Het derde model is duurder en bewerkelijker dan de eerste twee. Wij stellen het voor als er een reden voor is, niet omdat het indruk maakt.
Wat een toetsing werkelijk vraagt
Bij een audit, een DORA-toetsing of een NIS2-gesprek gaat het zelden over het algoritme. Het gaat over vier dingen, en die zijn alle vier administratief.
- Waar staat de sleutel. Niet "in de cloud", maar in welk systeem, onder wiens beheer en in welk land.
- Wie kan erbij. Op naam, niet op rol alleen, en met een lijst die klopt met wie er nu werkt.
- Wanneer is hij vervangen. Een sleutel die er acht jaar in zit, is een bevinding, ook als er nooit iets mee gebeurd is.
- Wat gebeurt er als hij weg is. Als niemand die vraag kan beantwoorden, is de back-up van die data theoretisch.
Die vier vragen zijn te beantwoorden zonder dure hardware. Ze zijn niet te beantwoorden zonder vastlegging, en dat is waar het in de praktijk misgaat.
De sleutel en de back-up
Er is één fout die we vaker tegenkomen dan alle andere bij elkaar: de back-up is versleuteld met een sleutel die alleen in de omgeving staat die je aan het herstellen bent.
Dat gaat goed tot de dag dat je die omgeving kwijt bent. Dan heb je reservekopieën die niemand kan openen, en dat merk je op het slechtst denkbare moment. Onveranderbare back-ups zijn hier geen oplossing voor; die beschermen tegen wijzigen en wissen, niet tegen het kwijtraken van de sleutel.
Wij testen daarom niet alleen of een back-up terugkomt, maar of hij terugkomt in een omgeving die opnieuw is opgebouwd. Dat is een ander soort test, en hij levert vaker een verrassing op.
Wat wij hierin doen
Wij bouwen geen versleuteling en we schrijven geen sleutelbeheersoftware. Wat we wel doen:
- In kaart brengen waar sleutels staan. Dat is bij een overname vrijwel altijd de eerste verrassing: er zijn er meer dan iemand dacht, en een deel staat op een plek die niemand had bedacht.
- Toegang beperken en vastleggen. Per persoon, met meervoudige verificatie, en met een spoor dat achteraf te lezen is.
- Vervanging inplannen. Een sleutel heeft net als een certificaat een houdbaarheidsdatum. Die bewaken we en we melden hem ruim op tijd.
- Herstel testen zonder de bestaande omgeving. De test die telt is de test waarbij je doet alsof er niets meer staat.
Hoe dat in de bredere beveiliging past staat onder cybersecurity; hoe we hersteltijden afspreken en aantonen onder data en continuïteit.
Wanneer hardware zinvol is
Hardwarematige sleutelopslag is zinvol als minstens één van deze drie geldt.
- Er is een eis, uit regelgeving of van een klant, dat sleutels aantoonbaar buiten de omgeving van je clouddienst staan.
- Je verwerkt betaalgegevens of iets anders waarvoor een norm het expliciet vraagt.
- Je moet kunnen aantonen dat niemand — ook jij niet — een sleutel kan uitlezen, alleen gebruiken.
Geldt geen van de drie, dan is sleutelbeheer bij je cloudleverancier met een goede vastlegging de verstandige keuze, en zeggen we dat ook. Iets kopen waar je geen eis voor hebt, is geld dat niet naar het volgende gat gaat.
Vragen die we hierover krijgen
De vragen die het vaakst langskomen zodra dit onderwerp op tafel ligt.
Is versleuteling door de cloudleverancier niet genoeg?
Voor het grootste deel van de organisaties wel. Het is goed beveiligd en je hebt er geen omkijken naar. Het wordt onvoldoende zodra je moet kunnen aantonen dat de leverancier zelf niet bij de sleutel kan, want dat is een eigenschap van hun systeem en niet van jouw beleid. Of dat voor jou geldt, hangt af van je sector en je klanten.
Wat is het verschil tussen een versleutelde back-up en een onveranderbare back-up?
Versleuteld betekent dat niemand hem kan lezen zonder de sleutel. Onveranderbaar betekent dat niemand hem kan wijzigen of wissen binnen de bewaartermijn, ook een beheerder niet. Ze lossen verschillende problemen op en je hebt ze allebei nodig: het eerste tegen meelezen, het tweede tegen ransomware.
Hoe vaak moet een sleutel vervangen worden?
Dat hangt af van het soort sleutel en van wat je afspreekt in je eigen beleid. Belangrijker dan het interval is dat er een interval ís en dat je kunt laten zien dat je het volgt. Een sleutel die er acht jaar in zit zonder dat iemand het weet, is een bevinding — ook als er nooit iets mee gebeurd is.
Moeten wij hier hardware voor kopen?
Meestal niet. Hardwarematige sleutelopslag is zinvol als een norm of een klant eist dat sleutels aantoonbaar buiten je cloudleverancier staan, of als je moet kunnen aantonen dat niemand een sleutel kan uitlezen. Geldt dat niet, dan is sleutelbeheer bij je leverancier met goede vastlegging de verstandige keuze, en zeggen wij dat ook als je er zelf om vraagt.
Waar dit bij ons terechtkomt
De diensten waar dit onderwerp onder valt.
Weet je waar je sleutels staan?
Noem de systemen met gegevens die er echt toe doen en de eisen waaraan je moet voldoen. Daar beginnen we de inventarisatie.