WAF-OPS-080 – Feature Flag & Safe Deployment Patterns
Beschreibung
Produktions-Deployments MÜSSEN Progressive-Delivery-Muster (Canary, Blue/Green, Feature Flags) verwenden, um den Blast Radius von fehlerhaften Deployments zu reduzieren. Rollback MUSS innerhalb von 5 Minuten ohne neues Deployment möglich sein. Neue Features mit signifikanter Nutzerauswirkung MÜSSEN hinter Feature Flags deployt werden.
Rationale
Big-Bang-Deployments – alle Änderungen auf alle Nutzer gleichzeitig – maximieren den Blast Radius jedes Fehlers. Progressive Delivery reduziert den Blast Radius: Eine fehlerhafte Canary-Version trifft 5% der Nutzer, nicht 100%. Feature Flags ermöglichen sofortigen Rollback in Sekunden ohne Deployment-Zyklus.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Voller Blast Radius |
Big-Bang-Deployment: fehlerhafter Release trifft 100% der Nutzer gleichzeitig. |
Langsamer Rollback |
Ohne Progressive Delivery erfordert Rollback einen neuen Deployment-Zyklus (10–20 Minuten). |
Nicht abbrechbare Launches |
Features ohne Flag können nicht sofort deaktiviert werden wenn negative Metriken auftreten. |
Irreversible Deployments |
Datenbankmigrationen ohne Canary machen Deployments praktisch unumkehrbar. |
Anforderung
-
Alle Production-Deployments MÜSSEN Canary, Blue/Green oder Feature Flags verwenden
-
Rollback MUSS in < 5 Minuten ohne neues Deployment möglich sein
-
Neue Features mit Nutzerauswirkung MÜSSEN hinter Feature Flags deployt werden
-
Auto-Rollback MUSS bei Fehlerrate-Anstieg konfiguriert sein (CodeDeploy Alarm, etc.)
Implementierungsanleitung
-
Deployment-Strategie wählen: Blue/Green für vollständige Umgebungswechsel; Canary für schrittweisen Traffic-Split
-
CodeDeploy konfigurieren:
CodeDeployDefault.ECSCanary10Percent5MinutesstattAllAtOnce -
Auto-Rollback-Alarms konfigurieren: CloudWatch Alarm der bei Fehlerrate-Anstieg Rollback auslöst
-
Feature-Flag-Service einrichten: AWS AppConfig, LaunchDarkly, Unleash, oder Flagsmith
-
Rollback-Prozedur testen: Regelmäßige Übung des Rollback-Prozesses (mindestens quartalsweise)
-
Flag-Lifecycle verwalten: Veraltete Feature Flags (> 90 Tage) regelmäßig entfernen
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Big-Bang Deployments |
Alle Änderungen gleichzeitig auf 100% der Nutzer. Rollback = neues Deployment. |
2 |
Basis-Deployment-Sicherheit |
Rolling Updates oder manuelle Blue/Green. Kein Auto-Rollback. |
3 |
Progressive Delivery |
Canary/Blue-Green mit Health-Check-basiertem Auto-Rollback. Feature Flags für neue Features. |
4 |
Automatische Canary-Analyse |
Metriken-Vergleich auto-entscheidet Promotion/Rollback. Change Failure Rate tracked. |
5 |
Experiment-Plattform |
DORA Elite: CFR < 5%. A/B-Testing-Infrastruktur. Deployment-Entscheidungen vollautomatisch. |
Terraform Checks
waf-ops-080.tf.aws.codedeploy-deployment-config
Prüft: AWS CodeDeploy Deployment Group nutzt Canary oder Linear, nicht AllAtOnce.
| Compliant | Non-Compliant |
|---|---|
|
|
waf-ops-080.tf.aws.appconfig-feature-flag
Prüft: AWS AppConfig Application für Feature-Flag-Management konfiguriert.
# Compliant
resource "aws_appconfig_application" "feature_flags" {
name = "payment-service-feature-flags"
description = "Feature flags for payment service"
}
resource "aws_appconfig_environment" "production" {
name = "production"
application_id = aws_appconfig_application.feature_flags.id
}
Remediation: deployment_config_name auf Canary- oder Linear-Strategie ändern.
auto_rollback_configuration mit enabled = true konfigurieren.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
IaC |
✅ Pflicht |
Load-Balancer oder Deployment-Konfiguration mit Progressive-Delivery-Pattern. |
Config |
✅ Pflicht |
Feature-Flag-Service-Konfiguration (AppConfig, LaunchDarkly, etc.). |
Process |
Optional |
Deployment-Runbook mit Canary-Promotion und Rollback-Entscheidungskriterien. |
Config |
Optional |
Auto-Rollback-Alarm-Konfiguration mit Schwellenwerten für Deployment-Abbruch. |
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 |