Patroon voor sleutelhuis

Uit NORA Online
Naar navigatie springen Naar zoeken springen


Beveiliging
Onderdeel van
Thema's
Contact
Guus van den Berg
Guus.vandenberg@cip-overheid.nl
Status
Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging


Criteria

Beschikbaarheid, Integriteit, Vertrouwelijkheid en Controleerbaarheid

Definitie

Het sleutelhuis omvat het geheel aan taken, organisatie, processen en techniek voor het beheer van cryptografische sleutels.

Context

Dit patroon behandelt het sleutelhuis en een raamwerk van controleniveaus daarvoor. Organisaties die encryptie toepassen hebben intern een sleutelhuis nodig voor de beheersing van zowel de operationele-, ontwikkeling- en beheerprocessen, vanaf het ontstaan tot en met de vernietiging van sleutels en het geheel aan sleutelmateriaal gerelateerde activiteiten. Daarin onderscheidt het zich van een Trusted Third Party (TTP), die als een derde vertrouwde partij certificaten uitgeeft en beheert voor verschillende organisaties die encryptie toepassen bij hun onderlinge communicatie. De uit TTP-certificaten gegenereerde sleutels worden in het sleutelhuis van een organisatie bewaard.

Omgeving sleutelhuis

Probleem

Elke organisatie die versleuteling van gegevens toepast, ervaart op een bepaald moment, dat het introduceren van encryptietechnieken betrekkelijk eenvoudig is, maar dat zonder adequaat ingericht sleutelbeheer de organisatie zeer grote risico’s loopt voor ongeautoriseerde toegang of verlies van kritische gegevens.

Oplossing

Inrichting van een ‘sleutelhuis’, waarin een reeks gestructureerde processen voor ontwikkeling, beheer en controle en het operationele beheer van sleutels plaatsvinden. Bij de toepassing van cryptologie zijn de volgende factoren van belang:

  • Versleutelde data is net zo lang toegankelijk als de beschikbaarheid van de bijbehorende sleutel;
  • De versleuteling is net zo sterk als de mate van de geheimhouding van de sleutel;
  • Adequaat sleutelbeheer is vereist op grond van de Wet op de inlichtingen- en veiligheidsdiensten (WIV), artikel 24:3 waarin vermeld staat dat AIVD of MIVD na een schriftelijk verzoek om toegang tot gevraagde versleutelde gegevens de toegang daartoe verleend moet worden. Verder staat in artikel 89 van de WIV vermeld dat het al dan niet opzettelijk hinderen bij het ontsleutelen van gegevens als overtreding of misdrijf strafbaar gesteld wordt.
Betrokkenen bij sleutelbeheer

Organisatiestructuur

Het sleutelhuis is een virtueel organisatieonderdeel dat een gecontroleerde invulling geeft aan het lifecycle-management van certificaten en cryptografische sleutels. Voor het vullen van dit organisatieonderdeel wordt veelal gebruik gemaakt van medewerkers met een andere hoofdtaak. Functiescheiding is een belangrijk punt van aandacht binnen de sleutelhuisprocessen en procedures.

  • De Security Officer is eindverantwoordelijk voor het (laten) ontwikkelen, implementeren en uitvoeren van de *De IT-afdeling wordt geraadpleegd bij de ontwikkeling van de technische werkinstructies en is verantwoordelijk voor de uitvoering van het technische deel van de procedures.
  • De IT-auditor toetst periodiek de effectiviteit, efficiency en beveiliging van de uitvoering van het sleutelbeheer en rapporteert daarover aan de directie die eindverantwoordelijk is voor de informatiebeveiliging als geheel.

Lifecycle-management van sleutels

Adequaat lifecycle-management van cryptografische sleutels is randvoorwaardelijk voor toepassing van encryptie. Dat houdt in dat een sleutel de volgende fasen op gecontroleerde wijze doorloopt: generatie, distributie, operationeel, archiveren en vernietigen. Deze fasen worden hierna beschreven.

Levenscyclus cryptografische sleutels
  1. Genereren van sleutels. Cryptografische sleutels kunnen symmetrisch of asymmetrisch zijn. Voor beide typen sleutels geldt dat het genereren ervan zodanig dient te gebeuren dat niet voorspelbaar is wat (het private deel van) de sleutel is. De Wet Elektronische Handtekening (WEH) stelt eisen aan de manier waarop sleutels gegenereerd worden. Er zijn verschillende aanleidingen voor genereren van nieuwe sleutels:
    1. Een nieuwe toepassing waarvoor sleutelmateriaal nodig is. Dit begint met een inventarisatie en registratie. Dit startpunt van de operationele sleutelbeheer processen legt het profiel vast van het gevraagde of aangeboden sleutelmateriaal en/of certificaten. Aan de hand van de eigenschappen en operationele eisen die voor een sleutel nodig zijn om verantwoord sleutelbeheer te kunnen voeren, worden de cryptografische eigenschappen en het eigenaarschap van het materiaal geregistreerd, de levensfases van het materiaal geïnventariseerd en vastgesteld welke sleutelbeheer procedures hiervoor noodzakelijk zijn. Alle informatie wordt vastgelegd in de Crypto Sleutelbeheer-Database, die zelf ook valt onder een regiem van geheimhouding en beschikbaarheid.
    2. Aanvraag van een certificaat. Dit begint met autorisatie van de aanvrager. De Security Officer verzamelt en verifieert de identiteitsgegevens van de aanvrager en autoriseert de aanvraag. Voor certificaataanvragen fungeert de Security Officer als interne Registration Authority (RA), dat wil zeggen identificatie, authenticatie en autorisatie van de aanvraag, het bepalen en aanvullen van de juiste inhoud en het optreden als tussenpersoon naar de interne of externe partij die certificaten uitgeeft: de Certificate Authority (CA).
    3. Ter vervanging van sleutels waarvan de levensduur verstreken is. Per toepassing dient in een sleutelplan te worden vastgelegd wanneer en hoe sleutels vervangen dienen te worden.
    4. Vervangen van een sleutel als gevolg van een beveiligingsincident of compromittatie van een in gebruik zijnde sleutel. Aangezien in een dergelijke situatie snel moet worden gehandeld om (verder) informatieverlies te voorkomen, moet zijn vastgelegd waar incidenten gemeld worden, wie een sleutel mag intrekken, hoe dat gecommuniceerd dient te worden, welke stappen verder moeten worden genomen en welke ingetrokken sleutels op een revocation list komen. Cryptografische sleutels moeten veilig worden opgeslagen. Dit geldt ook voor back-ups van systemen waarin deze sleutels kunnen voorkomen. Het maken van een back-up van een sleutel is, afhankelijk van de toepassing, noodzakelijk / gewenst of juist niet toegestaan. Reden voor een back-up is het nog kunnen ontcijferen van informatie na verlies van de originele sleutel. Redenen voor het juist niet toestaan van een back-up kunnen bijvoorbeeld liggen in de eisen die de Wet Elektronische Handtekening (WEH) stelt voor authenticiteit en onweerlegbaarheid.
  2. Distributie van sleutels. Dit dient op veilige wijze te gebeuren. Distributie kan fysiek of elektronisch verlopen, afhankelijk van de toepassing. Sleutels om andere sleutels te beveiligen (Key Encryption Key) en certificaten worden veelal fysiek, bijvoorbeeld op een smartcard, gedistribueerd, waarna ze onder andere voor de elektronische distributie van encryptie sleutels kunnen worden ingezet. Meer hierover staat beschreven in de patronen Symmetrische Encryptie en PKI. Alle in omloop zijnde sleutels worden op basis van een unieke identiteit geregistreerd samen met wie de ontvanger is, zodat bij compromittatie direct bekend is welke partijen geraakt zijn (in geval van asymmetrische sleutels is dat er vanzelfsprekend maar één).
  3. Operationalisering van sleutels. Sleutels en certificaten hebben een aan hun gebruik aangepaste levensduur. In een sleutelplan wordt vastgelegd wanneer welke sleutel waar wordt toegepast. Uitzondering hierop zijn sessiesleutels die per sessie tussen partijen onderling worden afgesproken en alleen gedurende communicatiesessies geldig zijn.
  4. Archivering van sleutels. Na de operationele fase is het van belang dat back-ups van sleutels gearchiveerd blijven, zolang de opgeslagen en nog te raadplegen berichten en bestanden nog beveiligd zijn met die sleutels en voor verificatiedoeleinden. Toegang tot het archief en het opvragen van sleutels eruit dient volgens strikte procedures te verlopen om de integriteit en vertrouwelijkheid te waarborgen.
  5. Vernietiging van sleutels. Niet meer toegepaste sleutels dienen op een veilige wijze vernietigd te worden. Afhankelijk van het soort sleutel wordt voor operationele sleutels gebruik gemaakt van een hardwarematige “erase” functie of een softwarematige “wipe” functie. Het geheugen wordt hierbij zodanig overschreven dat het daarna niet mogelijk is om het sleutelmateriaal te reproduceren. Goede registratie is een voorwaarde om er voor te zorgen dat alle kopieën van sleutels vernietigd worden. Ook sleutels in back-ups en in het archief mogen niet vergeten worden om te vernietigen.

Sleutelbeheerrollen

In het sleutelhuis worden een aantal rollen onderscheiden. De rollen en de omschrijving van de bijbehorende taak staan in onderstaande tabel. Vanwege de beschikbaarheid is het wenselijk dat meerdere personen dezelfde rol kunnen vervullen en dus als back-up voor elkaar kunnen optreden. Dit is van belang om bij beveiligingsincidenten onder alle omstandigheden snel te kunnen handelen.

  • Ceremoniemeester. De Ceremoniemeester heeft een sturende rol in het sleutelbeheer. Initieert en/of organiseert tijdig de uitvoering van het bestaande sleutelbeheer procedures gedurende de levensfases van sleutels en certificaten. Fungeert als aanspreekpunt van het sleutelhuis, signaleert de behoefte aan nieuwe sleutelbeheer procedures en initieert de ontwikkeling hiervan.
  • Administratief sleutelbeheerder. De Administratief Sleutelbeheerder heeft een uitvoerende rol in de sleutelbeheerprocedures:
    • De rol is inventariserend, administratief en controlerend van aard.
    • Doet de inventarisatie van sleutelmateriaal, de aanvragen van certificaten en werkt daarbij op basis van de sjablonen voor sleutel- en certificaatprofielen. Voert tevens een registratie uit in de Crypto Sleutelbeheer Database.
    • Fungeert als geautoriseerd interface richting de CA.
    • Bepaalt met behulp van het sleutelprofiel de sleutelbeheerprocedures welke noodzakelijk zijn gedurende de levensfases van het sleutelmateriaal.
    • Heeft een signalerende rol indien blijkt dat er aanvragen liggen voor sleutelmateriaal waar nog geen procedures voor bestaan en bepaalt de te nemen stappen.
    • Beslist bij compromittatie van sleutelmateriaal en andere beveiligingsincidenten over de te volgen procedure.
  • Technisch Sleutelbeheerder. De Technisch Sleutelbeheerder heeft een uitvoerende rol in de sleutelbeheerprocedures. Zijn/haar rol is technisch/uitvoerend van aard. Hij/zij voert de technische handeling uit op (cryptografische) systemen.
  • Kluisbeheerder. De Kluisbeheerder heeft toegang tot het algemene deel van de kluis en bezit een deel van de toegangsmiddelen nodig voor de toegang tot het compartiment in de kluis waarvoor Multi Party Control vereist is.
  • Auditor. Uitvoeren van een audit op de beveiliging van het sleutelbeheerproces.

Functiescheiding

Afhankelijk van het gewenste beveiligingsniveau kan het noodzakelijk zijn om bij de uitvoering van de procedures functiescheiding toe te passen. Dit betekent dat de rollen door verschillende personen worden uitgevoerd. In dit kader kunnen de volgende niveaus worden onderscheiden:

  1. SD-SPC Separation of Duties (= functiescheiding) – Single Party Control. De Security Officer vervult de rol van Ceremoniemeester, Administratief Sleutelbeheerder en Kluisbeheerder. Hij/zij heeft hier het initiatief, coördineert, stuurt het proces aan en start procedures op. Een beheerder van de IT-afdeling vervult de rol van Technisch sleutelbeheerder en voert de technische werkinstructies uit.
  2. SD-SPC-A Separation of Duties – Single Party Control – Audited. Als 1, maar nu uitgebreid met auditing. De rol van Auditor wordt ingevuld door een IT-auditor. De Administratief Sleutelbeheerder kan optreden als Auditor voor de Technisch Sleutelbeheerder.
  3. SD–MPC–A Separation of Duties – Multi Party Control – Audited. Functiescheiding is hierbij dusdanig doorgevoerd dat geen enkel persoon een (deel van een) procedure alleen kan uitvoeren. Dit door benodigde kennis of fysieke middelen voor de gehele procedure over meerdere personen met functiescheidend tegengesteld belang te verdelen.

Het gewenste niveau van functiescheiding van de sleutelbeheerprocedure wordt vastgelegd in het sleutel- of certificaatprofiel. De keuze komt tot stand op basis van een risicoanalyse. Ook kan worden opgeschaald bijvoorbeeld van SD-SPC naar SD-SPC-A bij compromittatie van een TLS-certificaat.

Eigenschap Key encryption key Periodieke sleutel Sessiesleutel
Doel Encryptie van de periodieke of sessiesleutel Symmetrische encryptie van de gevoelige gegevens Symmetrische encryptie van de gevoelige gegevens
Soort Publieke sleutel of geheime sleutel Geheime sleutel Geheime sleutel
Levensduur 1 jaar Vastgestelde periode 1 sessie
Distributie Fysiek (smartcard, CD-ROM, sleutellaadapparaat, papier) over vertrouwd pad Beveiligd met KEK over communicatiepad zelf of over ander onvertrouwd pad Beveiligd met KEK over communicatiepad zelf
Fysiek over vertrouwd pad (geen KEK)

Operationeel ontwikkelproces sleutelhuis

De Security Officer is verantwoordelijk voor de sleutelbeheer procedures en de Crypto Sleutelbeheer Database en beslist of hier onderhoud op kan plaatsvinden. Voor klein onderhoud gebeurt dit door de Security Officer zelf; groot onderhoud of functionele wijzigingen gebeuren in overleg met de IT-afdeling. Trigger voor dit proces is een eventuele constatering dat er nog ontbrekende sleutelbeheer procedures zijn. Voor de sleutelbeheer procedures vindt ontwikkeling plaats op twee niveaus:

  1. Systeem onafhankelijke procedures, per type sleutel- of certificaatprofiel, voor alle fasen uit de lifecycle. Voor sommige procedures kan dit afdoende zijn voor een gecontroleerde uitvoering. Het raamwerk wordt uitgebreid indien er sprake is van een nieuw type sleutel of certificaat.
  2. Technische werkinstructies die, indien noodzakelijk, het generieke deel van de procedure uit het raamwerk aanvullen met systeem specifieke technische instructies. 

Afwegingen

De inrichting van een sleutelhuis is voor een belangrijk deel afhankelijk van het beveiligingsniveau, de schaalgrootte en de verscheidenheid waarop encryptie wordt toegepast plus het belang van de ermee versleutelde gegevens. Naarmate het niveau hoger is, zullen procedures strikter zijn en de mate van functiescheiding toenemen. Een risicoanalyse kan inzicht geven in welke risico’s met maatregelen, technisch, fysiek, procedureel of een combinatie, dienen te worden afgedekt. Dit wordt ook bepaald door hoe een organisatie met risico’s omgaat: risicomijdend, risiconeutraal of risicodragend. In risico-afwegingen moet ook de werkbaarheid van de procedures worden meegenomen. “Onwerkbare“ procedures zullen genegeerd worden en er zelfs toe leiden dat het beveiligingsniveau afneemt.

Implicaties

Het inrichten van een sleutelhuis in een organisatie kan betekenen dat huidige werknemers er nieuwe taken bij krijgen. Als deze er onvoldoende voor worden vrijgemaakt kan dat ten koste van de beveiliging gaan.

Gerelateerde patronen

Overgenomen van "https://www.noraonline.nl/index.php?title=Patroon_voor_sleutelhuis&oldid=8243"