Stellar Engine ist mit mehrschichtigen Phasen konzipiert, um die Abhängigkeitsisolierung, die Sicherheitseinschränkung und wiederholbare Bereitstellungen zu implementieren. Das Repository ist in vier aufeinanderfolgende Phasen unterteilt. Jede Phase ist für einen bestimmten Bereich der Landing Zone verantwortlich.
Phase 0: Bootstrap
In der Bootstrap -Phase wird die minimal funktionsfähige Infrastruktur initialisiert, die für die Verwaltung des Bereitstellungsprozesses selbst erforderlich ist. Sie fungiert als Vertrauensanker für die IaC-Pipeline.
In dieser Phase wird das Prinzip der geringsten Berechtigung für das anfängliche Dienstkonto des Bereitstellers und eine strikte Trennung der Verwaltungshierarchie verwendet.
Ziel dieser Phase ist es, Folgendes zu erstellen:
- Verwaltungsgrundlage
- Remote-Zustandsverwaltung
- Erster Sicherheitsperimeter
Die folgenden Ressourcen werden erstellt:
- Verbindungen zu Abrechnungskonten und Budgetbenachrichtigungen
- Dediziertes administratives IaC-Projekt zum Hosten von Dienstkonten für die Bereitstellung
- Abgesicherte Cloud Storage-Buckets für den Terraform-Remote Zustand, bei denen die Objektversionsverwaltung aktiviert ist
- Globale Audit-Log-Senken, die in einen zentralen Cloud Logging Bucket eingebunden sind
- Konfiguration von „Wichtige Kontakte“, um sicherzustellen, dass Sicherheits-, Technik- und Abrechnungsbenachrichtigungen nur an autorisierte Agenturdomains weitergeleitet werden
Phase 1: Ressourcenverwaltung
In der Phase der Ressourcenverwaltung werden die Organisationshierarchie, die Zugriffsgrenzen und die Mandantenisolierung erstellt.
Ziel dieser Phase ist es, die Ordner, Projekte und benutzerdefinierten IAM-Rollen zu definieren, die für bestimmte rechtliche Rahmenbedingungen erforderlich sind.
In dieser Phase wird das Prinzip der Aufgabentrennung über verschiedene Verwaltungsdomains hinweg und eine strikte Ressourcenisolierung verwendet.
Die folgenden Ressourcen werden erstellt:
- Compliance-konforme Ordnerhierarchie (z. B.
Prod,Non-Prod,Security, undShared) - Dedizierte Mandantenprojekte, die nach Umgebung und Funktion isoliert sind
- Granulare IAM-Rollenbindungen und benutzerdefinierte Rollen, um das Prinzip der geringsten Berechtigung zu erzwingen
Phase 2: Netzwerke
In der Phase der Netzwerke werden die Kommunikationswege, die Sicherheitskontrollen für die Grenzen und die Hybridkonnektivität bereitgestellt. Stellar Engine unterstützt mehrere Netzwerkmodule, darunter FedRAMP High und IL5 NGFW.
Ziel dieser Phase ist es, sichere Konnektivitätsmuster, Paketfilterung und Kontrollen für eingehenden und ausgehenden Traffic einzurichten.
In dieser Phase liegt der Schwerpunkt auf dem strikten Schutz der Grenzen, der zentralen Traffic-Prüfung und der detaillierten Paketfilterung. Nachdem Sie diese Phase ausgeführt haben, binden Sie eine SIEM-Lösung ein, um die Ressourcen zu beobachten. Segmentieren Sie Ihr SIEM in einem separaten Google Cloud Projekt und in einer separaten VPC, von der aus Daten erfasst werden.
Die folgenden Ressourcen werden erstellt:
- Hub-and-Spoke-Topologie mit gemeinsam genutzter VPC oder Network Connectivity Center -Architekturen, die die öffentliche Gefährdung minimieren
- VPC-Peering-, Cloud VPN- oder Dedicated Interconnect-Verbindungen für Hybridarbeitslasten
- Standard-VPC-Routing oder erweiterte Dienstverkettung mit Palo Alto VM-Series Next-Generation Firewalls (NGFW) (erforderlich für DoD IL5-Enklaven) in einer speziellen VPC für die Prüfung
Phase 3: Sicherheit und Audit
Ziel dieser Phase ist es, den Datenschutz, die Audit-Nachverfolgbarkeit und die kryptografische Souveränität zu verbessern.
In dieser Phase liegt der Schwerpunkt auf der Souveränität im Ruhezustand, der Souveränität bei der Verwendung und der strikten kryptografischen Isolierung von Daten.
Die folgenden Ressourcen werden erstellt:
- Cloud Key Management Service-Schlüsselringe und ‑schlüssel, um die Anforderungen an vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) für alle Speicher dienste zu erfüllen
- Sperrskripts und Einschränkungen des Organisationsrichtliniendienstes, die auf die Dienstkonten angewendet werden, die während der Bereitstellung verwendet werden
- Themen für unzustellbare Nachrichten und Benachrichtigungen für die fehlgeschlagene Aufnahme von Audit-Logs
Bereitstellungsprinzipien
In der folgenden Tabelle werden die Prinzipien beschrieben, die Stellar Engine für den Bereitstellungsprozess verwendet.
| Prinzip | Beschreibung |
|---|---|
| Zustandsisolierung |
Terraform-Zustandsdateien werden strikt nach Phase getrennt. Ein Fehler oder eine Zustandsbeschädigung in Phase 2 kann beispielsweise nicht auf den Kernzustand oder die Anmeldedaten der Phasen 0 oder 1 zugreifen oder diese beschädigen. |
| Modulversion anpinnen |
Blueprints verweisen auf modulare Abhängigkeiten mit angepinnten Git-Tags oder Commit-Hashes. Durch das Anpinnen wird verhindert, dass Upstream-Änderungen in der Modul registrierung ohne ausdrückliche Überprüfung automatisch in Zielumgebungen eingeführt werden. |
| Auswirkungen begrenzen |
Updates werden lokal in den Phasenverzeichnissen ausgeführt. Durch die Begrenzung der Auswirkungen wird sichergestellt, dass eine Codeänderung an Firewallregeln in Phase 2 keine Auswirkungen auf Cloud KMS-Schlüssel in Phase 3 hat. |
| Fehlerbegrenzung |
Cloud Storage-Zustands-Buckets werden mit aktivierter Objektversionsverwaltung konfiguriert. Wenn eine fehlerhafte Codeänderung oder eine manuelle Zustandsbearbeitung die Zustands datei beschädigt, kann die Datei sofort auf eine frühere Version zurückgesetzt werden. |