Betrieb und Verwaltung → Prüfung von Konfigurationen

Prüfung von Konfigurationen

1) Zweck und Wert

Konfigurationsaudits bieten nachweisbare Rechenschaftspflicht und Wiederholbarkeit von Änderungen: wer, wann und was hat sich geändert; als gerechtfertigt; wie geprüft; wie man zurückrollt. Dies reduziert das Risiko von Vorfällen, Geheimnissen, Compliance-Verstößen und „versteckten“ Bearbeitungen in der Produktion.

• Eine einzige Quelle der Wahrheit (SoT) für Config.
• Vollständige Änderungsverfolgung (End-to-End).
• Vorhersehbare Releases und schnelles Rollback.
• Compliance mit regulatorischen Anforderungen und Sicherheitsrichtlinien.

2) Geltungsbereich

Infrastruktur: Terraform/Helm/Ansible/K8s Manifeste, Netzwerk-ACL/WAF/CDN.
Anwendungs-Configs: 'yaml/json/properties' Dateien, Ficha-Flags, Limits/Kontingente.
Geheimnisse und Schlüssel: vault/kms, Zertifikate, Token, Passwörter.
Daten-Pipelines: Schemata, Transformationen, ETL/Stream-Zeitpläne.
Integrationen: PSP/KYC/Provider, Webhooks, Retry/Timeout-Richtlinien.
Beobachtbarkeit: Alert-Regeln, Dashboards, SLO/SLA.

3) Grundsätze

Config as Data: deklarative, versionierbare, testbare Artefakte.
Immutabilität und Idempotenz: Reproduzierbarkeit des Mediums aus dem Code.
Schemata und Verträge: strenge Validierung (JSON-Schema/Protobuf), Back-/Forward-Kompatibilität.
Manuelle Bearbeitungen minimieren: Änderungen nur über MR/PR.
Aufgabenteilung (SoD) und 4-Augen: Autor! = Deployer; Die obligatorische Revue.
Attribution und Signaturen: Commit-/Release-Signaturen, Artefakt-Attestationen.

4) Audit-Architektur

1. SCM (Git) als SoT: alle Configs im Repository, der 'main' -Zweig ist gesichert.

• Config Registry (Verzeichnis der Config, Ownership, SLA, Environments),
• Schema Registry (Versionen von Config/Event-Schemas),
• Policy Engine (OPA/Conftest) - Eine Reihe von Prüfungen.
• 3. CI/CD-Gates: Format/Schema → statische Überprüfung → Policy-Checks → Secret-Scan → Dry-Run → Änderungsplan.
• 4. Lieferung: GitOps (z.B. ArgoCD/Flux) mit Drift-Detektor und Audit-Logs der Anwendungen.
• 5. Evidence Store: Speicher für Audit-Artefakte (Plan, Protokolle, Signaturen, Bilds, SBOMs).
• 6. Aktivitätsprotokoll: Unveränderliches Protokoll (nur Append) der Ereignisse' CREATE/APPROVE/APPLY/ROLLBACK/ACCESS'.

5) Auditdatenmodell (Minimum)

Сущности: `ConfigItem(id, env, service, owner, schema_version, sensitivity)`

События: `change_id, actor, action, ts, diff_hash, reason, approvals[]`

Артефакты: `plan_url, test_report_url, policy_report, signature, release_tag`

Kommunikation: RFC/Ticket ↔ PR ↔ Depla (sha) ↔ Release Record ↔ SLO-Überwachung.

6) Veränderungsprozess (Ende-zu-Ende)

1. RFC/Ticket → Ziel, Risiko, Backout.
2. PR/MR → Linting, schematische Validierung, Policy-Checks, Secret-Scan.
3. Plan/Vorschau → Dry-Run/Plan, Ressourcen-Diff, Kostenschätzung/Impact.
4. Approve (4-eyes/SoD, CAB-Tag mit hohem Risiko).
5. Deploy (nach Fenster/Kalender) → GitOps verwendet; Drift-Alerting ist aktiviert.
6. Verifizierung → Smoke/SLO-Gardrails, Bestätigung des Ergebnisses.
7. Archivierung von Beweisen → evidence store; Aktualisierung des Config-Wörterbuchs.

7) Richtlinien und Regeln (Beispiele)

SoD: Der PR-Autor reitet nicht in den Prod.
Zeitlimit: Prod-Deploy außerhalb von „freeze“ ist verboten.
Scope: Das Ändern von sensitiven Schlüsseln erfordert 2x Apruver aus Security/Compliance.
Geheimnisse: Es ist verboten, in Repos zu speichern; nur vault-Pfadreferenzen + Zugriffsrolle.
Netzwerke: ingress mit'0. 0. 0. 0/0 'ist ohne zeitliche Ausnahme und TTL verboten.
Alerta: Es ist verboten, die Kritikalität von P1 ohne CAB zu reduzieren.

8) Kontrolle der Geheimnisse

Lagerung in Vault/KMS, kurze TTL, automatische Rotation.
Secret scanning in CI (Schlüsselmuster, high-entropy).
Isolierung von Geheimnissen nach Umgebungen/Rollen; erforderliche Mindestprivilegien.
Verschlüsselung „auf Draht“ und „in Ruhe“; geschlossene Audit-Protokolle für den Zugriff auf Geheimnisse.

9) Werkzeuge (variabel)

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.
Policy: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (drift detection, audit, RBAC).
Geheimnisse: HashiCorp Vault, Cloud KMS, Cert-Manager.
Scanner: trufflehog, gitleaks (Geheimnisse); OPA/Regula (Regeln).
Reporting: Export von Logs in DWH/BI, Verknüpfung mit Incident- und Change-System.

10) Beispiele für Regeln und Artefakte

JSON-Schema für die Konfiguration von Limits

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA (rego) - Verbot'0. 0. 0. 0/0` в ingress

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

Conftest/OPA - SoD

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL (DWH) - wer hat die Kritikalität von Warnmeldungen in einem Monat reduziert

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

Beispiel für Git-Befehlsmeldung (erforderliche Felder)

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11) Überwachung und Alerting

Drift-detect: config im Cluster ≠ Git → P1/P2 Signal + Auto-Remediation (reconcile).
Hochrisikoänderung: Netzwerke/Geheimnisse/Richtlinien ändern - Benachrichtigung in # security-ops.
Fehlende evidence: deploy ohne Plan/Unterschrift/Berichte - Block oder alert.
Expired assets: Gültigkeitsdauer von Zertifikaten/Schlüsseln → pro-aktive Alerts.

12) Metriken und KPIs

Audit Coverage% - Anteil der Config unter Schemas/Policies/Scannern.
Drift MTTR - durchschnittliche Zeit, um Drift zu beseitigen.
Policy Compliance% - Policy Pass auf PR.
Secrets Leak MTTR - vom Leck bis zum Rückruf/Rotation.
Backout Rate - Anteil der Config Change Rollbacks.
Mean Change Size - Durchschnitt diff nach Zeilen/Ressourcen (weniger ist besser).

13) Berichterstattung und Compliance

Auditspuren: Lagerung ≥ 1-3 Jahre (je nach Anforderung), unveränderliche Lagerung.
Regulatory: ISO 27001/27701, SOX-like SoD, DSGVO (PII), branchenspezifische Anforderungen (iGaming: Berücksichtigung von Änderungen der GGR/NGR-Berechnungen, Limits, Bonusregeln).
Monatsberichte: Top-Änderungen, Richtlinienverstöße, Drift, auslaufende Zertifikate, Status der Rotationen.

14) Playbooks

A. Drift im Produkt entdeckt

1. Auto-Deploy für den betroffenen Dienst sperren.
2. Entfernen Sie den Schnappschuss des aktuellen Zustands.
3. Vergleichen Sie mit Git, initiieren Sie' reconcile' oder Rollback.
4. P2 Incident erstellen, Driftquelle angeben (manuelles Kubectl/Konsole).
5. Schutz aktivieren: Direkte Änderungen verbieten (PSP/ABAC), Eigentümer benachrichtigen.

B. Abgelaufene PSP-Bescheinigung

1. Auf Backup-Pfad/PSP umschalten, Timeouts/Retrays herunterstufen.
2. Neues Zertifikat über PKI-Prozess freigeben, config über Git aktualisieren.
3. Smoke-Test, Verkehr zurückbringen, Vorfall schließen, Post-Mortem durchführen.

C. Das Geheimnis hat es in die PR geschafft

1. Schlüssel/Token zurückziehen, Rotation aktivieren.
2. Geschichte umschreiben/Artefakt aus Caches entfernen, RCA gestalten.
3. Regel zum geheimen Scanner hinzufügen, Befehl trainieren.

15) Anti-Muster

Manuelle Bearbeitungen „am Produkt“ ohne Spur oder Rollback.
Configs ohne Schaltungen und ohne Validierung.
Geheimnisse in Git/CI-Variablen ohne KMS/Vault.
Monorepo mit dem Äquivalent eines „globalen Superrechts“.
„Deaf“ GitOps ohne Drift-Alert und Anwendungsprotokolle.
Riesige Alles-auf-einmal-PRs sind eine unscharfe Zuschreibung und ein hohes Risiko.

16) Checklisten

Vor dem Merge

• Schema und Linter bestanden
• OPA/Conftest Politiker der Grünen
• Secret-scan - „sauber“
• Plan/Diff angebracht, Risiko bewertet, Backout bereit
• 2 apruvas (prod) und SoD eingehalten

Vor dem Deploy

• Veröffentlichungsfenster und Kalender überprüft
• Drift-Monitoring aktiv
• SLO-Gardrails sind eingerichtet, Smoke-Tests stehen bereit

Monatlich

• Schlüssel-/Zertifikatrotation nach Zeitplan
• Bestandsaufnahme der Eigentümer und Rechte
• Überprüfung der OPA-Regeln/Ausnahmen (TTL)
• Incident-Playbook-Test (Feuerbohrer)

17) Design-Tipps

Brechen Sie die Änderungen in kleine Diffs; Eine PR - ein Ziel.
Obligatorische PR/Commit-Vorlagen mit RFC/Risiko/Rollback.
Verwenden Sie für dynamische Config „Config Center“ mit Audit und Rollback.
Versionieren Sie die Schemata; Brechen ohne Migration verbieten.
Visualisieren Sie die „Karte der Config“: was, wo, von wem gesteuert.

18) Integrationen mit Change und Incident Management

PR ↔ RFC ↔ Veröffentlichungskalender ↔ Incidents/Post-Mortems.
Automatische Zuordnung von Metriken (SLO/Business) zu Config-Releases.
Automatische Erstellung von Aufgaben zum Löschen alter Flags/Ausnahmen (TTL).

19) Das Ergebnis

Konfigurationsaudits sind kein „Papierreporting“, sondern ein Betriebsmechanismus der Zuverlässigkeit: Configs sind Daten, Änderungen sind kontrollierbar und überprüfbar, Geheimnisse sind unter Verschluss, und die gesamte Geschichte ist transparent und überprüfbar. So entsteht eine nachhaltige, konforme und berechenbare Plattform.