Een effectief beleid voor het roteren van SSH-sleutels ontwerpen

SSH- sleutels (Secure Shell) vormen de basis van moderne infrastructuren en stellen beheerders, automatiseringssystemen en CI/CD-pipelines in staat om veilig en zonder wachtwoorden te communiceren via netwerken. SSH-sleutels verlopen echter niet standaard: eenmaal gegenereerd en vertrouwd, kunnen ze onbeperkt geldig blijven. Zonder een expliciet rotatiebeleid verzamelen organisaties lang bestaande, niet-geroteerde inloggegevens die permanente toegang bieden tot kritieke systemen, lang nadat de oorspronkelijke bedrijfsbehoefte is verdwenen. Aanvallers weten dit. Als ze een privé-SSH-sleutel bemachtigen die jaren geleden is aangemaakt, krijgen ze vaak direct wachtwoordloze toegang tot de systemen die ermee geautoriseerd zijn. De aanbevolen actie: definieer een formeel SSH-sleutelrotatiebeleid met risicogebaseerde rotatieschema's, gebeurtenisgebaseerde triggers, cryptografische standaarden en geautomatiseerde handhaving via een gecentraliseerd SSH-sleutelbeheerplatform.

Kort antwoord: Wat vereist een effectief SSH-sleutelrotatiebeleid?

Een effectief beleid voor het roteren van SSH-sleutels vereist: een volledige inventarisatie van alle SSH-sleutels in de omgeving; een governance-structuur die eigendom, rollen en verantwoordelijkheden definieert; risicogebaseerde rotatieschema's (30 tot 90 dagen voor sleutels met een hoog risico, jaarlijks voor sleutels met een laag risico); gebeurtenisgebaseerde triggers voor rotatie (vertrek, compromittering, veroudering van algoritmen); afgedwongen cryptografische standaarden (Ed25519 heeft de voorkeur, RSA-3072 is het minimum); een gedocumenteerd end-to-end rotatieproces; automatisering via een SSH-sleutelbeheerplatform; en auditlogboeken die bewijs leveren van naleving. Zie voor meer informatie onze artikelen over de vergelijking van SSH-sleutelalgoritmen en wachtwoordloze SSH-authenticatie.

Waarom wordt het roteren van SSH-sleutels vaak over het hoofd gezien?

In tegenstelling tot wachtwoorden of TLS-certificaten hebben SSH-sleutels geen ingebouwd vervalmechanisme. Er verschijnt geen herinnering wanneer een sleutel een bepaalde leeftijd bereikt; geen authenticatiefout geeft aan dat de sleutel aan vervanging toe is. Dit technische gebrek aan urgentie creëert een beheerslacune die blijft bestaan ​​totdat een incident de kwestie aan het licht brengt. Veelvoorkomende operationele problemen die hieruit voortvloeien:

• Er is geen inventarisatie van waar de sleutels zich bevinden: welke servers welke openbare sleutels hebben geautoriseerd, waar de privésleutels worden opgeslagen of hoeveel SSH-sleutels er in totaal in de omgeving aanwezig zijn.
• Handmatige rotatie is foutgevoelig en kan op grote schaal operationele problemen veroorzaken: het bijwerken van authorized_keys op honderden servers vereist automatisering om betrouwbaar te zijn.
• Gebruikers genereren vrijelijk sleutels met ssh-keygen, wat leidt tot inconsistenties in algoritmesterkte, sleutellengte en naamgevingsconventies binnen de omgeving.
• Verouderde sleuteltypen (DSA, RSA-1024) blijven in productie zonder inzicht in de gebruiksfrequentie, de tijdstempels van de laatste toegang of of de eigenaar van de sleutel nog steeds bij de organisatie werkt.
• Vastgelegde sleutels in applicaties of automatiseringsscripts die nooit kunnen worden gewijzigd zonder een codeaanpassing.
• Geen centraal beheer: geen enkel team is verantwoordelijk voor het beheer van de levenscyclus van SSH-sleutels in de gehele omgeving.

De risico's van het niet roteren van SSH-sleutels

Risico	Beschrijving
Aanhoudende ongeautoriseerde toegang	Sleutels verlopen niet, waardoor aanvallers langdurige toegang hebben zodra ze een privésleutel in handen hebben.
Verweesde sleutels	Sleutels die zijn aangemaakt door gebruikers die de organisatie hebben verlaten, blijven geautoriseerd op servers, soms met beheerdersrechten.
Zijwaartse beweging	Het hergebruik van sleutels over meerdere systemen stelt aanvallers in staat om ongemerkt tussen servers te wisselen.
Schaduw IT	Ontwikkelaars en beheerders maken onbeheerde sleutels aan zonder goedkeuring, buiten elk beheer- of inventarisatieproces om.
Audit- en nalevingskwesties	PCI DSS, ISO 27001, SOX, NIST SP 800-53 en FedRAMP vereisen bewijs van cryptografisch sleutelbeheer en toegangscontrole; niet-geroteerde sleutels leiden tot bevindingen met betrekking tot naleving.

Onderdelen van een SSH-sleutelpaar

Een SSH-sleutelpaar bestaat uit twee cryptografisch gekoppelde componenten:

• Prive sleutel: Veilig opgeslagen op de client; moet vertrouwelijk blijven; wordt nooit via het netwerk verzonden. Dit is de inloggegevens die toegang verlenen.
• Publieke sleutel: Deze gegevens worden opgeslagen in het bestand authorized_keys op de externe server. De server controleert dit bestand om te bepalen of de client geautoriseerd is.

Sleutelrotatie vervangt beide componenten: er wordt een nieuw sleutelpaar gegenereerd; de nieuwe publieke sleutel wordt geïmplementeerd op geautoriseerde servers; de oude publieke sleutel wordt verwijderd uit de authorized_keys-bestanden van alle servers; de privésleutel op de client wordt vervangen door de nieuwe. De rotatie is pas voltooid wanneer de oude publieke sleutel is verwijderd van elke server die deze geautoriseerd had.

Een goed ontworpen rotatiebeleid regelt de volledige levenscyclus van SSH-sleutels:

1. Verzoek / Aanmaken
2. Goedkeuring en toewijzing van metadata
3. Implementatie naar doelservers
4. Gebruik en monitoring
5. Rotatie / Herroeping
6. Ontmanteling

Een sterk rotatiebeleid moet risicogebaseerd, geautomatiseerd en cryptografisch beveiligd zijn, en afgestemd op de bedrijfsvoering.

Het ontwerpen van het SSH-sleutelrotatiebeleid

Een effectief beleid voor het roteren van SSH-sleutels zorgt voor duidelijke en afdwingbare controle over de gehele levenscyclus van de SSH-sleutel. De volgende acht componenten definiëren een compleet beleidsraamwerk:

1. Stel SSH-governance in

Voordat u rotatie invoert, moet u een bestuursstructuur definiëren die het volgende omvat:

• Rollen en verantwoordelijkheden (wie is verantwoordelijk voor het beheer van SSH-sleutels, wie handhaaft het beleid, wie keurt sleutelaanvragen goed)
• Eigendom van elke SSH-sleutel: elke sleutel moet een gedocumenteerde eigenaar hebben, ofwel een persoon ofwel een systeem.
• Goedkeuringsworkflows voor het genereren van nieuwe sleutels en het verlenen van toegang
• Periodiek toegangsbeoordelingsplan (kwartaal- of halfjaarlijks voor sleutels met een hoog risico)
• Handhavingsmechanisme (geautomatiseerde beleidshandhaving via SSH-sleutelbeheerplatform)
• Een formeel, schriftelijk document met een beleid voor het roteren van SSH-sleutels.

2. Voer SSH-sleuteldetectie uit.

Je kunt niet roteren wat je niet kunt zien. De ontdekking moet het volgende omvatten:

• Alle servers in de omgeving (Linux, Unix, cloud-instanties, applicaties)
• Alle authorized_keys-bestanden op alle servers en gebruikersaccounts.
• Alle lokale privésleutelarchieven op werkstations en servers.
• Sleutels ingebed in scripts, automatiseringstools, CI/CD-pipelines en configuratiebestanden.

Het resultaat van de ontdekking is een complete SSH-sleutelinventaris die elke publieke sleutel koppelt aan de eigenaar, implementatielocaties, aanmaakdatum, algoritme en het tijdstempel van de laatste toegang. Zonder deze inventaris is de sleutelrotatie onvolledig, omdat je een sleutel niet van elke server kunt verwijderen als je niet weet op welke servers deze zich bevindt. Zie ons artikel over cryptografische inventaris voor een bredere context over inventarisatie.

3. Sleutels classificeren op basis van risico

Een op risico gebaseerd rotatieschema voorkomt zowel onderrotatie (sleutels met een hoog risico en lange rotatieschema's) als overrotatie (sleutels met een laag risico die frequente onderbrekingen vereisen). De volgende classificatie is een voorbeeldkader; het specifieke beleid van uw organisatie moet de interne risicobeoordeling en wettelijke vereisten weerspiegelen:

Risico niveau	Criteria op hoog niveau	Rotatiefrequentie
Hoge	Roottoegang, gedeelde sleutels, onbekende eigenaren, sleutels ouder dan 2 jaar, sleutels met toegang tot gevoelige gegevens of productieomgevingen	30 om 90 dagen
Medium	DevOps- en automatiseringssleutels, gebruikerssleutels met sudo, serviceaccountsleutels	90 om 180 dagen
Laag	Niet-bevoorrechte accounts, test- en ontwikkelingssystemen, alleen-leestoegang	180 om 365 dagen

4. Definieer cryptografische standaarden

Het rotatiebeleid moet minimale cryptografische standaarden afdwingen voor alle nieuwe en geroteerde sleutels. Aanbevolen standaarden zijn in lijn met NIST SP 800-57 en de huidige OpenSSH-richtlijnen:

• Ed25519: De voorkeur voor alle nieuwe en geroteerde sleutels. Deterministische handtekeningen, bewerkingen met constante uitvoeringstijd, beveiliging equivalent aan ~128-bits, kleinste sleutelgroottes.
• RSA-3072 of RSA-4096 met SHA-2-handtekeningen: Voor compatibiliteit met oudere systemen waar Ed25519 niet wordt ondersteund. RSA-2048 is het minimaal acceptabele niveau; RSA-1024 is verouderd en mag niet worden gebruikt.
• ECDSA P-256 of sterker: Aanvaardbaar indien Ed25519 niet beschikbaar is en een elliptische curve vereist is.
• DSA: verboden. Afgeschreven door NIST in FIPS 186-5 (2023); uitgeschakeld in OpenSSH 7.0+. Alle bestaande DSA-sleutels moeten onmiddellijk worden vervangen.

Voor een volledige vergelijking van algoritmen, zie ons artikel over het vergelijken van SSH-sleutelalgoritmen.

5. Definieer het rotatieproces

Een complete end-to-end workflow voor sleutelrotatie:

• Start de rotatie op basis van een schema of een geactiveerde gebeurtenis.
• Genereer een nieuw sleutelpaar op een goedgekeurd clientsysteem of via een SSH-sleutelbeheerplatform, met behulp van een goedgekeurd algoritme (Ed25519 heeft de voorkeur).
• Hanteer de volgende naamgevingsconventies: gebruiker, systeem, datum, omgeving.
• Implementeer de nieuwe publieke sleutel op alle doelservers via het geautomatiseerde SSH-sleutelbeheerplatform.
• Controleer of de nieuwe sleutel correct werkt op alle geautoriseerde servers voordat u de oude sleutel verwijdert.
• Trek de oude openbare sleutels in en verwijder ze uit de authorized_keys-bestanden van alle servers.
• Werk de centrale inventaris en het auditlogboek bij met de rotatiegebeurtenis, de datum en de operator.

6. Definieer rotatietriggers

Naast op tijd gebaseerde rotatieschema's moeten ook op gebeurtenissen gebaseerde rotatietriggers worden gedefinieerd en onmiddellijk worden afgedwongen wanneer deze worden geactiveerd:

• Vertrek van gebruiker of wijziging van rol: Alle SSH-sleutels van de vertrekkende of van functie veranderende persoon moeten onmiddellijk worden geroteerd en ingetrokken op alle servers waartoe hij of zij toegang had.
• Vermoedelijke of bevestigde inbreuk: Vervang de betreffende sleutel onmiddellijk op alle servers waar deze geautoriseerd is; onderzoek de omvang van de toegang gedurende de periode waarin de inbreuk plaatsvond.
• Resultaten van de toegangsbeoordeling: Sleutels die tijdens toegangscontroles als overbodig, ongebruikt of niet-conform het beleid worden aangemerkt, moeten onmiddellijk worden vervangen of ingetrokken.
• Infrastructuurmigratie: Sleutels moeten worden gecontroleerd en vervangen wanneer servers opnieuw worden geïnstalleerd, naar een nieuwe omgeving worden gemigreerd of aan een ander team worden overgedragen.
• Algoritme wordt afgeschaft: Elke sleutel die gebruikmaakt van een verouderd algoritme (DSA, RSA-1024) moet onmiddellijk na identificatie worden vervangen door een goedgekeurd algoritme.

7. Integreer automatisering en SSH-sleutelbeheer

Automatisering is niet optioneel voor het roteren van SSH-sleutels op bedrijfsniveau. Handmatige rotatie over honderden of duizenden servers is foutgevoelig en niet schaalbaar. Een SSH-sleutelbeheerplatform zoals SSH Secure moet het volgende bieden:

• Gecentraliseerd overzicht van alle SSH-sleutels met eigenaar, algoritme, implementatielocatie en datum van laatste toegang.
• Geautomatiseerde detectie (met en zonder agents) van alle servers in het gehele serverpark.
• Op beleid gebaseerde sleutelcreatie die cryptografische standaarden afdwingt.
• Geautomatiseerde implementatie van publieke sleutels naar alle geautoriseerde servers.
• Automatische verwijdering van oude sleutels van alle servers nadat de nieuwe sleutel is geverifieerd.
• Op rollen gebaseerde toegangscontrole en goedkeuringsworkflows
• Auditlogboeken en nalevingsrapporten voor alle gebeurtenissen in de levenscyclus.

8. Overwegingen met betrekking tot naleving

Een robuust beleid voor het rouleren van SSH-sleutels genereert het auditbewijs dat vereist is door nalevingskaders:

• PCI DSS v4.0: Vereiste 2.2.7 (sterke cryptografie voor administratieve toegang buiten de console); Vereiste 12.6 (periodieke controles van beveiligingsbewustzijn en toegang).
• NISTSP 800-53: SC-12 (Cryptografische sleutelopbouw en -beheer) en SC-17 (Certificaten voor openbare sleutelinfrastructuur); IA-3 (Apparaatidentificatie en -authenticatie).
• NISTSP 800-57: Cryptoperiod-aanbevelingen op basis van sleuteltype en algoritme.
• ISO 27001:2022 Controle 8.24: Gebruik van cryptografie, vereisten voor sleutelbeheer.
• SOX / FedRAMP: Periodieke rotatie, toegangscontrole, sleutelbeheer, functiescheiding, traceerbaarheid en het elimineren van gedeelde inloggegevens.

Toegangsbeleidsvereisten voor SSH-sleutels

• Eén sleutel per gebruiker: Elke gebruiker moet een uniek sleutelpaar hebben. Gedeelde sleutels maken het onmogelijk om per gebruiker te controleren of toegang is toegestaan ​​en bemoeilijken intrekking.
• Minste privilege: Elke sleutel mag alleen geautoriseerd worden op de specifieke servers en gebruikersaccounts die nodig zijn voor de betreffende bedrijfsfunctie. Brede autorisatie vergroot de impact van een eventuele inbreuk op een enkele sleutel.
• Geen vastgelegde sleutels: SSH-sleutels die in broncode of configuratiebestanden zijn ingebed, kunnen niet worden geroteerd zonder een herinstallatie. Gebruik platforms voor geheimbeheer om SSH-referenties dynamisch toe te voegen.
• Geen wachtwoordvrije privésleutels voor bevoorrechte toegang: Privésleutels voor toegang met een hoog risico moeten met een wachtwoordzin worden beveiligd of in HSM-hardware worden opgeslagen om te voorkomen dat ze kunnen worden achterhaald als het clientsysteem wordt gecompromitteerd.
• Periodieke toegangsbeoordeling: Alle SSH-sleutelautorisaties moeten minstens elk kwartaal worden gecontroleerd voor toegang met een hoog risico en jaarlijks voor standaardtoegang om te bevestigen dat ze nog steeds nodig zijn.

Auditbewijs: Wat vereisen belangrijke rotatieaudits?

• Belangrijkste inventaris: Een actueel overzicht van alle SSH-sleutels, eigenaren, algoritmen, aanmaakdatums, implementatieservers en datums van laatste sleutelrotatie.
• Rotatielogboeken: Tijdgestempelde registraties van elke rotatiegebeurtenis, inclusief of deze op tijd gebaseerd of door een gebeurtenis geactiveerd was, de operator, de sleutelvingerafdruk voor en na de rotatie, en een bevestiging van de verwijdering van de oude sleutel.
• Documentatie voor gebeurtenistriggers: Wanneer een vertrek of inbreuk een rotatie activeert, documenteer dan de gebeurtenis, de tijdlijn van de trigger tot de voltooiing van de rotatie, en bevestig dat de oude sleutel van alle servers is verwijderd.
• Toegang tot beoordelingsgegevens: Gedateerde documenten die de voltooiing van de toegangscontrole bevestigen, inclusief eventuele ingetrokken sleutels of bijgewerkte eigenaarsgegevens.
• Bewijs van naleving van het algoritme: Bevestiging dat alle sleutels in de omgeving gebruikmaken van goedgekeurde algoritmen; registratie van de oplossing van verouderde sleutels.

Hoe SSH Secure schaalbare rotatie mogelijk maakt

SSH Secure is ontworpen om end-to-end beveiliging en beheer van de levenscyclus van SSH-sleutels op bedrijfsniveau te bieden. Belangrijkste mogelijkheden:

• Gecentraliseerde zichtbaarheid en eigendomsregistratie: Agentgebaseerde en agentloze detectie lokaliseert elke SSH-sleutel op servers en gebruikerscomputers; alle sleutels worden opgeslagen in een uniforme inventaris met eigenaar, gebruiksgegevens en implementatiebereik; elimineert ongebruikte sleutels en vermindert sleutelverspreiding.
• Geautomatiseerde orkestratie van de levenscyclus van sleutels: Automatiseert de veilige generatie (Ed25519, ECDSA, RSA-4096), beleidsgestuurde rotatie, geplande vervaldatum en intrekking; elimineert zwakke en verouderde sleutels; vermindert menselijke tussenkomst.
• Toetsrotatie zonder aanraken: SSH-sleutels op aanvraag of volgens een schema roteren in één geautomatiseerde bewerking: nieuwe sleutel genereren, naar alle servers distribueren, verifiëren en oude sleutel verwijderen; geen handmatige tussenkomst op individuele servers; volledig inzicht in alle actieve SSH-toegang.
• Beleidsgestuurde kernactiviteiten: Alle processen voor generatie, goedkeuring, rotatie en intrekking worden afgedwongen via configureerbaar beleid; consistente handhaving in de gehele omgeving; aanpasbaar aan wettelijke vereisten.
• HSM-geïntegreerde bescherming van privésleutels: Privésleutels beveiligd in HSM's; niet-exporteerbaar en fraudebestendig; beschermd zelfs tegen compromittering op besturingssysteemniveau en geheugenuitleesaanvallen.
• Continue monitoring, audits en paraatheid voor naleving: Realtime monitoring met detectie van afwijkingen; SIEM-integratie (Splunk, Loki-Grafana); downloadbare auditlogboeken en compliance-rapporten; maakt snelle incidentrespons mogelijk.

Conclusie

Het ontwerpen van een effectief beleid voor het roteren van SSH-sleutels is geen best practice die aan de lijst met achterstallige taken moet worden toegevoegd: het is een cruciaal onderdeel van de beveiliging van geprivilegieerde toegang binnen een organisatie. SSH-sleutels die nooit worden geroteerd, bieden zowel aanvallers als voormalige medewerkers permanente toegang. Een volledig beleid vereist volledig inzicht in de inventaris, op risico gebaseerde rotatieschema's, op gebeurtenissen gebaseerde triggers voor onmiddellijke rotatie, afgedwongen cryptografische standaarden (Ed25519 heeft de voorkeur, verouderde algoritmen zijn verboden), een gedocumenteerd en geautomatiseerd rotatieproces en het auditbewijs dat compliance-frameworks vereisen. Automatisering via een SSH-sleutelbeheerplatform is de enige praktische manier om consistente beleidshandhaving op grote schaal te realiseren. Zie voor meer informatie onze artikelen over het vergelijken van SSH-sleutelalgoritmen , wachtwoordloze SSH-authenticatie en SSH Secure.

Veelgestelde Vragen / FAQ

Waarom hebben organisaties een beleid voor het roteren van SSH-sleutels nodig als sleutels niet verlopen?

Omdat sleutels die nooit verlopen zich oneindig blijven ophopen. Sleutels van voormalige medewerkers blijven geautoriseerd op servers. Gecompromitteerde sleutels blijven bruikbaar totdat ze handmatig worden ingetrokken. Een rotatiebeleid creëert de controles die rotatie afdwingen volgens een schema en bij specifieke gebeurtenissen (vertrek, compromittering, veroudering van algoritme), waardoor de stille accumulatie van lang geldige inloggegevens die aanvallers kunnen misbruiken, wordt voorkomen.

Hoe vaak moeten SSH-sleutels worden geroteerd?

Op risico gebaseerd: hoog risico (root-toegang, gedeeld, onbekende eigenaar) elke 30-90 dagen; gemiddeld risico (DevOps, automatisering, sudo) elke 90-180 dagen; laag risico (niet-bevoorrecht, testsystemen) elke 180-365 dagen. Gebeurtenisgestuurde triggers (vertrek, inbreuk, afschaffing) overschrijven het schema en vereisen onmiddellijke rotatie.

Wat moet een SSH-sleutelrotatieproces omvatten?

Start de sleutelrotatie; genereer een nieuw sleutelpaar (bij voorkeur Ed25519) op een goedgekeurd systeem of via een SSH-sleutelbeheerder; pas de naamgevingsconventies toe; implementeer de nieuwe publieke sleutel op alle doelservers; test of de nieuwe sleutel correct authenticeert; verwijder de oude publieke sleutels uit de authorized_keys-bestanden van alle servers; werk de inventaris en het auditlogboek bij.

Welke SSH-sleutelalgoritmen moet een rotatiebeleid afdwingen?

Ed25519 heeft de voorkeur (deterministische, constante-tijd, 128-bits equivalente beveiliging). Minimaal RSA-3072 of RSA-4096 indien RSA vereist is. ECDSA P-256+ is acceptabel. DSA is verboden (verouderd volgens NIST FIPS 186-5, 2023; uitgeschakeld in OpenSSH 7.0+). RSA-1024 is verboden. Alle geroteerde sleutels moeten voldoen aan de algoritmevereisten; bestaande niet-conforme sleutels moeten worden vervangen.

Welke compliance-frameworks vereisen het roteren van SSH-sleutels?

PCI DSS v4.0-vereisten 2.2.7 en 12.6; NIST SP 800-53 SC-12, SC-17, IA-3; NIST SP 800-57 (cryptoperioden); ISO 27001:2022-controle 8.24; SOX (toegangscontroles en beoordeling van inloggegevens); FedRAMP (verwijst naar NIST 800-53).

Hoe automatiseert SSH Secure de rotatie van SSH-sleutels?

Ontdekking van alle SSH-sleutels; gecentraliseerde inventaris met eigendom en gebruik; beleidsgestuurde rotatieschema's die automatisch worden afgedwongen; zero-touch rotatie (genereren, implementeren, verifiëren, oude sleutels verwijderen) in één geautomatiseerde bewerking; gebeurtenisgestuurde rotatie bij vertrek of inbreuk; HSM-ondersteunde bescherming van privésleutels; SIEM-geïntegreerde auditlogboeken voor bewijs van naleving.