Uw database is gecodeerd. De verkoper heeft het over “geïntegreerd KMS”. Dan een incident: wie heeft de testback-up om 02.00 uur gedecodeerd? Niemand weet het: KMS-logboeken worden niet geëxporteerd, de toegang tot de hostbeheerder is niet gecorreleerd en in het contract staat alleen "encryptie ingeschakeld".
Een Key Management Service is geen andere technische optie. Dit is waar de verifieerbare scheiding plaatsvindt tussen degene die de gegevens opslaat en degene die deze kan lezen. Als het goed is ontworpen, levert het bewijsmateriaal op. Het is slecht ontworpen en voegt een laag jargon toe zonder het vertrouwensmodel te veranderen.
Architectuur: waar sleutels en gegevens leven
Het principe is eenvoudig: de gecodeerde gegevens blijven op schijf of object; de hoofdsleutels bevinden zich elders, op een speciale afdeling met een strikt toegangsbeleid.
In de praktijk zijn er drie patronen gebruikelijk bij Europese gastheren:
Cloud-native KMS. Eén sleutel per project, regio of resource. Automatische rotatie mogelijk. Decrypt-oproepen worden geregistreerd — als u toegang heeft tot de logs.
Externe KMS of opdrachtgever HSM. U brengt de sleutel mee; de host slaat alleen referenties op (envelop-encryptie). Versterkte controle, grotere complexiteit op het gebied van beschikbaarheid.
Gedeelde KMS zonder IAM-isolatie. Meerdere clients delen een exemplaar; de sleutels zijn logisch gescheiden, maar de platformbeheerders blijven krachtig. Expliciet te documenteren.
| Element | Vraag om te stellen | Gezond signaal |
|---|---|---|
| Sleutelbereik | Eén sleutel per omgeving? | Aparte productie / staging / back-up |
| Rotatie | Automatisch of handmatig? | Gedateerd beleid + test na rotatie |
| KMS-logboeken | Exporteerbaar naar SIEM? | Retentie ≥ auditduur |
| Glasbreuk | Noodprocedure? | Geschreven, getest, geplot |
Het scheiden van sleutels en gegevens heeft geen zin als hetzelfde beheerdersaccount beide kan beïnvloeden.
IAM en scheiding der machten
KMS faalt zelden op het algoritme. Het mislukt bij wie kan welke API aanroepen.
Zorg ervoor dat niemand bij de gastheer – of bij u thuis – ongecontroleerd accumuleert:
- aanmaken/verwijderen van sleutels;
- decodering van productiegegevens;
- verwijdering van sleutelgebruikslogboeken.
Het minste privilege is van toepassing op zowel KMS als servers. Idealiter: twee mensen voor destructieve operaties, waarschuwingen bij massale 'Decrypt', correlatie met incidenttickets.
Voor een ISO-audit of klantenvragenlijst laat u een geanonimiseerd loguittreksel zien waaruit blijkt dat een sleuteltoegang overeenkomt met een gedocumenteerde wijziging en niet met een mondelinge belofte.
Frequente projectfouten
Eén sleutel voor alles. Productie, back-ups en analyses delen dezelfde hoofdsleutel. Een lek of intrekking legt alles lam.
Rotatie zonder restauratietest. De sleutel draait; Oude back-ups worden onleesbaar door gebrek aan versiedocumentatie.
KMS in de ene regio, data in een andere. Latentie, compliance en beschikbaarheid lopen uiteen. Kopieën tussen meerdere regio's bevatten soms gerepliceerde sleutels zonder dat de DPO hiervan op de hoogte is.
Totale afhankelijkheid van de uitvoerhost KMS. Zonder sleutelexport of transitieperiode wordt omkeerbaarheid een eenzijdige hefboom.
Elke fout wordt gecorrigeerd door een kaart: welke bron gebruikt welke sleutel, wie kan deze intrekken, hoe lang de logs worden bewaard.
De top: de KMS vervangt het contract niet
Dit is wat de dia's over 'cloudbeveiliging' weglaten.
Het toppunt van analyse: vereist bewijs van scheiding, geen acroniem. Tijdens een crisisvergadering moet u weten wie binnen een uur de toegang tot de sleutels kan afsnijden – en of die persoon bij u of bij hen thuis is.
Beslis en ga vooruit zonder blinde vlek
Maak een lijst van de gecodeerde bronnen (bases, buckets, volumes, back-ups). Noteer voor elk de sleutel-ID, KMS-regio, IAM-eigenaar en rotatiefrequentie.
Vraag twee hosts op de shortlist: export van KMS-logboeken over 30 dagen, rotatiebeleid, intrekkingsscenario. Verwijzingen met onze vergelijker en de gids Encryption at rest om sleutels en gegevens op één lijn te brengen.
Test een rotatie op enscenering en vervolgens een gedateerde archiefrestauratie. Zonder deze test blijft het KMS-beleid theoretisch.
Veelgestelde vragen
Wat is een KMS in een hostingcontext?
Een Key Management Service centraliseert het aanmaken, opslaan, rouleren en controleren van het gebruik van encryptiesleutels. Het scheidt sleutels op een logische manier van gecodeerde gegevens, op voorwaarde dat de toegangsrechten op de juiste manier worden geïsoleerd.
KMS beheerd door de host of externe KMS?
Het KMS van de host vereenvoudigt de integratie, maar heeft vaak dezelfde operationele reikwijdte. Een extern KMS (HSM, soevereine cloud, on-premise) versterkt de onafhankelijkheid als u de beschikbaarheid en latentie controleert.
Hoe kan ik bewijzen dat er geen misbruik is gemaakt van een sleutel?
Via API-oproeplogboeken (Decrypt, GenerateDataKey), gecorreleerd aan IAM-identiteiten, met voldoende retentie- en leestoegang gereserveerd voor uw beveiligingsteam of de auditor.
Wat gebeurt er als de KMS niet beschikbaar is?
Services die hiervan afhankelijk zijn, kunnen weigeren gegevens te starten of te lezen. Dit is de afweging tussen controle: hoge beschikbaarheid van documenten, back-upsleutels en de break-glass-procedure.
Een KMS is alleen waard wat uw logbestanden en rechten kunnen bewijzen — niet wat het productblad belooft.