Security-Härtung und verbleibende Grenzen

Umgesetzt

• Backend ist als stateless OAuth2 Resource Server mit Keycloak-JWT konfiguriert.
• API-Berechtigungen werden serverseitig anhand der Realm-Rollen geprüft.
• Das Datenbankpasswort besitzt keinen unsicheren Defaultwert mehr; PROCUREX_DB_PASSWORD

muss aus .env, Jenkins-Credentials oder einer Kubernetes-Secret-Referenz kommen.

• Docker-Runtime-Images laufen mit einem unprivilegierten Benutzer.
• Kubernetes referenziert ein vorhandenes Secret statt Zugangsdaten im Helm-Repository zu

versionieren.

• Das Frontend nutzt für die Benutzeranmeldung Authorization Code + PKCE.

Lernprojekt-Grenzen

Die lokale Umgebung verwendet absichtlich HTTP-Hostnamen und darf deshalb nicht als

Produktions-Sicherheitskonfiguration verstanden werden. Für einen echten Betrieb fehlen noch

TLS-Zertifikate, HSTS, zentrale Secret-Verwaltung, Rate Limiting, Security-Header-Prüfung,

Dependency-/Container-Scanning und ein automatisierter DAST-Scan.

Der Prometheus-Endpunkt ist für die lokale Plattform ohne JWT erreichbar, damit Prometheus

scrapen kann. In einer produktiven Umgebung muss der Zugriff auf das Monitoring-Netz oder eine

separate Authentifizierung begrenzt werden.

Sicherheitsnachweis

Vor einem Release sind mindestens folgende Prüfungen auszuführen und zu archivieren:

1. JWT-Tests für erlaubte und verbotene Rollen;
2. Prüfung, dass fehlende Secrets den Start abbrechen;
3. Dependency- und Container-Scan;
4. TLS-/Header-Prüfung am Ingress;
5. DAST-Baseline gegen eine isolierte Testumgebung;
6. Prüfung, dass keine Secrets in Git, Logs oder Testreports erscheinen.