Best Practices zum Schutz von SSH-Anmeldedaten

In diesem Dokument werden Best Practices für den 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, 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 Verfahren, die entweder für Google Cloud spezifisch sind oder bei der Verwendung von SSH in Google Cloudvon 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. Anstatt diesen Arbeitslasten die Verwendung eines langlebigen SSH-Schlüsselpaars zu erlauben, können Sie ihnen bei jeder Ausführung einen neuen, kurzlebigen SSH-Schlüssel zuweisen.

Wenn Sie sitzungsspezifische SSH-Schlüssel verwenden möchten, müssen Sie die folgenden Schritte in Ihren Deployment-Pipelines oder Automatisierungsprozessen 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 können Sie SSH-Verbindungen zu VM-Instanzen herstellen.

  5. Optional können Sie den öffentlichen Schlüssel aus der Veröffentlichung entfernen und den 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 Angreifer muss weder den Nutzernamen noch das Passwort des Nutzers kennen oder überhaupt Google-Anmeldedaten besitzen.

Sicherheitsmaßnahmen wie die 2‑Faktor-Authentifizierung und die Begrenzung der Sitzungsdauer für Google Cloud -Dienste können das Risiko eines Anmeldedatendiebstahls wirksam verringern. Diese Maßnahmen 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, verwenden Sie IAP, um den SSH-Zugriff zu steuern, und Firewallrichtlinien, um zu erzwingen, 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 Nutzer eine Verbindung herstellen können, und den 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 durch Diebstahl von 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, um die Bestätigung in zwei Schritten zu erzwingen.
  2. Begrenzen Sie die Sitzungslänge für Google Cloud -Dienste, damit im Cache gespeicherte Anmeldedaten automatisch ungültig werden und Nutzer sich regelmäßig neu authentifizieren und die Multi-Faktor-Authentifizierung durchfü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 MFA erforderlich ist, und begrenzen Sie die Sitzungslänge, damit Nutzer jedes Mal, wenn ihre Google Cloud Sitzung abläuft, MFA durchführen müssen.

Damit die MFA auch für den SSH-Zugriff gilt, müssen Sie mindestens eine der folgenden Aktionen ausführen:

  1. IAP zur Steuerung des Netzwerkzugriffs verwenden, damit Nutzer regelmäßig die 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, damit Nutzer bei jeder SSH-Verbindung eine MFA durchführen müssen.

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 nicht auch die MFA 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 der Festplatte. gcloud compute ssh generiert beispielsweise bei der ersten Verwendung ein SSH-Schlüsselpaar und speichert es in Ihrem Home-Verzeichnis. 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.

Bei einigen SSH-Clients können Sie auf die Verwendung dateibasierter Schlüssel verzichten und stattdessen alternative Optionen zum Verwalten privater SSH-Schlüssel nutzen, 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 hardwarebasierte Schlüssel verwenden, müssen Sie kein privates Schlüsselmaterial im Dateisystem Ihres Computers speichern.
  • Schlüsselspeicherfunktionen des Betriebssystems verwenden: IAP Desktop verwendet beispielsweise keine dateibasierten Schlüssel, sondern 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 mit einer Passphrase geschützten SSH-Schlüssel zu verwenden, benötigt ein Angreifer 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 verleiten, eine Verbindung zu einer manipulierten 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 in der Regel bei der ersten Verbindung den Hostschlüssel einer VM 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 Methode zum Abrufen eines Hostschlüssels besteht darin, ihn über einen vertrauenswürdigen Side-Channel 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 sich zum ersten Mal mit ihr verbinden, 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, verwendet die gcloud CLI das Aktualisierungstoken, um Sie automatisch zu authentifizieren.

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, sondern die gcloud CLI stattdessen das angehängte Dienstkonto der VM verwenden lassen. Vermeiden Sie es auch, andere Tools auszuführen, die möglicherweise persönliche Anmeldedaten in Ihrem Basisverzeichnis speichern.

Sie können das Risiko 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 die zugehörigen Dienstkonten) haben, können die von diesen Tools verwendeten privaten SSH-Schlüssel besonders vertraulich 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