Fünf Infrastruktur-Richtlinien, die verhindern, dass Ihre Cloud Geld und Sicherheit verbrennt

Ein Entwickler benötigt SSH-Zugriff auf einen Produktionsserver für eine kurze Debugging-Sitzung. Er öffnet Port 22 für 0.0.0.0/0, damit er sich von seiner Heim-IP verbinden kann. Das Debugging ist beendet, das Ticket wird geschlossen, und diese Security-Group-Regel bleibt drei Monate lang offen. Niemand bemerkt es, bis die Cloud-Rechnung mit einer Überraschung eintrifft: Jemand hat eine m5.24xlarge-Instanz im Dev-Account gestartet, die 24/7 läuft, ohne Tags, und den Namen test123 trägt.

Dies ist keine hypothetische Situation. Dieses Muster wiederholt sich quartalsweise in Teams auf der ganzen Welt. Die Lösung ist nicht mehr manuelle Überprüfung oder strengere Zugriffskontrollen. Die Lösung ist Policy as Code, die automatisch geprüft wird, bevor eine Ressource erstellt wird.

Infrastruktur-Richtlinien lassen sich in fünf Kategorien einteilen. Jede löst eine bestimmte Klasse von Problemen. Wenn Sie diese verstehen, können Sie entscheiden, welche Sie in Ihrer Pipeline priorisieren sollten.

Sicherheit: Die unverhandelbare Basis

Sicherheitsrichtlinien sind am kritischsten, da Verstöße sofortige, sichtbare Konsequenzen haben. Das klassische Beispiel ist das Blockieren von Security-Group-Regeln, die SSH- oder Datenbank-Ports für 0.0.0.0/0 öffnen. Entwickler öffnen diese oft für temporären Zugriff und vergessen, sie zu schließen. Eine Richtlinie, die solche Regeln zur Pipeline-Zeit ablehnt, verhindert, dass Produktionsressourcen versehentlich dem Internet ausgesetzt werden.

Weitere gängige Sicherheitsrichtlinien sind:

  • Verschlüsselung im Ruhezustand für S3-Buckets und EBS-Volumes erzwingen
  • Veraltete TLS-Versionen auf Load Balancern blockieren
  • HTTPS-only Traffic auf allen öffentlichen Endpunkten erzwingen
  • VPC Flow Logs für Produktionsumgebungen vorschreiben
  • IAM-Rollen anstelle von langlebigen Zugriffsschlüsseln vorschreiben

Sicherheitsrichtlinien haben in der Regel ein hartes Fehlverhalten: Wenn die Prüfung fehlschlägt, stoppt die Pipeline und die Ressource wird nicht erstellt. Es gibt keinen Warnmodus für einen Port, der für das gesamte Internet geöffnet ist.

Kosten: Versehentliche Bankrotte verhindern

Cloud-Ressourcen sind teuer, wenn sie nicht kontrolliert werden. Ein einzelner Entwickler kann versehentlich einen Instanztyp provisionieren, der so viel kostet wie das Monatsgehalt eines Teammitglieds. Kostenrichtlinien setzen Leitplanken für Ausgaben, ohne dass jede Ressource manuell genehmigt werden muss.

Typische Kostenrichtlinien umfassen:

  • Teure Instanztypen (wie m5.24xlarge oder r5.metal) in Nicht-Produktionsumgebungen blockieren
  • Die Anzahl der EBS-Volumes oder GPUs pro Account begrenzen
  • Spot-Instanzen für fehlertolerante Workloads vorschreiben
  • Maximale Speichergrößen für Datenbanken festlegen
  • Auto-Stop-Zeitpläne für Entwicklungsumgebungen erzwingen

Kostenrichtlinien helfen Teams, budgetbewusst zu bleiben, insbesondere wenn viele Entwickler Cloud-Zugriff haben. Ohne sie kann die Bequemlichkeit einer Person zur Überraschungsrechnung des Teams werden.

Tagging: Die Metadaten, die den Betrieb am Laufen halten

Tagging klingt langweilig, bis Sie herausfinden müssen, wem eine Ressource gehört, die seit sechs Monaten läuft. Tags wie owner, environment, cost-center und project sind unerlässlich für die Kostenverfolgung, die Automatisierung der Bereinigung und das Debugging von Vorfällen.

Tagging-Richtlinien erzwingen, dass jede Ressource zum Zeitpunkt der Erstellung die erforderlichen Tags hat. Zum Beispiel:

  • Jede Ressource muss einen owner-Tag mit einer gültigen E-Mail-Adresse haben
  • Jede Ressource muss einen environment-Tag haben: dev, staging oder production
  • Jede Ressource muss einen cost-center-Tag haben, der dem Budgetcode des Teams entspricht

Wenn eine Ressource die Tagging-Richtlinie nicht erfüllt, kann die Pipeline sie entweder ablehnen oder mit einer Warnung und einer geplanten Bereinigung erstellen. Wichtig ist, dass ungetaggte Ressourcen nicht stillschweigend akkumulieren. Tagging-Richtlinien verhindern das Problem der „verwaisten Ressourcen“, bei dem Abrechnungsteams monatelang mysteriöse Ressourcen ohne klaren Besitzer finden.

Namenskonventionen: Konsistenz für Menschen und Automatisierung

Ressourcennamen sind wichtiger, als die meisten Teams glauben. Ein Bucket namens test123 und ein anderer namens data-barang sind schwer zu durchsuchen, schwer zu automatisieren und schwer zu troubleshooten. Namensrichtlinien erzwingen konsistente Muster, damit Betriebsteams und Automatisierungstools Ressourcen schnell finden können.

Häufige Namensrichtlinien sind:

  • Alle S3-Buckets müssen mit dem Projektnamen beginnen
  • Alle Security Groups müssen ein Präfix haben, das die Umgebung angibt
  • Alle RDS-Instanzen müssen dem Muster {projekt}-{umgebung}-{funktion} folgen
  • Alle IAM-Rollen müssen den Dienstnamen und die Berechtigungsstufe enthalten

Namensrichtlinien werden oft mit Tagging-Richtlinien kombiniert. Zusammen stellen sie sicher, dass jede Ressource identifizierbar, durchsuchbar und skalierbar verwaltbar ist. Ohne sie enden Sie mit einem Cloud-Account, der wie eine Schublade voller Krimskrams aussieht.

Compliance: Externe Regeln in Code übersetzen

Compliance-Richtlinien behandeln Anforderungen aus externen Vorschriften wie PCI DSS, HIPAA, SOC 2 oder GDPR. Diese sind nicht optional. Sie übersetzen rechtliche und regulatorische Anforderungen in automatisierte Prüfungen, die ausgeführt werden, bevor eine Ressource bereitgestellt wird.

Beispiele für Compliance-Richtlinien:

  • Alle Produktionsdatenbanken müssen Verschlüsselung im Ruhezustand verwenden
  • Jeder Zugriff auf Produktionsressourcen muss in einem zentralen Audit-Trail protokolliert werden
  • Alle Daten müssen in genehmigten geografischen Regionen gespeichert werden
  • Alle Backups müssen verschlüsselt und in einem separaten Account gespeichert werden
  • Jeder API-Zugriff muss Multi-Faktor-Authentifizierung verwenden

Compliance-Richtlinien sind oft am schwierigsten zu verhandeln, da sie von außerhalb des Engineering-Teams kommen. Aber sie als Code zu kodieren, macht sie konsistent, prüfbar und viel einfacher durchzusetzen als manuelle Checklisten.

Wie diese Richtlinien interagieren

Diese fünf Kategorien wirken nicht isoliert. Eine einzelne EC2-Instanz wird gleichzeitig gegen mehrere Richtlinien geprüft: Security-Group-Regeln, Instanztyp, Tags, Namensmuster und Compliance-Anforderungen. Eine gute Pipeline führt all diese Prüfungen durch, bevor die Ressource erstellt wird, nicht danach.

Das folgende Diagramm zeigt, wie die fünf Richtlinienkategorien zueinander und zur Deployment-Pipeline in Beziehung stehen:

flowchart TD A[Pipeline-Trigger] --> B{Sicherheit & Compliance} B -->|Bestanden| C{Kosten} B -->|Fehlgeschlagen| D[Ressource ablehnen] C -->|Bestanden| E{Tagging} C -->|Fehlgeschlagen| D E -->|Bestanden| F{Namenskonventionen} E -->|Fehlgeschlagen| G[Warnen oder ablehnen] F -->|Bestanden| H[Ressource erstellen] F -->|Fehlgeschlagen| G D --> I[Team benachrichtigen] G --> I

Auch die Reihenfolge ist wichtig. Sicherheits- und Compliance-Prüfungen sollten zuerst laufen, da Verstöße in diesen Kategorien nicht verhandelbar sind. Kosten- und Tagging-Prüfungen können folgen. Namensprüfungen sind in der Regel am wenigsten kritisch, aber dennoch wertvoll für die betriebliche Stabilität.

Praktische Checkliste für den Einstieg

Wenn Sie neu bei Infrastruktur-Richtlinien sind, fangen Sie klein an. Wählen Sie eine Kategorie und automatisieren Sie eine Prüfung. Hier ist eine Abfolge, die für die meisten Teams funktioniert:

  • Woche eins: Fügen Sie eine Sicherheitsrichtlinie hinzu, die öffentlichen SSH-Zugriff blockiert. Lassen Sie die Pipeline hart fehlschlagen.
  • Woche zwei: Fügen Sie eine Tagging-Richtlinie hinzu, die owner- und environment-Tags erfordert. Beginnen Sie mit einer Warnung und wechseln Sie nach zwei Wochen zu einem harten Fehlschlag.
  • Woche drei: Fügen Sie eine Kostenrichtlinie hinzu, die teure Instanztypen in Dev-Accounts blockiert. Warnen Sie bei Verstoß und eskalieren Sie an den Teamleiter.
  • Woche vier: Fügen Sie Namenskonventionen für die häufigsten Ressourcentypen in Ihrem Account hinzu.
  • Monat zwei: Überprüfen Sie die Compliance-Anforderungen und kodieren Sie die drei wichtigsten als automatisierte Prüfungen.

Das Ziel ist nicht, alle Richtlinien auf einmal zu schreiben. Das Ziel ist, Dynamik aufzubauen, indem Sie zuerst die schmerzhaftesten Probleme lösen.

Was am wichtigsten ist

Sicherheits- und Compliance-Richtlinien schützen Sie vor externen Bedrohungen und rechtlichen Risiken. Kostenrichtlinien schützen Ihr Budget. Tagging- und Namensrichtlinien schützen Ihre betriebliche Stabilität. Alle fünf Kategorien arbeiten zusammen, um das Infrastrukturmanagement von einem manuellen, fehleranfälligen Prozess in einen automatisierten, konsistenten zu verwandeln.

Beginnen Sie mit der Richtlinie, die heute am meisten wehtut. Für die meisten Teams ist das entweder die Security Group, die weit offen für das Internet ist, oder die mysteriöse Ressource, die die Rechnung in die Höhe treibt. Automatisieren Sie diese Prüfung, dann gehen Sie zur nächsten über. Mit der Zeit wird Ihre Pipeline zu einem Sicherheitsnetz, das Fehler abfängt, bevor sie zu Vorfällen werden.