Ihr ultimativer Leitfaden für die SSH-Schlüsselverwaltung in Multi-Cloud-Umgebungen

AWS stellt eine herunterladbare .pem-Datei bereit. Azure speichert einen öffentlichen Schlüssel im Ordner „authorized_keys“ einer einzelnen VM. GCP verknüpft den SSH-Zugriff – sofern die Anmeldung über das Betriebssystem aktiviert ist – mit einer IAM-Identität anstatt mit einer Schlüsseldatei. Drei Clouds, drei unterschiedliche Modelle für dieselben Anmeldeinformationen – und die meisten Sicherheitsteams machen diese Erfahrung auf die harte Tour: bei einem Audit, einem Offboarding oder einem Sicherheitsvorfall, wenn niemand eine Liste der SSH-Zugriffsrechte für die gesamte Umgebung erstellen kann.

Veröffentlicht: März 2026. Aktualisiert: August 2026. Geprüft vom Key-Management-Team von Encryption Consulting.

Warum ist die SSH-Schlüsselverwaltung in Multi-Cloud-Umgebungen schwieriger als in Single-Cloud-Umgebungen?

Die Verwaltung von SSH-Schlüsseln in Multi-Cloud-Umgebungen ist komplexer als in Single-Cloud-Umgebungen, da es keine gemeinsame SSH-Schlüsselverwaltungsebene für AWS, Azure und GCP gibt. Jeder Anbieter implementiert, speichert und verwaltet Schlüssel über eigene Mechanismen, die nicht miteinander kompatibel sind. Ein für eine AWS EC2-Instanz generierter Schlüssel hat keine Verbindung zu einem Schlüssel, der auf einer Azure-VM oder einer GCP Compute Engine-Instanz bereitgestellt wird, selbst wenn derselbe Administrator alle drei verwaltet und aus praktischen Gründen dasselbe Schlüsselpaar wiederverwendet.

Diese Diskrepanz zeigt sich auf drei konkrete Arten, sobald eine Organisation ihre Workloads tatsächlich auf mehr als einer Cloud ausführt:

• Fragmentierte Lagerbestände. AWS verwaltet Schlüsselpaare pro Region und Konto, Azure speichert öffentliche Schlüssel pro VM-Datei „authorized_keys“ (oder pro Azure Key Vault-Ressource, falls ein Team die Einrichtung vornimmt), und GCP speichert Schlüssel in Projekt- oder Instanzmetadaten oder in IAM, wenn die Betriebssystemanmeldung aktiviert ist. Keine einzelne Konsole zeigt alle diese Informationen an.
• Inkonsistente Ausgangswerte. Eine in AWS durch interne Prozesse erzwungene Schlüsseltyp- und Rotationsrichtlinie muss in Azure und GCP separat und manuell erzwungen werden, da keine der drei Clouds die Richtlinie einer anderen Cloud für Sie anwendet.
• Wiederverwendete Schlüssel, keine gemeinsame Identität. Ingenieure kopieren aus praktischen Gründen häufig denselben öffentlichen Schlüssel in alle drei Clouds. Dieser Schlüssel hat nun drei separate Verbreitungsradien, drei separate Widerrufspunkte und keinen einzigen Eintrag, der ihn einem bestimmten Besitzer zuordnet.

Eine umfassende Darstellung des SSH-Schlüssellebenszyklusmanagements in beliebigen Umgebungen, einschließlich Eigentümerschaft, Rotationsauslösern, Zugriffsrichtlinien und Prüfnachweisen, finden Sie im Leitfaden „Comprehensive SSH Key Lifecycle Management for Enterprise Security“ von Encryption Consulting . Dieser Leitfaden baut darauf auf und konzentriert sich speziell auf die Änderungen, die sich ergeben, wenn dieselbe Vorgehensweise gleichzeitig für AWS, Azure und GCP gelten muss.

Die Daten hinter der Ausbreitung

Die unkontrollierte Verbreitung von SSH-Schlüsseln ist kein theoretisches Risiko. Aktuelle Analystenberichte, Herstellerstudien und Branchenumfragen belegen mit Zahlen, in welchem ​​Ausmaß unkontrollierte Anmeldeinformationen, einschließlich SSH-Schlüssel, die Governance überholt haben:

• Die Geheimnisverbreitung nimmt schneller Fahrt auf, als die Teams sie verfolgen können. GitGuardians State of Secrets Sprawl 2026 Ein am 17. März 2026 veröffentlichter Bericht stellt fest, dass allein im Jahr 2025 29 Millionen neue, fest codierte Geheimnisse auf öffentlichen GitHub-Konten offengelegt wurden – ein Anstieg von 34 % gegenüber dem Vorjahr und der größte jemals verzeichnete Zuwachs innerhalb eines Jahres. Derselbe Bericht weist darauf hin, dass bei jüngsten Lieferkettenvorfällen, darunter der LiteLLM-Kompromittierung, gezielt SSH-Schlüssel und Cloud-Zugangsdaten erbeutet wurden.
• Maschinenidentitäten, einschließlich SSH-Schlüssel, stellen mittlerweile menschliche Konten in den Schatten. CyberArks Bericht zum Stand der maschinellen Identitätssicherheit 2025Eine Studie, die auf einer Umfrage unter 1,200 Sicherheitsverantwortlichen basiert, ergab, dass Unternehmen davon ausgehen, dass die Zahl der Maschinenidentitäten weiter steigen wird und dass manuelle Prozesse diese nicht mehr in diesem Umfang erfassen können. Das Verhältnis von Maschinenidentitäten zu menschlichen Identitäten liegt demnach bei etwa 82 zu 1.
• Sicherheitslücken, die auf Zugangsdaten basieren, sind am langsamsten aufzudecken und gehören zu den kostspieligsten. IBMs 2025 Kosten eines Datenverletzungsberichts Die Studie ergab, dass Sicherheitsvorfälle, die mit gestohlenen oder kompromittierten Zugangsdaten begannen, im Durchschnitt 4.67 Millionen US-Dollar kosteten und 246 Tage für deren Identifizierung und Eindämmung benötigten – einer der längsten Lebenszyklen von Sicherheitsvorfällen, die der Bericht erfasst.

Bei Multi-Cloud-Umgebungen vervielfacht sich jede dieser Zahlen, da derselbe Schlüssel, ohne dass er erfasst wird, in drei separaten Inventaren anstatt in einem existieren kann.

Wie handhaben AWS, Azure und GCP jeweils SSH-Schlüssel nativ?

AWS, Azure und GCP behandeln den SSH-Schlüsselzugriff jeweils als Detail auf Instanz- oder Projektebene und nicht als zentral verwaltete Anmeldeinformation. GCP bildet hier eine Ausnahme: Die Funktion „OS Login“ ermöglicht die Verknüpfung des SSH-Zugriffs mit einer IAM-Identität anstelle eines gespeicherten Schlüssels. AWS und Azure bieten diese Funktion lediglich als separate, optionale Zusatzdienste an, die auf ihrem Standard-Schlüsselmodell aufbauen.

AWS: EC2-Schlüsselpaare

Das Standardmodell von AWS ist das EC2-Schlüsselpaar. Wenn Sie eine Instanz über die Konsole, die Befehlszeilenschnittstelle (CLI) oder CloudFormation starten, speichert AWS den öffentlichen Schlüssel zusammen mit der Instanz und gibt Ihnen genau einen Versuch, den privaten Schlüssel herunterzuladen. AWS-eigenes EC2-BenutzerhandbuchSchlüsselpaare sind regionsspezifisch, mit einem dokumentierten Limit von 5,000 Schlüsselpaaren pro Region und Konto. Es gibt keinen integrierten Mechanismus zum Teilen von Schlüsselpaaren zwischen Regionen oder Konten. AWS unterstützt sowohl RSA- als auch ED25519-Schlüssel und ermöglicht den Import extern generierter öffentlicher Schlüssel anstelle von AWS-generierten Schlüsseln. Die Dokumentation beschreibt jedoch keine automatische Rotationsfunktion. Die Rotation eines EC2-Schlüsselpaares bedeutet, einen neuen Schlüssel zu generieren und den vorhandenen zu aktualisieren. authorized_keys bei jeder betroffenen Instanz und die Außerbetriebnahme des alten Schlüsselpaares, manuell oder durch Ihre eigene Automatisierung.

AWS bietet mit dem AWS Systems Manager Session Manager eine IAM-basierte Alternative, die den Bedarf an einem gespeicherten privaten Schlüssel oder einem offenen eingehenden SSH-Port überflüssig macht. Er ist nicht standardmäßig aktiviert: Er erfordert den auf der Instanz ausgeführten SSM-Agenten und eine IAM-Rolle, die der Instanz die Berechtigung zur Kommunikation mit Systems Manager erteilt. Session Manager ermöglicht IAM-gesteuerten Zugriff und Sitzungsprotokollierung, existiert aber parallel zu EC2-Schlüsselpaaren, anstatt diese in Umgebungen zu ersetzen, in denen bereits schlüsselbasierter Zugriff in Skripten, Images und CI/CD-Pipelines integriert ist.

Azure: SSH-Schlüssel pro VM

Das Standardmodell von Azure ähnelt dem von AWS, ist aber noch enger gefasst und auf die einzelne VM beschränkt. Dokumentation zu Microsoft Azure Virtual MachinesSie generieren ein Schlüsselpaar (üblicherweise RSA oder ED25519, mithilfe von ssh-keygen oder unter der az vm create --generate-ssh-keys Flagge) und der öffentliche Schlüssel wird in die VM geschrieben. ~/.ssh/authorized_keys Die Datei wird bei der Erstellung angelegt. Der private Schlüssel verbleibt auf dem lokalen Rechner, der ihn generiert hat. Dasselbe Schlüsselpaar kann auf mehreren VMs wiederverwendet werden, was die Einrichtung vereinfacht, aber auch bedeutet, dass ein kompromittierter privater Schlüssel jede VM erreichen kann, auf die er jemals kopiert wurde. Die Microsoft-Dokumentation beschreibt weder eine Schlüsselverwaltung auf Abonnementebene noch eine in den Standard-VM-Erstellungsprozess integrierte Azure Key Vault-Funktion oder eine automatische Schlüsselrotation. Zwar kann ein Team Key Vault in ein Bereitstellungsskript einbinden, um ein Schlüsselpaar zu generieren und zu speichern, dies ist jedoch ein individuell entwickeltes Muster und keine Standardfunktion von Azure.

Die IAM-basierte Alternative von Azure ist Microsoft Entra ID-Anmeldung für Linux-VMs, das SSH-Sitzungen anhand von Entra-ID-Anmeldeinformationen und Azure-RBAC-Rollenzuweisungen anstelle eines statischen Schlüssels authentifiziert. Wie AWS Session Manager ist es optional: Es erfordert die Installation von AADSSHLoginForLinux Die VM-Erweiterung ermöglicht die Einrichtung einer systemseitig zugewiesenen verwalteten Identität und die Zuweisung von Rollen wie z. B. „Anmeldung als Administrator virtueller Maschinen“. Die standardmäßige SSH-Authentifizierung mit öffentlichen Schlüsseln ist weiterhin der Azure-Standard, und die meisten Umgebungen verwenden eine Mischung aus Entra-fähigen und reinen Schlüssel-VMs anstelle eines einheitlichen Modells.

GCP: Metadatenschlüssel oder Betriebssystemanmeldung, die an IAM gebunden ist

GCP beginnt an der gleichen Stelle wie AWS und Azure: Standardmäßig liest die Compute Engine SSH-Public-Keys aus den Projekt- oder Instanzmetadaten und schreibt sie in authorized_keys auf der Ziel-VM, pro Googles eigene Anleitung zum Hinzufügen von SSH-Schlüsseln zu VMsWas GCP auszeichnet, ist OS-AnmeldungDiese Funktion ersetzt metadatenbasierte Schlüssel durch IAM-gesteuerte Zugriffsrechte. Bei aktivierter Betriebssystemanmeldung gewährt ein Administrator einem Benutzer die entsprechenden Berechtigungen. roles/compute.osLogin or roles/compute.osAdminLogin Anstelle der Verteilung einer Schlüsseldatei verwendet Google eine IAM-Rolle. Die Dokumentation von Google beschreibt eine kontinuierliche, sitzungsbezogene Auswertung: Wenn ein Administrator die IAM-Berechtigung eines Benutzers entfernt, wird dessen SSH-Zugriff sofort widerrufen, ohne dass jemand eine VM oder eine andere Schnittstelle berührt. authorized_keys OS Login unterstützt außerdem die Zwei-Faktor-Authentifizierung über Google Authenticator, SMS oder Sicherheitsschlüssel und protokolliert Verbindungsversuche zu Prüfungszwecken. Best Practices für den SSH-Login-Zugriff bei Google.

Die Betriebssystemanmeldung ist auch nicht die Standardeinstellung von GCP; sie muss mit einem Befehl aktiviert werden. enable-oslogin=TRUE Metadatenkennzeichen auf Projekt- oder Instanzebene, gemäß Googles Dokumentation zur Einrichtung der OS-AnmeldungDer eigentliche Unterschied liegt darin, was passiert, sobald es eingeschaltet ist: Die Betriebssystemanmeldung steuert den SSH-Zugriff über dieselbe Schnittstelle. ssh Der Befehl und der Standard-OpenSSH-Client nutzen IAM als zentrale Informationsquelle, ohne dass ein separater Agent oder eine Erweiterung wie bei AWS Session Manager und Azure Entra ID erforderlich ist. Dadurch lässt sich der IAM-basierte SSH-Zugriff in einer GCP-Umgebung deutlich einfacher und konsistenter implementieren als in den anderen beiden Cloud-Diensten, obwohl auch hier der gleiche sorgfältige Rollout-Prozess wie bei AWS und Azure notwendig ist.

Entscheidungstabelle: Cloud-Anbieter vs. native SSH-Schlüsselverwaltung vs. Zentralisierungslücke

Cloud-Anbieter	Native SSH-Schlüsselverarbeitung	Zentralisierungslücke
AWS	EC2-Schlüsselpaare pro Region; öffentlicher Schlüssel wird mit der Instanz gespeichert, privater Schlüssel kann einmalig heruntergeladen werden; RSA oder ED25519; bis zu 5,000 Paare pro Region; optionaler IAM-basierter Systems Manager Session Manager als Add-on	Keine integrierte Rotation; keine regions- oder kontoübergreifende Schlüsselverwaltung; Session Manager erfordert separate Einrichtung eines SSM-Agenten und einer IAM-Rolle und entfernt keine vorhandenen Schlüsselpaare.
Azure	VM-spezifische authorized_keys-Einträge, generiert über CLI, Portal oder ARM-Vorlage; wiederverwendbar für mehrere VMs; optionale Microsoft Entra ID-Anmeldung für Linux als Add-on	Es ist kein Schlüsselinventar auf Abonnementebene dokumentiert; keine automatische Rotation; die Anmeldung mit Entra ID erfordert zusätzlich zum Standardschlüsselmodell die AADSSHLoginForLinux-Erweiterung und die RBAC-Rollenzuweisung.
GCP	Standardmäßig werden Projekt- oder Instanzmetadatenschlüssel verwendet; alternativ kann die Betriebssystemanmeldung genutzt werden, um den Zugriff an eine IAM-Identität zu binden, mit kontinuierlicher Berechtigungsprüfung und optionaler Zwei-Faktor-Authentifizierung.	OS Login muss explizit aktiviert werden; eine GCP-Umgebung, die OS Login nie aktiviert, ist genauso dezentralisiert wie AWS oder Azure; OS Login selbst erstreckt sich nicht auf AWS- oder Azure-Ressourcen.

Jede Zeile in dieser Tabelle beschreibt eine einzelne Cloud isoliert. Keiner der drei Mechanismen – EC2-Schlüsselpaare, Azure-Authorized-Keys-Dateien oder GCP-OS-Login – erzeugt einen Datensatz, der die anderen beiden umfasst. Genau diese Zentralisierungslücke muss ein Multi-Cloud-Programm bewusst schließen, da kein Anbieter dies automatisch tut.

Wem gehört der Lebenszyklus von SSH-Schlüsseln über Cloud-Grenzen hinweg?

In einer einzelnen Cloud lässt sich die Eigentümerschaft zumindest theoretisch auf denjenigen zurückführen, der das Schlüsselpaar, die VM oder die IAM-Bindung in diesem einen Konto erstellt hat. Über drei Clouds hinweg bricht diese Spur ab, es sei denn, die Eigentümerschaft wird zentral und unabhängig von der Plattform zugewiesen, auf der sich der jeweilige Schlüssel befindet.

Stadium des Lebenszyklus	Realität einer einzigen Wolke	Was sich über drei Wolken bricht
Generation	Ein Techniker erstellt oder importiert ein Schlüsselpaar in einer Konsole.	Dasselbe Schlüsselpaar wird aus praktischen Gründen häufig in AWS, Azure und GCP wiederverwendet, sodass ein Ereignis der Generation nun drei separate Auslöseradien ohne gemeinsamen Datensatz aufweist.
Die Anerkennung	Der Teamleiter oder ein Sicherheitsmitarbeiter prüft die Anfrage im Workflow der jeweiligen Cloud.	Die Genehmigungsworkflows unterscheiden sich je nach Cloud (IAM-Richtlinienzuordnung in AWS, RBAC-Rollenzuweisung in Azure, IAM-Rolle für die Betriebssystemanmeldung in GCP), daher muss ein einheitlicher Genehmigungsstandard über alle drei Plattformen gelegt werden.
Provisioning	Der öffentliche Schlüssel wurde in die Metadaten, die Datei authorized_keys oder die IAM-Bindung dieser Cloud geschrieben.	Es gibt keine gemeinsame Bereitstellungs-API; ein zentrales Tool oder ein dokumentiertes Runbook muss dieselbe Richtlinie durch drei verschiedene Bereitstellungsmechanismen übertragen.
Anwendungsbereich	Die native Protokollierung dieser Cloud (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) zeichnet die Sitzung auf.	Drei unterschiedliche Protokollformate und Aufbewahrungsrichtlinien bedeuten, dass die Nutzungsnachweise normalisiert werden müssen, bevor sie für eine cloudübergreifende Zugriffsprüfung nützlich sind.
Rotation und Stilllegung	Der Schlüssel wurde aus der Instanz oder den Metadaten dieser einen Cloud entfernt.	Die Abmeldung eines Ingenieurs, der Zugriff auf alle drei Clouds hatte, erfordert drei separate Abmeldevorgänge, von denen jeder unabhängig voneinander übersehen werden kann, es sei denn, ein System löst alle drei aus.

Die praktische Lösung besteht darin, für jeden Schlüssel bei dessen Erstellung einen verantwortlichen Eigentümer – eine Rolle und nicht nur eine Person – festzulegen und in diesem Datensatz zu erfassen, auf welche Cloud(s) dieser Schlüssel zugreift. Diese eine Änderung ermöglicht es, dass eine Checkliste für den Austritt von Mitarbeitern oder ein Audit den „SSH-Zugriff dieser Person“ als einen einzigen Punkt anstatt als drei behandelt.

Was sollte die Rotation auslösen, und warum ist die Cloud-native Rotation oft manuell oder unvollständig?

Die Rotation des SSH-Schlüssels sollte in jeder Cloud unter denselben drei Bedingungen ausgelöst werden: Ablauf der Kryptoperiode, Personal- oder Rollenwechsel und Verdacht auf Kompromittierung (gemäß dem allgemeinen Rahmenwerk in NIST IR 7966) . In einer Multi-Cloud-Umgebung ändert sich jedoch, dass keiner der drei Anbieter alle drei Auslöser automatisiert und keiner die Schlüsselrotation automatisch durchführt, ohne dass Sie diese Automatisierung selbst implementieren.

• AWS Es gibt keine geplante Rotation für EC2-Schlüsselpaare. Rotation bedeutet, ein neues Schlüsselpaar zu generieren und den neuen öffentlichen Schlüssel an alle betroffenen Instanzen zu übertragen. authorized_keys Die Datei muss (manuell, über den Systems Manager oder Ihre eigene Konfigurationsverwaltung) bearbeitet und das alte Schlüsselpaar aus dem Konto gelöscht werden. Die Plattform weist Sie nicht darauf hin, dass dies überfällig ist.
• Azure Dasselbe gilt für die VM-Ebene: Nichts erzwingt eine Aktualisierung des vorhandenen Schlüssels. authorized_keysDa dasselbe Schlüsselpaar häufig auf vielen VMs wiederverwendet wird, bedeutet ein Rotationsereignis in Azure oft, dass Dutzende von VMs einzeln aktualisiert werden müssen, es sei denn, dies wird vom Konfigurationsmanagement übernommen.
• GCP Metadatenschlüssel verhalten sich wie die anderen beiden: Sie laufen nicht automatisch ab und werden nicht aktualisiert. OS Login verändert die Problematik, anstatt die Rotation direkt zu lösen, da der Zugriff an eine IAM-Bindung anstatt an einen statischen Schlüssel gebunden ist. Das Entziehen der IAM-Rolle erfolgt praktisch sofort, was der Rotation beim interaktiven Zugriff durch Benutzer entspricht. Dienstkontoschlüssel und alle noch verwendeten metadatenbasierten Schlüssel folgen jedoch demselben manuellen Muster wie AWS und Azure.

Die praktische Konsequenz: Eine Rotationsrichtlinie, die allgemein für „SSH-Schlüssel“ geschrieben wurde, wird in einer Multi-Cloud-Umgebung stillschweigend scheitern, es sei denn, sie legt für jede Cloud genau fest, welche Aktion diese Richtlinie erfüllt, da „den Schlüssel rotieren“ auf jeder Plattform eine andere Abfolge von Schritten bedeutet.

Wie lässt sich eine konsistente Zugriffsrichtlinie über drei verschiedene IAM-Modelle hinweg gewährleisten?

AWS IAM, Azure RBAC und Google Cloud IAM definieren Zugriffskontrolle so unterschiedlich, dass eine für ein System erstellte Richtlinie nicht direkt auf die anderen übertragbar ist. Um konsistente Zugriffsrichtlinien zu gewährleisten, muss die Richtlinie einmalig cloudunabhängig definiert und anschließend separat in das jeweilige Modell jedes Anbieters integriert werden, anstatt eine einzige native Richtlinie zu erstellen und auf Generalisierbarkeit zu hoffen.

• Minimale Privilegien, ausgedrückt pro Plattform. „Produktionsdatenbankadministratoren erhalten SSH-Zugriff auf Produktionsdatenbankhosts“ muss zu einer bereichsbezogenen IAM-Richtlinie in AWS, einer bereichsbezogenen RBAC-Rollenzuweisung in Azure und einer bereichsbezogenen OS-Login-IAM-Rolle in GCP werden – drei separate Konfigurationen, die die gleiche Absicht durchsetzen.
• Quellen- und Befehlsbeschränkungen. Keine der drei Cloud-Lösungen erzwingt Quell-IP- oder Befehlsbeschränkungen für SSH-Sitzungen nativ auf Plattformebene in gleicher Weise; diese Kontrollmechanismen werden, sofern verwendet, typischerweise im Schlüssel konfiguriert. authorized_keys Der Zugriff erfolgt entweder direkt über den Anmeldevorgang (AWS, Azure) oder über die vom Betriebssystem unterstützten Optionen (GCP). Daher müssen die Schlüssel von dem Prozess, der sie bereitstellt, konsequent angewendet werden und dürfen nicht von der Cloud übernommen werden.
• Funktionstrennung. Die Person, die eine Zugriffsanfrage genehmigt, sollte nicht dieselbe Person sein, die sie bereitstellt. Diese Regel lässt sich innerhalb des Workflows einer Cloud leicht durchsetzen, gerät aber leicht aus dem Blick, wenn drei separate Workflows nebeneinander existieren.
• Dienstkonto- und Automatisierungsschlüssel. CI/CD-Pipelines und Konfigurationsmanagement-Tools verwenden häufig langlebige SSH-Schlüssel mit großer Reichweite über Cloud-Grenzen hinweg; diese Schlüssel benötigen die gleiche Disziplin in Bezug auf Richtlinien wie menschliche Schlüssel, möglicherweise sogar mehr, da sie kontinuierlich verwendet werden und eine Kompromittierung schwerer zu bemerken ist.

Eine Cloud-agnostische SSH-Schlüsselverwaltungsschicht, die über AWS IAM, Azure RBAC und GCP IAM angesiedelt ist, anstatt ein viertes, inkompatibles Modell zu sein, macht „eine Richtlinie, drei Durchsetzungen“ erreichbar statt nur ein Wunschtraum.

Wie erzeugt man Prüfnachweise über mehrere Cloud-Konsolen hinweg?

Die Erstellung von Prüfnachweisen für AWS, Azure und GCP erfordert das Abrufen von Belegen für Anfrage, Genehmigung, Bereitstellung, Nutzung und Kündigung aus drei separaten Protokollierungssystemen, deren Normalisierung und die Darstellung als ein Datensatz pro Berechtigung anstatt drei voneinander getrennter Fragmente. Frameworks wie SOC 2, ISO/IEC 27001 und PCI DSS setzen voraus, dass ein Unternehmen nachweist, dass Zugriffe zeitnah überprüft und widerrufen werden. Ein Prüfer, der fragt: „Wer konnte sich per SSH in dieses System einloggen und dies nachweisen?“, interessiert sich nicht dafür, ob die Antwort drei verschiedene Cloud-Konsolen umfasst.

• AWS Die Beweise stammen aus CloudTrail (API-Aktionen auf Schlüsselpaarebene) und, sofern verwendet, aus den Sitzungsprotokollen des Session Managers; keines von beiden protokolliert nativ, welche Person den privaten Schlüssel für ein bestimmtes EC2-Schlüsselpaar besaß, sondern nur, dass das Schlüsselpaar existierte und welche API-Aufrufe darauf zugegriffen haben.
• Azure Die Beweise stammen aus dem Azure-Aktivitätsprotokoll und den Authentifizierungsdatensätzen auf VM-Ebene; da ein Schlüsselpaar auf vielen VMs wiederverwendet werden kann, erfordert die Zuordnung eines bestimmten Anmeldeereignisses zu einer bestimmten Person einen Abgleich mit dem privaten Schlüssel, den diese Person tatsächlich besitzt – Informationen, die Azure selbst nicht erfasst.
• GCP Die Beweiskraft ist am größten, wenn OS Login aktiviert ist, da Cloud Audit Logs dann jede Sitzung direkt mit einer IAM-Identität und nicht mit einem anonymen Schlüssel verknüpfen; ohne OS Login weist die Metadaten-Schlüsselprotokollierung von GCP die gleiche Besitzlücke auf wie AWS und Azure.

Die Lösung ist dieselbe, die auch das Problem der Besitzverhältnisse über den gesamten Lebenszyklus hinweg löst: Bei der Ausstellung wird ein Eigentümer zugewiesen, es wird protokolliert, mit welcher Cloud oder welchen Clouds ein Schlüssel in Kontakt kommt, und die Nutzungsprotokolle aller drei Konsolen werden in ein System, eine SIEM-Plattform wie Splunk oder ein dediziertes SSH-Schlüsselverwaltungstool eingespeist, sodass die Prüfnachweise kontinuierlich gesammelt und nicht jedes Mal unter Zeitdruck neu erstellt werden müssen, wenn ein Prüfer danach fragt.

Ein praktischer Workflow zur Zentralisierung der SSH-Schlüsselverwaltung in Multi-Cloud-Umgebungen

Die zentrale Verwaltung von SSH-Schlüsseln über AWS, Azure und GCP hinweg erfordert weder die Aufhebung bestehender Zugriffsrechte noch die Unterbrechung laufender Workloads. Es bedeutet, Erkennung, Richtlinien und Automatisierung in einer definierten Reihenfolge auf die bereits vorhandenen Funktionen der einzelnen Cloud-Plattformen aufzubauen:

1. Erfassen Sie jeden Schlüssel in jedem Konto, Projekt und Abonnement. Scannen Sie AWS-Regionen und -Konten nach EC2-Schlüsselpaaren, Azure-Abonnements nach Einträgen in der Datei „authorized_keys“ von VMs und GCP-Projekte nach Metadatenschlüsseln und OS-Login-Bindungen. Die manuelle Ermittlung in diesem Umfang ist, wie NIST IR 7966 selbst über SSH-Schlüsselinventare im Allgemeinen ausführt, „praktisch unmöglich“. Daher sollte dieser Schritt von Anfang an automatisiert werden.
2. Ordnen Sie jeden Schlüssel einem Besitzer und einer Cloud zu. Dokumentieren Sie, wer für welchen Schlüssel verantwortlich ist und auf welche Cloud(s) dieser Schlüssel Zugriff gewährt. Ein Schlüssel, der auf allen drei Plattformen kopiert wurde, sollte als einzelnes, risikoreiches Attribut gekennzeichnet und nicht als drei unabhängige Einträge erfasst werden.
3. Entscheiden Sie pro Cloud zwischen nativen Schlüsseln und der IAM-basierten Alternative. Prüfen Sie AWS Systems Manager Session Manager, Microsoft Entra ID Login für Linux-VMs und GCP OS Login im Hinblick auf die betrieblichen Anforderungen Ihrer Umgebung. Keine dieser Lösungen ist zwingend erforderlich, aber jede von ihnen entfernt einen statischen privaten Schlüssel vom täglichen Benutzerzugriff, sofern sie eingesetzt wird.
4. Vereinheitlichung der Richtlinien über alle drei Clouds hinweg. Legen Sie einen Standard für Schlüsseltyp und -länge, einen Rotationszyklus pro Risikostufe und einen Workflow für die Zugriffsgenehmigung fest und setzen Sie diese eine Richtlinie dann durch die Bereitstellung in jeder Cloud durch, anstatt drei separate, sich ständig ändernde Richtlinien zu schreiben.
5. Rotation und Deaktivierung zentral automatisieren. Ein Offboarding-Ereignis sollte die Schlüsselentfernung in AWS, Azure und GCP als eine einzige Aktion auslösen, nicht drei separate Tickets, die davon abhängen, dass drei verschiedene Personen daran denken, sie zu schließen.
6. Die Nutzungsprotokolle aller drei Clouds werden in einer einzigen Ansicht zusammengeführt. Leiten Sie SSH-relevante Ereignisse aus CloudTrail, Azure Activity Log und GCP Cloud Audit Log an eine gemeinsam genutzte SIEM- oder dedizierte SSH-Schlüsselverwaltungsplattform weiter, sodass eine Zugriffsprüfung oder ein Audit nur eine Quelle anstatt drei benötigt.
7. Testen Sie die Reaktion auf Cloud-übergreifende Vorfälle, bevor Sie sie benötigen. Führen Sie eine Planspielübung für den Fall durch, dass „dieser Schlüssel kompromittiert wurde und in zwei unserer drei Clouds wiederverwendet wurde“, bevor dieses Szenario tatsächlich eintritt.

Wie sollten Sie reagieren, wenn ein SSH-Schlüssel über mehrere Clouds hinweg kompromittiert wird?

Ein kompromittierter SSH-Schlüssel, der in einer Cloud auftaucht, muss so lange als Multi-Cloud-Vorfall behandelt werden, bis das Gegenteil bewiesen ist, da die Wiederverwendung von Schlüsseln über AWS, Azure und GCP hinweg so üblich ist, dass derselbe private Schlüssel häufig an mehr als einem Ort gültig ist.

1. In der Cloud speichern, wo es zuerst gefunden wurde. Entfernen Sie das AWS EC2-Schlüsselpaar und löschen Sie den Eintrag aus den betroffenen Azure-VMs. authorized_keys Die Datei oder die GCP IAM-Rolle, die den OS-Login-Zugriff unterstützt, kann sofort widerrufen werden, ohne eine vollständige Untersuchung abzuwarten.
2. Prüfen Sie, ob in den anderen beiden Clouds eine Wiederverwendung möglich ist. Durchsuchen Sie Ihren Bestand (erstellt im obigen Workflow) nach demselben öffentlichen Schlüssel-Fingerabdruck in AWS, Azure oder GCP. Ein einmal generierter Schlüssel, der in drei Umgebungen kopiert wird, ist eines der häufigsten Muster für die Ausbreitung in Multi-Cloud-Umgebungen und der schnellste Weg, wie ein Vorfall in einer Cloud zu einem Vorfall in allen drei wird.
3. Authentifizierungsprotokolle von allen drei Konsolen abrufen. Rekonstruieren Sie die Zugriffszeitleiste mithilfe von AWS CloudTrail, Azure Activity Log und VM-Authentifizierungsdatensätzen sowie GCP Cloud Audit Logs, wobei Sie insbesondere nach Sitzungen aus unerwarteten Quellen oder zu unerwarteten Zeiten suchen.
4. Rotieren Sie die nachgelagerten Anmeldeinformationen, die der Schlüssel erreichen kann. Ein Schlüssel, der einen Bastion-Host in einer Cloud geöffnet hat, kann ein erster Schritt zu Anmeldeinformationen, Geheimnissen oder zusätzlichen Schlüsseln in einer anderen Cloud sein; behandeln Sie alles, was von der kompromittierten Sitzung aus erreichbar ist, als potenziell gefährdet.
5. IAM-Berechtigungen müssen unverzüglich überall dort widerrufen werden, wo IAM-basierter Zugriff genutzt wurde. Wenn der Zugriff über OS Login oder Entra ID Login geregelt wird, entfernt das Trennen der IAM- oder RBAC-Bindung den Zugriff sofort, ohne dass jede VM einzeln angefasst werden muss – schneller als die Rotation eines verteilten statischen Schlüssels.
6. Dokumentieren Sie nur einen Vorfallsbericht, nicht drei. Die Ergebnisse aller drei Clouds werden in einem einzigen Datensatz zusammengefasst, der die Rotation, die Überprüfung und die für die Reaktion relevanten Nachweise enthält und direkt in den oben beschriebenen Prüfnachweisprozess einfließt.

Dies ist eine Zusammenfassung der unmittelbaren Reaktion in einer Multi-Cloud-Umgebung und kein vollständiger Leitfaden für die Reaktion auf Sicherheitsvorfälle. Eine detaillierte Schritt-für-Schritt-Anleitung zum Umgang mit einem offengelegten SSH-Schlüssel finden Sie im Leitfaden „ Incident Response for Exposed SSH Keys“ von Encryption Consulting.

Einschränkungen

• Die hier beschriebenen nativen Cloud-Verhaltensweisen spiegeln die Dokumentation von AWS, Azure und GCP vom Jahr 2026 wider; alle drei Anbieter aktualisieren die IAM- und VM-Zugriffsfunktionen regelmäßig. Überprüfen Sie daher das aktuelle Verhalten anhand der Live-Dokumentation des jeweiligen Anbieters, bevor Sie eine darauf basierende Steuerung endgültig festlegen.
• Die GCP-Betriebssystemanmeldung muss für jedes Projekt oder jede Instanz explizit aktiviert werden; sie ist nicht standardmäßig in GCP enthalten. Eine GCP-Umgebung, in der diese Funktion nie aktiviert ist, ist genauso dezentralisiert wie eine AWS- oder Azure-Umgebung.
• AWS Systems Manager Session Manager und Microsoft Entra ID Login für Linux VMs entfernen den lokalen privaten Schlüssel aus dem täglichen Zugriff, aber beide sind weiterhin von einer korrekt definierten IAM- oder RBAC-Richtlinie abhängig; eine falsch konfigurierte IAM-Rolle verlagert das Risiko lediglich von einem verwaisten SSH-Schlüssel auf eine überprivilegierte Identität.
• Dieser Leitfaden behandelt AWS, Azure und GCP, die drei Hyperscaler, auf denen die meisten Multi-Cloud-Umgebungen von Unternehmen laufen. Kleinere oder regionale Cloud-Anbieter sowie On-Premises- oder Hybrid-Infrastrukturen benötigen dieselbe Vorgehensweise bei der Datenermittlung und -zentralisierung, die hier beschrieben wird, auch wenn sich ihre nativen Tools von den drei hier behandelten unterscheiden.
• Die hier gegebenen Hinweise sind allgemeiner Natur. Regulierte Umgebungen (FIPS 140-3, PCI DSS, HIPAA, DORA) sollten spezifische Rotationszyklen und Kontrollentscheidungen anhand ihrer eigenen Compliance-Verpflichtungen überprüfen, bevor sie die Richtlinien endgültig festlegen.

Was würde Encryption Consulting empfehlen?

Wir würden den Multi-Cloud-SSH-Zugriff als einen einzigen verwalteten Zugangsdatenbestand behandeln, nicht als drei cloudspezifische Probleme, die von drei separaten Teams bearbeitet werden. In unseren Projekten wiederholt sich das Muster: Eine Organisation verfügt über relativ ausgereifte Sicherheitsvorkehrungen in einer Cloud – oft dort, wo das Sicherheitsteam seine Aufmerksamkeit ursprünglich darauf gerichtet hat – und hat kaum Einblick in die anderen beiden, da AWS, Azure oder GCP keine standardmäßige cloudübergreifende Transparenz gewährleisten.

Mit SSH Secure bietet Encryption Consulting Unternehmen eine zentrale Bestands- und Lebenszyklusübersicht für AWS, Azure, GCP und ihre lokale Infrastruktur – anstatt drei separate Ansichten pro Cloud, die ein Sicherheitsteam manuell abgleichen muss. So sieht das in der Praxis aus:

1. Zentralisierte Transparenz- und Eigentumszuordnung

Durch agentenbasierte und agentenlose Erkennung findet SSH Secure jeden SSH-Schlüssel in AWS-, Azure- und GCP-Instanzen sowie auf lokalen Servern und speichert sie in einem einzigen Inventar mit Eigentums- und Nutzungsdetails. Dadurch entfallen die fragmentierten, Cloud-spezifischen Tabellenkalkulationen, mit denen die meisten Teams üblicherweise arbeiten.

2. Sichere Zugriffskontrolle und Durchsetzung sitzungsgebundener Schlüssel

Die detaillierte rollenbasierte Zugriffskontrolle stellt sicher, dass Benutzer nur die minimal erforderlichen Zugriffsrechte erhalten. Diese werden unabhängig davon, ob sich das Zielsystem in AWS, Azure oder GCP befindet, identisch durchgesetzt. Für sensible oder temporäre Vorgänge stellt SSH Secure temporäre, sitzungsgebundene Schlüssel aus, die automatisch ablaufen. Dadurch wird der potenzielle Schaden begrenzt, unabhängig davon, welche Cloud die Sitzung nutzt.

3. Automatisierte Orchestrierung des Schlüssellebenszyklus über Clouds hinweg

SSH Secure automatisiert Generierung, richtlinienbasierte Rotation, geplante Ablaufdaten und Widerruf als einen einzigen Workflow, der AWS, Azure und GCP gleichzeitig erreicht, sodass ein Offboarding-Ereignis den Zugriff auf alle drei Clouds in einer einzigen Aktion entfernt, anstatt drei separate manuelle Schritte durchzuführen.

4. HSM-integrierter Schutz

Private Schlüssel werden in HSMs sicher gespeichert , wodurch ihre Nichtexportierbarkeit und Manipulationssicherheit gewährleistet sind, unabhängig davon, auf welche Cloud ein Schlüssel letztendlich Zugriff autorisiert. Die Schlüssel werden mithilfe starker Algorithmen wie RSA -4096, ECDSA und Ed25519 generiert und bleiben vom Arbeitsspeicher des Betriebssystems isoliert, selbst wenn ein Host in einer der drei Clouds kompromittiert wird.

5. Richtliniengesteuerte Regelung wichtiger Betriebsabläufe

Alle wichtigen Vorgänge, Generierung, Genehmigungsworkflows, Rotation und Widerruf werden durch richtlinienbasierte Kontrollen durchgesetzt, die unabhängig davon, welche Cloud eine Anfrage berührt, identisch gelten und die drei separaten, sich verändernden Richtlinien ersetzen, die sich organisch entwickeln, wenn jedes Cloud-Team seine eigenen Regeln schreibt.

6. Kontinuierliche Überwachung, Prüfung und Einhaltung der Vorschriften

SSH Secure bietet Echtzeitüberwachung mit detaillierter Ereignisprotokollierung und ist in Splunk- oder Loki-Grafana-Dashboards integriert. So fließen alle Aktivitäten von AWS, Azure und GCP in einen einzigen Audit-Trail anstatt in drei getrennte Konsolenprotokolle. Zentralisierte, richtlinienbasierte Warnmeldungen ermöglichen eine schnellere Anomalieerkennung und Reaktion auf Vorfälle in der gesamten Multi-Cloud-Umgebung.

Fazit

AWS, Azure und GCP lösen das Problem des SSH-Schlüsselzugriffs jeweils für ihre eigenen Instanzen, jedoch nicht für Ihr gesamtes Unternehmen. Diese Lücke, nicht die Schwäche einer einzelnen Cloud, führt dazu, dass der SSH-Zugriff in mehreren Clouds fragmentierte Bestände, inkonsistente Rotation und Audit-Nachweise erfordert, die unter Zeitdruck aus drei verschiedenen Konsolen zusammengetragen werden müssen. Werden SSH-Schlüssel hingegen als einheitlicher, verwalteter Bestand an Anmeldeinformationen behandelt – mit bei der Ausstellung zugewiesener Eigentümerschaft, Rotationsauslösern, die die jeweiligen Mechanismen der einzelnen Clouds berücksichtigen, konsistent durchgesetzten Richtlinien in allen drei IAM-Modellen und kontinuierlich erfassten statt rekonstruierten Audit-Nachweisen –, so wird der SSH-Zugriff in mehreren Clouds von einem versteckten, fragmentierten Risiko zu einem kontrollierten, auditierbaren Bestandteil des Sicherheitsprogramms, unabhängig davon, mit welcher Cloud ein bestimmter Schlüssel in Kontakt steht.

Weiterführende Lektüre von Encryption Consulting

Weiterführende Ressourcen zum Thema SSH-Schlüssellebenszyklus, Cloud-Kryptographie und den oben beschriebenen Migrationsarbeiten:

• Umfassendes SSH-Schlüssellebenszyklusmanagement für die UnternehmenssicherheitDer Leitfaden von Encryption Consulting zu SSH-Schlüsselbesitz, -Rotation, -Zugriffsrichtlinien und Prüfnachweisen in jeder beliebigen Umgebung.
• SSH-Schwachstellen und wie man sich davor schützt umfasst CVEs auf Protokoll- und Implementierungsebene, die SSH unabhängig von der verwendeten Cloud betreffen.
• Reaktion auf Sicherheitsvorfälle bei offengelegten SSH-Schlüsseln ist der vollständige Handlungsplan, der den zusammengefassten Schritten im Abschnitt „Vorfallreaktion“ dieses Leitfadens zugrunde liegt.
• SSH-Schlüsselbesitz geht detaillierter auf die Zuweisung und Durchsetzung von Eigentumsmodellen für privilegierte Anmeldeinformationen ein.
• PQC für Cloud-Umgebungen: Gemeinsame Verantwortung für AWS, Azure und Google Cloud umfasst das gleiche Drei-Wolken-Vergleichsmodell, das auf die Verantwortung für die Migration nach der Quantenmigration angewendet wird.
• CBOM Secure erweitert die kryptografische Erkennung über SSH-Schlüssel hinaus auf Zertifikate und Algorithmen in jeder Umgebung, sowohl in der Cloud als auch lokal.

Häufig gestellte Fragen

Rotieren AWS, Azure oder GCP SSH-Schlüssel automatisch? Nein. Keine der drei großen Cloud-Plattformen rotiert SSH-Schlüssel standardmäßig automatisch. AWS EC2-Schlüsselpaare und Einträge in der Datei `authorized_keys` von Azure-VMs bleiben unbegrenzt gültig, bis sie manuell ersetzt oder entfernt werden. GCP-Metadatenschlüssel verhalten sich genauso. Die GCP-Betriebssystemanmeldung ändert dies nur für IAM-gesteuerte Zugriffe. Hier bewirkt das Entziehen einer IAM-Rolle eines Benutzers eine Art sofortige Rotation, jedoch nicht für Dienstkonten oder Metadaten-basierte Schlüssel.

Worin besteht der wesentliche Unterschied zwischen GCP OS Login und der SSH-Schlüsselverwaltung von AWS und Azure? OS Login verknüpft den SSH-Zugriff direkt mit einer Google IAM-Identität. Dadurch werden die Zugriffsrechte automatisch aktualisiert, wenn sich die IAM-Berechtigungen ändern, und die Autorisierung erfolgt unabhängig von einem gespeicherten privaten Schlüssel. AWS und Azure bieten vergleichbare IAM-basierte Alternativen: AWS Systems Manager Session Manager und Microsoft Entra ID Login für Linux-VMs. Beide erfordern jedoch die Installation eines separaten Agenten oder einer Erweiterung und sind optionale Zusatzfunktionen, die auf der standardmäßigen schlüsselbasierten Authentifizierung aufbauen – im Gegensatz zu GCP OS Login, das einen nativen SSH-Authentifizierungspfad nutzt.

Kann ich SSH-Schlüssel in allen drei Clouds durch IAM-basierten Zugriff ersetzen? Sie können in jeder Cloud einzeln auf IAM-basierten Zugriff umstellen – AWS Session Manager, Azure Entra ID Login und GCP OS Login unterstützen dies alle. Allerdings ist keines der drei Systeme mit den anderen integriert. Die Umstellung auf IAM-basierten Zugriff in allen drei Clouds bedeutet weiterhin, dass Sie drei separate IAM-Systeme einheitlich verwalten müssen. Genau dieses Problem soll eine zentrale SSH-Schlüsselverwaltungsschicht lösen.

Wie erhalte ich eine zentrale Übersicht aller SSH-Schlüssel in AWS, Azure und GCP? Sie benötigen einen Erkennungsprozess oder eine dedizierte SSH-Schlüsselverwaltungsplattform, die EC2-Schlüsselpaare in allen AWS-Regionen und -Konten, Einträge in der Datei „authorized_keys“ von VMs in allen Azure-Abonnements sowie Metadaten von GCP-Projekten oder -Instanzen und Betriebssystem-Anmeldedaten durchsucht und diese Daten anschließend in einem einzigen Datensatz pro Schlüssel mit zugewiesenem Besitzer zusammenführt. Keine der drei Cloud-Konsolen bietet diese Ansicht nativ, da sie die Existenz der anderen beiden nicht kennen.

Bedeutet die Aktivierung von GCP OS Login, dass wir keine SSH-Schlüsselrotationsrichtlinie mehr benötigen? Nein. OS Login entfernt gespeicherte private Schlüssel aus dem Prozess der interaktiven Benutzeranmeldungen auf GCP Compute Engine. Dienstkonten, Automatisierungen und alle Instanzen oder Projekte, die weiterhin metadatenbasierte Schlüssel verwenden, unterliegen jedoch weiterhin denselben Rotationsanforderungen wie AWS und Azure. OS Login gilt außerdem nur für GCP. Daher ist für jedes Zugriffsmodell von AWS und Azure weiterhin eine Rotationsrichtlinie erforderlich.

Referenzen

• Erstellen Sie ein Schlüsselpaar für Ihre Amazon EC2-InstanceAmazon Web Services
• AWS Systems Manager SitzungsmanagerAmazon Web Services
• Detaillierte Schritte zum Erstellen eines SSH-SchlüsselpaaresMicrosoft Learn, Azure Virtual Machines
• Melden Sie sich mit Ihrer Microsoft Entra ID und OpenSSH bei einer virtuellen Linux-Maschine in Azure an.Microsoft Learn
• Über die BetriebssystemanmeldungGoogle Cloud, Compute Engine-Dokumentation
• Betriebssystemanmeldung einrichtenGoogle Cloud, Compute Engine-Dokumentation
• Bewährte Verfahren zur Kontrolle des SSH-AnmeldezugriffsGoogle Cloud, Compute Engine-Dokumentation
• NIST IR 7966: Sicherheit der interaktiven und automatisierten Zugriffsverwaltung mittels Secure Shell (SSH), Nationales Institut für Standards und Technologie
• State of Secrets Sprawl 2026, GitGuardian
• Bericht zum Stand der maschinellen Identitätssicherheit 2025CyberArk
• Bericht über die Kosten eines Datenschutzverstoßes 2025, IBM