Infrastructure as Code: Sicherheit von Anfang an mitdenken

Infrastructure as Code hat die Art verändert, wie wir Infrastruktur verwalten. Reproduzierbar, versioniert, auditierbar. Aber IaC löst nicht automatisch Sicherheitsprobleme — es verschiebt sie. Statt falsch konfigurierter Server haben wir jetzt falsch konfigurierte Terraform-Module. Der Unterschied: Ein fehlerhaftes Modul kann in Minuten hunderte falsch konfigurierte Server erzeugen.

Das Grundproblem

IaC-Tools sind mächtig. Terraform kann mit einem apply eine komplette Cloud-Infrastruktur hochfahren. Das ist der Vorteil — und das Risiko. Ein einziger fehlender Parameter kann eine Datenbank öffentlich zugänglich machen.

Häufige Fehlerquellen

1. Secrets im State

Terraform speichert den State im Klartext. Jedes Passwort, jeder API-Key, der als Variable übergeben wird, landet lesbar im State-File. Bei lokalem State ist das ein Dateisystem-Problem. Bei Remote State (S3, GCS) ein Zugriffskontroll-Problem.

# Schlecht: Secret im Output
output "db_password" {
  value = random_password.db.result
}

# Besser: Sensitive markieren
output "db_password" {
  value     = random_password.db.result
  sensitive = true
}

# Am besten: Secret direkt in Vault/SSM schreiben
resource "aws_ssm_parameter" "db_password" {
  name  = "/app/prod/db-password"
  type  = "SecureString"
  value = random_password.db.result
}

2. Zu breite IAM-Policies

Die häufigste Sicherheitslücke in Cloud-Infrastruktur sind überprivilegierte Rollen. Action: "*" auf Resource: "*" ist das Cloud-Äquivalent von chmod 777.

# Schlecht
resource "aws_iam_policy" "app" {
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = "*"
      Resource = "*"
    }]
  })
}

# Besser: Explizite Actions und Resources
resource "aws_iam_policy" "app" {
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = [
        "s3:GetObject",
        "s3:PutObject",
      ]
      Resource = "${aws_s3_bucket.data.arn}/*"
    }]
  })
}

3. Fehlende Verschlüsselung

Viele Cloud-Ressourcen sind standardmäßig unverschlüsselt. S3-Buckets, EBS-Volumes, RDS-Instanzen — ohne explizite Konfiguration liegen Daten im Klartext.

Security in die Pipeline integrieren

Statische Analyse von IaC-Code fängt Probleme ab, bevor sie die Cloud erreichen. Die Werkzeuge sind ausgereift:

security-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Trivy IaC Scan
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: config
        scan-ref: ./infrastructure
        severity: HIGH,CRITICAL
        exit-code: 1

    - name: Checkov
      uses: bridgecrewio/checkov-action@master
      with:
        directory: ./infrastructure
        framework: terraform
        soft_fail: false

Module als Sicherheitsgrenze

Gut geschnittene Terraform-Module sind die effektivste Maßnahme. Ein Modul, das eine RDS-Instanz erstellt, sollte Verschlüsselung und restriktive Security Groups erzwingen — nicht optional anbieten.

# modules/rds/main.tf
resource "aws_db_instance" "this" {
  # Erzwungen -- nicht konfigurierbar
  storage_encrypted      = true
  deletion_protection    = true
  publicly_accessible    = false
  skip_final_snapshot    = false

  # Konfigurierbar
  engine         = var.engine
  instance_class = var.instance_class
  # ...
}

Das Prinzip: Sichere Defaults, die schwer zu umgehen sind. Wer publicly_accessible = true braucht, muss das Modul forken — und das fällt im Code Review auf.

Fazit

IaC macht Infrastruktur programmierbar. Das bedeutet: Alle Werkzeuge, die wir für Code-Qualität haben — Reviews, Tests, statische Analyse, CI/CD — lassen sich auf Infrastruktur anwenden. Die Frage ist nicht, ob man das tun sollte. Die Frage ist, warum so viele Teams es noch nicht tun.