Best Practices für die Steuerung des SSH-Netzwerkzugriffs

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

Zum Herstellen einer Verbindung zu einer VM-Instanz über SSH benötigt ein Nutzer Netzwerkzugriff auf die VM-Instanz und gültige SSH-Anmeldedaten. Standardmäßig verwendet die Compute Engine eine Firewallregel, die den SSH-Netzwerkzugriff nicht einschränkt, aber es jedem im Internet erlaubt, eine Verbindung zu Port 22 von VM-Instanzen herzustellen. Dies ist für Entwickler praktisch, weil sie für einen schnellen Einstieg sorgen können, ohne Netzwerk- oder Sicherheitskontrollen zu berücksichtigen. Nutzer können jedoch von jedem Gerät aus eine Verbindung herstellen. Außerdem birgt dies Risiken für ein Netzwerk und einen Standort:

  • Nutzer stellen möglicherweise eine Verbindung von nicht vertrauenswürdigen Geräten oder Netzwerken her.
  • Böswillige Akteure können Brute-Force-Angriffe starten und versuchen, Ihre VM-Instanzen zu manipulieren.
  • Böswillige Akteure mit Zugriff auf SSH-Anmeldedaten, die gehackt wurden oder nicht rechtzeitig widerrufen wurden, können mit den Anmeldedaten auf eine VM von einem beliebigen Netzwerk aus zugreifen und sich bei dieser anmelden.

In den folgenden Abschnitten wird beschrieben, wie Sie Risiken reduzieren können, indem Sie die Netzwerke, Standorte oder Geräte beschränken, von denen Nutzer eine SSH-Verbindung zu Ihren VMs herstellen 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.

Netzwerkexposition reduzieren

Wenn Sie Nutzern erlauben, von überall aus SSH-Verbindungen herzustellen, sind Sie für den Schutz Ihrer VMs vollständig auf die SSH-Authentifizierungs- und -Autorisierungsmechanismen angewiesen. Sie können das Risiko verringern und eine zusätzliche Schutzebene schaffen, indem Sie die Netzwerkzugriffsrechte von VMs einschränken.

Es gibt mehrere Möglichkeiten, die Netzwerkexposition Ihrer VMs zu reduzieren. Um den Ansatz zu ermitteln, der für Ihre Umgebung am besten geeignet ist, müssen Sie eine Reihe von Faktoren berücksichtigen, wie im folgenden Flussdiagramm dargestellt:

Netzwerkexposition reduzieren

  • Externer Zugriff: Der erste Faktor, der zu berücksichtigen ist, ist, ob die VM nur innerhalb des VPC-Netzwerks zugänglich sein muss oder ob die VM auch extern zugänglich sein muss.

    Wenn der VPC-interne Zugriff ausreicht, müssen Sie der VM keine externe IP-Adresse zuweisen. Sie müssen jedoch entscheiden, wie der Zugriff verwaltet werden soll.

  • Größe des internen Netzwerks: Wenn der VPC-interne Zugriff ausreicht, ist der zweite zu berücksichtigende Faktor die Größe des internen Netzwerks.

    In kleineren Netzwerken kann es ausreichend sein, Firewallregeln zu verwenden, die eingehenden Traffic von internen Adressen zu Port 22 zulassen, um Ihre VMs zu schützen. In größeren Netzwerken könnte die Verwendung von Firewallregeln allein zu einschränkend sein: In solchen Fällen können Sie von der TCP-Weiterleitung für Cloud Identity-Aware Proxy profitieren, um kontextabhängige Wissenszugriff auf VMs.

  • VPC Service Controls-Perimeter-Design: Der nächste Faktor, den Sie berücksichtigen müssen, ist, ob die VM-Instanz Teil eines VPC Service Controls-Perimeters ist.

    Wenn die VM Teil eines Dienstperimeters ist, wird jeder API-Zugriff, der von der VM ausgeht, als Zugriff innerhalb des Perimeters betrachtet. Wenn Sie einem Nutzer, der sich außerhalb des Perimeter befindet, SSH-Zugriff auf eine VM innerhalb des Perimeter gewähren, kann er potenziell Daten aus dem Perimeter auf seine lokale Workstation kopieren oder umgekehrt. Dies kann die Vertraulichkeit und Integrität der Daten Ihres Perimeter gefährden.

    Wenn Sie einer VM-Instanz, die Teil eines VPC Service Controls-Perimeters ist, SSH-Zugriff gewähren müssen, verwenden Sie die IAP-TCP-Weiterleitung. IAP erkennt, ob die Workstation des Nutzers Teil desselben VPC Service Controls-Perimeters ist, und blockiert standardmäßig Zugriffsversuche von außerhalb des Dienstperimeters. Wenn Sie externen Zugriff zulassen möchten, verwenden Sie Regeln für eingehenden Traffic und konfigurieren Sie sie so, dass ein kontextsensitiver Zugriff erzwungen wird.

  • Verwaltung von Clientgeräten: Der letzte Faktor ist die Verwaltung Ihrer Clientgeräte, da dies bestimmt, wie Sie den kontextsensitiven Zugriff steuern können.

    Der kontextsensitive Zugriff ist am effektivsten, wenn Access Context Manager Zugriff auf eine Vielzahl von Signalen zu einem Nutzer, seinem Gerät und seinem Standort hat. Daher funktioniert er in Kombination mit Chrome Enterprise Premium: Wenn Sie Ihre Geräte mit Chrome Enterprise Premium verwalten, können Sie Zugriffsebenen einrichten, die den Zugriff basierend auf der Gerätebereitschaft steuern. Sie können diese Zugriffsebene dann auf den SSH-Zugriff anwenden. Dazu verwenden Sie die IAP-TCP-Weiterleitung in Kombination mit Zugriffsbindungen oder IAM-Bedingungen.

    Wenn Sie die Konfiguration eines Clientgeräts nicht steuern, müssen Sie es als nicht verwaltet und potenziell nicht vertrauenswürdig betrachten.

    Für den Zugriff von nicht verwalteten Geräten können Sie auch die IAP-TCP-Weiterleitung verwenden. Allerdings können Sie den Zugriff nur basierend auf der Nutzeridentität und der IP-Adresse des Geräts verwalten. Da Access Context Manager keinen Zugriff auf Gerätesignale hat, können Sie den Zugriff nicht anhand des Gerätestatus einschränken.

Basierend auf den Faktoren und mithilfe des Flussdiagramms können Sie ermitteln, welcher Ansatz zur Reduzierung der Netzwerkpräsenz für Ihre Umgebung am besten geeignet ist. Diese Schritte werden in den folgenden Abschnitten näher erläutert.

IAP-basierter SSH-Zugriff

Bei diesem Ansatz wird nur der SSH-Zugriff über die IAP-TCP-Weiterleitung zugelassen und IAP kann den Zugriff anhand der Identität des Nutzers steuern.

Wir empfehlen diesen Ansatz für VM-Instanzen, für die Folgendes gilt:

  • Die VM-Instanz muss extern oder über ein großes internes Netzwerk zugänglich sein.
  • Die VM ist nicht Teil eines VPC Service Controls-Perimeters.

Standardmäßig ist für eine VM-Instanz mit einer externen IP-Adresse der SSH-Zugriff zulässig, da Standard-Firewalls Verbindungen vom öffentlichen Internet zu Port 22 zulassen. Dieser Ansatz wird jedoch nicht empfohlen. Dieser Ansatz kann das Risiko erheblich erhöhen, dass die VM Ziel von Angriffen wie den folgenden wird:

  • Nutzung nicht widerrufener Anmeldedaten: Ehemalige Mitarbeiter, deren Zugriff nicht vollständig widerrufen wurde, können weiterhin auf die VM zugreifen.
  • Missbrauch gültiger Anmeldedaten: Böswillige Akteure, die gestohlene oder geleakte Anmeldedaten haben, können sich damit anmelden.
  • Denial of Service: Böswillige Akteure versuchen möglicherweise, die Ressourcen der VM zu erschöpfen, indem sie sie mit Anfragen überlasten.

Die Verwendung der IAP-TCP-Weiterleitung ist eine sicherere Methode, um externen SSH-Zugriff auf eine VM-Instanz zu ermöglichen. Ähnlich wie ein Bastion Host oder Reverse-Proxy fungiert die IAP-TCP-Weiterleitung als Vermittler zwischen dem Clientgerät und der VM.

Die IAP-TCP-Weiterleitung führt die folgenden vier Funktionen aus, wenn ein Nutzer versucht, eine SSH-Verbindung herzustellen:

  • Authentifizierung: IAP überprüft, ob der Nutzer gültige Google-Anmeldedaten hat.
  • Autorisierung: IAP prüft die IAM-Richtlinien, um festzustellen, ob dem Nutzer die Berechtigung zum Herstellen einer Verbindung zur VM über IAP gewährt wurde.
  • Kontextsensitiver Zugriff: Optional kann IAP prüfen, ob der Nutzer, sein Gerät und sein Standort bestimmte Zugriffsebenen erfüllen.
  • Auditing: Wenn Datenzugriffs-Logs aktiviert sind, protokolliert IAP jeden erfolgreichen und fehlgeschlagenen Versuch, eine Verbindung zu einer VM-Instanz herzustellen.

Da IAP als Vermittler fungiert und diese Funktionen ausführt, muss der VM keine externe IP-Adresse zugewiesen werden. Außerdem wird eine zusätzliche Sicherheitsebene bereitgestellt.

IAP-basierter kontextsensitiver SSH-Zugriff

Bei diesem Ansatz soll der SSH-Zugriff nur über die IAP-TCP-Weiterleitung zugelassen und der Zugriff von IAP basierend auf der Identität des Nutzers und zusätzlichen Faktoren gesteuert werden.

Wir empfehlen diesen Ansatz für VM-Instanzen, für die Folgendes gilt:

  • Die VM-Instanz muss von außerhalb der VPC und der mit der VPC verbundenen Netzwerke zugänglich sein.
  • Die VM ist nicht Teil eines VPC Service Controls-Perimeters.
  • Der Zugriff auf die VM muss nur von bestimmten Geräten, Netzwerken oder Standorten aus möglich sein.

Wenn Sie einem Nutzer SSH-Zugriff auf eine VM-Instanz gewähren – direkt oder über IAP –, kann er standardmäßig von jedem Gerät, Netzwerk und Standort aus auf die VM-Instanz zugreifen. Diese Zugriffsebene ist zwar praktisch für Nutzer, erhöht aber die Risiken, da Nutzer eine Verbindung von manipulierten Geräten oder nicht vertrauenswürdigen Netzwerken herstellen könnten.

Um das Risiko zu verringern, konfigurieren Sie die IAP-TCP-Weiterleitung so, dass Nutzer nur von bestimmten Geräten oder Standorten aus auf VM-Instanzen zugreifen können. Sie können diesen kontextsensitiven Zugriff auf zwei Arten konfigurieren:

  • Zugriffsbindungen: Sie können eine Zugriffsebene erstellen und sie mithilfe einer Zugriffsbindung einer Gruppe zuweisen. Zugriffsbindungen sind formular- oder identitätsbasierte Richtlinien und gelten für alle Ressourcen, auf die ein Nutzer zuzugreifen versucht. Dazu gehören IAPs, aber auch andere APIs und die Google Cloud Console.

    Die Verwendung von Zugriffsbindungen funktioniert am besten, wenn Sie dafür sorgen möchten, dass der kontextsensitive Zugriff für alle Ressourcen einheitlich erzwungen wird.

  • IAM-Bedingungen: Sie können eine Zugriffsebene erstellen und sie mithilfe von IAM-Bedingungen einzelnen IAM-Rollenbindungen zuweisen.

    Die Verwendung von IAM-Rollenbindungen ist eine Form der ressourcenbasierten Richtlinie. Dieser Ansatz funktioniert am besten, wenn Sie unterschiedliche Richtlinien auf unterschiedliche VMs anwenden möchten.

Mit einfachen Zugriffsebenen können Sie den Zugriff nach Netzwerk oder Standort beschränken. Als Chrome Enterprise Premium-Abonnent können Sie den Zugriff auch anhand anderer Attribute einschränken, z. B. anhand der Stärke der Anmeldedaten, der Konfiguration des Browsers, der für die Authentifizierung verwendet wird, oder der Geräteposition.

VPC Service Controls-basierter SSH-Zugriff

Bei diesem Ansatz soll der SSH-Zugriff nur über die IAP-TCP-Weiterleitung zugelassen werden. Der Dienstperimeter wird so konfiguriert, dass der IAP-Zugriff für bestimmte Identitäten und Quellen zulässig ist.

Wir empfehlen diesen Ansatz für VM-Instanzen, die Teil eines VPC Service Controls-Perimeters sind.

Wenn Sie Nutzern externen SSH-Zugriff auf eine VM gewähren, die Teil eines Dienstperimeter ist, kann das riskant sein, da Nutzer so den VPC Service Controls-Perimeter untergraben und Daten über SSH exfiltrieren können.

Wenn Sie den SSH-Zugriff nur über die IAP-TCP-Weiterleitung zulassen, können Sie dieses Risiko verringern und dafür sorgen, dass der gesamte SSH-Zugriff der Konfiguration Ihres VPC Service Controls-Perimeters unterliegt:

  • Wenn ein Nutzer versucht, eine Verbindung von außerhalb des Dienstperimeters herzustellen (wie im vorherigen Beispiel dargestellt), prüft die IAP-TCP-Weiterleitung nicht nur, ob dem Nutzer IAM-Zugriff auf die VM gewährt wird, sondern prüft auch Wenn die Anfrage eine der Regeln für eingehenden Traffic des Perimeters erfüllt.

  • Wenn ein Nutzer versucht, eine Verbindung von innerhalb des Dienstperimeters herzustellen, wird bei der IAP-TCP-Weiterleitung auch geprüft, ob dem Nutzer IAM-Zugriff auf die VM gewährt wurde. VPC Service Controls-Regeln für eingehenden Traffic werden jedoch ignoriert.

    IAP betrachtet eine Verbindung als Verbindung aus einem Dienstperimeter, wenn eine der folgenden Bedingungen zutrifft:

    • Die Quell-IP-Adresse ist die externe IP-Adresse einer VM, die Teil des Dienstperimeters ist.
    • Die Verbindung wird über den privaten Google-Zugriff von einer VM hergestellt, die Teil des Dienstperimeters ist.
    • Die Verbindung wird über einen Private Service Connect-Zugriffsendpunkt hergestellt, der Teil des Dienstperimeters ist.

Firewallgesteuerter interner SSH-Zugriff

Bei diesem Ansatz wird der gesamte externe Zugriff verhindert und nur der VPC-interne SSH-Zugriff zugelassen.

Sie können diesen Ansatz für VM-Instanzen verwenden, für die Folgendes gilt:

  • Die VM-Instanz muss nicht extern zugänglich sein.
  • Die VM ist mit einem kleinen bis mittelgroßen internen Netzwerk verbunden.
  • Die VM ist nicht Teil eines VPC Service Controls-Perimeters.

So können Sie den externen Zugriff deaktivieren:

  • Stellen Sie die VM-Instanzen ohne externe IP-Adresse bereit.
  • Konfigurieren Sie Firewallregeln, damit eingehender SSH-Traffic von IP-Bereichen außerhalb des VPC nicht zulässig ist.

Zugriff auf die serielle Konsole deaktivieren

Zur Behebung von nicht funktionierenden VM-Instanzen können Sie in Compute Engine über ein SSH-Gateway ssh-serialport.googleapis.com eine Verbindung zur seriellen Port-Konsole einer Instanz herstellen. Dieses Gateway ist über das Internet öffentlich zugänglich.

Das SSH-Gateway greift über den zugrunde liegenden Hypervisor statt über das VPC-Netzwerk auf die VM zu. Der Zugriff auf die serielle Konsole wird daher durch IAM-Richtlinien und nicht durch Firewallregeln gesteuert.

Wenn Sie Nutzern den Zugriff auf eine serielle Konsole einer VM erlauben, kann dies unbeabsichtigt verlassen werden. Um diese übermäßige Offenlegung zu verhindern, verwenden Sie die Organisationsrichtlinien-Einschränkung compute.disableSerialPortAccess, um den Zugriff auf die serielle Konsole zu deaktivieren, und heben Sie die Einschränkung vorübergehend auf, wenn Sie Notfallzugriff auf die Der serielle Port der VM.

Bastion-VM verwenden, wenn Sie eine Sitzungsaufzeichnung benötigen

Da es als Vermittler zwischen Clientgeräten und VMs fungiert, führt die IAP-TCP-Weiterleitung Funktionen aus, die normalerweise von Bastion Hosts oder Jump-Servern ausgeführt werden. Zu diesen Funktionen gehören:

  • Zugriffsrichtlinien zentral durchsetzen
  • Zugriff prüfen

Im Gegensatz zu einigen Bastion Hosts werden SSH-Verbindungen durch die IAP-TCP-Weiterleitung nicht beendet: Wenn Sie eine SSH-Verbindung zu einer VM über die IAP-TCP-Weiterleitung herstellen, wird die SSH-Verbindung zwischen Ihrem Client und der VM Ende-zu-Ende verschlüsselt. Aufgrund dieser Ende-zu-Ende-Verschlüsselung kann der Inhalt der SSH-Sitzung nicht durch IAP-TCP-Weiterleitung geprüft werden und es gibt keine Funktionen zur Sitzungsaufzeichnung. Die IAP-Audit-Logs enthalten Verbindungsmetadaten, geben jedoch keine Informationen zum Inhalt der Sitzung an.

Wenn Sie eine Sitzungsaufzeichnung benötigen, verwenden Sie eine Bastion-VM:

  • Konfigurieren Sie die Bastion-VM so, dass sie SSH-Verbindungen beendet und deren Inhalt aufzeichnet. Achten Sie darauf, die Verwendung der SSH-Portweiterleitung einzuschränken, da dies die Effektivität der Sitzungsaufzeichnung beeinträchtigen kann.
  • Richten Sie Firewallregeln von Ziel-VMs so ein, dass SSH-Verbindungen nur von der Bastion-VM aus zugelassen werden.
  • Zugriff auf die Bastion-VM nur über die IAP-TCP-Weiterleitung zulassen

SSH-Zugriff mit Firewallrichtlinien einschränken

Nachdem Sie festgelegt haben, welche Methode zur Begrenzung der SSH-Freigabe für Ihre Umgebung am besten funktioniert, müssen Sie dafür sorgen, dass alle VMs und Projekte entsprechend konfiguriert sind. Sie müssen insbesondere dafür sorgen, dass für alle Projekte konsistente Firewallregeln verwendet werden, die die Verwendung von SSH bestimmen.

Wenn Sie eine Reihe von Firewallregeln auf mehrere Projekte anwenden möchten, verwenden Sie hierarchische Firewallrichtlinien und wenden sie auf Ordner in Ihrer Ressourcenhierarchie an.

Wenn Sie beispielsweise erzwingen möchten, dass der gesamte SSH-Zugriff über die IAP-TCP-Weiterleitung erfolgt, wenden Sie eine Firewallrichtlinie an, die die folgenden beiden benutzerdefinierten Regeln (in der Reihenfolge ihrer Priorität) enthält:

  1. Lassen Sie eingehenden Traffic von 35.235.240.0/20 zu Port 22 der ausgewählten VMs zu. 35.235.240.0/20 ist der IP-Bereich, der von der IAP-TCP-Weiterleitung verwendet wird.
  2. Lehnen Sie eingehenden Traffic von 0.0.0.0/0 zu Port 22 aller VMs ab.

Nächste Schritte