Onbeheerde SSH-sleutels vormen uw grootste beveiligingslek op het gebied van bevoorrechte toegang.

Een CISO kan doorgaans elke wachtwoordkluis, elk MFA-beleid en elke tool voor het vastleggen van geprivilegieerde sessies die in de omgeving actief is, opnoemen. Vraag dezelfde CISO echter hoeveel SSH-sleutels root- of beheerdersrechten verlenen op de servers, en het antwoord zal vrijwel altijd een schatting zijn. Die lacune is geen probleem met de zichtbaarheid dat het beveiligingsteam over het hoofd heeft gezien. Het is een structurele blinde vlek die inherent is aan de manier waarop de meeste Privileged Access Management (PAM)-programma's zijn ontworpen.

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

Dit is een specifiekere vraag dan alleen de wildgroei aan SSH-sleutels of het sleutelbezit. De wildgroei aan SSH-sleutels is een volumeprobleem: te veel sleutels, gedupliceerd op te veel systemen. Het bezit van SSH-sleutels is een procesprobleem: hoe koppel je elke sleutel terug aan een persoon of service voordat een toegangscontrole plaatsvindt. Dit artikel gaat over het risico: waarom onbeheerde SSH-sleutels buiten de toegangsbeheersystemen vallen waarover beveiligingsmanagers al rapporteren, wat de kosten zijn als het misgaat en hoe SSH in hetzelfde beheermodel kan worden opgenomen als alle andere geprivilegieerde referenties. Voor het volledige stappenplan, van ontdekking tot intrekking, raadpleegt u onze uitgebreide handleiding voor het beheer van de levenscyclus van SSH-sleutels.

Waarom creëren onbeheerde SSH-sleutels een blinde vlek in PAM?

De meeste PAM-platformen zijn gebouwd rond een specifiek model van bevoorrechte toegang: een mens of een service haalt een inloggegeven uit een kluis, gebruikt het voor een afgebakende sessie en de sessie wordt vastgelegd. Dat model werkt goed voor wachtwoorden, databaseaanmeldingen en RDP-sessies. Het beschrijft echter niet hoe SSH-sleutels in de meeste bedrijven daadwerkelijk functioneren.

Een SSH-publieke sleutel die in het authorized_keys-bestand van een server is geplaatst, wordt direct vertrouwd zodra deze wordt toegevoegd, ongeacht een kluis, directory of autorisatiesysteem. De server roept geen PAM-broker aan om te controleren of de verbindingssleutel nog steeds geautoriseerd is. De server vergelijkt de aangeboden privésleutel met de publieke sleutel die al wordt vertrouwd, en als deze overeenkomen, wordt toegang verleend. Dit maakt SSH efficiënt voor automatisering en lastig voor beheer: de toegangsbeslissing wordt eenmaal genomen, tijdens de provisioning, en niets in het protocol controleert deze later opnieuw.

PAM- en Identity and Access Management (IAM)-systemen zien identiteiten doorgaans via een directory, zoals Active Directory of een door een identiteitsprovider (IdP) uitgegeven token. SSH-sleutels worden vaak lokaal gegenereerd, handmatig of via scripts gedistribueerd en nooit centraal geregistreerd. Een sleutel kan root-toegang verlenen tot een productieserver zonder ooit in aanraking te komen met de systemen waarnaar uw compliance-team verwijst wanneer een auditor vraagt ​​hoe bevoorrechte toegang wordt beheerd. Dat is de blinde vlek: niet dat SSH onveilig is, maar dat het werkt met een parallel vertrouwensmodel waar de meeste PAM-programma's niet op zijn ontworpen.

Wat is het bedrijfsrisico van onbeheerde, bevoorrechte SSH-toegang?

Het bedrijfsrisico is niet abstract. Het komt op drie plaatsen naar voren waar beveiligingsleiders al over rapporteren: de kosten van een inbreuk, de groei van de markt die bedoeld is om inbreuken te voorkomen, en gedocumenteerde incidenten waarbij toegang via SSH het toegangspunt was.

De investeringen in PAM nemen toe. MarketsandMarkets voorspelt dat de wereldwijde PAM-markt zal groeien van 2.9 miljard dollar in 2023 naar 7.7 miljard dollar in 2028, een samengestelde jaarlijkse groei van 21.5%, grotendeels gedreven door de adoptie van cloudtechnologie en het risico van geprivilegieerde accounts. Deze uitgaven duiden erop dat besturen en CISO's geprivilegieerde toegang steeds meer beschouwen als een prioriteit waarvoor budget wordt vrijgemaakt, in plaats van een post die kan worden uitgesteld. Het probleem is echter dat een groot deel van deze uitgaven naar tools voor kluis- en sessiebeheer gaat die niet zijn ontworpen om vertrouwensrelaties tussen SSH-sleutels te ontdekken of te beheren. Dit betekent dat een organisatie haar PAM-budget aanzienlijk kan verhogen, terwijl haar SSH-omgeving nog steeds onvoldoende wordt beheerd.

De kosten van een datalek blijven stijgen, zelfs nu de totale kosten van een datalek dalen. IBM's Cost of a Data Breach Report 2025 toonde aan dat de gemiddelde kosten van een datalek wereldwijd daalden tot 4.44 miljoen dollar, de eerste daling in vijf jaar. De gemiddelde doorlooptijd van een datalek, oftewel de tijd die nodig is om een ​​incident te identificeren en in te dammen, bedraagt ​​echter nog steeds 241 dagen. Onbeheerde SSH-sleutels verlengen die doorlooptijd specifiek. Wanneer een sleutel niet is gekoppeld aan een gedocumenteerde eigenaar, kan een incidentresponder niet snel vaststellen van wie de sleutel was, waartoe deze toegang had moeten bieden, of het gebruik ervan tijdens het incident normaal of kwaadwillig was. Die onduidelijkheid is precies wat een ingedamd incident verandert in een onderzoek van 241 dagen.

SSH-gegevens zijn al in de praktijk de toegangspoort gebleken tot incidenten, niet alleen in theoretische gevallen. GoDaddy onthulde dat een onbevoegde persoon toegang had gekregen tot inloggegevens voor SSH-verbindingen met een deel van hun hostingaccounts. Deze inbreuk begon in oktober 2019 en werd pas ongeveer zes maanden later, in april 2020, ontdekt. ​​Volgens een rapport van Solutions Review werden minder dan 30,000 accounts getroffen . De detectiekloof in dat incident, maandenlang onopgemerkte toegang via SSH-gegevens, is kenmerkend voor het patroon dat onbeheerde sleutels mogelijk maken: toegang die ongemerkt voortduurt omdat er in de omgeving niets is dat controleert of deze wordt beëindigd.

Waar komen de hiaten in het eigendom van SSH-sleutels gedurende hun levenscyclus vandaan?

Eigendomslacunes vormen de hoofdoorzaak van de meeste bovengenoemde risico's. Een sleutel zonder gedocumenteerde eigenaar kan niet met een gerust hart worden vervangen, ingetrokken of aan een auditor worden uitgelegd, omdat niemand kan zeggen of het verwijderen ervan iets kapot zal maken. Drie patronen creëren deze lacunes steevast:

• Zelfbedieningsgeneratie. Ontwikkelaars en engineers genereren sleutelparen rechtstreeks op hun eigen machines om verbinding te maken met een staging-server of een eenmalige taak uit te voeren. De sleutel blijft bestaan ​​nadat de taak is voltooid, omdat iemand zich moet herinneren dat de sleutel bestaat voordat deze verwijderd kan worden.
• Serviceaccounts zonder menselijke sponsor. CI/CD-pipelines, back-uptaken en configuratiebeheertools bevatten allemaal sleutels die zijn uitgegeven aan de automatisering zelf, en niet aan een persoon die verantwoordelijk is voor het controleren of die automatisering nog steeds toegang nodig heeft.
• Geërfde landgoederen. Fusies, overnames en reorganisaties van teams zorgen ervoor dat beveiligingsteams te maken krijgen met een belangrijke groep mensen die ze niet zelf hebben aangewezen en die ze niet kunnen controleren op basis van vastgelegde intenties.

Bij het vertrek van een medewerker komen deze hiaten aan het licht. Het uitschakelen van het account van een vertrokken medewerker heeft geen invloed op de SSH-sleutels die die medewerker maanden of jaren eerder over servers heeft verspreid, omdat SSH-vertrouwen lokaal op elke host wordt afgedwongen, niet centraal via de directory. Vaststellen wie de eigenaar is van elke sleutel en die toewijzing actueel houden naarmate rollen veranderen, is een aparte discipline die losstaat van de risicoanalyse in dit artikel. Onze handleiding voor het in kaart brengen van alle geprivilegieerde SSH-referenties vóór uw volgende toegangsbeoordeling behandelt dit tactische proces uitgebreid.

Welke rotatietriggers worden niet afgedwongen in onbeheerde omgevingen?

Het rotatiebeleid op papier komt zelden overeen met de rotatie in de praktijk wanneer sleutels niet worden beheerd. NIST IR 7966 beveelt gedefinieerde cryptoperioden aan voor SSH-sleutels, met kortere intervallen voor accounts met hoge privileges en geautomatiseerde accounts, maar een cryptoperiode werkt alleen als controlemechanisme als er daadwerkelijk iets is dat deze afdwingt. In de praktijk worden vier triggers het vaakst niet afgedwongen:

1. Geplande vervaldatum. Standaard gebruikerssleutels moeten volgens een vast schema worden vernieuwd, meestal om de paar maanden, met kortere cycli voor beheerders- en serviceaccountsleutels. Zonder geautomatiseerde handhaving is geplande vernieuwing afhankelijk van iemand die eraan denkt, wat niet schaalbaar is voor meer dan een handvol servers.
2. Functieverandering of vertrek. Zodra iemand van functie verandert of vertrekt, moeten alle sleutels die die persoon bezit, worden ingetrokken. Dit is de trigger die het vaakst over het hoofd wordt gezien bij offboardingprocessen, omdat het intrekken van SSH-toegang zelden is geïntegreerd in de HR- of IAM-offboardingworkflow.
3. Openbaarmaking van kwetsbaarheden. Wanneer een kwetsbaarheid een sleuteltype of een bibliotheek voor sleutelgeneratie aantast, moeten alle getroffen sleutels snel worden vervangen. CVE-2024-31497, een kwetsbaarheid in de generatie van misleidende nonces in PuTTY-versies 0.68 tot en met 0.80 die ECDSA-bewerkingen op de NIST P-521-curve beïnvloedt, dwong organisaties die de getroffen tools gebruikten (waaronder FileZilla, WinSCP en TortoiseGit, die de kwetsbare bibliotheek bevatten) om elke P-521-sleutel die door die tools was aangeraakt te identificeren en te vervangen. Organisaties zonder een complete sleutelinventaris konden die reactie niet snel genoeg uitvoeren. handleiding voor de wildgroei aan SSH-sleutels gaat dieper in op de onderliggende kwetsbaarheid.
4. Vermoedelijke inbreuk. Elke aanwijzing dat een privésleutel mogelijk is gelekt, via een verloren apparaat, een blootgestelde opslagplaats of een gecompromitteerd eindpunt, moet leiden tot onmiddellijke vervanging van die sleutel en een controle van alle locaties waar deze werd vertrouwd. Onbeheerde omgevingen kunnen vaak niet voldoen aan het tweede deel van die eis: alle locaties waar de sleutel werd vertrouwd.

Welke lacunes in het toegangsbeleid zorgen ervoor dat onbeheerde sleutels de PAM-controles kunnen omzeilen?

Een formeel toegangsbeleid moet verifieerbaar zijn om nuttig te zijn. NIST SP 800-192, Verification and Test Methods for Access Control Policies/Models , maakt een punt dat hier direct van toepassing is: toegangscontrolesystemen falen niet alleen door slechte bedoelingen, maar ook door beleid dat niet kan worden getoetst aan wat het systeem daadwerkelijk afdwingt. De meeste SSH-omgevingen slagen niet voor die test, omdat het beleid dat er is, als er al een is, een document is en het handhavingspunt een tekstbestand op elke individuele server is.

Drie tekortkomingen komen steeds terug in onbeheerde omgevingen:

• Geen aanvraag- of goedkeuringsproces. Voor het aanmaken van sleutels is standaard geen ticket, geen goedkeuring van een manager en geen beveiligingscontrole nodig. Dit betekent dat sleutels volledig buiten de goedkeuringsprocessen worden toegevoegd die uw PAM- en IAM-tools normaal gesproken voor elke authenticatiebron vereisen.
• Geen beperkingen qua omvang. NIST IR 7966 beveelt aan om te beperken wat een geautomatiseerde sleutel kan uitvoeren, door middel van commando- en bronbeperkingen in authorized_keys. De meeste sleutels worden geïmplementeerd met onbeperkte shelltoegang, omdat de beperking handmatig moet worden geconfigureerd en handmatige stappen onder tijdsdruk vaak worden overgeslagen.
• Er is geen onderscheid tussen toegangsbeleid voor mensen en machines. Toegang tot de productieomgeving, de ontwikkelomgeving en serviceaccounts verloopt vaak via hetzelfde informele pad naar sleutelaanmaak. Daardoor is een beleid dat voor één context is opgesteld, standaard van toepassing op alle drie.

Welke auditbewijzen hebt u nodig om aan te tonen dat u controle hebt over bevoorrechte SSH-toegang?

Compliancekaders zoals PCI DSS , NIST SP 800-53 , ISO 27001 en SOC 2 vereisen allemaal dat organisaties controle over bevoorrechte toegang aantonen, en niet alleen beweren dat ze die controle hebben. Voor SSH betekent dit specifiek dat ze vijf dingen op aanvraag moeten kunnen leveren:

• Een volledig overzicht van elke SSH-sleutel in de omgeving, inclusief de vingerafdruk, het algoritme en de status ervan.
• Elke sleutel heeft een gedocumenteerde eigenaar, gekoppeld aan een specifieke persoon of serviceaccount met een aantoonbare zakelijke rechtvaardiging.
• Een registratie van de goedkeuring waaruit blijkt wie de toegang heeft verleend en wanneer.
• Een overzicht van de rotatie en het laatst gebruikte tijdstip voor elke toets, waaruit blijkt dat deze nog steeds actief en nodig is.
• Een intrekkingsbewijs waaruit blijkt dat de toegang is verwijderd toen een persoon vertrok of een systeem buiten gebruik werd gesteld.

Wanneer auditors vragen wie op een bepaald moment toegang had tot een productiesysteem, is het eerlijke antwoord in een onbeheerde omgeving een schatting gebaseerd op serverlogs, en niet op een rapport uit een officieel systeem. Die lacune maakt van een routineaudit een wekenlange zoektocht naar bewijsmateriaal, en het is precies dit soort bewijsmateriaal dat PAM-programma's gefinancierd worden om te verzamelen voor alle andere soorten certificeringen.

Hoe los je problemen op met onbeheerde SSH-sleutels? Een stappenplan in vijf stappen.

Het dichten van deze kloof is geen eenmalig opruimproject. Het is een workflow die continu moet draaien, omdat er sneller nieuwe sleutels worden aangemaakt dan handmatige controles ze kunnen bijhouden.

1. Ontdekken. Scan elke server, cloudworkload, container en gebruikersendpoint met behulp van zowel agentgebaseerde als agentloze methoden. Agentgebaseerde scanning bereikt systemen die u direct beheert; agentloze scanning dekt systemen waar geen agent kan worden geïnstalleerd. Samen leveren ze een complete inventaris op die handmatige audits niet kunnen bieden.
2. Classificeren. Sorteer gevonden sleutels op basis van privilege-niveau (root of beheerder versus standaardgebruiker), functie (interactieve menselijke toegang versus geautomatiseerde servicetoegang) en blootstelling (internetgericht versus alleen intern). Niet elke sleutel brengt hetzelfde risico met zich mee, en door ze identiek te behandelen, wordt er onnodig tijd besteed aan het oplossen van problemen met sleutels met een laag risico, terwijl sleutels met een hoog risico moeten wachten.
3. Eigendom toewijzen. Koppel elke sleutel aan een verantwoordelijke persoon of service-eigenaar. Sleutels die niet binnen een bepaalde periode aan een gedocumenteerde eigenaar kunnen worden gekoppeld, moeten standaard als hoog risico worden beschouwd en niet het voordeel van de twijfel krijgen.
4. Handhaaf het beleid. Pas rotatieschema's, beperkingen voor opdrachten en bronnen, en goedkeuringsworkflows toe, zodat nieuwe sleutels in de reeds beheerde omgeving terechtkomen in plaats van de achterstand te vergroten.
5. Continu monitoren. Houd het sleutelgebruik bij, markeer inactieve sleutels die gedurende een bepaalde periode niet zijn geverifieerd en ontvang waarschuwingen wanneer nieuwe sleutels buiten de goedgekeurde workflow worden toegevoegd. Discovery is geen project met een einddatum; het is de controle die ervoor zorgt dat de andere vier stappen correct verlopen.

Traditioneel PAM versus speciaal SSH-sleutelbeheer: welke oplossing dekt daadwerkelijk onbeheerde sleutels?

Het uitbreiden van een bestaande PAM-implementatie en het gebruik van een speciaal SSH-sleutelbeheerplatform sluiten elkaar niet uit, maar ze lossen wel verschillende aspecten van dit probleem op. De onderstaande tabel laat zien wat de precieze impact van elke aanpak is.

Bekwaamheid	Traditioneel PAM (Vault and Session Model)	Speciaal SSH-sleutelbeheer
Ontdekt sleutels die al buiten de kluis zijn geïmplementeerd	Zelden; PAM ziet wat er is ingecheckt, niet wat er op de schijf staat.	Ja, door middel van agentgebaseerde en agentloze scans op servers, endpoints en in de cloud.
Geeft het eigenaarschap weer voor sleutels die buiten een aanvraagworkflow zijn aangemaakt.	Geen inheems mechanisme	Ja, het in kaart brengen van eigendomsrechten is een essentieel resultaat van de ontdekkingsfunctie.
Dwingt rotatie af voor sleutels die niet in de kluis zijn geregistreerd.	Nee; niet-geregistreerde sleutels zijn onzichtbaar voor het rotatiebeleid.	Ja, beleidsgestuurde rotatie is van toepassing op de volledige ontdekte inventaris.
Geeft kortstondige, sessiegebonden inloggegevens uit	Ja, voor beveiligde wachtwoorden en beheerde sessies.	Ja, via tijdelijke, aan de sessie gebonden SSH-sleutels.
Beschermt privésleutels in hardware.	Afhankelijk van de integratie; vaak optioneel	Native HSM-ondersteunde generatie en opslag
Genereert SSH-specifiek auditbewijs (vingerafdruk, vertrouwenskaart, laatste gebruik).	Beperkt tot wat via de kluis was geregeld.	Ja, in de gehele ontdekte sleutelpopulatie.

De praktische conclusie is dat PAM de inloggegevens beheert die het kent. SSH-sleutelbeheer is er om de gegevens te vinden en te beheren die het niet kent, wat voor de meeste bedrijven het grootste deel van het sleutelbestand is.

Heeft u behoefte aan speciaal SSH-sleutelbeheer? Een beslissingstabel

Signaal in uw omgeving	Wat het betekent	Aangeraden actie
De beveiligingsafdeling kan het totale aantal SSH-sleutels dat dagelijks in productie is niet bekendmaken.	Er bestaat geen gecentraliseerd ontdekkingssysteem.	Geef prioriteit aan onderzoek boven beleidsvorming of rotatieplanning.
Offboardingtickets bevatten geen stap voor het intrekken van de SSH-sleutel.	SSH is losgekoppeld van IAM/HR-offboarding.	Integreer het intrekken van sleutels in de bestaande offboarding-workflow en automatiseer dit vervolgens.
Een auditor heeft eerder al aangegeven dat SSH-toegang niet verifieerbaar is.	Het tekort aan auditbewijs is reeds gedocumenteerd.	Stel de vijfdelige bewijsset samen (inventaris, eigendom, goedkeuring, rotatiegeschiedenis, intrekkingsregistratie).
CI/CD-, back-up- of automatiseringsaccounts beschikken over langdurige, niet-geroteerde sleutels.	Serviceaccount-sleutels vormen het segment met de hoogste privileges en de minste controle.	Geef prioriteit aan deze voor vervanging door tijdelijke of certificaatgebaseerde oplossingen.
De PAM-implementatie omvat wachtwoorden en RDP, maar SSH werd uitgesteld naar "fase twee".	Een structurele lacune, geen tijdelijke, gezien de manier waarop SSH-vertrouwen werkt.	Overweeg nu al het beheer van specifieke SSH-sleutels, in plaats van te wachten op een PAM-uitbreidingsproject.

Wat kost een incident met een SSH-sleutel nu eigenlijk?

De kosten van een SSH-gerelateerd incident lopen op een specifieke manier op: detectie is traag omdat geldige, op sleutels gebaseerde aanmeldingen geen authenticatiefouten veroorzaken, en het vaststellen van de omvang van het incident is traag omdat de organisatie vaak niet kan vaststellen welke systemen de gecompromitteerde sleutel vertrouwen. Beide problemen zijn terug te voeren op dezelfde onderliggende oorzaak als alle bovenstaande, namelijk een ongecontroleerde sleutelpopulatie zonder eigenaar en zonder centraal register.

Tegen de achtergrond van een gemiddelde datalekcyclus van 241 dagen en een gemiddelde datalekkosten van 4.44 miljoen dollar (IBM, 2025), is de operationele rekensom eenvoudig: elke dag die wordt toegevoegd aan de detectie- en analysetijd, verhoogt beide cijfers. Een beheerde sleutelinventaris voorkomt incidenten niet, maar elimineert wel de twee variabelen die de duur ervan het meest verlengen – onduidelijk eigenaarschap en onvolledige vertrouwensmapping – volledig uit de reactieprocedure. Voor de volledige technische reactieprocedure zodra is bevestigd dat een sleutel is blootgesteld, raadpleegt u onze handleiding voor incidentrespons bij blootgestelde SSH-sleutels.

Beperkingen

Enkele belangrijke kanttekeningen moeten duidelijk worden vermeld. De hier genoemde rotatiefrequenties zijn algemene richtlijnen, geen universele voorschriften; het juiste interval hangt af van uw risicotolerantie, wettelijke verplichtingen en de gevoeligheid van wat een bepaalde sleutel beschermt. Tijdelijke, sessiegebonden sleutels verminderen het risico aanzienlijk, maar ze zijn niet altijd haalbaar voor legacy-systemen, omgevingen zonder internetverbinding of apparaten van leveranciers die alleen statische sleutelbestanden ondersteunen. Detectietools, of ze nu agentgebaseerd zijn of niet, hebben hun eigen dekkingslacunes; agentloze scans kunnen sleutels missen op systemen waar ze niet mee kunnen authenticeren, en agentgebaseerde scans zijn afhankelijk van de implementatie van de agent op alle benodigde locaties. En geen enkel SSH-sleutelbeheerprogramma vervangt de noodzaak van beveiliging op hostniveau, netwerksegmentatie en MFA waar SSH dit ondersteunt; het beheren van de sleutels is noodzakelijk, maar op zichzelf niet voldoende.

Wat zou Encryption Consulting aanbevelen?

Voor een CISO die evalueert waar SSH past in een bestaande PAM-strategie, is ons advies duidelijk: wacht niet tot een PAM-leverancier dit hiaat opvult als een toekomstig roadmap-item. SSH-sleutels authenticeren per definitie buiten het vault-and-session-model, en dat is iets wat een PAM-platform niet achteraf zal implementeren zonder een speciale discovery- en governance-laag eronder.

Ons SSH Secure- platform is specifiek ontwikkeld om deze lacune op te vullen. Het combineert agentgebaseerde en agentloze detectie om een ​​complete inventaris op te bouwen, koppelt elke sleutel aan een verantwoordelijke eigenaar en dwingt rotatie en intrekking af via beleid in plaats van handmatige processen. Privésleutels worden gegenereerd en opgeslagen in Hardware Security Modules (HSM's) met behulp van RSA-4096, ECDSA en Ed25519, zodat sleutelmateriaal nooit onbeschermd op een werkstation of in een configuratiebestand wordt bewaard. Voor gevoelige bewerkingen kan SSH Secure tijdelijke, sessiegebonden sleutels uitgeven die automatisch verlopen. Dit is het dichtstbijzijnde SSH-equivalent van het brokered session-model dat PAM-teams al gebruiken voor wachtwoorden. Realtime monitoring, anomaliedetectie en downloadbare auditlogboeken, met integratie in Splunk of Grafana Loki, bieden beveiligingsteams de vijfdelige bewijsset waar auditors om vragen, zonder dat handmatige verzameling nodig is.

Het resultaat is geen vervanging voor uw PAM-programma. Het is de ontbrekende laag die ervoor zorgt dat het governance-model van uw PAM-programma daadwerkelijk kan worden uitgebreid naar SSH, waarmee een hiaat wordt gedicht dat de meeste bedrijfsbrede strategieën voor geprivilegieerde toegang jarenlang ongemerkt hebben meegedragen.

Conclusie

Onbeheerde SSH-sleutels zijn geen bijzaak in uw strategie voor bevoorrechte toegang. Ze vormen een structurele lacune, ontstaan ​​doordat SSH-authenticatie plaatsvindt buiten het kluis-en-sessiemodel waarop de meeste PAM-programma's zijn gebouwd. Deze lacune komt tot uiting in auditbevindingen die niet kunnen worden beantwoord, incidentonderzoeken die maanden in plaats van dagen duren, en een gedocumenteerde geschiedenis van datalekken, van GoDaddy tot talloze kleinere, niet-gerapporteerde incidenten, waarbij SSH-gegevens het toegangspunt vormden.

Het dichten van dit probleem vereist niet dat u uw PAM-investering vervangt. Het vereist dat u dezelfde governance-discipline, detectie, eigendom, beleid en auditbewijs toepast op een type inloggegevens waarvoor uw bestaande tools nooit zijn ontworpen. Organisaties die SSH-sleutels behandelen als beheerde, geprivilegieerde inloggegevens in plaats van statische configuratiebestanden, dichten deze lacune permanent. Organisaties die dit niet doen, zullen er steeds weer mee geconfronteerd worden tijdens hun volgende audit, hun volgende incident of hun volgende bestuursvergadering over waarom het PAM-budget het risico dat iedereen aannam niet dekte.

FAQ

Is SSH-sleutelbeheer onderdeel van PAM, of staat het daar los van?
SSH-sleutelbeheer is een aparte discipline die onderdeel moet uitmaken van uw bredere PAM-strategie, en deze niet mag vervangen. PAM beheert de opgeslagen, via een broker beheerde referenties; SSH-sleutelbeheer ontdekt en beheert de op sleutels gebaseerde vertrouwensrelaties die buiten de kluis bestaan. Volwaardige beveiligingsprogramma's gebruiken beide, waarbij SSH-sleutelgegevens dezelfde audit- en rapportagelaag voeden als de rest van PAM.

Kunnen we er gewoon voor zorgen dat alle SSH-toegang via onze bestaande PAM-kluis verloopt?
Je kunt dit in de toekomst vereisen voor nieuw toegewezen toegang, maar dat beleid heeft geen invloed op de sleutels die al in je omgeving waren geïmplementeerd voordat het beleid bestond. Die sleutels authenticeren nog steeds rechtstreeks via authorized_keys-bestanden zonder dat er een kluis in het pad staat. Daarom moet de detectie voorafgaan aan de handhaving.

Hoe kunnen we het bestuur overtuigen van de kosten van een speciaal SSH-sleutelbeheersysteem?
Vergelijk het met wat de raad van bestuur al financiert: de investeringen in PAM (Private Access Management) groeien met een samengesteld jaarlijks groeipercentage van 21.5% in de hele sector (MarketsandMarkets), en het duurt nu gemiddeld 241 dagen om een ​​datalek te beheersen (IBM, 2025). Een onbeheerde SSH-omgeving is de specifieke reden waarom een ​​onderzoek naar een datalek maandenlang vastloopt, omdat onderzoekers niet snel de eigenaar of de omvang van de impact kunnen vaststellen. Het gaat erom een ​​aantoonbaar tekort in de bestaande beveiligingsuitgaven te dichten, niet om een ​​geheel nieuwe budgetpost te creëren.

Wat moeten we als eerste prioriteren als we helemaal geen inzicht hebben?
Ontdekking. U kunt geen sleutels classificeren, eigendom toewijzen, beleid afdwingen of auditbewijs genereren voor sleutels waarvan u niet weet dat ze bestaan. Voer eerst agentgebaseerde en agentloze ontdekking uit op servers, cloudworkloads en endpoints, en ga vervolgens over op eigendomstoewijzing en beleidsafdwinging zodra de inventarisatie is voltooid.

Maken tijdelijke SSH-sleutels een inventaris overbodig?
Nee. Tijdelijke, sessiegebonden sleutels verkleinen het risico dat een individuele sleutel met zich meebrengt, omdat ze na gebruik automatisch verlopen. Toch is het belangrijk om een ​​inventaris bij te houden welke systemen en accounts geconfigureerd zijn om ze te accepteren, welke oudere systemen ze nog niet ondersteunen en of er naast de tijdelijke sleutels nog statische sleutels actief zijn.

Referenties

• NIST IR 7966, Beveiliging van interactief en geautomatiseerd toegangsbeheer met behulp van Secure Shell (SSH), Oktober 2015. nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.7966.pdf
• NIST SP 800-192, Verificatie- en testmethoden voor toegangscontrolebeleid/modellen, Juni 2017. csrc.nist.gov/pubs/sp/800/192/final
• NIST SP 800-57 Deel 1 Revisie 5, Aanbeveling voor sleutelbeheer: Algemeen, Mag 2020. csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• Markten en markten, Markt voor Privileged Access Management, projectie voor de periode 2023 tot 2028. marketsandmarkets.com/Market-Reports/privileged-access-management-market-113381799.html
• IBM, Kosten van een datalekrapport 2025. ibm.com/reports/data-breach
• Oplossingenoverzicht, Het datalek bij GoDaddy: wat u moet weten. solutionsreview.com/identity-management/the-godaddy-data-breach-what-you-need-to-know
• NVD, CVE-2024-31497 Details. nvd.nist.gov/vuln/detail/CVE-2024-31497