WAF-OPS-090 – Configuration Drift Detection & Remediation
Beschreibung
Alle Produktions-Infrastruktur MUSS kontinuierlich gegen ihre IaC-Definition verglichen werden. Configuration Drift – jede Abweichung zwischen tatsächlichem und deklariertem Zustand – MUSS automatisch erkannt, dem zuständigen Team gemeldet und innerhalb definierter SLAs behoben werden. Notfall-manuelle Änderungen MÜSSEN innerhalb von 24 Stunden in IaC überführt werden.
Rationale
In Umgebungen mit mehreren Änderungskanälen (Konsole, CLI, API, IaC) ist Drift unvermeidlich wenn nicht aktiv erkannt und behoben. Drift schafft unsichtbares Risiko: eine Sicherheitsgruppe die manuell geöffnet wurde, ein Parameter der Konsole-seitig geändert wurde. Drift ist die Lücke zwischen dem was man denkt zu haben und dem was man tatsächlich hat.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Stille Security-Verschlechterung |
Security-Group-Regeln manuell geöffnet für Debugging – bleibt offen; IaC weiß es nicht. |
Debugging-Änderungen permanent |
"Temporäre" Konsolen-Änderung wird vergessen und zur permanenten, nicht-dokumentierten Konfiguration. |
DR-Versagen |
Disaster-Recovery aus IaC scheitert weil tatsächliche Konfiguration von IaC abweicht. |
Audit-Versagen |
Infrastruktur entspricht nicht dem genehmigten Design; Compliance-Nachweis nicht möglich. |
Anforderung
-
Automatische Drift-Erkennung MUSS mindestens täglich laufen
-
Drift-Alerts MÜSSEN das zuständige Team innerhalb von 1 Stunde nach Erkennung benachrichtigen
-
Notfall-Konsolen-Änderungen MÜSSEN innerhalb von 24 Stunden in IaC überführt werden
-
Drift-SLAs MÜSSEN definiert sein: Kritisch (Security-related) 4h; Major 24h; Minor 1 Sprint
-
Drift-Log MUSS alle Events mit Zeitstempel, Ressource und Resolutionszeit dokumentieren
Implementierungsanleitung
-
Terraform Plan automatisieren: EventBridge Scheduler für täglichen
terraform planRun; Alert bei non-empty Plan -
AWS Config aktivieren: Configuration Recorder für alle Ressourcentypen; Compliance Rules konfigurieren
-
CloudTrail Multi-Region: Audit-Trail aller API-Calls inkl. Konsolen-Änderungen
-
Drift-SLAs definieren: Kritisch (Security-relevante Ressourcen) 4h; Major 24h; Minor 1 Sprint
-
Console-Schutz: Service Control Policies (SCP) für sensible Ressourcen; IAM Permission Boundaries
-
Notfall-Change-Prozess: Manuelle Änderung = Ticket erstellen + IaC-PR innerhalb 24h
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Keine Drift-Erkennung |
Kein Mechanismus um Drift zu erkennen. Konsolen-Änderungen sind Routine. |
2 |
Ad-hoc Identifikation |
|
3 |
Automatisierte Erkennung |
Täglicher automatischer Drift-Check. Alerts bei Erkennung. Notfall-Change-Prozess definiert. |
4 |
SLA-Enforcement |
Drift-SLAs definiert und getrackt. Log mit allen Events. Console-Schutz für sensible Ressourcen. |
5 |
Automatische Remediation |
Auto-Remediation für sichere Drift-Muster. 0 ungelöster Drift > 48h in Production. |
Terraform Checks
waf-ops-090.tf.aws.config-rule-enabled
Prüft: AWS Config Recorder mit Recording-Group ist konfiguriert.
| Compliant | Non-Compliant |
|---|---|
|
|
waf-ops-090.tf.aws.cloudtrail-enabled
Prüft: CloudTrail ist Multi-Region Trail mit Log-File-Validierung.
# Compliant
resource "aws_cloudtrail" "main" {
name = "production-trail"
s3_bucket_name = aws_s3_bucket.cloudtrail.id
is_multi_region_trail = true # Pflicht
enable_log_file_validation = true # Pflicht
include_global_service_events = true
}
Remediation: AWS Config Recorder mit all_supported = true aktivieren.
CloudTrail mit is_multi_region_trail = true und enable_log_file_validation = true konfigurieren.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
Config |
✅ Pflicht |
Automatische Drift-Detection-Konfiguration (EventBridge Schedule, AWS Config Recorder). |
Process |
✅ Pflicht |
Drift-SLA-Policy mit Schweregrad-Klassifikation und Remediation-Fristen. |
Governance |
Optional |
Drift-Log der letzten 90 Tage mit Erkennungszeit, Schweregrad und Resolutionszeit. |
IaC |
Optional |
SCP oder IAM-Permission-Boundary die Console-Änderungen an sensiblen Ressourcen verhindert. |
Regulatorisches Mapping
| Framework | Controls |
|---|---|
ISO/IEC 20000-1:2018 |
8.2.3 – Change management; 8.3.4 – Release management; 10.2.2 – Financial management |
ITIL 4 |
SVS – Service value system; DP – Design principle; OV – Operation value chain |
AWS Well-Architected Framework |
Operational Excellence Pillar – Prepare; Operational Excellence Pillar – Deploy |
DORA |
DORA 2024 – Technical practices; DORA 2024 – Organizational culture |
SOC 2 Type II |
CC4.1 – Monitoring activities; CC7.1 – Infrastructure and software monitoring |
Google SRE Book |
Chapter 2 – SRE: The role of an SRE; Chapter 3 – Service Level Objectives |
PCI DSS v4.0 |
Req 6.4 – Secure development lifecycle; Req 6.5 – Secure coding practices |
FinOps Foundation |
Core Module – Financial accountability; Management Layer – Cost governance |
BSI C5:2020 |
OPS-01 – Operational monitoring; OPS-02 – Operational control; OPS-03 – Operational capacity |
NIST SP 800-53 |
CM-1 – Configuration management policy; CM-2 – Configuration management |
NIST CSF 2.0 |
GV.PO – Policy; RC.RP – Recovery planning; DE.CM – Continuous monitoring |
TISAX |
Information security – Change management |
ANSSI SecNumCloud |
Domain – Change management |
BIO |
BIO – Veranderingenbeheer |
ENS High |
op.exp.6 – Gestión de cambios |
UK NCSC CAF |
A4 – Policy and assurance; A5 – Continual improvement |
CMMC 2.0 |
CM.L2-3.4.1 – Establish baseline configurations |
IRAP |
ISM – Change management |
CCCS PBMM |
CM-2 – Baseline configuration; CA-7 – Continuous monitoring |
MAS TRM |
Ch.3 – Technology risk governance; Ch.9 – Change management |
ISMAP |
Operational excellence and continuous improvement |
FISC |
Operational measures – Change management |