Wir empfehlen, Richtlinieneinschränkungen zu definieren, die akzeptable Ressourcenkonfigurationen erzwingen und riskante Konfigurationen verhindern. Der Blueprint verwendet eine Kombination aus Einschränkungen der Organisationsrichtlinien und IaC-Validierung (Infrastructure-as-Code) in Ihrer Pipeline. Durch diese Kontrollen wird verhindert, dass Ressourcen erstellt werden, die nicht Ihren Richtlinien entsprechen. Wenn Sie diese Steuerelemente schon früh beim Entwerfen und Erstellen Ihrer Arbeitslasten erzwingen, können Sie spätere Korrekturarbeiten vermeiden.
Einschränkungen für Organisationsrichtlinien
Der Organisationsrichtliniendienst erzwingt Einschränkungen, um sicherzustellen, dass bestimmte Ressourcenkonfigurationen in Ihrer Google Cloud-Organisation nicht erstellt werden können, auch nicht durch eine Person mit einer IAM-Rolle mit ausreichend Rechten.
Der Blueprint erzwingt Richtlinien auf dem Organisationsknoten, sodass diese Steuerelemente von allen Ordnern und Projekten in der Organisation übernommen werden. Dieses Richtlinienpaket soll bestimmte Konfigurationen mit hohem Risiko verhindern, z. B. die Freigabe einer VM für das öffentliche Internet oder die Gewährung öffentlichen Zugriffs auf Speicher-Buckets, es sei denn, Sie erlauben bewusst eine Ausnahme von der Richtlinie.
In der folgenden Tabelle werden die Einschränkungen für Organisationsrichtlinien beschrieben, die im Blueprint implementiert sind:
| Organisationsrichtlinie-Beschränkung | Beschreibung |
|---|---|
| Eine verschachtelte Virtualisierung auf Compute Engine-VMs kann bei unsachgemäßer Konfiguration Monitoring und andere Sicherheitstools für Ihre VMs umgehen. Diese Einschränkung verhindert das Erstellen einer verschachtelten Virtualisierung. |
| IAM-Rollen wie |
| Externe IPv6-Subnetze können für nicht autorisierten Internetzugriff freigegeben werden, wenn sie schlecht konfiguriert sind. Diese Einschränkung verhindert das Erstellen externer IPv6-Subnetze. |
| Das standardmäßige Festlegen von SSH-Schlüsseln in Metadaten kann unbefugten Remotezugriff auf VMs ermöglichen, wenn die Schlüssel offengelegt werden. Diese Einschränkung erzwingt die Verwendung von OS Login anstelle von metadatenbasierten SSH-Schlüsseln. |
|
Eine VM-Protokollweiterleitung für externe IP-Adressen kann zu nicht autorisiertem ausgehenden Internettraffic führen, wenn sie schlecht konfiguriert ist. Diese Einschränkung erlaubt die VM-Protokollweiterleitung nur für interne Adressen. |
|
Das Löschen eines Hostprojekts einer freigegebene VPC kann Auswirkungen auf alle Dienstprojekte haben, die Netzwerkressourcen verwenden. Diese Einschränkung verhindert das versehentliche oder böswillige Löschen der freigegebenen VPC-Hostprojekte, da sie das Entfernen der Projektsperre für diese Projekte verhindert. |
|
Eine Legacy-Einstellung für das globale (projektweite) interne DNS wird nicht empfohlen, da sie die Dienstverfügbarkeit verringert. Durch diese Einschränkung wird die Verwendung der alten Einstellung verhindert. |
| In jedem neuen Projekt, für das die Compute Engine API aktiviert ist, werden ein Standard-VPC-Netzwerk und zu moderate Standard-VPC-Firewallregeln erstellt. Mit dieser Einschränkung wird das Erstellen des Standardnetzwerks und der Standard-VPC-Firewallregeln übersprungen. |
| Standardmäßig wird eine VM mit einer externen IPv4-Adresse erstellt, was zu nicht autorisierten Zugriffen aus dem Internet führen kann. Mit dieser Einschränkung wird eine leere Zulassungsliste mit externen IP-Adressen konfiguriert, die die VM verwenden kann. Alle anderen werden abgelehnt. |
|
Standardmäßig können wichtige Kontakte so konfiguriert werden, dass Benachrichtigungen zu Ihrer Domain an jede andere Domain gesendet werden. Mit dieser Einschränkung wird festgelegt, dass nur E-Mail-Adressen in genehmigten Domains als Empfänger für wichtige Kontakte festgelegt werden können. |
| Standardmäßig können Zulassungsrichtlinien für jedes Google-Konto gewährt werden, einschließlich nicht verwalteter Konten und Konten externer Organisationen. Mit dieser Einschränkung wird sichergestellt, dass Zulassungsrichtlinien in Ihrer Organisation nur verwalteten Konten aus Ihrer eigenen Domain gewährt werden können. Optional können Sie zusätzliche Domains zulassen. |
|
Standardmäßig werden Standarddienstkonten automatisch zu weitreichende Rollen zugewiesen. Diese Einschränkung verhindert die automatische Zuweisung von IAM-Rollen für Standarddienstkonten. |
|
Dienstkontoschlüssel sind nichtflüchtige Anmeldedaten mit hohem Risiko. In den meisten Fällen kann eine sicherere Alternative zu Dienstkontoschlüsseln verwendet werden. Durch diese Einschränkung wird das Erstellen von Dienstkontoschlüsseln verhindert. |
|
Wenn Sie Dienstkontoschlüsselmaterial hochladen, kann das Risiko steigen, wenn das Schlüsselmaterial offengelegt wird. Durch diese Einschränkung wird das Hochladen von Dienstkontoschlüsseln verhindert. |
|
Cloud SQL-Instanzen können nicht authentifiziertem Internetzugriff ausgesetzt sein, wenn die Instanzen so konfiguriert sind, dass sie autorisierte Netzwerke ohne Cloud SQL Auth-Proxy verwenden. Diese Richtlinie verhindert die Konfiguration autorisierter Netzwerke für den Datenbankzugriff und erzwingt stattdessen die Verwendung des Cloud SQL Auth-Proxys. |
| Cloud SQL-Instanzen können nicht authentifiziertem Internetzugriff ausgesetzt sein, wenn die Instanzen mit öffentlichen IP-Adressen erstellt werden. Diese Einschränkung verhindert öffentliche IP-Adressen in Cloud SQL-Instanzen. |
| Auf Objekte kann in Cloud Storage standardmäßig über Legacy-Access Control Lists (ACLs) statt auf IAM zugegriffen werden. Dies kann zu inkonsistenten Zugriffssteuerungen und zu einer versehentlichen Offenlegung führen, wenn falsch konfiguriert wird. Der Zugriff über Legacy-ACLs ist von der Einschränkung |
|
Cloud Storage-Buckets können nicht autorisiertem Internetzugriff ausgesetzt sein, wenn sie falsch konfiguriert sind. Diese Einschränkung verhindert ACLs und IAM-Berechtigungen, die Zugriff auf |
Diese Richtlinien sind ein Ausgangspunkt, den wir für die meisten Kunden und die meisten Szenarien empfehlen. Möglicherweise müssen Sie jedoch die Einschränkungen für Organisationsrichtlinien ändern, um bestimmte Arbeitslasttypen zu berücksichtigen. Beispielsweise wird eine Arbeitslast, die einen Cloud Storage-Bucket als Back-End für Cloud CDN zum Hosten öffentlicher Ressourcen verwendet, von storage.publicAccessPrevention blockiert, oder eine öffentliche Cloud Run-Anwendung, die keine Authentifizierung erfordert, wird durch iam.allowedPolicyMemberDomains blockiert. In diesen Fällen sollten Sie die Organisationsrichtlinie auf Ordner- oder Projektebene ändern, um eine eng gefasste Ausnahme zuzulassen.
Sie können auch Organisationsrichtlinien Einschränkungen bedingt hinzufügen, indem Sie ein Tag definieren, das eine Ausnahme oder Erzwingung für Richtlinien gewährt, und das Tag dann auf Projekte und Ordner anwenden.
Weitere Einschränkungen finden Sie unter Verfügbare Einschränkungen und Benutzerdefinierte Einschränkungen.
Vor der Bereitstellung Infrastruktur als Code validieren
Der Blueprint verwendet einen GitOps-Ansatz zur Verwaltung der Infrastruktur. Das bedeutet, dass alle Infrastrukturänderungen über versionierte Infrastructure as Code (IaC) implementiert werden und vor der Bereitstellung validiert werden können.
Die im Blueprint erzwungenen Richtlinien definieren zulässige Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn Code, der in Ihr GitHub-Repository hochgeladen wird, die Richtlinienprüfungen nicht besteht, werden keine Ressourcen bereitgestellt.
Informationen zur Verwendung von Pipelines und zur Durchsetzung von Kontrollen durch CI/CD-Automatisierung finden Sie unter Bereitstellungsmethodik.
Nächste Schritte
- Bereitstellungsmethode (nächstes Dokument in dieser Reihe)