De ultieme gids om SSH-sleutelspreiding te voorkomen

Een incidentresponsteam in een productieomgeving wist ooit een gecompromitteerde bastionhost te herleiden tot één enkele SSH-privésleutel. Vervolgens ontdekten ze dat diezelfde sleutel werd vertrouwd op 41 andere servers in drie cloudaccounts. Niemand in het team kon zeggen waarom. Dat is SSH-sleutelspreiding: niet één slechte sleutel, maar dezelfde toegang die stilletjes wordt gekopieerd, gekloond en achtergelaten, totdat een organisatie geen idee meer heeft hoeveel werkende kopieën van haar eigen toegangspoort er bestaan.

Gepubliceerd: januari 2025. Bijgewerkt: augustus 2026. Beoordeeld door het SSH Key Management-team van Encryption Consulting.

Wat is SSH-sleutelverspreiding en hoe ontstaat dit binnen een organisatie?

SSH-sleutelwildgroei treedt op wanneer het aantal vertrouwde SSH-sleutels in een omgeving sneller groeit dan iemand het kan bijhouden, meestal door duplicatie in plaats van door nieuwe, unieke toegangsrechten. Een enkele sleutel wordt opgenomen in een gouden image en gekloond naar 200 automatisch geschaalde instanties. Een ontwikkelaar genereert een nieuw sleutelpaar voor elke nieuwe laptop en trekt de oude sleutels nooit in. Bij een migratie wordt een volledig authorized_keys-bestand van een oude jumphost naar een nieuwe gekopieerd zonder dat iemand controleert of elke vermelding er nog steeds thuishoort. Geen van deze acties lijkt op zichzelf een beveiligingsrisico. Samen zorgen ze er echter voor dat een beheersbare set inloggegevens in de loop van enkele jaren verandert in duizenden bijna identieke kopieën van dezelfde toegang.

Dit verdient onderscheid van twee verwante problemen die in hetzelfde straatje liggen. Onbeheerde SSH-sleutels beschrijven een governance-lacune: een sleutel bestaat zonder toegewezen eigenaar, zonder directorylink en zonder toezicht vanaf dag één. Eigendomsmapping, behandeld in onze handleiding voor SSH-sleuteleigendom vóór een toegangsbeoordeling , is het auditproces waarbij aan elke bestaande sleutel een verantwoordelijke eigenaar wordt toegewezen. Sprawl is weer iets anders. Een sprawlende sleutel kan een perfect identificeerbare eigenaar hebben en toch een probleem vormen, omdat hetzelfde sleutelmateriaal naar veel meer locaties is gekopieerd dan de eigenaar daadwerkelijk nodig heeft, of omdat drie generaties sleutels voor dezelfde persoon tegelijkertijd actief zijn. De oplossing voor sprawl is niet alleen "vind de eigenaar". Het is "vind elke kopie, bepaal welke nog nodig zijn en stop met kopiëren".

Voor een volledig overzicht van hoe ontdekking, beleid, provisioning, rotatie en audit samenhangen, raadpleegt u onze uitgebreide handleiding voor het beheer van de levenscyclus van SSH-sleutels . Dit artikel gaat dieper in op de vraag waarom het aantal sleutels uit de hand loopt en hoe u dit kunt terugdringen.

Waar vindt de splitsing in eigendom gedurende de levenscyclus, die tot wildgroei leidt, nu eigenlijk plaats?

Wildgroei ontstaat zelden door één dramatische mislukking. Het komt voort uit kleine, op zichzelf redelijke beslissingen die worden genomen op verschillende momenten in de levenscyclus van de SSH-sleutel, waarbij niemand de verantwoordelijkheid draagt ​​voor de overdracht. Vier patronen zijn hiervoor grotendeels verantwoordelijk.

• Gouden beeld duplicatie. Een SSH-sleutel is ingebed in een basis-VM-image of containersjabloon, zodat nieuwe instanties automatisch kunnen opstarten. Elke kloon van die image is een nieuwe host die exact dezelfde privésleutel vertrouwt. Een team dat 15 tot 20 nieuwe instanties per maand bouwt op basis van hetzelfde sjabloon, kan binnen twee jaar die ene sleutel op duizenden hosts laten vertrouwen, zonder dat er een verband is tussen de oorspronkelijke provisioningbeslissing en de huidige configuratie.
• Overdracht van aannemer en project. Een aannemer krijgt SSH-toegang tot een bastionhost voor een migratieproject van zes weken. Het project eindigt, het contract loopt af en de toegangscontrole die de achtergebleven sleutel had kunnen opsporen, vindt niet plaats omdat niemand de taak "toegang voor het project verwijderen" op zich heeft genomen. Acht maanden later blijkt uit een beveiligingsaudit dat dezelfde publieke sleutel nog steeds wordt vertrouwd op elf bastionhosts in drie cloudaccounts.
• De vervanging van laptops en andere apparaten verloopt traag. Ingenieurs genereren een nieuw SSH-sleutelpaar telkens wanneer ze een nieuwe laptop krijgen, zich bij een nieuw team aansluiten of een nieuwe ontwikkelomgeving opzetten, en ze trekken de oude sleutels zelden in. Vermenigvuldig dat met een dienstverband van vijf jaar en een normale hardwarevernieuwingscyclus, en één persoon kan de bron zijn van drie of vier nog steeds actieve, functioneel redundante sleutels.
• Fusie en migratie van belangrijke bedrijfsonderdelen. Wanneer een bedrijf een ander bedrijf overneemt, of migreert van het ene identiteitssysteem naar het andere, brengt de nieuwe omgeving een eigen set SSH-sleutels met zich mee. In plaats van de toegang te consolideren onder één identiteit per persoon, is de snelste manier om "alles werkend te houden" om beide sleutelsystemen naast elkaar actief te laten. Zo beschikt dezelfde persoon over twee actieve sleutels die dezelfde toegang tot de productieomgeving verlenen via twee verschillende beheerspaden.

Wat deze vier patronen gemeen hebben, is een ontbrekende overdracht: een punt in het proces waar iemand had moeten vragen: "Moet deze sleutel nog steeds bestaan, of is het een duplicaat van toegang die we al hebben verleend?", maar niemand deed dat, omdat er in geen enkele stap van de workflow een specifieke verantwoordelijke voor die vraag was aangewezen.

Welke rotatietriggers hadden deze sleutels moeten verwijderen, en waarom is dat niet gebeurd?

De meeste organisaties hebben al gebeurtenissen die bedoeld zijn om SSH-sleutelrotatie of -verwijdering te activeren. Het probleem is niet dat deze triggers niet bestaan, maar dat ze wel worden geactiveerd, maar dat er vervolgens niets mee gebeurt.

1. Het verlaten van een dienstverband. De HR-afdeling deactiveert het gebruikersaccount, de IT-afdeling trekt de single sign-on in, en de SSH-sleutel die dezelfde persoon jaren eerder op een tiental servers had geautoriseerd, blijft precies waar hij is, omdat deze in eerste instantie nooit aan een directoryrecord was gekoppeld.
2. Afronding van contract of project. Het toegangsbewijs dat is verstrekt, heeft een startdatum en vaak geen formele einddatum, waardoor er geen systeemgebeurtenis wordt geactiveerd wanneer het project is afgerond.
3. Het buitenbedrijf stellen van de server of het overstappen naar een ander platform. Een host wordt buiten gebruik gesteld, maar het authorized_keys-bestand, inclusief alle sleutels daarin, wordt in zijn geheel gekopieerd naar de image van de vervangende host in plaats van opnieuw opgebouwd te worden vanuit een schone, actuele toegangslijst.
4. Gepland rotatiebeleid. Een schriftelijk beleid schrijft periodieke sleutelrotatie voor, maar rotatie is afhankelijk van iemand die handmatig alle locaties vindt waar een sleutel wordt vertrouwd en deze overal tegelijk vervangt. Deze taak krijgt echter minder prioriteit zodra er een risico bestaat dat een productieafhankelijkheid wordt verbroken waar niemand aan wil komen.

Het SSH-risicoonderzoek van Venafi, gebaseerd op een analyse van meer dan 14 miljoen SSH-clientsleutels en 3.3 miljoen SSH-hostsleutels, in combinatie met een enquête onder meer dan 550 CIO's, bracht de kern van het probleem direct aan het licht: 96% van de organisaties gaf aan een beleid te hebben dat vereist dat SSH-sleutels worden verwijderd wanneer een medewerker wordt ontslagen of van functie verandert, maar 40% zei dat ze de geautomatiseerde tools missen om dit daadwerkelijk uit te voeren. Het beleid bestaat. De trigger wordt geactiveerd. De handhaving ontbreekt, en elke keer dat deze stap ontbreekt, neemt de wildgroei toe met één extra sleutel die had moeten worden verwijderd maar dat niet is gebeurd.

Welk ontwerp van toegangsbeleid voorkomt daadwerkelijk toekomstige wildgroei?

Het aanpakken van de huidige wildgroei en het voorkomen van de toekomstige zijn twee verschillende problemen. Beleidsontwerp is essentieel om te voorkomen dat het aantal inwoners na een opruiming weer toeneemt. Vier ontwerpkeuzes zijn daarbij van het grootste belang.

• Verstrek sleutels per identiteit, nooit per team of per taak. Een sleutel die is gekoppeld aan één specifieke persoon of serviceaccount en die nooit met een groep wordt gedeeld, betekent dat elke toegangstoekenning op precies één plek kan worden gecontroleerd en op één plek kan worden ingetrokken.
• Stel bij uitgifte van elke sleutel een vervaldatum of een verplichte controledatum in. SSH-sleutels verlopen niet vanzelf, dus de vervaldatum moet een beleids- en workflowbeslissing zijn die wordt afgedwongen via het provisioning-systeem in plaats van aan het geheugen te worden overgelaten.
• Verbied sleutels die in gouden images zijn ingebouwd zonder een herbouwstap op een kloon. Als een sjabloon bootstrap-referenties moet bevatten, moet de image-pipeline bij de eerste opstart een nieuwe sleutel genereren in plaats van één statische privésleutel te gebruiken voor elke kloon.
• Leid elk verzoek om SSH-toegang door een goedkeuringsproces dat is gekoppeld aan een zakelijke rechtvaardiging. NIST IR 7966, de belangrijkste federale richtlijn voor de beveiliging van SSH-toegang, adviseert dat elk toegangsverzoek de rechtvaardiging ervan documenteert, de betrokken accounts en hosts specificeert en wordt beoordeeld op beëindiging wanneer het niet langer nodig is. Dat goedkeuringsdocument maakt beslissingen over het verwijderen van duplicaten later ook verdedigbaar: je kunt een echt benodigde sleutel onderscheiden van een overgebleven sleutel, omdat je de oorspronkelijke rechtvaardiging hebt om deze aan te toetsen.

Geen van deze controles vereist geavanceerde tools. Ze vereisen dat de uitgifte van sleutels een geregistreerde, goedgekeurde gebeurtenis wordt in plaats van een lokale, ad-hocgebeurtenis, en dat is precies de stap die de meeste organisaties overslaan onder tijdsdruk.

Hoe ernstig is de wildgroei aan SSH-sleutels bij u? Een beslissingstabel

Voordat u een herstelstrategie kiest, is het nuttig om te weten hoe ernstig de huidige situatie daadwerkelijk is. Gebruik de sectoroverschrijdende gemiddelden van Venafi als referentiepunt voor wat "typisch" is en vergelijk uw eigen cijfers daarmee.

Indicator	Lage bebouwing	Matige spreiding	Ernstige wildgroei
Dubbele privésleutels per server	0	1 tot 2 (het branchegemiddelde is 2)	3 of meer
Weessleutels op root- of beheerdersniveau	0 in het hele landgoed	Ongeveer 1 op de 10 servers	1 of meer per server (gemiddelde in de branche)
Sleutels die al meer dan 12 maanden niet zijn geroteerd.	Minder dan 10% van het vermogen	10% tot 30%	Meer dan 30%
Tijd om de eigenaar van een sleutel te benoemen en de rechtvaardiging daarvoor te geven.	Binnen 1 dag, uit een actuele voorraad.	1 tot 5 dagen, op basis van gedeeltelijke registraties.	Kan geen antwoord geven, of alleen vanuit een spreadsheet.

Een organisatie die in meerdere rijen in de kolom 'ernstig' staat, heeft niet te maken met een opschoontaak die in dagen wordt gemeten. Het gaat om een ​​programma: ontdekking, deduplicatie en beleidshandhaving die parallel draaien, en daar is de onderstaande workflow op gebaseerd.

Welk auditbewijs toont aan dat de aanpak van de stedelijke wildgroei daadwerkelijk effectief was?

Een saneringsproject dat geen bewijs kan leveren, is een saneringsproject dat een auditor op goed geloof moet aannemen. Het bewijs dat daadwerkelijk standhoudt, is kwantitatief en toont trends over een bepaalde periode, niet een eenmalige verklaring als "we hebben het opgeruimd".

• Totaal aantal sleutels in de loop van de tijd, De gegevens zijn afkomstig uit hetzelfde onderzoeksgebied en worden volgens een vast schema verzameld, waardoor de neerwaartse trendlijn zichtbaar is in plaats van een enkele momentopname van voor en na.
• Aantal dubbele sleutels, Met name het aantal verschillende privésleutels dat op meer hosts wordt vertrouwd dan waarvoor ze in de documentatie zijn opgegeven.
• Aantal wees- en niet-beheerde sleutels, Deze worden apart bijgehouden van duplicaten, omdat een sleutel uniek kan worden ingezet zonder dat er een verantwoordelijke eigenaar is.
• Tijdstip van herroeping, Gemeten vanaf het moment dat de trigger voor het buitenbedrijf stellen van het systeem wordt geactiveerd tot het moment dat elke kopie van de betreffende sleutel daadwerkelijk is verwijderd, niet alleen het primaire systeem.
• Dekking voor goedkeuring van voorzieningen, Het percentage van de momenteel actieve sleutels dat terug te voeren is op een gedocumenteerd, goedgekeurd verzoek in plaats van een niet-geregistreerde lokale actie.

Compliancekaders zoals PCI DSS, NIST SP 800-53, ISO 27001 en SOC 2 vereisen allemaal dat organisaties controle over bevoorrechte toegang aantonen. Een auditor die vraagt ​​wie op een bepaald moment toegang had tot een productiesysteem, heeft deze gegevens nodig; ze hoeven niet onder tijdsdruk te worden gereconstrueerd.

Hoe kun je de bestaande wildgroei aan SSH-sleutels inperken en terugdraaien?

Als er eenmaal sprake is van wildgroei, is de volgorde van de herstelmaatregelen van belang. Direct overgaan tot verwijdering is de manier waarop opruimprojecten de productie verstoren en halverwege vastlopen.

1. Inventariseer eerst alles, en alleen de inventaris. Scan elke server, cloud-instantie, container en gebruikerswerkstation op geautoriseerde sleutels met behulp van zowel agentgebaseerde als agentloze detectiemethoden, aangezien geen van beide methoden op zichzelf het volledige systeem dekt. ​​Registreer de vingerafdruk van elke sleutel, elke host waarop deze wordt vertrouwd en het tijdstempel van het laatste gebruik. Verwijder in dit stadium niets.
2. Verwijder duplicaten op basis van de vingerafdruk, niet op basis van bestandsnaam of opmerking. Groepeer alle hosts die dezelfde privésleutel vertrouwen. Dit is waar de wildgroei zichtbaar wordt als een getal: een sleutel met één rechtmatige eigenaar die op 200 hosts vertrouwd blijkt te zijn, terwijl de taak slechts toegang tot 6 vereist, is nu een concrete, bruikbare bevinding in plaats van een vaag vermoeden.
3. Consolideer naar één sleutel per identiteit per doel. Voor elke persoon of serviceaccount moet u overbodige, overlappende sleutels samenvoegen tot één actuele sleutel en de rest formeel buiten gebruik stellen. Als een sleutel door een golden image op meerdere hosts is gedupliceerd, moet u de image-pipeline aanpassen zodat toekomstige klonen bij de eerste opstart een unieke sleutel genereren in plaats van de oude sleutel over te nemen.
4. Voer elke verwijdering uit via een onderhoudsvenster, verwijder deze nooit direct. Schakel de sleutel eerst uit in plaats van hem te verwijderen, controleer op defecte automatisering of mislukte aanmeldingen en verwijder de sleutel pas volledig wanneer er niets meer van afhankelijk is. Een sleutel die niemand herkent, is precies het soort sleutel dat stilletjes een back-uptaak ​​of een verouderde integratie in leven houdt.
5. Handhaaf het beleid voor de toewijzing van voorraden om te voorkomen dat het aantal weer oploopt. Leid nieuwe sleutelaanvragen door de eerder beschreven goedkeuringsworkflow, uitgifte-regel per identiteit en vervalbeleid, zodat het ontdubbelen niet na achttien maanden hoeft te worden herhaald.
6. Stel een terugkerend ritme in voor het ontdekken en evalueren van resultaten. Stedelijke wildgroei is geen project met een einddatum; het is een accumulatieproces dat onder het tempo van de sanering moet worden gehouden. Minimaal driemaandelijkse herontdekking voorkomt dat de inventaris veroudert zoals de eerste keer.

Handmatige opschoning versus geautomatiseerde detectie en deduplicatie: welke methode werkt daadwerkelijk op grote schaal?

Beide benaderingen kunnen in principe de bovenstaande workflow uitvoeren. Ze lopen echter sterk uiteen zodra het aantal hosts de paar honderd overschrijdt.

Afmeting	Handmatige opschoning (spreadsheets, scripts, periodieke controles)	Geautomatiseerde tools voor het opsporen en verwijderen van duplicaten
Tijd om een ​​volledige, actuele inventaris op te bouwen.	Weken tot maanden, en dan vrijwel meteen weer muf.	Continue, vrijwel realtime, op het hele terrein
duplicatendetectiemethode	Het is afhankelijk van iemand die handmatig een patroon opmerkt.	Vergelijkt automatisch elke sleutel met elke host via een vingerafdruk.
De hoofdoorzaak is aangepakt.	Verwijdert bestaande duplicaten eenmaal	Dwingt per-identiteit-provisioning af, zodat er geen nieuwe duplicaten meer ontstaan.
Auditbewijs geproduceerd	Momentopname van een spreadsheet op een bepaald tijdstip	Continue logboekregistratie en exporteerbare trendrapporten
Praktische schaal plafond	Het valt weg bij een paar honderd hosts.	Ontworpen voor tienduizenden hosts en sleutels.

Handmatig opruimen is geen verspilde moeite. Het is vaak de enige realistische manier om de eerste inventarisatie uit te voeren in een omgeving waar dat nog nooit is gebeurd. Maar als je het als de permanente oplossing beschouwt, belandt dezelfde organisatie twee jaar later weer in de categorie 'ernstige wildgroei' van de beslissingstabel, omdat er niets is gedaan om te voorkomen dat er nieuwe duplicaten ontstonden terwijl het spreadsheet werd opgebouwd.

Wat gebeurt er als wildgroei wordt ontdekt tijdens een incident, en niet tijdens een audit?

De kosten van wildgroei zijn het gemakkelijkst te overzien achteraf, tijdens een incident dat een snelle inventarisatie van sleutels afdwingt waar niemand op voorbereid was. CVE-2024-31497, dat in april 2024 werd onthuld, is een nuttige casestudy. De kwetsbaarheid betrof een probleem met de generatie van een vertekende nonce in PuTTY-versies 0.68 tot en met 0.80, waardoor ECDSA-bewerkingen die gebruik maakten van de NIST P-521-curve werden getroffen. Het probleem trof ook tools die dezelfde PuTTY-bibliotheek gebruikten, waaronder FileZilla, WinSCP, TortoiseGit en TortoiseSVN. Elke organisatie die een getroffen client gebruikte, moest elke P-521-sleutel die mogelijk was blootgesteld identificeren en intrekken op alle locaties waar die sleutel werd vertrouwd, niet alleen op de host waar de client draaide.

In een omgeving zonder wildgroei betekent dat het controleren van één sleutel aan de hand van een bekende, korte lijst met hosts. In een wildgroeiomgeving kan dezelfde sleutel gedupliceerd zijn in een gouden image-lijn die honderden instanties omvat, waarvan niemand zich herinnert dat ze van het origineel zijn gekloond. De reactie op de kwetsbaarheid zelf kost in dat scenario geen tijd. Het vinden van elke kopie kost wel tijd. Dat is de operationele kosten van wildgroei die een beslissingstabel of een compliance-checklist niet volledig weergeeft: het verandert een afgebakende, goed begrepen patchtaak in een zoektocht zonder einde.

Beperkingen

Deduplicatie en geautomatiseerde detectie zijn op zichzelf geen complete oplossing. Scannen met agents kan geen systemen bereiken die niet met het internet verbonden zijn of offline zijn, zonder daar direct detectieagents op te installeren, wat in sommige omgevingen niet mogelijk is. Het consolideren van sleutels brengt altijd een klein risico met zich mee dat een ongedocumenteerde afhankelijkheid wordt verbroken. Daarom moet gefaseerde verwijdering via een onderhoudsvenster, in plaats van directe verwijdering, onderdeel blijven van het proces, ongeacht hoe goed de tools zijn. Geautomatiseerde tools vervangen ook niet de organisatorische beslissing om een ​​functie voor beleidshandhaving te financieren en te bemensen; ze nemen het excuus weg dat handhaving technisch onhaalbaar is, maar iemand moet nog steeds verantwoordelijk zijn voor het programma. Ten slotte vermindert de overstap van statische, langlevende sleutels naar kortlevende of certificaatgebaseerde SSH-toegang de toekomstige wildgroei aanzienlijk, maar het is een architectuurwijziging die applicatie- en automatiseringsupdates vereist, geen instelling die in een middag kan worden aangepast.

Wat zou Encryption Consulting aanbevelen?

Begin met een volledige, agentgebaseerde en agentloze inventarisatie voordat u ook maar één sleutel aanraakt. De meeste pogingen om een ​​wildgroei aan sleutels op te lossen mislukken niet omdat de opschoonlogica onjuist is, maar omdat er al wordt begonnen met verwijderen voordat de inventarisatie is voltooid. Hierdoor gaat er iets mis dat had kunnen worden opgelost. Zodra de inventarisatie compleet is, kunt u de sleutels prioriteren op basis van het aantal duplicaten en het privilege-niveau: een sleutel die op 40 hosts met root-toegang is gedupliceerd, heeft een hogere prioriteit dan een sleutel die op 3 hosts met alleen-leestoegang is gedupliceerd, zelfs als de tweede ouder is.

Ons SSH Secure- platform is gebouwd rond deze exacte volgorde. Het combineert agentgebaseerde en agentloze detectie om een ​​continu actuele inventaris op te bouwen, vergelijkt sleutels op elke host met behulp van fingerprint-matching om automatisch duplicaten te detecteren, dwingt per identiteit beleidsgestuurde provisioning af zodat er geen nieuwe duplicaten meer ontstaan, en slaat privésleutels op in HSM's om de blootstelling aan lokale bestanden te elimineren die ervoor kan zorgen dat één gecompromitteerde laptop uitgroeit tot een incident in de hele vloot. Continue monitoring levert gegevens aan Splunk of Grafana Loki, zodat het eerder beschreven auditbewijs – sleuteltellingen, trends in duplicaten en de tijd tot intrekking – een vast rapport is in plaats van een noodprocedure vóór elke controle.

Als uw organisatie nog niet precies weet hoe ernstig de wildgroei aan encryptie is, kunnen onze adviesdiensten op het gebied van encryptie een eerste inventarisatie uitvoeren en u helpen bij het opstellen van een plan met prioriteiten voor de oplossing van de problemen, voordat u zich vastlegt op een platform.

Conclusie

SSH-sleutelwildgroei ontstaat wanneer handige, goedbedoelde snelkoppelingen – zoals het klonen van een gouden image, het kopiëren van een authorized_keys-bestand en het genereren van een nieuwe sleutel in plaats van de oude op te sporen – zich in de loop der jaren opstapelen zonder dat er ooit wordt gecontroleerd of de duplicaatsleutel daadwerkelijk nodig was. De oplossing is niet een eenmalige actie. Het vereist een actuele inventarisatie, een deduplicatieproces waarbij vingerafdrukovereenkomsten als uitgangspunt worden genomen, consolidatie tot één sleutel per identiteit per doel en een provisioningbeleid dat voorkomt dat het aantal sleutels weer oploopt nadat de opruiming is voltooid. Organisaties die dit goed aanpakken, transformeren een open, op spreadsheets gebaseerd gokspel in een kleine set cijfers – aantal duplicaten, aantal weessleutels, tijd tot intrekking – die ze op aanvraag kunnen rapporteren in plaats van ze onder tijdsdruk te moeten reconstrueren.

Veelgestelde Vragen / FAQ

Is een wildgroei aan SSH-sleutels hetzelfde als onbeheerde SSH-sleutels?
Nee. Onbeheerde SSH-sleutels duiden op een governance-lacune: een sleutel zonder toegewezen eigenaar en zonder toezicht. Sprawl duidt op volume en duplicatie: dezelfde toegang gekopieerd naar veel meer systemen dan nodig, ongeacht of elke kopie technisch gezien een eigenaar heeft. Veel omgevingen hebben beide problemen tegelijk, maar ze vereisen verschillende oplossingen; zie onze handleiding voor onbeheerde SSH-sleutels voor het bestuurlijke aspect.

Hoeveel dubbele SSH-sleutels zijn normaal in een bedrijfsomgeving?
Uit een analyse van Venafi van meer dan 14 miljoen SSH-clientsleutels bleek dat bedrijven gemiddeld 2 dubbele privésleutels en 1 gedeelde privésleutel per server hebben, samen met gemiddeld meer dan 7,000 root-toegangssleutels zonder geldige sleutel, oftewel ongeveer één per server. Elk aantal dat significant boven deze basislijn ligt, met name op geprivilegieerde of productiehosts, is reden voor een extra controle.

Kun je de wildgroei aan SSH-sleutels tegengaan door ze te roteren?
Nee. Rotatie vervangt het materiaal van een sleutel volgens een schema; het spoort geen dubbele exemplaren van die sleutel op die op andere hosts staan, en het voorkomt ook niet dat er nieuwe duplicaten ontstaan ​​door hetzelfde gebrekkige provisioningproces dat in de eerste plaats tot de wildgroei heeft geleid. Rotatie is één van de vele beheersmaatregelen, geen vervanging voor inventarisatie, deduplicatie en het afdwingen van beleid.

Hoe lang duurt een project om de wildgroei aan SSH-sleutels op te lossen doorgaans?
De eerste fase van het opsporen van duplicaten in een middelgrote bedrijfsomgeving duurt doorgaans enkele weken met geautomatiseerde tools, en langer met handmatige scripts en spreadsheets. Deduplicatie en gefaseerde consolidatie beslaan meestal één tot twee kwartalen, omdat verwijderingen gefaseerd moeten plaatsvinden via onderhoudsvensters om te voorkomen dat ongedocumenteerde afhankelijkheden worden verbroken. Het handhaven van beleid dat herhaling voorkomt, is een continu proces en geen project met een einddatum.

Zal de overstap naar kortstondige of certificaatgebaseerde SSH-toegang de wildgroei van netwerken verhelpen?
Het vermindert de snelheid waarmee nieuwe systemen zich uitbreiden aanzienlijk, omdat vluchtige, sessiegebonden inloggegevens niet lang genoeg bewaard blijven om te worden gekopieerd naar een gouden image of vergeten te worden nadat een project is afgerond. Het ruimt niet met terugwerkende kracht een bestaande verzameling lang bestaande sleutels op en vereist het bijwerken van applicaties en automatisering die momenteel uitgaan van statische sleutelbestanden. Het is daarom een ​​betekenisvol architectuurproject in plaats van een snelle beleidswijziging.

Referenties

• NIST IR 7966, Beveiliging van interactief en geautomatiseerd toegangsbeheer met behulp van Secure Shell (2015)
• NIST SP 800-57 Deel 1 Rev. 5, Aanbeveling voor sleutelbeheer (2020)
• NVD, Details van CVE-2024-31497 (PuTTY-gebaseerde, bevooroordeelde ECDSA-noncegeneratie, bekendgemaakt in april 2024)
• Venafi, CIO's onderschatten de risico's van SSH aanzienlijk., SSH-risicobeoordeling van meer dan 14 miljoen client-sleutels en 3.3 miljoen host-sleutels in een enquête onder meer dan 550 CIO's (2021)
• Help Net Security, Slecht beheer van SSH-sleutels en machine-identiteiten stelt organisaties bloot aan onnodige risico's. (2021)