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, können sie in die Hände böswilliger Akteure gelangen, die diese Schlüssel verwenden können, um auf Ihre VM-Instanzen zuzugreifen.

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 Praktiken, die entweder spezifisch für Google Cloud oder von besonderer Bedeutung sind, wenn Sie SSH auf Google Cloudverwenden. 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 angehängtes Dienstkonto angehängt. Wenn Sie einer VM ein Dienstkonto anhängen, können Arbeitslasten, die auf diesen VMs ausgeführt werden, kurzlebige Zugriffstokens vom Metadatenserver anfordern , um auf APIs und Ressourcen zuzugreifen Google Cloud .

Wenn Sie über SSH eine Verbindung zu einer VM mit einem angehängten Dienstkonto herstellen, können Sie auch kurzlebige Zugriffstokens vom Metadaten server 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. Anstatt diesen Arbeitslasten die Verwendung eines langlebigen SSH-Schlüsselpaars zu erlauben, sollten 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 Cloudveröffentlichen und ein Ablaufdatum in der nahen Zukunft angeben (z. B. 1 Stunde in der Zukunft).

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

  4. Mit dem privaten Schlüssel SSH-Verbindungen zu VM-Instanzen herstellen.

  5. Optional: Veröffentlichung des öffentlichen Schlüssels aufheben und privaten Schlüssel löschen.

Beispiel:

# Generate RSA key pair without passphrase
ssh-keygen -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 zur Ergänzung der Authentifizierung mit öffentlichen SSH-Schlüsseln 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. Der böswillige Akteur muss weder den Nutzernamen noch das Passwort des Nutzers kennen oder überhaupt Google-Anmeldedaten besitzen.

Sicherheitskontrollen wie die Bestätigung in zwei Schritten und die Begrenzung der Sitzungslänge für Google Cloud Dienste können effektive Möglichkeiten sein, das Risiko von Anmeldedatendiebstahl zu verringern. Diese Kontrollen gelten jedoch 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. Außerdem können Sie mit IAP einschränken, mit welchen VMs sich Nutzer verbinden 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 Anmeldedatendiebstahl verringern, 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 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 Sitzungslänge für Google Cloud Dienste sodass im Cache gespeicherte Anmeldedaten automatisch ungültig werden und Nutzer sich regelmäßig neu authentifizieren und MFA durchführen müssen.

Wenn Sie die Einmalanmeldung (SSO) 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 Dienste Google Cloud 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 MFA erforderlich ist, und begrenzen Sie die Sitzungslänge, so dass Nutzer MFA jedes Mal durchführen müssen, wenn ihre Google Cloud Sitzung abläuft.

Damit MFA auch für den SSH-Zugriff gilt, müssen Sie außerdem mindestens eine der folgenden Maßnahmen ergreifen:

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

Nutzer mit der Rolle Compute Instance Admin oder einer entsprechenden Rolle für eine VM-Instanz oder ein Projekt können OS Login-2FA deaktivieren, indem sie die Instanzmetadaten ändern. Die Effektivität von OS Login-2FA ist daher begrenzt, wenn Sie MFA nicht auch in Cloud Identity oder Ihrem externen IdP erzwingen.

Nicht exportierbare oder durch eine Passphrase geschützte private Schlüssel verwenden

Viele SSH-Clients speichern private SSH-Schlüssel standardmäßig als Dateien auf der Festplatte. Beispielsweise generiert gcloud compute ssh 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 es Ihnen, die Verwendung von dateibasierten Schlüsseln zu vermeiden, und bieten alternative Optionen zum Verwalten privater SSH-Schlüssel, z. B.:

  • 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, vermeiden Sie, dass privates Schlüsselmaterial im Dateisystem Ihres Computers gespeichert wird.
  • Schlüsselverwaltungseinrichtungen Ihres Betriebssystems verwenden: Beispielsweise vermeidet IAP Desktop 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 keine Option ist, können Sie Ihren privaten SSH-Schlüssel mit einer Passphrase schützen: Um einen durch eine Passphrase geschützten SSH-Schlüssel zu verwenden, benötigt ein böswilliger Akteur nicht nur eine Kopie des privaten Schlüssels, sondern muss auch die Passphrase des Schlüssels kennen.

Hostschlüssel zur Authentifizierung des Hosts verwenden

Wenn Sie eine SSH-Verbindung zu einer VM-Instanz herstellen, identifizieren Sie die VM-Instanz anhand ihres Namens oder ihrer IP-Adresse. 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. Böswillige Akteure können Namen oder IP-Adressen absichtlich neu zuweisen oder wiederverwenden, um VM-Instanzen zu fälschen und Nutzer dazu zu bringen, eine Verbindung zu einer kompromittierten VM herzustellen.

SSH-Clients können mithilfe von SSH-Hostschlüsseln erkennen, wenn 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 den Hostschlüssel einer VM in der Regel bei der ersten Verbindung an und speichern ihn. Bei nachfolgenden Verbindungen wird geprüft, ob sich der Hostschlüssel der VM 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 zu erhalten, besteht darin, ihn über einen vertrauenswürdigen Nebenkanal zu beziehen, bevor Sie zum ersten Mal eine Verbindung zu einer VM herstellen.

Sie können die gcloud CLI Hostschlüssel über einen Back-Channel abrufen lassen, indem Sie Gastattribute in Ihrem Projekt aktivieren. Die gcloud CLI liest dann den Hostschlüssel einer VM, bevor Sie zum ersten Mal eine Verbindung zu ihr 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, vermeiden Sie es, die gcloud CLI oder Standardanmeldedaten für Anwendungen (ADC) mit Ihren persönlichen Anmeldedaten zu autorisieren, und lassen Sie die gcloud CLI stattdessen das angehängte Dienstkonto der VM verwenden. Vermeiden Sie außerdem die Ausführung anderer Tools, die möglicherweise persönliche Anmeldedaten in Ihrem Basisverzeichnis speichern.

Sie können die Risiken weiter verringern, 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 ihre angehängten Dienstkonten) haben, können die von diesen Tools 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, speichern Sie den privaten SSH-Schlüssel an einem sicheren Ort, der vom Quellcode getrennt ist, und verwenden Sie nach Möglichkeit sitzungsspezifische SSH-Schlüssel.

Nächste Schritte