Audit-Vorlage
infrastructure
Prüft, wie dein System gebaut, ausgeliefert und betrieben wird — und findet und behebt, was fragil, exponiert oder nicht wiederherstellbar ist.
Zugeordnet zu: CIS · Well-Architected · DORA
So funktioniert dieses Audit
Zwölf Spezialisten-Durchläufe decken IaC-Qualität und Drift, Cloud-Security und Netzwerk-Exposure, IAM, Secrets, Container, Kubernetes, CI/CD, High Availability, Backup/DR, Observability, Cost und Environment-Parität ab. Jeder Befund nennt ein konkretes Artefakt — eine IaC file:line, eine Manifest- oder Pipeline-Stanza, eine CIS- oder Well-Architected-Control. Die zentrale Frage lautet immer: Was passiert, wenn das ausfällt, und kannst du den Zustand wiederherstellen? Danach nehmen unabhängige Skeptiker jeden P0- und P1-Befund auseinander, bevor er es in den Bericht schafft.
Wann du es einsetzt
Vor einem Production-Launch
Du bringst einen Service ins öffentliche Internet und willst wissen, was tatsächlich exponiert ist. Das Audit verfolgt die Public-Exposure-Pfade — Security Groups, die auf 0.0.0.0/0 an sensiblen Ports offen stehen, öffentliche Buckets und Datenbanken, fehlendes TLS oder fehlender Edge-Schutz — und meldet jeden mit der exakten IaC-Zeile und der verletzten CIS-Control.
Nach einem Beinahe-Ausfall
Ein Incident hat dich fragen lassen, ob du wirklich aus Code und Backups neu aufbauen kannst. Das Audit prüft Single Points of Failure auf Tier-0-Pfaden und ob Backups verschlüsselt und restore-getestet sind — nicht bloss vorhanden — und legt die nicht wiederherstellbaren Zustände und fehlenden DR-Runbooks offen, bevor es der nächste Ausfall tut.
Deploy-Pipeline härten
Dein Team liefert schnell aus, und du vermutest, dass die Gates nur Deko sind. Das Audit prüft, ob Build-, Test-, Scan- und Approval-Schritte wirklich blockieren, kontrolliert die Branch Protection und den Scope der Pipeline-Credentials und markiert Injection-Pfade wie pull_request_target — und zeigt, wo ein kaputter oder ungescannter Build in der Prod landen kann.
Was du bekommst
Eine nach Dimensionen benotete Scorecard mit DORA-Snapshot, eine Blast-Radius-Map und ein nach Priorität sortiertes Backlog verifizierter Befunde — jeder als GitHub-Issue mit Beleg, Vorher/Nachher-Fix und Re-Audit-Kriterium.