SSH-sleutels versus SSH-certificaten: wat het verschil nu eigenlijk betekent

Zowel SSH-sleutels als SSH-certificaten authenticeren gebruikers en systemen met behulp van publieke-sleutelcryptografie , maar ze zijn gebaseerd op fundamenteel verschillende vertrouwensmodellen. SSH-sleutels creëren vertrouwen door geautoriseerde publieke sleutels in het authorized_keys-bestand van elke server te plaatsen; SSH-certificaten gebruiken een vertrouwde certificeringsinstantie (CA) om identiteiten te verifiëren en centraal toegang te verlenen voor een bepaalde tijdsperiode. Dit verschil is van invloed op elke fase van de levenscyclus van de authenticatiegegevens: hoe toegang wordt verleend, beheerd, gecontroleerd en ingetrokken, met name naarmate omgevingen groeien. De aanbevolen aanpak: beheer SSH-sleutels met een gecentraliseerde inventaris, rotatie en intrekking voor omgevingen waar sleutels praktisch zijn; evalueer authenticatie op basis van certificaten voor omgevingen waar de sleutelinventaris te groot is geworden voor handmatig beheer.

Kort antwoord: SSH-sleutels versus SSH-certificaten

SSH-sleutels: elke server vertrouwt onafhankelijk de openbare sleutels die in het authorized_keys-bestand staan ​​vermeld. Geen vervaldatum. Geen centraal register. Toegang blijft behouden totdat deze handmatig van elke server wordt verwijderd. SSH-certificaten: de server vertrouwt een certificeringsinstantie (CA); de CA garandeert de identiteit door certificaten te ondertekenen met geldigheidsperioden, principalnamen en optionele beperkingen. Toegang vervalt automatisch wanneer de geldigheidsperiode afloopt. Het verschil tussen de twee zit hem niet in de cryptografische sterkte, maar in wat er met de toegang gebeurt naarmate teams, systemen en referenties zich ophopen. Zie SSH Key Management Compliance voor een volledig overzicht van de naleving van SSH-sleutelbeheer. Zie Designing an Effective SSH Key Rotation Policy voor het rotatiekader.

Het accumulatieprobleem: waarom het verschil ertoe doet

De operationele impact van deze verschillende vertrouwensmodellen wordt duidelijk naarmate omgevingen groeien. Het probleem ontstaat niet als een eenmalige gebeurtenis, maar stapelt zich op. Een engineer komt in dienst en zijn sleutel wordt aan een dozijn servers toegevoegd. Een contractor rondt zijn opdracht af en zijn sleutel wordt niet verwijderd omdat niemand bijhield op welke servers deze zich bevond. Automatiseringsprocessen genereren sleutelparen die langer meegaan dan de processen waarvoor ze zijn ontworpen. Drie jaar later liggen er honderden sleutels verspreid over de serverinfrastructuur, zonder betrouwbaar overzicht van wie de eigenaar is.

Uit brancheonderzoek bleek dat 57% van de organisaties het beheren van SSH-sleutels als lastig en moeilijk beschouwde. Hoewel het bewustzijn hierover is toegenomen, blijft het onderliggende operationele risico van onbeheerde sleutels bestaan, ongeacht hoe goed het probleem wordt herkend. Wat het lastig maakt om dit vroegtijdig te ontdekken, is dat er ogenschijnlijk niets misgaat. Servers reageren, pipelines draaien, implementaties worden voltooid. Het toegangsprobleem is onzichtbaar totdat het zich manifesteert als een beveiligings- of compliance-incident.

Hier wordt het onderscheid tussen SSH-sleutels en SSH-certificaten belangrijk. Beide bieden sterke authenticatie, maar hun vertrouwensmodellen bepalen hoe dat vertrouwen in de loop der tijd wordt gehandhaafd, uitgebreid en ingetrokken. Inzicht in de structurele verschillen stelt organisaties in staat het juiste model te kiezen voor hun omgeving en de volwassenheid van hun governance.

Wat zijn SSH-sleutels?

Een SSH- sleutel is een cryptografisch gekoppeld paar: een privésleutel en een publieke sleutel, die samen als een bijpassende set worden gegenereerd. Ze dienen één enkel doel: identiteit bewijzen zonder een wachtwoord over het netwerk te versturen.

De privésleutel blijft op de computer waarop deze is aangemaakt. Deze mag nooit worden gekopieerd, gedeeld of overgedragen. Het is het enige bestand dat een authenticatieverzoek van de server kan voltooien, en de beveiliging ervan vormt de basis van het vertrouwen.

De publieke sleutel wordt verspreid naar servers waar toegang nodig is. Op elke server wordt deze opgeslagen in het bestand authorized_keys (meestal ~/.ssh/authorized_keys voor het betreffende gebruikersaccount). Dit bestand is een lijst: één publieke sleutel per regel, die elk een entiteit vertegenwoordigt die de server moet authenticeren.

De beveiliging is gebaseerd op asymmetrische cryptografie : de privésleutel genereert een cryptografische handtekening die alleen door de bijbehorende publieke sleutel kan worden geverifieerd. Kennis van de ene sleutel betekent niet dat de andere kan worden afgeleid; een geldige handtekening kan alleen worden gegenereerd door de houder van de privésleutel.

Hoe SSH-sleutelauthenticatie werkt

De authenticatieprocedure stelt de identiteit vast zonder de privésleutel te verzenden:

1. De publieke sleutel van de gebruiker wordt in het bestand authorized_keys op de doelservver geplaatst (door een beheerder, door de gebruiker als deze servertoegang heeft, of via geautomatiseerde provisioning).
2. De gebruiker initieert een verbinding. SSH De client geeft aan welke publieke sleutel hij wil gebruiken voor authenticatie.
3. De server controleert het authorized_keys-bestand. Als de ingediende publieke sleutel aanwezig is en is toegestaan ​​voor het betreffende gebruikersaccount, gaat de server verder met de authenticatie.
4. De client ondertekent het authenticatieverzoek met zijn privésleutel en stuurt het ondertekende verzoek naar de server. De privésleutel verlaat de client nooit.
5. De server verifieert de handtekening met behulp van de opgeslagen publieke sleutel. Een geldige handtekening bevestigt dat de client de bijbehorende privésleutel bezit. De authenticatie is geslaagd.

Het vertrouwensmodel: de server vertrouwt de SSH-sleutel omdat deze in authorized_keys staat. Dat vertrouwen heeft geen vervaldatum en geen centrale registratie. Het blijft bestaan ​​totdat iemand de sleutel handmatig uit dat bestand verwijdert op elke server waar deze is geïmplementeerd.

De operationele uitdagingen van SSH-sleutelbeheer

Het authenticatieproces zelf is veilig. De uitdagingen ontstaan ​​echter bij de manier waarop vertrouwen op grote schaal wordt opgebouwd en behouden:

• Elke server beheert zijn eigen authorized_keys-bestand. Elke openbare sleutel die toegang nodig heeft, moet afzonderlijk op elke server worden toegevoegd, bijgewerkt of verwijderd.
• SSH-sleutels hebben geen ingebouwde vervaldatum. Een publieke sleutel blijft vertrouwd totdat deze handmatig wordt verwijderd van elke server waarop deze is geïnstalleerd.
• Zonder een gecentraliseerde inventarisOrganisaties worstelen met de vraag wie de eigenaar is van een sleutel, waarom deze is uitgegeven, of deze nog steeds in gebruik is en of deze moet blijven bestaan.
• Sleutels die zijn aangemaakt voor tijdelijke projecten, aannemers of automatiseringsworkflows kunnen lang na het einde van hun doel actief blijven, waardoor het aanvalsoppervlak ongemerkt groter wordt.

Deze beperkingen zijn geen zwakke punten in de SSH-cryptografie. Ze zijn een gevolg van een gedecentraliseerd vertrouwensmodel waarin elke server onafhankelijk beslist welke publieke sleutels te vertrouwen zijn. Naarmate omgevingen schalen, zoeken organisaties naar manieren om vertrouwensbeslissingen te centraliseren, handmatig beheer te verminderen en de transparantie te verbeteren. SSH-certificaten zijn ontworpen om deze operationele uitdagingen aan te pakken. Zie voor gerelateerde richtlijnen over het beheren van SSH-sleutels op grote schaal de artikelen ' Hoe SSH-sleutelbeheer de beveiliging versterkt' en 'SSH-sleutels beveiligen met HSM's'.

Wat zijn SSH-certificaten?

Een SSH-certificaat is een openbare sleutel die is ondertekend door een vertrouwde certificeringsinstantie (CA). De handtekening van de CA koppelt identiteits- en toegangsinformatie aan de sleutel, waardoor een verifieerbare authenticatie met een ingebouwde vervaldatum ontstaat. In tegenstelling tot een losstaande openbare sleutel zonder eigendomsinformatie, bevat een SSH-certificaat de volgende gegevens:

• Sleutel-ID: Een willekeurige tekenreeks die tijdens het ondertekenen wordt toegewezen en die het certificaat identificeert in logboeken en auditverslagen. Organisaties gebruiken gebruikersnamen, e-mailadressen, personeels-ID's of ticketnummers.
• Lijst van schoolhoofden: De identiteiten die het certificaat mag vertegenwoordigen. Voor gebruikerscertificaten komen de principals overeen met gebruikersnamen van het besturingssysteem, zoals ubuntu, ec2-user of admin.
• Geldigheidsperiode: Een geldigheidsperiode voor en na (Unix-tijdstempels) wordt tijdens de authenticatie afgedwongen. Als de huidige tijd buiten dit tijdsvenster valt, wordt het certificaat automatisch geweigerd.
• extensions: mogelijkheden zoals permit-pty (terminaltoegang), permit-port-forwarding of permit-agent-forwarding.
• Kritieke opties: Afgedwongen beperkingen, zoals het beperken van het certificaat tot specifieke bron-IP-adressen of het beperken van de sessie tot één enkele opdracht.
• CA-handtekening: De cryptografische handtekening van de certificeringsinstantie (CA) over al het bovenstaande voorkomt manipulatie zonder het certificaat ongeldig te maken.

Het SSH-certificaatformaat dat door OpenSSH wordt gebruikt, is niet hetzelfde als het X.509- formaat dat voor HTTPS wordt gebruikt. Het is een speciaal ontwikkeld formaat dat is gedefinieerd in de OpenSSH PROTOCOL.certkeys-specificatie. De certificeringsinstantie (CA) zelf is simpelweg een SSH-sleutelpaar op een beveiligde locatie: de privésleutel ervan ondertekent gebruikers- en hostcertificaten; de publieke sleutel ervan wordt eenmaal aan elke server verstrekt. Vanaf dat moment kan elke server die is geconfigureerd om de CA te vertrouwen, certificaten authenticeren die door die CA zijn ondertekend.

Hoe SSH-certificaatverificatie werkt

De authenticatieprocedure verschilt van authenticatie op basis van sleutels in de manier waarop vertrouwen wordt gevestigd. In plaats van te controleren of de verbindingssleutel op die specifieke server is geregistreerd, controleert de server of het certificaat is ondertekend door een certificeringsinstantie (CA) die de server vertrouwt.

1. Er wordt een CA-sleutelpaar gegenereerd en de bijbehorende publieke sleutel wordt eenmalig naar elke server gedistribueerd met behulp van de TrustedUserCAKeys-richtlijn in sshd_config. Dit is een eenmalige configuratiestap per server; er zijn geen wijzigingen nodig wanneer gebruikers worden toegevoegd of verwijderd.
2. Wanneer een gebruiker toegang nodig heeft, wordt zijn of haar publieke sleutel ter ondertekening naar de certificeringsinstantie (CA) gestuurd. De CA ondertekent deze met zijn of haar privésleutel en stuurt een certificaat terug met de sleutel van de gebruiker, diens identiteit, de rollen waarvoor hij of zij gemachtigd is en de geldigheidsperiode. De privésleutel van de gebruiker blijft ongewijzigd.
3. De gebruiker initieert een verbinding. De SSH-client presenteert het certificaat van de gebruiker en bewijst het bezit van de privésleutel door het authenticatieverzoek te ondertekenen.
4. De server verifieert de CA-handtekening op het certificaat met behulp van de openbare CA-sleutel die hij al in zijn bezit heeft uit stap 1.
5. De server controleert of het certificaattype geschikt is voor gebruikersauthenticatie.
6. De server controleert of de huidige tijd binnen het geldigheidsvenster (valid-after en valid-before) valt.
7. De server controleert of ten minste één principal in het certificaat overeenkomt met het beoogde gebruikersaccount.
8. Als alle controles slagen, verifieert de server de handtekening van de client. Een geldige handtekening bevestigt dat de client de bijbehorende privésleutel bezit. Toegang wordt verleend.
9. Wanneer de geldigheidsperiode is verlopen, werkt het certificaat automatisch niet meer. De gebruiker moet een nieuw, door de certificeringsinstantie (CA) ondertekend certificaat verkrijgen om opnieuw toegang te krijgen. De privésleutel verlaat de client nooit.

Het structurele verschil met authenticatie op basis van sleutels: de server heeft geen vooraf bestaande gegevens van de gebruiker nodig. Het vertrouwen komt van de certificeringsinstantie (CA), niet van een bestand op elke individuele server.

SSH-sleutels versus SSH-certificaten: een directe vergelijking

Afmeting	SSH-sleutels	SSH-certificaten
Vertrouwensmodel	Elke server vertrouwt rechtstreeks op de individuele publieke sleutels die in het authorized_keys-bestand staan ​​vermeld.	Elke server is geconfigureerd om één of meer certificeringsinstanties (CA's) te vertrouwen en accepteert certificaten die door die CA's zijn ondertekend.
Referentieformaat	Op zichzelf staande openbare sleutel	Openbare sleutel met ondertekende metadata en CA-handtekening
Identiteitsgegevens	Optioneel opmerkingenveld; wordt niet gecontroleerd tijdens authenticatie.	De ondertekende sleutel-ID en principals zijn in het certificaat opgenomen en worden tijdens de authenticatie geverifieerd.
Afloop	Geen ingebouwde vervaldatum; de toegang blijft geldig totdat de sleutel handmatig van elke server wordt verwijderd.	De ingebouwde geldigheidsperiode wordt tijdens de authenticatie afgedwongen; het certificaat wordt automatisch geweigerd wanneer het venster wordt gesloten.
Toegangsvoorziening	Openbare sleutels moeten worden verspreid naar elke server waar toegang vereist is.	Servers vertrouwen de CA; gebruikers ontvangen certificaten uitgegeven door de CA; er zijn geen wijzigingen per server nodig wanneer gebruikers worden toegevoegd.
Toegang verwijderen	Openbare sleutels moeten van elke server worden verwijderd waar ze worden vertrouwd; het is gemakkelijk om servers over het hoofd te zien.	Verleng het certificaat niet; de toegang verloopt automatisch. Vroegtijdige intrekking via een Key Revocation List (KRL) is mogelijk, maar vereist dat de KRL naar alle servers wordt verzonden.
Rotatie	Vereist het genereren van een nieuw sleutelpaar, het distribueren van de nieuwe publieke sleutel en het verwijderen van de oude sleutel van alle servers.	Geef een nieuw certificaat uit; het onderliggende sleutelpaar kan opnieuw worden gebruikt als het organisatiebeleid dit toestaat.
serverbeheer	Vereist het bijhouden van authorized_keys-vermeldingen op alle servers voor alle gebruikers.	Vereist dat de CA-vertrouwensconfiguratie eenmaal per server wordt bijgehouden en dat de certificaatuitgifte wordt beheerd.
controleerbaarheid	Logboeken tonen belangrijke vingerafdrukken; eigendomsregistratie vereist externe gegevens; moeilijk toe te schrijven aan individuen wanneer sleutels worden gedeeld.	Certificaten bevatten ondertekende identiteitskenmerken, sleutel-ID's en serienummers die de traceerbaarheid direct in authenticatielogboeken verbeteren.
Schaalbaarheid	De beheerinspanning neemt lineair toe met het aantal gebruikers, sleutels en servers.	De focus van het beheer verschuift naar gecentraliseerde certificaatuitgifte en CA-governance; het toevoegen van gebruikers vereist geen wijzigingen per server.
Infrastructuurvereisten	Geen CA-infrastructuur vereist	Vereist een CA-sleutelpaar, een certificaatuitgifteproces en de distributie van CA-vertrouwen naar alle servers.
Nalevingshouding	Vereist actief voorraadbeheer, rotatiebeheer en intrekkingsbeheer om te voldoen aan de toegangscontrolekaders.	Ingebouwde vervaldatumregistratie en gecentraliseerde uitgiftegegevens leveren vanzelfsprekend bewijs van naleving; kortstondige certificaten verminderen de administratieve last van handmatige intrekking.
Typisch gebruiksvoorbeeld	Kleine tot middelgrote omgevingen, statische toegangsrelaties, eenvoudige implementaties met actief sleutelbeheer.	Grootschalige omgevingen, dynamisch toegangsbeheer, gecentraliseerd identiteitsbeheer of organisaties waar de SSH-sleutelvoorraad de handmatige beheercapaciteit overstijgt.

Levenscyclusbeheer: SSH-sleutels versus SSH-certificaten

Levenscyclusfase	SSH-sleutels: wie is verantwoordelijk?	SSH-certificaten: wie is verantwoordelijk?
Generatie	Gebruikers- of automatiseringssysteem; vereist handhaving van beleid met betrekking tot algoritme en sleutellengte.	De gebruiker stuurt de publieke sleutel naar de certificeringsinstantie (CA); de CA ondertekent het certificaat en stuurt het terug; het algoritme en de geldigheid worden afgedwongen door het beleid van de CA.
Distributie	De beheerder of een geautomatiseerd hulpmiddel plaatst de publieke sleutel in het authorized_keys-bestand van elke geautoriseerde server.	De gebruiker ontvangt een certificaat; de servers hoeven niet te worden aangepast; de openbare sleutel van de certificeringsinstantie is reeds verspreid.
Monitoren	Sessielogboeken tonen belangrijke vingerafdrukken; eigendomsmapping vereist externe inventarisatie.	Certificaatsleutel-ID en serienummer verschijnen in de logboeken; de identiteit kan direct uit het logboek worden afgeleid.
Rotatie	Nieuw sleutelpaar gegenereerd; nieuwe publieke sleutel geïmplementeerd op alle servers; oude sleutel verwijderd van alle servers.	Nieuw certificaat uitgegeven; het vorige certificaat verloopt automatisch; geen wijzigingen in authorized_keys per server nodig.
Intrekking bij vertrek	De publieke sleutel moet worden geïdentificeerd en van alle servers worden verwijderd; de kloof tussen vertrek en voltooiing vormt een compliance-risico.	Stop met het uitgeven van certificaten aan de vertrokken gebruiker; bestaand certificaat verloopt binnen de geldigheidsperiode; KRL-vermelding voor onmiddellijke vervroegde intrekking.
Controlebewijs	Gegenereerd op basis van sessielogboeken en externe sleutelinventaris; correlatie is vereist.	Het CA-uitgiftelogboek biedt directe toewijzing; het geldigheidsvenster biedt automatisch bewijs van toegang binnen een bepaalde tijdsperiode.

Wat moet je gebruiken: SSH-sleutels of SSH-certificaten?

Geen van beide benaderingen is universeel superieur. De juiste keuze hangt af van de schaal van de omgeving, de volwassenheid van het bestuur en de operationele capaciteit:

• SSH-sleutels zijn praktisch en veilig. In kleine tot middelgrote omgevingen waar de sleutelvoorraad bekend is, de eigenaren gedocumenteerd zijn, de sleutelrotatie volgens schema wordt afgedwongen en de sleutel direct bij vertrek wordt ingetrokken, zijn de governancevereisten voor SSH-sleutels beheersbaar op deze schaal, mits ondersteund door een SSH-sleutelbeheerplatform.
• SSH-certificaten worden voordelig Wanneer: de organisatie niet op verzoek een actuele inventaris van alle SSH-sleutels kan leveren; het beheren van authorized_keys-bestanden op honderden servers inconsistentie veroorzaakt; de tijd tussen het vertrek van een medewerker en de volledige intrekking van de SSH-sleutel langer is dan acceptabel; compliance-audits bevindingen opleveren over achtergebleven of niet-geroteerde sleutels; of de omgeving sneller groeit dan handmatig sleutelbeheer kan bijhouden.
• De overgang kan stapsgewijs plaatsvinden: Servers kunnen tijdens de migratie tegelijkertijd vertrouwen op zowel traditionele publieke sleutels als de certificeringsinstantie (CA). Dit betekent dat bestaande sleutels functioneel blijven terwijl authenticatie op basis van certificaten wordt uitgerold, waardoor een geleidelijke migratie met een laag risico mogelijk is.

Voor organisaties die overstappen op certificaten of tijdelijke toegangsmodellen, raadpleegt u 'Statische SSH-sleutels omzetten in kortstondige workload-identiteiten' voor het migratiekader en de SPIFFE/SPIRE-workload-identiteitsaanpak voor serviceaccounts.

Rotatie- en intrekkingstriggers

• Vertrek van een medewerker of functieverandering: Voor SSH-sleutels: verwijder de publieke sleutel onmiddellijk van alle servers; voor SSH-certificaten: stop met het uitgeven van certificaten en voeg een KRL-vermelding toe voor onmiddellijke vervroegde intrekking van elk geldig certificaat.
• Vermoedelijke of bevestigde inbreuk: Voor SSH-sleutels geldt: trek ze in op alle servers en genereer een vervangend exemplaar; voor SSH-certificaten geldt: voeg een KRL-vermelding toe en laat ze opnieuw uitgeven door de certificeringsinstantie.
• Algoritme wordt afgeschaft: Alle sleutels of certificaten die gebruikmaken van verouderde algoritmen (DSA, RSA-1024) moeten worden vervangen. Zie voor een vergelijking van de algoritmen de betreffende documentatie. SSH-sleutels vergelijken: RSA, DSA, ECDSA of EdDSA.
• Systeemontmanteling: Verwijder alle SSH-sleutelautorisaties voor systemen die buiten gebruik zijn gesteld; werk voor certificaatimplementaties het AuthorizedPrincipalsFile bij op de resterende systemen.
• Compromittering van de privésleutel van de CA: Bij de implementatie van certificaten is dit de meest kritieke gebeurtenis: de openbare sleutel van de certificeringsinstantie (CA) moet op elke server worden vervangen en alle eerder uitgegeven certificaten worden onbetrouwbaar. Bescherm de privésleutels van de CA in HSM's om dit scenario te voorkomen.

Incidentrespons: Compromittering van SSH-sleutel versus SSH-certificaat

• Gecompromitteerde SSH-sleutel: Identificeer alle servers met de publieke sleutel in authorized_keys (vereist inventarisatie); verwijder de publieke sleutel van elke server; genereer een nieuw sleutelpaar; distribueer de nieuwe publieke sleutel naar de geautoriseerde servers; controleer of de authenticatie met de nieuwe sleutel werkt; registreer alle acties met tijdstempels als bewijs van naleving.
• Gecompromitteerd SSH-certificaat: Voeg het serienummer van het certificaat toe aan de KRL; distribueer de bijgewerkte KRL onmiddellijk naar alle servers; het certificaat wordt geweigerd bij de volgende verbindingspoging; geef een nieuw certificaat uit nadat de fout bij de verwerking van de inloggegevens is opgelost; als de onderliggende privésleutel is gecompromitteerd, roteer dan ook het sleutelpaar.
• Gecompromitteerde privésleutel van de certificeringsinstantie (certificaatimplementaties): Een nieuw CA-sleutelpaar genereren; de nieuwe openbare CA-sleutel distribueren naar alle servers (ter vervanging van de oude TrustedUserCAKeys-vermelding); certificaten opnieuw uitgeven voor alle gebruikers vanuit de nieuwe CA; de oude openbare CA-sleutel kan van de servers worden verwijderd zodra alle gebruikers zijn gemigreerd naar de nieuwe CA. Dit is de meest ernstige gebeurtenis; bescherm de privésleutels van de CA in HSM's om dit te voorkomen.

Hoe encryptieconsultancy kan helpen

Bij Encryption Consulting begrijpen we de uitdagingen waar bedrijven voor staan ​​bij het beheren van SSH-sleutels op grote schaal. SSH Secure biedt end-to-end beveiliging van de sleutellevenscyclus, gecentraliseerd inzicht en HSM-ondersteunde bescherming voor zowel SSH-sleutel- als certificaatomgevingen.

1. Gecentraliseerde zichtbaarheid en eigendomstoewijzing

Zowel met als zonder agent kan elke SSH-sleutel worden opgespoord op servers en gebruikerscomputers. Alle sleutels worden opgeslagen in een uniforme inventaris met eigendoms- en gebruiksgegevens, waardoor ongebruikte sleutels worden geëlimineerd en volledige verantwoording binnen de omgeving wordt gewaarborgd.

2. Geautomatiseerde sleutellevenscyclusorkestratie

SSH Secure automatiseert de volledige sleutellevenscyclus: veilige generatie, beleidsgestuurde rotatie en intrekking. Tijdelijke, aan sessies gebonden sleutels verlopen automatisch bij gevoelige bewerkingen, waardoor toegang met minimale privileges wordt afgedwongen en wordt gegarandeerd dat sleutels niet langer worden gebruikt dan bedoeld.

3. HSM-geïntegreerde bescherming

Alle privésleutels worden gegenereerd en opgeslagen in HSM's met behulp van RSA-4096, ECDSA en Ed25519. De niet-exporteerbare, fraudebestendige opslag van privésleutels voorkomt extractie, zelfs bij een compromittering van het hostbesturingssysteem.

4. Beleidsgestuurde controle voor belangrijke activiteiten

Alle belangrijke processen worden afgedwongen via op beleid gebaseerde controles, wat zorgt voor consistentie binnen de gehele omgeving, minder handmatige fouten en naleving van wettelijke vereisten of interne governancemodellen.

5. Continue monitoring, audits en paraatheid voor naleving

Realtime monitoring met gedetailleerde gebeurtenisregistratie, integratie met Splunk of Grafana Loki, downloadbare auditlogboeken en compliance-rapporten bieden beveiligingsteams een helder inzicht in belangrijk gebruik en de algehele beveiligingsstatus.

Conclusie

SSH-sleutels en SSH-certificaten lossen hetzelfde authenticatieprobleem op cryptografisch niveau op. Beide bewijzen de identiteit zonder een wachtwoord te verzenden. Het verschil zit niet in de sterkte van de cryptografie, maar in wat er met de toegang gebeurt in de loop van de tijd. Een sleutel die drie jaar geleden op een server is geplaatst door iemand die niet meer bij de organisatie werkt, is vandaag de dag nog net zo geldig als op de dag dat hij werd toegevoegd. De server kan dat niet anders weten. Dat is geen fout in de sleutel, maar een gevolg van een gedecentraliseerd vertrouwensmodel dat is ontworpen voor eenvoud.

De lacune zit hem in het beheer van de gehele levenscyclus van de inloggegevens. Voor organisaties waar de inventaris van SSH-sleutels bekend is, het eigenaarschap is gedocumenteerd en rotatie en intrekking consistent worden afgedwongen, blijven SSH-sleutels een veilige en praktische keuze. Voor organisaties waar de inventaris te groot is geworden voor handmatig beheer, bieden SSH-certificaten structurele voordelen: ingebouwde vervaldatum, gecentraliseerde uitgiftelogboeken en het elimineren van het beheer van geautoriseerde sleutels per server. Het versterken van het beheer van SSH-sleutels door middel van gecentraliseerde ontdekking, eigendomsregistratie, beleidsgestuurde rotatie en tijdige intrekking is de meest directe en praktische stap om bevoorrechte toegang te beveiligen, ongeacht of een migratie naar certificaten gepland is. Zie voor meer informatie SSH Key Management Compliance , Why Never-Expiring SSH Keys Are a Security Risk en Transform Static SSH Keys into Short-Lived Workload Identities.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen SSH-sleutels en SSH-certificaten?

SSH-sleutels creëren vertrouwen door de publieke sleutel van de gebruiker in het authorized_keys-bestand van de server te plaatsen. Dit vertrouwen heeft geen vervaldatum en er is geen centrale registratie; het blijft bestaan ​​totdat de sleutel handmatig van elke server wordt verwijderd. SSH-certificaten gebruiken een vertrouwde certificeringsinstantie (CA) om identiteiten te verifiëren; de server vertrouwt de CA, het certificaat heeft een ingebouwde geldigheidsperiode en de toegang vervalt automatisch wanneer deze periode afloopt.

Wat moet ik gebruiken: SSH-sleutels of SSH-certificaten?

SSH-sleutels zijn praktisch wanneer de inventaris bekend is, het eigenaarschap gedocumenteerd is en er actief beheer is. SSH-certificaten zijn voordelig wanneer de sleutelinventaris te groot is geworden om handmatig bij te houden, intrekking traag verloopt of compliance-audits bevindingen opleveren. De overgang kan stapsgewijs verlopen: servers kunnen tijdens de migratie beide modellen tegelijkertijd vertrouwen.

Verlopen SSH-certificaten automatisch?

Ja. SSH-certificaten hebben een geldigheidsperiode (geldig-na en geldig-voor tijdstempels) die tijdens de authenticatie wordt afgedwongen. Wanneer de huidige tijd buiten deze periode valt, wordt het certificaat geweigerd, ongeacht eerdere vertrouwensrelaties. SSH-sleutels hebben geen ingebouwde vervaldatum; ze blijven vertrouwd totdat ze handmatig uit authorized_keys op elke server worden verwijderd.

Hoe trek je een SSH-certificaat in voordat het verloopt?

Via een Key Revocation List (KRL): de CA-beheerder voegt het serienummer van het certificaat of de sleutelvingerafdruk toe aan de KRL; elke server controleert de KRL via de RevokedKeys sshd_config-richtlijn. Beperking: de KRL moet naar alle servers worden gedistribueerd voordat de intrekking van kracht wordt. Certificaten met een korte geldigheidsduur verminderen dit probleem: een certificaat dat acht uur geldig is, verloopt voordat de meeste intrekkingsverzoeken zich voordoen.

Wat zijn de operationele kosten voor het implementeren van een SSH CA?

Eenmalig: genereer een CA-sleutelpaar; distribueer de openbare CA-sleutel naar alle servers via TrustedUserCAKeys. Bescherm de privésleutel van de CA in een HSM voor omgevingen met hoge betrouwbaarheid. Doorlopend: beheer de uitgifte van certificaten (integreer met identiteitsproviders, stel principals en geldigheidsperioden in); roteer de CA-sleutel volgens een meerjarig schema; beheer KRL's voor vroegtijdige intrekking. In ruil daarvoor: elimineer het beheer van authorized_keys per server voor alle gebruikers die onder certificaten vallen.

Zijn SSH-certificaten hetzelfde als TLS-certificaten?

Nee. SSH-certificaten gebruiken het OpenSSH PROTOCOL.certkeys-formaat (specifiek voor SSH), niet X.509 (gebruikt voor TLS/HTTPS). Beide gebruiken een certificeringsinstantie (CA) die garant staat voor een publieke sleutel, maar de formaten zijn structureel verschillend en niet uitwisselbaar. Een SSH CA is zelf gewoon een SSH-sleutelpaar, geen X.509 CA.