Es wird empfohlen, Richtlinieneinschränkungen zu definieren, die akzeptable Ressourcenkonfigurationen erzwingen und riskante Konfigurationen verhindern. Der Blueprint verwendet eine Kombination aus Organisationsrichtlinieneinschränkungen und der IaC-Validierung (Infrastructure-as-Code) in Ihrer Pipeline. Durch diese Steuerelemente wird verhindert, dass Ressourcen erstellt werden, die nicht Ihren Richtlinienrichtlinien entsprechen. Wenn Sie diese Kontrollen früh im Design und Build Ihrer Arbeitslasten erzwingen, können Sie spätere Abhilfemaßnahmen 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 ausreichenden IAM-Rollen.
Der Blueprint erzwingt Richtlinien auf dem Organisationsknoten, sodass diese Kontrollen von allen Ordnern und Projekten innerhalb der Organisation übernommen werden. Mit diesem Richtlinien-Bundle sollen bestimmte Konfigurationen mit hohem Risiko verhindert werden, z. B. die Freigabe einer VM im öffentlichen Internet oder das Gewähren des öffentlichen Zugriffs auf Storage-Buckets, es sei denn, Sie erlauben explizit eine Ausnahme von der Richtlinie.
In der folgenden Tabelle werden die Einschränkungen für Organisationsrichtlinien vorgestellt, die im Blueprint implementiert sind:
| Organisationsrichtlinie-Beschränkung | Beschreibung |
|---|---|
| Verschachtelte Virtualisierung auf Compute Engine-VMs kann das Monitoring und andere Sicherheitstools für Ihre VMs umgehen, wenn sie schlecht konfiguriert sind. Diese Einschränkung verhindert die Erstellung der verschachtelten Virtualisierung. |
| IAM-Rollen wie |
| Externe IPv6-Subnetze können bei nicht autorisierter Konfiguration für nicht autorisierten Internetzugriff freigegeben werden. Diese Einschränkung verhindert die Erstellung externer IPv6-Subnetze. |
| Das Standardverhalten bei der Einstellung SSH-Schlüssel in Metadaten kann den nicht autorisierten Remotezugriff auf VMs zulassen, wenn Schlüssel verfügbar gemacht 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 bei nicht ausreichender Weiterleitung zu nicht autorisiertem ausgehenden Internettraffic führen. Diese Einschränkung ermöglicht die VM-Protokollweiterleitung nur für interne Adressen. |
|
Das Löschen eines freigegebenen VPC-Hostprojekts kann alle Dienstprojekte beeinträchtigen, die Netzwerkressourcen verwenden. Diese Einschränkung verhindert das versehentliche oder böswillige Löschen der freigegebenen VPC-Hostprojekte, da die Projektsperre für diese Projekte nicht entfernt wird. |
|
Eine Legacy-Einstellung für das globale (projektweite) interne DNS wird nicht empfohlen, da dies die Dienstverfügbarkeit reduziert. Diese Einschränkung verhindert die Verwendung der Legacy-Einstellung. |
| 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 die Erstellung der Standardnetzwerk- und Standard-VPC-Firewallregeln übersprungen. |
| Standardmäßig wird eine VM mit einer externen IPv4-Adresse erstellt, die zu einem nicht autorisierten Internetzugriff führen kann. Mit dieser Einschränkung wird eine leere Zulassungsliste externer IP-Adressen konfiguriert, die die VM verwenden kann. Alle anderen werden abgelehnt. |
|
Standardmäßig können Wichtige Kontakte so konfiguriert werden, dass Benachrichtigungen über Ihre Domain an eine andere Domain gesendet werden. Durch diese Einschränkung wird erzwungen, dass nur E-Mail-Adressen in genehmigten Domains als Empfänger für wichtige Kontakte festgelegt werden können. |
| Standardmäßig können Zulassungsrichtlinien jedem Google-Konto zugewiesen werden, einschließlich nicht verwalteter Konten und Konten, die zu externen Organisationen gehören. Mit dieser Einschränkung wird sichergestellt, dass Richtlinien 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 moderate Rollen zugewiesen. Diese Einschränkung verhindert, dass Standarddienstkonten automatisch eine IAM-Rolle zugewiesen wird. |
|
Dienstkontoschlüssel sind nichtflüchtige Anmeldedaten mit hohem Risiko. In den meisten Fällen kann eine sicherere Alternative zu Dienstkontoschlüsseln verwendet werden. Diese Einschränkung verhindert das Erstellen von Dienstkontoschlüsseln. |
|
Das Hochladen von Schlüsselmaterial für das Dienstkonto kann das Risiko erhöhen, wenn Schlüsselmaterial bereitgestellt wird. Diese Einschränkung verhindert das Hochladen von Dienstkontoschlüsseln. |
|
Cloud SQL-Instanzen können über einen nicht authentifizierten Internetzugriff bereitgestellt werden, 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 authentifizierten Internetzugriff ausgesetzt sein, wenn die Instanzen mit öffentlichen IP-Adressen erstellt werden. Diese Einschränkung verhindert öffentliche IP-Adressen auf 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. eine Der Zugriff auf Legacy-ACLs ist von der Einschränkung |
|
Cloud Storage-Buckets können bei nicht konfiguriertem Internetzugriff freigegeben werden. Diese Einschränkung verhindert ACLs und IAM-Berechtigungen, mit denen der 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 anzupassen. Beispielsweise wird eine Arbeitslast, die einen Cloud Storage-Bucket als Back-End für Cloud CDN zum Hosten öffentlicher Ressourcen verwendet, von storage.publicAccessPrevention oder einer öffentlichen Cloud Run-Anwendung blockiert, die keine Authentifizierung durch iam.allowedPolicyMemberDomains blockiert. Ändern Sie in diesen Fällen die Organisationsrichtlinie auf Ordner- oder Projektebene, um eine enge Ausnahme zu ermöglichen.
Sie können auch Organisationsrichtlinien Einschränkungen 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.
Infrastruktur als Code vor der Bereitstellung validieren
Der Blueprint verwendet einen GitOps-Ansatz zur Verwaltung der Infrastruktur. Das bedeutet, dass alle Infrastrukturänderungen über die versionsgesteuerte Infrastruktur als Code (IaC) implementiert werden und vor dem Deployment validiert werden können.
Die im Blueprint erzwungenen Richtlinien definieren akzeptable Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn Code, der an Ihr GitHub-Repository gesendet wird, die Richtlinienprüfungen nicht besteht, werden keine Ressourcen bereitgestellt.
Informationen zur Verwendung von Pipelines und zur Durchsetzung von Kontrollen über die CI/CD-Automatisierung finden Sie unter Bereitstellungsmethode.
Wie geht es weiter?
- Mehr über die Bereitstellungsmethode erfahren (nächstes Dokument in dieser Reihe)