Best Practices für die Steuerung des SSH-Anmeldezugriffs

In diesem Dokument werden Best Practices für die Steuerung des SSH-Anmeldezugriffs auf Linux-VM-Instanzen beschrieben.

Um den SSH-Zugriff auf VM-Instanzen effektiv zu verwalten, müssen Sie Nutzern Zugriff gewähren, wenn sie ihn benötigen, und ihn widerrufen, wenn er nicht mehr benötigt wird. Wenn Ihr Verfahren zum Widerrufen des Zugriffs nicht zuverlässig ist oder nicht alle Ressourcen abdeckt, können böswillige Akteure möglicherweise weiterhin auf Ihre Ressourcen zugreifen, auch wenn ihr Zugriff eigentlich widerrufen werden sollte.

Die folgenden Abschnitte enthalten Best Practices, mit denen Sie den Widerruf von Zugriffen effektiv gestalten und sich vor Persistenzbedrohungen schützen 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.

Mit OS Login eine kontinuierliche Zugriffsbewertung anhand von IAM-Richtlinien gewährleisten

Die öffentlichen Linux-Images der Compute Engine sind so konfiguriert, dass die SSH-Authentifizierung mit öffentlichen Schlüsseln zulässig ist. Sie können einen öffentlichen Schlüssel eines Nutzers autorisieren und ihm die Berechtigung zum Herstellen einer SSH-Sitzung gewähren. Dazu stehen Ihnen zwei Mechanismen zur Verfügung:

  • Metadatenbasierte Schlüsselautorisierung: Als Administrator laden Sie den öffentlichen Schlüssel eines Nutzers in die Metadaten der VM oder des Projekts hoch oder Sie lassen die Nutzer den Upload selbst ausführen, indem Sie ihnen die Berechtigung zum Ändern von Metadaten erteilen.

    Ein öffentlicher Schlüssel, der in die Metadaten einer einzelnen VM hochgeladen wird, gewährt dem Nutzer Root-Berechtigungen nur für die VM. Ein Schlüssel, der in Projektmetadaten hochgeladen wird, gewährt einem Nutzer Zugriff auf alle VMs im Projekt.

  • OS Login-Schlüsselautorisierung: Als Nutzer laden Sie einen oder mehrere öffentliche Schlüssel in Ihr OS Login-Profil hoch, das Teil Ihres Google-Nutzerkontos ist. “

    Als Administrator können Sie festlegen, ob Sie einem Nutzer Root-Berechtigungen oder die Berechtigungen eines regulären Nutzers auf der VM gewähren möchten. Dazu weisen Sie ihm entweder die IAM-Rolle OS Login Admin User oder die IAM-Rolle OS Login User zu.

    Die gcloud CLI, der SSH-Client der Google Cloud Console und IAP Desktop erkennen automatisch, welchen Mechanismus Sie verwenden, und können den Schlüssel eines Nutzers entsprechend hochladen.

Ein wesentlicher Unterschied zwischen den beiden Mechanismen besteht darin, wenn der Zugriff anhand von IAM-Richtlinien bewertet wird:

  • Mit Metadatenschlüsseln wird der Zugriff nur einmal beim Hochladen des Schlüssels ausgewertet.

    Der Schlüssel des Nutzers ist an den Lebenszyklus der VM oder des Projekts gebunden und bleibt gültig, bis Sie den Schlüssel entfernen oder die VM oder das Projekt löschen. Das Sperren oder Löschen des Nutzerkontos hat keine Auswirkungen auf die Gültigkeit seiner Schlüssel.

  • Bei OS Login wird der Zugriff jedes Mal ausgewertet, wenn ein Nutzer versucht, eine SSH-Sitzung zu starten.

    Der Schlüssel des Nutzers ist an den Lebenszyklus seines Nutzerkontos gebunden. Wenn Sie einen Nutzer in Cloud Identity oder Google Workspace sperren oder löschen, können seine Schlüssel nicht mehr verwendet werden, um SSH-Zugriff zu gewähren.

Die Verwendung von metadatenbasierten Schlüsseln kann Persistenzbedrohungen darstellen: Nutzer behalten den SSH-Zugriff möglicherweise länger als nötig, wenn ihr öffentlicher Schlüssel nicht rechtzeitig aus Metadaten entfernt wird. Außerdem behalten sie den Zugriff möglicherweise auch nach dem Verlassen der der Organisation. Sie können dieses Risiko zwar reduzieren, indem Sie Metadaten regelmäßig prüfen, dies kann jedoch in größeren Umgebungen schwierig sein und ist möglicherweise nicht ausreichend, da metadatenbasierte Schlüssel Nutzern Root-Berechtigungen gewähren.

Um sich vor solchen Persistenzbedrohungen zu schützen, sollten Sie Nutzern nicht erlauben, metadatenbasierte Schlüssel zu verwenden. Konfigurieren Sie stattdessen Ihre Projekte so, dass die Verwendung von OS Login erzwungen wird.

Mithilfe von Organisationsrichtlinien eine einheitliche Verwendung von OS Login erzwingen

OS Login wird über den Metadatenschlüssel enable-oslogin gesteuert: Wenn Sie enable-oslogin in den Projekt- oder Instanzmetadaten auf TRUE festlegen, wird OS Login aktiviert. Wenn Sie ihn auf FALSE festlegen, wird OS Login deaktiviert.

Zum Ändern von Metadaten auf Projektebene benötigen Sie die Berechtigung compute.projects.setCommonInstanceMetadata für das Projekt. Diese Berechtigung ist Teil der Rollen Compute-Instanzadministrator (roles/compute.instanceAdmin.v1) und Compute-Administrator (roles/compute.admin). Ebenso ist für die Änderung von Metadaten auf Instanzebene die Berechtigung compute.instances.setMetadata für die jeweilige VM-Instanz erforderlich.

Metadaten auf Instanzebene haben Vorrang vor Metadaten auf Projektebene. Wenn Sie enable-oslogin in den Projektmetadaten auf TRUE festlegen, ist das daher nicht ausreichend, um die Verwendung von OS Login im gesamten Projekt zu erzwingen. Nutzer mit der Rolle Compute Instance Admin oder einem entsprechenden Zugriff auf VM-Instanzen im Projekt können Ihre Einstellung überschreiben, indem sie den Metadaten der VM-Instanz enable-oslogin=FALSE hinzufügen.

Wenn Sie eine einheitliche Verwendung von OS Login erzwingen möchten, sollten Sie nicht nur in den Projektmetadaten enable-oslogin auf TRUE festlegen. Wenden Sie stattdessen die Richtlinie „OS Login für eine Organisation mit einer Organisationsrichtlinie aktivieren“ an, damit alle Versuche, enable-oslogin in Instanz- oder Projektmetadaten auf false festzulegen, abgelehnt werden.

Privilegierte Rollen temporär oder pro VM gewähren

Wenn Sie VM-Instanzen haben, auf denen unterschiedliche Arbeitslasten ausgeführt werden und die von verschiedenen Teams verwaltet werden, können Sie die Zugriffsverwaltung vereinfachen, indem Sie diese VMs in verschiedenen Google Cloud-Projekten bereitstellen und die Projekte ein gemeinsames Netzwerk verwenden lassen. Die Verwendung separater Projekte ist jedoch nicht immer praktikabel. Einige Ihrer Projekte können eine Kombination von VM-Instanzen enthalten, wobei unterschiedliche VM-Instanzen nur für verschiedene Nutzer zugänglich sein sollten.

Wenn ein Projekt eine solche Kombination aus verschiedenen VM-Instanzen enthält, sollten Sie Nutzern nicht dauerhaft Rollen wie Compute Instance Admin auf Projektebene zuweisen. Unterscheiden Sie stattdessen zwischen schreibgeschütztem und privilegiertem Zugriff:

  • Gewähren Sie Nutzern die Rolle Compute-Betrachter oder eine entsprechende Rolle mit Lesezugriff auf Projektebene. Mit dieser Rolle können Nutzer VMs über die Google Cloud Console durchsuchen, aber keine SSH-Schlüssel veröffentlichen oder auf die VMs zugreifen.
  • Gewähren Sie Nutzern Compute OS Login, Compute-Instanzadministrator oder andere privilegierte Rollen nur für einzelne VMs oder auf einem Just-in-Time-Prinzip. nur als Basis.

Nutzerkonten sperren, wenn Nutzer die Organisation verlassen

Wenn Sie ein Nutzerkonto in Cloud Identity oder Google Workspace sperren oder löschen, werden die IAM-Berechtigungen des Nutzers automatisch widerrufen. Da OS Login die IAM-Berechtigungen eines Nutzers prüft, bevor er eine SSH-Sitzung herstellen kann, wird durch das Sperren oder Löschen eines Nutzerkontos auch der Zugriff des Nutzers auf VMs mit OS Login aufgehoben.

Wenn Sie Cloud Identity oder Google Workspace so konfiguriert haben, dass ein externer IdP für die Einmalanmeldung verwendet wird, haben Mitarbeiter sowohl bei Ihrem externen IdP als auch in Cloud Identity oder Google Workspace ein Nutzerkonto. Durch das Deaktivieren oder Löschen des Nutzerkontos eines Mitarbeiters in Ihrem externen IdP kann keine neuen Browsersitzungen für den Zugriff auf Google-Dienste eingerichtet werden. Dies hat aber keine unmittelbaren Auswirkungen auf OS Login: solange das Cloud Identity- oder Google Workspace-Nutzerkonto des Mitarbeiters aktiv bleibt, kann sich der Nutzer mit OS Login weiterhin authentifizieren und SSH-Verbindungen herstellen.

Wenn Sie den SSH-Zugriff zuverlässig widerrufen möchten, wenn ein Nutzer die Organisation verlässt, müssen Sie sein Cloud Identity- oder Google Workspace-Nutzerkonto sperren oder löschen. Wenn Sie einen externen IdP verwenden, konfigurieren Sie ihn so, dass Ereignisse zur Nutzersperrung weitergegeben werden, damit OS Login den Zugriff widerrufen kann.

SSH-Zugriff auf VMs mit einem privilegierten Dienstkonto nicht gewähren

Wenn eine VM-Instanz ein angehängtes Dienstkonto hat, können auf der VM ausgeführte Anwendungen kurzlebige Anmeldedaten vom Metadatenserver der VM anfordern. und diese Anmeldedaten verwenden, um als Dienstkonto zu fungieren.

SSH-Zugriff auf eine VM gewährt Ihnen ähnliche Berechtigungen: Wie bei einer Anwendung können Sie kurzlebige Anmeldedaten vom Metadatenserver der VM anfordern und als angehängtes Dienstkonto fungieren.

Da Sie mit SSH-Zugriff auf eine VM mit einem angehängten Dienstkonto als Dienstkonto agieren können, benötigen Sie für OS Login die Berechtigung iam.serviceAccounts.actAs für das Dienstkonto. Diese Berechtigung wird bei jeder Verbindung zur VM-Instanz geprüft. So trägt OS Login dazu bei, die Sicherheit des Dienstkontos aufrechtzuerhalten und zu verhindern, dass der SSH-Zugriff für die Rechteausweitung missbraucht wird.

Ziehen Sie die folgenden Alternativen in Betracht, um die mit VMs mit privilegierten Dienstkonten verbundenen Risiken weiter zu minimieren:

  • Hängen Sie kein Dienstkonto an die VM an, es sei denn, die Arbeitslast benötigt Zugriff auf Google Cloud-Ressourcen.
  • Verwenden Sie ein Dienstkonto für einen einzigen Zweck und gewähren Sie ihm nur Zugriff auf die Ressourcen, die die Arbeitslast benötigt.
  • Erfordern Sie von Nutzern, dass sie Just-in-Time-Zugriff anfordern, anstatt ihnen dauerhaften Zugriff auf die VM und das Dienstkonto zu gewähren.

Verwendung von Root-Berechtigungen einschränken

Wenn Sie OS Login verwenden und einem Nutzer die Rolle OS Login-Nutzer (roles/compute.osLogin) zuweisen, erhalten Sie eingeschränkte Nutzerberechtigungen für die VM. Gewähren Sie einem Nutzer dagegen dieOS Login-Administrator-Rolle (roles/compute.osAdminLogin), eine metadatenbasierte Schlüsselautorisierung anstelle von OS Login verwenden oder Nutzern die Änderung von VM-Metadaten ermöglichen, gewähren Sie dem Nutzer implizit Root-Berechtigungen für die VM.

Wenn Sie Nutzern Root-Berechtigungen auf einer VM gewähren, können Sie Persistenzrisiken verursachen: Nutzer können diese Berechtigungen missbrauchen, um neue Nutzerkonten zu erstellen oder Backdoors zu installieren, um den persistenten Zugriff auf die VM beizubehalten.

Um dieses Risiko zu verringern, sollten Sie die Verwendung von Root-Berechtigungen einschränken und die Rolle OS Login-Nutzer (roles/compute.osLogin) nur gewähren, wenn keine Root-Berechtigungen erforderlich sind.

POSIX-Profile vorab erstellen, um konsistente Nutzernamen und UIDs zu gewährleisten

Jede Linux-VM verwaltet eine lokale Datenbank mit Nutzern (/etc/passwd) und Gruppen (/etc/groups). Wenn Sie zum ersten Mal über SSH eine Verbindung zu einer Linux-VM herstellen, erstellt die Gastumgebung automatisch ein Linux-Nutzerkonto für Sie und weist ihm eine UID zu.

Wenn Sie metadatenbasierte Schlüssel verwenden, verknüpft die Gastumgebung den Linux-Nutzer nicht mit Ihrem Google-Nutzerkonto und weist Ihnen möglicherweise auf jeder VM, zu der Sie eine Verbindung herstellen, eine andere UID zu. Wenn Sie Protokolle wie NFS verwenden, die in einer Umgebung, die keine konsistenten UIDs über mehrere Computer erzwingt, von konsistenten UIDs ausgehen, können Nutzer aus Versehen oder – im Fall von böswilligen Akteuren – absichtlich den Remotezugriff als ein anderer Nutzer ausführen.

Wenn Sie metadatenbasierte Schlüssel verwenden, können Sie in der Gastumgebung auch den gewünschten Nutzernamen auswählen. Wenn Sie einen Nutzernamen auswählen, den ein Kollege zuvor verwendet hat, werden Sie mit dem Konto angemeldet, das ursprünglich für Ihren Kollegen erstellt wurde.

Mit OS Login können Sie solche Mehrdeutigkeiten bei UIDs und Nutzernamen vermeiden: Wenn Sie sich zum ersten Mal mit OS Login in einer Linux-VM anmelden, wird in der Gastumgebung ein Linux-Nutzer basierend auf dem POSIX-Profil Ihres Google-Nutzerkontos erstellt. Das POSIX-Profil dient als Vorlage für Linux-Nutzer und definiert Folgendes:

  • Einen Linux-Nutzernamen, der für alle Nutzer desselben Cloud Identity- oder Google Workspace-Kontos eindeutig ist.
  • eine UID und GID, die für alle Google Cloud-Projekte eindeutig ist
  • ein Pfad des Basisverzeichnisses
  • zusätzliche Konfiguration, z. B. eine Anmelde-Shell

Wenn Ihr Google-Konto bei der ersten Anmeldung kein POSIX-Profil hat, erstellt OS Login automatisch eines für Sie.

Der von OS Login zugewiesene Nutzername und UIDs sind innerhalb Ihrer Google Cloud-Umgebung eindeutig. Sie können sich jedoch mit Nutzernamen und UIDs überschneiden, die Sie außerhalb von Google Cloud verwenden. Wenn die Nutzernamen und UIDs von OS Login in anderen Umgebungen einheitlich sein sollen, sollten Sie die automatische Profilerstellung nicht verwenden. Verwenden Sie stattdessen die Directory API, um OS Login-POSIX-Profile vorab zu erstellen und benutzerdefinierte Nutzernamen, UIDs und GIDs zuzuweisen.

Nächste Schritte