.jpg)
Dies ist der zweite Teil einer Serie von Beiträgen über die Sicherheit der Google Cloud Platform. Der erste Beitrag befasst sich mit der Sicherheit im Allgemeinen und dem Sicherheitsdesign der Google Cloud Platform. Dieser Beitrag enthält praktische, umsetzbare Einstellungen, die Sie im IAM ändern können, um die Sicherheit Ihres Projekts zu verbessern. Wenn Sie nicht alle Änderungen vornehmen können oder wollen, ist es dennoch von Vorteil, eine Teilmenge davon zu implementieren. Sie verbessern individuell die Sicherheit. Lesen Sie weiter und erfahren Sie mehr über die notwendige IAM-Sicherheit. Verpassen Sie auch nicht den Rest dieser Serie:
Artikel III: Wie Sie Ihr Google Cloud Platform-Projekt sicherer machen: Eingebaute GCE-Sicherheit
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
Die Multi-Faktor-Authentifizierung ist eine Methode, bei der zusätzlich zur Verwendung einer Information zur Authentifizierung eines Nutzers (z. B. ein Passwort) mindestens eine weitere Beweisquelle erforderlich ist, um sicherzustellen, dass die richtige Person auf ein System zugreift. Auf der Google Cloud Platform authentifizieren sich die Nutzer über Google-Konten. Dabei handelt es sich um individuelle E-Mail-Adressen, die als Google-Konto registriert sind, oder (häufiger) um Konten einer Google Suite Domain. Auf der Google Cloud Platform-Seite können Sie nicht erzwingen, dass Google-Konten, die Zugriff auf Ihr Projekt haben, MFA aktiviert haben müssen. Wenn Sie jedoch nur Nutzern aus Ihrer Google Suite-Domäne Zugriff gewähren, kann der Administrator MFA so einrichten, dass jeder gezwungen ist, es zu verwenden. Was ist, wenn Sie Personen ohne Konten in Ihrer Google Suite-Domäne Zugriff gewähren müssen? Sie können für diese Personen Konten in Ihrer Google Suite-Domäne erstellen, die ausschließlich für den Zugriff auf Ihr Projekt bestimmt sind. Auf diese Weise können Sie Einstellungen für deren Konten erzwingen.
Wenn Sie diese beiden Regeln kombinieren, können Sie sicher sein, dass jeder Nutzer, der Zugriff auf das Google Cloud Platform-Projekt hat, sich mit MFA validieren muss. Das macht es viel schwieriger, Ihr Projekt zu kompromittieren, selbst wenn das Passwort für eine E-Mail-Adresse aus einer anderen Quelle durchsickert.
Hier finden Sie Informationen darüber, wie Sie die MFA-Authentifizierung (für Google Suite Domains, MFA verwendet 2 Faktoren) für Google Suite Domains erzwingen können.
Die Einstellungen der Passwortrichtlinien sind technisch gesehen nicht innerhalb der Google Cloud Platform. Sie liegen im Ermessen des Google Suite Domain-Administrators. Wenn Sie nur Nutzer aus Ihrer Domäne zulassen und die Domäne mit der richtigen Passwortrichtlinie eingerichtet ist, werden diese beiden Dinge zusammen dazu führen, dass die Passwortrichtlinie für alle Ihre GCP-Nutzer durchgesetzt wird. Hier finden Sie weitere Informationen darüber, wie Sie die Passwortanforderungen für Ihre Google Suite-Domain einrichten können.
Es ist im Allgemeinen eine gute Praxis, allen Ihren Nutzern nur die minimal erforderlichen Berechtigungen zu gewähren. Wenn alle zuvor besprochenen Methoden zum Schutz von Konten fehlschlagen, haben Ihre Angreifer immer noch weniger Dienste, in die sie einbrechen oder von denen sie Informationen stehlen können. Die tatsächliche Umsetzung dieses Grundsatzes hängt von Ihrem Nutzungsverhalten ab. Geben Sie beispielsweise Ihren Datenbankadministratoren, die nur Google Cloud SQL-Verwaltungsaufgaben durchführen, nicht die Rolle "Project Editor". Geben Sie ihnen stattdessen die Rolle Cloud SQL Admin.
Die meisten Rollen in IAM sind leicht zu verstehen. Sie verfügen sogar über Beschreibungen, die Ihnen bei der Entscheidung helfen, welche Rolle Sie für ein bestimmtes Szenario verwenden möchten. Es gibt jedoch einige bemerkenswerte Ausnahmen, bei denen es ziemlich schwierig ist zu entscheiden, welche Rolle für einen bestimmten Vorgang ausreichend ist. So sind zum Beispiel die Google Compute Engine (GCE)-bezogenen Rollen etwas verworren, vor allem seit neue Regeln eingeführt wurden, die sich derzeit noch im Beta-Stadium befinden.
Das Wichtigste ist, dass viele GCE-bezogene Rollen Ihnen SSH-Zugriff auf die Instanzen selbst gewähren. Wenn die Instanz unter Linux läuft, erstellt GCE das Konto so, dass Sie mit sudo zu root werden können. Wenn Sie diesen "Nebeneffekt" bei der Zuweisung von GCE-bezogenen Rollen nicht wünschen, lesen Sie die Dokumentation für weitere Details.
Für jedes neu erstellte Projekt auf Google Cloud Platform werden standardmäßig Kontingente festgelegt. Dies ist eine letzte Sicherheitskontrolle, um unerwartete unkontrollierte Ausgaben zu vermeiden. So kann beispielsweise ein fehlerhaftes Skript, das Ressourcen auf rekursive Weise erstellt, diese nur bis zu den Quotengrenzen erstellen. Es kann auch vor einem kompromittierten Konto schützen, das viele neue Ressourcen für die Zwecke des Angreifers erstellt.
Sie können die Quoten auf der Seite Quotas ändern, benötigen dafür aber die Berechtigung serviceusage.quotas.update. Diese Berechtigung ist nur in den folgenden vordefinierten Rollen enthalten: Eigentümer, Redakteur und Quotenadministrator. Wenn also ein kompromittiertes Konto oder ein fehlerhaftes Skript nicht über diese Berechtigung verfügt, können die Ausgaben nur bis zu den Quotengrenzen erhöht werden.
Neben den Nutzerkonten gibt es auf der Google Cloud Platform eine weitere Art von Konten: Dienstkonten.
Dienstkonten sind für programmatische Anwendungsfälle gedacht. Sie können sie nicht für den Zugriff auf die Google Cloud Console verwenden, 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 ohne zusätzliche Authentifizierung auf andere Cloud-Dienste zugreifen. Wie Sie Servicekonten in Kombination mit GCE verwenden können, erfahren Sie im dritten Beitrag dieser Serie im Detail.
Dienstkonten verwenden Schlüssel zur Authentifizierung. Einem Dienstkonto können mehrere Schlüssel zugeordnet sein. Es ist eine gute Praxis, die Schlüssel des Dienstkontos regelmäßig zu wechseln. Sie können dies erreichen, indem Sie einen neuen Schlüssel für das Dienstkonto erstellen. Dann müssen Sie den aktuellen Schlüssel mit dem neuen Schlüssel überschreiben, und zwar überall dort, wo er gespeichert wurde. Zum Schluss müssen Sie den alten Schlüssel für das Dienstkonto löschen. Auf diese Weise hat der Angreifer nur ein begrenztes Zeitfenster für die Verwendung des Schlüssels. Selbst wenn eine Anwendung, in der der Schlüssel gespeichert war, ohne Ihr Wissen kompromittiert wird.
Weitere Informationen zur IAM-Sicherheit finden Sie in der Google Cloud Platform-Dokumentation auf dieser Seite.
Wenn es sich bei Ihrer Organisation um ein großes Unternehmen handelt, sollten Sie sich die Sicherheitsrichtlinien ansehen, die hier speziell für größere Kunden geschrieben wurden.
