Best Practices zum Schutz von SSH-Anmeldedaten

In diesem Dokument werden Best Practices zum Schutz von SSH-Anmeldedaten beschrieben.

Standardmäßig verwendet Compute Engine die schlüsselbasierte SSH-Authentifizierung: Nutzer werden anhand von etwas authentifiziert, das sie haben, nämlich einem privaten SSH-Schlüssel. Wenn die privaten Schlüssel der Nutzer nicht ordnungsgemäß gesichert sind, geraten sie möglicherweise in die Hände von böswilligen Nutzern, die diese Schlüssel für den Zugriff auf Ihre VM-Instanzen verwenden können.

Die folgenden Abschnitte enthalten Best Practices, mit denen Sie Schlüssellecks vermeiden und die potenziellen Auswirkungen von gehackten privaten Schlüsseln reduzieren können:

Das Dokument konzentriert sich auf Verfahren, die entweder für Google Cloud spezifisch sind oder bei der Verwendung von SSH in Google Cloud von besonderer Bedeutung sind. In diesem Dokument werden keine Best Practices für bestimmte Implementierungen von SSH-Clients oder -Servern behandelt.

Private SSH-Schlüssel ähnlich wie Dienstkontoschlüssel behandeln

Einigen Ihrer VM-Instanzen ist möglicherweise ein Dienstkonto angehängt. Wenn Sie ein Dienstkonto an eine VM anhängen, können Arbeitslasten, die auf diesen VMs ausgeführt werden, kurzlebige Zugriffstokens vom Metadatenserver anfordern, um auf Google Cloud APIs und ‑Ressourcen zuzugreifen.

Wenn Sie über SSH eine Verbindung zu einer VM mit einem angehängten Dienstkonto herstellen, können Sie auch kurzlebige Zugriffstokens vom Metadatenserver anfordern. Wenn Sie einem Nutzer SSH-Zugriff auf eine VM gewähren, erteilen Sie ihm in gewisser Weise die Berechtigung, als angehängtes Dienstkonto zu agieren. Daher sollten Sie private SSH-Schlüssel, insbesondere wenn sie nicht durch eine Passphrase geschützt sind, wie Dienstkontoschlüssel behandeln: Beim Hacken solcher Schlüssel kann ein Angreifer Zugriff auf Google Cloud-Ressourcen erhalten.

Sitzungsspezifische SSH-Schlüssel für Nutzer von Maschinen verwenden

Für Bereitstellungspipelines oder Automatisierungsprozesse ist möglicherweise SSH-Zugriff auf VM-Instanzen erforderlich, um Bereitstellungen durchzuführen oder Konfigurationsänderungen anzuwenden. Statt für diese Arbeitslasten ein langlebiges SSH-Schlüsselpaar zu verwenden, lassen Sie sie bei jeder Ausführung einen neuen, sitzungsspezifischen SSH-Schlüssel verwenden.

Wenn Sie sitzungsspezifische SSH-Schlüssel verwenden möchten, lassen Sie Ihre Bereitstellungspipelines oder Automatisierungsprozesse die folgenden Schritte ausführen:

  1. Sich als Dienstkonto, ohne einen Schlüssel oder ein Secret authentifizieren, z. B. mit einem angehängten Dienstkonto oder einer Identitätsföderation von Arbeitslasten.
  2. Mit einem Tool wie ssh-keygen ein temporäres SSH-Schlüsselpaar generieren.

  3. Den öffentlichen Schlüssel in Google Cloud veröffentlichen und ein Ablaufdatum in der nahen Zukunft angeben (z. B. 1 Stunde in der Zukunft).

    Mit OS Login können Sie ein Ablaufdatum für Schlüssel angeben, wenn Sie einen Schlüssel veröffentlichen. Ebenso können Sie ein Ablaufdatum angeben, wenn Sie einen öffentlichen SSH-Schlüssel in Projekt- oder VM-Metadaten veröffentlichen.

  4. Verwenden Sie den privaten Schlüssel, um SSH-Verbindungen zu VM-Instanzen herzustellen.

  5. Optional können Sie die Veröffentlichung des öffentlichen Schlüssels aufheben und den privaten Schlüssel löschen.

Beispiel:

# Generate RSA2048 key pair without passphrase
ssh-keygen -b 2048 -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

Ein sitzungsspezifischer privater SSH-Schlüssel kann zwar ebenfalls gehackt werden, er kann aber nur für kurze Zeit verwendet werden. Die Verwendung von sitzungsspezifischen SSH-Schlüsseln kann daher das Risiko von Anmeldedatenlecks verringern und Sie können Cloud IAM als primäres Mittel für die Authentifizierung und Autorisierung verwenden.

IAP als Ergänzung zur Authentifizierung mit einem öffentlichen SSH-Schlüssel verwenden

Standardmäßig können private SSH-Schlüssel unabhängig von Google-Anmeldedaten verwendet werden: Wenn der private SSH-Schlüssel eines Nutzers gehackt wird, kann ein böswilliger Akteur mit dem Schlüssel eine Verbindung zu allen VM-Instanzen herstellen und sich dort authentifizieren, auf die der Schlüssel Zugriff hat. Es ist nicht notwendig, dass der böswillige Akteur den Nutzernamen oder das Passwort des Nutzers kennt oder überhaupt Google-Anmeldedaten hat.

Sicherheitskontrollen wie die Bestätigung in zwei Schritten und die Beschränkung der Sitzungsdauer für Google Cloud-Dienste können wirksame Möglichkeiten sein, das Risiko von Anmeldedatendiebstahl zu verringern. Diese Steuerelemente gelten nur für Ressourcen, für die Google-Anmeldedaten erforderlich sind.

Damit SSH-Schlüssel nicht ohne gültige Google-Anmeldedaten verwendet werden können, steuern Sie den SSH-Zugriff mit IAP und erzwingen Sie mit Firewallrichtlinien, dass der gesamte SSH-Zugriff über IAP erfolgt.

IAP fungiert als Reverse-Proxy und erlaubt Nutzern nur dann, SSH-Verbindungen zu VM-Instanzen herzustellen, wenn sie sich mit ihren Google-Anmeldedaten authentifiziert haben. Darüber hinaus können Sie mit IAP einschränken, zu welchen VMs Nutzer eine Verbindung herstellen können, und kontextsensitiven Zugriff erzwingen.

Multi-Faktor-Authentifizierung verwenden

Die Verwendung von IAP zur Steuerung des SSH-Zugriffs erschwert es einem böswilligen Akteur, mithilfe gehackter Anmeldedaten auf VM-Instanzen zuzugreifen, macht es aber nicht unmöglich: Ein böswilliger Akteur könnte beispielsweise eine Workstation manipulieren und sowohl einen privaten SSH-Schlüssel also auch im Cache gespeicherte Anmeldedaten der gcloud CLI finden – ausreichend, um die Authentifizierungs- und Autorisierungsprüfungen von IAP zu bestehen und eine Verbindung zu den VM-Instanzen des Nutzers herzustellen.

Sie können die möglichen Auswirkungen solcher Angriffe auf Anmeldedaten reduzieren, indem Sie Cloud Identity oder Google Workspace so konfigurieren, dass die Multi-Faktor-Authentifizierung (MFA) erforderlich ist.

Wenn Cloud Identity oder Google Workspace Ihr primärer Identitätsanbieter ist, gehen Sie so vor, um die MFA zu erzwingen:

  1. Konfigurieren Sie Cloud Identity oder Google Workspace so, dass die Bestätigung in zwei Schritten erzwungen wird.
  2. Begrenzen Sie die Sitzungsdauer für Google Cloud-Dienste, sodass im Cache gespeicherte Anmeldedaten automatisch ungültig werden und Nutzer sich regelmäßig neu authentifizieren und MFA ausführen müssen.

Wenn Sie die Einmalanmeldung mit einem externen IdP verwenden, gehen Sie stattdessen so vor:

  1. Konfigurieren Sie Cloud Identity oder Google Workspace so, dass die Sitzungslänge für Google Cloud-Dienste begrenzt wird, sodass im Cache gespeicherte Anmeldedaten automatisch ungültig werden und Nutzer sich regelmäßig neu mit dem externen IdP authentifizieren müssen.
  2. Konfigurieren Sie Ihren externen IdP so, dass die MFA erforderlich ist, und begrenzen Sie die Sitzungsdauer so, dass Nutzer jedes Mal, wenn ihre Google Cloud-Sitzung abläuft, die MFA ausführen müssen.

Damit MFA auch für den SSH-Zugriff gilt, müssen Sie außerdem mindestens einen der folgenden Schritte ausführen:

  1. Verwenden Sie IAP, um den Netzwerkzugriff zu steuern, damit Nutzer regelmäßig eine Bestätigung in zwei Schritten durchführen müssen, um ihre Google-Anmeldedaten zu aktualisieren.
  2. Aktivieren Sie die Bestätigung in zwei Schritten für OS Login für einzelne VM-Instanzen oder ganze Projekte, damit Nutzer jedes Mal eine MFA ausführen müssen, wenn sie eine SSH-Verbindung herstellen.

Nutzer mit der Rolle Compute-Instanzadministrator oder einer entsprechenden Rolle für eine VM-Instanz oder ein Projekt können OS Login-2FA durch Ändern von Instanzmetadaten deaktivieren. Die Wirksamkeit der Bestätigung in zwei Schritten für OS Login ist daher begrenzt, wenn Sie die Bestätigung in zwei Schritten nicht auch in Cloud Identity oder Ihrem externen IdP erzwingen.

Nicht exportierbare oder mit einer Passphrase geschützte private Schlüssel verwenden

Viele SSH-Clients speichern private SSH-Schlüssel standardmäßig als Dateien auf dem Laufwerk. gcloud compute ssh generiert beispielsweise bei der ersten Verwendung ein SSH-Schlüsselpaar und speichert es in Ihrem Basisverzeichnis. Ihr Betriebssystem kann verhindern, dass andere Nutzer auf Ihre Dateien zugreifen. Wenn jedoch ein böswilliger Akteur Dateisystemberechtigungen überwinden kann, z. B. durch Kopieren und Bereitstellen des Laufwerks auf einem anderen Computer, kann er die Schlüssel an anderer Stelle kopieren und ohne Ihr Wissen verwenden.

Einige SSH-Clients ermöglichen die Verwendung dateibasierter Schlüssel und bieten alternative Optionen zum Verwalten privater SSH-Schlüssel wie die folgenden:

  • Hardwaregestützten Schlüssel verwenden: Mit modernen Versionen von OpenSSH können Sie FIDO2-Sicherheitsschlüssel für die Authentifizierung verwenden. Sie können OS Login so konfigurieren, dass nur Sicherheitsschlüssel zugelassen werden, die für Cloud Identity oder Google Workspace registriert sind. Wenn Sie hardwaregestützte Schlüssel verwenden, müssen Sie kein privates Schlüsselmaterial im Dateisystem Ihres Computers speichern.
  • Schlüsselspeicherfunktionen Ihres Betriebssystems verwenden: IAP Desktop vermeidet beispielsweise die Verwendung dateibasierter Schlüssel und verwendet stattdessen Windows CNG, um Ihre SSH-Schlüssel zu schützen.

Wenn die Verwendung von hardwaregestützten oder vom Betriebssystem verwalteten Schlüsseln nicht möglich ist, können Sie Ihren privaten SSH-Schlüssel mit einer Passphrase schützen: Um einen mit einer Passphrase geschützten SSH-Schlüssel zu verwenden, benötigt ein Angreifer nicht nur eine Kopie des privaten Schlüssels, sondern auch die Passphrase des Schlüssels.

Hostschlüssel zur Authentifizierung des Hosts verwenden

Wenn Sie eine SSH-Verbindung zu einer VM-Instanz herstellen, geben Sie die VM-Instanz anhand ihres Namens oder ihrer IP-Adresse an. Namen und IP-Adressen können neu zugewiesen und wiederverwendet werden. Der Name, der sich gestern auf eine bestimmte VM-Instanz bezog, bezieht sich heute möglicherweise nicht mehr auf dieselbe VM-Instanz. Angreifer können Namen oder IP-Adressen absichtlich neu zuweisen oder wiederverwenden, um VM-Instanzen zu spoofen und Nutzer dazu zu verleiten, eine Verbindung zu einer manipulierten VM herzustellen.

SSH-Clients können mithilfe von SSH-Hostschlüsseln Situationen erkennen, in denen eine zuvor vertrauenswürdige VM-Instanz durch eine andere VM-Instanz ersetzt wurde: Der SSH-Hostschlüssel einer VM wird beim ersten Start generiert und dient zur Identifizierung der Instanz. SSH-Clients fordern in der Regel bei der ersten Verbindung den Hostschlüssel einer VM an und speichern ihn. Außerdem wird geprüft, ob sich der Hostschlüssel der VM bei nachfolgenden Verbindungen nicht geändert hat.

SSH-Hostschlüssel basieren auf dem TOFU-Schema (Trust on first use, Vertrauen bei der ersten Verwendung). Die Effektivität von SSH-Hostschlüsseln kann beeinträchtigt werden, wenn ein Angreifer einen MITM-Angriff (Man-in-the-Middle) ausführt, um einen Client dazu zu bringen, bei der ersten Verwendung eine Verbindung zur falschen VM herzustellen und ihr zu vertrauen. Eine bessere Möglichkeit, einen Hostschlüssel abzurufen, besteht darin, ihn über einen vertrauenswürdigen Nebenkanal abzurufen, bevor Sie zum ersten Mal eine Verbindung zu einer VM herstellen.

Sie können die gcloud CLI Hostschlüssel über einen Backchannel abrufen lassen, indem Sie Gastattribute in Ihrem Projekt aktivieren. Die gcloud CLI liest dann den Hostschlüssel einer VM, bevor Sie eine Verbindung dazu herstellen, und speichert ihn auf Ihrem lokalen Computer.

Keine persönlichen Anmeldedaten auf VMs speichern

Wenn Sie die gcloud CLI autorisieren, ruft das Tool ein OAuth-Aktualisierungstoken ab und speichert es in Ihrem lokalen Basisverzeichnis. Wenn Sie anschließend einen gcloud CLI-Befehl ausführen, authentifiziert die gcloud CLI Sie automatisch mit dem Aktualisierungstoken.

Der Zugriff auf Ihren lokalen Computer ist für andere Nutzer möglicherweise nicht möglich. Auf einer VM-Instanz kann jedoch auch von anderen Nutzern, die Sudo-Berechtigungen für die VM haben, auf Ihr Basisverzeichnis zugegriffen werden.

Wenn ein böswilliger Akteur es schafft, sudo-Berechtigungen für eine VM zu erhalten, kann er in den Basisverzeichnissen anderer Nutzer nach Aktualisierungstokens und anderen Anmeldedaten suchen und diese Anmeldedaten verwenden, um seine Berechtigungen oder seinen Zugriff auf andere Ressourcen zu erweitern (Lateral Movement).

Wenn Sie über SSH mit einer VM-Instanz verbunden sind, sollten Sie die gcloud CLI oder die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) nicht mit Ihren persönlichen Anmeldedaten autorisieren und die gcloud CLI stattdessen das angehängte Dienstkonto der VM verwenden lassen. Führen Sie auch keine anderen Tools aus, die personenbezogene Anmeldedaten in Ihrem Basisverzeichnis speichern könnten.

Sie können die Risiken weiter reduzieren, indem Sie die Sitzungslänge für Google Cloud-Dienste begrenzen, sodass gespeicherte OAuth-Aktualisierungstokens nach einer bestimmten Zeit automatisch ablaufen.

Keine privaten SSH-Schlüssel an Quellcode-Repositories senden

Einige Automatisierungstools wie Ansible verwenden SSH, um auf VM-Instanzen zuzugreifen und sie zu verwalten. Da solche Tools möglicherweise Zugriff auf viele VM-Instanzen (und die zugehörigen Dienstkonten) haben, können die von ihnen verwendeten privaten SSH-Schlüssel besonders sensibel sein.

Wenn Sie einen privaten SSH-Schlüssel an ein Quellcode-Repository senden, besteht ein erhöhtes Risiko, dass der Schlüssel für nicht autorisierte Nutzer und böswillige Akteure zugänglich ist:

  • Böswillige Akteure scannen den Quellcode von öffentlichen Quell-Repositories möglicherweise nach gehackten Schlüsseln.
  • Sie entscheiden zu einem späteren Zeitpunkt, ein ehemals privates Quell-Repository in ein öffentliches Repository umzuwandeln, ohne es auf Schlüssel zu prüfen.
  • Andere Teammitglieder speichern Kopien des Quellcodes auf ihrer Workstation.

Um diese Risiken zu minimieren, sollten Sie den privaten SSH-Schlüssel an einem sicheren Ort speichern, der vom Quellcode getrennt ist, und nach Möglichkeit sitzungsspezifische SSH-Schlüssel verwenden.

Nächste Schritte