Der Schlüssel neben dem Tresor
Ein Tresor ist nur so sicher wie die Art, wie man den Schlüssel aufbewahrt. Wenn der Schlüssel direkt daneben hängt, nützt die beste Tür nichts. Genauso verhält es sich mit Kryptografie: Selbst die stärkste Verschlüsselung ist wertlos, wenn Schlüsselmanagement versagt.
Harcoded Keys im Quellcode
Einer der häufigsten Fehler: Entwickler speichern Keys direkt im Code.
Beispiel:
const secretKey = "mySuperSecretKey123";
Wird der Code in ein Repository wie GitHub hochgeladen – egal ob öffentlich oder intern – finden Angreifer den Schlüssel sofort.
Es gibt sogar Suchmaschinen, die gezielt nach API-Keys oder Secrets in Repos scannen.
Fehlende Schlüsselrotation
Viele Systeme nutzen denselben Schlüssel über Jahre hinweg.
Problem:
- Wird der Schlüssel irgendwann kompromittiert, kann der Angreifer alle Daten – auch alte – entschlüsseln.
- Compliance-Standards (z. B. PCI DSS) fordern regelmäßige Rotation.
Ein klassisches Beispiel: Datenbanken, die mit einem „Master-Key“ verschlüsselt sind, der nie geändert wird.
Unsichere Speicherung von Schlüsseln
Ein weiterer Fehler: Keys werden einfach in Konfigurationsdateien oder Umgebungsvariablen im Klartext abgelegt – oft ohne Zugriffskontrolle.
Beispiele:
config.jsonmit allen Datenbank-Passwörtern..env-Datei ohne Schutz, die versehentlich ins Repo committet wird.- Backups, die unverschlüsselt in der Cloud liegen.
Fehlende Zugriffskontrollen
Schlüssel sind hochsensible Daten – trotzdem haben in manchen Firmen alle Entwickler Zugriff auf Produktions-Keys.
Risiken:
- Insider-Bedrohungen.
- Ungewollte Leaks (z. B. durch Debugging).
- Kein Überblick, wer Zugriff hatte.
Best Practices für sicheres Schlüsselmanagement
Secrets Manager nutzen
Statt Keys im Code oder in Dateien abzulegen, sollte man spezialisierte Systeme verwenden, z. B.:
- HashiCorp Vault
- AWS KMS (Key Management Service)
- Azure Key Vault
- Google Cloud KMS
Diese Systeme speichern Keys verschlüsselt, verwalten Zugriffsrechte und protokollieren, wer wann auf welche Secrets zugegriffen hat.
Schlüsselrotation automatisieren
- Keys regelmäßig wechseln.
- Alte Keys widerrufen und sicher löschen.
- Prozesse und Tools einsetzen, die Rotation automatisiert durchführen.
Zugriff einschränken
- Prinzip des Least Privilege: Nur diejenigen dürfen Keys sehen, die sie wirklich brauchen.
- Rollenbasierte Zugriffsrechte (z. B. Devs nur für Test-Keys, Ops für Prod-Keys).
- Logging & Monitoring, um Missbrauch zu erkennen.
Keine Hardcoded Secrets
- Keys niemals im Code oder in Repos speichern.
- Stattdessen über sichere Umgebungsvariablen oder Secrets Manager einbinden.
- GitHub bietet z. B. Secret Scanning, um versehentlich hochgeladene Keys zu erkennen.
Organisatorische Maßnahmen
- Schulungen für Entwickler: Viele Leaks entstehen durch Unwissenheit.
- Security Policies: Klare Vorgaben, wie Keys erzeugt, gespeichert und rotiert werden.
- Notfallpläne: Wenn ein Schlüssel kompromittiert wird, muss klar sein, wie man ihn ersetzt und Systeme absichert.
Schreibe einen Kommentar