Secrets Management - Definition & Erklärung

Secrets Management ist das systematische Gegenmittel zu einer der häufigsten Sicherheitslücken moderner Softwareentwicklung: Hart codierte Credentials, API-Keys in .env-Dateien die in Git eingecheckt werden, oder Passwörter in Environment-Variablen ohne Rotation. Jeden Tag werden Tausende von API-Keys versehentlich auf GitHub veröffentlicht.

Das Problem: Secrets überall

Verbreitete Anti-Patterns

1. Hardcoded im Source Code (häufigster Fehler):

database_password = "SuperSecret123!"
AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"

2. In .env-Dateien eingecheckt:

.env enthält: DB_PASSWORD=geheim

.gitignore fehlt oder .env trotzdem committed. Die Git-History enthält das Credential - auch nach Löschung rekonstruierbar!

3. Unkryptierte Config-Files:

config.yml: password: admin123

4. CI/CD-Variables im Klartext:

# Gitlab-CI:
variables:
  PROD_KEY: "abc123"  # nicht als masked!

5. Docker Images mit Secrets:

ENV DB_PASSWORD=geheim  # ← in Docker-Layer, auch nach rm sichtbar!

6. Log-Dateien mit sensitiven Daten:

logger.debug(f"Connecting to DB with {password}")

Konsequenzen

Credential Scanning (TruffleHog, GitLeaks) findet Keys in Sekunden
GitLab/GitHub: kontinuierliches Secret-Scanning (seit 2023 kostenlos)
Ein AWS-Key = potenzieller 6-stelliger Cloud-Schaden in Minuten
Rotation nötig, aber Abhängigkeiten unklar? → unkontrolliertes Secret-Chaos

HashiCorp Vault - Enterprise Secrets Management

Vault ist das am weitesten verbreitete Open-Source Secrets Management System.

Konzepte

Begriff	Bedeutung
Secret Engines	Plugins für verschiedene Secret-Typen
Auth Methods	Wie sich Clients authentifizieren
Policies	Was ein Client lesen/schreiben darf
Lease	Secrets haben TTL (Time-to-Live)
Audit Log	Jede Vault-Operation wird geloggt

# Docker:
docker run -d --name vault \
  -p 8200:8200 \
  -e 'VAULT_DEV_ROOT_TOKEN_ID=dev-token' \
  hashicorp/vault:latest

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='dev-token'

# KV (Key-Value) Engine aktivieren:
vault secrets enable -path=secret kv-v2

# Secret speichern:
vault kv put secret/database \
  username=dbuser \
  password="Sup3rS3cure!" \
  host="db.intern.firma.de"

# Secret lesen:
vault kv get secret/database

# JSON-Output für Scripting:
vault kv get -format=json secret/database | jq '.data.data.password'

# Dynamic Secrets (Auto-rotating Database Credentials):
# Vault generiert temporäre DB-Credentials on-demand!

vault secrets enable database

vault write database/config/my-postgresql-database \
  plugin_name=postgresql-database-plugin \
  allowed_roles="readonly" \
  connection_url="postgresql://{{username}}:{{password}}@localhost:5432/mydb" \
  username="vaultadmin" \
  password="admin-password"

vault write database/roles/readonly \
  db_name=my-postgresql-database \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN VALIDITY '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# App-Aufruf: jedes Mal neues Credential!
vault read database/creds/readonly
# Key      Value
# username  v-readonly-2024AbCd
# password  A1b2C3d4-random-40chars
# lease_duration  1h (danach wird Account automatisch gelöscht!)

Cloud-Native Secrets Management

# AWS Secrets Manager - Secret erstellen:
aws secretsmanager create-secret \
  --name "prod/app/database" \
  --description "Production database credentials" \
  --secret-string '{"username":"dbuser","password":"secret123"}'

# AWS Secrets Manager - In Anwendung abrufen (Python/Boto3):
import boto3
import json

client = boto3.client('secretsmanager', region_name='eu-central-1')
response = client.get_secret_value(SecretId='prod/app/database')
secret = json.loads(response['SecretString'])
db_password = secret['password']

# AWS - Automatische Rotation aktivieren:
aws secretsmanager rotate-secret \
  --secret-id "prod/app/database" \
  --rotation-lambda-arn "arn:aws:lambda:eu-central-1:123456:function:rotation-fn" \
  --rotation-rules AutomaticallyAfterDays=30

# Azure Key Vault - Geheimnis setzen:
az keyvault secret set \
  --vault-name "mycompany-keyvault" \
  --name "DatabasePassword" \
  --value "SuperSecretPassword!"

# Azure Key Vault - In App (Python):
from azure.keyvault.secrets import SecretClient
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()  # Managed Identity!
client = SecretClient(
  vault_url="https://mycompany-keyvault.vault.azure.net/",
  credential=credential
)
password = client.get_secret("DatabasePassword").value

# Kubernetes External Secrets Operator (besser als plain K8s Secrets):
# Hinweis: Plain kubectl secrets sind Base64-kodiert, nicht verschlüsselt!
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: database-secret
  data:
  - secretKey: password
    remoteRef:
      key: secret/database
      property: password

Secrets Detection und Prävention

# Pre-Commit Hooks - Secrets vor dem Push stoppen:

# git-secrets installieren:
brew install git-secrets
git secrets --install      # In Repo konfigurieren
git secrets --register-aws # AWS-Key-Pattern hinzufügen

# gitleaks (modernes Tool):
brew install gitleaks
gitleaks protect --staged  # Staged Changes prüfen
gitleaks detect            # Gesamtes Repository scannen

# TruffleHog:
trufflehog git file://./mein-repo --json

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

# CI/CD-Integration (GitLab):
secret_scanning:
  stage: security
  image: trufflesecurity/trufflehog:latest
  script:
    - trufflehog git file://$CI_PROJECT_DIR --only-verified
  allow_failure: false    # Pipeline schlägt bei Fund fehl!

# GitLab Secret Detection (built-in, seit GitLab 13.1):
include:
  - template: Security/Secret-Detection.gitlab-ci.yml

GitHub Advanced Security

Automatisches Secret Scanning auf allen Public Repos
Push Protection (verhindert Commit mit bekannten Secrets)
Partner-Program: GitHub informiert AWS/GitHub/etc. bei Fund
Private Repos: Teil von GitHub Advanced Security (kostenpflichtig)

Was erkannt wird:

AWS Access Keys (AKIA...)
Google API Keys (AIza...)
GitHub Personal Access Tokens (ghp_...)
Stripe API Keys (sk_live_...)
Twilio API Keys
100+ weitere Provider-Patterns

Secrets Rotation - Kontinuierliche Erneuerung

Rotations-Strategie

Passwörter:

Kritische System-Passwörter: monatlich oder quartalsweise
Service-Account-Passwörter: Vault dynamic secrets (TTL 1-24h)
Automatisierte Rotation via Skript oder Vault

API-Keys:

Expiry-Dates setzen (max. 1 Jahr)
Regelmäßiges Audit: werden alle Keys noch genutzt?
Unused Keys sofort revoken

Zertifikate:

Let’s Encrypt: automatisch alle 60 Tage (certbot / cert-manager)
Interne PKI: 1-2 Jahre, automatisierte Verlängerung
TLS-Zertifikate überwachen (Expiry-Alerts!)

Rotation Best Practices

Zero-Downtime-Rotation: neues Secret setzen, dann altes invalidieren
Abhängigkeiten dokumentieren: wer nutzt diesen Key?
Staging-Test vor Production-Rotation
Rollback-Plan: falls neue Credentials nicht funktionieren
Audit-Log der Rotation (wer, wann, warum?)

Rotation-Checkliste nach Datenpanne

Sofort: alle betroffenen Credentials invalidieren
Neue Credentials mit höherer Entropie generieren
Alle Abhängigkeiten updaten
Logs prüfen: war der Key kompromittiert? (Access-Logs!)
Ursache beheben (wie kamen Credentials raus?)

Unternehmens-Checkliste

Sofort-Maßnahmen

# History auf Credentials prüfen:
git log --all --full-history -- "*.env" | grep -i password

# Alle Repos scannen:
# TruffleHog oder gitleaks ausführen

# AWS Console: IAM → Access Analyzer (öffentliche Ressourcen?)
# HIBP API: wurden Firmen-Credentials im Darknet gefunden?

Mittelfristig

Vault oder Cloud Secrets Manager einführen
Pre-Commit Hooks auf allen Entwickler-Rechnern
CI/CD: Secret-Scanning als Pflicht-Stage
Alle bestehenden Credentials rotieren
Inventory: welche Secrets existieren wo?

Dauerhaft

Dynamic Secrets für Datenbanken (Vault)
Least Privilege: jeder Service nur nötige Secrets
Audit-Log: wer hat welche Secrets abgerufen?
Break-Glass: Notfall-Prozedur für Vault-Ausfall
Jährliche Credentials-Inventur