STD-0003: Encryptie en centraal sleutelbeheer¶

Documentgegevens¶

Doel en reikwijdte¶

Deze standaard stelt een CIZ-brede ondergrens voor encryptie tijdens transport en opslag en voor cryptografisch sleutelbeheer. Zij geldt voor CIZ-oplossingen en leveranciersdiensten, inclusief databases, disks, objectopslag, back-ups, snapshots, replica's, exports en tijdelijke persistente opslag.

Normatieve bepalingen¶

Transport¶

• Niet-vertrouwde verbindingen en verbindingen met authenticatie-, persoons-, gezondheids- of andere vertrouwelijke gegevens MOETEN versleuteling, integriteitsbescherming en passende peer- of serverauthenticatie gebruiken.
• TLS 1.2 is de minimale protocolversie voor bestaande verbindingen; TLS 1.0 en 1.1 MOGEN NIET worden onderhandeld.
• Nieuwe applicatieverbindingen BEHOREN TLS 1.3 te gebruiken. Tijdelijk gebruik van TLS 1.2 vereist aantoonbare interoperabiliteitsnoodzaak.
• Ieder traject na TLS-terminatie MOET afzonderlijk worden beoordeeld op versleuteling, authenticatie en gegevensrisico.

Opslag¶

• Alle persistente gegevens en kopieën MOETEN versleuteld worden opgeslagen.
• Waar een dienst envelope encryption ondersteunt, BEHOORT een DEK de gegevens te versleutelen en een niet-exporteerbare KEK/CMK de DEK te beschermen.
• HSM-backed customer-managed keys BEHOREN de standaard voor nieuwe oplossingen te zijn.
• Platform-managed of software-protected keys MOGEN alleen worden gebruikt wanneer classificatie, risico, proportionaliteit of platformondersteuning dit rechtvaardigt.
• Per opslagtype MOET een dreigingsmodel bepalen welke combinatie van opslag-, host-, database- en applicatielaagversleuteling nodig is.

Sleutelbeheer¶

• CIZ MOET eigenaar blijven van cryptografisch beleid en risicoacceptatie, ook wanneer een leverancier het operationele beheer uitvoert.
• Sleutels, certificaten en trust anchors MOETEN centraal beheerd worden voor uitgifte, opslag, autorisatie, monitoring, intrekking, herstel en rotatie.
• Toegang MOET RBAC, least privilege, functiescheiding en individueel herleidbare beheeridentiteiten toepassen.
• Workloads BEHOREN beheerde identiteiten of een gelijkwaardig mechanisme te gebruiken in plaats van langlevende credentials.
• Sleutelvoorzieningen MOETEN passende netwerkafscherming, auditlogging, soft-delete, purge protection, back-up, herstel en gecontroleerde intrekking ondersteunen.
• Applicatiecode MAG GEEN geheime sleutels of hardcoded cryptografische configuratie bevatten.

Rationale¶

Centrale regie en HSM-backed CMK geven CIZ meer controle over sleutelhouderschap, functiescheiding, rotatie en intrekking. Een uitzonderingsroute blijft noodzakelijk omdat niet iedere dienst dezelfde mogelijkheden ondersteunt en extra sleutelbeheer kosten en beschikbaarheidsrisico introduceert.

Uitzonderingen en risicoacceptatie¶

Een afwijking MOET classificatie, technische of proportionele reden, sleutelhouder, compenserende maatregelen, eigenaar, risicoacceptatie en eind- of evaluatiedatum bevatten. Afwijkingen van HSM-backed CMK MOETEN aantonen waarom de voorkeursrichting niet ondersteund of disproportioneel is.

Naleving en vereiste bewijslast¶

• encryptiestatus per opslagtype en alle kopieën;
• sleuteltype, sleutelhouder en bewijs van HSM-bescherming;
• RBAC-, functiescheidings- en managed-identityreview;
• rotatie-, herstel-, beschikbaarheids- en gecontroleerde-intrekkingstest;
• logging van sleutelhandelingen en actuele afwijkingsregistratie.

Implementatieprofielen¶

Voor Azure is Key Vault Premium met HSM-protected keys het normale profiel wanneer de dienst dit ondersteunt. Managed HSM BEHOORT te worden gebruikt wanneer single-tenant cryptografische isolatie, sleutelattestatie, een apart beheermodel of zwaardere functiescheiding vereist is. Encryption at Host, server-side encryption en database-encryptie zoals TDE worden gecombineerd wanneer het dreigingsmodel dit vraagt. Concrete Apoyo-bevindingen staan in het afzonderlijke implementatie- en afwijkingenregister.

Externe mappings en bronnen¶

Wijzigingshistorie¶