Die Checkliste lügt nicht, sie veraltet nur sofort

Du kennst das Ritual: vor dem Audit, vor dem Kunden-Review, vor dem Pentest füllst du eine Checkliste aus. Sind alle S3-Buckets privat? Hat jede Security Group noch offene Ports? Läuft überall Verschlüsselung? Du klickst dich durch die Konsole, trägst Haken ein, exportierst ein PDF. Das Ergebnis ist in dem Moment korrekt, in dem du es erzeugst. Fünf Minuten später klickt jemand in der Konsole eine neue Security Group zusammen, ein Kollege öffnet für einen Hotfix kurzzeitig Port 22 auf 0.0.0.0/0 und vergisst ihn wieder zu schließen, ein Skript legt per CLI einen neuen Bucket an. Deine Checkliste weiß davon nichts. Sie hat den Moment geprüft, nicht den Zustand.

AWS Config löst genau dieses Problem: Es bewertet nicht einen Zeitpunkt, sondern führt eine fortlaufende Historie jeder Ressourcenänderung in deinem Account, ausgewertet gegen Regeln, die du einmal definierst und die danach dauerhaft laufen.

Wo AWS Config ansetzt und wo nicht

Für dieses Thema lohnt sich eine Abgrenzung, weil die drei Mechanismen leicht verwechselt werden.

AWS Organizations Service Control Policies setzen präventiv auf IAM-Ebene an: Sie verhindern eine Aktion von vornherein, bevor sie überhaupt ausgeführt wird. Ein SCP-Deny lässt den API-Call gar nicht erst durch.

Policy as Code für Terraform mit OPA und Conftest prüft den IaC-Code vor dem apply, also den geplanten Zustand. Es sagt dir, ob dein Terraform-Plan gegen eine Regel verstößt, bevor überhaupt etwas in AWS entsteht.

AWS Config tut beides nicht. Es verhindert nichts und es prüft keinen Code. Es beobachtet den tatsächlichen Ist-Zustand deiner Ressourcen in der laufenden Infrastruktur, kontinuierlich, auch für Änderungen, die nie durch Terraform gelaufen sind: Console-Klicks, CLI-Befehle, manuelle Notfalländerungen. Genau diese Lücke lassen eine Checkliste und Policy as Code offen, weil beide nur an einem bestimmten Punkt im Lebenszyklus greifen.

Config Rules: AWS verwaltet oder selbst gebaut

AWS Config bewertet Ressourcen gegen Config Rules. Es gibt zwei Arten.

AWS verwaltete Regeln liefert AWS vorgefertigt. Die Regel s3-bucket-public-read-prohibited (Identifier S3_BUCKET_PUBLIC_READ_PROHIBITED) prüft Block-Public-Access-Einstellungen, Bucket-Policy und Bucket-ACL eines S3-Buckets und meldet den Bucket als NON_COMPLIANT, sobald öffentlicher Lesezugriff möglich ist. Die Regel restricted-ssh (Identifier INCOMING_SSH_DISABLED) prüft Security Groups: Ist eingehender SSH-Traffic auf etwas anderes als 0.0.0.0/0 oder ::/0 beschränkt, ist die Ressource konform, sonst nicht.

Eigene Regeln, Custom Rules, baust du dir selbst, wenn die verwalteten Regeln deinen Fall nicht abdecken. Dafür gibt es zwei Wege: Custom Lambda Rules, bei denen eine Lambda-Funktion in Java, Python oder Node.js die von AWS Config gesendete Konfiguration auswertet, und Custom Policy Rules, geschrieben in Guard (CloudFormation Guard), einer Policy-as-Code-Sprache, die ohne eigene Lambda-Funktion auskommt. Beide Regeltypen reagieren auf Konfigurationsänderungen und werten laufend neu aus, nicht nur einmal beim Anlegen.

Conformance Packs: Regeln bündeln und ausrollen

Eine einzelne Regel reicht selten. Ein Conformance Pack bündelt mehrere Config Rules und die dazugehörigen Remediation Actions zu einer Einheit, die sich in einem Account und einer Region oder organisationsweit über AWS Organizations ausrollen lässt. Du schreibst dafür eine YAML-Vorlage mit der Liste der AWS verwalteten oder eigenen Regeln samt Remediation-Verknüpfung und deployst sie über Konsole oder CLI, alternativ als SSM-Dokument hinterlegt. Für eine Umgebung mit mehreren Konten ist das der Unterschied zwischen „jedes Team pflegt seine eigene Checkliste“ und „eine Vorlage, ein Rollout, ein Compliance-Dashboard pro Pack“.

Die Konfigurationshistorie: der Teil, den keine Checkliste hat

Der eigentliche Kern von AWS Config ist die Configuration Timeline: Für jede überwachte Ressource hält AWS Config fest, wie sie konfiguriert war, wie sie zu anderen Ressourcen in Beziehung steht und wann sich das geändert hat. Du kannst damit rückwirkend beantworten, welche IAM-Policy ein Nutzer an einem bestimmten Tag hatte oder welche Security-Group-Regel zu einem bestimmten Zeitpunkt offen war, ohne dass du das vorher explizit protokolliert hast. Das ist der Unterschied zur Checkliste in einem Satz: Die Checkliste hat einen Zustand, AWS Config hat eine Geschichte.

Automatische Korrektur und die Sicht über mehrere Konten

AWS Config kann noch zwei Dinge, die über reine Erkennung hinausgehen. Für automatische Remediation verknüpfst du eine Regel mit einem SSM-Automation-Dokument, das bei NON_COMPLIANT eine Korrekturaktion ausführt, zum Beispiel einen offenen Port schließen. AWS liefert dafür vorgefertigte Automation-Dokumente, eigene lassen sich ebenso anbinden. Und über einen Aggregator holst du dir die Konfigurations- und Compliance-Daten mehrerer Accounts und Regionen in eine zentrale Sicht, statt dich durch jedes Konto einzeln zu klicken.

Nichts davon ersetzt die Guardrails aus SCP oder die Prüfung deines Terraform-Codes vor dem Apply. AWS Config ist die dritte Schicht: die, die merkt, wenn die Realität von beidem abweicht.

Hast du Fragen zu AWS Config in deiner Umgebung, melde dich unter mm@mhm-dl.de. Und wenn du zu DevOps, Cloud und Security regelmäßig etwas lesen willst, abonniere den Newsletter dieses Blogs, dann bekommst du neue Artikel direkt in dein Postfach.