Din ultimata guide för SSH-nyckelhantering i flera moln

AWS ger dig en nedladdningsbar .pem-fil. Azure placerar en publik nyckel i en enda virtuell maskins authorized_keys. Om du aktiverar OS Login kopplar GCP SSH-åtkomst till en IAM-identitet istället för en nyckelfil överhuvudtaget. Tre moln, tre olika modeller för samma autentiseringsuppgifter, och de flesta säkerhetsteam upptäcker detta den hårda vägen: under en granskning, en offboarding eller en incident, när ingen kan skapa en enda lista över vem som kan använda SSH till vad i hela miljön.

Publicerad: mars 2026. Uppdaterad: augusti 2026. Granskad av Encryption Consultings nyckelhanteringsteam.

Varför är SSH-nyckelhantering i flera moln svårare än i ett enda moln?

SSH-nyckelhantering i flera moln är svårare än i ett enda moln eftersom det inte finns något delat SSH-nyckelkontrollplan mellan AWS, Azure och GCP. Varje leverantör injicerar, lagrar och styr nycklar via sin egen mekanism, och ingen av dessa mekanismer kommunicerar med de andra. En nyckel som genereras för en AWS EC2-instans har ingen relation till en nyckel som distribuerats på en virtuell Azure-dator eller en GCP Compute Engine-instans, även om samma ingenjör hanterar alla tre och återanvänder samma nyckelpar av bekvämlighetsskäl.

Den skillnaden visar sig på tre konkreta sätt när en organisation faktiskt kör arbetsbelastningar på mer än ett moln:

• Fragmenterade lager. AWS spårar nyckelpar per region och konto, Azure spårar publika nycklar per virtuell maskins authorized_keys-fil (eller per Azure Key Vault-resurs, om ett team gör sig besväret med att koppla ihop det), och GCP spårar nycklar i projekt- eller instansmetadata, eller i IAM om OS-inloggning är aktiverad. Ingen enskild konsol visar allt.
• Inkonsekventa baslinjer. En nyckeltyps- och rotationspolicy som tillämpas i AWS via interna processer måste tillämpas separat, manuellt i Azure och GCP, eftersom inget av de tre molnen kommer att tillämpa en annan molnpolicy åt dig.
• Återanvända nycklar, ingen delad identitet. Ingenjörer kopierar vanligtvis samma publika nyckel över alla tre moln för enkelhetens skull. Den nyckeln har nu tre separata sprängradier, tre separata återkallningspunkter och ingen enskild post som knyter den tillbaka till en ägare.

För en fullständig beskrivning av vad livscykelhantering för SSH-nyckel innebär i en enskild miljö, ägarskap, rotationsutlösare, åtkomstpolicy och revisionsbevis, se Encryption Consultings omfattande guide om livscykelhantering för SSH-nyckel för företagssäkerhet . Den här guiden bygger vidare på den grunden och fokuserar specifikt på vad som förändras när samma disciplin måste gälla för AWS, Azure och GCP samtidigt.

Data bakom utbredningen

Spridning av SSH-nycklar är inte en teoretisk risk. Nyligen genomförda analytikerrapporter, leverantörsundersökningar och branschundersökningar visar siffror som visar exakt hur långt ohanterade autentiseringsuppgifter, inklusive SSH-nycklar, har överträffat styrning:

• Hemlighetsspridningen accelererar snabbare än team kan spåra den. GitGuardians Hemligheternas tillstånd Sprawl 2026 Rapporten, publicerad 17 mars 2026, fann att 29 miljoner nya hårdkodade hemligheter exponerades på den offentliga GitHub enbart under 2025, en ökning med 34 % jämfört med föregående år och den största ökningen på ett enskilt år som företaget har registrerat. Samma rapport noterar att de senaste incidenterna i leveranskedjan, inklusive LiteLLM-komprometteringen, specifikt skördade SSH-nycklar tillsammans med molnuppgifter.
• Maskinidentiteter, inklusive SSH-nycklar, överskuggar nu mänskliga konton. CyberArks Rapport om maskinidentitetssäkerhetens tillstånd 2025, baserat på en undersökning av 1 200 säkerhetschefer, fann att organisationer förväntar sig att maskinidentiteter kommer att fortsätta öka och att manuella processer inte längre kan spåra dem i stor skala, vilket sätter förhållandet mellan maskinidentiteter och mänskliga identiteter till ungefär 82:1.
• Intrång baserade på autentiseringsuppgifter är de långsammaste och bland de dyraste att upptäcka. IBM: s Kostnad för en dataöverföringsrapport för 2025 fann att intrång som började med stulna eller komprometterade inloggningsuppgifter uppgick i genomsnitt till 4.67 miljoner dollar och tog 246 dagar att identifiera och begränsa, en av de längsta intrångslivscyklerna som rapporten spårar.

Multimolnanläggningar förvärrar vart och ett av dessa siffror, eftersom samma nyckel kan existera, utan att redovisas, i tre separata inventeringar istället för ett.

Hur hanterar AWS, Azure och GCP SSH-nycklar nativt?

AWS, Azure och GCP behandlar alla SSH-nyckelåtkomst som en detalj på instansnivå eller projektnivå snarare än en styrd, centralt hanterad autentiseringsuppgift. GCP är det delvisa undantaget: dess OS-inloggningsfunktion kan binda SSH-åtkomst till IAM-identitet istället för en lagrad nyckel, något som AWS och Azure endast erbjuder som separata, opt-in-tjänster som läggs ovanpå deras standardnyckelmodell.

AWS: EC2-nyckelpar

AWS standardmodell är nyckelparet EC2. När du startar en instans via konsolen, CLI eller CloudFormation lagrar AWS den publika nyckeln med instansen och ger dig exakt en chans att ladda ner den privata nyckeln, per... AWS egen EC2 användarhandbokNyckelpar begränsas per region, med en dokumenterad gräns på 5 000 nyckelpar per region och konto, och det finns ingen inbyggd mekanism för att dela ett nyckelpar mellan regioner eller konton. AWS stöder både RSA- och ED25519-nyckeltyper och låter dig importera en externt genererad offentlig nyckel istället för att använda AWS-genererat material, men dokumentationen beskriver ingen automatiserad rotationsfunktion. Att rotera ett EC2-nyckelpar innebär att generera en ny nyckel, uppdatera authorized_keys på varje berörd instans och dra tillbaka det gamla nyckelparet, manuellt eller via din egen automatisering.

AWS erbjuder även AWS Systems Manager Session Manager som ett IAM-baserat alternativ som eliminerar behovet av en lagrad privat nyckel eller en öppen inkommande SSH-port. Det är inte standard: det kräver att SSM-agenten körs på instansen och en IAM-roll som ger instansen behörighet att kommunicera med Systems Manager. Session Manager ger dig IAM-kontrollerad åtkomst och sessionsloggning, men den samexisterar med EC2-nyckelpar snarare än att ersätta dem över en applikation som redan har nyckelbaserad åtkomst inbyggd i skript, bilder och CI/CD-pipelines.

Azure: SSH-nycklar per virtuell maskin

Azures standardmodell liknar AWS men är ännu snävare begränsad till den enskilda virtuella maskinen. Microsofts dokumentation för virtuella Azure-maskiner, genererar du ett nyckelpar (vanligtvis RSA eller ED25519, med hjälp av ssh-keygen eller az vm create --generate-ssh-keys flagga), och den publika nyckeln skrivs in i den virtuella maskinen ~/.ssh/authorized_keys filen vid skapandet. Den privata nyckeln finns kvar på den lokala datorn som genererade den, och samma nyckelpar kan återanvändas på många virtuella maskiner, vilket gör installationen enkel men innebär att en läckt privat nyckel kan nå varje virtuell maskin den någonsin kopierats till. Microsofts egen dokumentation beskriver inte en nyckelinventering på prenumerationsnivå, en Azure Key Vault-integration inbyggd i standardflödet för skapande av virtuella maskiner eller någon automatiserad rotationstillämpning; ett team kan koppla Key Vault till ett distributionsskript för att generera och lagra ett nyckelpar, men det är ett mönster som du bygger, inte ett standardmönster som Azure tillhandahåller.

Azures IAM-baserade alternativ är Microsoft Entra ID-inloggning för virtuella Linux-maskiner, som autentiserar SSH-sessioner mot Entra ID-autentiseringsuppgifter och Azure RBAC-rolltilldelningar istället för en statisk nyckel. Liksom AWS Session Manager är det opt-in: det kräver installation av AADSSHLoginForLinux VM-tillägg, vilket möjliggör en systemtilldelad hanterad identitet och tilldelar roller som inloggning för virtuell maskinadministratör. Standardautentisering med offentlig SSH-nyckel är fortfarande Azures standard, och de flesta fastigheter kör en blandning av Entra-aktiverade och nyckelbaserade virtuella maskiner snarare än en konsekvent modell.

GCP: metadatanycklar eller OS-inloggning kopplad till IAM

GCP startar från samma plats som AWS och Azure: som standard läser Compute Engine SSH-publika nycklar från projekt- eller instansmetadata och skriver dem till authorized_keys på mål-VM, per Googles egen vägledning om att lägga till SSH-nycklar till virtuella maskinerDet som skiljer GCP från mängden är OS-inloggning, en funktion som ersätter metadatabaserade nycklar med IAM-styrd åtkomst. Med OS-inloggning aktiverad ger en administratör en användare roles/compute.osLogin or roles/compute.osAdminLogin IAM-roll istället för att distribuera en nyckelfil, och Googles dokumentation beskriver kontinuerlig utvärdering per session: när en administratör tar bort en användares IAM-behörighet återkallas den användarens SSH-åtkomst omedelbart, utan att någon rör en virtuell maskin eller en authorized_keys fil. OS Login stöder även tvåfaktorsautentisering via Google Authenticator, SMS eller säkerhetsnycklar, och loggar anslutningsförsök för granskningsändamål, enligt Googles bästa praxis för SSH-inloggning.

OS-inloggning är inte heller GCP:s standardinställning; den måste aktiveras med en enable-oslogin=TRUE metadataflagga på projekt- eller instansnivå, enligt Googles Dokumentation för installation av OS-inloggningDen verkliga skillnaden är vad som händer när den väl är påslagen: OS-inloggning styr SSH-åtkomst genom samma ssh kommandot och standard OpenSSH-klienten, med IAM som sanningskälla, utan att kräva en separat agent eller tillägg på samma sätt som AWS Session Manager och Azure Entra ID-inloggning gör. Det gör IAM-baserad SSH-åtkomst lättare att implementera konsekvent över en GCP-fastighet än på de andra två molnen, även om det fortfarande kräver samma avsiktliga utrullningsbehov som AWS och Azure.

Beslutstabell: Molnleverantör kontra nativ SSH-nyckelhantering kontra centraliseringsgap

Molnleverantör	Inbyggd SSH-nyckelhantering	Centraliseringsgap
AWS	EC2-nyckelpar per region; publik nyckel lagrad med instansen, privat nyckel nedladdningsbar en gång; RSA eller ED25519; upp till 5 000 par per region; valfri IAM-baserad Systems Manager Session Manager som tillägg	Ingen inbyggd rotation; ingen nyckelinventering mellan regioner eller konton; Session Manager kräver separat konfiguration av SSM-agent och IAM-roll och tar inte bort befintliga nyckelpar.
Azure	Poster av typen authorized_keys per virtuell maskin, genererade via CLI, portal eller ARM-mall; återanvändbara mellan virtuella maskiner; valfri Microsoft Entra ID-inloggning för Linux som ett tillägg	Ingen dokumenterad nyckelinventering på prenumerationsnivå; ingen automatiserad rotation; Entra ID-inloggning kräver AADSSHLoginForLinux-tillägget och RBAC-rolltilldelning utöver standardnyckelmodellen.
GCP	Projekt- eller instansmetadatanycklar som standard; OS-inloggning tillgänglig för att binda åtkomst till IAM-identitet istället, med kontinuerlig behörighetsutvärdering och valfri 2FA	OS-inloggning måste vara explicit aktiverad; en GCP-egendom som aldrig slår på den är exakt lika decentraliserad som AWS eller Azure; OS-inloggning i sig omfattar inte AWS- eller Azure-resurser.

Varje rad i den tabellen beskriver ett enda moln isolerat. Ingen av de tre mekanismerna, EC2-nyckelpar, Azure authorized_keys-filer eller GCP OS-inloggning, producerar en post som sträcker sig över de andra två. Det är det centraliseringsgap som ett multimolnprogram måste stänga medvetet, eftersom ingen leverantör stänger det åt dig.

Vem äger SSH-nyckelns livscykel över molngränser?

I ett enda moln är äganderätten åtminstone teoretiskt spårbar tillbaka till den som skapade nyckelparet, den virtuella maskinen eller IAM-bindningen i det kontot. Över tre moln bryts det spåret om inte äganderätten tilldelas centralt och oberoende av vilken plattform en given nyckel råkar finnas på.

Livscykelstadiet	Verklighet i ett enda moln	Vad som bryter över tre moln
Generation	Ingenjör skapar eller importerar ett nyckelpar i en konsol	Samma nyckelpar återanvänds ofta i AWS, Azure och GCP för enkelhetens skull, så en generationshändelse har nu tre separata sprängradier utan delad post.
Godkännande	Teamledaren eller säkerhetspersonalen granskar begäran i molnets arbetsflöde	Godkännandearbetsflöden skiljer sig åt beroende på moln (IAM-policykoppling i AWS, RBAC-rolltilldelning i Azure, OS-inloggning för IAM i GCP), så en enda godkännandestandard måste läggas ovanpå alla tre.
Provisioning	Offentlig nyckel skriven till molnets metadata, authorized_keys-fil eller IAM-bindning	Det finns inget delat provisionerings-API; ett centraliserat verktyg eller en dokumenterad runbook måste driva samma policy genom tre olika provisioneringsmekanismer.
Användning	Molnets inbyggda loggning (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) registrerar sessionen.	Tre separata loggformat och lagringspolicyer innebär att användningsbevis måste normaliseras innan de är användbara för en granskning av åtkomst över hela molnet.
Rotation och avveckling	Nyckel borttagen från det molnets instans eller metadata	Att offboarda en ingenjör som hade åtkomst till alla tre molnen innebär tre separata borttagningsåtgärder, som var och en kan missas oberoende av varandra, såvida inte ett system utlöser alla tre

Den praktiska lösningen är att utse en ansvarig ägare, en roll, inte bara en person, för varje nyckel i det ögonblick den skapas, och registrera vilket eller vilka moln nyckeln berör som en del av samma post. Det är just den ändringen som gör att en offboarding-checklista, eller en revision, kan behandla "denna persons SSH-åtkomst" som en enda post istället för tre.

Vad bör utlösa rotation, och varför är molnbaserad rotation ofta manuell eller ofullständig?

SSH-nyckelrotation bör utlösas under samma tre villkor i varje moln: förfluten kryptoperiod, en personal- eller rollbyte och misstänkt kompromiss, enligt det allmänna ramverket i NIST IR 7966. Det som förändras i en multimolnfastighet är att ingen av de tre leverantörerna automatiserar alla tre utlösare, och ingen av dem kommer att rotera en nyckel åt dig utan att du själv bygger den automatiseringen.

• AWS har ingen schemalagd rotation för EC2-nyckelpar. Rotation innebär att generera ett nytt nyckelpar och skicka den nya publika nyckeln till varje berörd instans. authorized_keys fil (manuellt, eller via Systemhanteraren eller din egen konfigurationshantering), och ta bort det gamla nyckelparet från kontot. Ingenting i plattformen påminner dig om att detta är försenat.
• Azure är samma sak på VM-nivå: ingenting tvingar fram en uppdatering av nyckeln som sitter i authorized_keys, och eftersom samma nyckelpar ofta återanvänds på många virtuella maskiner, innebär en rotationshändelse i Azure ofta att dussintals virtuella maskiner uppdateras en efter en om inte konfigurationshanteringen hanterar det.
• GCP Metadatanycklar beter sig som de andra två: ingen automatisk utgångsdatum eller uppdatering. OS Login ändrar problemets form snarare än att lösa rotationen direkt, eftersom åtkomsten är knuten till en IAM-bindning istället för en statisk nyckel; återkallandet av IAM-rollen sker i praktiken omedelbart, vilket fungerar som rotation för mänsklig interaktiv åtkomst, men servicekontonycklar och alla metadatabaserade nycklar som fortfarande används följer samma manuella mönster som AWS och Azure.

Den praktiska implikationen: en rotationspolicy skriven för "SSH-nycklar" kommer generellt att misslyckas i tysthet i en multimolnmiljö om den inte specificerar, per moln, exakt vilken åtgärd som uppfyller den policyn, eftersom "rotera nyckeln" innebär en annan sekvens av steg på varje plattform.

Hur håller man åtkomstpolicyn konsekvent över tre olika IAM-modeller?

AWS IAM, Azure RBAC och Google Cloud IAM uttrycker alla åtkomstkontroll tillräckligt olika för att en policy som skrivits för en leverantör inte direkt ska kunna överföras till de andra. Att hålla åtkomstpolicyn konsekvent innebär att definiera policyn en gång, i moln-agnostiska termer, och sedan mappa den separat till varje leverantörs modell, snarare än att försöka skriva en inbyggd policy och hoppas att den generaliseras.

• Minst privilegier, uttryckt per plattform. ”Produktionsdatabasadministratörer får SSH-åtkomst till produktionsdatabasvärdar” måste bli en IAM-policy med begränsad räckvidd i AWS, en rolltilldelning med begränsad RBAC-roll i Azure och en IAM-roll med begränsad räckvidd för OS Login i GCP, tre separata konfigurationer som tillämpar samma avsikt.
• Käll- och kommandobegränsningar. Inget av de tre molnen tillämpar käll-IP eller kommandobegränsningar på SSH-sessioner direkt på plattformsnivå på samma sätt; dessa kontroller, när de används, konfigureras vanligtvis i nyckelns authorized_keys själva posten (AWS, Azure) eller via OS Logins stödda alternativ (GCP), så de måste tillämpas konsekvent av vilken process som helst som tillhandahåller nyckeln, inte antas från molnet.
• Uppdelning av arbetsuppgifter. Den person som godkänner en åtkomstbegäran bör inte vara samma person som etablerar den, en regel som är enkel att upprätthålla i ett molns arbetsflöde och lätt att tappa bort när tre separata arbetsflöden finns sida vid sida.
• Tjänstkonto och automatiseringsnycklar. CI/CD-pipelines och konfigurationshanteringsverktyg innehåller ofta långlivade SSH-nycklar med bred räckvidd över molngränser; dessa nycklar behöver samma policydisciplin som mänskliga nycklar, förmodligen mer, eftersom de används kontinuerligt och är svårare att upptäcka om de komprometteras.

Ett moln-agnostiskt SSH-nyckelhanteringslager, som ligger ovanför AWS IAM, Azure RBAC och GCP IAM snarare än att försöka vara en fjärde inkompatibel modell, är det som gör "en policy, tre tillämpningar" uppnåelig istället för ambitiös.

Hur producerar man revisionsbevis över flera molnkonsoler?

Att producera revisionsbevis för AWS, Azure och GCP innebär att man hämtar bevis på begäran, godkännande, provisionering, användning och avslutning från tre separata loggsystem, normaliserar dem och presenterar dem som en post per autentiseringsuppgifter snarare än tre separata fragment. Ramverk som SOC 2, ISO/IEC 27001 och PCI DSS förväntar sig alla att en organisation visar att åtkomst granskas och återkallas i tid, och en revisor som frågar "vem som kan SSH:a in i det här systemet och bevisa det" bryr sig inte om att svaret spänner över tre olika molnkonsoler.

• AWS Bevisen kommer från CloudTrail (nyckelparsåtgärder på API-nivå) och, där de används, Session Manager-sessionsloggar; ingen av dem registrerar direkt vilken människa som innehade den privata nyckeln för ett givet EC2-nyckelpar, bara att nyckelparet existerade och vilka API-anrop som berörde det.
• Azure Bevis kommer från Azure-aktivitetsloggen och autentiseringsposter på virtuell maskinnivå; eftersom ett nyckelpar kan återanvändas på många virtuella maskiner kräver kopplingen av en specifik inloggningshändelse till en specifik person att man jämför vilken privat nyckel den personen faktiskt innehar, information som Azure självt inte spårar.
• GCP Bevisen är starkast när OS Login är aktiverad, eftersom Cloud Audit Logs sedan kopplar varje session direkt till en IAM-identitet snarare än en anonym nyckel; utan OS Login har GCP:s metadata-nyckelloggning samma ägarskapsgap som AWS och Azure.

Lösningen är densamma som löser problemet med livscykelägande: tilldela en ägare vid utfärdande, registrera vilket eller vilka moln en nyckel berör och mata in användningsloggar från alla tre konsoler till ett system, en SIEM-plattform som Splunk eller ett dedikerat SSH-nyckelhanteringsverktyg, så att revisionsbevis kontinuerligt samlas in snarare än rekonstrueras under deadlinepress varje gång en revisor frågar.

Ett praktiskt arbetsflöde för centralisering av SSH-nyckelhantering i flera moln

Att centralisera SSH-nyckelhantering över AWS, Azure och GCP kräver inte att befintlig åtkomst tas bort eller att pågående arbetsbelastningar störs. Det innebär att lägga till identifiering, policy och automatisering ovanpå vad varje moln redan gör, i en definierad sekvens:

1. Inventera varje nyckel, i varje konto, projekt och prenumeration. Skanna AWS-regioner och konton efter EC2-nyckelpar, Azure-prenumerationer för VM authorized_keys-poster och GCP-projekt för metadatanycklar och OS Login-bindningar. Manuell identifiering i denna skala är, med NIST IR 7966:s egna ord om SSH-nyckelinventeringar i allmänhet, "praktiskt taget omöjlig", så detta steg bör automatiseras från början.
2. Mappa varje nyckel till en ägare och ett moln. Registrera vem som är ansvarig för varje nyckel och vilket eller vilka moln som nyckeln ger åtkomst till. En nyckel som kopieras över alla tre plattformar bör flaggas som en enda autentiseringsuppgift med högre risk, inte spåras som tre orelaterade poster.
3. Bestäm, per moln, mellan nativa nycklar och det IAM-baserade alternativet. Utvärdera AWS Systems Manager Session Manager, Microsoft Entra ID-inloggning för virtuella Linux-maskiner och GCP OS-inloggning mot din fastighets operativa begränsningar. Inget är obligatoriskt, men var och en tar bort en statisk privat nyckel från daglig mänsklig åtkomst där den används.
4. Normalisera policyn över alla tre molnen. Ange en standard för nyckeltyp och längd, en rotationskadens per risknivå och ett arbetsflöde för åtkomstgodkännande, och tillämpa sedan den enda policyn genom provisionering i varje moln istället för att skriva tre separata, drivande policyer.
5. Automatisera rotation och avprovisionering centralt. En offboarding-händelse bör utlösa borttagning av nyckel i AWS, Azure och GCP som en enda åtgärd, inte tre separata ärenden som är beroende av att tre separata personer kommer ihåg att stänga dem.
6. Mata in användningsloggar från alla tre molnen i en vy. Dirigera CloudTrail, Azure Activity Log och GCP Cloud Audit Log SSH-relevanta händelser till en delad SIEM- eller dedikerad SSH-nyckelhanteringsplattform, så att en åtkomstgranskning eller en granskning hämtar från en källa istället för tre.
7. Testa incidentrespons över hela molnet innan du behöver den. Kör en övning i tabellform för att se "den här nyckeln är komprometterad och den har återanvänds i två av våra tre moln" innan det scenariot händer på riktigt.

Hur ska du reagera när en SSH-nyckel komprometteras över flera moln?

En komprometterad SSH-nyckel som dyker upp i ett moln måste behandlas som en multimolnincident tills motsatsen bevisas, eftersom återanvändning av nycklar i AWS, Azure och GCP är tillräckligt vanligt för att samma privata nyckel ofta är giltig på mer än ett ställe.

1. Innehåll i molnet där den hittades först. Ta bort AWS EC2-nyckelparet, ta bort posten från de berörda Azure-VM:erna authorized_keys filen, eller återkalla GCP IAM-rollen som stöder OS Login-åtkomst, omedelbart, utan att vänta på en fullständig utredning.
2. Kontrollera om det finns återanvändning i de andra två molnen. Sök i ditt inventarium (inbyggt i arbetsflödet ovan) efter samma publika nyckelfingeravtryck var som helst i AWS, Azure eller GCP. En nyckel som genereras en gång och kopieras och klistras in i tre miljöer är ett av de vanligaste spridningsmönstren för flera moln och det snabbaste sättet att en incident i ett moln blir en incident i alla tre.
3. Hämta autentiseringsloggar från alla tre konsolerna. Rekonstruera åtkomsttidslinjen med hjälp av AWS CloudTrail, Azure Activity Log och VM-autentiseringsposter samt GCP Cloud Audit Logs, och leta specifikt efter sessioner från oväntade källor eller vid oväntade tidpunkter.
4. Rotera nedströms autentiseringsuppgifter som nyckeln kunde nå. En nyckel som öppnade en bastionvärd i ett moln kan vara en språngbräda mot autentiseringsuppgifter, hemligheter eller ytterligare nycklar i ett annat; behandla allt som är nåbart från den komprometterade sessionen som potentiellt exponerat.
5. Återkalla IAM-behörigheter omedelbart överallt där IAM-baserad åtkomst användes. Där OS-inloggning eller Entra ID-inloggning styr åtkomst, tar man bort åtkomsten direkt om man bryter IAM- eller RBAC-bindningen utan att vidröra varje virtuell maskin individuellt, snabbare än att rotera en distribuerad statisk nyckel.
6. Dokumentera en incidentrapport, inte tre. Konsolidera resultaten från alla tre molnen till en enda post som täcker vad som roterades, vad som granskades och vilka bevis som stöder svaret, vilket matar direkt in i den revisionsbevisprocess som beskrivs ovan.

Detta är en sammanfattning av den omedelbara multimolnresponsen, inte en fullständig handbok för incidentrespons. För steg-för-steg-hantering av en exponerad SSH-nyckel i allmänhet, se Encryption Consultings guide om incidentrespons för exponerade SSH-nycklar .

Begränsningar

• De inbyggda molnbeteenden som beskrivs här återspeglar AWS-, Azure- och GCP-dokumentation som granskades 2026. Alla tre leverantörer uppdaterar IAM- och VM-åtkomstfunktioner regelbundet, så verifiera aktuellt beteende mot varje leverantörs live-dokumentation innan du slutför en kontroll som är beroende av den.
• GCP OS-inloggning måste vara explicit aktiverad per projekt eller instans; det är inte GCP:s standardinställning. En GCP-fastighet som aldrig aktiverar den är precis lika decentraliserad som en AWS- eller Azure-fastighet.
• AWS Systems Manager Session Manager och Microsoft Entra ID-inloggning för virtuella Linux-maskiner tar bort den lokala privata nyckeln från den dagliga åtkomsten, men båda är fortfarande beroende av korrekt omfattad IAM- eller RBAC-policy; en felkonfigurerad IAM-roll flyttar helt enkelt risken från en föräldralös SSH-nyckel till en överprivilegierad identitet.
• Den här guiden täcker AWS, Azure och GCP, de tre hyperskalningsplattformar som de flesta multimolnanläggningar för företag körs på. Mindre eller regionala molnleverantörer, och lokala eller hybridinfrastrukturer, behöver samma identifierings- och centraliseringsdisciplin som beskrivs här, även om deras inbyggda verktyg skiljer sig från alla tre som behandlas här.
• Vägledningen här är generell. Reglerade miljöer (FIPS 140-3, PCI DSS, HIPAA, DORA) bör validera specifika rotationskadenser och kontrollbeslut mot sina egna efterlevnadsskyldigheter innan de slutför policyn.

Vad skulle krypteringskonsulter rekommendera?

Vi skulle behandla SSH-åtkomst i flera moln som en enda styrd autentiseringsuppgiftspopulation, inte tre molnspecifika problem som hanteras av tre separata team. I våra engagemang upprepas mönstret: en organisation har någorlunda mogna kontroller i ett moln, ofta där säkerhetsteamets uppmärksamhet började, och nästan ingen insyn i de andra två, eftersom ingenting i AWS, Azure eller GCP tvingar fram molnöverskridande insyn på egen hand.

Genom SSH Secure ger Encryption Consulting organisationer en centraliserad inventering och livscykel över AWS, Azure, GCP och lokal infrastruktur, snarare än tre separata vyer per moln som ett säkerhetsteam måste stämma av manuellt. Så här fungerar det i praktiken:

1. Centraliserad synlighet och ägarkartläggning

Genom agentbaserad och agentlös identifiering lokaliserar SSH Secure varje SSH-nyckel i AWS-, Azure- och GCP-instanser tillsammans med lokala servrar, och lagrar dem i en enda inventering med ägarskaps- och användningsinformation, vilket eliminerar de fragmenterade kalkylbladen per moln som de flesta team börjar med.

2. Säker åtkomstkontroll och tillämpa sessionsbundna nycklar

Detaljär rollbaserad åtkomstkontroll säkerställer att användare får den lägsta åtkomst som krävs, och tillämpas identiskt oavsett om målsystemet sitter i AWS, Azure eller GCP. För känsliga eller tillfälliga operationer utfärdar SSH Secure kortlivade, sessionsbundna nycklar som upphör att gälla automatiskt, vilket begränsar explosionsradien oavsett vilket moln sessionen berör.

3. Automatiserad orkestrering av nyckellivscykeln i molnen

SSH Secure automatiserar generering, policydriven rotation, schemalagd utgång och återkallelse som ett arbetsflöde som når AWS, Azure och GCP tillsammans, så en offboarding-händelse tar bort åtkomst från alla tre moln i en enda åtgärd istället för tre separata manuella steg.

4. HSM-integrerat skydd

Privata nycklar är säkrade inom HSM:er , vilket säkerställer att de inte kan exporteras och är manipulationssäkra oavsett vilket moln en nyckel slutligen ger åtkomst till. Nycklar genereras med hjälp av starka algoritmer som RSA -4096, ECDSA och Ed25519, och förblir isolerade från operativsystemets minne även om en värd i något av de tre molnen komprometteras.

5. Policydriven kontroll för nyckelverksamheter

Alla nyckelåtgärder, generering, arbetsflöden för godkännande, rotation och återkallelse, verkställs genom policybaserade kontroller som gäller identiskt oavsett vilket moln en begäran berör, och ersätter de tre separata, drivande policyer som byggs upp organiskt när varje molnteam skriver sina egna regler.

6. Kontinuerlig övervakning, revision och beredskap för efterlevnad

SSH Secure tillhandahåller realtidsövervakning med detaljerad händelseloggning, integrerad med Splunk- eller Loki-Grafana-instrumentpaneler, så att aktivitet från AWS, Azure och GCP flyter in i en enda revisionslogg istället för tre frånkopplade konsolloggar. Centraliserade, policybaserade aviseringar möjliggör snabbare avvikelsedetektering och incidenter i hela multimolnområdet.

Slutsats

AWS, Azure och GCP löser alla SSH-nyckelåtkomst för sina egna instanser, och ingen av dem löser det för din organisation som helhet. Den bristen, inte något enskilt molns svaghet, är det som förvandlar SSH-åtkomst i flera moln till fragmenterade inventeringar, inkonsekvent rotation och revisionsbevis som måste samlas in från tre konsoler under deadlinepress. Att behandla SSH-nycklar som en styrd autentiseringsuppgifter, med ägarskap tilldelat vid utfärdande, rotationsutlösare som tar hänsyn till varje molns faktiska mekanik, policy som tillämpas konsekvent genom alla tre IAM-modeller och revisionsbevis som samlas in kontinuerligt snarare än rekonstrueras, förvandlar SSH-åtkomst i flera moln från en dold, fragmenterad risk till en kontrollerad, granskningsbar del av säkerhetsprogrammet, oavsett vilket moln en given nyckel råkar beröra.

Relaterad läsning från Encryption Consulting

Ytterligare resurser om SSH-nyckellivscykeldisciplin, molnkryptografi och migreringsarbetet som diskuterats ovan:

• Omfattande SSH-nyckellivscykelhantering för företagssäkerhet, Encryption Consultings grundläggande guide till SSH-nycklarägande, rotation, åtkomstpolicy och revisionsbevis i en enskild miljö.
• SSH-sårbarheter och hur man skyddar sig mot dem täcker CVE:er på protokollnivå och implementeringsnivå som påverkar SSH oavsett vilket moln det körs i.
• Incidentrespons för exponerade SSH-nycklar är den fullständiga handboken bakom de koncentrerade stegen i den här guidens avsnitt om incidenthantering.
• Ägarskap för SSH-nyckel går djupare in på att tilldela och tillämpa ägarskapsmodeller för privilegierade autentiseringsuppgifter.
• PQC för molnmiljöer: Delat ansvar mellan AWS, Azure och Google Cloud täcker samma tre-molns jämförelsemodell som tillämpas på ansvar efter kvantmigrering.
• CBOM-säkerhet utökar kryptografisk upptäckt bortom SSH-nycklar till certifikat och algoritmer i alla miljöer, både molnbaserade och lokala.

Vanliga frågor om partihandel med mat och dryck

Roterar AWS, Azure eller GCP SSH-nycklar automatiskt? Nej. Inget av de tre stora molnen roterar SSH-nycklar automatiskt som standard. AWS EC2-nyckelpar och Azure VM authorized_keys-poster förblir giltiga på obestämd tid tills någon manuellt ersätter eller tar bort dem. GCP-metadatanycklar fungerar på samma sätt; GCP:s OS-inloggning ändrar detta endast för IAM-styrd åtkomst, där återkallelse av en användares IAM-roll fungerar som omedelbar rotation, men det omfattar inte tjänstkonton eller metadatabaserade nycklar.

Vad är den verkliga skillnaden mellan GCP OS Login och hur AWS och Azure hanterar SSH-nycklar? OS Login binder SSH-åtkomst direkt till en Google IAM-identitet, så åtkomsten uppdateras automatiskt när IAM-behörigheter ändras och är inte beroende av en lagrad privat nyckel för auktoriseringsbeslut. Både AWS och Azure erbjuder jämförbara IAM-baserade alternativ, AWS Systems Manager Session Manager och Microsoft Entra ID-inloggning för virtuella Linux-maskiner, men båda kräver installation av en separat agent eller ett tillägg och är opt-in-tillägg som läggs ovanpå en nyckelbaserad standard, snarare än en inbyggd SSH-autentiseringsväg som GCP:s OS Login gör.

Kan jag ersätta SSH-nycklar med IAM-baserad åtkomst i alla tre molnen? Du kan gå över till IAM-baserad åtkomst i varje moln individuellt. AWS Session Manager, Azure Entra ID-inloggning och GCP OS-inloggning stöder alla det, men ingen av de tre integreras med de andra. Om du väljer IAM-baserad åtkomst i alla tre molnen har du fortfarande tre separata IAM-system att styra konsekvent, vilket är precis det problem som ett centraliserat SSH-nyckelhanteringslager är byggt för att lösa.

Hur får jag en inventering av SSH-nycklar över AWS, Azure och GCP? Du behöver en identifieringsprocess, eller en dedikerad SSH-nyckelhanteringsplattform, som skannar EC2-nyckelpar över varje AWS-region och konto, VM authorized_keys-poster över varje Azure-prenumeration, och GCP-projekt- eller instansmetadata och OS Login-bindningar, och sedan normaliserar allt till en enda post per nyckel med en tilldelad ägare. Ingen av de tre molnkonsolerna kommer att producera den vyn direkt, eftersom ingen av dem är medvetna om att de andra två existerar.

Betyder aktivering av GCP OS Login att vi inte längre behöver en SSH-nyckelrotationspolicy? Nej. OS Login tar bort lagrade privata nycklar från ekvationen för interaktiva mänskliga inloggningar på GCP Compute Engine, men tjänstkonton, automatisering och alla instanser eller projekt som fortfarande använder metadatabaserade nycklar behåller samma rotationskrav som AWS och Azure. OS Login styr också bara GCP, så en rotationspolicy krävs fortfarande för vilken åtkomstmodell som helst som AWS och Azure använder.

Referensprojekt

• Skapa ett nyckelpar för din Amazon EC2-instansAmazon Web Services
• AWS Systems Manager Session ManagerAmazon Web Services
• Detaljerade steg för att skapa ett SSH-nyckelpar, Microsoft Learn, Azure Virtual Machines
• Logga in på en virtuell Linux-dator i Azure med hjälp av Microsoft Entra ID och OpenSSH, Microsoft Learn
• Om OS-inloggning, Google Cloud, Compute Engine-dokumentation
• Konfigurera OS-inloggning, Google Cloud, Compute Engine-dokumentation
• Bästa praxis för att kontrollera SSH-inloggningsåtkomst, Google Cloud, Compute Engine-dokumentation
• NIST IR 7966: Säkerhet för interaktiv och automatiserad åtkomsthantering med hjälp av Secure Shell (SSH), Nationella institutet för standarder och teknologi
• Hemligheternas tillstånd Sprawl 2026, GitGuardian
• Rapport om maskinidentitetssäkerhetens tillstånd 2025, CyberArk
• Kostnad för en dataintrångsrapport 2025, IBM