Secrets- und Konfigurationsverwaltung

Hardcodierte Secrets sind die leichte Beute bei Sicherheitsvorfällen. Ein API-Schlüssel in einer Konfigurationsdatei, ein Datenbankpasswort in einem Docker Compose, ein AWS-Zugriffsschlüssel in einem Testskript — diese werden eingecheckt, gepusht und vergessen. Dann forkt jemand das Repository, GitHub indiziert es, oder ein Laptop wird gestohlen. Jetzt ist Ihre Produktionsdatenbank das Spielfeld von jemand anderem.

Die Lösung ist nicht kompliziert: Keine Secrets im Code speichern, einen Secrets Manager verwenden, Zugangsdaten regelmäßig rotieren. Aber dorthin zu gelangen erfordert eine Bestandsaufnahme des Ist-Zustands, die richtigen Tools zu wählen und die Art und Weise zu ändern, wie Ihr Team mit Konfiguration umgeht. Dieses Kapitel führt Sie durch diesen Prozess.

Warum das für kleine Unternehmen wichtig ist

Kleine Teams überspringen die Secrets-Verwaltung oft, weil „wir kein Angriffsziel sind" oder „wir das später reparieren werden". Beide Annahmen sind falsch.

Die Angriffsfläche ist größer, als Sie denken. Ihre Codebasis berührt wahrscheinlich ein Dutzend Services: Datenbank, E-Mail-Anbieter, Zahlungs-Gateway, Analytics, Cloud-Speicher, Monitoring, CDN. Jede Integration hat Zugangsdaten. Das sind ein Dutzend Angriffsvektoren, wenn irgendein Zugangsdaten-Set exponiert wird.

Git vergisst nie. Ein Secret aus dem Code zu löschen entfernt es nicht aus der Historie. Jeder Commit ist dauerhaft. Wenn Sie vor sechs Monaten einen AWS-Schlüssel gepusht und ihn am nächsten Tag entfernt haben, ist er noch da. Automatisierte Scanner prüfen die Git-Historie, nicht nur aktuelle Dateien. Im Jahr 2024 hat GitHub 39 Millionen Secret-Leaks in öffentlichen Repositories entdeckt. Laut GitGuardians Bericht 2025 sind 70 % der im Jahr 2022 geleakten Secrets noch heute aktiv — Angreifer haben eine wachsende Angriffsfläche.

Kleine Teams bedeuten gemeinsamen Zugriff. Wenn fünf Personen Zugang zu Produktions-Zugangsdaten über geteilte .env-Dateien oder Slack-Nachrichten haben, wissen Sie nicht, wer was getan hat, wenn etwas schiefgeht. Und wenn jemand das Unternehmen verlässt, sollten Sie alles rotieren — aber niemand tut es.

Die Wiederherstellungskosten sind hoch. Für ein Startup kann ein einziger Vorfall mit geleakten Zugangsdaten bedeuten: tagelange Aufräumarbeiten — jeden exponierten Schlüssel rotieren, Zugriffsprotokolle prüfen, Kunden benachrichtigen, wenn auf Daten zugegriffen wurde. Das ist Zeit, die Sie nicht haben.

Reale Vorfälle

Das sind keine hypothetischen Szenarien — es sind dokumentierte Fälle.

Home Depot (2025). Home Depot ließ interne Systeme über ein Jahr lang gefährdet durch einen exponierten GitHub-Zugriffstoken eines Mitarbeiters. Der Token ermöglichte Zugriff auf Hunderte private Repositories mit kritischen Systemen — Cloud-Infrastruktur, Auftragsverwaltung, Inventar. Ein geleakter Zugangsdaten-Satz, über ein Jahr Exposition.

GitLab Massenexposition (2025). Sicherheitsingenieur Luke Marshall scannte 5,6 Millionen öffentliche GitLab-Repositories mit TruffleHog und fand 17.430 gültige Secrets — API-Schlüssel, Cloud-Zugangsdaten, Zugriffstoken. Diese betrafen über 2.800 einzigartige Domains. Die meisten Secrets waren zum Zeitpunkt der Entdeckung noch aktiv und ausnutzbar.

GhostAction Supply-Chain-Angriff (2025). Angreifer kompromittierten 327 GitHub-Konten und stahlen 3.325 Secrets aus CI/CD-Umgebungen über 817 Repositories. Die gestohlenen Daten enthielten PyPI-Token, npm-Token, DockerHub-Zugangsdaten, GitHub-Token und AWS-Zugriffsschlüssel. Eine kompromittierte Action verbreitete sich durch die gesamte Supply Chain.

Das 39-Millionen-Problem (2024). GitHubs eigene Daten zeigen, dass 39 Millionen Secrets im Jahr 2024 allein in öffentlichen Repositories geleakt wurden. Das ist kein Fehler — es ist ein Muster. Entwickler fügen Secrets „vorübergehend" hinzu, vergessen sie und pushen schließlich Code in öffentliche Repos.

Das Muster wiederholt sich ständig. Das Secret wird „nur für Tests" hinzugefügt, überlebt mehrere Refactorings und landet irgendwann irgendwo öffentlich. Automatisierte Scanner finden es in Minuten. Wenn Sie es bemerken, ist der Schaden angerichtet.

Was als Secret gilt

Alles, was Zugang zu einem System oder Service gewährt:

Kategorie	Beispiele
Passwörter	Datenbankzugangsdaten, Admin-Konten, Service-Passwörter
API-Schlüssel und Token	Stripe, Twilio, SendGrid, GitHub/GitLab-Token, OAuth-Secrets
Kryptografisches Material	Private Schlüssel, TLS-Zertifikate, SSH-Schlüssel, JWT-Signing-Keys
Verbindungszeichenketten	Datenbank-URLs mit eingebetteten Zugangsdaten, Message-Broker-URIs
Cloud-Zugangsdaten	AWS-Zugriffsschlüssel, GCP-Service-Account-JSON, Azure-Verbindungszeichenketten

Wenn Sie nicht sicher sind, ob etwas ein Secret ist: Wenn es Ihnen ermöglicht, sich zu authentifizieren oder auf Daten zuzugreifen, ist es ein Secret.

Wo Secrets enden (und nicht enden sollten)

Quellcode

Der offensichtlichste Ort. Entwickler hardcoden Werte während des Prototypings und vergessen, sie zu entfernen:

# BAD: This gets committed, pushed, and indexed
db = connect(
    host="db.internal",
    password="Pr0d_P@ssw0rd_2024!"  # TODO: fix this
)

Konfigurationsdateien

Weniger offensichtlich, aber gleichermaßen gefährlich:

# BAD: docker-compose.yml in version control
services:
  api:
    environment:
      - STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc

// BAD: config.js with real credentials
module.exports = {
  database: {
    password: process.env.DB_PASS || "fallback_password_123"
  }
};

Dieser „Fallback" ist jetzt für immer in Ihrer Codebasis.

Git-Historie

Sie haben das Secret entfernt, aber:

$ git log -p --all -S "sk_live_" | head -20
commit a1b2c3d4...
-      STRIPE_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc

Jeder mit Repository-Zugriff kann es finden.

CI/CD-Protokolle

Build-Protokolle geben oft Umgebungsvariablen oder Befehlsausgaben aus:

$ ./deploy.sh
Connecting to database with password: Pr0d_P@ssw0rd_2024!
Deployment complete.

Lokale Dateien

.env-Dateien, die Entwickler über Slack, Notion oder E-Mail teilen. Kein Prüfpfad, keine Zugriffskontrolle, und sie verbreiten sich über Laptops.

Clientseitiger Code

Secrets in JavaScript-Bundles, mobilen App-Binaries oder Frontend-Konfigurationen. Das sind keine Secrets mehr — sie sind öffentlich.

Häufige Fehler

Bevor wir zu Lösungen kommen, hier die Muster, die Teams in Schwierigkeiten bringen. Sie werden einige davon wiedererkennen.

Secrets in „Beispiel"-Dateien

# .env.example — committed to repo
DATABASE_URL=postgres://user:REAL_PASSWORD@host/db

„Beispiel"-Dateien mit echten Werten sind dennoch Leaks. Verwenden Sie offensichtlich gefälschte Werte:

# .env.example — safe
DATABASE_URL=postgres://user:CHANGE_ME@localhost/db

Secrets protokollieren

# BAD
logger.info(f"Connecting with password: {password}")

# BAD
logger.debug(f"Request headers: {request.headers}")  # Might include auth tokens

Niemals Zugangsdaten protokollieren. Sensible Felder vor dem Protokollieren filtern.

Secrets in Fehlermeldungen

# BAD
raise ConnectionError(f"Failed to connect to {host} with password {password}")

# GOOD
raise ConnectionError(f"Failed to connect to {host}")

Clientseitigem Speicher vertrauen

API-Schlüssel in Frontend-JavaScript, mobilen App-Konfigurationen oder Electron-Apps sind keine Secrets. Sie sind öffentlich. Wenn Sie eine API schützen müssen, verwenden Sie einen Backend-Proxy.

Über Slack/E-Mail teilen

„Hey, kannst du mir das Produktions-DB-Passwort schicken?" → Passwort in Slack → für immer durchsuchbar → kein Prüfpfad → keine Widerrufmöglichkeit.

Verwenden Sie den Secrets Manager. Teilen Sie Zugriff, nicht Zugangsdaten.

Rotation nach dem Offboarding überspringen

Mitarbeiter verlässt das Unternehmen → sein Laptop hatte Zugriff auf .env-Dateien → diese Secrets sind jetzt unkontrolliert. Zugangsdaten rotieren, wenn Personen das Unternehmen verlassen, insbesondere privilegierte Konten.

Fehlende .gitignore-Muster

Wenn Sie Secret-Dateien nicht explizit ignorieren, wird sie jemand früher oder später einchecken. Fügen Sie das zu jedem Repository hinzu:

# Environment files
.env
.env.*
!.env.example

# Secret/credential files
*.pem
*.key
*.p12
*.pfx
secrets.yml
secrets.yaml
credentials.json
*-credentials.json
service-account*.json

# IDE and tool configs that might contain secrets
.idea/**/dataSources/
.idea/**/dataSources.xml

# Terraform state (contains secrets in plain text)
*.tfstate
*.tfstate.*
.terraform/

Der Ansatz zur Secrets-Verwaltung

Prinzipien

1. Secrets berühren nie die Versionskontrolle. Nicht im Code, nicht in Konfigurationsdateien, nicht in „Beispiel"-Dateien mit echten Werten.

2. Einzige Quelle der Wahrheit. Ein System speichert Zugangsdaten. Alles andere bezieht sie zur Laufzeit daraus.

3. Least-Privilege-Zugriff. Deployment-Skripte erhalten Produktions-Secrets. Entwickler-Laptops erhalten Entwicklungs-Secrets. Niemand bekommt alles.

4. Alles auditieren. Wissen, wer wann auf was zugegriffen hat.

5. Regelmäßig rotieren. Ob geleakt oder nicht — Zugangsdaten sollten nach einem Zeitplan gewechselt werden.

Tool-Kategorien

Typ	Beispiele	Am besten für
Dedizierte Secrets Manager	Passwork, HashiCorp Vault, AWS Secrets Manager	Infrastruktur und CI/CD-Automatisierung
Cloud-native Lösungen	Passwork Cloud, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault	Einzelne Cloud- und Hybrid-Umgebungen
Umgebungsvariablen-Plattformen	Doppler, Infisical	Entwicklerfokussierte Workflows
Passwortmanager	Passwork (deckt sowohl Menschen als auch Automatisierung ab)	Menschliche Zugangsdaten + Infrastruktur-Secrets in einem Tool

Wir empfehlen Passwork — einen Business-Passwort- und Secrets-Manager, der beide Seiten des Problems in einem einzigen Tool abdeckt.

Die meisten Teams pflegen zwei separate Systeme: einen Passwortmanager für Personen und einen Secrets-Tresor für Infrastruktur. Passwork eliminiert diese Aufteilung. Es verwaltet menschliche Zugangsdaten (mit geteilten Tresoren, rollenbasiertem Zugriff und Audit-Protokollen) zusammen mit Infrastruktur-Secrets (über API, CLI und SDKs für Automatisierung). Ein Tool, ein Prüfpfad, eine Zugriffsrichtlinie.

Deployment-Optionen. Passwork ist als On-Premise-Lösung erhältlich — auf Ihren eigenen Servern installiert, Daten verlassen niemals Ihre Infrastruktur — und als Cloud-Version. Beide verwenden dieselbe Zero-Knowledge-Architektur: Die gesamte Verschlüsselung erfolgt clientseitig, sodass selbst Passwork keinen Zugriff auf Ihre Secrets hat.

Für Teams jeder Größe gebaut. Passwork skaliert von kleinen Startups bis zu Enterprise-Deployments mit 30.000+ Benutzern. Es ist ISO 27001 zertifiziert, unabhängig von HackerOne getestet und wird von Regierungsbehörden und regulierten Organisationen in ganz Europa vertraut. Der Standardplan beginnt bei 3 €/Benutzer/Monat.

Passwork als Secrets Manager

Passwork bietet die Funktionen, die Sie für die Infrastruktur-Secret-Verwaltung benötigen:

Zero-Knowledge-Verschlüsselung. Alle Ver- und Entschlüsselung erfolgt clientseitig — im Browser, in der CLI oder im SDK. Der Server speichert nur verschlüsselte Daten. Selbst wenn jemand den Server kompromittiert, erhält er verschlüsselte Blöcke, keine Secrets.

API-First-Design. Alles, was Sie in der UI tun können, ist über die HTTP-API verfügbar. CI/CD-Pipelines, Deployment-Skripte und benutzerdefinierte Automatisierung verwenden alle dieselbe Schnittstelle.

CLI für DevOps. Das passwork-cli-Tool bewältigt die häufigsten Szenarien: Secrets als Umgebungsvariablen abrufen, bevor ein Befehl ausgeführt wird, einzelne Werte für Skripte abrufen und Zugangsdaten nach der Rotation aktualisieren.

Python-SDK für komplexe Automatisierung. Wenn CLI nicht ausreicht — Bulk-Migrationen, Integritätsprüfungen, Rotation mit Fehlerbehandlung — gibt das SDK vollständigen programmatischen Zugriff.

Passwork für Infrastruktur einrichten

1. Einen dedizierten Tresor erstellen.

Trennen Sie Infrastruktur-Secrets von Mitarbeiterpasswörtern. Erstellen Sie einen Tresor namens infrastructure oder devops.

2. Nach Umgebung und Kategorie organisieren.

infrastructure/
├── production/
│   ├── databases/
│   │   ├── mysql-primary
│   │   └── postgresql-orders
│   ├── cloud/
│   │   └── aws-credentials
│   └── services/
│       ├── stripe-api
│       └── sendgrid-api
├── staging/
│   └── ...
└── development/
    └── ...

Diese Struktur ermöglicht es, CI/CD-Zugriff auf bestimmte Ordner zu gewähren. Das Produktions-Deployment erhält infrastructure/production, Staging erhält infrastructure/staging, Entwickler erhalten infrastructure/development.

3. Benutzerdefinierte Felder für benannte Secrets verwenden.

Statt alles in das Passwortfeld zu packen, verwenden Sie benutzerdefinierte Felder mit beschreibenden Namen:

Feld	Wert
MYSQL_HOST	mysql.prod.internal
MYSQL_USER	backend_svc
MYSQL_PASSWORD	xK9#mP2$vL7!nQ

Das entspricht direkt den Umgebungsvariablen bei Verwendung der CLI.

4. Service-Konten erstellen.

Für Automatisierung dedizierte Benutzer statt persönlicher Konten erstellen:

Konto	Zweck	Zugriff
deploy-prod-svc	Produktions-Deployment	Nur Lesen auf infrastructure/production
deploy-staging-svc	Staging-Deployment	Nur Lesen auf infrastructure/staging
cred-rotator	Secret-Rotation	Lesen/Schreiben auf alle Umgebungen

Service-Konten bieten:

• Klaren Prüfpfad (Sie sehen, was Automatisierung vs. Menschen getan haben)
• Personalunabhängigkeit (Personen die das Unternehmen verlassen, brechen CI/CD nicht)
• Granulare Zugriffskontrolle (Produktions-Deployment kann keine Secrets ändern)

passwork-cli in CI/CD verwenden

Installation via pip:

pip install passwork-python

Oder das Docker-Image direkt in Pipelines verwenden:

docker run --rm \
  -e PASSWORK_HOST="https://passwork.your-company.com" \
  -e PASSWORK_TOKEN="$PASSWORK_TOKEN" \
  -e PASSWORK_MASTER_KEY="$PASSWORK_MASTER_KEY" \
  passwork/passwork-cli exec --folder-id "$SECRETS_FOLDER_ID" ./deploy.sh

GitLab-CI-Beispiel:

deploy_production:
  stage: deploy
  image: passwork/passwork-cli:latest
  variables:
    PASSWORK_HOST: $PASSWORK_HOST
    PASSWORK_TOKEN: $PASSWORK_TOKEN
    PASSWORK_MASTER_KEY: $PASSWORK_MASTER_KEY
  script:
    - passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" ./deploy.sh
  environment:
    name: production
  when: manual

GitHub-Actions-Beispiel:

- name: Deploy with secrets
  run: |
    docker run --rm \
      -e PASSWORK_HOST="${{ secrets.PASSWORK_HOST }}" \
      -e PASSWORK_TOKEN="${{ secrets.PASSWORK_TOKEN }}" \
      -e PASSWORK_MASTER_KEY="${{ secrets.PASSWORK_MASTER_KEY }}" \
      -v ${{ github.workspace }}:/app \
      -w /app \
      passwork/passwork-cli:latest \
      exec --folder-id "${{ vars.SECRETS_FOLDER_ID }}" ./deploy.sh

Der exec-Modus ruft alle Secrets aus dem angegebenen Ordner ab, konvertiert sie in Umgebungsvariablen und führt Ihren Befehl aus. Secrets existieren nur für die Dauer dieses Prozesses.

Secrets in Skripten abrufen

Für einzelne Werte in Bash:

# Get the database password
DB_PASS=$(passwork-cli get --password-id "<item-id>")

# Get a specific custom field
STRIPE_KEY=$(passwork-cli get --password-id "<item-id>" --field STRIPE_SECRET)

# Get a TOTP code
MFA_CODE=$(passwork-cli get --password-id "<item-id>" --totp)

Docker Compose mit Secrets

Für lokale Entwicklungs- und Staging-Umgebungen Secrets via exec injizieren:

# Start containers with secrets from Passwork
passwork-cli exec --folder-id "<folder-id>" docker compose up -d

In Ihrer docker-compose.yml Umgebungsvariablen referenzieren, ohne Werte zu hardcoden:

services:
  api:
    image: backend:latest
    environment:
      - MYSQL_HOST=${MYSQL_HOST}
      - MYSQL_USER=${MYSQL_USER}
      - MYSQL_PASSWORD=${MYSQL_PASSWORD}
      - STRIPE_SECRET_KEY=${STRIPE_SECRET_KEY}
  
  worker:
    image: worker:latest
    environment:
      - REDIS_URL=${REDIS_URL}
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}

Passworks exec-Modus setzt diese Variablen vor dem Start von Docker Compose, sodass Secrets nie auf die Festplatte gelangen.

Notfallzugriffsverfahren

Was passiert, wenn die einzige Person mit Passwork-Admin-Zugriff im Urlaub ist und Sie ein kompromittiertes Zugangsdaten-Set rotieren müssen?

Planen Sie dafür:

1. Mehrere Administratoren. Mindestens zwei Personen sollten Admin-Zugriff auf den Infrastruktur-Tresor haben. Dokumentieren Sie, wer das ist.

2. Break-Glass-Konto. Erstellen Sie ein dediziertes Notfall-Admin-Konto mit Zugangsdaten, die sicher offline gespeichert werden (ausgedruckt, in einem physischen Safe oder beim Rechtsberater Ihres Unternehmens). Quartalsweise testen.

3. Dokumentierter Wiederherstellungsprozess. Schreiben Sie genau auf, wie man:

• Auf das Break-Glass-Konto zugreift
• Kompromittierte Zugangsdaten rotiert
• Das Team über das Geschehene informiert

4. Backup-Export. Exportieren Sie regelmäßig verschlüsselte Backups kritischer Secrets. Bewahren Sie sie getrennt von Passwork mit klaren Entschlüsselungsanweisungen auf.

Das ist keine Paranoia — das ist Geschäftskontinuität. Ein einziger Ausfallpunkt beim Secret-Zugriff kann Ihren gesamten Betrieb zum Stillstand bringen.

Repositories auf Secrets auditieren

Bevor Sie zu einem Secrets Manager migrieren, müssen Sie wissen, was bereits exponiert ist.

Tools

git-secrets — AWS-Tool, das das Einchecken von Secrets verhindert und bestehende Historie scannt:

# Install
brew install git-secrets

# Register common patterns (AWS keys)
git secrets --register-aws

# Scan current repo
git secrets --scan

# Scan commit history
git secrets --scan-history

# Install as pre-commit hook
git secrets --install

truffleHog — Tief-Scanner, der Entropie und Muster über alle Branches und die Historie prüft:

# Install
pip install trufflehog

# Scan local repository
trufflehog git file://. --only-verified

# Scan with unverified matches too
trufflehog git file://.

gitleaks — Schnell und konfigurierbar, beliebt in CI/CD:

# Install
brew install gitleaks

# Scan current state
gitleaks detect --source .

# Scan with verbose output
gitleaks detect --source . --verbose

# Scan as pre-commit
gitleaks protect --source . --staged

Was mit Befunden zu tun ist

Sofort: Wenn Sie aktive Zugangsdaten finden (aktuelle API-Schlüssel, Produktionspasswörter), rotieren Sie diese jetzt. Warten Sie nicht, bis Sie das Audit abgeschlossen haben.

Historie bereinigen: Für exponierte Zugangsdaten ist das Umschreiben der Git-Historie eine Option, aber komplex. Normalerweise ist es einfacher, die Zugangsdaten zu rotieren und die Historie in Ruhe zu lassen. Wenn Sie die Historie bereinigen müssen:

# Use BFG Repo-Cleaner (faster than git filter-branch)
bfg --replace-text secrets.txt repo.git

Wiederholung verhindern: Pre-Commit-Hooks installieren, die Commits mit Secrets blockieren.

Pre-Commit-Hook-Setup

Mit dem pre-commit-Framework und gitleaks:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Installieren:

pip install pre-commit
pre-commit install

Commits mit erkannten Secrets werden jetzt blockiert.

Secret-Rotation

Rotation ist nicht nur nach Datenpannen nötig. Regelmäßige Rotation begrenzt das Schadensfenster, wenn Zugangsdaten ohne Ihr Wissen exponiert wurden.

Rotations-Workflow

1. Neues Zugangsdaten-Set generieren
      ↓
2. Zielsystem aktualisieren (Datenbank, Service)
      ↓
3. Neue Zugangsdaten in Passwork speichern
      ↓
4. Verifizieren, dass alles funktioniert
      ↓
5. (Optional) Alte Zugangsdaten invalidieren

Kritisch: Das Zielsystem vor der Speicherung in Passwork aktualisieren. Andernfalls gibt es einen Widerspruch — Passwork hält den neuen Wert, während das System noch den alten erwartet.

Rotation mit passwork-cli

PostgreSQL-Passwortrotation:

#!/bin/bash
set -e

ITEM_ID="<passwork-item-id>"
DB_USER="backend_svc"

# 1. Generate new password
NEW_PASS=$(openssl rand -base64 32)

# 2. Apply to PostgreSQL
psql -h pg.prod.internal -U postgres -c \
  "ALTER ROLE ${DB_USER} WITH PASSWORD '${NEW_PASS}';"

# 3. Store in Passwork
passwork-cli update --password-id "${ITEM_ID}" --password "${NEW_PASS}"

echo "Password rotated for ${DB_USER}"

MySQL-Passwortrotation:

#!/bin/bash
set -e

ITEM_ID="<passwork-item-id>"
DB_USER="order_service"

NEW_PASS=$(openssl rand -base64 32)

mysql -h mysql.prod.internal -u root -p"${MYSQL_ROOT_PASSWORD}" -e \
  "ALTER USER '${DB_USER}'@'%' IDENTIFIED BY '${NEW_PASS}';"

passwork-cli update --password-id "${ITEM_ID}" --password "${NEW_PASS}"

echo "Password rotated for ${DB_USER}"

Rotationsplan

Secret-Typ	Empfohlene Häufigkeit
Produktionsdatenbankpasswörter	30–90 Tage
Externe API-Schlüssel	90 Tage oder gemäß Anbieterrichtlinie
Service-Token	7–30 Tage
SSH-Schlüssel	6–12 Monate

Mit Cron automatisieren:

# /etc/cron.d/passwork-rotation
# Every Sunday at 3 AM
0 3 * * 0 deploy /opt/scripts/rotate-db-passwords.sh >> /var/log/rotation.log 2>&1

Secrets aus Code zu Passwork migrieren

Schritt 1: Bestandsaufnahme

Alle Secrets in Ihrer Codebasis und Ihrem Deployment auflisten:

Secret	Aktueller Ort	Zielsystem	Passwork-Pfad
MySQL-Prod-Passwort	.env.production	mysql.prod	infrastructure/production/databases/mysql-primary
Stripe-API-Schlüssel	config/secrets.yml	Stripe API	infrastructure/production/services/stripe-api
AWS-Zugriffsschlüssel	CI/CD-Variablen	AWS	infrastructure/production/cloud/aws-credentials

Schritt 2: Struktur in Passwork erstellen

Ordner entsprechend Ihrer Umgebungs-/Kategoriestruktur einrichten. Einträge mit beschreibenden Namen und passenden benutzerdefinierten Feldern erstellen.

Schritt 3: Anwendungen aktualisieren

Hardcodierte Werte durch Umgebungsvariablen-Abfragen ersetzen:

# Before
stripe.api_key = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"

# After
import os
stripe.api_key = os.environ["STRIPE_SECRET_KEY"]

Das folgt dem 12-Factor-App-Prinzip: Konfiguration in der Umgebung speichern. Ihre Anwendung sollte:

1. Niemals Secrets im Code enthalten. Nicht in Quelldateien, nicht in Konfigurationsdateien, die eingecheckt werden.

2. Secrets aus Umgebungsvariablen lesen. Das ist die Standardschnittstelle, die überall funktioniert — Container, VMs, Serverless, lokale Entwicklung.

3. Schnell scheitern, wenn Secrets fehlen. Keine stillen Defaults verwenden. Wenn DATABASE_URL nicht gesetzt ist, sofort mit einer klaren Fehlermeldung abbrechen:

import os
import sys

required_vars = ["DATABASE_URL", "STRIPE_SECRET_KEY", "JWT_SECRET"]
missing = [var for var in required_vars if not os.environ.get(var)]

if missing:
    print(f"Missing required environment variables: {', '.join(missing)}")
    sys.exit(1)

4. Secrets niemals protokollieren oder exponieren. Nicht in Fehlermeldungen, nicht in Debug-Ausgaben, nicht in Stack Traces.

Dieser Ansatz funktioniert unabhängig davon, woher Secrets kommen — Passwork, ein anderer Tresor oder CI/CD-Variablen. Ihre Anwendung kümmert sich nicht um die Quelle; sie liest einfach Umgebungsvariablen.

Schritt 4: CI/CD aktualisieren

Pipelines so anpassen, dass Secrets vor dem Deployment aus Passwork bezogen werden:

# Before
script:
  - export STRIPE_KEY=$STRIPE_KEY_CICD_VAR
  - ./deploy.sh

# After
script:
  - passwork-cli exec --folder-id "$SECRETS_FOLDER_ID" ./deploy.sh

Schritt 5: Aufräumen

• Secrets aus CI/CD-Variablen entfernen (nur Passwork-Verbindungszugangsdaten behalten)
• .env-Dateien mit Produktions-Zugangsdaten löschen
• Secrets aus Konfigurationsdateien entfernen
• Secret-Scanner ausführen, um zu verifizieren, dass nichts übrig bleibt

.env-Dateien via Python-SDK importieren

Für Bulk-Migration:

import os
from pathlib import Path
from passwork import Client

def migrate_env_file(env_path: str, folder_id: str, tags: list):
    """Import secrets from a .env file into Passwork."""
    
    client = Client(
        url=os.environ["PASSWORK_HOST"],
        token=os.environ["PASSWORK_TOKEN"],
    )
    
    env_file = Path(env_path)
    secrets_dict = {}
    
    for line in env_file.read_text().splitlines():
        line = line.strip()
        if not line or line.startswith("#"):
            continue
        if "=" in line:
            key, value = line.split("=", 1)
            secrets_dict[key.strip()] = value.strip().strip('"\'')
    
    client.create_password(
        folder_id=folder_id,
        title=env_file.stem,
        fields=secrets_dict,
        tags=tags,
    )
    
    print(f"Imported {len(secrets_dict)} secrets from {env_path}")

# Usage
migrate_env_file(
    env_path="./legacy/.env.production",
    folder_id="<infrastructure-production-folder-id>",
    tags=["production", "imported"],
)

Workshop: Auditieren und migrieren

Blocken Sie 2–3 Stunden für diese Übung.

Teil 1: Secret-Scanning (30 Minuten)

1. Einen Scanner installieren:

pip install trufflehog
# or
brew install gitleaks

2. Ihre Hauptrepositories scannen:

trufflehog git file://./your-repo --only-verified
# or
gitleaks detect --source ./your-repo --verbose

3. Befunde dokumentieren:

Repository	Datei/Commit	Secret-Typ	Status
backend	.env.prod (gelöscht in abc123)	DB-Passwort	Muss rotiert werden
frontend	config.js Zeile 42	API-Schlüssel (Test)	Falsch-Positiv

4. Alle aktiven Produktions-Zugangsdaten sofort rotieren.

Ergebnis: Scan-Bericht mit Behebungsstatus

Teil 2: Bestehende Secrets inventarisieren (30 Minuten)

Eine Tabelle aller Secrets in Ihrer Infrastruktur erstellen:

Secret-Name	Aktueller Ort	Umgebung	Eigentümer	Zuletzt rotiert	Passwork-Pfad (geplant)
MySQL root	CI/CD-Variablen	Produktion	DevOps	Unbekannt	infra/prod/databases/mysql-primary
Stripe-Schlüssel	.env.prod	Produktion	Backend	Nie	infra/prod/services/stripe
AWS-Zugriffsschlüssel	CI/CD-Variablen	Alle	DevOps	6 Monate	infra/prod/cloud/aws

Ergebnis: Secret-Inventar-Tabelle

Teil 3: Passwork einrichten (45 Minuten)

1. Ordnerstruktur erstellen:

infrastructure/
├── production/
│   ├── databases/
│   ├── cloud/
│   └── services/
├── staging/
└── development/

2. Service-Konten erstellen:

   • deploy-prod-svc (Nur Lesen auf Produktion)
   • deploy-staging-svc (Nur Lesen auf Staging)
   • cred-rotator (Lesen/Schreiben auf alle)

3. 3–5 kritische Secrets aus Ihrem Inventar migrieren

4. Abruf testen:

export PASSWORK_HOST="https://passwork.your-company.com"
export PASSWORK_TOKEN="<service-account-token>"
export PASSWORK_MASTER_KEY="<master-key>"

passwork-cli get --password-id "<item-id>"

Ergebnis: Funktionierendes Passwork-Setup mit migrierten Secrets

Teil 4: Eine CI/CD-Pipeline aktualisieren (30 Minuten)

Ein nicht-kritisches Deployment (Staging, Dev-Umgebung) auswählen und:

1. Passwork-Zugangsdaten zu CI/CD-Secrets hinzufügen
2. Pipeline so anpassen, dass sie passwork-cli exec verwendet
3. Deployment testen
4. Alte Secrets aus CI/CD-Variablen entfernen

Ergebnis: Funktionierende Pipeline, die Passwork verwendet

Teil 5: Pre-Commit-Hooks installieren (15 Minuten)

pip install pre-commit

# Create .pre-commit-config.yaml
cat > .pre-commit-config.yaml << EOF
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
EOF

pre-commit install

Testen, indem Sie versuchen, ein gefälschtes Secret einzuchecken:

echo "aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" > test.txt
git add test.txt
git commit -m "test"  # Should be blocked
rm test.txt

Ergebnis: Pre-Commit-Hook, der Secret-Commits verhindert

Teil 6: .gitignore aktualisieren und Notfallzugriff dokumentieren (15 Minuten)

1. Secret-Dateimuster zu .gitignore hinzufügen:

cat >> .gitignore << 'EOF'

# Secrets and credentials
.env
.env.*
!.env.example
*.pem
*.key
secrets.yml
credentials.json
EOF

git add .gitignore
git commit -m "Add secret file patterns to .gitignore"

2. Notfallzugriffs-Dokumentation erstellen:

# Emergency Access Procedure

## Break-glass accounts
- Primary: [[email protected]] — has full Passwork admin access
- Secondary: [[email protected]] — has full Passwork admin access
- Emergency: Physical safe in [location], envelope labeled "Passwork Emergency"

## If a secret is compromised
1. Identify the compromised credential
2. Rotate it immediately in the target system
3. Update Passwork with the new value
4. Check audit logs for unauthorized access
5. Notify the team via [channel]

## If Passwork is unreachable
1. Contact [admin1] or [admin2]
2. If unavailable, use break-glass credentials from physical safe
3. Document all actions taken

Ergebnis: Aktualisiertes .gitignore und Notfallzugriffs-Prozessdokument

Artefakte aus diesem Kapitel

Am Ende dieses Kapitels sollten Sie haben:

1. Secret-Scan-Bericht — Befunde aus dem Repository-Scan mit Behebungsstatus
2. Secret-Inventar — Tabelle aller Secrets in Ihrer Infrastruktur
3. Passwork-Ordnerstruktur — organisierte Hierarchie für Infrastruktur-Secrets
4. Service-Konten — dedizierte Konten für CI/CD und Automatisierung
5. Migrierte Secrets — mindestens 5 kritische Secrets zu Passwork verschoben
6. Aktualisierte Pipeline — mindestens ein CI/CD-Workflow, der Passwork verwendet
7. Pre-Commit-Hooks — gitleaks oder git-secrets blockiert Secret-Commits
8. Aktualisiertes .gitignore — Muster zur Verhinderung von Secret-Datei-Commits
9. Notfallzugriffsverfahren — dokumentierter Break-Glass-Prozess

Erklärung gegenüber der Führungsebene

Wenn jemand fragt, warum Sie Zeit mit Secrets-Verwaltung verbringen:

„Ich verschiebe unsere Zugangsdaten — Datenbankpasswörter, API-Schlüssel, Cloud-Zugriff — aus unserer Codebasis in einen geeigneten Secrets Manager. Im Moment sind diese über Konfigurationsdateien, CI/CD-Variablen und .env-Dateien verstreut, die Personen über Slack teilen. Wenn jemandes Laptop gestohlen wird, ein unzufriedener Mitarbeiter vorhanden ist oder jemand versehentlich eine Konfigurationsdatei in ein öffentliches Repository pusht, hätten wir ein ernstes Problem. Mit Passwork erhalten wir zentralisierten Speicher mit Verschlüsselung, Zugriffskontrolle damit nur die richtigen Services die richtigen Secrets lesen können, und ein Audit-Protokoll darüber, wer auf was zugegriffen hat. Ich richte auch automatisches Scanning ein, damit wir neue Secrets abfangen, bevor sie eingecheckt werden."

Kurze Version: „Ich stelle sicher, dass unsere Passwörter und API-Schlüssel nicht gestohlen werden können, wenn jemandes Laptop verloren geht."

Selbstcheck

Repository-Hygiene

• Alle Repositories nach Secrets gescannt
• Exponierte Zugangsdaten rotiert
• Pre-Commit-Hooks installiert und funktionsfähig
• .gitignore mit Secret-Dateimustern aktualisiert
• Keine Secrets in der aktuellen Codebasis

Secrets-Verwaltung

• Passwork (oder Alternative) eingerichtet
• Ordnerstruktur entspricht den Umgebungen
• Service-Konten für Automatisierung erstellt
• Kritische Secrets migriert
• Notfallzugriffsverfahren dokumentiert

CI/CD-Integration

• Mindestens eine Pipeline verwendet Passwork
• Nur Passwork-Verbindungszugangsdaten in CI/CD-Variablen
• Deployment mit neuem Setup getestet

Prozess

• Secret-Inventar dokumentiert
• Rotationsplan definiert
• Team weiß, keine Secrets einzuchecken
• Anwendungen lesen Secrets aus Umgebungsvariablen

Haken Sie mindestens 12 von 17 Punkten ab, bevor Sie weitermachen.

Weiterführende Lektüre

• truffleHog-Dokumentation
• gitleaks-Dokumentation
• Passwork-Dokumentation

Was als nächstes kommt

Secrets aus dem Code. Rotation eingerichtet. Zugriff nach Rolle kontrolliert, nicht davon abhängig, wer den Slack-Kanal kennt, in dem jemand vor zwei Jahren den Schlüssel eingefügt hat.

Weiter: CI/CD-Pipeline-Sicherheit — SAST, DAST und Abhängigkeits-Scanning in Ihren Deployment-Workflow integrieren, damit Schwachstellen abgefangen werden, bevor sie ausgeliefert werden.