CEREMONIE HANDBOEK. voor de DNSSEC ceremonie. Krista Vermeulen. ICT-pd-Requirements en procedure voor de DNSSEC ceremonie-v1.4 Definitief Public

CEREMONIE HANDBOEK voor de DNSSEC ceremonie

Datum

25 november 2010

Auteur

Krista Vermeulen

Opdrachtgever Projectnummer Projectmanager Kenmerk

ICT-pd-Requirements en procedure voor de DNSSEC ceremonie-V1.4

Status

Definitief

Classificatie

Public

Historie en autorisatie Versie

Datum

Auteur

Inhoud wijziging

1.0

20-07-2011

K. Vermeulen

Upload naar Sharepoint

1.4

1-9-2014

M. Groeneweg

TLD onafhankelijk maken

Distributie De volgende personen hebben een exemplaar ontvangen. Naam

Rol/Functie

Actie

Directie

Goedkeuren Lezen

ICT-pd-Requirements en procedure voor de DNSSEC ceremonie-V1.4 Pagina 2 van 48

Inhoudsopgave

1

Inleiding

4

2

Requirements voor de DNSSEC-ceremonie

5

2.1

5

3

4

5

6

Kader

Opslaan van de backuptokens en KSK-partitiebackup in externe kluizen 5 3.1

Aannames

6

3.2

Besluiten

6

3.3

Definities

7

3.4


9

3.5

Requirements voor de nood-rolloverprocedure

10

3.6

Opslag van de tokens

11

Implementatie van de DNSSEC-ceremonie

12

4.1

HSM operations en configuratie

12

4.2

Rollen

13

4.3

Lijsten met namen van de rolhouders

15

5.1

1. Starten van de DNSSEC-ceremonie

16

5.2

2. Ophalen tokens en partitie-backupkaart

17

5.3

3. Voorbereiden KSK-rollover

18

5.4

4. Maken backup van KSK-partitie

19

5.5

5. Beëindigen DNSSEC-ceremonie

20

5.6

6. Uitvoeren KSK-rollover

21

5.7

7. Restore HSM: KSK-partitie

24

5.8

8. Restore alle HSM’s

26

5.9

9. Initieel inrichten HSM

29

Procedures rondom de kluizen

31

6.1

Inleiding

31

6.2

Procedures rondom toegang tot de kluizen

32

6.3

10. Initieel inrichten van kluizen

33

6.4

11. Beheren van gebruikers van kluizen

38

6.5

12. Ophalen backuptokens uit de externe kluis

40

6.6

13. Wegbrengen backuptokens naar de externe kluis

42

6.7

14. Ophalen van de partitiebackup uit de externe kluis

44

6.8

15. Wegbrengen van de partitiebackup naar de externe kluis

46

6.9

16. Wegbrengen van de reservesleutel naar de notaris

47

6.10

17. Ophalen van de reservesleutel bij de notaris


14

DNSSEC-ceremonie procedures

48

1

Inleiding

Dit document beschrijft de requirements en procedure voor de DNSSEC-ceremonie in het kader van het DNSSECprogramma van SIDN. De DNSSEC-ceremonie moet worden uitgevoerd wanneer nieuwe KSK’s (key signing keys) voor het signeren van de zone worden aangemaakt, een rollover van de KSK plaatsvindt, een nieuwe HSM wordt geïnstalleerd of een tweede HSM wordt bijgeplaatst. Ook verwante subprocedures, waaronder het aanmaken van een backup van de KSK en het bewaren en ophalen van de tokens uit een kluis worden beschreven. Tenslotte worden de procedures voor het initialiseren en beheren van de kluizen vermeld. In hoofdstuk 2 worden het kader, de aannames en de requirements voor de DNSSEC-ceremonie gepresenteerd. De voorgestelde implementatie van de requirements – op hoog niveau – wordt beschreven in hoofdstuk 3. Tenslotte worden de processen voor de ceremonie weergegeven in hoofdstuk 4. Deze processen zijn eveneens op hoog niveau beschreven. Daar waar van toepassing worden de processtappen nader toegelicht.


2


2.1

Kader

In de volgende paragrafen worden de requirements voor de DNSSEC-ceremonie opgesomd. De algemene term DNSSECceremonie verwijst naar een selectie van de onderstaande processen – of stappen die uitgevoerd moeten worden – met betrekking tot de HSM, het sleutelmateriaal en de tokens, namelijk: de operationele KSK-handelingen, het uitvoeren van een KSK-rollover, het maken van een backup van de KSK en het ophalen en wegbrengen van de backups van de KSK-partitie en de tokens. De volgende procedures worden in dit document beschreven (zie hoofdstukken 4 en 5): Operationele KSK-handelingen -

Aanmaken van een nieuwe KSK – normale procedure

-

In een kluis bewaren van de tokens

-

Toegang krijgen tot de tokens in de kluis

Rollover -

Een KSK rollover, inclusief het verzenden van het DS-record naar de root

Backup van KSK (partitie) -

Aanmaken van een backup van de KSK

HSM’s -

Initiële configuratie van een HSM

-

Restore HSM

-

Restore alle HSM’s

Kluizen -

Initiële configuratie van de kluizen

-

Beheer van de gebruikers van de kluizen

-

Opslaan en ophalen van de reservesleutel voor de backupkluizen bij de notaris


3

Opslaan van de backuptokens en KSK-partitiebackup in externe kluizen

3.1

Aannames

De requirements en beleidsbeslissingen die in de volgende paragrafen worden benoemd, gaan ervan uit dat er gebruik gemaakt gaat worden van een Hardware Security Module (HSM) voor het aanmaken en opslaan van sleutels en voor het signeren zelf. Een andere aanname is dat OpenDNSSEC gebruikt wordt om key sets te signeren (met de KSK die zich in de HSM bevindt). Tenslotte wordt ervan uitgegaan dat OpenDNSSEC in staat is om de HSM opdracht te geven om sleutels te genereren. Hoewel de DNSSEC-ceremonie uitgevoerd wordt door mensen, hangt de uitvoering ervan voor een groot deel af van de hardware en software die gebruikt wordt. Het is niet eenvoudig om de hardware en software zodanig aan te passen, om onze eventuele van de standaard afwijkende wensen en eisen te ondersteunen, in elk geval niet zonder veel verlies van tijd of zonder de betrouwbaarheid van de DNSSEC-oplossing geweld aan te doen. Vandaar dat we de mogelijkheden van de HSM en de OpenDNSSEC-software zullen moeten aanvaarden als randvoorwaarden.

3.2

Besluiten

Op een aantal vlakken zijn besluiten genomen, die de vorm, inrichting en uitwerking van de requirements hebben bepaald. De onderstaande besluiten zijn met name van belang. Kluismanagement – operationele besluiten Ten behoeve van het veilig bewaren van tokens is er gekozen voor twee kluizen op locatie van SIDN. Beide kluizen kennen een kluismaster en een kluismanager. De kluismanager is tevens kluisgebruiker. De kluismaster is géén gebruiker van de kluis, en kan de kluis dan ook niet (mede) openen. Elke kluisgebruiker heeft een eigen unieke code. Met één code is een kluis nooit te openen, er moeten altijd twee codes worden ingevoerd voordat de kluisdeur opent. De ongebruikte slots voor kluisgebruikers op elke kluis worden inactief gemaakt. Het toevoegen, verwijderen en wijzigen van kluisgebruikers gebeurt volgens een voorgeschreven procedure. De kluizen zijn ingericht met de volgende rollen. Deze rollen worden vervuld door de volgende DNSSEC-ceremonie rolhouders: 1.

2.

De kluis van de Crypto Officers

De kluis van de HSM-operators

e

kluismaster:

1 Crypto Officer

kluismanager:

één van de 2 Crypto Officers

kluisgebruiker:

kluismanager en alle 2 Crypto Officers

kluismaster:

ICT-manager / vervangende 1 Crypto Officer

kluismanager:

één van de HSM-operators

kluisgebruiker:

alle HSM-operators

e

e

e

Gebruikerscode Crypto Officers in kluis van HSM-operators e

e

Omdat er momenteel slechts drie personen de rol van 2 Crypto Officer vervullen en de aanwezigheid van twee 2 Crypto Officers niet altijd gegarandeerd is, ligt er in de kluis van de HSM-operators envelop met 1 gebruikerscode van de kluis van e

de Crypto Officers. Deze code kan door een HSM-operator gebruikt worden om samen met één 2 Crypto Officer de kluis van de Crypto Officers te openen. De HSM-operators hebben op deze manier op een veilige wijze toegang tot het rode


token wanneer dat nodig is, bijvoorbeeld voor een restore van een HSM, ook wanneer er geen twee Crypto Officers (maar altijd minimaal één) aanwezig zijn. Logboek van de kluis Elke kluis heeft een logboek. In dit logboek worden de handelingen die op de kluis worden uitgevoerd genoteerd, zoals het toevoegen en verwijderen van kluisgebruikers. De kluis moet echter ook zonder de ceremonieprocessen te volgen, op een veilige en gecontroleerde manier geopend kunnen worden. Omwille van operationele redenen wordt het logboek van de kluis in de kluis zelf bewaard, waarna de procedure voorschrijft of en zo ja welke handelingen in het logboek genoteerd moeten worden. Tokens Er is besloten om geen gebruik te maken van de mogelijkheid om elk token van een eigen pincode te voorzien. Eén token wordt gebruikt voor beide HSM’s. Voor elke HSM die met het token wordt benaderd, moet een unieke pincode op het token worden aangemaakt. Hoewel het gebruik van een pincode op een token een verhoging van de veiligheid kan inhouden, leidt dit in de praktijk tot verwarring en daarmee tot een risico op fouten: welke pincode hoort bij welke HSM voor dit betreffende token? Vandaar dat ervoor is gekozen om de tokens niet te voorzien van één (of meer) pincode(s). Dit besluit is vastgelegd en beargumenteerd in de besluitenlijst onder nummer B03. De tokens hebben kleuren, en deze kleuren behoren bij rollen, die vastliggen in de configuratie van de HSM. Er is voor de volgende verdeling van de tokens over de rollen in de DNSSEC-ceremonie gekozen: e

-

De 2 Crypto Officer beheert het rode token

-

De HSM-operators beheren het zwarte en blauwe token

Met deze verdeling van de beheerverantwoordelijkheden, alsmede de toegang tot de tokens, is de functiescheiding gewaarborgd. HSM-partities Op elke HSM wordt slechts één partitie ingericht. Het gebruik van één partitie in tegenstelling tot twee, vermindert de kans op fouten bij het maken van partiebackups, het aanmaken van een nieuwe KSK en het herstellen van een partitie door middel van het terugzetten van een partitiebackup. Dit besluit is vastgelegd en beargumenteerd in de besluitenlijst onder nummer B05. Auditor-functie van OpenDNSSEC Voor het eerste onderdeel van de implentatie van DNSSEC voor , namelijk voor Tier1, is besloten om geen gebruik te maken van de auditorfunctie van OpenDNSSEC. De auditor is een standaard onderdeel van de software OpenDNSSEC en controleert of de (softwarematige) processen goed verlopen. Dit besluit is vastgelegd en beargumenteerd in de besluitenlijst onder nummer B06.

3.3

Definities

In dit document worden de volgende specifieke begrippen gehanteerd: Rolhouder

De individu die benoemd is als handelaar in de DNSSEC-ceremonie, en daarbij een vastgestelde rol vervult.

Eerstverantwoordelijke rolhouder

De rolhouder die default als eerste is aangewezen om de rol in de


DNSSEC-ceremonie uit te voeren. De eerstverantwoordelijke rolhouder moet een vervanger aanwijzen als hijzelf niet aanwezig kan zijn bij de ceremonie. Vervangende rolhouder of vervanger

De individu die door de eerstverantwoordelijke rolhouder expliciet is benoemd om de taken van de rolhouder tijdens de DNSSEC-ceremonie uit te voeren.

Tokenhouder

De rolhouder (of vervanger van de rolhouder) die een token tot zijn beschikking heeft. Een token is bij sommige handelingen in de DNSSEC-ceremonie nodig.

HSM-operator

Een van de rollen in de DNSSEC-ceremonie. De HSM-operator beheert de HSM en bedient OpenDNSSEC. Er zijn altijd minimaal 2 HSM-operators aanwezig tijdens de ceremonie, om de kans op fouten bij de bediening van de HSM te beperken. In de praktijk wordt de rol van HSM-operator ingevuld door een beheerder. Beide HSM-operators zijn tokenhouder van e

het zwarte token. Er is door de 1 Crypto Officer één HSM-operator aangewezen als kluismanager van de kluis van de HSM-operators. e

1 Crypto officer

Een van de rollen in de DNSSEC-ceremonie. De Crypto officer representeert de controle op de veiligheid van het proces. Er zijn twee Crypto e

e

e

officers, de 1 en de 2 Crypto officer. De 1 Crypto officer beslist of de DNSSEC-ceremonie doorgang vindt en beheert de masterpincode van beide kluizen. De 1

e

e

Crypto Officer wijst één 2

Crypto officer aan als

kluismanager van de kluis van de Crypto officers. e

2 Crypto officer

e

Een van de rollen in de DNSSEC-ceremonie. De 2 Crypto officer is aanwezig tijdens de ceremonie en ziet toe op de veiligheid en naleving van de e

procedures. De 2 Crypto officer is tevens tokenhouder van het rode token. e

De 2 Crypto officer is kluismanager van de kluis van de Crypto officers en kent de managerspincode van deze kluis. DNSSEC-team

De individuen die samen de noodzakelijke rolhouders zijn voor een specifieke DNSSEC-ceremonie. De eerstverantwoordelijke rolhouders vormen het default DNSSEC-team. De teamleden kunnen vervangen worden door de aangewezen vervangende rolhouders, die op hun beurt dan het DNSSEC-team vormen.

Kluismaster

De kluismaster heeft beschikking over de masterpincode van beide kluizen en kan daarmee een kluismanager

voor elke kluis aanmaken. De

kluismaster kan de kluis niet openen: de masterpincode is niet geldig als e

gebruikerspincode voor de kluis. De 1 Crypto officer is kluismaster voor beide kluizen (die van de Crypto officers en die van de HSM-operators). Kluismanager

De kluismanager kent de managerpincode van de kluis. Met de managerpincode én met een gebruikerspincode van één van de andere 2

e

Crypto officers (conform het “4 ogen” principe) kan de kluis worden geopend en kunnen gebruikers worden aangemaakt, verwijderd en worden geblokkeerd. De kluismanager is tevens één van de gebruikers van een kluis.


3.4


De (op hoog niveau) gedefinieerde requirements voor de DNSSEC-ceremonie zijn de volgende: Nr

Requirement

opmerkingen

A1

De KSK (key signing key) kan worden aangemaakt.

A2

Er is een procedure (DNSSEC-ceremonie) opgesteld ten behoeve van het gecontroleerd en veilig aanmaken van de KSK.

A3

De DNSSEC-ceremonie is – waar van toepassing, m.n. bij het verzenden van het DSrecord naar de root - gebaseerd op de draft “Placing TLD trust anchors in the root zone” dat door IANA is uitgegeven.

A4

De DNSSEC-ceremonie moet worden uitgevoerd door ten minste 3 individuen, te e

weten 2 HSM-operators en één 2 Crypto officer. A5

Voor elke rol (individu) in de DNSSEC ceremonie moet een vervanger (als backup) benoemd zijn.

A6

De DNSSEC-ceremonie mag alleen doorgang vinden na een expliciete opdracht van de e

1 Crypto officer.

Dit is de bestuurder van SIDN (Roelof Meijer), of een door hem aangewezen vervanger.

A7 A8

Alle handelingen die op de HSM worden uitgevoerd, moeten worden gelogd door de

Inclusief het gebruik van

HSM.

de tokens.

Elke individu met een rol in de DNSSEC-ceremonie heeft voldoende training gehad en

Zie: details hieronder

heeft voldoende kennis van DNSSEC om zijn taken voor deze rol uit te voeren. A9

In het geval dat een noodprocedure voor een KSK-rollover uitgevoerd moet worden, moeten alle individuen met een noodzakelijke rol (of hun vervangers) binnen een afgesproken termijn (X uur) aanwezig zijn op de locatie waar de DNSSEC- ceremonie uitgevoerd gaat worden.

A10

De HSM moet op zodanige wijze geconfigureerd worden dat de rollen die benodigd

Procedurele afspraken zijn

zijn om de handelingen voor het maken van een HSM-backup en het restoren van de

minstens zo belangrijk tbv

HSM uit te voeren, aanwezig moeten zijn voordat deze processen kunnen worden

het afdekken van risico’s.

doorlopen. A11

De configuratie van de HSM moet op een gecontroleerde wijze plaatsvinden, door

Dit mag ook proce-dureel

tenminste 2 personen (4-ogenprincipe).

itt softwarematig worden afgedwongen.

A12

Voor elke KSK die is gegenereerd, moet een backup worden aangemaakt.

A13

De backup van de KSK moet worden bewaard op een geheugenstick of

De KSK blijft in de HSM,

geheugenkaart.

en een versleutelde backup staat op het externe geheugen.

A14

e

De 1 Crypto officer - en diens mogelijke vervangers – heeft op zijn laptop de

Bij voorbeeld met PGP

mogelijkheid om een signed email te versturen.

handtekening ter bevestiging van de opdracht.


A15

Er moet een mailgroep of mailbox worden aangemaakt waarin alle rolhouders en

Bijvoorbeeld “DNSSEC”

e

vervangers toegang hebben tot de toestemmingsemail die door de 1 Crypto officer naar deze mailgroep gestuurd wordt. A16

Voor elke persoon die een rol heeft in de ceremonie, moet aan zijn/haar personeelsdossier een aanhangsel worden toegevoegd, waarop staat vermeld welke rol deze persoon vervult tijdens de DNSSEC-ceremonie

A17

Aan het personeelsdossier van elke persoon met een rol in de DNSSEC-ceremonie, moet een verklaring worden toegevoegd waaruit blijkt dat hij/zij de training voor de ceremonie heeft gevolgd.

Specificatie van requirement A8: Elke persoon die een (vervangende) rol vervult in de DNSSEC ceremonie: -

Krijgt specifieke training,

-

Moet minimaal eenmaal een DNSSEC ceremonie hebben uitgevoerd in een testomgeving als onderdeel van de training,

-

Moet het belang van zijn rol inzien en begrijpen,

-

Moet de rol van en van DNS in de lokale en globale context begrijpen,

-

Moet de basisprincipes van DNSSEC begrijpen,

-

Moet in staat zijn om een pincode te onthouden (behorend bij de kluis waar het token is opgeborgen – alleen voor tokenhouders),

-

Moet een SIDN arbeidscontract voor onbepaalde tijd hebben,

-

Moet minimaal een half jaar in dienst zijn bij SIDN. Uitzonderingen op deze regel zijn de bestuurder van SIDN en de manager ICT van SIDN.

3.5

Requirements voor de nood-rolloverprocedure

In het geval dat de hardware faalt (HSM is kapot) of de KSK is verloren of gecompromitteerd, kan een noodprocedure (ongeplande) DNSSEC-ceremonie nodig zijn. De volgende requirements zijn opgesteld voor de ongeplande DNSSECceremonie: Nr

Requirement

B1

Het moet mogelijk zijn om op elk ogenblik binnen een vooraf afgesproken tijdspanne

Opmerkingen

een noodprocedure tbv een KSK creatie en rollover uit te voeren. B2

De noodprocedure voor een KSK rollover moet – voor zover mogelijk – identiek zijn aan de normale procedure.

B3

Het moet mogelijk zijn om een falende HSM te vervangen door een nieuwe HSM.

B4

De configuratie van de signer mag alleen plaatsvinden als 2 daartoe geautoriseerde personen aanwezig zijn.

B5

Toegang tot de signer is alleen toegestaan voor HSM-operators.

De normale procedure (zie procedure 1 Starten van de DNSSEC-ceremonie) wordt tevens gevolgd wanneer er een noodrollover moet plaatsvinden. Hiermee wordt voldaan aan requirement B2. Na analyse blijkt de separate noodprocedure niet afwijkend te zijn van de normale procedure. Het enige verschil in beide procedures is een timingskwestie: waar een geplande procedure een lange tijd vooraf gepland kan worden, zal een noodprocedure niet gepland zijn. De requirements zoals beschreven in paragraaf 2.4 en de te volgen stappen zijn echter nog steeds geldig.


3.6

Opslag van de tokens

Voordat een initiële configuratie of backup van het sleutelmateriaal op de HSM kan worden uitgevoerd, moeten de tokenhouders een token aanbieden aan de HSM. De tokens zijn daarom een noodzakelijk en belangrijk onderdeel van de DNSSEC-ceremonie, omdat zij voor deze specifieke handelingen toegang verlenen tot de HSM. De volgende requirements met betrekking tot het gebruik en de opslag van de tokens zijn gedefinieerd: Nr

Requirement

C1

Alle individuen met een rol in de DNSSEC-ceremonie en die een handeling moeten

Opmerkingen

uitvoeren die een token vereist, moeten een token hebben. C2

Voor elk token moet een backup token worden aangemaakt.

C3

Alle tokens moeten worden bewaard op een veilige plaats in een kluis.

C4

De kluis met de backup tokens moet op een andere locatie staan dan de kluis met de (normale) tokens.

C5

e

Het token voor de HSM–operators en het token voor de 2 Crypto officer moeten

De HSM-operators

worden bewaard in twee aparte kluizen.

hebben hun token vaker e

nodig dan de 2 Crypto officer. C6

Alle tokenhouders moeten toegang hebben tot de kluis met hun eigen tokens en de

De HSM-operators mogen

kluis met hun eigen backup tokens.

geen toegang hebben tot het token van de Crypto officer en v.v.

C7 C8

Er moeten procedures opgesteld zijn ten behoeve van het openen van een kluis met

Te bepalen door de

tokens.

security officer.

De kluis met de zwarte tokens voor de HSM-operators kan alleen met twee pincodes worden geopend: beide HSM-operators moeten hun pincode invoeren.


4

Implementatie van de DNSSEC-ceremonie

4.1

HSM operations en configuratie

De onderdelen van de DNSSEC-ceremonie voor het aanmaken van de KSK, het rollen van de KSK, alsmede de noodprocedures voor beide handelingen, vereisen een procedurele afdichting van de risico’s die gemoeid zijn met het omgaan met DNSSEC-sleutelmateriaal. Voor deze procedures is namelijk – als gevolg van de noodzakelijke toegang die OpenDNSSEC moet hebben tot de KSK - geen token vereist, en de HSM is daarmee een black box waartoe individuen met kennis over de inlogcodes en wachtwoorden zichzelf toegang kunnen verschaffen. De procedures die gevolgd moeten worden en die in het volgende hoofdstuk worden beschreven, zorgen voor voldoende beveiliging tegen deze risico’s. Nadat de KSK is aangemaakt, blijft deze in de HSM. Elke keer als de zone file is gegenereerd, moet deze ondertekend worden met de KSK voordat hij gepubliceerd kan worden. OpenDNSSEC biedt de records (DNSkey sets) van de zone file aan aan de HSM, waarna de records met de KSK worden gesigneerd en teruggegeven aan OpenDNSSEC. De KSK blijft onbereikbaar voor menselijke interactie, maar blijft voor OpenDNSSEC benaderbaar in de HSM ten behoeve van het signeren van de zone file. De HSM slaat het sleutelmateriaal (KSK en ZSK) op. De partitie waarop de KSK wordt bewaard, is niet zonder meer te benaderen door een individu. Alleen ten behoeve van het maken van een backup van de KSK of voor het terugzetten van een backup (restore) wordt het sleutelmateriaal door menselijk handelen overgezet op een extern medium (een geheugenkaart). De inhoud van het sleutelmateriaal blijft echter onbereikbaar en encrypted. Voor het maken van een backup en voor het terugzetten van de backup is een token nodig, waarmee de veiligheid van het proces wordt ondersteund. De configuratie van de benodigde tokens voor het maken van een backup van de keys en het terugzetten van de backup op de (nieuwe) HSM (een restore), wordt vastgelegd in de HSM. Deze configuratie wordt onderhouden door de HSMoperators. De initiële configuratie van de HSM’s, benodigd om te kunnen starten met het toepassen van DNSSEC, moet worden gecontroleerd door meerdere getuigen, waarmee wordt geborgd dat ook in deze allereerste fase geen ontoelaatbare acties (zoals het middels de configuratie van de HSM omzeilen van de beveiligde procedures) kunnen plaatsvinden. Samengevat kunnen de volgende procedures worden uitgevoerd zonder token: -

Aanmaken van een nieuwe KSK – procedure Voorbereiden KSK-rollover

-

Het uitvoeren van een normale KSK rollover, inclusief het verzenden van het DS-record naar de root

-

In een kluis bewaren van de tokens en backupkaart van de partitie

-

Toegang krijgen tot de tokens en partitie-backupkaart in de kluis

-

Initieel inrichten en beheren van de gebruikers van de kluizen

Deze procedures vereisen wel een token, alsmede een procedurele afdichting van de risico’s: -

Aanmaken van een backup van de KSK-partitie

-

Toegang krijgen tot de backup van de KSK-partitie

-

Initiële configuratie van een HSM

-

Restore van een HSM

-

Restore van alle HSM’s


Er zijn 3 typen tokens: -

Blauw token: dit token is voor HSM-operators voor het uitvoeren van administratieve taken op de HSM zoals het wijzigen van wachtwoorden, policy settings en het uitvoeren van firmware upgrades.

-

Zwart token (partitie owner token): dit token geeft toegang tot partitie op de HSM waarop het ZSK- en KSKsleutelmateriaal zijn opgeslagen. Het is nodig voor het maken van een backup van het ZSK- en KSKsleutelmateriaal. Dit token maakt onderdeel uit van de DNSSEC-ceremonies en wordt gebruikt door de HSMoperators.

-

Rood token (cloning domain token): dit token is nodig om een HSM of PCMCIA-backupkaart (deze wordt ook als HSM gezien) in een groep op te nemen die elkaars ZSK- en KSK-sleutelmateriaal mogen uitwisselen en gebruiken.

Om gebruik te kunnen maken van het sleutelmateriaal dat is opgeslagen in de HSM’s of op de PCMCIA-backupkaart heb je nodig: -

het zwarte partitie owner token om bij het sleutelmateriaal te mogen komen,

-

het rode cloning domain token om het apparaat waarop je het sleutelmateriaal wilt gebruiken onderdeel te laten uitmaken van de groep waarin dit sleutelmateriaal gebruikt mag worden.

Binnen de DNSSEC-ceremonie is ervoor gekozen om het zwarte en het rode token te scheiden over twee rollen zodat het nooit mogelijk is dat 1 rol zowel bij het sleutelmateriaal kan komen en in staat is dit sleutelmateriaal op een nieuw in te richten apparaat te gebruiken.

4.2

Rollen

Voor de uitvoering van de DNSSEC-ceremonie zijn de volgende rollen gedefinieerd: Rol in DNSSEC-ceremonie

SIDN-rol

HSM-operator (1)

DNS administrator

HSM-operator (2)

DNS administrator

Crypto officer (1) – verleent toestemming

Bestuurder

Crypto officer (2)

Security officer

Vervangende HSM-operator (1)

DNS administrator

Vervangende HSM-operator (2)

DNS administrator

Vervangende Crypto officer (1) – verleent toestemming. Deze vervangende Crypto officer (1)

MT-lid

moet expliciet door de Crypto officer (1) zijn aangewezen bij geplande onbereikbaarheid. Bij ongeplande onbereikbaarheid (calamiteit) van x uur van de Crypto officer (1) of de vervangende Crypto officer (1) vervult het MT lid dat de bestuurder waarneemt de

rol van

vervangende Crypto officer (1) Vervangende Crypto officer (2) De HSM-operators zijn nodig om taken op de HSM uit te voeren. Zij kunnen OpenDNSSEC een nieuwe KSK laten aanmaken, maar zij kunnen indien nodig ook veranderingen in de configuratie van de HSM aanbrengen. De tweede HSM-operator moet controleren wat de eerste HSM-operator doet. e

e

De 1 Crypto officer heeft een autoriserende rol, deze rol wordt normaliter vervuld door de bestuurder van SIDN. De 2

Crypto officer is aanwezig bij de DNSSEC-ceremonie. Hij kan gerepresenteerd worden door een door hemzelf aangewezen


e

vervanger, eveneens in de rol van 2e Crypto officer. De rol van de 2 Crypto officer is anders dan die van de 1e Crypto officer: de

e

1 Crypto officer verleent namelijk toestemming om de DNSSEC-ceremonie te starten. Hij heeft een

besluitvormende rol, die ook op afstand uitgevoerd kan worden (de uitwerking hiervan is te zien in de procedure 1.Starten e

DNSSEC-ceremonie). De rollen van de 1

e

en de 2 Crypto officer zijn door de verschillende inhoud van de rollen niet

uitwisselbaar. De individuen die deze rollen vervullen, kunnen dan ook niet elkaars vervanger zijn. Alle actoren (individuen) die een rol hebben in de DNSSEC-ceremonie moeten een vervanger hebben, die in geval van afwezigheid van de eerstverantwoordelijke de rol van deze individu kan overnemen. De vervangers kunnen alleen optreden als actor in de DNSSEC-ceremonie wanneer zij daartoe expliciet door de eerstverantwoordelijke rolhouders zijn benoemd voor een (specifieke) DNSSEC-ceremonie. e

In het uitzonderlijke geval dat er geen logische vervanger aan te wijzen is voor de 1 Crypto officer, bijvoorbeeld omdat het gehele MT niet in staat is om deze rol op zich te nemen én geen vervanger kan aanwijzen, zal de voorzitter van de Raad van e

Toezicht van SIDN de rol van 1 Crypto officer overnemen, danwel die toewijzen aan een ander lid van de Raad van Toezicht of een medewerker van SIDN. In geval van een noodprocedure - de DNSSEC-ceremonie vindt plaats op een ongeplande tijd en met een noodzakelijkheid als gevolg van een verloren, gestolen of gecompromitteerde KSK – moeten de rolhouders binnen een vooraf afgesproken tijdsduur aanwezig te zijn op kantoor. Zij moeten inschatten of een ongeplande procedure voor een KSK rollover nodig is, en zij moeten dit aan alle betrokkenen kunnen uitleggen.

4.3

Lijsten met namen van de rolhouders

De actuele lijst met de namen van de personen die rolhouder zijn voor de verschillende procedures in de DNSSECceremonie is te vinden in Rollen en Rolhouders voor de DNSSEC-ceremonie.doc, versie 2.0. Dit document is in beheer bij HRM. Zodra een rolhouder uit dienst gaat of om een andere reden de taken van de rol niet meer zal uitvoeren, moet dit document worden aangepast. Tevens zal een nieuwe rolhouder gezocht moeten worden en de naam van deze persoon moet worden toegevoegd aan de lijst met rolhouders. Het is de verantwoordelijkheid van de Security Officer om deze lijst compleet te houden. Het is de taak van HRM om de lijst te bewaren bij de personeelsdossiers en waar mogelijk de Security Officer te attenderen op een mogelijke onvolledigheid van de lijst. Specifiek voor de procedures 16 en 17, waarin geauthoriseerde rolhouders zich bij de notaris mogen melden om de reservesleutel voor de kluizen op te halen of af te geven, is het document SEC-RA-Lijst MT leden kluissleutels notaris v1.0.doc opgesteld. Dit document wordt door de Security Officer beheerd en bij wijziging wordt een kopie afgegeven aan de notaris, zodat deze laatste de vereiste persoonscontroles kan uitvoeren die in de procedures 16 & 17 staan beschreven.


5

DNSSEC-ceremonie procedures

Onderstaande procedures beschrijven op hoog niveau de stappen die gezet moeten worden in de DNSSEC-ceremonie. De volgende processen zijn uitgewerkt: DNSSEC-ceremonie: 1.

Starten van de DNSSEC-ceremonie

2.

Ophalen tokens en partitie-backupkaart

3.

Voorbereiden KSK-rollover

4.

Maken backup van partitie

5.

Beëindigen DNSSEC-ceremonie

6.

Uitvoeren KSK-rollover

HSM: 7.

Restore HSM : partitie herstellen

8.

Restore alle HSM’s : partitie herstellen

9.

Initieel inrichten van de HSM

Kluizen: 10. Intitieel inrichten van de kluizen 11. Beheer van de gebruikers van de kluizen 12. Ophalen backup tokens 13. Backup tokens in extern beheer brengen 14. Ophalen partitiebackup uit kluis 15. Wegbrengen partitiebackup naar kluis 16. Backup sleutel van de backup tokens in beheer bij notaris brengen 17. Backup sleutel van de backup tokens ophalen bij notaris


5.1

1. Starten van de DNSSEC-ceremonie

1.1 geplande DNSSEC-ceremonie, volgens schema of CMprocedure; of resultaat van analyse na prio 1 IM-call (noodprocedure) en de KSK moet rollen. Deze noodprocedure wordt gestart door de waakdienstmedewerker.

1.1 Event: starten DNSSEC- ceremonie

1.2 Start DNSSECceremonie vlg. planning?

nee

1.3 Stel DNSSECceremonie uit.

1.3. Bv: tot alle rollen aanwezig zijn, er meer tijd voor is, update gedaan is, etc.

ja 1.4 Stel datum en tijdstip vast voor DNSSECceremonie

1.4 Bepaal de datum/tijd van de ceremonie.

1.5 Zodra bekend is wanneer de DNSSEC-ceremonie gehouden wordt, moet één van de HSM operators opdracht geven om de backupkaart van de partitie van de HSM uit de externe kluis te laten halen (door de gecontracteerde gespecialiseerde vervoerder, Schippers).

1.5 Laat partitiebackupkaart ophalen uit de kluis.

1.6 Bepaal wie de rolhouders zijn. Dit kunnen de eerstverantwoordelijke rolhouders zijn, maar ook de aangewezen vervangers.

1.6 Stel vast wie de rolhouders zijn.

1.7 Roep het DNSSECteam bij elkaar

1.7 Neem contact op met de rolhouders die bij de DNSSECceremonie aanwezig zijn.

1.10 Laat de partitie-backupkaart terugleggen in de kluis.

1.8 Vraag toestemming start aan 1e Crypto officer

1.9 Toestemming van 1e Crypto officer?

1.8 De 1e Crypto officer wordt gebeld of gemaild. Hij moet toestemming geven voor de start van de DNSSECceremonie, met deze rolhouders en op de geplande dag en tijd. Het DNSSEC-team is getuige van de vraag en het antwoord.

1.9 Geeft de 1e Crypto officer toestemming? Zo ja, dan moet hij een gesigneerde email (PGP) ter bevestiging sturen. Deze email moet ook verstuurd worden als de 1e Crypto Officer fysiek bij de ceremonie aanwezig is.

nee

1.10 Eén van de HSM operators geeft opdracht om de backupkaart terug te leggen in de externe kluis (door de gecontracteerde vervoerder, Schippers). ja

1.11 Stuur gesigneerde email naar DNSSEC-team

1.12 Informeer Communicatie mbt de DNSSEC-ceremonie

1.11 De 1e Crypto officer stuurt de toestemming voor het starten van de DNSSEC-ceremonie per gesigneerde email aan het DNSSEC-team (mailgroep DNSsec ceremonie) 1.12 De 2e Crypto officer laat Communicatie weten dat er een DNSSEC-ceremonie gepland staat.

3.3 1.13 Werk logboek DNSSECceremonie bij.

1.14 Communiceer geplande DNSSEC- ceremonie binnen SIDN

1.15 Start DNSSEC- ceremonie

1.13 In het logboek wordt aangegeven wanneer de DNSSECceremonie start, wie de rolhouders zijn en alle rolhouders tekenen het logboek.

1.14 Communicatie laat medewerkers weten dat er een DNSSEC- ceremonie gepland staat, en wie wat doet.

1.15 Op de geplande datum/tijd start de DNSSEC-ceremonie.

Ga verder met “2. Ophalen tokens en backupkaart” 2


5.2

2. Ophalen tokens en partitie-backupkaart 2

2.1 De tokenhouders moeten met elkaar als getuigen de kluis met tokens openen.

2.1 Alle tokenhouders komen bijeen.

2.2 Werk logboek DNSSEC-ceremonie bij.

2.3 De verzegelde box met de backupkaart is door de gecontracteerde vervoerder afgeleverd op het kantoor van SIDN. De box is door de vervoerde overgedragen aan een HSMoperator, die geïdentificeerd is middels het tonen van een identiteitsbewijs.

2.3 Alle tokenhouders gaan naar ‘tamper proof bag’ met de partitiebackupkaart

2.4 Het zegelnummer van het zegel dat de box met de backupkaart afsluit, wordt gecontroleerd met het zegelnummer dat in het logboek vermeld staat.

2.4 Alle tokenhouders controleren het zegelnummer van de box.

2.5 Komen de zegelnummers overeen?

nee

2.6 Achterhaal de oorzaak en bepaal vervolgacties (escalatie)

ja 2.7 De HSM-operator haalt de partitie-backupkaart uit de box.

2.5 Als het zegelnummer op de box overeenkomt met het genoteerde zegelnummer in het logboek, mag de box geopend worden. Zo niet, dan is er een probleem: de backupkaart met daarop de partitiekopie kan niet vertrouwd worden. Het proces mag daarom niet doorgaan. Het logboek moet worden bijgewerkt en de oorzaak van de verschillende zegelnummers plus vervolgacties moeten worden bepaald. 2.7 Alle rolhouders (behalve de 1e Crypto officer) zijn getuige van het openen van deze box.

2.8 Alle tokenhouders gaan naar de kluis van de Crypto officer.

2.9 De 2e Crypto officer haalt rode token uit de kluis.

2.10 Alle tokenhouders gaan naar de kluis van de HSM-operators.

2.10 De tokens van de HSM-operators liggen in een andere kluis dan de tokens van de Crypto Officer.

2.11 Beide HSM-operators halen het zwarte en blauwe token uit de kluis.

2.11 Beide HSM-operators moeten hun eigen pincode invoeren om de kluis met het ene zwarte token en ene blauwe te kunnen openen.

2.12 Beide HSM-operators halen het password/secret van de HSM-partitie uit de kluis.

2.12 Het secret is nodig om een backup van de HSM-partitie te kunnen maken.

2.13 Werk logboek DNSSECceremonie bij.

3


Ga verder met “3. Voorbereiden KSK-rollover”.

5.3

3. Voorbereiden KSK-rollover 3

3.1 Alle rolhouders en geïnteresseerden verzamelen.

3.1 De rolhouders moeten allemaal aanwezig zijn (met eventuele andere geïnteresseerden uit het bedrijf). nee

3.2 Zijn alle rolhouders aanwezig? 3.2. Als niet alle rolhouders (behalve de 1e Crypto Officer) aanwezig zijn, kan de DNSSEC-ceremonie niet van start gaan.

ja

1.10

3.3 Encrypted email met toestemming 1e Crypto officer

3.4 Is de toestemming van de 1e Crypto officer ontvangen?

nee

3.5 Bepaal actie: wachten op email, opnieuw plannen DNSSEC-ceremonie, ...

3.4 De toestemming van de 1e Crypto officer moet binnen zijn voordat de DNSSEC-ceremonie van start kan gaan. De email komt in de mailbox van/voor het DNSSEC-team.

ja 3.6 Alle aanwezige rolhouders tekenen het logboek.

3.6 Alle drie de rolhouders tekenen het logboek: DNSSEC- Ceremonie start.

3.7 De camera en microfoon in de serverruimte worden gebruikt om opnames te maken. Hiermee kunnen evt. ongeregeldheden later worden opgespoord.

3.7 Start de dvd-opname

9

Alleen na initieel Inrichten HSM

3.8 Via OpenDNSSEC wordt aan de HSM het commando gegeven om een nieuwe KSK aan te maken. Deze KSK blijft buiten zicht van de rolhouders, alleen de naam wordt teruggegeven aan OpenDNSSEC. OpenDNSSEC gaat de KSK in de zone toevoegen als voorbereiding op het rollen.

3.8 Start de KSK-rollover in OpenDNSSEC op de signer

3.9 Vraag in OpenDNSSEC het DS-record op.

3.9 Het DS-record wordt door de HSM-operator via OpenDNSSEC opgevraagd en opgeslagen in een text-bestand. 3.10 De email die de 1e Crypto officer heeft gestuurd, moet geprint worden en aan het DNSSEC-ceremonielogboek worden toegevoegd..

3.10 Voeg toestemmingsemail van 1e Crypto officer toe aan logboek.

3.11 Werk het logboek DNSSEC-ceremonie bij.

3.11 Het logboek van de DNSSECceremonie wordt bijgewerkt met stap “Voorbereiden KSK-rollover”.

3.12 Controleer de dvdopname.

3.12 De dvd met de opname van de serverruimte wordt (versneld) bekeken door alle aanwezigen.

3.13 Is alles in orde?

nee

3.14 Onderbreek de ceremonie.

ja 3.15 Plan event: versturen DSrecord naar root.

4


6

3.14 Als er ongeregeldheden te zien zijn (zoals het wegnemen van tokens, onbevoegde en oncontroleerbare handelingen, etc.) dan moet de ceremonie opnieuw doorlopen worden. 3.15 De nieuwe KSK moet een X tijd (TTL = 2 uur) in de zone staan voordat de KSKrollover kan plaatsvinden. Na deze tijd moet het DS-record naar de root gestuurd worden, dit proces loopt verder bij “6 Versturen DS-record naar root”. Ga verder met “4. Maken backup van KSK”.

5.4

4. Maken backup van KSK-partitie

4

4.1 Log in op de HSM

4.2 Voer partitie-backupkaart in in de HSM

9.29 / 3

4.4 Password/ secret van de partitie

4.3 Geef partitie-backupcommando aan de HSM

4.4 Hergebruik het blauwe token.

4.5 HSM operator geeft toestemming met blauwe token

4.6 2e Crypto officer voert rood token in op HSM

4.7 Hergebruik het rode token.

4.8 Hergebruik het zwarte token.

4.4 Het blauwe token wordt hergebruikt.

4.5 Het blauwe token is nodig om toestemming te geven voor aanmaken van het rode token.

4.6 De crypto officer geeft met het rode token toestemming voor maken backup.

4.7 Het rode token wordt hergebruikt.

4.8 Het zwarte token wordt hergebruikt.

4.9 HSM operator geeft toestemming met zwart token op HSM

4.10 HSM maakt partitiebackup van KSK

4.10 De partitie met de KSK’s wordt in één keer op een PCMCIA-kaart gezet.

4.11 Alle rolhouders gaan naar de ‘tamper proof bag’ voor de KSK-partitiebackupkaart

4.11 Alle rolhouders (behalve de 1e Crypto officer) moeten getuige zijn bij het plaatsen van de KSKpartitiebackup in de box.

4.12 Plaats de partitiebackupkaart en een notitie met card-id en de KSK- en ZSK-keytags in de box

4.13 Verzegel de box met de partitiebackupkaart en noteer het zegelnummer in het logboek.

4.13 Het logboek van de DNSSEC-ceremonie wordt bijgewerkt met het nummer van het zegel dat de box afsluit.

4.14 Zet de box met de partitiebackupkaart op een veilige plaats.

4.14 De tamper proof bag moet op een veilige plaats gezet worden, totdat de vervoerder van de backuplocatie deze komt ophalen (zie proces 15 Wegbrengen partitiebackup naar externe kluis).

4.15 Werk het logboek bij

4.15 Het logboek van de DNSSEC-ceremonie wordt bijgewerkt met stap “Maken backup KSK-partitie”.

5


4.12 Het zegelnummer van de box moet in het logboek worden genoteerd. Ook worden de gegevens van de backupkaart (id en serienummer) genoteerd, evenals de keytags van de KSK en ZSK. Voordat de verzegelde box de volgende keer wordt geopend, moet het nummer gecontroleerd worden.

Ga verder met “5. Beëindigen DNSSEC-ceremonie”.

5.5

5. Beëindigen DNSSEC-ceremonie 5

5.1 Alle tokenhouders gaan naar de kluis van de HSMoperators.

9.29 / 3


5.1 Alle tokenhouders (behalve 1e Crypto Officer) moeten getuige zijn bij het openen van de kluis van de HSM-operators.

5.2 Twee HSMoperators openen de kluis.

5.2 Twee HSM-operators maken de kluis open, waarvoor zij beiden een pincode moeten intoetsen.

5.3 HSM operators leggen zwarte en blauwe token in de kluis.

5.3 In de kluis van de HSM-operators liggen de zwarte en blauwe tokens. Er ligt ook een dichte envelop met een (1) pincode van de kluis van de Crypto officers, die bij de initiële DNSSECceremonie in de kluis is gelegd.

5.5 HSM-operators leggen secret in de kluis.

5.6 Alle tokenhouders gaan naar de kluis van de Crypto officer.

5.7 De kluis van de Crypto officers wordt geopend door twee gebruikers.

5.8 Crypto officer legt rode token in de kluis en sluit de kluis.

5.9 Bevestig het einde van de key ceremonie aan Communicatie

5.9 Communiceer de afloop van de key ceremonie aan Communicatie. Zij zullen de medewerkers en andere betrokkenen (externe partijen) inlichten over het einde van de ceremonie en de aankomende KSK-rollover.

5.10 Werk het logboek DNSSECceremonie bij.

5.10 Het logboek wordt afgetekend door alle aanwezige rolhouders.

5.11 Berg het logboek DNSSEC-ceremonie veilig op


5.7 De twee pincodes zijn nodig om de kluis te openen. De HSM-operator is gebruiker van de kluis van de Crypto officers. Alleen bij de ‘zware’ procedure zijn twee Crypto officers nodig en zij openen hun kluis met hun pincodes. In ‘lichte’ procedures is een 2e Crypto officer en 1 HSMoperator aanwezig om de kluis te openen.

5.11 Het logboek bevat geen vertrouwelijke gegevens en dient alleen ter verificatie dat de procedure correct is gevolgd.

5.6

6. Uitvoeren KSK-rollover

6

6.1 De 2e Crypto Officer voert in IM een ICTchangecall tbv het doorgeven van het DS-record aan IANA in. Deze call komt bij de Change manager uit.

6.1 De 2e Crypto Officer voert ICTchange in in IM.

6.2 De Change Manager voert een CAB-akkoordverzoek in.

6.3 Email met akkoord-verzoek naar 1e Crypto Officer en ICT-mgr.

6.4 Beoordeling en terugmelding op CABakkoordverzoek.

6.2 De Change Manager voert in IM een verzoek voor het CAB (change advisory board) in, met de vraag om akkoord te geven op het doorzetten van het DSrecord naar IANA. Dit CAB-akkoordverzoek komt uit bij de 1e Crypto Officer en de ICT-manager, op dit moment resp. Roelof Meijer en Cees Toet. 6.4 De 1e Crypto Officer en de ICT-manager beoordelen het CAB-akkoordverzoek en sturen een reactie - OK of niet-OK - via email naar IM.

6.5 Email met akkoord/niet akkoord van 1e Crypto Officer 6.5 Email met akkoord/niet akkoord van ICT-mgr

6.6 Change Manager ontvangt antwoord op CABakkoordverzoek.

6.7 Zijn zowel 1e Crypto Officer als ICTmgr akkoord?

6.6 De Change Manager ontvangt in IM antwoord van de 1e Crypto Officer en de ICT-manager.

nee

6.8 De Change Managementprocedure wordt gevolgd.

6.8 Als er geen akkoord wordt gegeven, zal de Change Manager de CM-procedure volgen. Er moet afgestemd worden hoe verdergegaan wordt met de KSK-rollover.

ja 6.9 Change Manager zet IMtaak uit in DNSSEC-queue

3.9

DS-record

6.9 De Change Manager maakt in IM een taak aan voor de HSM-operators, in een aparte DNSSECqueue. Deze taak omvat het versturen van een email met formulier en DS-record aan IANA.

6.10 HSMoperator stelt bericht voor IANA op

6.10 De HSM-operator vult het formulier in en voegt daar het DS-record aan toe.

6.11 De HSMoperator stuurt de email aan IANA.

6.11 De email met het formulier en het DS-record wordt naar IANA gestuurd.

6.12 De HSM-operator voegt de email, het formulier en het DS-record, evenals ticketnummer en de datum/tijd ticketnr van IANA toe aan de IM-call.

6.12 HSMoperator werkt IMcall bij.

6.16


6.13

6.12

6.11

6.13 Email van IANA aan 1e Crypto Officer

6.13 De 1e Crypto Officer en de ICT-manager krijgen een email van IANA met de vraag of zij de change van het DS-record accorderen.

6.13 Email van IANA aan ICT-mgr

6.16 Wachten op bevestiging van doorvoeren wijziging (IANA)

6.14 Beoordeling en terugmelding op akkoordvraag van IANA.

6.14 De 1e Crypto Officer en de ICT-manager beoordelen de vraag om akkoord voor het wijzigen van het ds-record in de root van IANA en sturen een reactie - OK of niet-OK - via email naar IANA.

6.15 Email van 1e Crypto Officer aan IANA

6.15 De 1e Crypto Officer en de ICT-manager sturen een reply op de email van IANA waarin zij akkoord (of niet akkoord) geven voor de wijziging van het DSrecord in de root..

6.15 Email van ICT-mgr aan IANA

6.17 Akkoord van1e Crypto Officer en ICT-mgr?

nee


6.17 Als IANA akkoord heeft van beide personen, de 1e Crypto Officer en de ICT-mgr, dan wordt de wijziging doorgevoerd. Zo niet, dan CM-procedure volgen..

ja 6.19 Wijziging van DS-record in de root wordt doorgevoerd.

6.20 Bevestigingsemail van IANA aan HSM-operator

6.21 HSMoperator werkt IMcall bij.

6.22 HSMoperator vraagt in IM toestemming voor doorstart aan 2e Crypto Officer.

6.21 De HSM-operator voegt de bevestigingsemail van IANA toe aan de IM-call.

6.23 Email met doorstartverzoek naar 2e Crypto Officer.

6.22 De HSM-operator zet via IM een verzoek uit aan de 2e Crypto Officer, deze moet toestemming geven om de afronding van de procedure te starten.

6.24 Beoordeling en terugmelding op doorstartverzoek.

6.24 De 2e Crypto Officer beoordeelt het doorstartverzoek en stuurt een reactie - OK of nietOK - via email naar IM.

6.25 Email met akkoord/niet akkoord van 2e Crypto Officer

6.26


6.20 Als IANA de wijziging van het DS-record in de root heeft doorgevoerd, wordt er een bevestigingsemail aan de HSM-operator gestuurd.

6.22

6.26 Akkoord van 2e Crypto Officer?

nee


6.26 Heeft de 2e Crypto Officer (via IM) akkoord gegeven voor de doorstart van de KSK-rollover? Zo ja, dan gaat de HSM-operator verder. Zo nee, dan moet de CM-procedure gevolgd worden.

ja 6.28 HSMoperator start KSK-rollover in OpenDNSSEC

6.28 De HSM-operator start OpenDNSSEC en beantwoordt de vraag “DS seen?” bevestigend.

6.29 HSMoperator werkt de IM-call bij.

6.29 De HSM-operator vult de IM-call aan met de KSK-rollover in OpenDNSSEC. Dit wordt via IM doorgegeven aan de Change Manager.

6.30 De 2e Crypto Officer stuurt een bericht naar Communicatie.

6.30 De 2e Crypto officer (in de praktijk zal dit echter de Change Manager zijn) bericht aan Communicatie dat de KSK-rollover heeft plaatsgevonden.

6.31 De 2e Crypto officer sluit de call in IM.

6.31 De 2e Crypto officer (in de praktijk zal dit echter de Change Manager zijn) sluit de IM-call..

6.32 Communicatie informeert de belanghebbenden.


6.32 Communicatie zorgt voor de berichtgeving over de KSK-rollover naar buiten.

5.7

7. Restore HSM: KSK-partitie 7

7.1 Event: Restore HSM

7.2 Start Restore HSM direct?

7.1 Aanleiding is een event waardoor de KSKpartitie op de HSM hersteld moet worden.

nee

7.3. Bv: tot alle rollen aanwezig zijn, er meer tijd voor is, update gedaan is, etc.

7.3 Stel Restore HSM uit.

ja 7.4 Bepaal de datum/tijd van de ceremonie.

7.4 Stel datum en tijdstip vast voor Restore HSM


7.5 Neem contact op met de rolhouders en bepaal wie er bij deze procedure aanwezig is.

7.6 Roep het DNSSEC-team bij elkaar

7.7 De 1e Crypto officer wordt gebeld of gemaild. Hij moet toestemming geven voor de start van deze procedure, met deze rollen en op de geplande dag en tijd.



ja

7.9 Bepaal actie: wachten op email, opnieuw plannen Restore HSM, ...

nee



nee

7.8 Geeft de 1e Crypto officer toestemming? Zo ja, dan moet hij een gesigneerde email (PGP) ter bevestiging sturen.

7.11 De toestemming van de 1e Crypto officer moet binnen zijn voordat de DNSSEC-ceremonie van start kan gaan. De email komt in de mailbox van/voor het DNSSEC-team.

ja 7.12 Informeer Communicatie mbt de Restore HSM

7.13 Controleer beide HSM’s en KSK’s

7.14 Maak de HSM leeg

7.13 Voordat de backup wordt teruggezet, wordt eerst de status op beide HSM’s gecontroleerd. 7.14 De HSM die hersteld moet worden, wordt eerst leeggemaakt (default settings), om er zeker van te zijn dat er geen rare dingen blijven staan.

7.15 Maak een HSM-servercertificaat aan

7.16 Initialiseer de HSM


7.18 Geef toestemming voor aanzetten cloning


7.20


7.17 De bestaande tokens worden hergebruikt. Er worden dus geen nieuwe aangemaakt.

7.19

7.20 Activeer het gebruik van cloning.

7.21 Maak partitie aan

7.22 Hergebruik het zwarte token

7.23 HSM maakt partitie aan

7.24 Activeer de partitie

7.25 Koppel de signer aan de HSM

7.26 Koppel standby-signer aan de HSM

7.27 Herstel de High Availability groep

7.28 Synchroniseer de nieuwe HSM

7.27 De HSM-operator controleert de eerder ingerichte HA-groep en koppelt de nieuw ingerichte HSM hieraan. 7.28 De opnieuw ingerichte HSM wordt gesynchroniseerd met de nog draaiende HSM. Hierdoor worden de KSK-partities op beide machines weer identiek.

7.29 Alle drie de rolhouders tekenen het logboek: Restore HSM.

7.30 Beëindigen DNSSEC-ceremonie


7.30 Beëindig de procedure Restore HSM via de procedure Beëindigen DNSSEC-ceremonie

5.8

8. Restore alle HSM’s

Dit proces is tijdkritisch: beide HSM’s zijn om de één of andere reden ontregeld, en moeten opnieuw ingericht worden. Het signeerproces ligt in de tussentijd stil. Er is in de kluis een backupkaart met een backup van de KSK. Ook is het cloning domain er al, namelijk het rode token.


8

8.1 Aanleiding is een event waardoor alle HSM’s hersteld moet worden (backup van de KSK-partitie is er nog en moet worden teruggezet).

8.1 Event: Restore alle HSM’s

8.2 Start Restore alle HSM’s direct?

nee

8.3 Stel Restore alle HSM’s uit.

ja 8.4 Stel datum en tijdstip vast voor Restore alle HSM’s



8.5 Neem contact op met de rolhouders en bepaal wie er bij deze procedure aanwezig is.

8.6 Roep het DNSSEC-team bij elkaar

8.7 De 1e Crypto officer wordt gebeld of gemaild. Hij moet toestemming geven voor de start van deze procedure, met deze rollen en op de geplande dag en tijd.



ja

8.9 Bepaal actie: wachten op email, opnieuw plannen Restore alle HSM’s, ...

nee

8.8 Geeft de 1e Crypto officer toestemming? Zo ja, dan moet hij een gesigneerde email (PGP) ter bevestiging sturen.



nee

ja 8.12 Informeer Communicatie mbt de Restore alle HSM’s

8.13 Alle drie de rolhouders tekenen het logboek

8.14 Voer procedure uit: “2. Ophalen tokens en partitie-backupkaart”.

8.14 Ophalen tokens en partitiebackupkaart

8.15 De camera en microfoon in de serverruimte worden gebruikt om opnames te maken. Hiermee kunnen evt. ongeregeldheden later worden opgespoord.

8.15 Start de dvd-opname

8.16 De aanwezige settings en data op de beide HSM’s wordt gecontroleerd (uitgangssituatie).

8.16 Controleer beide HSM’s en KSK’s

8.17 Maak de HSM leeg

8.17 De HSM wordt door de HSM-operator leeggemaakt tot de fabriekssettings.


8.19 Bij het inrichten van de HSM worden de bestaande tokens hergebruikt. De HSM vraagt om een token en geeft de optie om dit te hergebruiken voor deze installatie.



8.21


8.26

8.20

8.16

8.21 Activeer het gebruik van cloning.

8.22 Voer de partitie-backupkaart in.

8.22 De backup van de partitie met het KSKsleutelmateriaal wordt op de HSM gezet.


9.29 / 3


8.25 De backup van het sleutelmateriaal wordt op de HSM gezet.

8.25 Zet partitiebackup op de HSM

8.26 Beide HSM’s ingericht?

Nee: herhalen voor de volgende HSM

8.27 Koppel de signer aan beide HSM’s

8.27 De HSM-operator koppelt de beide HSM’s aan de signer. Dit vindt niet meer plaats naast de HSM, maar op de (eigen) werkplek.

8.28 Koppel standby-signer aan alle HSM’s

8.29 Controleer de High Availability groep

8.29 De HSM-operator controleert de eerder ingerichte HA-groep en koppelt beide HSM’s hieraan.

8.30 Zet de beide HSM’s in de high availability groep.

8.31 Controleer de settings in OpenDNSSEC.

8.32 Zet OpenDNSSEC aan..

8.31 De HSM-operator controleert de instellingen in OpenDNSSEC en zorgt ervoor dat de HSM’s via de HA-groep bereikbaar zijn en werken zoals het hoort. 8.32 De HSM-operator zet OpenDNSSEC aan om keys aan te maken.

8.33 Alle drie de rolhouders tekenen het logboek: Restore alle HSM’s.

8.34 Beëindigen DNSSEC-ceremonie


8.34 Beëindig de procedure Restore alle HSM’s via de procedure Beëindigen DNSSEC-ceremonie

5.9

9. Initieel inrichten HSM 9

9.1 Event: Initieel inrichten HSM’s

9.1 Beide HSM’s moeten voor het eerst ingericht worden


9.2 Stel datum en tijdstip vast voor Initieel inrichten HSM

9.3 Roep de eerstverantwoordelijke én de vervangende rollen bij elkaar. Iedereen moet aanwezig zijn (4 HSM ops en 4 Crypto officers)

9.3 Roep alle rolhouders én vervangers bij elkaar

9.4 De 1e Crypto officer moet toestemming geven voor de start van de procedure op de geplande dag en tijd.


9.5 Geeft de 1e Crypto officer toestemming? Zo ja, dan moet hij een gesigneerde email (PGP) ter bevestiging sturen. 9.5 Toestemming van 1e Crypto officer?

nee

9.6 Bepaal actie: wachten op email, opnieuw plannen Restore alle HSM’s, ...


ja

9.8 Gesigneerde email van 1e Crypto officer is ontvangen en OK?

ja 9.9 De 2e Crypto officer meldt aan Communicatie dat de HSM’s worden ingericht. Communicatie laat medewerkers weten dat er een DNSSEC- ceremonie gepland staat, en wie wat doet.

9.9 Informeer Communicatie mbt het Initieel inrichten HSM

9.10 Alle rolhouders tekenen het logboek

9.11 Er moeten nieuwe tokens gemaakt worden. Er zijn twee blauwe, twee zwarte en twee rode tokens nodig. De HSM operator zorgt dat de tokens aanwezig zijn.

9.11 Haal nieuwe tokens.

9.12 Er is een nieuwe backupkaart nodig, waarmee later in het proces een backup van de KSK(-partitie) gemaakt kan worden. De HSM operator zorgt dat de backupkaart aanwezig is en noteert de nummers van de kaart op papier. Deze gegevens gaan later in de kluis.

9.12 Haal een nieuwe backupkaart en noteer servicenr en modelnr.

9.13 De fabriekssettings van de HSM worden gecontroleerd. Eventueel wordt een actieve reset uitgevoerd.

9.13 Controleer de settings van de HSM

9.14 Er moet als eerste een servercertificaat aangemaakt en geactiveerd worden.

9.14 Maak HSM servercertificaat aan


ja

9.16 Is dit de 1e HSM?

9.17 Maak blauwe token + 1 backup blauw token aan.

nee


9.18 Voor elke volgende HSM worden deze tokens hergebruikt.

9.19


9.17 De HSM operator initialiseert het blauwe token op de HSM en maakt een backup op een (tweede) blauw token. Blauwe token is voor de HSM admin.

9.30

9.18

9.13

9.19 Geef toestemming voor aanzetten cloning (invoeren blauwe token).


ja 9.21 Maak een rood token + 1 backup rood token aan.

9.19 De HSM-operator geeft met het blauwe token toestemming om cloning aan te zetten.

nee 9.21 De HSM-operator initialiseert het rode token op de HSM en maakt een backup op een (tweede) rood token. Rode token is voor de 2e Crypto officer.


9.22 Voor elke volgende HSM wordt het rode token hergebruikt. 9.23 Activeer het gebruik van cloning (met rode token).

9.24 De HSM-operator geeft het commando om een partitie op de HSM aan te maken.

9.24 Maak een partitie aan.


ja

9.26 Maak zwart token + 1 backup zwart token aan.

nee 9.26 De HSM-operator maakt een zwart token en een backup aan. Het zwarte token is voor de HSM operator en hoort bij de partitie van de HSM.


9.27 Voor elke volgende HSM wordt het zwarte token hergebruikt. 9.29 Password/ secret van de partitie

9.28 HSM maakt partitie aan.

9.29 Activeer de partitie.

9.30 Alle HSM’s ingericht?

4.3

9.28 De HSM maakt de partitie aan met de door de HSM-operator opgegeven naam. De HSM geeft een secret (password) terug: dit is nodig voor het maken van een backup en moet goed bewaard worden, in de kluis met het zwarte token. 9.29 De HSM-operator activeert met het zwarte token de partitie.

Nee: herhalen voor elke volgende HSM

ja 9.31 Koppel de signer aan alle HSM’s

9.31 De HSM-operator koppelt de beide HSM’s aan de signer. Dit vindt niet meer plaats naast de HSM, maar op de (eigen) werkplek.

9.32 Koppel standby-signer aan alle HSM’s

9.33 Configureer de High Availability groep

9.33 De HSM-operator configureert een HA-groep en koppelt de eerste HSM hieraan.

9.34 Zet de 2e HSM in de high availability groep.

9.35 Configureer OpenDNSSEC.

9.36 Maak een repository aan op de HSM.

3.7


9.36 De HSM-operator maakt een repository aan op de (virtuele) HSM. Hierna wordt OpenDNSSEC aangezet om keys aan te maken.

Ga verder met 3.7: “Start KSK-rollover”.

6

Procedures rondom de kluizen

6.1

Inleiding

De tokens, backuptokens en PCMCIA-kaart met de partitiebackup van de HSM worden bewaard in kluizen. Er zijn vijf kluizen in gebruik, te weten: -

1 kluis van de Crypto officers, in het kantoor van SIDN, bedoeld voor de opslag van het rode token,

-

1 kluis van de HSM-operators, in het kantoor van SIDN, bedoeld voor de opslag van het zwarte en het blauwe token,

-

1 kluis van de Crypto officers, op een externe locatie, bedoeld voor de opslag van het rode backuptoken,

-

1 kluis van de HSM-operators, kluis op een externe locatie, bedoeld voor de opslag van het zwarte backuptoken en het blauwe backuptoken,

-

1 kluis voor de partitiebackup van de HSM, op een externe locatie, met daarin de PCMCIA-kaart met de partitiebackup van de HSM.

De kluizen op de externe locatie moeten geopend worden met een sleutel, die bij SIDN wordt bewaard. Er is een reservesleutel beschikbaar, zodat de kluizen ook na verlies van de originele sleutel geopend kunnen worden. Ten behoeve van het veilig bewaren van deze reservesleutel is een (zesde) kluis bij de notaris beschikbaar: -

Een kluis bij de notaris met daarin de reservesleutel voor de externe backupkluizen.

De kluis van de Crypto officers en de kluis van de HSM-operators in het kantoor van SIDN zijn voorzien van sloten met pincodes. Op elke kluis kunnen meerdere (N, maximaal 9) gebruikers gedefinieerd worden. Voor het openen van een kluis zijn de pincodes van twee gebruikers nodig. Geen enkele persoon kent meer dan één pincode van één kluis, waarmee wordt afgedwongen dat voor het openen van een kluis minimaal 2 personen (van de N gebruikers) aanwezig moeten zijn. e

De 2 Crypto officer heeft een pincode voor de kluis van de Crypto officers. Voor de DNSSEC-ceremonie is de fysieke e

e

aanwezigheid van alleen de 2 Crypto officer verplicht: de 1 Crypto officer mag op afstand toestemming verlenen voor het uitvoeren van de ceremonie, en heeft daarom geen pincode van de kluis nodig. De kluis van de Crypto officers kan echter alleen door twee personen geopend worden, zodat er een 4-ogencontrole ontstaat. Om toch zowel de gecontroleerde toegang tot de kluis als het uitvoeren van de DNSSEC-ceremonie mogelijk te maken, ligt er 1 pincode voor de kluis van de Crypto officers in een dichte envelop in de kluis van de HSM-operators. Met deze pincode kan één HSM-operator, samen e

met de 2 Crypto officer, de kluis van de Crypto officers openen. De kluis van de Crypto officers en de kluis van de HSM-operators in het pand van SIDN kennen drie soorten pincodes: 1. De masterpincode, waarmee de kluismaster toegang krijgt tot het mastersmenu. In het mastersmenu van de kluismaster wordt de pincode van de kluismanager ingesteld. 2. De managerspincode, waarmee de kluismanager toegang krijgt tot het managersmenu. In het managersmenu wordt het gebruikersbeheer voor de kluis uitgevoerd. De manager is tevens een gebruiker en de managerspincode is tevens een gebruikerspincode.


3. De gebruikerspincode, waarmee de kluis (mede) geopend kan worden. Zowel de kluis van de Crypto officers als de kluis van de HSM-operators kunnen alleen geopend worden wanneer er twee gebruikers van die kluis hun pincode invoeren.

6.2

Procedures rondom toegang tot de kluizen

In de volgende paragrafen worden de procedures omtrent het gebruik van de kluizen en de inrichting van de toegang tot de kluizen beschreven. Deze procedures zijn de volgende: Op locatie bij SIDN: 10.

Initieel inrichten van de kluizen

11.

Beheren van de gebruikers van de kluizen

Op externe backuplocatie: 12.

Ophalen van backuptokens uit de externe kluis

13.

Wegbrengen van backuptokens naar de externe kluis

14.

Ophalen van de partitiebackup uit de externe kluis

15.

Wegbrengen van de partitiebackup naar de externe kluis

De gedetailleerde uitwerking van de procedures 12 t/m 15 zijn beschreven in het document ‘SEC-PD-DNSsec externe kluisprocedures’. In dit document staan onder meer de namen en rollen van de personen die conform de procedure aanwezig moeten zijn bij het openen van de kluizen op de externe locatie. Bij de notaris: 16.

Wegbrengen van de reservesleutel naar de notaris

17.

Ophalen van de reservesleutel bij de notaris


6.3

10. Initieel inrichten van kluizen


10

10.1 De 1e Crypto officer gaat naar de kluis van de HSM-operators.

10.1 In geval van een nieuwe kluis of een reset van de kluis moet de 1e Crypto officer de standaard master pincode van de kluis van de HSM-operators wijzigen.

10.2 De kluis wordt geopend, de deur blijft open.

10.2 De default pincode is 12345678. De kluisdeur moet openstaan om de master pincode te wijzigen.

10.3 De 1e Crypto officer wijzigt standaard master pincode

10.3 De 1e Crypto officer moet een zelfgekozen 8-cijferige code invoeren.

10.4 De 1e Crypto officer geeft code aan zijn vervanger.

10.4 De 1e Crypto officer moet deze code delen met minimaal 1 andere 1e Crypto officer (zijn vervanger).

10.5 De 1e Crypto officer gaat naar de kluis van de Crypto officers.

10.5 In geval van een nieuwe kluis of een reset van de kluis moet de 1e Crypto officer de standaard master pincode van de kluis van de Crypto officers wijzigen.


10.6 De default pincode is 12345678. De kluisdeur moet openstaan om de master pincode te wijzigen.

10.7 De 1e Crypto officer wijzigt standaard master pincode

10.7 De 1e Crypto officer moet een zelfgekozen 8-cijferige code invoeren.

10.8 De 1e Crypto officer geeft code aan zijn vervanger.

10.8 De 1e Crypto officer moet deze code delen met minimaal 1 andere 1e Crypto officer (zijn vervanger).

10.9 De 1e Crypto officer wijst de managers van beide kluizen aan.

10.9 De 1e Crypto officer wijst officieel de manager van de HSMoperatorskluis en de manager van de Crypto-officerskluis aan. De beide managers zijn ook gebruikers van de kluis.

10.10

De stappen tot aan dit punt kunnen door de 1e Crypto officer worden uitgevoerd buiten de ceremonie om. De vervolgstappen moeten vallen onder procedurele controles.


10.10

10.11 De HSMoperators gaan naar de kluis van de HSM-operators

10.11 Alle HSM-operators gaan naar hun eigen kluis.

10.12 De kluis van de HSM-operators wordt geopend (met de default settings).


10.13 De manager van de kluis van de HSM-operators wijzigt de standaard manager-code. De default code is 123456. De manager voert een zelfgekozen 6-cijferige code in.

10.13 De manager van de kluis van de HSM-operators wijzigt de code.

10.14 Test – met de deur open – of de code werkt.

nee

10.14 De manager van de kluis van de HSM-operators voert zijn nieuwe code in en controleert of de code werkt. Deze test wordt uitgevoerd terwijl de deur van de kluis open staat. Als de code niet werkt, wordt hij opnieuw ingevoerd.

10.15 Werkt de code van de manager?

ja 10.16 HSMoperator of vervanger wijzigt standaard code.


10.16 Elke HSM-operator en elke vervanger moet gebruiker worden van de kluis van de HSM-operators. Elke gebruiker moet de standaard gebruikerscode wijzigen. De default code is 123456. De gebruiker voert een zelfgekozen 6-cijferige code in.

nee

10.18 Werkt de code van de gebruiker?

ja nee 10.23

10.19 Alle gebruikers toegevoegd?

ja

10.20


10.17 De gebruiker van de kluis van de HSM-operators voert zijn nieuwe code in en controleert of de code werkt. Deze test wordt uitgevoerd terwijl de deur van de kluis open staat. Als de code niet werkt, wordt hij opnieuw ingevoerd.

10.19

10.20 Manager verwijdert overige gebruikers

10.20 De manager van de kluis verwijdert de overige gebruikersslots op de kluis. Hiervoor moet behalve de manager, ook (minimaal) één HSM-operator zijn code intoetsen.

10.21 Het logboek van de kluis wordt bijgewerkt.

10.21 In het logboek van de kluis wordt vastgelegd: wie de manager (gebruiker 1) van de kluis is en wie de overige gebruikers (2 t/m 8) zijn.

10.22 HSMoperators controleren aantal gebruikers

10.22 De HSM-operators verifiëren of het aantal actieve gebruikers op de kluis (dit is het aantal gebruikersslots die op de kluis zijn ingevoerd) overeenkomt met het aantal HSM-operators. Er mogen niet meer kluisgebruikers zijn dan er HSM-operators zijn, zodat de kans op fraude minimaal is.

10.23 Aantal gebruikers OK?

10.16

10.23 Als er nog overbodige gebruikersslots op de kluis zijn, moeten deze alsnog verwijderd worden. Als er HSM-operators zijn zonder gebruikerscode, moeten deze nog toegevoegd worden.

ja 10.24 De HSM-operators tekenen het logboek voor akkoord. Het logboek wordt in de kluis gelegd.

10.24 Teken het logboek

10.25 De kluis van de HSM-operators wordt gesloten. Deze kan nu alleen nog met twee gebruikers worden geopend.

10.25 Sluit de kluis van de HSMoperators

De kluis van de HSM-operators is nu ingericht. Vervolgen met de kluis van de Crypto officers.

10.26 De Crypto officers gaan naar de kluis van de Crypto officers

10.26 Alle Crypto officers gaan naar hun eigen kluis.


10.27 De kluis van de Crypto officers wordt geopend (met de default settings).

10.28 De manager van de kluis van de Crypto officers wijzigt de code.

10.28 De manager van de kluis van de Crypto officers wijzigt de standaard manager-code. De default code is 123456. De manager voert een zelfgekozen 6-cijferige code in.


nee

10.29 De manager van de kluis van de Crypto officers voert zijn nieuwe code in en controleert of de code werkt. Deze test wordt uitgevoerd terwijl de deur van de kluis open staat. Als de code niet werkt, wordt hij opnieuw ingevoerd.

10.30 Werkt de code van de manager?

ja 10.31


10.30

10.31 De 2e Crypto officer of vervanger wijzigt standaard code.


10.31 Elke 2e Crypto officer en elke vervanger moet gebruiker worden van de kluis van de Crypto officers. Elke gebruiker moet de standaard gebruikerscode wijzigen. De default code is 123456. De gebruiker voert een zelfgekozen 6-cijferige code in.

10.32 De gebruiker van de kluis van de Crypto officers voert zijn nieuwe code in en controleert of de code werkt. Deze test wordt uitgevoerd terwijl de deur van de kluis open staat. Als de code niet werkt, wordt hij opnieuw ingevoerd.

nee


ja nee 10.34 Alle gebruikers toegevoegd?

ja

nee

10.35 Manager verwijdert overige gebruikers

10.35 De manager van de kluis verwijdert de overige gebruikersslots op de kluis. Hiervoor moet behalve de manager, ook (minimaal) één 2e Crypto officer zijn code intoetsen.


10.36 In het logboek van de kluis wordt vastgelegd: wie de manager (gebruiker 1) van de kluis is en wie de overige gebruikers (2 t/m 8) zijn.

10.37 De 2e Crypto officers controleren aantal gebruikers

10.37 De 2e Crypto officers verifiëren of het aantal actieve gebruikers op de kluis (dit is het aantal gebruikersslots die op de kluis zijn ingevoerd) overeenkomt met het aantal 2e Crypto officers. Er mogen niet meer kluisgebruikers zijn dan er 2e Crypto officers zijn, zodat de kans op fraude minimaal is.

10.38 Als er nog overbodige gebruikersslots op de kluis zijn, moeten deze alsnog verwijderd worden. Als er 2e Crypto officers zijn zonder gebruikerscode, moeten deze nog toegevoegd worden.


ja 10.39 De 2e Crypto officers tekenen het logboek voor akkoord. Het logboek wordt in de kluis gelegd.


10.40 Sluit de kluis van de Crypto officers

10.40 De kluis van de 2e Crypto officers wordt gesloten. Deze kan nu alleen nog met twee gebruikers worden geopend.

De kluis van de Crypto officers is nu ingericht.


6.4

11. Beheren van gebruikers van kluizen

11

11.1 Kluismanager en kluismaster bepalen wijziging in gebruikers

11.1 De manager van de kluis bepaalt met de master van de kluis (dat is de 1e Crypto officer) welke wijziging in de gebruikersinstellingen van de kluis gewenst is. Dit kan een nieuwe gebruiker zijn, een gebruiker die van de kluis verwijderd moet worden, of een gebruiker die geblokkeerd moet worden.

11.2 Kluismanager informeert alle andere gebruikers van de kluis.

11.2 De manager van de kluis stelt alle andere gebruikers van de kluis op de hoogte van de wijziging die gaat worden doorgevoerd.

11.3 Kluismanager en minstens 1 andere gebruiker gaan naar de kluis

11.3 De manager van de kluis en minstens één andere kluisgebruiker gaan naar de kluis. De kluis kan alleen geopend worden met tenminste twee pincodes.

11.4 Het logboek wordt bijgewerkt.

11.4 Het logboek wordt bijgewerkt: het besluit van de kluismanager en de kluismaster om een wijziging door te voeren in de gebruikersinstellingen van de kluis wordt vastgelegd.


11.5 Beide gebruikers, de kluismanager en de andere gebruiker, voeren hun pincode in en openen de kluis. De deur blijft open staan.

11.6 De kluismanager logt in in het managersmenu

11.6 De manager van de kluis logt in op het managersmenu van de kluis met de managerspincode.

11.7 De andere gebruiker logt in in het managersmenu

11.7 De andere gebruiker van de kluis logt in met zijn eigen gebruikerspincode.

11.8 De kluismanager voert de wijziging door.

11.8 De kluismanager voert de wijziging door zoals afgesproken (toevoegen gebruiker, verwijderen of blokkeren gebruiker).

11.9 De andere gebruiker controleert de acties van de kluismanager

11.10 Wijzigingen ok?

nee

11.9 De andere gebruiker van de kluis checkt of de kluismanager de wijzigingen doorvoert zoals afgesproken. Hij kijkt dus mee op het scherm van de kluis.

11.10 Zijn de wijzigingen doorgevoerd zoals afgesproken? Zo ja, dan wordt het logboek bijgewerkt. Zo nee, dan moeten de juiste wijzigingen alsnog worden doorgevoerd.

ja

11.11 Het logboek wordt bijgewerkt.

11.11 Het logboek van de kluis wordt bijgewerkt met de zojuist uitgevoerde wijzigingen.

11.12


11.11

11.12 Is er een gebruiker toegevoegd?

nee

ja 11.13 Nieuwe gebruiker wijzigt standaard code.


11.13 De nieuwe gebruiker van de kluis voert zijn nieuwe code in en controleert of de code werkt. Deze test wordt uitgevoerd terwijl de deur van de kluis open staat. Als de code niet werkt, wordt hij opnieuw ingevoerd.

nee


ja nee 11.16 Alle gebruikers toegevoegd?

ja

nee

11.17 Manager verwijdert overige gebruikersslots.

11.17 De manager van de kluis verwijdert de overige gebruikersslots op de kluis. Hiervoor moet behalve de manager, ook (minimaal) één andere gebruiker zijn code intoetsen.


11.18 In het logboek van de kluis wordt vastgelegd: wie de nieuwe gebruiker van de kluis is (één van de gebruikers 2 t/m 8).

11.19 Controleer het aantal actieve gebruikers

11.19 De 2e Crypto officer verifieert of het aantal actieve gebruikers op de kluis (dit is het aantal gebruikersslots die op de kluis zijn ingevoerd) overeenkomt met het aantal HSM-operators of 2e Crypto officers (afhankelijk van welke kluis het betreft). Er mogen niet meer kluisgebruikers zijn dan er 2e Crypto officers of HSM-operators zijn, zodat de kans op fraude minimaal is.


11.20 Als er nog overbodige gebruikersslots op de kluis zijn, moeten deze alsnog verwijderd worden. Als er gebruikers zijn zonder gebruikerscode, moeten deze nog toegevoegd worden.

ja


11.22 Sluit de kluis.

11.21 De aanwezigen tekenen het logboek voor akkoord. Het logboek wordt in de kluis gelegd.

11.22 De kluis wordt gesloten. Deze kan nu alleen nog met twee gebruikers worden geopend.


6.5

12. Ophalen backuptokens uit de externe kluis

12

12.1 Meld ophalen backuptokens bij backuplocatie

Rode backuptoken (Crypto officer)

12.1 Afhankelijk van de vraag welke backuptokens nodig zijn, zal de 2e Crypto officer of de HSM-operator contact opnemen met de backuplocatie, in dit geval Schipper Safestore. Er wordt doorgegeven dat medewerkers van SIDN naar de backuplocatie zullen komen om het (de) token(s) op te halen.

12.2 Welke backuptokens moeten worden opgehaald?

Zwarte en blauwe backuptokens (HSM-operators)

12.3 De 2e Crypto officer belt backuplocatie

12.4 De HSMoperator belt backuplocatie 12.5 In de kluis bij SIDN ligt de sleutel waarmee de kluis op de backuplocatie kan worden geopend. In de kluis van de Crypto officer ligt de sleutel van de Crypto-officerkluis op de backuplocatie, in de kluis van de HSM-operators ligt de kluis van de HSM-operatorskluis op de backuplocatie.

12.5 De tokenhouders halen de sleutel uit de kluis.

12.6 Als de blauwe en zwarte backuptokens worden opgehaald, gaan de twee HSM-operators naar de backuplocatie. Als het rode backuptoken wordt opgehaald, gaan de twee HSM-operators én de 2e Crypto officer naar de backuplocatie.

12.6 De tokenhouders gaan naar de backuplocatie

12.7 De tokenhouders legitimeren zich bij de backuplocatie

12.7 De tokenhouders (medewerkers van SIDN) moeten zich legitimeren bij de backuplocatie.

12.8 De medewerker van de backuplocatie controleert de legitimatie en gaat na of de juiste tokenhouders aanwezig zijn (2e Crypto officer en 2 HSM-operators voor het rode backuptoken óf 2 HSM-operators voor zwarte/blauwe backuptokens). Lijst met namen en rollen zijn aanwezig ter verificatie.

12.8 Medewerker van de backuplocatie controleert legitimatie

12.9 Legitimatie en rollen OK?

nee

12.10 Backuplocatie escaleert naar bestuurder SIDN.

12.9 Als de legitimatie en rollen in orde zijn, mogen de tokenhouders naar binnen. Als de legitimatie en/of rollen niet in orde zijn, eindigt hier het proces; de SIDNmedewerkers komen niet binnen.

12.11 Directie backuplocatie en SIDN stemmen vervolg af.

12.12 De tokenhouders worden naar de juiste kluis gebracht. Dat kan de kluis voor het rode backuptoken zijn, of de kluis voor de zwarte en blauwe backuptokens.

ja 12.12 Tokenhouders worden naar kluis gebracht.

12.13 Tokenhouders halen security pack uit de kluis

12.14


12.13 De tokenhouders openen de kluis met de sleutel, halen het security pack met daarin de backuptokens uit de kluis en sluiten de kluis.

12.13

12.14 De tokenhouders controleren het zegelnummer van het security pack. Dit zegelnummer moet overeenkomen met het nummer dat genoteerd staat in het logboek, zoals dat is genoteerd toen de backuptokens in de kluis werden gelegd.

12.14 Tokenhouders controleren nummer van security pack

12.15 Nummer van security pack is OK?

nee

12.16 Escaleer naar 1e Crypto officer

12.16 Als de nummers niet overeenkomen, is er iets mis: misschien klopt het logboek niet, misschien is er gerommeld met de backuptokens. Deze backuptokens mogen niet gebruikt worden. De tokenhouders escaleren naar de 1e Crypto officer, die de vervolgstappen moet bepalen.

12.17 De 1e Crypto bepaalt vervolgstappen.

12.18 Als het zegelnummer op het security pack overeenkomt met het nummer uit het logboek, is alles OK. Het logboek wordt getekend door de tokenhouders en door de medewerker van de backuplocatie.

ja

12.18 Werk logboek bij.

12.19 Tokenhouders gaan met de backuptokens terug naar SIDN

12.20 De tokenhouders leggen de sleutel en de tokens in de kluis



12.19 De tokenhouders gaan met de backuptokens terug naar SIDN.

12.20 De sleutel van de externe kluis wordt in de kluis bij SIDN teruggelegd. De backuptokens worden opgeslagen in de kluizen van de Crypto officers en de HSMoperators, totdat ze gebruikt gaan worden in de ceremonie. In de praktijk zal er namelijk tijd zitten tussen aankomst op het kantoor van SIDN en het starten van de DNSSEC-ceremonie.

12.21 Tenslotte wordt het logboek bijgewerkt. Alle betrokken tokenhouders tekenen het logboek. Dit logboek wordt bewaard.

6.6

13. Wegbrengen backuptokens naar de externe kluis 13

13.1 Meld wegbrengen backuptokens bij backuplocatie

Rode backuptoken (Crypto officer)

13.1 Afhankelijk van de vraag welke backuptokens weggebracht moeten worden, zal de 2e Crypto officer of de HSM-operator contact opnemen met de backuplocatie, in dit geval Schipper Safestore. Er wordt doorgegeven dat medewerkers van SIDN naar de backuplocatie zullen komen om het (de) token(s) in de kluis te leggen.

13.2 Welke backuptokens moeten worden weggebracht?

Zwarte en blauwe backuptokens (HSM-operators)

13.3 De 2e Crypto officer belt backuplocatie

13.4 De HSMoperator belt backuplocatie 13.5 De backuptokens en sleutels worden uit de kluis gehaald.

13.5 De backuptokens zijn na creatie in een security pack gedaan en deze is in de kluis gelegd. In de kluis ligt ook de sleutel waarmee de kluis op de backuplocatie kan worden geopend. Security pack en sleutel moeten nu uit de kluis gehaald worden volgens de procedure. Daarna worden de tokens (in security pack) weggebracht. 13.6 Als de blauwe en zwarte backuptokens worden weggebracht, gaan de twee HSM-operators naar de backuplocatie. Als het rode backuptoken wordt weggebracht, gaan de twee HSM-operators én de 2e Crypto officer naar de backuplocatie.

13.6 De tokenhouders gaan naar de backuplocatie

13.7 De tokenhouders legitimeren zich bij de backuplocatie

13.7 De tokenhouders (medewerkers van SIDN) moeten zich legitimeren bij de backuplocatie.

13.8 Medewerker van de backuplocatie controleert legitimatie

13.8 De medewerker van de backuplocatie controleert de legitimatie en gaat na of de juiste tokenhouders aanwezig zijn (2e Crypto officer en 2 HSM-operators voor het rode backuptoken óf 2 HSM-operators voor zwarte/blauwe backuptokens). Lijst met namen en rollen zijn aanwezig ter verificatie.

13.9 Legitimatie en rollen OK?

nee

13.10 Backuplocatie escaleert naar bestuurder SIDN.

13.9 Als de legitimatie en rollen in orde zijn, mogen de tokenhouders naar binnen. Als de legitimatie en/of rollen niet in orde zijn, eindigt hier het proces; de SIDNmedewerkers komen niet binnen.

13.11 Directie backuplocatie en SIDN stemmen vervolg af.

13.12 De tokenhouders worden naar de juiste kluis gebracht. Dat kan de kluis voor het rode backuptoken zijn, of de kluis voor de zwarte en blauwe backuptokens.

ja 13.12 Tokenhouders worden naar kluis gebracht.

13.13 Tokenhouders maken kluis open met de sleutel

13.13 De tokenhouders openen de kluis met de sleutel die SIDN zelf bewaart.

13.14 Tokenhouders doen security pack in de kluis.

13.14 De tokenhouers doen het security pack met daarin de backuptokens in de kluis en sluiten de kluis.


13.15 Het logboek wordt getekend door de tokenhouders en door de medewerker van de backuplocatie.

13.16


13.15

13.16 Tokenhouders gaan terug naar SIDN

13.17 De tokenhouders leggen de sleutel van de backupkluis terug.



13.17 De sleutel van de kluis van de backuplocatie wordt bij SIDN weer in de kluis van de Crypto officer (igv rode token) of de HSM-operators (igv zwarte en blauwe token) gelegd.

13.18 Tenslotte wordt het logboek bijgewerkt. Alle betrokken tokenhouders tekenen het logboek. Dit logboek wordt bewaard.

6.7

14. Ophalen van de partitiebackup uit de externe kluis


14

14.1 De HSM-operator neemt contact op met de backuplocatie, in dit geval Schipper Safestore. De ‘tamper proof bag’ (safepack) met daarin de kaart met de partitiebackup wordt besteld.

14.1 Bestel de levering van de partitiebackup.

14.2 De ‘tamper proof bag’ met de kaart met de partitiebackup wordt naar het gebouw van SIDN vervoerd.

14.2 Vervoerder komt naar SIDN

14.3 De vervoerder meldt zich bij de receptie

14.4 Is de legitimatie OK?

nee

ja

14.5 Vervoerder neemt partitiebackup terug naar backuplocatie.

14.6 Backuplocatie en SIDN stemmen vervolg af.

14.7 De vervoerder geeft partitiebackup aan HSM-operators

ja

14.12 Werk het logboek bij.

14.13 De HSMoperators leggen de partitiebackup in de kluis

14.14 Werk het logboek bij.

14.5 De vervoerder mag de ‘tamper proof bag’ niet afgeven. Hij keert – met de partitiebackup - terug naar de backuplocatie. 14.6 De directie van de backuplocatie en SIDN stemmen af wat er mis ging en wat er nu moet gebeuren. 14.7 De vervoerder geeft de ‘tamper proof bag’ aan de HSM-operators.

14.8 HSMoperators controleren safepacknummer

14.9 Komen de nummers overeen?

14.4 De vervoerder controleert de legitimatie van de HSM-operators. Zijn deze twee SIDN-medewerkers HSM-operators die de partitiebackup in ontvangst mogen nemen?

14.8 De HSM-operators controleren of het nummer van de ‘tamper proof bag’ overeenkomt met het nummer dat genoteerd staat in het logboek. Dit nummer is genoteerd toen de backupkaart in de ‘tamper proof bag’ is gedaan en dit nummer moet gelijk zijn aan het nummer op de zojuist afgeleverde safepack.

nee

14.10 Bestuurder SIDN escaleert naar bestuurder backuplocatie.

14.9 Als de nummers uit het logboek en op de safepack overeenkomen, is alles in orde. Zo niet, dan wordt er geëscaleerd.

14.11 Directie backuplocatie en SIDN stemmen vervolg af. 14.12 De vervoerder en de HSM-operators tekenen het logboek. Hierna kan de vervoerder weer vertrekken.

14.13 De partitiebackup worden opgeslagen in de kluis van de HSM-operators, totdat hij gebruikt gaat worden in de ceremonie. In de praktijk zal er namelijk tijd zitten tussen aankomst op het kantoor van SIDN en het starten van de DNSSEC-ceremonie.

14.14 Tenslotte wordt het logboek bijgewerkt. De HSMoperators tekenen het logboek. Dit logboek wordt bewaard.


6.8

15. Wegbrengen van de partitiebackup naar de externe kluis 15

15.1 Bestel bij de backuplocatie ophalen van partitiebackup.

15.1 De HSM-operator neemt contact op met de backuplocatie, in dit geval Schipper Safestore. De ‘tamper proof bag’ (safepack) met daarin de kaart met de partitiebackup moet worden opgehaald bij SIDN en naar de backuplocatie worden vervoerd.

15.2 Vervoerder komt naar SIDN

15.3 De vervoerder meldt zich bij de receptie

15.4 HSMoperators controleren de legitimatie

15.5 Is legitimatie OK?

15.4 De HSM-operators controleren de legitimatie van de medewerker van de backuplocatie. Komt deze persoon voor op de lijst met geautoriseerde personen die de partitiebackup in ontvangst mogen nemen?

nee

15.6 Vervoerder keert terug naar backuplocatie.

15.6 Als de legitimatie niet in orde is of als deze persoon niet door de backuplocatie is geautoriseerd, krijgt hij de partitiebackup niet mee. Hij kan terugkeren naar de backuplocatie. Er moet vervolgens worden afgestemd wat de vervolgstappen zijn.

ja

4.13

Partitiebackup In safepack

15.8 HSMoperators halen partitiebackup uit de kluis

15.7 Backuplocatie en SIDN stemmen vervolg af.

15.9 De HSMoperators geven partitiebackup aan vervoerder.

15.9 De HSM-operators overhandigen de safepack aan de vervoerder.

15.10 De vervoerder noteert het zegelnummer van de safepack.

15.10 De vervoerder noteert het zegelnummer van de safepack in zijn eigen administratie, zodat een volgende keer het juiste zegelnummer gecommuniceerd kan worden.

15.11 Het logboek wordt bijgewerkt

15.11 Het logboek wordt door de vervoerder en de HSMoperators getekend en bewaard.

15.12 Vervoerder brengt partitiebackup naar de kluis op backup-locatie

15.12 De vervoerder rijdt met de safepack naar de backuplocatie en bergt de verzegelde partitiebackup op in de kluis.


15.8 De HSM-operators halen gezamenlijk de safepack met daarin de kaart met de partitiebackup uit de kluis van de HSM-operators. Deze safepack is verzegeld en het nummer van het zegel is bij het verpakken van de kaart genoteerd in het logboek.

6.9

16. Wegbrengen van de reservesleutel naar de notaris

16

16.1 De 1e Crypto Officer gaat naar notaris

16.1 De rolhouder die de backupsleutel bij de notaris mag afleveren is benoemd in het document “Rollen en rolhouders voor de DNSSEC-ceremonie.doc” versie 2. De 1e Crypto Officer – in dit geval de directeur – is vooralsnog de enige die de sleutel mag afleveren

16.2 De 1e Crypto Officer legitimeert zich met zijn paspoort

16.2 De rolhouder met de backupsleutel meldt zich bij de notaris of diens vervanger en legitimeert zich met zijn paspoort.

16.3 Legitimatie OK?

16.3 De notaris controleert de identiteit van de rolhouder met de backupsleutel.

nee

ja

16.6 Is de rolhouder bevoegd?

nee

16.4 Rolhouder keert terug naar SIDN.

ja 16.7 Notaris neemt de backupsleutel in bewaring.

16.5 SIDN en notaris stemmen vervolg af.


16.4 en 16.5 Als de legitimatie niet in orde is of als deze persoon niet door de backuplocatie is geautoriseerd, kan de notaris de backupsleutel niet aannemen. De rolhouder moet terugkeren naar SIDN. Er moet vervolgens worden afgestemd wat de vervolgstappen zijn. 16.6 De notaris controleert de bevoegdheid van de rolhouder met de backupsleutel: staat deze persoon vermeld op de meest recente lijst met geautoriseerde rolhouders. 16.7 De notaris neemt de backupsleutel in bewaring. De rolhouder kan terugkeren naar SIDN.

6.10

17. Ophalen van de reservesleutel bij de notaris

17

17.1 Eén van de rolhouders gaat naar notaris

17.1 De rolhouders die de backupsleutel bij de notaris mogen ophalen zijn benoemd in het document “Rollen en rolhouders voor de DNSSEC-ceremonie.doc” versie 2. De toegestane rollen in dit proces zijn: (vervangende) 1e Crypto Officer en de 2e Crypto Officer

17.2 De rolhouder legitimeert zich met zijn paspoort

17.2 De rolhouder die de backupsleutel komt ophalen, meldt zich bij de notaris of diens vervanger en legitimeert zich met zijn paspoort.

17.3 Legitimatie OK?

17.3 De notaris controleert de identiteit van de rolhouder die de backupsleutel komt ophalen. nee

ja

17.6 Is de rolhouder bevoegd?

nee

17.4 Rolhouder keert terug naar SIDN.

ja 17.7 Notaris haalt de backupsleutel uit depot.

17.5 SIDN en notaris stemmen vervolg af.

17.4 en 17.5 Als de legitimatie niet in orde is of als deze persoon niet door de backuplocatie is geautoriseerd, kan de notaris de backupsleutel niet afgeven. De rolhouder moet terugkeren naar SIDN. Er moet vervolgens worden afgestemd wat de vervolgstappen zijn. 17.6 De notaris controleert de bevoegdheid van de rolhouder met de backupsleutel: staat deze persoon vermeld op de meest recente lijst met geautoriseerde rolhouders. 17.7 De notaris haalt de backupsleutel uit depot.

17.8 De notaris overhandigt de backupsleutel aan de rolhouder

17.8 De notaris overhandigt de backupsleutel aan de rolhouder.

17.9 De rolhouder keert terug naar SIDN

17.9 De rolhouder keert met de backupsleutel terug naar SIDN.


CEREMONIE HANDBOEK. voor de DNSSEC ceremonie. Krista Vermeulen. ICT-pd-Requirements en procedure voor de DNSSEC ceremonie-v1.4 Definitief Public

Recommend Documents