Delegeer het uitgeven van VPN-certificaten zonder de rootsleutel

Iemand de mogelijkheid geven om VPN-clients te registreren en hem een draagbare kopie van de rootsleutel geven zijn twee verschillende daden, en het verschil wordt pas zichtbaar wanneer die persoon vertrekt of die sleutel uitlekt. Het eerste verleent een handeling binnen een werkstroom die u beheert; het tweede verleent de mogelijkheid om overal, offline en onbeperkt vertrouwen te scheppen. Beslis welke van de twee het werk nodig heeft voordat u sleutelmateriaal aanraakt. Een hiërarchiediagram beantwoordt die vraag niet voor u.

Schrijf de registratietaak op als drie vragen: wie mag aanvragen, wie keurt goed, en wat de uitgevende component mag ondertekenen.

Beslis welke bevoegdheid u verleent

Een uitgevende dienst kan een goedkeuringsworkflow aanbieden terwijl het ondertekeningsmateriaal bij een aparte eigenaar blijft. Een operator keurt een apparaatverzoek goed, de dienst past beleid toe en registreert de uitgifte, en niemand van de betrokkenen houdt de CA-sleutel. Documenteer de toegestane identiteiten, de goedkeurders en de reikwijdte van wat de dienst mag ondertekenen; bescherm daarna het beheer ervan even zorgvuldig als de sleutel. Een certificaatondertekeningsverzoek is een verzoek, geen autorisatiebeslissing.

Hardware-ondersteunde opslag verandert het risico dat de sleutel wordt gekopieerd, niet de noodzaak van autorisatie. Niet-exporteerbaar betekent dat de sleutel er niet uit kan worden gehaald, en het betekent niet dat iedereen die de ondertekeningsinterface kan aanroepen recht heeft op een certificaat. Beoordeel die twee eigenschappen afzonderlijk.

Een tussenliggend certificaat begrenst de bevoegdheid

Een root kan een tussenliggend certificaat certificeren voor dagelijkse uitgifte, zodat routinewerk de rootsleutel niet meer aanraakt, zolang de eigen ondertekenings- en herstelprocedures van de root beschermd blijven. Dat is een echte grens en ze is niet gratis: nog een certificaat, nog een sleutel, nog een verlenging en nog een intrekkingslijst om te onderhouden. Gebruik er een wanneer het een bewuste beheer- of risicogrens vertegenwoordigt. Per beheerder een uitgever aanmaken levert meer van alles op en koopt niets wat de werkstroom niet al bood.

Controleer dat de VPN-verifieerders de keten bouwen zoals u verwacht. Een tussenliggend certificaat leveren voor ketenopbouw en het installeren als rechtstreeks vertrouwd anker zijn verschillende regelingen.

pathLen nul betekent niet wat u denkt

RFC 5280 paragraaf 4.2.1.9 definieert de basisbeperkingen, en het padlengteveld beperkt hoeveel niet-zelfuitgegeven tussenliggende certificaten in een geldig pad mogen volgen. Een waarde van nul beperkt de verdere tussenliggende diepte; het beperkt niet het aantal eindentiteitscertificaten. Mensen lezen het als nul toegestane certificaten en vragen zich dan af waarom uitgifte nog werkt. Lees het veld als een dieptebeperking voor CA's, en het gedrag wordt voorspelbaar.

Dezelfde paragraaf impliceert dat een vertrouwensanker een invoer is voor padvalidatie in plaats van een gewoon certificaat in het pad. Daarom verwijdert het publiceren van een intrekkingsitem voor een zelfondertekende root die niet betrouwbaar uit elke opslag.

Uitdiensttreding is geen sleutelcompromis

Waar de vertrekkende niets anders had dan een persoonlijk beheeraccount, trek die toegang en de sessies in via het ondersteunde identiteitsproces en beoordeel daarna de activiteit en goedkeuringen die het heeft opgeleverd. Eerder uitgegeven cliëntcertificaten worden niet ongeldig omdat hun goedkeurder vertrok, en ze als gecompromitteerd behandelen veroorzaakt een grote, onnodige herregistratie. Een account uitschakelen kan een gekopieerde ondertekeningssleutel ook niet ongeldig maken, dus het antwoord hangt af van welke bevoegdheid werd gehouden.

Wanneer een tussenliggend certificaat wordt gecompromitteerd, moet de autorisatie ervan worden ingetrokken en elke identiteit waarvoor het instond worden vervangen, volgens het beleid dat de verifieerder handhaaft. Rootvertrouwen vereist een eigen antwoord, omdat het anker in vertrouwensopslag leeft die u mogelijk niet beheert.

Accepteer het ontwerp met vier concrete gevallen: een geschikt apparaat registreert zich, een niet-goedgekeurd verzoek wordt geweigerd, een verwijderde operator kan niet meer uitgeven, en een uitgetreden uitgever verleent geen toegang meer. Die vier resultaten zijn het runbook.