Sicherheits-Checkliste für Audits
Führen Sie diese Prüfungen an jedem System durch, bevor Sie es in die Produktion ausliefern oder nach größeren Änderungen.
Bevor Sie beginnen
Die Checkliste selbst ist in Prosa verfasst und benötigt nichts. Die drei Scanner unter scripts/ sind Python, daher benötigen Sie Python 3 auf Ihrem Rechner (python3 --version). Ohne Python können Sie die Checkliste trotzdem manuell abarbeiten; Sie erhalten dann nur keine automatischen Scans für Secrets, Header und IaC.
1. Datenschutz und Datenverwaltung
- Datenschutzerklärung vorhanden, wenn die App Benutzerdaten sammelt, speichert oder verarbeitet. Verlinken Sie sie in der Fußzeile und in den Anmeldeabläufen.
- Wissen, wo Benutzerdaten gespeichert werden: Dokumentieren Sie die primäre Datenbank, Caches, Logs, Backups und Drittanbieterdienste. Prüfen Sie die Anforderungen an den Datenaufenthaltsort (DSGVO, CCPA).
- Datenminimierung: Erfassen Sie nur, was Sie benötigen. Löschen oder anonymisieren Sie Daten, die Sie nicht verwenden.
2. Geheimnis- und Schlüsselhygiene
- .env-Werte werden nicht preisgegeben: Scannen Sie das gesamte Repository auf hartcodierte Geheimnisse.
- API-Schlüssel niemals im Frontend-Code offenlegen: keine Schlüssel in JS-Bundles, keine sensiblen Werte in öffentlichen Umgebungsvariablen-Präfixen (
REACT_APP_,NEXT_PUBLIC_,VITE_). - Schlüssel serverseitig oder hinter einem Proxy verschieben: Alle Drittanbieter-API-Aufrufe, die Geheimnisse erfordern, müssen über einen Backend-Endpunkt erfolgen.
- Geheimnisse aus Logs entfernen: Durchsuchen Sie Logs und Fehlerberichte mit grep nach Schlüsseln, Token und Passwörtern. Maskieren oder schwärzen Sie diese vor der Ausgabe.
- Kompromittierte Anmeldeinformationen sofort rotieren, wenn etwas gefunden wird.
Schnelle Scan-Befehle:
# Den integrierten Secret-Scanner ausführen
python3 scripts/scan_secrets.py .
# Manuelle ripgrep-Muster
grep -rE '(api[_-]?key|secret|token|password)\s*[:=]\s*["\047][a-zA-Z0-9_\-]{16,}' --include='*.{js,ts,py,go,rb,php,java,json,yaml,yml,env,sh,tf,hcl}' .
grep -rE 'AKIA[0-9A-Z]{16}' . # AWS-Keys
grep -rE 'ghp_[a-zA-Z0-9]{36}' . # GitHub-Token
grep -rE 'sk-[a-zA-Z0-9]{48}' . # OpenAI-Keys
3. Sicherheitsheader
-
Content-Security-Policyschränkt Skriptquellen ein und blockiert nach Möglichkeit die Inline-Ausführung. -
X-Frame-Optionsoderframe-ancestorsverhindert Clickjacking. -
Strict-Transport-Securityerzwingt HTTPS. -
X-Content-Type-Options: nosniffist vorhanden. -
Referrer-Policybegrenzt die Weitergabe von Referrern.
Header auf einer Live-URL prüfen:
python3 scripts/check_headers.py https://ihre-app.com
4. OWASP Top 10 Grundlagen
| # | Risiko | Was zu prüfen ist |
|---|---|---|
| A01 | Defekte Zugriffskontrolle | Jeder Endpunkt prüft Authentifizierung und Autorisierung. Keine IDOR-Fehler. |
| A02 | Kryptografische Fehler | Passwörter mit bcrypt/Argon2 gehasht. TLS 1.2+ erzwungen. Keine sensiblen Daten in URLs. |
| A03 | Injection | SQL verwendet parametrisierte Anweisungen. Keine rohe Zeichenkettenverkettung in Abfragen. |
| A04 | Unsicheres Design | Ratenbegrenzung bei Authentifizierung und sensiblen Aktionen. Geschäftslogik hat Missbrauchsprüfungen. |
| A05 | Sicherheitsfehlkonfiguration | Standard-Anmeldeinformationen entfernt. Debug-Modus in Produktion ausgeschaltet. Fehlermeldungen geben keine Stack-Traces preis. |
| A06 | Angreifbare Komponenten | Abhängigkeitsaudit: npm audit, pip-audit, cargo audit, snyk test. |
| A07 | Authentifizierungsfehler | Sitzungstoken sind zufällig und werden bei Berechtigungsänderungen rotiert. MFA für sensible Konten. |
| A08 | Datenintegrität | Lockfiles vorhanden, nach Möglichkeit signierte Commits. |
| A09 | Protokollierungsfehler | Sicherheitsereignisse werden ohne Geheimnisse protokolliert. |
| A10 | SSRF | Serverseitige Anfragen verwenden eine Whitelist. Keine benutzergesteuerten URLs, die interne Dienste erreichen. |
5. Eingabevalidierung und Injection
- SQL Injection: Alle Abfragen verwenden ORM-Parameter oder Prepared Statements.
- XSS: Benutzerausgabe wird HTML-escaped.
dangerouslySetInnerHTMLund ähnliche Umgehungen werden auditiert. - Command Injection: Kein
exec(),system()odereval()mit Benutzereingabe. - Path Traversal: Dateipfade werden bereinigt und auf ein Whitelist-Verzeichnis beschränkt.
- NoSQL Injection: MongoDB-Abfragen verwenden parametrisierte Objekte.
6. API-Sicherheit
- API-Antworten auf sensible Daten prüfen: keine internen IDs, Passwort-Hashes, Token oder unnötige PII.
- Authentifizierung an allen nicht-öffentlichen Endpunkten: keine offenen Admin- oder Debug-Routen.
- Ratenbegrenzung, bevor jemand Ihre API-Rechnung in die Höhe treibt: Pro-IP- und Pro-Benutzer-Ratenbegrenzung bei teuren oder authentifizierungsrelevanten Endpunkten. Rückgabe von
429mitRetry-After. - CORS ist restriktiv:
Access-Control-Allow-Originist nicht*. Preflight für zustandsändernde Methoden erforderlich.
7. Authentifizierung und Sitzung
- Passwortrichtlinie: mindestens 8 Zeichen, keine maximale Länge, die Passphrasen verhindert.
- Brute-Force-Schutz: exponentielle Verzögerung oder CAPTCHA nach fehlgeschlagenen Anmeldungen.
- Sitzungsverwaltung: sichere, httpOnly, SameSite-Cookies. JWTs haben kurze Ablaufzeiten und Refresh-Rotation.
- Passwortzurücksetzung: Token sind einmalig, zufällig und laufen schnell ab.
8. Sicherheit des Cloud-Anbieters
Gilt für AWS, GCP, Azure und jede andere Cloud-Plattform.
8.1 Identitäts- und Zugriffsverwaltung (IAM)
- Es existieren keine Root-Konto-Zugriffsschlüssel. Root-MFA ist aktiviert.
- Prinzip der geringsten Privilegien: Jede Rolle, jeder Benutzer und jedes Dienstkonto hat die minimal erforderlichen Berechtigungen. Keine Wildcard-Aktionen (
*) oder Ressourcen, es sei denn, dies ist unbedingt erforderlich. - Keine langlebigen Zugriffsschlüssel für Benutzer. Bevorzugen Sie IAM-Rollen mit temporären Anmeldeinformationen (STS, Instanzprofile, Workload Identity).
- MFA erzwungen für alle menschlichen Benutzer, insbesondere Administratoren und Abrechnungszugriff.
- Inaktive Identitäten entfernt: Löschen oder deaktivieren Sie seit 90+ Tagen ungenutzte Benutzer, Rollen und Dienstkonten.
- Kontenübergreifender Zugriff verwendet explizite Rollenannahmen mit externer ID, sofern zutreffend. Keine Vertrauensrichtlinien mit
Principal: *.
8.2 Speicher (S3 / GCS / Azure Blob)
- Keine öffentlichen Buckets/Container, es sei denn, es werden absichtlich öffentliche statische Assets gehostet. Blockieren Sie den öffentlichen Zugriff auf Kontenebene.
- Verschlüsselung im Ruhezustand aktiviert (AES-256 oder KMS). Keine unverschlüsselten Speichervolumes oder Snapshots.
- Verschlüsselung während der Übertragung erzwungen (HTTPS/TLS nur). Kein
httperlaubt. - Lebenszyklusrichtlinien löschen oder verschieben alte Daten. Versionierung für kritische Buckets aktiviert.
- Bucket-Richtlinien gewähren kein
Principal: *oderAllUsers. Zugriff erfolgt über IAM-Rollen, nicht über hartcodierte Schlüssel. - Protokollierung aktiviert für Zugriffslogs und Objektebene-Ereignisse (S3 Server Access Logs, CloudTrail-Datenereignisse).
8.3 Compute (EC2 / GCE / Azure VM / Lambda / Cloud Run)
- Keine Standard-Sicherheitsgruppen, die 0.0.0.0/0 auf sensiblen Ports zulassen (22, 3389, 3306, 5432, 6379, 27017).
- SSM / Session Manager wird nach Möglichkeit anstelle von direktem SSH verwendet. Kein Port 22 zum Internet hin geöffnet.
- IMDSv2 erforderlich auf AWS EC2 (IMDSv1 deaktivieren).
- Instanzmetadaten werden nicht für Container oder nicht vertrauenswürdigen Code freigegeben.
- Funktionslaufzeit verwendet minimale Privilegien. Lambda-/GCP-Cloud-Funktionen laufen nicht mit Admin-Rollen.
- Funktionsumgebungsvariablen enthalten keine Klartext-Geheimnisse. Verwenden Sie einen Secrets Manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).
8.4 Datenbank und Cache
- Kein öffentlicher Zugriff: Datenbanken befinden sich in privaten Subnetzen oder VPCs. Kein
0.0.0.0/0in Sicherheitsgruppen. - Verschlüsselung im Ruhezustand und während der Übertragung aktiviert.
- Automatisierte Backups mit Point-in-Time-Recovery.
- Starke Authentifizierung: keine Standard-Passwörter. Verwenden Sie IAM-Datenbank-Auth oder TLS-Client-Zertifikate, wo unterstützt.
- Audit-Protokollierung für Verbindungen und Schemaänderungen aktiviert.
8.5 Netzwerk
- VPC / Netzwerksegmentierung: Produktion, Staging und Entwicklung befinden sich in getrennten Netzwerken oder zumindest in getrennten Subnetzen.
- Sicherheitsgruppen / Firewalls sind standardmäßig verweigernd. Nur erforderliche Ports sind geöffnet.
- Keine übermäßig freizügigen CIDRs:
0.0.0.0/0wird vermieden, außer für HTTPS (443) auf öffentlich zugänglichen Load-Balancern. - Private Subnetze für Datenbanken, Caches und interne Dienste. NAT-Gateway oder VPC-Endpunkte für ausgehenden Internetzugriff.
- DDoS-Schutz aktiviert, wo anwendbar (AWS Shield, Cloud Armor, Azure DDoS Protection).
- DNS / Domain: DNSSEC aktiviert, wenn der Registrar dies unterstützt. Keine hängenden DNS-Einträge, die auf abgelaufene IPs oder gelöschte Ressourcen verweisen (Subdomain-Übernahmerisiko).
8.6 Protokollierung, Überwachung und Alerting
- CloudTrail / Audit Logs / Activity Logs für alle Regionen und Dienste aktiviert.
- Protokollintegrität: Protokolle sind unveränderlich oder werden in einem separaten Konto mit Write-Once-Berechtigungen gespeichert.
- Sensible Daten nicht protokolliert: Cloud-Protokolle enthalten keine Passwörter, Token oder PII.
- Alarme konfiguriert für Root-Anmeldung, IAM-Richtlinienänderungen, Erstellung öffentlicher Buckets, Sicherheitsgruppenänderungen und Spitzen fehlgeschlagener Authentifizierungen.
- Protokollaufbewahrung erfüllt Compliance-Anforderungen (in der Regel 1 Jahr).
9. Sicherheit von Containern und Orchestrierung
9.1 Docker / Container-Images
- Keine Geheimnisse in Images: Scannen Sie Dockerfiles und Layer auf
.env,config.jsonoder hartcodierte Anmeldeinformationen. - Minimale Basis-Images: Verwenden Sie nach Möglichkeit distroless, Alpine oder Scratch anstelle von vollständigem Ubuntu/Debian.
- Nicht als Root ausführen: Dockerfile setzt
USERauf eine Nicht-Root-UID/GID. - Image-Scanning: Aktivieren Sie die Schwachstellensuche in der Registry (ECR, GCR, ACR, Docker Hub) und blockieren Sie kritische CVEs in CI.
- Unveränderliche Tags: Verwenden Sie in der Produktion nicht
latest. Verwenden Sie Digests oder spezifische Semver. - Mehrstufige Builds: Build-Artefakte und Entwicklungsabhängigkeiten landen nicht im endgültigen Image.
9.2 Kubernetes
- RBAC: Rollen und Rollenbindungen mit geringsten Privilegien. Kein Cluster-Admin für Dienstkonten.
- Keine Standard-Dienstkontotoken in Pods eingebunden, die sie nicht benötigen (
automountServiceAccountToken: false). - Netzwerkrichtlinien: Standardmäßig eingehenden/ausgehenden Verkehr verweigern, dann explizit erforderlichen Verkehr zulassen.
- Pod-Sicherheitsstandards: Erzwingen Sie das Profil
restrictedoderbaseline. Keine privilegierten Container, kein hostPath, kein hostNetwork. - Geheimnisverschlüsselung: etcd-Verschlüsselung im Ruhezustand ist aktiviert. Keine Klartext-Geheimnisse in Git.
- Container-Laufzeitsicherheit: seccomp-, AppArmor- oder SELinux-Profile angewendet.
- Admission Controller: Verwenden Sie OPA/Gatekeeper oder Kyverno, um Richtlinien durchzusetzen (kein latest-Tag, erforderliche Labels, Ressourcengrenzen).
- Ressourcengrenzen: Jeder Pod hat CPU- und Speichergrenzen, um DoS durch Ressourcenerschöpfung zu verhindern.
10. Infrastructure as Code (IaC)
- Keine Geheimnisse in Terraform / CloudFormation / Pulumi / CDK: Zustandsdateien enthalten keine Klartext-Passwörter oder -Schlüssel. Remote-Zustand ist verschlüsselt und zugriffsgeschützt.
- Terraform-Zustandsbackend ist sicher: S3 mit SSE-KMS, DynamoDB-Sperre und kein öffentlicher Lesezugriff.
- IaC-Scanning: Führen Sie vor dem Merge
checkov,tfsecoderterrascanauf Terraform/CloudFormation aus. - Drift-Erkennung: Geplante Scans erkennen manuelle Konsolenänderungen, die von IaC abweichen.
- Module sind versionsfest: Ziehen Sie keine Module aus Branches oder unversionierten Quellen.
Schneller IaC-Scan:
python3 scripts/scan_iac.py .
# Oder verwenden Sie spezielle Tools, falls installiert:
checkov -d . --framework terraform,cloudformation,dockerfile
# tfsec .
11. CI/CD-Pipeline-Sicherheit
- Keine Geheimnisse in Pipeline-Konfigurationen: keine hartcodierten Token in
.github/workflows,.gitlab-ci.yml, Azure Pipelines oder Jenkinsfiles. - Geheimnisse werden injiziert aus dem nativen Secrets Manager der CI-Plattform (GitHub Secrets, GitLab CI Variables, Azure DevOps Library).
- Pipeline-Berechtigungen sind minimal: CI-Dienstkonten haben nur die für die Bereitstellung erforderlichen Berechtigungen.
- Branch-Schutz: Direkte Pushes zu main/master sind blockiert. Alle Änderungen erfordern PR/MR + Review.
- Signierte Commits oder Merge-Anforderungen: Für sensible Repos sind signierte Commits oder zumindest verifizierte Merge-Commits erforderlich.
- Abhängigkeitsscanning: SCA-Tools (Snyk, Dependabot, Renovate) werden in jedem PR ausgeführt.
- SAST: Statische Analyse (Semgrep, CodeQL, SonarQube) wird in jedem PR ausgeführt.
- Container-Scanning: Images werden vor der Bereitstellung auf CVEs gescannt.
- Keine selbstgehosteten Runner, die ohne VPN oder IP-Whitelist dem öffentlichen Internet ausgesetzt sind.
- Pipeline führt keinen nicht vertrauenswürdigen Code aus Forks ohne manuelle Genehmigung aus (Pwn Request verhindern).
12. Domain- und DNS-Sicherheit
- DNSSEC beim Registrar aktiviert, falls unterstützt.
- Keine hängenden CNAME / A / NS-Einträge, die auf abgelaufene Dienste verweisen (Subdomain-Übernahmerisiko).
- Wildcard-Zertifikate oder zertifikatsbezogene Zertifikate von einer vertrauenswürdigen CA. Keine selbstsignierten Zertifikate in der Produktion.
- Zertifikatablaufüberwachung: Warnungen 30 und 7 Tage vor Ablauf.
- CDN / WAF mit sinnvollen Regeln konfiguriert (SQLi, XSS, LFI-Blöcke). Ratenbegrenzung am Edge aktiviert.
Audit-Ergebnis
Erstellen Sie nach dem Durchlaufen der Checkliste einen prägnaten Markdown-Bericht mit:
- Zusammenfassung — Bestanden / Fehlgeschlagen / Überprüfung erforderlich pro Kategorie.
- Kritische Ergebnisse — Alles, was vor der Produktion behoben werden muss.
- Empfohlene Korrekturen — Bestimmte Code-Änderungen, Konfigurationsupdates oder Bibliotheks-Upgrades.
- Risikomatrix — Wahrscheinlichkeit × Auswirkung für jedes Ergebnis.
- Behebungszeitplan — Prioritätsreihenfolge und Fristen vorschlagen.