Uitgebreid beheer van de levenscyclus van SSH-sleutels voor bedrijfsbeveiliging

Gepubliceerd: februari 2026. Bijgewerkt: augustus 2026. Beoordeeld door het sleutelbeheerteam van Encryption Consulting.

SSH (Secure Shell) is een cryptografisch netwerkprotocol dat wordt gebruikt voor authenticatie, communicatie en gegevensuitwisseling tussen systemen via een onbetrouwbaar netwerk. Uitgebreid beheer van de levenscyclus van SSH-sleutels voor bedrijfsbeveiliging betekent dat elk sleutelpaar waarop het protocol vertrouwt, zowel door mensen als door geautomatiseerde systemen, moet worden behandeld als een beheerde referentie met een eigenaar, een rotatieschema en een auditlogboek, in plaats van een bestand dat eenmalig wordt aangemaakt en vervolgens wordt vergeten.

Wanneer beheerders en automatiseringssystemen via SSH verbinding maken met servers, vindt authenticatie vrijwel altijd plaats via SSH-sleutels in plaats van wachtwoorden. Deze sleutels bieden sterke, versleutelde toegang en zijn de standaard geworden voor het beheren van Linux-servers, cloudworkloads, CI/CD-pipelines (continuous integration/continuous delivery) en kritieke bedrijfsinfrastructuren. Als u eerst een basiskennis van het protocol nodig hebt voordat u verdergaat, behandelt onze complete SSH-handleiding de basisprincipes; deze handleiding richt zich specifiek op het beheren van de sleutels gedurende hun volledige levenscyclus.

In grote omgevingen hebben SSH- sleutels de neiging zich snel te vermenigvuldigen. Sleutels worden gedeeld tussen gebruikers en systemen, hergebruikt op verschillende servers, gekopieerd zonder dat dit wordt bijgehouden en blijven actief lang nadat ze hun oorspronkelijke doel hebben verloren. In tegenstelling tot certificaten of gebruikersaccounts hebben SSH-sleutels vaak geen vervaldatum, geen duidelijke eigenaar en geen gecentraliseerd beheer. Dit maakt ze tot een vaak over het hoofd gezien, maar significant beveiligingsrisico voor bedrijven.

Deze handleiding behandelt wat SSH-sleutellevenscyclusbeheer precies inhoudt, wie de sleutels in elke fase moet bezitten, wat een sleutelrotatie moet activeren, hoe een toegangsbeleid moet worden ontworpen, welk auditbewijs een volwaardig programma moet opleveren, een praktische implementatieworkflow van ontdekking tot buitenbedrijfstelling, hoe handmatige, PAM-geïntegreerde en dedicated SSH-sleutelbeheerplatforms zich tot elkaar verhouden, en de basisprincipes van reageren wanneer een sleutel wordt blootgesteld.

Wat is SSH-sleutellevenscyclusbeheer?

Het beheer van de levenscyclus van SSH-sleutels omvat het controleren van een SSH-sleutelpaar vanaf het moment dat het wordt gegenereerd tot het moment dat het wordt verwijderd. Dit omvat wie de eigenaar is, waartoe de sleutel toegang heeft, wanneer deze wordt vervangen en hoe het gebruik ervan wordt geregistreerd. Het is nodig omdat een standaard SSH-sleutelpaar, zonder eigenaar, vervaldatum of goedkeuringsregistratie, geen eigenaar of andere beheermogelijkheden heeft. Deze controles moeten daarom worden toegevoegd.

SSH-sleutels worden gebruikt om de identiteit te bewijzen bij het gebruik van SSH. In plaats van telkens een wachtwoord in te typen, maakt SSH meestal gebruik van authenticatie op basis van sleutels. Dit is beter bestand tegen raden en brute-force-aanvallen en is gemakkelijker te automatiseren.

Een SSH-sleutel wordt geleverd als een paar:

• A private key, die bij de gebruiker of applicatie blijft en geheim moet blijven.
• Een publieke sleutel, die in het authorized_keys-bestand van de server wordt geplaatst om toegang te verlenen.

Wanneer een verbinding tot stand komt, controleert de server of de client de privésleutel bezit die overeenkomt met de openbare sleutel die de server vertrouwt. Als de sleutel overeenkomt, wordt toegang verleend. De huidige OpenSSH-versies genereren standaard een Ed25519-sleutel. ssh-keygen wordt uitgevoerd zonder argumenten; waar RSA vereist is voor compatibiliteit, stelt de OpenSSH-handleiding de standaard en minimaal aanbevolen grootte in op 3072 bits, en de CISA-richtlijnen voor het beveiligen van communicatie-infrastructuur bevelen onafhankelijk een minimale RSA-sleutel van 3072 bits aan voor SSH, volgens de ssh-keygen handleidingpagina en CISA's richtlijnen voor verbeterde zichtbaarheid en beveiliging van communicatie-infrastructuurRecente OpenSSH-releases voegen naast Ed25519 en RSA ook post-quantum hybride sleuteltypen toe, een teken dat de keuze van het algoritme, en niet alleen het rotatiebeleid, onderdeel uitmaakt van een actueel SSH-sleutelprogramma.

Het cruciale verschil met certificaatgebaseerde management Een standaard SSH-sleutelpaar verloopt niet vanzelf. Een X.509-certificaat heeft een notAfter Een datum die vernieuwing afdwingt; een onbewerkt SSH-sleutelpaar blijft onbeperkt geldig, tenzij iets buiten het protocol, een beleid, een script of een beheerplatform, het verwijdert. Dat ene feit is de reden waarom er een wildgroei aan SSH-sleutels ontstaat en waarom levenscyclusbeheer een weloverwogen programma moet zijn in plaats van een aanname.

Waarom is levenscyclusbeheer van SSH-sleutels nodig?

SSH-sleutels vereisen lifecyclemanagement omdat ze buiten de identiteitssystemen vallen waarop bedrijven al vertrouwen voor toegangsbeheer. De meeste bedrijven gebruiken IAM-systemen (Identity and Access Management) voor het beheren van gebruikersidentiteiten en PAM-platforms (Privileged Access Management) voor beheerders met een hoog risico. SSH-sleutels bevinden zich tussen deze twee gebieden: ze fungeren als digitale identiteiten voor zowel personen als diensten en verlenen directe systeemtoegang zonder dat deze noodzakelijkerwijs via een van beide controlepunten hoeft te lopen.

Technisch gezien kunnen SSH-sleutels IAM en PAM omzeilen, omdat toegang direct op systeemniveau wordt verleend met behulp van het sleutelpaar, zonder dat er inloggegevens nodig zijn die door een van beide systemen worden beheerd. Zodra een publieke sleutel op een server is geautoriseerd, vertrouwt die server deze onafhankelijk van elke gecentraliseerde identiteits- of toegangsbeheercontrole. Dit is precies de reden waarom niet-geregistreerde sleutels standaard governance kunnen omzeilen en waarom NIST in zijn eigen richtlijnen de beveiliging van op SSH-sleutels gebaseerde toegang beschrijft als een gebied dat "tot nu toe grotendeels is genegeerd" in de meeste organisaties, aldus NIST IR 7966, Security of Interactive and Automated Access Management Using Secure Shell.

In bedrijfsomgevingen zijn automatiseringsplatforms, CI/CD-pipelines en operationele scripts afhankelijk van SSH-sleutels om op grote schaal toegang tussen systemen mogelijk te maken. Dit model biedt snelheid en betrouwbaarheid, maar zorgt er ook voor dat het SSH-gebruik snel groeit en niet meer handmatig te controleren is. Naarmate omgevingen uitbreiden, worden sleutels gekopieerd naar verschillende hosts, hergebruikt door meerdere services en blijven ze aanwezig nadat applicaties veranderen of teams vertrekken. Deze ongecontroleerde groei, vaak zonder duidelijke eigenaar, vervaldatum of centraal inzicht, staat bekend als SSH-sleutelwildgroei.

Onbeheerde SSH-sleutels brengen specifieke, goed gedocumenteerde risico's met zich mee:

• Zijwaartse beweging: Als een sleutel gecompromitteerd raakt, kunnen aanvallers zich ongemerkt tussen systemen bewegen die die sleutel vertrouwen, waardoor ze hun toegang tot het netwerk kunnen uitbreiden.
• Permanente bevoorrechte toegang: Sleutels die lang actief blijven nadat ze niet meer nodig zijn, of nadat de beheerder is vertrokken, bieden voortdurende administratieve toegang die misbruikt kan worden.
• Niet-gedetecteerde serviceaccounts: Geautomatiseerde processen, scripts of applicaties kunnen SSH-sleutels gebruiken zonder duidelijke eigenaar, waardoor verborgen accounts ontstaan ​​die moeilijk te traceren zijn.
• Auditlacunes: Zonder gecentraliseerd inzicht is het moeilijk te controleren wie toegang heeft tot welke systemen, waardoor compliance-audits traag, onvolledig of onbetrouwbaar worden.

Deze risico's kunnen leiden tot datalekken, verstoring van de bedrijfsvoering en juridische of financiële gevolgen. Het aanpakken ervan gaat niet over het beperken van automatisering; het gaat erom SSH-sleutels te behandelen als beheerde toegangsreferenties in plaats van onbeheerde bestanden, zodat dezelfde governanceprincipes die van toepassing zijn op identiteiten en bevoorrechte toegang ook van toepassing zijn op SSH-toegang. Voor een nadere beschouwing van hoe specifieke hiaten in toegangsprocessen ontstaan, zie Het elimineren van hiaten in SSH-toegang.

Wie is de eigenaar van de SSH-sleutels in elke fase van de levenscyclus?

Het eigenaarschap moet worden toegewezen op het moment dat een sleutel wordt verstrekt, en niet later worden gereconstrueerd tijdens een audit of een incident. NIST IR 7966 vereist dat organisaties een eigenaar, een applicatie- of bedrijfsproceseigenaar, toewijzen voor elke sleutel die toegang verleent tot een server. Idealiter wordt dit automatisch gekoppeld aan een configuratiedatabase in plaats van handmatig bijgehouden. In de praktijk is eigenaarschap niet één rol; het verschuift gedurende de levenscyclus en elke fase vereist een benoemde verantwoordelijke partij. Voor een diepere bespreking van eigenaarschapsmodellen, zie SSH Key Ownership.

Levenscyclusfase	Primaire eigenaar	Verantwoordelijkheid
Generatie	Aanvragende engineer of applicatie-eigenaar	Genereer het sleutelpaar met behulp van een goedgekeurd algoritme en een goedgekeurde lengte; bescherm de privésleutel.
Goedkeuring van de miner	Beveiligings- of toegangsbeheerteam	Beoordeel het verzoek aan de hand van het beleid; keur de reikwijdte, de bron en de beperkingen met betrekking tot de opdracht goed.
Provisioning	Beheerder van automatiseringsplatformen of -systemen, onder toezicht van de beveiliging.	Installeer de publieke sleutel met de goedgekeurde beperkingen; registreer de installatiegebeurtenis.
Gebruik	Beveiligingsoperaties (SOC)	Monitor authenticatiegebeurtenissen die aan de sleutel zijn gekoppeld; markeer afwijkend gebruik of gebruik dat niet in overeenstemming is met het beleid.
Rotatie	Sleutelbeheerder, afgedwongen door het beveiligingsteam, uitgevoerd via automatisering	Vervang de sleutel vóór het verstrijken van de cryptoperiode of bij een triggerende gebeurtenis.
Ontmanteling	Applicatie- of service-eigenaar, in samenwerking met het beveiligingsteam	Verwijder de sleutel bij het buitenbedrijf stellen van het systeem, een personeelswijziging of een functiewijziging; bevestig de verwijdering.

De eigenaar is in elke fase verantwoordelijk, maar het is de registratie van wie wat wanneer heeft goedgekeurd die daadwerkelijk standhoudt bij een audit. Dat is de rode draad tussen eigenaarschap, roulatie en de bewijsvereisten die later in deze handleiding aan bod komen.

Wat is de aanleiding voor een SSH-sleutelrotatie?

Een SSH-sleutel moet op basis van drie soorten triggers worden vernieuwd, niet op basis van één vaste kalender: het einde van de gedefinieerde cryptoperiode, een specifieke gebeurtenis die verband houdt met de persoon of het systeem dat de sleutel bezit, en elke indicatie van een risico voor de sleutel zelf.

1. Op basis van tijd (vervaldatum cryptoperiode). Organisaties moeten de maximale gebruiksduur, de cryptoperiode, vaststellen waarbinnen een identiteitssleutel mag worden gebruikt voordat deze moet worden vervangen. De specifieke tijdsperiode moet gebaseerd zijn op het type sleutel en de gebruikssituatie. NIST SP 800-57 Deel 1 Revisie 5 Dit document biedt het algemene kader voor de cryptoperiode; NIST IR 7966 past dit specifiek toe op SSH-identiteitssleutels. In de praktijk rechtvaardigen geautomatiseerde servicesleutels doorgaans een kortere cryptoperiode dan interactieve, door mensen gebruikte sleutels, omdat ze continu worden gebruikt en moeilijker te detecteren zijn als ze worden gecompromitteerd.
2. Op basis van gebeurtenissen (personeels- en systeemwijzigingen). NIST IR 7966 stelt expliciet dat identiteitssleutels die worden gebruikt voor geautomatiseerde processen "moeten worden gewijzigd vóór het verstrijken van de cryptoperiode wanneer een beheerder die verantwoordelijk is voor het beheer van de sleutels voor een of meer geautomatiseerde processen is herplaatst of ontslagen." Dezelfde logica geldt voor functieveranderingen, het beëindigen van contracten met externe partijen of leveranciers, en het buitenbedrijf stellen van applicaties. In al deze gevallen moet onmiddellijke rotatie of intrekking van de sleutels worden geactiveerd, ongeacht de resterende cryptoperiode.
3. Op basis van risico (vermoedelijke of bevestigde inbreuk). Een sleutel die is blootgesteld in een code repository, een logbestand, een supportticket of op een verloren apparaat, moet onmiddellijk worden geroteerd. Hetzelfde geldt wanneer een sleutel niet langer voldoet aan de huidige algoritme- of lengtenormen, of wanneer een CVE de SSH-implementatie of een systeem waarmee de sleutel in contact komt, beïnvloedt.

Bedrijven met volwaardige programma's gebruiken alle drie de triggertypes samen. Een vaste kalender alleen mist personeelswijzigingen en beveiligingslekken; triggers alleen, zonder een basiscryptieperiode, laten slapende, niet-gecontroleerde sleutels voor onbepaalde tijd bestaan.

Hoe moeten bedrijven hun SSH-toegangsbeleid ontwerpen?

Een effectief SSH-toegangsbeleid definieert wie toegang kan aanvragen, wanneer sleutels worden uitgegeven, hoe lang de toegang geldig is en welke omgevingen strengere controles vereisen. Vervolgens worden deze regels automatisch afgedwongen, in plaats van dat individuele beheerders ze moeten onthouden.

Een werkbaar beleid moet het volgende omvatten:

• Toegang op basis van rollen en functiescheiding. Toegang tot de productieomgeving moet anders worden beheerd dan toegang tot de ontwikkelomgeving, en serviceaccounts moeten andere regels volgen dan gebruikersaccounts. De persoon die een sleutelaanvraag goedkeurt, mag niet dezelfde persoon zijn die de sleutel installeert, indien de omgeving die scheiding toelaat.
• Bron- en commandobeperkingen. NIST IR 7966 beveelt aan om beperkingen voor bron-IP-adressen en commando's rechtstreeks op geautomatiseerde processleutels te configureren, zodat een gestolen sleutel beperkt wordt in waar deze verbinding kan maken en wat deze kan uitvoeren, in plaats van onbeperkte shelltoegang te verlenen.
• Omgevingsgebaseerde besturing. Strengere goedkeuringsprocedures en kortere cryptoperiodes voor productie- en internetgerichte systemen; minder strenge controles, maar nog steeds met registratie, voor geïsoleerde ontwikkelomgevingen.
• Integratie van CI/CD-pipelines. Door beleidscontroles toe te voegen aan CI/CD-pipelines wordt de toegang geverifieerd als onderdeel van het implementatieproces zelf. Dit sluit aan bij de manier waarop DevOps-teams al werken en voorkomt dat beleid een handmatige poort wordt die onder tijdsdruk wordt overgeslagen.

Om de resultaten aan het management te kunnen presenteren, kunt u statistieken bijhouden zoals het aantal verwijderde achtergebleven sleutels, de tijdsbesparing tijdens audits en de verbetering van het slagingspercentage bij compliance-tests. Deze cijfers onderstrepen de noodzaak van voortdurende investeringen in een gestructureerd SSH-sleutelbeheerprogramma.

Welke auditbewijzen moeten de belangrijkste SSH-programma's opleveren?

Audits vereisen bewijs, geen beschrijving van de intentie. NIST IR 7966 modelleert een gecontroleerde SSH-toegangscyclus in vijf fasen: aanvraag, goedkeuring, provisioning, gebruiksregistratie en beëindiging. Een programma dat in elke fase een registratie kan genereren, maakt compliance tot een bijproduct van normale bedrijfsvoering in plaats van een aparte inspanning.

• Verzoek om een ​​dossier: wie toegang heeft aangevraagd, tot welke systemen en de opgegeven zakelijke rechtvaardiging.
• Goedkeuringsrecord: Wie heeft het verzoek beoordeeld, aan de hand van welk beleid en welke beperkingen (bron, opdracht) waren eraan verbonden?
• Voorzieningsregistratie: Bevestiging van wanneer en waar de publieke sleutel is geïnstalleerd, en via welk proces.
• Gebruikslogboek: NIST IR 7966 beveelt aan dat SSH-servers sleutelvingerafdrukken vastleggen voor elke geauthenticeerde sessie, zodat het gebruik kan worden gekoppeld aan een specifieke sleutel en eigenaar voor forensisch onderzoek en auditdoeleinden.
• Beëindigingsdossier: Bevestiging dat de sleutel is verwijderd, wanneer en waarom (functiewijziging, uitdiensttreding of buitenbedrijfstelling van het systeem).

Frameworks zoals SOC 2, ISO/IEC 27001 en PCI DSS vereisen allemaal dat een organisatie aantoont dat toegang tijdig wordt gecontroleerd en ingetrokken. SSH-sleutels vormen vaak de zwakste schakel in die bewijsketen, juist omdat ze, in tegenstelling tot certificaten, geen automatische vervaldatum hebben waaraan een controle kan worden gekoppeld. Onze handleiding voor het slagen voor SSH-sleutelaudits gaat dieper in op het voorbereiden van dit bewijsmateriaal voor een specifieke auditcyclus.

Hoe implementeer je SSH-sleutellevenscyclusbeheer?

Het invoeren van SSH-sleutellevenscyclusbeheer vereist geen verstoring van bestaande processen. Het voegt governance en automatisering toe aan bestaande workflows in een gedefinieerde volgorde, van ontdekking tot buitenbedrijfstelling.

Stap 1: Ontdek en inventariseer alle sleutels

Voordat een organisatie beleid kan invoeren, moet ze weten welke SSH-sleutels er al bestaan. NIST IR 7966 is hier heel duidelijk over: het handmatig opsporen en inventariseren van alle identiteits- en geautoriseerde sleutels in een grote omgeving is "praktisch onmogelijk" en automatisering is in feite een vereiste. In de praktijk betekent dit het scannen van servers, cloud-instanties en automatiseringsplatformen op geautoriseerde sleutels, het in kaart brengen van vertrouwensrelaties tussen systemen en het vastleggen van de eigenaar van elke sleutel. Tools zoals SSH Secure automatiseren dit proces en bieden een uniform overzicht van de SSH-toegang in de hele omgeving.

Niet-geregistreerde of achtergebleven sleutels kunnen ongeautoriseerde toegang mogelijk maken en de incidentrespons bemoeilijken. Begin met het beoordelen van de huidige inventaris en stel vervolgens een migratieplan op dat prioriteit geeft aan kritieke systemen en geleidelijk wordt uitgebreid, om de verstoring te minimaliseren en tegelijkertijd een consistent overzicht te garanderen.

Stap 2: Eigendom toewijzen

Elke gevonden sleutel, en elke sleutel die in de toekomst wordt uitgegeven, moet een benoemde eigenaar hebben die is gekoppeld aan een persoon, rol of applicatie. Eigenaarschap is niet optioneel; het maakt audits, toegangscontroles en incidentafhandeling beheersbaar in plaats van een forensisch onderzoek. Een tool voor levenscyclusbeheer houdt dit eigenaarschap en de toegangscontext automatisch bij in elke fase van de levenscyclus van de sleutel.

Stap 3: Het toegangsbeleid definiëren en afdwingen

Met inzicht en verantwoordelijkheid op orde, kunt u de eerder beschreven toegangsbeleidsregels, op rollen gebaseerde toegang, bron- en commandobeperkingen en omgevingsspecifieke controles toepassen en deze afdwingen tijdens het provisioneringsproces zelf, in plaats van achteraf.

Stap 4: Voorziening met gecontroleerde goedkeuring

Nieuwe sleutels moeten een aanvraag- en goedkeuringsproces doorlopen voordat ze worden geactiveerd, conform het fasemodel dat NIST IR 7966 beschrijft. Waar mogelijk moet de activering zelf worden geautomatiseerd: NIST IR 7966 merkt op dat geautomatiseerde activering het benodigde resources vermindert, de behoefte aan permanente geprivilegieerde toegang verkleint en handmatige configuratiefouten elimineert in vergelijking met een beheerder die handmatig een sleutel bewerkt. authorized_keys bestand.

Stap 5: Automatiseer de rotatie

Handmatige sleutelrotatie over meerdere systemen is complex en foutgevoelig. Geautomatiseerde rotatie stelt organisaties in staat nieuwe sleutels te implementeren zonder de dienstverlening te verstoren, met name in multi-cloudomgevingen, en zorgt er tegelijkertijd voor dat uitgaande sleutels snel worden verwijderd in plaats van actief te blijven naast de vervangende sleutels.

Stap 6: Gebruik monitoren en registreren

Elke SSH-login moet worden vastgelegd met de specifieke sleutel die is gebruikt, de eigenaar ervan en het systeem waartoe toegang is verkregen. Deze gebruiksgegevens maken het mogelijk om ongebruikte sleutels te identificeren, toegang buiten het beleid te detecteren en te bevestigen of een sleutel moet worden geroteerd of ingetrokken. Door SSH-sleutelactiviteit te integreren in een SIEM-platform zoals Splunk blijft het SSH-zicht consistent met de rest van de beveiligingsactiviteiten van de organisatie.

Stap 7: Buitenbedrijf stellen en intrekken

Uiteindelijk moet elke sleutel worden verwijderd, bijvoorbeeld bij het buiten gebruik stellen van een systeem, een functieverandering, het verlaten van een team of het einde van een contract. Deze verwijdering moet worden bevestigd en niet als vanzelfsprekend worden beschouwd. Dit is de stap die de meeste ad-hoc SSH-praktijken volledig overslaan, waardoor er jarenlang ongebruikte sleutels zonder duidelijk doel in een omgeving ophopen.

Handmatig, PAM-geïntegreerd of apart: welk SSH-sleutelbeheermodel past het beste?

Bedrijven beheren SSH-sleutels over het algemeen op een van de drie manieren, en elk daarvan leidt tot een heel ander audit- en risico-uitkomst naarmate de omgeving groeit.

Bekwaamheid	Handleiding (scripts, spreadsheets)	PAM-geïntegreerd	Speciaal SSH-sleutelbeheer
De reis van mijn leven	Ad hoc, vaak onvolledig	Beperkt tot sleutels die al in PAM zijn opgeslagen.	Continue, omgevingsoverstijgende ontdekking
Eigendomsregistratie	Informele, tribale kennis	Verbonden met de PAM-identiteit, maar niet altijd de sleutel zelf.	Toegewezen en bijgehouden per sleutel bij uitgifte.
Rotatie	Handmatig, foutgevoelig op grote schaal	Geautomatiseerd, maar alleen voor sleutels in een kluis.	Geautomatiseerd met behoud van SSH-specifieke beperkingen.
Bron-/opdrachtbeperkingen	Wordt zelden consequent gehandhaafd	Vaak niet standaard ondersteund	Eigen aan het SSH-vertrouwensmodel
Controlebewijs	Handmatig geassembleerd, trage productie	Sterk voor sleutels in kluizen, blind voor de rest	Doorlopend en exporteerbaar voor de volledige inventaris.
Typische pasvorm	Zeer kleine omgevingen	Organisaties hebben PAM al gestandaardiseerd met een gemiddeld sleutelvolume.	Grote, hybride of sterk gereguleerde omgevingen

Een PAM-platform is geen vervanging voor SSH-specifiek lifecyclemanagement; het beheert doorgaans de sleutels die het opslaat goed, maar SSH-sleutels die buiten die kluis worden gegenereerd, ingebed in automatisering, gekopieerd naar een nieuwe host of overgebleven zijn van een eerder project, blijven onzichtbaar voor het platform. Die lacune is precies wat speciale tools voor het ontdekken en beheren van SSH-sleutels moeten opvullen.

Welke beveiligingsmaatregelen zijn vereist voor welke SSH-sleutelrisicocategorie?

Niet elke sleutel brengt hetzelfde risico met zich mee, en het toepassen van één rotatiefrequentie op elke sleutel leidt tot verspilling van inspanning bij sleutels met een laag risico, terwijl sleutels met een hoog risico onvoldoende worden gecontroleerd. Gebruik de sleutelklasse om de vereiste controles in te stellen.

Sleutelklasse	Voorbeeld	Rotatiecadans	Vereiste controles
Interactieve mens	Inloggen als engineer of beheerder op de productieomgeving	Korte cryptoperiode (meestal 90 tot 180 dagen), of direct bij een functie- of arbeidsverandering.	Met een wachtwoord beveiligde privésleutel, goedkeuringsworkflow, MFA-ondersteunde provisioning (indien beschikbaar).
Geautomatiseerd/service	CI/CD-pipeline, implementatieagent, monitoringsysteem	De cryptoperiode is korter dan die van menselijke sleutels bij continu, frequent gebruik; onmiddellijke rotatie als de beheerder van de automatisering van rol verandert.	Commando- en bron-IP-beperkingen, beveiligde opslag, geen interactieve wachtwoordzin vereist.
Derde partij/leverancier	Toegang voor aannemers of beheerde serviceproviders	Wissel van rol bij het bereiken van contractmijlpalen en direct aan het einde van het contract.	Toegang beperkt tot de minimaal vereiste systemen, geregistreerd en afzonderlijk van interne sleutels.
Wortel/glas breken	Noodtoegangspad voor administratief gebruik	Draai na elk gebruik.	Goedkeuring door meerdere partijen, verzegelde of beveiligde opslag, verplichte evaluatie na gebruik.

Hoe moeten bedrijven reageren als een SSH-sleutel is gecompromitteerd?

Een gecompromitteerde SSH-sleutel moet worden behandeld als een actief incident, niet als een routinecontrole. Het eerste uur is cruciaal, omdat een sleutel die toegang geeft tot één systeem, via vertrouwensrelaties, toegang kan verschaffen tot vele andere systemen.

1. Draai de sleutel onmiddellijk om of trek hem in. Verwijder de gecompromitteerde publieke sleutel van elk apparaat. authorized_keys Het item waarin het voorkomt, hoeft u niet te wachten op een gepland rotatievenster.
2. Breng de vertrouwensrelaties in kaart. Identificeer elk systeem dat de gecompromitteerde sleutel vertrouwde, inclusief alle downstream-systemen die deze kon bereiken, met behulp van de inventaris die tijdens de ontdekking is opgesteld.
3. Controleer de authenticatielogboeken op laterale bewegingen. Controleer of de sleutel is gebruikt vanuit een onverwachte bron, op een onverwacht tijdstip of om toegang te krijgen tot systemen die buiten het normale patroon vallen.
4. Roteer de downstream-sleutels indien nodig. Als de gecompromitteerde sleutel gebruikt had kunnen worden om toegang te krijgen tot andere inloggegevens of systemen, beschouw die dan ook als potentieel blootgesteld.
5. Leg het incident vast. Leg vast wat er is gebeurd, wat er is geroteerd en welk bewijsmateriaal de reactie ondersteunt. Dit dient direct als input voor de eerder beschreven bewijsketen binnen de audit.

Dit is een samenvatting van de directe reactie, geen volledig draaiboek. Voor een stapsgewijze afhandeling van incidenten, zie Incidentrespons bij blootgestelde SSH-sleutels , en voor het beveiligen van SSH tegen de aanvalstechnieken die in eerste instantie tot sleutelcompromittering leiden, zie SSH beveiligen tegen aanvallen.

Beperkingen

• Lifecycle-tools verminderen risico's, maar vervangen geen beleidsbeslissingen; toewijzing van verantwoordelijkheid vereist nog steeds draagvlak binnen de organisatie en een gedefinieerd proces, niet alleen software.
• Geautomatiseerde detectie kan sleutels missen die zijn ingebed in containerimages, hardgecodeerd in scripts buiten de gescande paden of opgeslagen in onbeheerde persoonlijke wachtwoordkluizen; periodieke handmatige controle blijft daarom noodzakelijk naast automatisering.
• Het beheer van de levenscyclus van SSH-sleutels vormt een aanvulling op IAM en PAM; het vervangt deze niet. Het regelt specifiek een type inloggegevens dat IAM en PAM vaak niet standaard kunnen herkennen.
• Wanneer een organisatie overstapt op SSH-certificaten, kortstondige referenties uitgegeven door een interne SSH-certificeringsinstantie, verschuift een deel van de rotatielast naar de uitgifte van certificaten in plaats van de vervanging van statische sleutels. Deze handleiding behandelt de levenscyclus van standaard sleutelparen; een SSH-CA is een apart operationeel model met eigen afwegingen.
• De hier gegeven richtlijnen zijn algemeen van aard. In gereguleerde omgevingen (FIPS 140-3, PCI DSS, HIPAA) dienen specifieke rotatieschema's en controlebeslissingen te worden getoetst aan de eigen nalevingsverplichtingen alvorens het beleid definitief vast te stellen.

Wat zou Encryption Consulting aanbevelen?

We beschouwen de wildgroei aan SSH-sleutels als een governance-tekortkoming, niet als een tekortkoming in de tools die met één enkel script kan worden opgelost. In onze projecten zien we steeds hetzelfde patroon: organisaties hebben strenge controles op certificaten en wachtwoorden, maar vrijwel geen inzicht in SSH-sleutels, omdat het protocol dat inzicht niet verplicht stelt.

Met SSH Secure biedt Encryption Consulting organisaties gecentraliseerd inzicht in de volledige levenscyclus van SSH-sleutels: ontdekking, beleidsdefinitie, gecontroleerde provisioning, toewijzing van eigendom, rotatie, intrekking, monitoring en auditing, allemaal op één plek. Deze op de levenscyclus gebaseerde aanpak versterkt de toegangscontrole, vermindert ongeautoriseerde toegang, minimaliseert operationele verstoringen en verlaagt de doorlopende beheerkosten. Duidelijk eigendom en controleerbare gegevens vereenvoudigen toegangscontroles en het verwijderen van gebruikers, terwijl continue zichtbaarheid compliance-beoordelingen sneller en minder arbeidsintensief maakt.

SSH Secure integreert met SIEM-platforms zoals Splunk, waardoor SSH-activiteit wordt gemonitord samen met de rest van de beveiligingsprocessen van een organisatie, in plaats van in een aparte omgeving. Samen met CertSecure Manager voor certificaatlevenscyclusbeheer, PKI-as-a-Service voor schaalbare publieke sleutelinfrastructuur en HSM-as-a-Service voor hardwarematige sleutelbescherming, stelt SSH Secure bedrijven in staat om cryptografische toegang consistent te beheren in plaats van één type authenticatie tegelijk.

Conclusie

Veelgestelde Vragen / FAQ

Wat is SSH-sleutellevenscyclusbeheer? SSH-sleutellevenscyclusbeheer is de gestructureerde methode om elk SSH-sleutelpaar in een omgeving te detecteren, een verantwoordelijke eigenaar toe te wijzen, toegangsbeleid af te dwingen bij het aanmaken van de sleutel, sleutels te roteren volgens een gedefinieerde cryptoperiode of een triggerende gebeurtenis, te controleren hoe elke sleutel wordt gebruikt en deze in te trekken of buiten gebruik te stellen wanneer toegang niet langer nodig is. Het vervangt de informele, server-per-server sleutelafhandeling door een gereguleerd, controleerbaar proces.

Hoe vaak moeten SSH-sleutels worden geroteerd? Er is geen universeel getal. De NIST-richtlijnen koppelen rotatie aan een gedefinieerde cryptoperiode, bepaald door het sleuteltype en het risico. Deze periode is doorgaans korter voor geautomatiseerde servicesleutels dan voor sleutels die door mensen worden gebruikt. Bovendien is onmiddellijke rotatie vereist bij specifieke gebeurtenissen, zoals een functieverandering, ontslag van een medewerker of een vermoedelijke inbreuk, ongeacht hoeveel cryptoperiode er nog resteert.

Wie moet de eigenaar zijn van SSH-sleutels in een bedrijfsomgeving? Elke SSH-sleutel moet een benoemde eigenaar hebben op het moment dat deze wordt aangemaakt. Dit is doorgaans de aanvragende engineer of de applicatiebeheerder van de sleutel zelf. Een beveiligings- of toegangsbeheerteam is verantwoordelijk voor het goedkeuren van de aanvraag en het handhaven van het beleid. Het eigenaarschap mag nooit achteraf worden gewijzigd tijdens een audit of incident.

Wat is het verschil tussen SSH-sleutelrotatie en SSH-sleutelintrekking? Rotatie is een geplande, routinematige vervanging van een sleutel vóór of aan het einde van de cryptoperiode, om de geldigheidsduur van een sleutel te beperken. Intrekking is het intrekken van het vertrouwen in een specifieke sleutel, meestal als gevolg van een incident, een rolwijziging of het buitenbedrijf stellen van een systeem, en kan op elk moment plaatsvinden, ongeacht het rotatieschema.

Kan het beheer van de levenscyclus van SSH-sleutels worden geautomatiseerd zonder CI/CD-pipelines te verstoren? Ja. Provisionering op basis van sjablonen, geautomatiseerde rotatie en beleidscontroles kunnen direct in CI/CD-workflows worden geïntegreerd, zodat de uitgifte en rotatie van sleutels onderdeel uitmaken van de pipeline in plaats van een handmatig proces. NIST IR 7966 beveelt specifiek geautomatiseerde provisionering aan om handmatige configuratiefouten te verminderen en de behoefte aan permanente geprivilegieerde toegang te verlagen.

Gerelateerde SSH-beveiligingsbronnen

Deze handleiding is de centrale referentie van Encryption Consulting voor het beheer van de levenscyclus van SSH-sleutels. De onderstaande bronnen gaan dieper in op specifieke onderdelen van de SSH-beveiliging:

• Alles wat u moet weten over SSH, om de basisprincipes van protocollen te leren kennen voordat we ons verdiepen in levenscyclusbeheer.
• Het dichten van toegangskloven via SSH, om de specifieke proceshiaten te dichten die ervoor zorgen dat ongecontroleerde toegang zich ophoopt.
• SSH-sleuteleigendomVoor een diepere analyse van het toewijzen en handhaven van eigendomsmodellen.
• SSH-sleutelspreiding, voor hoe ongecontroleerde sleutelgroei ontstaat en hoe je dit kunt terugdraaien.
• Niet-beheerde SSH-sleutels, met het oog op de specifieke risico's van sleutels zonder traceerbare eigenaar.
• SSH-kwetsbaarheden: hoe u zich ertegen kunt beschermen, voor kwetsbaarheden op protocolniveau en implementatieniveau.
• SSH beveiligen tegen aanvallen, om SSH te beveiligen tegen aanvalstechnieken die tot inbreuken leiden.
• Incidentrespons voor blootgestelde SSH-sleutelsRaadpleeg de volledige handleiding voor incidentrespons waarnaar hierboven wordt verwezen.
• SSH beveiligdHet platform van Encryption Consulting voor het ontdekken, beheren van beleid, roteren en controleren van SSH-sleutels gedurende hun gehele levenscyclus.

Referenties

• NIST IR 7966: Beveiliging van interactief en geautomatiseerd toegangsbeheer met behulp van Secure Shell (SSH)Nationaal Instituut voor Standaarden en Technologie
• NIST SP 800-57 Deel 1 Revisie 5: Aanbeveling voor sleutelbeheer, algemeenNationaal Instituut voor Standaarden en Technologie
• Verbeterde zichtbaarheid en richtlijnen voor de versterking van communicatie-infrastructuurAgentschap voor cyberbeveiliging en infrastructuurbeveiliging
• ssh-keygen(1) handleidingpaginaOpenBSD/OpenSSH-project