.jpg)
Dies ist der dritte Artikel in einer Reihe von Beiträgen über die Sicherheit von Google Cloud Platform. Die ersten beiden Artikel (Artikel I., Artikel II.) der Serie konzentrierten sich auf die Härtungsmöglichkeiten auf Projektebene mit Google Cloud Platform. In diesem Beitrag erfahren Sie mehr über Sicherheitseinstellungen für virtuelle Maschineninstanzen, die auf Google Compute Engine (GCE) laufen. Lesen Sie diesen Beitrag, um mehr über die integrierte GCE-Sicherheit zu erfahren. Verpassen Sie auch nicht den Rest dieser Serie:
Artikel IV.: Wie Sie Ihr Google Cloud Platform-Projekt sicherer machen: GCE-Netzwerksicherheit
Artikel V.: Wie Sie Ihr Google Cloud Platform-Projekt sicherer machen: GCE OS-Sicherheit
Es ist immer eine gute Praxis, nur die Dienste laufen zu lassen, die wirklich benötigt werden, und sie mit den geringstmöglichen Privilegien auszuführen. Auf diese Weise wird die Liste der möglichen Einstiegspunkte für Angreifer kürzer, was die statistische Wahrscheinlichkeit eines erfolgreichen Angriffs erheblich verringert. Diese Technik wird oft als Reduzierung der Angriffsfläche bezeichnet.
Wenn Sie Ihre laufenden Google Compute Engine-Instanzen regelmäßig überprüfen, können Sie manchmal Instanzen finden, die nicht mehr verwendet werden, aber aus irgendeinem Grund nicht außer Betrieb genommen wurden. Wenn Sie diese Instanzen löschen (natürlich nach einem Backup), werden Sie zwei wichtige Vorteile feststellen. Ihre Angriffsfläche wird durch eine alte, vergessene Instanz verringert, und Ihre monatlichen Kosten werden sinken.
Im zweiten Artikel dieser Reihe habe ich über Dienstkonten geschrieben und darauf hingewiesen, dass Dienstkonten für programmatische Anwendungsfälle gedacht sind. Sie können nicht für den Zugriff auf die Google Cloud Console verwendet werden, da sie nur für den Zugriff auf die Google Cloud API gültig sind. Der häufigste Anwendungsfall ist die Ausführung von Anwendungen oder Instanzen, die die Rechte eines bestimmten Servicekontos erben. Auf diese Weise können sie auf andere Cloud-Services zugreifen, indem sie die mit dem Service-Konto verbundenen Rechte ohne zusätzliche Authentifizierung nutzen. Auf Google Compute Engine verwendet jede Instanz ein Service-Konto, um dessen Rechte für den Zugriff auf verschiedene GCP-Dienste zu erben und zu nutzen. Sie können das zugehörige Dienstkonto für eine Instanz während der Erstellung oder durch Bearbeiten der Instanz definieren, wenn diese nicht läuft.
Durch die Definition eines neuen Servicekontos für eine Reihe ähnlicher Instanzen unter Verwendung von Identity & Access Management (IAM) können Sie die nutzbaren GCP-Funktionen für diese Instanzen sehr detailliert festlegen. Zum Beispiel können Sie dem Service-Konto das Recht "Storage Object Viewer" geben. Dann kann die Instanz, die dieses Service-Konto verwendet, alle Dateien aus allen mit dem Projekt verbundenen Google Cloud Storage (GCS)-Buckets lesen (herunterladen). Wenn Ihr spezieller Anwendungsfall nicht erfordert, dass Ihre virtuellen Maschinen Zugriff auf GCS-Objekte haben, ist es eine gute Idee, dieses Recht für das mit diesen Instanzen verknüpfte Dienstkonto zu entziehen. Es ist auch wichtig zu beachten, dass diese Rechte tatsächlich bedeuten, dass es keine weiteren Sicherheitsebenen zwischen den Instanzen und den GCP-Diensten gibt, für die der Zugriff gewährt wurde. So kann jeder lokale Nicht-Root-Benutzer der Instanz den gesamten GCP-Dienst nutzen. Sie benötigen keine zusätzlichen Schlüssel oder irgendeine Form der Authentifizierung, die erforderlich ist, wenn die Instanz über ihr zugehöriges Dienstkonto Rechte auf den Dienst hat. Aus diesem Grund ist es sehr wichtig, die Service-Konten für Ihre Instanzen korrekt einzurichten. Sie können hier mehr über die Verwendung von Dienstkonten im Zusammenhang mit GCE lesen.
Ein weiterer Satz von Einstellungen ist verfügbar, um zu kontrollieren, auf welche GCP-Dienste eine Instanz zugreifen kann. Dabei handelt es sich im Grunde um ein Legacy-System, das nicht erforderlich ist, wenn Sie das Service-Konto der Instanz korrekt eingerichtet haben. Dies ist lediglich eine weitere Ebene, um den Zugriff auf GCP-Dienste auf individueller Instanzbasis festzulegen, falls Sie dies benötigen.
Jeder Zugriff erlaubt der Instanz, das zu tun, was der Name vermuten lässt, wenn das Dienstkonto diesen Zugriff ebenfalls erlaubt. Dienstkonten ersetzen die Zugriffsbereiche und es ist besser, den Zugriff auf die GCP-Dienste über sie einzurichten. Dennoch muss auch die Instanz die richtigen Werte für die Zugriffsbereiche haben. Wenn Sie für eine Instanz "deaktiviert" als Zugriffsbereich auf Cloud Storage festlegen, kann sie nicht auf Cloud Storage zugreifen. Selbst wenn das zugehörige Dienstkonto die entsprechenden Rechte für Cloud Storage hat. Mehr über Instanz-Zugriffsbereiche können Sie hier lesen.
Bei Linux-Instanzen verfügt GCE über eine Funktion, mit der Sie Ihre Benutzer und SSH-Schlüssel automatisch in eine laufende Instanz einfügen können, so dass Sie über SSH auf sie zugreifen können. Es gibt zwei Stellen, an denen die SSH-Schlüssel hinzugefügt werden können. Der eine ist der spezielle Metadatenschlüssel auf Projektebene namens "ssh-keys". Der andere ist der gleichnamige Metadatenschlüssel auf Instanzebene. Es ist möglich, die SSH-Schlüssel auf Projektebene für einzelne Instanzen zu deaktivieren, wenn Sie möchten, dass die SSH-Zugriffsschlüssel bestimmter Instanzen nur über den Metadatenschlüssel auf Instanzebene separat verwaltet werden.
Der ssh-Schlüssel ist ein spezielles Metadatenelement, das einen oder mehrere Einträge enthält. Jeder Eintrag besteht aus einem Schlüssel- und einem Wertepaar. Der Schlüssel ist der Benutzername und der Wert ist die Zeichenfolge des öffentlichen SSH-Schlüssels in diesem Format: " ". Jeder öffentliche Schlüssel, der hier hinzugefügt wird, erstellt automatisch den entsprechenden Benutzer mit dem Schlüssel in der Datei authorized_keys auf allen Ihren Rechnern. Es ist sehr wichtig, die SSH-Schlüsselliste auf Projektebene und auch die Listen auf Instanzebene regelmäßig zu überprüfen, wenn Sie diese zuvor verwendet haben. Sie sollten regelmäßig die nicht benötigten SSH-Schlüssel aus dieser Liste entfernen. Auf diese Weise werden die entsprechenden Benutzer nicht aus dem Betriebssystem gelöscht. Allerdings wird der Schlüssel aus ihrer authorized_keys-Datei entfernt. Mehr über die Handhabung von SSH-Schlüsseln erfahren Sie hier.
