Jouw ultieme gids voor SSH-sleutelbeheer in meerdere clouds

AWS levert een downloadbaar .pem-bestand. Azure plaatst een publieke sleutel in de authorized_keys van een enkele virtuele machine. GCP koppelt, als je OS Login inschakelt, SSH-toegang aan een IAM-identiteit in plaats van aan een sleutelbestand. Drie clouds, drie verschillende modellen voor dezelfde referenties, en de meeste beveiligingsteams ontdekken dit op de harde manier: tijdens een audit, een offboarding of een incident, wanneer niemand een overzicht kan geven van wie in welke omgeving toegang heeft via SSH.

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

Waarom is het beheren van SSH-sleutels in meerdere clouds lastiger dan in één cloud?

Het beheren van SSH-sleutels in meerdere clouds is complexer dan in één cloud, omdat er geen gedeeld beheersysteem voor SSH-sleutels is tussen AWS, Azure en GCP. Elke provider injecteert, bewaart en beheert sleutels via zijn eigen mechanisme, en geen van deze mechanismen communiceert met de andere. Een sleutel die is gegenereerd voor een AWS EC2-instantie heeft geen verband met een sleutel die is geïmplementeerd op een Azure VM of een GCP Compute Engine-instantie, zelfs niet als dezelfde engineer alle drie beheert en uit gemaksoverwegingen hetzelfde sleutelpaar hergebruikt.

Die kloof komt op drie concrete manieren aan het licht zodra een organisatie daadwerkelijk workloads op meer dan één cloud uitvoert:

• Gefragmenteerde voorraden. AWS houdt sleutelparen bij per regio en account, Azure houdt openbare sleutels bij per authorized_keys-bestand van de VM (of per Azure Key Vault-resource, als een team de moeite neemt om dat te configureren), en GCP houdt sleutels bij in project- of instantiemetadata, of in IAM als OS Login is ingeschakeld. Geen enkele console toont dit allemaal.
• Inconsistente uitgangswaarden. Een sleuteltype- en rotatiebeleid dat in AWS via een intern proces wordt afgedwongen, moet in Azure en GCP afzonderlijk en handmatig worden afgedwongen, omdat geen van de drie cloudplatformen het beleid van een ander platform voor u zal toepassen.
• Hergebruikte sleutels, geen gedeelde identiteit. Ingenieurs kopiëren doorgaans dezelfde publieke sleutel naar alle drie de clouds voor het gemak. Die sleutel heeft nu drie afzonderlijke 'blast radiuss', drie afzonderlijke intrekkingspunten en geen enkel record dat hem aan één eigenaar koppelt.

Voor een volledige uiteenzetting van wat SSH-sleutellevenscyclusbeheer inhoudt in één enkele omgeving, inclusief eigendom, rotatietriggers, toegangsbeleid en auditbewijs, raadpleegt u de uitgebreide handleiding 'SSH Key Lifecycle Management for Enterprise Security' van Encryption Consulting . Deze handleiding bouwt voort op die basis en richt zich specifiek op de veranderingen die optreden wanneer dezelfde discipline tegelijkertijd moet worden toegepast op AWS, Azure en GCP.

De data achter de wildgroei

De wildgroei aan SSH-sleutels is geen theoretisch risico. Recente analistenrapporten, onderzoek van leveranciers en brancheonderzoeken tonen aan in welke mate onbeheerde inloggegevens, waaronder SSH-sleutels, de governance hebben ingehaald:

• De verspreiding van geheimen gaat sneller dan teams het kunnen bijhouden. GitGuardian's State of Secrets Sprawl 2026 Uit een rapport, gepubliceerd op 17 maart 2026, blijkt dat er alleen al in 2025 29 miljoen nieuwe hardgecodeerde geheimen op openbare GitHub zijn blootgesteld, een stijging van 34% ten opzichte van het jaar ervoor en de grootste jaarlijkse toename die het bedrijf ooit heeft geregistreerd. In hetzelfde rapport wordt opgemerkt dat bij recente incidenten in de toeleveringsketen, waaronder het LiteLLM-incident, specifiek SSH-sleutels naast cloudreferenties zijn buitgemaakt.
• Machine-identiteiten, waaronder SSH-sleutels, zijn tegenwoordig vele malen talrijker dan menselijke accounts. CyberArk's Rapport over de stand van zaken rond machine-identiteitsbeveiliging in 2025Uit een onderzoek onder 1,200 beveiligingsmanagers bleek dat organisaties verwachten dat het aantal machine-identiteiten zal blijven toenemen en dat handmatige processen deze niet langer op grote schaal kunnen traceren, waardoor de verhouding tussen machine-identiteiten en menselijke identiteiten ongeveer 82 op 1 bedraagt.
• Inbreuken op basis van gestolen inloggegevens zijn het traagst en behoren tot de duurste om op te sporen. IBM's 2025 kosten van een datalekrapport Uit het onderzoek bleek dat datalekken die begonnen met gestolen of gecompromitteerde inloggegevens gemiddeld $4.67 miljoen kostten en dat het 246 dagen duurde om ze te identificeren en in te dammen. Dit is een van de langste datalekcycli die in het rapport worden beschreven.

Multicloudomgevingen maken al deze cijfers nog complexer, omdat dezelfde sleutel ongemerkt in drie verschillende inventarissen kan voorkomen in plaats van in één.

Hoe gaan AWS, Azure en GCP elk op hun eigen manier om met SSH-sleutels?

AWS, Azure en GCP behandelen SSH-sleuteltoegang elk als een detail op instantie- of projectniveau in plaats van een gereguleerde, centraal beheerde referentie. GCP vormt hierop een gedeeltelijke uitzondering: de OS Login-functie kan SSH-toegang koppelen aan een IAM-identiteit in plaats van een opgeslagen sleutel, iets wat AWS en Azure alleen aanbieden als aparte, optionele services bovenop hun standaard sleutelmodel.

AWS: EC2-sleutelparen

Het standaardmodel van AWS is het EC2-sleutelpaar. Wanneer u een instantie start via de console, CLI of CloudFormation, slaat AWS de openbare sleutel op bij de instantie en geeft u precies één kans om de privésleutel te downloaden. De eigen EC2-gebruikershandleiding van AWSSleutelparen zijn per regio beperkt, met een gedocumenteerde limiet van 5,000 sleutelparen per regio per account. Er is geen ingebouwd mechanisme om een ​​sleutelpaar te delen tussen regio's of accounts. AWS ondersteunt zowel RSA- als ED25519-sleuteltypen en stelt u in staat een extern gegenereerde openbare sleutel te importeren in plaats van door AWS gegenereerd materiaal te gebruiken, maar de documentatie beschrijft geen automatische rotatiemogelijkheid. Het roteren van een EC2-sleutelpaar betekent het genereren van een nieuwe sleutel en het bijwerken van de gegevens. authorized_keys op elke betreffende instantie, en het oude sleutelpaar buiten gebruik stellen, handmatig of via uw eigen automatisering.

AWS biedt ook AWS Systems Manager Session Manager aan als een op IAM gebaseerd alternatief dat de noodzaak van een opgeslagen privésleutel of een open inkomende SSH-poort wegneemt. Het is niet de standaardoptie: het vereist dat de SSM Agent op de instantie draait en een IAM-rol die de instantie toestemming geeft om met Systems Manager te communiceren. Session Manager biedt IAM-gestuurde toegang en sessielogging, maar het werkt naast EC2-sleutelparen in plaats van ze te vervangen in een omgeving waar al sleutelgebaseerde toegang is ingebouwd in scripts, images en CI/CD-pipelines.

Azure: SSH-sleutels per virtuele machine

Het standaardmodel van Azure lijkt op dat van AWS, maar is nog specifieker, namelijk gericht op de individuele virtuele machine. Per De documentatie van Microsoft over Azure Virtual MachinesJe genereert een sleutelpaar (meestal RSA of ED25519, met behulp van ssh-keygen of de az vm create --generate-ssh-keys vlag), en de publieke sleutel wordt in de VM geschreven. ~/.ssh/authorized_keys bestand bij aanmaak. De privésleutel blijft op de lokale machine die deze heeft gegenereerd en hetzelfde sleutelpaar kan worden hergebruikt in meerdere VM's. Dit vereenvoudigt de configuratie, maar betekent wel dat een gelekte privésleutel elke VM kan bereiken waarnaar deze ooit is gekopieerd. De documentatie van Microsoft zelf beschrijft geen sleutelinventaris op abonnementsniveau, geen Azure Key Vault-integratie in de standaard VM-aanmaakworkflow en geen geautomatiseerde rotatie. Een team kan Key Vault wel in een implementatiescript integreren om een ​​sleutelpaar te genereren en op te slaan, maar dit is een patroon dat je zelf moet ontwikkelen, geen standaardfunctionaliteit van Azure.

Azure's op IAM gebaseerde alternatief is Aanmelden met Microsoft Entra ID voor Linux-VM's, waarmee SSH-sessies worden geverifieerd aan de hand van Entra ID-referenties en Azure RBAC-roltoewijzingen in plaats van een statische sleutel. Net als AWS Session Manager is het een optionele functie: installatie is vereist. AADSSHLoginForLinux VM-uitbreiding, waardoor een door het systeem toegewezen beheerde identiteit mogelijk wordt en rollen zoals 'Aanmelden als beheerder van virtuele machine' kunnen worden toegewezen. Standaard SSH-authenticatie met openbare sleutels blijft de standaard van Azure, en de meeste omgevingen draaien een mix van VM's met Entra-ondersteuning en VM's die alleen met sleutels worden geverifieerd, in plaats van één consistent model.

GCP: metadata-sleutels, of OS-aanmelding gekoppeld aan IAM

GCP begint op dezelfde manier als AWS en Azure: standaard leest Compute Engine openbare SSH-sleutels uit de project- of instantie-metadata en schrijft deze weg. authorized_keys op de doel-VM, per De eigen richtlijnen van Google voor het toevoegen van SSH-sleutels aan virtuele machines.Wat GCP onderscheidt is... OS-aanmelding, een functie die op metadata gebaseerde sleutels vervangt door IAM-beheerde toegang. Met OS Login ingeschakeld, verleent een beheerder een gebruiker de roles/compute.osLogin or roles/compute.osAdminLogin In plaats van een sleutelbestand te distribueren, wordt een IAM-rol gebruikt. De documentatie van Google beschrijft continue evaluatie per sessie: wanneer een beheerder de IAM-toegang van een gebruiker intrekt, wordt de SSH-toegang van die gebruiker onmiddellijk ingetrokken, zonder dat iemand een virtuele machine of een server hoeft aan te raken. authorized_keys OS Login ondersteunt ook tweefactorauthenticatie via Google Authenticator, sms of beveiligingssleutels, en registreert verbindingspogingen voor controledoeleinden, aldus het bestand. Aanbevelingen van Google voor SSH-aanmelding.

Aanmelden bij het besturingssysteem is ook niet de standaardinstelling van GCP; deze moet worden ingeschakeld met een enable-oslogin=TRUE metadata-vlag op project- of instantieniveau, volgens Google's Installatiehandleiding voor het inloggen op het besturingssysteemHet echte verschil zit hem in wat er gebeurt als het eenmaal is ingeschakeld: OS Login regelt de SSH-toegang via hetzelfde systeem. ssh De opdracht en de standaard OpenSSH-client gebruiken IAM als bron van waarheid, zonder dat een aparte agent of extensie nodig is zoals bij AWS Session Manager en Azure Entra ID-aanmelding. Daardoor is IAM-gebaseerde SSH-toegang eenvoudiger consistent te implementeren in een GCP-omgeving dan in de andere twee cloudomgevingen, hoewel het nog steeds dezelfde zorgvuldige uitrol vereist als AWS en Azure.

Beslissingstabel: Cloudprovider versus native SSH-sleutelbeheer versus centralisatiekloof

Cloud provider	Native SSH-sleutelafhandeling	Centralisatiekloof
AWS	EC2-sleutelparen per regio; openbare sleutel opgeslagen bij het exemplaar, privésleutel eenmalig te downloaden; RSA of ED25519; tot 5,000 paren per regio; optionele IAM-gebaseerde Systems Manager Session Manager als add-on.	Geen ingebouwde rotatie; geen sleutelinventarisatie over meerdere regio's of accounts; Session Manager vereist een aparte configuratie van de SSM Agent en IAM-rol en verwijdert geen bestaande sleutelparen.
Azuur	Authorized_keys-vermeldingen per VM, gegenereerd via CLI, portal of ARM-sjabloon; herbruikbaar voor verschillende VM's; optionele Microsoft Entra ID-aanmelding voor Linux als add-on.	Er is geen inventarisatie van sleutels op abonnementsniveau gedocumenteerd; er is geen automatische rotatie; voor Entra ID-aanmelding is de AADSSHLoginForLinux-extensie en RBAC-roltoewijzing vereist bovenop het standaard sleutelmodel.
GCP	Standaard worden project- of instantiemetadatasleutels gebruikt; OS-aanmelding is beschikbaar om toegang te koppelen aan een IAM-identiteit, met continue machtigingsevaluatie en optionele tweefactorauthenticatie (2FA).	OS Login moet expliciet worden ingeschakeld; een GCP-omgeving die dit nooit inschakelt, is net zo gedecentraliseerd als AWS of Azure; OS Login zelf is niet beschikbaar voor AWS- of Azure-resources.

Elke rij in die tabel beschrijft één enkele cloud op zichzelf. Geen van de drie mechanismen – EC2-sleutelparen, Azure authorized_keys-bestanden of GCP OS-aanmelding – produceert een record dat de andere twee overspant. Dat is de centralisatiekloof die een multi-cloudprogramma bewust moet dichten, omdat geen enkele provider dat voor je doet.

Wie is verantwoordelijk voor de levenscyclus van SSH-sleutels over de grenzen van cloudomgevingen heen?

In één cloudomgeving is het eigenaarschap in theorie in ieder geval terug te voeren op degene die het sleutelpaar, de virtuele machine of de IAM-binding in dat specifieke account heeft aangemaakt. In drie verschillende clouds valt die traceerbaarheid weg, tenzij het eigenaarschap centraal en onafhankelijk van het platform waarop de betreffende sleutel zich bevindt, wordt toegewezen.

Levenscyclusfase	Een enkele cloudrealiteit	Wat breekt er door drie wolken heen?
Generatie	De engineer maakt of importeert een sleutelpaar in één console.	Hetzelfde sleutelpaar wordt vaak hergebruikt in AWS, Azure en GCP voor het gemak, waardoor één generatiegebeurtenis nu drie afzonderlijke verspreidingsgebieden heeft zonder gedeeld record.
Goedkeuring van de miner	De teamleider of de beveiligingsmedewerker beoordeelt het verzoek in de workflow van die cloudomgeving.	De goedkeuringsworkflows verschillen per cloud (IAM-beleid koppelen in AWS, RBAC-roltoewijzing in Azure, IAM-rol voor besturingssysteemaanmelding in GCP), dus er moet één goedkeuringsstandaard bovenop alle drie worden gelegd.
Provisioning	De openbare sleutel wordt opgeslagen in de metadata van die cloud, het authorized_keys-bestand of de IAM-binding.	Er is geen gedeelde API voor provisioning; een gecentraliseerde tool of gedocumenteerd draaiboek moet hetzelfde beleid via drie verschillende provisioningmechanismen implementeren.
Gebruik	De native logboekregistratie van die cloud (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) registreert de sessie.	Door de drie verschillende logformaten en bewaarbeleidsregels moeten gebruiksgegevens worden gestandaardiseerd voordat ze bruikbaar zijn voor een toegangscontrole over meerdere clouds.
Rotatie en ontmanteling	Sleutel verwijderd uit de instantie of metadata van die specifieke cloud.	Het uitdiensttreden van een engineer die toegang had tot alle drie de clouds, vereist drie afzonderlijke verwijderingsacties. Elk van deze acties kan afzonderlijk over het hoofd worden gezien, tenzij één systeem alle drie de acties activeert.

De praktische oplossing is om voor elke sleutel één verantwoordelijke eigenaar aan te wijzen, een rol in plaats van alleen een persoon, op het moment dat deze wordt aangemaakt, en vast te leggen met welke cloud(s) die sleutel verbonden is. Deze ene wijziging zorgt ervoor dat een checklist voor het verlaten van een bedrijf, of een audit, "de SSH-toegang van deze persoon" als één item in plaats van drie afzonderlijke items behandelt.

Wat zou rotatie moeten activeren, en waarom is cloud-native rotatie vaak handmatig of onvolledig?

SSH-sleutelrotatie zou in elke cloudomgeving moeten worden geactiveerd onder dezelfde drie voorwaarden: het verstrijken van de cryptoperiode, een personeels- of rolwijziging en een vermoedelijke inbreuk, conform het algemene kader in NIST IR 7966. Wat er in een multi-cloudomgeving anders is, is dat geen van de drie providers alle drie de triggers automatiseert, en dat geen van hen namens u een sleutel roteert zonder dat u die automatisering zelf implementeert.

• AWS Er is geen geplande rotatie voor EC2-sleutelparen. Rotatie betekent het genereren van een nieuw sleutelpaar en het pushen van de nieuwe publieke sleutel naar elke betreffende instantie. authorized_keys bestand (handmatig, of via Systems Manager of uw eigen configuratiebeheer) en verwijder het oude sleutelpaar uit het account. Niets in het platform herinnert u eraan dat dit nodig is.
• Azuur Hetzelfde geldt voor de virtuele machine: niets dwingt een vernieuwing af van de sleutel die zich daar bevindt. authorized_keysEn omdat hetzelfde sleutelpaar vaak voor meerdere VM's wordt gebruikt, betekent een rotatiegebeurtenis in Azure vaak dat tientallen VM's één voor één moeten worden bijgewerkt, tenzij configuratiebeheer dit afhandelt.
• GCP Metadata-sleutels gedragen zich net als de andere twee: geen automatische vervaldatum of vernieuwing. OS Login verandert de aard van het probleem in plaats van de rotatie direct op te lossen, omdat de toegang is gekoppeld aan een IAM-binding in plaats van een statische sleutel; het intrekken van de IAM-rol gebeurt vrijwel direct, wat functioneert als rotatie voor interactieve toegang door mensen, maar serviceaccountsleutels en alle nog in gebruik zijnde op metadata gebaseerde sleutels volgen hetzelfde handmatige patroon als AWS en Azure.

De praktische implicatie: een rotatiebeleid dat is opgesteld voor "SSH-sleutels" in het algemeen zal in een multi-cloudomgeving stilzwijgend falen, tenzij het per cloud precies specificeert welke actie aan dat beleid voldoet. "Sleutel roteren" betekent immers een andere reeks stappen op elk platform.

Hoe zorg je ervoor dat het toegangsbeleid consistent blijft in drie verschillende IAM-modellen?

AWS IAM, Azure RBAC en Google Cloud IAM hanteren allemaal een zodanig verschillende toegangsbeheerstructuur dat een beleidsverklaring die voor de ene is geschreven, niet direct toepasbaar is op de andere. Om een ​​consistent toegangsbeleid te garanderen, is het belangrijk om het beleid eenmaal te definiëren, in cloud-onafhankelijke termen, en het vervolgens afzonderlijk in kaart te brengen voor elk model van de provider. Dit is een betere aanpak dan te proberen één standaardbeleid te schrijven en te hopen dat het universeel toepasbaar is.

• Het principe van minimale privileges, zoals dat per platform wordt toegepast. Het beleid "Productiedatabasebeheerders krijgen SSH-toegang tot productiedatabasehosts" moet een specifiek IAM-beleid worden in AWS, een specifieke RBAC-roltoewijzing in Azure en een specifieke IAM-rol voor besturingssysteemaanmelding in GCP. Dit zijn drie afzonderlijke configuraties die hetzelfde doel nastreven.
• Bron- en commandobeperkingen. Geen van de drie cloudproviders hanteert op dezelfde manier native op platformniveau beperkingen voor bron-IP-adressen of commando's voor SSH-sessies; dergelijke beperkingen worden, indien van toepassing, doorgaans geconfigureerd in de sleutel. authorized_keys De sleutel wordt ofwel via de toegangsmethode zelf (AWS, Azure) of via de door het besturingssysteem ondersteunde inlogopties (GCP) aangeleverd. De sleutel moet dus consistent worden toegepast door het proces dat de sleutel verstrekt, en mag niet vanuit de cloud worden aangenomen.
• Scheiding van taken. De persoon die een toegangsverzoek goedkeurt, mag niet dezelfde persoon zijn die de toegang verleent. Deze regel is eenvoudig te handhaven binnen de workflow van één cloudomgeving, maar raakt snel uit het oog wanneer er drie afzonderlijke workflows naast elkaar bestaan.
• Serviceaccount en automatiseringssleutels. CI/CD-pipelines en configuratiebeheertools bevatten vaak langdurige SSH-sleutels met een breed bereik over cloudomgevingen heen; deze sleutels vereisen dezelfde, zo niet meer, beleidsdiscipline als menselijke sleutels, omdat ze continu worden gebruikt en het moeilijker is om een ​​eventuele inbreuk op te sporen.

Een cloud-agnostische laag voor SSH-sleutelbeheer, die bovenop AWS IAM, Azure RBAC en GCP IAM functioneert in plaats van een vierde, incompatibel model te zijn, maakt "één beleid, drie handhavingsopties" haalbaar in plaats van een utopie.

Hoe genereer je auditbewijs voor meerdere cloudconsoles?

Het genereren van auditbewijs voor AWS, Azure en GCP betekent dat bewijs van aanvraag, goedkeuring, provisioning, gebruik en beëindiging uit drie afzonderlijke logsystemen moet worden gehaald, genormaliseerd en gepresenteerd als één record per authenticatiegegevens in plaats van drie losse fragmenten. Frameworks zoals SOC 2, ISO/IEC 27001 en PCI DSS verwachten allemaal dat een organisatie kan aantonen dat toegang tijdig wordt gecontroleerd en ingetrokken. Een auditor die vraagt ​​"wie kon via SSH toegang krijgen tot dit systeem en dat bewijzen?", is niet geïnteresseerd in het feit dat het antwoord betrekking heeft op drie verschillende cloudomgevingen.

• AWS Het bewijsmateriaal is afkomstig van CloudTrail (API-acties met betrekking tot sleutelparen) en, waar gebruikt, van Session Manager-sessielogboeken; geen van beide registreert standaard welke persoon de privésleutel voor een bepaald EC2-sleutelpaar in handen had, alleen dat het sleutelpaar bestond en welke API-aanroepen ermee verband hielden.
• Azuur Het bewijsmateriaal is afkomstig uit het Azure-activiteitenlogboek en authenticatiegegevens op VM-niveau; omdat een sleutelpaar hergebruikt kan worden voor meerdere VM's, vereist het koppelen van een specifieke aanmeldingsgebeurtenis aan een specifieke persoon het nagaan welke privésleutel die persoon daadwerkelijk bezit, informatie die Azure zelf niet bijhoudt.
• GCP Het bewijs is het sterkst wanneer OS Login is ingeschakeld, omdat Cloud Audit Logs elke sessie dan direct koppelt aan een IAM-identiteit in plaats van een anonieme sleutel; zonder OS Login heeft de metadata-sleutelregistratie van GCP dezelfde eigendomslacune als AWS en Azure.

De oplossing is dezelfde als die voor het beheer van de levenscyclus van een licentiesleutel: wijs een eigenaar toe bij uitgifte, registreer welke cloud(s) een licentiesleutel gebruikt en voer gebruikslogboeken van alle drie de consoles in één systeem, een SIEM-platform zoals Splunk, of een speciaal SSH-sleutelbeheersysteem. Zo wordt auditbewijs continu verzameld in plaats van telkens opnieuw te moeten worden samengesteld onder tijdsdruk wanneer een auditor erom vraagt.

Een praktische workflow voor het centraliseren van SSH-sleutelbeheer in meerdere clouds.

Het centraliseren van SSH-sleutelbeheer over AWS, Azure en GCP vereist geen verwijdering van bestaande toegang of verstoring van lopende workloads. Het betekent dat detectie, beleid en automatisering worden toegevoegd aan wat elke cloud al doet, in een vooraf gedefinieerde volgorde:

1. Inventariseer elke sleutel in elk account, project en abonnement. Scan AWS-regio's en -accounts op EC2-sleutelparen, Azure-abonnementen op authorized_keys-vermeldingen voor virtuele machines en GCP-projecten op metadatasleutels en OS-aanmeldingsbindingen. Handmatige detectie op deze schaal is, zoals NIST IR 7966 zelf stelt over SSH-sleutelinventarissen in het algemeen, "praktisch onmogelijk", dus deze stap moet vanaf het begin worden geautomatiseerd.
2. Wijs elke sleutel toe aan een eigenaar en een cloud. Leg vast wie verantwoordelijk is voor elke sleutel en tot welke cloud(s) die sleutel toegang verleent. Een sleutel die op alle drie de platforms is gekopieerd, moet worden aangemerkt als één enkele, risicovolle inloggegeven en niet worden bijgehouden als drie afzonderlijke, ongerelateerde items.
3. Kies per cloudomgeving tussen native sleutels en het op IAM gebaseerde alternatief. Evalueer AWS Systems Manager Session Manager, Microsoft Entra ID-aanmelding voor Linux-VM's en GCP OS-aanmelding in het licht van de operationele beperkingen van uw omgeving. Geen van deze opties is verplicht, maar ze zorgen er wel voor dat er geen statische privésleutel meer nodig is voor dagelijkse toegang door gebruikers, indien ze worden toegepast.
4. Standaardiseer het beleid voor alle drie de clouds. Stel één standaard in voor sleuteltype en -lengte, één rotatiefrequentie per risiconiveau en één workflow voor toegangsgoedkeuring, en pas dat ene beleid vervolgens toe via de provisioning in elke cloud, in plaats van drie afzonderlijke, steeds veranderende beleidsregels te schrijven.
5. Automatiseer rotatie en deprovisionering centraal. Een offboarding-gebeurtenis zou in één actie moeten leiden tot het verwijderen van de sleutels in AWS, Azure en GCP, en niet tot drie afzonderlijke tickets die afhankelijk zijn van drie verschillende personen die eraan moeten denken om ze te sluiten.
6. Toon gebruikslogboeken van alle drie de clouds in één overzicht. Routeer SSH-relevante gebeurtenissen uit CloudTrail, Azure Activity Log en GCP Cloud Audit Log naar een gedeeld SIEM-systeem of een speciaal platform voor SSH-sleutelbeheer, zodat een toegangscontrole of audit gegevens uit één bron haalt in plaats van drie.
7. Test de incidentrespons in meerdere clouds voordat u deze nodig hebt. Voer een simulatie uit voor het scenario "deze sleutel is gecompromitteerd en is hergebruikt in twee van onze drie cloudomgevingen" voordat dit scenario zich in de praktijk voordoet.

Hoe moet je reageren als een SSH-sleutel in meerdere clouds is gecompromitteerd?

Een gecompromitteerde SSH-sleutel die in één cloud opduikt, moet worden beschouwd als een incident dat meerdere clouds betreft, tenzij het tegendeel wordt bewezen. Hergebruik van sleutels tussen AWS, Azure en GCP komt namelijk zo vaak voor dat dezelfde privésleutel regelmatig op meerdere locaties geldig is.

1. Bewaar het in de cloud waar het voor het eerst werd gevonden. Verwijder het AWS EC2-sleutelpaar en verwijder de vermelding uit de betreffende Azure VM. authorized_keys Dien onmiddellijk een bezwaar in of trek de GCP IAM-rol in die de toegang tot het besturingssysteem ondersteunt, zonder een volledig onderzoek af te wachten.
2. Controleer of hergebruik mogelijk is in de andere twee clouds. Zoek in uw inventaris (opgebouwd in de bovenstaande workflow) naar dezelfde publieke sleutelvingerafdruk, overal in AWS, Azure of GCP. Een sleutel die eenmaal is gegenereerd en vervolgens in drie omgevingen is gekopieerd, is een van de meest voorkomende patronen van wildgroei in meerdere clouds en de snelste manier waarop een incident in één cloud een incident in alle drie wordt.
3. Haal de authenticatielogboeken op van alle drie de consoles. Reconstrueer de toegangstijdlijn met behulp van AWS CloudTrail, Azure-activiteitenlogboeken en VM-authenticatiegegevens, en GCP Cloud Audit Logs, waarbij specifiek wordt gezocht naar sessies afkomstig van onverwachte bronnen of op onverwachte tijdstippen.
4. De downstream-referenties die de sleutel kan bereiken, moeten regelmatig worden geroteerd. Een sleutel waarmee een bastionhost in de ene cloud werd geopend, kan een opstapje zijn naar inloggegevens, geheimen of extra sleutels in een andere cloud; beschouw alles wat bereikbaar is vanuit de gecompromitteerde sessie als potentieel blootgesteld.
5. Trek IAM-machtigingen onmiddellijk in, overal waar toegang via IAM werd gebruikt. Wanneer de toegang wordt bepaald door inloggen via het besturingssysteem of Entra ID, verwijdert het verbreken van de IAM- of RBAC-binding de toegang direct, zonder elke VM afzonderlijk aan te raken, en sneller dan het roteren van een gedistribueerde statische sleutel.
6. Leg één incident vast, niet drie. Bundel de bevindingen uit alle drie de cloudomgevingen in één document met daarin een overzicht van wat er is geroteerd, wat er is beoordeeld en welk bewijsmateriaal de reactie ondersteunt. Dit document dient direct als input voor het hierboven beschreven auditproces.

Dit is een samenvatting van de directe reactie in een multi-cloudomgeving, geen volledig draaiboek voor incidentafhandeling. Voor een stapsgewijze handleiding voor het afhandelen van een blootgestelde SSH-sleutel, raadpleegt u de handleiding ' Incident Response for Exposed SSH Keys' van Encryption Consulting.

Beperkingen

• Het hier beschreven native cloudgedrag is gebaseerd op de documentatie van AWS, Azure en GCP die in 2026 is herzien. Alle drie de providers werken de IAM- en VM-toegangsfuncties regelmatig bij, dus controleer het huidige gedrag aan de hand van de actuele documentatie van elke provider voordat u een beheermaatregel definitief vastlegt die daarvan afhankelijk is.
• GCP OS Login moet expliciet per project of instantie worden ingeschakeld; het is niet de standaardinstelling van GCP. Een GCP-omgeving die deze functie nooit inschakelt, is net zo gedecentraliseerd als een AWS- of Azure-omgeving.
• AWS Systems Manager Session Manager en Microsoft Entra ID-aanmelding voor Linux-VM's verwijderen de lokale privésleutel uit de dagelijkse toegang, maar beide zijn nog steeds afhankelijk van een correct geconfigureerd IAM- of RBAC-beleid; een verkeerd geconfigureerde IAM-rol verplaatst het risico simpelweg van een achtergebleven SSH-sleutel naar een identiteit met te veel privileges.
• Deze handleiding behandelt AWS, Azure en GCP, de drie hyperscalers waarop de meeste multi-cloudomgevingen van bedrijven draaien. Kleinere of regionale cloudproviders, en on-premises of hybride infrastructuren, vereisen dezelfde discipline voor ontdekking en centralisatie als hier beschreven, ook al verschillen hun eigen tools van de drie die hier worden besproken.
• De hier gegeven richtlijnen zijn algemeen van aard. In gereguleerde omgevingen (FIPS 140-3, PCI DSS, HIPAA, DORA) dienen specifieke rotatieschema's en controlebeslissingen te worden getoetst aan de eigen nalevingsverplichtingen alvorens het beleid definitief vast te stellen.

Wat zou Encryption Consulting aanbevelen?

We zouden SSH-toegang tot meerdere clouds behandelen als één beheerde groep inloggegevens, in plaats van drie cloudspecifieke problemen die door drie afzonderlijke teams worden aangepakt. In onze projecten zien we hetzelfde patroon: een organisatie heeft redelijk volwassen beveiligingsmaatregelen in één cloud, vaak de cloud waar het beveiligingsteam zich aanvankelijk op richtte, en vrijwel geen inzicht in de andere twee, omdat er in AWS, Azure of GCP geen aparte functionaliteit voor cross-cloud-zichtbaarheid bestaat.

Met SSH Secure biedt Encryption Consulting organisaties één gecentraliseerd overzicht van hun inventaris en levenscyclus voor AWS, Azure, GCP en on-premises infrastructuur, in plaats van drie afzonderlijke overzichten per cloud die een beveiligingsteam handmatig moet controleren. Zo werkt dat in de praktijk:

1. Gecentraliseerde zichtbaarheid en eigendomsmapping

Dankzij zowel agentgebaseerde als agentloze detectie vindt SSH Secure elke SSH-sleutel op AWS-, Azure- en GCP-instanties, evenals op on-premises servers, en slaat deze op in één inventaris met eigendoms- en gebruiksgegevens. Dit maakt een einde aan de gefragmenteerde spreadsheets per cloud waarmee de meeste teams beginnen.

2. Beveilig de toegangscontrole en dwing sessiegebonden sleutels af.

Gedetailleerde, op rollen gebaseerde toegangscontrole zorgt ervoor dat gebruikers de minimaal vereiste toegang krijgen, en dat dit op dezelfde manier wordt afgedwongen, ongeacht of het doelsysteem zich in AWS, Azure of GCP bevindt. Voor gevoelige of tijdelijke bewerkingen geeft SSH Secure tijdelijke, sessiegebonden sleutels uit die automatisch verlopen, waardoor de impact beperkt blijft, ongeacht in welke cloudomgeving de sessie plaatsvindt.

3. Geautomatiseerde orkestratie van de levenscyclus van sleutels in verschillende clouds.

SSH Secure automatiseert de generatie, beleidsgestuurde rotatie, geplande vervaldatum en intrekking als één workflow die AWS, Azure en GCP tegelijkertijd bereikt. Hierdoor wordt bij een offboarding-gebeurtenis de toegang tot alle drie de clouds in één actie verwijderd, in plaats van drie afzonderlijke handmatige stappen.

4. HSM-geïntegreerde beveiliging

Privésleutels worden beveiligd in HSM's , waardoor ze niet-exporteerbaar en fraudebestendig zijn, ongeacht tot welke cloud een sleutel uiteindelijk toegang verleent. Sleutels worden gegenereerd met behulp van sterke algoritmen zoals RSA -4096, ECDSA en Ed25519, en blijven geïsoleerd van het geheugen van het besturingssysteem, zelfs als een host in een van de drie clouds wordt gecompromitteerd.

5. Beleidsgestuurde controle voor belangrijke operationele processen

Alle belangrijke bewerkingen, zoals het genereren, de goedkeuringsworkflows, de rotatie en de intrekking, worden afgedwongen via beleidsgebaseerde controles die identiek van toepassing zijn, ongeacht met welke cloud een aanvraag te maken heeft. Dit vervangt de drie afzonderlijke, steeds veranderende beleidsregels die organisch ontstaan ​​wanneer elk cloudteam zijn eigen regels opstelt.

6. Continue monitoring, audits en paraatheid voor naleving

SSH Secure biedt realtime monitoring met gedetailleerde logboekregistratie van gebeurtenissen, geïntegreerd met Splunk- of Loki-Grafana-dashboards. Hierdoor wordt activiteit van AWS, Azure en GCP in één auditlogboek vastgelegd in plaats van in drie losgekoppelde consolelogboeken. Gecentraliseerde, op beleid gebaseerde waarschuwingen maken snellere detectie van afwijkingen en incidentrespons mogelijk in de gehele multi-cloudomgeving.

Conclusie

AWS, Azure en GCP bieden elk een oplossing voor SSH-sleuteltoegang voor hun eigen instanties, maar geen van hen biedt een oplossing voor uw organisatie als geheel. Die lacune, en niet de zwakte van één specifieke cloud, zorgt ervoor dat SSH-toegang in meerdere clouds gefragmenteerd raakt, inconsistent verloopt en dat auditbewijs onder tijdsdruk van drie verschillende consoles moet worden verzameld. Door SSH-sleutels te behandelen als één beheerde populatie van referenties, met eigendom toegewezen bij uitgifte, rotatietriggers die rekening houden met de specifieke werking van elke cloud, consistent beleid dat wordt afgedwongen via alle drie de IAM-modellen en continu verzameld in plaats van gereconstrueerd auditbewijs, verandert SSH-toegang in meerdere clouds van een verborgen, gefragmenteerd risico in een gecontroleerd en controleerbaar onderdeel van het beveiligingsprogramma, ongeacht in welke cloud een bepaalde sleutel zich bevindt.

Gerelateerde artikelen van Encryption Consulting

Meer informatie over de levenscyclus van SSH-sleutels, cloudcryptografie en de hierboven besproken migratiewerkzaamheden vindt u hier:

• Uitgebreid beheer van de levenscyclus van SSH-sleutels voor bedrijfsbeveiliging, de pijlergids van Encryption Consulting voor SSH-sleuteleigendom, -rotatie, toegangsbeleid en auditbewijs in elke omgeving.
• SSH-kwetsbaarheden en hoe u zich daartegen kunt beschermen Dit document behandelt CVE's op protocol- en implementatieniveau die van invloed zijn op SSH, ongeacht in welke cloudomgeving het draait.
• Incidentrespons voor blootgestelde SSH-sleutels Dit is het volledige draaiboek dat ten grondslag ligt aan de beknopte stappen in het onderdeel incidentrespons van deze handleiding.
• SSH-sleuteleigendom Het artikel gaat dieper in op het toewijzen en afdwingen van eigendomsmodellen voor bevoorrechte inloggegevens.
• PQC voor cloudomgevingen: gedeelde verantwoordelijkheid voor AWS, Azure en Google Cloud omvat hetzelfde driecloud-vergelijkingsmodel dat wordt toegepast op de verantwoordelijkheid voor post-kwantummigratie.
• CBOM Secure Breidt cryptografische ontdekking uit van SSH-sleutels naar certificaten en algoritmen in elke omgeving, zowel in de cloud als on-premises.

Veelgestelde Vragen / FAQ

Worden SSH-sleutels automatisch geroteerd door AWS, Azure of GCP? Nee. Geen van de drie grote cloudproviders roteert SSH-sleutels standaard automatisch. AWS EC2-sleutelparen en authorized_keys-vermeldingen in Azure VM's blijven onbeperkt geldig totdat iemand ze handmatig vervangt of verwijdert. GCP-metadatasleutels gedragen zich op dezelfde manier; de OS Login van GCP wijzigt dit alleen voor IAM-beheerde toegang, waarbij het intrekken van de IAM-rol van een gebruiker werkt als directe rotatie, maar dit geldt niet voor serviceaccounts of op metadata gebaseerde sleutels.

Wat is nu precies het verschil tussen GCP OS Login en hoe AWS en Azure omgaan met SSH-sleutels? OS Login koppelt SSH-toegang rechtstreeks aan een Google IAM-identiteit, waardoor de toegang automatisch wordt bijgewerkt wanneer IAM-machtigingen wijzigen en niet afhankelijk is van een opgeslagen privésleutel voor autorisatiebeslissingen. AWS en Azure bieden beide vergelijkbare IAM-gebaseerde alternatieven, namelijk AWS Systems Manager Session Manager en Microsoft Entra ID login voor Linux-VM's, maar beide vereisen de installatie van een aparte agent of extensie en zijn optionele toevoegingen bovenop een standaard sleutelgebaseerde authenticatie, in plaats van een native SSH-authenticatiepad zoals GCP's OS Login dat is.

Kan ik SSH-sleutels vervangen door IAM-gebaseerde toegang in alle drie de clouds? Je kunt in elke cloud afzonderlijk overstappen op IAM-gebaseerde toegang. AWS Session Manager, Azure Entra ID-aanmelding en GCP OS-aanmelding ondersteunen dit allemaal, maar geen van de drie integreert met de andere. Als je kiest voor IAM-gebaseerde toegang in alle drie de clouds, heb je nog steeds drie afzonderlijke IAM-systemen die je consistent moet beheren. Dit is precies het probleem dat een gecentraliseerde laag voor SSH-sleutelbeheer probeert op te lossen.

Hoe krijg ik één overzicht van alle SSH-sleutels in AWS, Azure en GCP? Je hebt een ontdekkingsproces nodig, of een speciaal platform voor SSH-sleutelbeheer, dat EC2-sleutelparen scant in elke AWS-regio en elk AWS-account, authorized_keys-vermeldingen van virtuele machines in elk Azure-abonnement, en metadata van GCP-projecten of -instanties en OS-aanmeldingsbindingen. Vervolgens normaliseert het al deze gegevens tot één record per sleutel met een toegewezen eigenaar. Geen van de drie cloudconsoles biedt dit overzicht standaard, omdat ze niet weten dat de andere twee bestaan.

Betekent het inschakelen van GCP OS Login dat we geen SSH-sleutelrotatiebeleid meer nodig hebben? Nee. OS Login verwijdert opgeslagen privésleutels uit de vergelijking voor interactieve menselijke aanmeldingen op GCP Compute Engine, maar serviceaccounts, automatisering en alle instanties of projecten die nog steeds metadata-gebaseerde sleutels gebruiken, behouden dezelfde rotatievereisten als AWS en Azure. OS Login is bovendien alleen van toepassing op GCP, dus een rotatiebeleid blijft vereist voor elk toegangsmodel dat AWS en Azure gebruiken.

Referenties

• Maak een sleutelpaar voor uw Amazon EC2-instantieAmazon Web Services
• AWS Systems Manager SessiemanagerAmazon Web Services
• Gedetailleerde stappen voor het aanmaken van een SSH-sleutelpaarMicrosoft Learn, Azure Virtual Machines
• Meld u aan bij een virtuele Linux-machine in Azure met behulp van uw Microsoft Entra ID en OpenSSH.Microsoft Learn
• Over OS-aanmeldingGoogle Cloud, Compute Engine-documentatie
• OS-aanmelding instellenGoogle Cloud, Compute Engine-documentatie
• Aanbevelingen voor het beheren van SSH-toegangGoogle Cloud, Compute Engine-documentatie
• NIST IR 7966: Beveiliging van interactief en geautomatiseerd toegangsbeheer met behulp van Secure Shell (SSH)Nationaal Instituut voor Standaarden en Technologie
• State of Secrets Sprawl 2026, GitGuardian
• Rapport over de stand van zaken rond machine-identiteitsbeveiliging in 2025CyberArk
• Kosten van een datalekrapport 2025IBM