Een gedetailleerde handleiding voor het bouwen van uw eigen PKI

Introductie

Met de steeds veranderende en uitbreidende infrastructuur van ondernemingen is het van groot belang geworden dat elke organisatie over een eigen robuuste en volwassen infrastructuur beschikt. Publieke Sleutel Infrastructuur (PKI) die vertrouwen kunnen creëren tussen hun systemen, applicaties, gebruikers en apparaten op niet-vertrouwde netwerken. De adoptie van private cloud, public cloud, DevOps, microservices en de toevoeging van IoT en netwerkverbonden apparaten biedt een breed scala aan beschermingsgebieden. Een Public Key Infrastructure (PKI) biedt niet alleen vertrouwde identiteiten aan gebruikers en apparaten, maar biedt ook een veilig kanaal om communicatie tijdens de overdracht te beschermen.

Tegenwoordig zijn de meeste PKI-configuraties in organisaties tientallen jaren oud en moeten ze worden vernieuwd en geüpgraded om aan te sluiten bij het veranderende IT-landschap. De grootste behoefte voor de meeste organisaties is een uiterst veilige en robuuste PKI-configuratie die kan uitgeven en beheren. digitale certificaten snel via zelfvoorzienende systemen. Een interne PKI-opstelling door de organisatie moet zowel on-premises als cloudsystemen ondersteunen om te voldoen aan de DevOps-vereisten. Maar hoe werkt een PKI?

Wat is een PKI en hoe werkt een PKI?

Een PKI is een systeem dat digitale certificaten verstrekt aan eindgebruikers, systemen, apparaten en applicaties om hen een vertrouwde identiteit te geven. Deze identiteiten worden gebruikt voor de authenticatie van de certificaathouder en voor het tot stand brengen van beveiligde communicatie met andere certificaathouders binnen het netwerk. Een PKI-infrastructuur is gebaseerd op asymmetrische sleutels. geheimschrift gebruikmakend van een openbare sleutel en een privésleutelpaar dat gekoppeld is aan een digitaal certificaat uitgegeven door een uitgevende instantie Certificate Authority (CA)Deze certificeringsinstantie creëert vertrouwen tussen twee certificaathouders met behulp van deze digitale certificaten. Naast het verstrekken van hun identiteit aan de certificaathouders, bieden deze certificaten ook toegangsrechten en stellen ze de certificaathouder in staat een beveiligd communicatiekanaal tussen twee certificaathouders tot stand te brengen.

Componenten van PKI

1. Root-CA:De Root CA is het belangrijkste onderdeel van een PKI-infrastructuurDe root-CA geeft certificaten uit en stelt de vertrouwensbasis vast tussen identiteiten waaraan een digitaal certificaat wordt uitgegeven. De root-CA geeft ook certificaten uit aan uitgevende CA's, waardoor deze de bevoegdheid krijgen om certificaten uit te geven voor de Rot-CA, aangezien deze normaal gesproken offline blijft.
2. Intermediaire CAEen intermediaire CA, ook wel een ondergeschikte CA genoemd, is een certificeringsinstantie (CA) die tussen de uitgevende CA staat, die namens de root-CA certificaten uitgeeft. Root-CA's kunnen meerdere intermediaire CA's onder zich hebben in de PKI-hiërarchie, maar elke intermediaire CA kan slechts één root-CA hebben. De intermediaire CA wordt normaal gesproken alleen gebruikt in een drielaagse PKI-architectuur.
3. Uitgevende CADe uitgevende CA geeft certificaten uit aan eindgebruikers, apparaten en andere certificaataanvragers. Uitgevende CA's fungeren als online root-CA's en geven certificaten uit aan gebruikers die ze nodig hebben. Uitgevende CA's worden gebruikt in zowel twee- als drielaagse CA's.
4. public Key: Een cryptografische sleutel die wordt gecreëerd door een asymmetrisch sleutelalgoritme, zoals RSA, en die samen met een digitaal certificaat aan het publiek kan worden uitgegeven. Een openbare sleutel hoeft niet veilig te worden bewaard en wordt gebruikt voor openbare distributie. De openbare sleutel is de helft van het asymmetrische sleutelpaar dat is gemaakt met een asymmetrisch sleutelalgoritme.
5. private Key: Een cryptografische sleutel die de andere helft vormt van een asymmetrisch sleutelpaar. De privésleutel is het belangrijkste onderdeel van authenticatie en moet veilig worden bewaard.
6. Certificaat opslaan: Een certificaatopslag wordt gebruikt om rootcertificaten op te slaan die zijn uitgegeven door meerdere certificeringsinstanties (CA's). Certificaatopslag bevat ook rootcertificaten van intermediaire CA's en eindgebruikerscertificaten. De certificaatopslag vertelt een computer welke CA's vertrouwde CA's zijn.
7. Certificaatintrekkingslijst (CRL)Een CRL is een lijst met informatie over ingetrokken certificaten, inclusief de certificaatgegevens en de reden voor de intrekking. CRL's worden met bepaalde tijdsintervallen gepubliceerd, wat mogelijk problemen kan veroorzaken met certificaten die tussen de publicatiemomenten van de CRL's worden ingetrokken.
8. Delta CRL'sDelta-CRL's zijn CRL's die worden gepubliceerd in het tijdsinterval tussen de publicatie van CRL's. Dit dekt de mogelijkheid dat een certificaat dat is ingetrokken vóór de publicatie van de volgende CRL, over het hoofd wordt gezien.
9. HSM (Hardware Beveiligingsmodule): An HSM is een zeer belangrijk onderdeel van een veilige PKI-configuratie en wordt aanbevolen voor het opslaan van de privésleutel van de root-CA. HSM's kunnen ook worden gebruikt voor het opslaan van de privésleutels van intermediaire certificeringsinstanties (ICA's). HSM's zijn extreem veilig, met beveiligingsmechanismen die fraude en manipulatie tegengaan.
10. Certificaatbeheer: Certificaatbeheer is een belangrijk aspect van een PKI-infrastructuur, omdat het helpt bij het up-to-date en veilig houden van certificaten. Hieronder volgen de verschillende fasen van de certificaatlevenscyclus die worden gebruikt voor certificaatbeheer.
    1. Certificaatinschrijving: Deze fase heeft betrekking op de initiële aanmaak van een certificaat voor de certificaataanvrager. Een online gebruiker, organisatie of apparaat verzendt een Certificate Signing Request (CSM), of CSR, naar de certificeringsinstantie. De CSR bevat de openbare sleutel van de aanvrager en andere informatie over de aanvrager. De certificeringsinstantie verifieert vervolgens de verstrekte informatie en, indien deze legitiem is, maakt het certificaat aan en schrijft de gebruiker in bij de PKI. De certificeringsinstantie die het certificaat aanmaakt, kan eigendom zijn van de organisatie die het certificaat wenst, of van een derde partij. Als het certificaat van een derde partij is verkregen, moet het bij hen worden gekocht.
    2. Uitgifte van certificaten: Zodra het certificaat is aangemaakt en de gebruiker is ingeschreven in de PKI, wordt het certificaat aan de gebruiker uitgegeven. Zoals eerder vermeld, gebruikt de gebruiker dit certificaat nu om zich binnen het netwerk te identificeren. Dit zorgt ervoor dat elk lid van de PKI de certificaathouder vertrouwt.
    3. Geldigheid van het certificaat: Certificaatgeldigheid houdt in dat de geldigheid van het certificaat wordt gecontroleerd bij interactie met een ander lid van het netwerk. Dit certificaat wordt geverifieerd door de vertrouwensketen van het certificaat te volgen. Deze vertrouwensketen, of certificeringspad, toont het certificaat van de uitgevende CA die het te verifiëren certificaat heeft uitgegeven. Vervolgens wordt het certificeringspad van het certificaat van de uitgevende CA gecontroleerd, tot aan het certificaat van de root-CA. Zodra de vertrouwensketen tot aan de root-CA is geverifieerd, wordt het oorspronkelijk geverifieerde certificaat als geldig beschouwd.
    4. Certificaat intrekken: Deze stap vindt alleen plaats als het certificaat verloopt en niet langer nodig is, als het certificaat wordt gestolen en misbruikt, of als het certificaat in het algemeen niet langer nodig is. Als een van deze situaties zich voordoet, wordt het certificaat ingetrokken en kan het niet langer worden gebruikt. Het ingetrokken certificaat wordt vervolgens toegevoegd aan de CRL.
    5. Certificaat vernieuwing: Wanneer een certificaat verloopt, moet het worden verlengd. Dit proces geeft het certificaat opnieuw uit, met hetzelfde sleutelpaar en dezelfde informatie, maar met een nieuwe, bijgewerkte vervaldatum.
11. Certificaatbeleid (CP): Het certificaatbeleid is een document waarin de standaarden van de PKI zijn vastgelegd. Het CP laat gebruikers en PKI-beheerders weten hoe ze een certificaat kunnen aanvragen, wat de naamgevingsstandaarden voor certificaten zijn en meer. Het CPS volgt de standaarden die in het CP zijn vastgelegd.
12. Certificaatpraktijkverklaring (CPS): De Certificate Practice Statement beschrijft de procedures die in de PKI worden gebruikt. Deze procedures zijn gebaseerd op de standaarden van het certificaatbeleid. De CP informeert een gebruiker of beheerder wat te doen, terwijl de CPS hen vertelt hoe om het te doen.

Certificaatdetails

Een digitaal certificaat bevat de volgende informatie om de identiteit van de certificaathouder te bewijzen:

• Gegevens van de certificaatuitgever: De gegevens van de uitgever bevatten de naam van de uitgevende certificeringsinstantie (CA). Deze wordt weergegeven op het tabblad Algemeen onder het veld 'Uitgegeven door' en op het tabblad Details onder het veld 'Uitgever'. Het veld 'Uitgever' toont niet alleen de naam van de uitgevende certificeringsinstantie (CA), maar ook de algemene naam, de organisatienaam en het land van de uitgever.

  

• Gegevens van de certificaathouder:De gegevens van de certificaathouder in het certificaat omvatten de openbare sleutel van de houder, diens openbare sleutel en de naam van de certificaathouder.
  

• Certificeringspad: Een digitaal certificaat bevat ook het certificeringspad van het certificaat. Dit helpt andere gebruikers, applicaties of apparaten binnen het netwerk om de geldigheid van het certificaat te verifiëren.

  

• Publieke sleutelZoals vermeld, wordt de openbare sleutel van de certificaathouder in het certificaat opgeslagen. Dit, samen met hun eigen privésleutel, verifieert of de sleutelhouder overeenkomt met de openbare sleutel in het certificaat.

  

• Sleutelgebruik en uitgebreid sleutelgebruik: Het veld "Sleutelgebruik" vertelt de lezer waarvoor de sleutel wordt gebruikt. Het is ook mogelijk dat het certificaat een veld "Uitgebreid sleutelgebruik" heeft, dat andere toepassingen van de sleutel beschrijft die niet in het veld "Sleutelgebruik" zijn opgenomen.

  

• Digitale handtekening van de uitgever: Een ander belangrijk onderdeel van een digitaal certificaat is de digitale handtekening van de uitgever. Deze helpt bij de verificatie van het certificaat, omdat de lezer zo weet wie het certificaat heeft uitgegeven.

  

Veelvoorkomende toepassingen van digitale certificaten

Het veld 'Sleutelgebruik' biedt veel verschillende toepassingen voor het digitale certificaat. Hieronder volgen enkele van de meest voorkomende toepassingen voor certificaten:

• SSL/TLS-certificaten Om communicatiekanalen te beveiligen – Een van de belangrijkste toepassingen van certificaten is SSL/TLS-communicatie. Dit houdt in dat de communicatie tussen een client en een server of een client en een andere client beveiligd is.
• Digitale handtekeningen voor documenten – Certificaten kunnen ook worden gebruikt als digitale handtekeningen voor documenten. Door een document digitaal te ondertekenen, weet de ontvanger dat de ondertekenaar het document heeft verzonden en dat er geen schadelijke inhoud in het document staat.
• Codeondertekening – Code ondertekening Met certificaten is het erg vergelijkbaar met het ondertekenen van documenten. Wanneer code wordt gecreëerd, ondertekent de codeontwerper de code om te bevestigen dat hij/zij de code heeft gemaakt en dat er geen schadelijke code in verborgen zit.
• Client-serverauthenticatie – Client-serverauthenticatie verifieert de identiteit van zowel de client als de server ten opzichte van de andere partij in de communicatie. De respectievelijke communicatoren controleren het certificeringspad van elkaars certificaat om te verifiëren of hun certificaat geldig is.
• VPN-authenticatie – Net als client-serverauthenticatie controleert VPN-authenticatie de identiteit van elk lid van de verbinding aan de hand van het certificatiepad van hun certificaat.
• E-mail- en gegevensversleuteling – E-mail en gegevens encryptie gebruikt de persoonlijke sleutel van de afzender om gegevens te versleutelen. Zodra de e-mail is ontvangen, kan het bericht worden ontsleuteld, omdat het certificaat openbaar is en de openbare sleutel van de afzender bevat. De ontvanger weet dan dat de afzender is wie hij zegt dat hij is.
• Wifi-authenticatie – Bij wifi-authenticatie wordt ook de identiteit van elk lid van de verbinding geverifieerd aan de hand van het certificeringspad van hun certificaat.

Enterprise PKI-services

Ontvang complete end-to-end consultatieondersteuning voor al uw PKI-vereisten!

Meer informatie

Belangrijke elementen voor het opzetten van uw eigen PKI

• Identificeer uw certificaatvereisten – U moet eerst alle huidige en toekomstige vereisten voor digitale certificaten identificeren. Dit verwijst naar waarvoor uw certificaten binnen uw PKI worden en zullen worden gebruikt. Zie de sectie Veelvoorkomende use cases voor digitale certificaten hierboven voor meer informatie.
• De juiste certificeringsinstantie selecteren – Afhankelijk van uw vereisten moet u het type certificeringsinstantie selecteren dat u wilt instellen. Als u uw PKI doorgaans gebruikt ter ondersteuning van uw bedrijfsvereisten, die meestal gebaseerd zijn op Microsoft-services, is het instellen van een Microsoft-certificeringsinstantie (CA) een goede optie voor uw organisatie. Andere typen CA's zijn Google- en Amazon-CA's.
• Cloud versus on-premises hosting Traditioneel worden alle interne PKI's on-premises opgezet. Applicaties en services migreren echter steeds vaker naar de cloud, waardoor het belangrijk is om cloudvereisten te ondersteunen. In situaties waarin de meeste services en producten zich in de cloud bevinden, is het belangrijk om ervoor te zorgen dat de CA die u instelt cloudgebaseerde vereisten ondersteunt.
• Certificaatbeheer – Het opzetten van een interne PKI-infrastructuur garandeert niet dat uw organisatie aan alle PKI-gerelateerde vereisten kan voldoen en deze kan beheren. Een van de belangrijkste vereisten van een PKI-infrastructuur is het automatiseren van certificaatbeheer. Met name bij DevOps, continuatie en de CI/CD-pipeline is het van groot belang om het provisionen en deprovisioneren van certificaten direct en zonder tussenkomst van de gebruiker te laten verlopen. Dit zorgt ervoor dat alle benodigde certificaatbewerkingen snel worden voltooid en dat menselijke fouten geen invloed hebben.
• Uw root- en CA-privésleutels beveiligen – De privésleutels van de root- en uitgevende CA's moeten met de grootst mogelijke veiligheid worden bewaard, omdat ze de vertrouwensbasis vormen. Het is daarom belangrijk dat deze privésleutels veilig worden opgeslagen in een HSM. De privésleutels van de root- en uitgevende CA's worden doorgaans opgeslagen in de HSM, wat maximale beveiliging biedt en manipulatie of misbruik van deze sleutels voorkomt.
• Creëren van CP (Certificaatbeleid) en CPS (Certificaatbeleidverklaring) – De CP & CPS van de PKI definiëren het beleid voor uw certificeringsinstanties en helpen u bij het ontwerpen van uw PKI-infrastructuur. Deze documenten vormen tevens het kader en de scope van uw certificeringsinstantie en geven aan aan wie certificaten mogen worden uitgegeven, wat de grenzen zijn waarbinnen de certificeringsinstantie werkt en welke procedures worden gebruikt om uw certificeringsinstantie te beheren.
• Certificaatintrekking en CRL-controle – Een andere belangrijke stap bij het creëren van uw PKI is ervoor te zorgen dat certificaten worden ingetrokken wanneer dat nodig is, en dat ze, wanneer ze worden ingetrokken, in de CRL worden geplaatst. Het is ook belangrijk dat uw CA's regelmatig controleren op nieuwe CRL's, zodat ze op de hoogte blijven van de nieuwste ingetrokken certificaten.

Basisarchitecturen

De twee meest voorkomende PKI-architecturen zijn de tweelaagse en drielaagse architectuur. Hieronder vindt u de PKI-componenten waaruit elk type PKI-architectuur bestaat:

Tweelaagse architectuur

Een tweelaagse architectuur is de meest voorkomende vorm van PKI-hiërarchie en tevens de meest evenwichtige architectuur. Het omvat alleen een root-CA en de uitgevende CA's in de PKI. Deze opzet maakt het eenvoudig om een ​​tweelaagse PKI te implementeren, zonder de beveiliging ervan te verliezen. De onderstaande afbeelding toont hoe de configuratie van een tweelaagse PKI eruitziet.




Het ontwerp van een tweelaagse PKI-architectuur is gericht op veiligheid en eenvoud, waardoor de root of trust, de root-CA, offline blijft en zo beschermd is tegen aanvallen. Omdat de root-CA niet gecompromitteerd kan worden, hoeft u zich geen zorgen te maken dat certificaten worden misbruikt of aan niet-vertrouwde gebruikers worden verstrekt. In plaats van dat de root-CA certificaten uitgeeft, creëert de root-CA de certificaten voor de oorspronkelijke uitgevende CA's en stelt deze in staat om certificaten uit te geven aan eindgebruikers. Tweelaagse PKI-architecturen zijn de meest gebruikte hiërarchie.

Drielaagse architectuur



De drielaagse architectuur is het veiligst, omdat er meer schakels in de keten zijn die door aanvallers gecompromitteerd moeten worden. Het opzetten van een drielaagse architectuur is echter een veel ingewikkelder proces dan het opzetten van een tweelaagse architectuur. Met de toevoeging van intermediaire CA's zijn er veel meer CA's om in te stellen en te integreren binnen de PKI, vooral als er een groot aantal uitgevende en intermediaire CA's moet worden aangemaakt. Hoe meer CA's er nodig zijn in een PKI, hoe ingewikkelder de implementatie en het onderhoud. Een drielaagse architectuur wordt veel minder vaak gebruikt dan een tweelaagse architectuur.

Veelvoorkomende implementatiefouten

• Gebrek aan planning en tracking: Een van de meest voorkomende fouten bij een PKI is het gebrek aan planning en tracking. Slechte planning in een PKI kan een PKI ernstige schade toebrengen, omdat er beveiligingslekken kunnen zijn die een aanvaller kan misbruiken. Slechte planning kan ook leiden tot slecht certificaat- en sleutelbeheer, wat een extra mogelijkheid biedt voor aanvallers om te misbruiken. Naast planning kan slechte tracking van PKI-assets ook problemen veroorzaken. Om deze problemen op te lossen, moet u ervoor zorgen dat PKI-professionals een goede planning uitvoeren om de beste PKI-kwaliteit te garanderen. Het gebruik van SIEM-tools kan ook helpen bij het volgen van de verschillende componenten van uw PKI, waardoor u meer inzicht krijgt in de interne werking ervan.
• Root CA-beveiliging: Als root of trust is de root-CA van cruciaal belang voor de PKI en moet daarom goed beveiligd zijn. Als de root-CA gecompromitteerd zou worden, zou de hele PKI helemaal opnieuw moeten worden opgebouwd, aangezien geen enkel certificaat dat binnen die PKI wordt uitgegeven meer vertrouwd zou zijn. Om dit te verhelpen, kunt u een HSM gebruiken om de sleutels van de root-CA te beveiligen tegen aanvallen van buitenaf.
• Levenscyclusbeheer van slechte certificaten: Een andere veelvoorkomende fout bij de implementatie van PKI is slecht beheer van de levenscyclus van certificaten. Als certificaten worden gecompromitteerd of ongebruikt blijven, kunnen kwaadwillende gebruikers deze gebruiken om gevoelige gegevens te stelen of er toegang toe te krijgen. Bovendien kan het verlopen van het certificaat van een gebruiker of applicatie zonder verlenging leiden tot verlies van de service voor die gebruiker of applicatie. Goede automatisering en monitoring van de levenscyclus van certificaten kan deze fout voorkomen.

PKI als een service

Een vorm van PKI die steeds vaker voorkomt, is PKI as a Service. PKI as a Service werkt als volgt: een provider installeert de PKI, in zijn eigen datacenter of binnen uw organisatie, en verzorgt al het beheer en de updates in de PKI. Hierdoor hoeven organisaties die deze service afnemen geen PKI-professionals op te leiden of in te huren, wat hen geld en mankracht bespaart. Als de PKI in het datacenter van de provider wordt geïnstalleerd, zal de organisatie die hun diensten afneemt hoogstwaarschijnlijk de PKI certificaten laten uitgeven aan hun gebruikers, zonder dat ze een eigen uitgevende instantie (CA) nodig hebben. PKI as a Service is een van de vele diensten die Encryption Consulting aanbiedt. Wij assisteren uw organisatie bij het ontwerp, de implementatie en de implementatie van uw PKI. Een deel van onze PKI-configuratie omvat het gebruik van een on-premises Thales-SafeNet, nCipher of Utimaco HSM. We kunnen deze implementeren in ons datacenter in Dallas, Texas, of op uw locatie. Welke hardwarebeveiligingsmodule u ook kiest, ze voldoen allemaal aan FIPS 140-2 Level 2 en 3, zodat u aan al uw compliance-eisen voldoet. Naast een HSM helpen we u ook bij het bouwen en ontwerpen van een back-up voor uw PKI, voor minimaal tot geen verlies van service door onvoorziene omstandigheden. We kunnen ook verschillende SIEM-tools in uw PKI implementeren, zodat u certificaten en sleutels kunt monitoren en op de hoogte kunt blijven van ingetrokken certificaten, ongebruikte sleutels, enz. Onze PKI as a Service kan zowel on-premises als in de cloud worden geïnstalleerd.