Skip to content
NeuralSkills
Sicherheit

Secrets-Manager

Secrets, API-Keys und Zugangsdaten sicher verwalten — Umgebungsvariablen, Vaults, Rotationsstrategien und Leak-Praevention.

Einsteiger Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Secrets landen staendig an den falschen Stellen — hardcodierte API-Keys im Quellcode, Datenbankpasswoerter in Docker-Compose-Dateien, die ins Git eingecheckt werden, AWS-Credentials in .env-Dateien ohne Gitignore. Sobald ein Secret in der Versionshistorie liegt, ist es fuer immer kompromittiert, selbst wenn es im naechsten Commit geloescht wird. Geleakte Zugangsdaten sind die Hauptursache fuer Cloud-Sicherheitsverletzungen.

Der Prompt

Du bist ein Secrets-Management-Spezialist. Pruefe mein Projekt auf Credential-Exposition und entwirf eine sichere Secrets-Management-Strategie.

PROJEKTTYP: [z.B. Node.js-App, Docker-Deployment, CI/CD-Pipeline, Monorepo]
DEPLOYMENT: [z.B. Vercel, AWS, Docker, Netlify, Self-Hosted]
AKTUELLE SECRETS-SPEICHERUNG: [z.B. .env-Dateien, Hardcoded, Docker-Env, CI-Variablen]

AUFGABE 1 — AUDIT: Folgende Dateien auf exponierte Secrets scannen:
[.env, .env.example, docker-compose.yml, Konfigurationsdateien, CI/CD-Configs einfuegen]

Suchen nach:
- Hardcodierten API-Keys, Tokens, Passwoertern, Verbindungsstrings
- Secrets in eingecheckten Dateien (nicht in .gitignore)
- Secrets in Docker-Images oder Build-Logs
- Standard-Zugangsdaten, die nie geaendert wurden
- Zu weit gefasste API-Key-Berechtigungen

AUFGABE 2 — DESIGN: Secrets-Management-Strategie erstellen:
1. **Speicherung**: Wo jeder Secret-Typ liegen sollte (Env-Vars, Vault, CI-Secrets)
2. **Zugriff**: Least-Privilege-Zugriff pro Umgebung (Dev, Staging, Prod)
3. **Rotation**: Rotationsplan und automatisierte Rotation wo moeglich
4. **Erkennung**: Pre-Commit-Hooks und CI-Checks zur Leak-Erkennung
5. **.gitignore-Template**: Vollstaendiges Template fuer meinen Projekttyp
6. **.env.example**: Sicheres Template mit Platzhalterwerten

Implementierungsschritte fuer meine spezifische Deployment-Plattform bereitstellen.

Beispielausgabe

## Secrets-Audit: 3 Expositionen gefunden

### KRITISCH: Datenbankpasswort in docker-compose.yml (eingecheckt)
Zeile 12: POSTGRES_PASSWORD=prodpass123
Datei wird in Git getrackt. Passwort ist dauerhaft in der Versionshistorie.
Loesung: In .env (gitignored) verschieben, in Compose als ${POSTGRES_PASSWORD} referenzieren.

### Secrets-Management-Strategie:
| Secret-Typ | Dev | Staging | Produktion |
|------------|-----|---------|------------|
| DB-Passwort | .env.local | Vercel-Env-Vars | Vault + Rotation |
| API-Keys | .env.local | CI-Secrets | Vault + Scoped |
| JWT-Secret | .env.local | CI-Secrets | Vault + 90-Tage-Rotation |

Wann verwenden

Das Secrets-Audit zu Beginn jedes Projekts, nach dem Onboarding neuer Entwickler und vor dem Open-Sourcing eines Repositorys ausfuehren. Die Management-Strategie beim initialen Projekt-Setup entwerfen. Ueberpruefen bei neuen Drittanbieter-Integrationen, Deployment-Plattform-Wechseln oder nach Sicherheitsvorfaellen mit Credential-Exposition.

Profi-Tipps

  • Git-Historie scannen — git log -p | grep -i "password\|secret\|api_key" oder Tools wie truffleHog verwenden. Aus HEAD entfernen reicht nicht.
  • .env.local fuer echte Secrets nutzen — .env.example mit Platzhaltern committen und .env.local in .gitignore aufnehmen. Dieses Muster funktioniert in allen Frameworks.
  • Nach Exposition sofort rotieren — war ein Secret jemals in einem oeffentlichen Commit, innerhalb von Minuten rotieren, nicht Tagen. Bots scannen GitHub in Echtzeit.
  • API-Keys minimal einschraenken — nie einen Root-/Admin-API-Key verwenden, wenn ein Read-Only-Scoped-Key ausreichen wuerde. Separate Keys pro Dienst und Umgebung erstellen.