Transformeer statische SSH-sleutels in tijdelijke workload-identiteiten.

Het SSH-sleutelpaar is al meer dan twee decennia de standaard voor toegang tot machines en beheerders, en die lange levensduur is nu juist het probleem. Een statische SSH-privésleutel is een referentie zonder ingebouwde vervaldatum, zonder standaard multifactorauthenticatie en vaak zonder auditlogboek. Hij werkt op dezelfde manier vanaf de dag dat hij wordt gegenereerd tot de dag dat de engineer die hem heeft gemaakt het bedrijf verlaat. In een wereld waarin workloads vluchtig zijn, continu schalen en steeds autonomer worden, is een referentie die ontworpen is om eeuwig mee te gaan, een slechte keuze voor een infrastructuur die elk uur opnieuw wordt opgebouwd.

Dit artikel beargumenteert dat SSH-toegang moet worden behandeld als een kortstondige workload-identiteit in plaats van een langdurig geheim. Deze verschuiving is niet theoretisch. Hetzelfde patroon dat wachtwoordbestanden verving door single sign-on, vervangt nu statische sleutelbestanden door geverifieerde, automatisch geroteerde identiteiten die worden uitgegeven op het moment van toegang. We bespreken waarom deze verandering nu belangrijk is, de technische basis van SSH-certificaten en het SPIFFE/SPIRE-workload-identiteitsraamwerk, de operationele risico's van niets doen en een praktisch migratiepad dat de automatisering waarop uw bedrijf vertrouwt, niet verstoort.

Waarom dit nu van belang is

Drie factoren hebben ertoe geleid dat statische SSH-sleutels een zaak op bestuursniveau zijn geworden in plaats van een routineklus.

Machine-identiteiten domineren nu het landgoed.

Niet-menselijke identiteiten hebben menselijke accounts stilletjes en met grote marge ingehaald. Uit onderzoek van CyberArk uit 2025 bleek dat machine-identiteiten meer dan 80 keer zo talrijk zijn als menselijke identiteiten, waarbij bijna de helft gevoelige of bevoorrechte toegang heeft. Andere metingen tonen een nog hogere verhouding in cloud-native omgevingen. Elk van deze identiteiten moet zich ergens bij authenticeren, en een groot deel doet dat nog steeds met een statische SSH-sleutel of een vergelijkbaar, langdurig geheim. Alleen al door de schaal is handmatig sleutelbeheer onhoudbaar.

Het risico is er altijd geweest, en aanvallers weten dat.

De uitvinder van SSH, Tatu Ylonen, schreef de richtlijnen van het Amerikaanse National Institute of Standards and Technology over dit onderwerp. Hij heeft er openlijk over gesproken dat het probleem zich de afgelopen 20 jaar heeft opgebouwd omdat toegang tussen systemen grotendeels onopgemerkt is gebleven door de meeste beveiligingsprogramma's. Onbeheerde SSH-vertrouwensrelaties stellen een aanvaller die één systeem compromitteert in staat om toegang te krijgen tot vele andere systemen, en achtergebleven sleutels van voormalige medewerkers fungeren als permanente, niet-traceerbare achterdeuren.

Moderne gereedschappen maken het alternatief eindelijk praktisch uitvoerbaar.

Tot voor kort was operationele frictie het grootste obstakel voor tijdelijke SSH-toegang. Dat is veranderd. Dankzij OpenSSH-certificaatondersteuning, integratie met identiteitsproviders en volwaardige open-source frameworks voor identiteitsbeheer kan een organisatie nu SSH-referenties uitgeven die slechts enkele uren geldig zijn in plaats van jaren, met automatische verlenging waar de gebruikers geen last van hebben. Authenticatie op basis van certificaten maakt het beheer van sleutels minder gevoelig voor fouten: als niemand een referentie verlengt, verloopt de toegang simpelweg in plaats van oneindig te blijven bestaan.

Hoe werken kortstondige SSH-referenties?

Het vervangen van een statische sleutel door een kortstondige identiteit berust op twee bouwstenen: SSH-certificaten, die een publieke sleutel verpakken in ondertekende, verlopende metadata, en het SPIFFE/SPIRE-workload-identiteitsframework, dat vaststelt wat een workload is voordat er referenties worden uitgegeven. Inzicht in waarom een ​​statische sleutel structureel zwak is, hoe certificaten dit oplossen en waar workload-identificatie in past, vormt de basis voor een migratie die de automatisering niet verstoort.

Waarom een ​​statische SSH-sleutel structureel zwak is

Een standaard SSH-sleutel bevat vrijwel geen informatie over wie of wat hem gebruikt. Een SSH-sleutel werkt als een fysieke deursleutel: bezit alleen al geeft toegang, en velden zoals de opmerking zijn optioneel en worden niet door de server geïnterpreteerd. Er is geen identiteitsbinding, geen vervaldatum en geen centrale autoriteit. Toegang wordt verleend door een publieke sleutel toe te voegen aan een authorized_keys-bestand op elke server, wat betekent dat het vertrouwen gedecentraliseerd is en in feite onmogelijk op grote schaal te inventariseren valt.

SSH zelf was nooit ontworpen om dit probleem op te lossen. Het interne rapport van NIST over dit onderwerp stelt duidelijk dat SSH geen ingebouwde mechanismen heeft voor het verlopen of vernieuwen van sleutels, of voor geautomatiseerde geldigheidscontroles. Dit is precies de reden waarom ongecontroleerde accumulatie, ook wel bekend als key sprawl, zo vaak voorkomt.

Kortstondige SSH-certificaten

Een SSH-certificaat behoudt het bekende sleutelpaar, maar verpakt de publieke sleutel in ondertekende metadata: een principal die de gebruiker of service identificeert, een geldigheidsperiode en optionele beperkingen zoals verplichte commando's of beperkingen op het bron-IP-adres. Elk certificaat wordt ondertekend door een vertrouwde certificeringsinstantie (CA), waardoor servers de CA vertrouwen in plaats van per gebruiker geautoriseerde sleutels bij te houden. De vervaldatum zorgt ervoor dat gecompromitteerde inloggegevens automatisch verlopen. Dit is hetzelfde model dat organisaties zoals Google, Netflix en Uber gebruiken om servertoegang op grote schaal te beheren.

Het typische uitgifteproces is eenvoudig. Een gebruiker authenticeert zich via single sign-on, de login-utility genereert een nieuw sleutelpaar en vraagt ​​een ondertekend certificaat aan bij de certificeringsinstantie (CA). De CA retourneert vervolgens een certificaat dat slechts geldig is voor een werksessie, vaak acht tot twintig uur, waarna de gebruiker zich opnieuw authenticeert. Sommige implementaties geven certificaten uit die dagelijks worden vernieuwd of na één werkdag verlopen, terwijl platforms met bevoorrechte toegang voor elke verbinding een nieuw certificaat uitgeven dat slechts enkele minuten geldig kan zijn. De fundamentele eigenschap blijft hetzelfde: de authenticatiegegevens zijn tijdelijk en de host vertrouwt op een autoriteit en een beleidsbeslissing in plaats van op een permanente lijst met sleutels.

Hoe servers worden geconfigureerd om de CA te vertrouwen

Aan de serverzijde is de verandering gering. De openbare sleutel van de certificeringsinstantie (CA) wordt op elke host geplaatst en sshd wordt geïnformeerd dat deze moet worden vertrouwd met behulp van de TrustedUserCAKeys-richtlijn, waarbij een AuthorizedPrincipalsFile certificaatprincipals koppelt aan toegestane lokale accounts. Er kunnen ook hostcertificaten worden uitgegeven, zodat clients niet langer de prompt 'vertrouwen bij eerste gebruik' hoeven te accepteren, iets wat de meeste gebruikers blindelings doen. Omdat authenticatie met openbare sleutels parallel kan lopen tijdens de overgang, kan de migratie stapsgewijs plaatsvinden in plaats van in één keer abrupt.

Werkbelastingidentificatie met SPIFFE en SPIRE

Certificaten bieden een oplossing voor het formaat van de inloggegevens, maar ze beantwoorden op zichzelf niet de diepere vraag hoe een workload bewijst wat het is voordat er inloggegevens worden uitgegeven. Dit is waar SPIFFE, het Secure Production Identity Framework for Everyone, en de bijbehorende referentie-implementatie SPIRE in beeld komen. Beide zijn afstudeerprojecten van de Cloud Native Computing Foundation.

SPIFFE kent aan elke workload een gestructureerde identiteit toe, de SPIFFE ID, uitgedrukt als een URI zoals spiffe://prod.acme.com/billing/api. Een SPIFFE-compatibel systeem geeft een kortstondige authenticatiecode uit, het SPIFFE Verifiable Identity Document (SVID), dat een X.509-certificaat of een JWT kan zijn. Het belangrijkste architectonische principe is dat de workload geen authenticatiegeheim mee-implementeert. In plaats daarvan inspecteert de lokale agent de aantoonbare eigenschappen van de workload, zoals de Kubernetes-namespace, het serviceaccount of de containerimage, en geeft pas daarna een identiteit uit. De SPIFFE-documentatie beschrijft hoe, om de risico's van een gelekte of gecompromitteerde sleutel te minimaliseren, alle privésleutels en certificaten een korte levensduur hebben, regelmatig worden geroteerd en automatisch worden geroteerd.

SPIRE beheert de levenscyclus. Een centrale SPIRE-server ondertekent en verstrekt SVID's, terwijl lichtgewicht SPIRE-agents op elk knooppunt workloads verifiëren en referenties ophalen. Cruciaal is dat de verlenging onzichtbaar is voor de applicatie. De SPIRE-agent vernieuwt SVID's halverwege hun geldigheidsperiode, waardoor een certificaat van één uur elke dertig minuten automatisch wordt vernieuwd en gecachede referenties geldig blijven tijdens een korte storing. De beveiligingsberekening is de kern van de zaak: een gecompromitteerde referentie van één uur heeft een maximale blootstellingsperiode van zestig minuten, terwijl een referentie van één jaar een blootstellingsperiode van 8,760 uur heeft.

Waar SSH en SPIFFE elkaar ontmoeten

De twee benaderingen vullen elkaar aan. In plaats van te vertrouwen op statische SSH-sleutels, kan een SPIFFE-compatibele implementatie kortstondige certificaten uitgeven voor toegang tot de infrastructuur, doorgaans via een SSH-server of -client die certificaten valideert die zijn ondertekend door een CA die wordt beheerd door SPIRE, of door een SPIFFE-identiteit in te wisselen voor tijdelijke SSH-referenties. Dit vermindert het risico op gecompromitteerde sleutels en vereenvoudigt het sleutelbeheer door de statische sleutel volledig te elimineren. Voor geautomatiseerde taken kan een door SPIRE uitgegeven JWT-SVID zelfs worden uitgewisseld met een cloudidentiteitsservice zoals AWS STS om kortstondige referenties per taak te verkrijgen, zonder permanente privileges toe te kennen aan gedeelde CI-agents.

Wat statische SSH-sleutels u daadwerkelijk kosten

Inzicht in de oorzaken van de tekortkomingen van de huidige situatie maakt duidelijk waarom de migratie de moeite waard is.

Risico	Waarom het gebeurt?	consequentie
Verlaten en verouderde sleutels	SSH-sleutels verlopen nooit en worden zelden ingetrokken wanneer medewerkers vertrekken of van functie veranderen.	Voormalige werknemers en contractanten behouden vaak ongeregistreerde, en soms bevoorrechte, toegang tot gegevens, lang na hun vertrek.
Schaduwtoegang	Ingenieurs genereren ad hoc sleutels zonder goedkeuringsproces.	Toegang met privileges omzeilt centraal identiteitsbeheer en ontwijkt controles.
Zijwaartse beweging	Vertrouwensrelaties tussen systemen vormen onbewaakte netwerken van vertrouwen.	Met één gecompromitteerde sleutel kan een aanvaller toegang krijgen tot meerdere systemen.
Geen verantwoording	Sleutels hebben geen identiteit en verbindingen zijn niet aan een persoon gebonden.	Forensisch onderzoek en incidentafhandeling verlopen traag en leveren geen uitsluitende resultaten op.
Blootstelling aan naleving	Niet-beheerde sleutels schenden de principes van minimale bevoegdheden en toegangscontrole.	Bevindingen onder GDPR, PCI DSS, HIPAAen soortgelijke regimes.

Stedelijke wildgroei is de norm, niet de uitzondering.

De omvang van het tekort aan adequate inventarisatie is opvallend. Onderzoek van Keyfactor en het Ponemon Institute toonde aan dat ongeveer 57 procent van de organisaties geen nauwkeurige inventarisatie van hun SSH-sleutels heeft. Een veel geciteerd onderzoek van het Ponemon Institute uit 2014, in opdracht van Venafi, wees uit dat organisaties gemiddeld zo'n 23,000 SSH-sleutels bezitten, waarvan de overgrote meerderheid niet beheerd wordt en geen vervaldatum, MFA (Multi-Factor Authentication) of auditlogboek heeft. Hetzelfde onderzoek van Keyfactor/Ponemon meldde dat ongeveer 53 procent van de organisaties geen gecentraliseerd systeem heeft en afhankelijk is van handmatige processen, zoals spreadsheets, voor het beheer van SSH-sleutels. Deze aanpak is niet schaalbaar en is foutgevoelig.

De normeringsinstantie heeft zich er al over uitgesproken.

Dit is geen probleem dat door de leverancier is veroorzaakt. In 2015 publiceerde NIST het rapport NISTIR 7966, Security of Interactive and Automated Access Management Using Secure Shell (SSH) , waarin wordt gewaarschuwd dat SSH-toegangsrechten doorgaans de bevoegdheden verhogen, vaak tot root-niveau, en dat er een aantal kwetsbaarheden ontstaan ​​als er geen adequate procedures voor provisioning, beëindiging en monitoring worden geïmplementeerd. Het rapport merkt op dat veel organisaties niet eens weten hoeveel SSH-sleutels ze hebben geconfigureerd of wie de kopieën ervan beheert.

Uitdagingen bij migratieplanning

De overstap naar kortstondige identiteiten brengt een eigen operationele discipline met zich mee, en het is beter om dit vooraf te erkennen. De centrale autoriteit wordt kritieke infrastructuur: de beschikbaarheid van de SPIRE-server is van belang, en hoewel agents lokaal referenties cachen om korte storingen op te vangen, moet het uitgifteproces zeer betrouwbaar zijn. Er is ook daadwerkelijk integratiewerk nodig. Identiteiten die tijdens de implementatie worden uitgegeven, zijn steeds vaker afkomstig uit CI/CD-systemen, en een framework dat uw buildplatforms niet native authenticeert, kan teams terugdringen naar langlopende join-tokens, waardoor het probleem dat de migratie juist moest oplossen, zich herhaalt. Ten slotte moeten auditlogs van elke referentie-uitgifte naar een SIEM worden verzonden, zodat afwijkende uitgiften kunnen worden gedetecteerd.

Migreren zonder de automatisering te onderbreken

Een pragmatische migratie zorgt ervoor dat de werkzaamheden zo worden gepland dat de waarde snel wordt gerealiseerd en de risico's beperkt blijven.

1. Stel eerst de voorraad samen: Je kunt niet buiten gebruik stellen wat je niet kunt zien. Gebruik agentgebaseerde en agentloze detectie om elke SSH-sleutel op servers en gebruikerscomputers te lokaliseren, eigendom en laatst gebruikte gegevens vast te leggen en achtergebleven sleutels te markeren. Houd detectie en herstel strikt gescheiden, omdat productieautomatisering vaak afhankelijk is van slecht gedocumenteerde sleutels en het verwijderen van de verkeerde sleutel back-ups, implementaties of noodtoegang kan verstoren. Encryption Consulting's SSH beveiligd Dit systeem voert precies deze ontdekking uit, zowel met als zonder agent, waarbij eigendoms- en laatstgebruikte gegevens worden vastgelegd, zodat achtergebleven sleutels ter beoordeling worden voorgelegd in plaats van blindelings te worden verwijderd.
2. Zet een certificeringsinstantie op en maak parallel vertrouwen mogelijk: Configureer hosts om de CA te vertrouwen via TrustedUserCAKeys, terwijl de bestaande authenticatie met publieke sleutels behouden blijft. Dit maakt de overgang stapsgewijs en omkeerbaar.
3. Integreer de uitgifte met uw identiteitsaanbieder: Koppel de uitgifte van certificaten aan single sign-on en multifactorauthenticatie, zodat een menselijk verzoek een certificaat voor de sessieduur oplevert en groepslidmaatschap wordt gekoppeld aan serverrollen. Het toevoegen of verwijderen van een gebruiker bij de identiteitsprovider wordt vervolgens automatisch doorgevoerd in de SSH-toegang.
4. Migreer eerst de workloads met de breedste privileges van statische sleutels naar andere systemen: Voor service- en automatiseringsaccounts implementeert u SPIFFE/SPIRE, zodat workloads geattesteerde, automatisch roterende SVID's ontvangen. Begin met de workloads met de meest uitgebreide machtigingen, documenteer het auditspoor als bewijs van naleving en breid vervolgens uit naar VM's en bare-metal hosts met behulp van node-attestors.
5. Beperk de reikwijdte en geldigheidsduur van certificaten: Beperk de principes strikt, stel de geldigheidsduur in op de kortst mogelijke periode die het werk niet verstoort en pas bronbeperkingen of forceer opdrachten toe waar nodig. Vermijd de meest voorkomende fout, namelijk het behandelen van een certificaat als een permanente sleutelvervanging terwijl de principes, het vertrouwen van de uitgever of de geldigheidsduur onbeperkt blijven.
6. Instrument en monitor: Verzend SVID- en certificaatuitgiftelogboeken naar uw SIEM, ontvang waarschuwingen bij uitgiften die niet overeenkomen met de verwachte selectoren en controleer vertrouwensbundels en CA-rotaties volgens een vast schema. SSH Secure centraliseert deze monitoring en verzendt uitgiftelogboeken naar Splunk- of Loki-Grafana-dashboards met ingebouwde anomaliedetectie.
7. Bewust buiten bedrijf stellen: Zodra een workload volledig is gemigreerd, verwijdert u de oude sleutels gefaseerd via configuratiebeheer tijdens een onderhoudsvenster en observeert u direct daarna het gedrag van de applicatie.

Wat elk beveiligingsteam ermee wint

De overstap van statische sleutels naar kortstondige workload-identiteiten raakt verschillende functies, elk met een eigen belang.

• CISO's Een meetbare vermindering van de permanente toegang tot de productieomgeving bereiken en een verdedigbaar antwoord geven op de auditvraag wie toegang heeft tot de productieomgeving en hoe lang.
• Beveiligingsarchitecten SSH-toegang kan worden geïntegreerd in een coherent zero-trust-model waarin elk verzoek wordt geverifieerd, afgebakend en aan een tijdslimiet gebonden, in plaats van te worden verleend door een statisch bestand.
• PKI- en cryptografieteams Breid de bestaande discipline voor de levenscyclus van certificaten uit naar SSH, waarbij SSH-certificaten onder hetzelfde beheer vallen als TLS en codeondertekening.
• DevSecOps-teams Verwijder ingebedde privésleutels uit runners en pipelines en vervang ze door per-taak-referenties die verlopen wanneer de taak is voltooid.
• Cloud- en IAM-teams De identiteit van workloads uniformeren over clusters en accounts heen, door geverifieerde identiteiten uit te wisselen voor kortstondige cloudtokens in plaats van statische referenties te distribueren.
• Infrastructuur ingenieurs Stop met het onderhouden van authorized_keys-bestanden in de hele vloot en laat hosts in plaats daarvan vertrouwen op een autoriteit en een beleidsbeslissing.

Hoe SSH Secure SSH-sleutelbeheer implementeert

Bij Encryption Consulting begrijpen we de uitdagingen waar bedrijven voor staan ​​bij het beheren van SSH-sleutels op grote schaal. SSH Secure is ontwikkeld om end-to-end beveiliging van de sleutellevenscyclus en uitgebreid inzicht te bieden, zodat organisaties sleutels met vertrouwen en zonder extra complexiteit kunnen beheren. Zo helpt het:

1. Gecentraliseerde zichtbaarheid en eigendomsregistratie: Door een combinatie van agentgebaseerde en agentloze ontdekking, SSH beveiligd Het systeem lokaliseert alle SSH-sleutels op alle servers en gebruikerscomputers. Alle sleutels worden opgeslagen in één centrale inventaris met details over eigenaarschap en gebruik, waardoor er geen sleutels meer overblijven, de verspreiding van sleutels wordt beperkt en volledige verantwoording binnen de omgeving wordt gewaarborgd.
2. Beveiligde toegangscontrole en sessiegebonden sleutels: Gedetailleerde, op rollen gebaseerde toegangscontrole (RBAC) zorgt ervoor dat gebruikers alleen het minimaal vereiste toegangsniveau krijgen. Voor gevoelige of tijdelijke bewerkingen geeft SSH Secure tijdelijke, sessiegebonden sleutels uit die automatisch verlopen. Samen zorgen deze controles ervoor dat het principe van minimale bevoegdheden wordt nageleefd en dat de gevolgen van een eventueel gecompromitteerde inloggegevens minimaal zijn.
3. Geautomatiseerde orkestratie van de levenscyclus van sleutels: SSH Secure automatiseert de volledige levenscyclus van sleutels, inclusief beveiligde generatie, beleidsgestuurde rotatie, geplande vervaldatum en intrekking. Levenscyclusbeheer elimineert zwakke of verouderde sleutels, vermindert menselijke tussenkomst en zorgt voor continue naleving van best practices in de branche.
4. HSM-geïntegreerde beveiliging: Alle privésleutels worden beveiligd in HSM's, waardoor ze niet-exporteerbaar en fraudebestendig zijn. De sleutels worden gegenereerd met behulp van sterke cryptografische algoritmen zoals... RSA-4096, ECDSA en Ed25519, wat zorgt voor sterke bescherming en weerstand tegen brute-force-aanvallen.
5. Beleidsgestuurde controle voor belangrijke operationele processen: Alle belangrijke bewerkingen, waaronder generatie, goedkeuringsworkflows, rotatie en intrekking, worden afgedwongen via beleidsgestuurde controles. Dit zorgt voor consistentie binnen de gehele omgeving, vermindert handmatige fouten en handhaaft de beveiligingsnormen voor de hele organisatie. Beleidsregels kunnen worden aangepast aan wettelijke vereisten of worden afgestemd op interne governancemodellen.
6. Continue monitoring, audits en paraatheid voor naleving: SSH Secure biedt realtime monitoring van belangrijke activiteiten met gedetailleerde gebeurtenisregistratie en ingebouwde anomaliedetectie. Logboeken kunnen worden geïntegreerd met Splunk- of Loki-Grafana-dashboards voor geavanceerde visualisatie, correlatie en waarschuwingen. Flexibele auditmogelijkheden, waaronder downloadbare logboeken en gedetailleerde rapporten, geven beveiligingsteams een duidelijk inzicht in het gebruik van belangrijke gegevens en de algehele beveiligingsstatus. Gecentraliseerde auditing met op beleid gebaseerde waarschuwingen maakt proactief beveiligingsbeheer, snelle anomaliedetectie en een snellere incidentrespons mogelijk.

Conclusie

Statische SSH-sleutels blijven bestaan ​​omdat ze vertrouwd zijn en omdat ze individueel gezien onschadelijk lijken. Gezamenlijk vormen ze een van de grootste pools van onbeheerde bevoorrechte toegang binnen moderne bedrijven, onaangetast door vervaldatum, multifactorauthenticatie of audits. Het alternatief is niet langer experimenteel. Kortstondige SSH-certificaten, uitgegeven via single sign-on, en geverifieerde workload-identiteiten, uitgegeven via SPIFFE en SPIRE, stellen een organisatie in staat permanente sleutels te vervangen door referenties die bewijzen wat een workload is, toegang verlenen zolang dat nodig is en zichzelf automatisch vernieuwen.

De overgang van statische SSH-sleutels naar kortstondige workload-identiteiten is in wezen een verschuiving van op bezit gebaseerd vertrouwen naar een geverifieerde, tijdsgebonden identiteit. Begin met ontdekking, schakel parallel vertrouwen in zodat de migratie veilig en omkeerbaar is, en migreer eerst uw workloads met de hoogste privileges. Beschouw SSH-toegang als een identiteit die beheerd moet worden in plaats van een geheim dat opgeslagen moet worden, en de referentie die voorheen voor altijd geldig was, wordt er een die verloopt voordat er misbruik van kan worden gemaakt.