42 lines
5.1 KiB
Markdown
42 lines
5.1 KiB
Markdown
|
# 06c – Secrets-Handling-Audit (Security & Data-Engineering)
|
|||
|
|
|
|||
|
|
**Projekt:** CRM System v1.0
|
|||
|
|
**Datum:** 2026-06-04
|
|||
|
|
**Auditor:** Security Data Engineer (Phase 6)
|
|||
|
|
**Repository:** `Leopoldadmin/crm-system`, Branch `main`
|
|||
|
|
**Scope:** .env/.gitignore-Prüfung, AUTH_SECRET-Handling, DATABASE_URL-Credentials, Coolify-ENV-Vars, Hardcoded-Fallback-Kontrolle
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Findings
|
|||
|
|
|
|||
|
|
| ID | Severity | Kategorie | Beschreibung | Empfehlung |
|
|||
|
|
|----|----------|-----------|-------------|------------|
|
|||
|
|
| SEC-01 | **PASS** | .gitignore-Regel | `.gitignore` enthält `.env`, `.env.*` mit Ausnahmen `!.env.example` und `!.env.docker.example`. Diese Konfiguration ist korrekt: Die `.env`-Datei (mit realen Dev-Secrets) ist nicht im Git-Tree (`git ls-files --error-unmatch .env` → "did not match"). | Keine Änderung nötig. Sicherstellen, dass `.env.docker` (falls jemals erstellt) ebenfalls exkludiert ist (aktuell durch `.env.*` abgedeckt). |
|
|||
|
|
| SEC-02 | **PASS** | .env.example (Template) | Enthält `AUTH_SECRET=replace-me-with-a-secure-random-string-at-least-32-chars-long` mit klarer Anweisung zum Generieren. Kein echter Secret-Wert committed. | Akzeptabel als Entwickler-Dokumentation. |
|
|||
|
|
| SEC-03 | **PASS** | .env (Dev) | Lokale `.env` enthält `AUTH_SECRET=test-secret-with-at-least-thirty-two-characters-for-development` – 62 Zeichen, kein Platzhalter, aber ein Dev-Secret. Datei ist nicht committed. | Nur für lokale Entwicklung akzeptabel. Sollte vor einem versehentlichen Commit durch `.gitignore` geschützt sein – ist es. |
|
|||
|
|
| SEC-04 | **PASS** | AUTH_SECRET-Validierung | `config.py` `Settings.AUTH_SECRET: str = Field(..., min_length=32)` – zwingendes Feld ohne Default, Hard-Fail bei fehlendem Wert. Zusätzlicher `field_validator` lehnt Platzhalter (`replace-me`, `changeme`, `secret`) ab. Erfüllt Architecture R-5 (NO JWT secret fallback). | Robust implementiert. Kein Angriffspunkt. |
|
|||
|
|
| SEC-05 | **PASS** | AUTH_SECRET-Generierung | `COOLIFY_SETUP.md` dokumentiert Secret-Generierung mit `python -c "import secrets; print(secrets.token_urlsafe(48))"`. Empfohlene Länge: 48 Zeichen (Base64-encoded, ~384 Bit Entropie). | Entspricht Best Practices. Empfehlung für Rotation: `cron`-Job, der AUTH_SECRET rotiert und alle Tokens invalidiert (v1.1). |
|
|||
|
|
| SEC-06 | **PASS** | Hardcoded-Fallback-Kontrolle | Kein `AUTH_SECRET = "dev-secret"`-Fallback im Code. `Field(...)` (Ellipsis) in Pydantic bedeutet: Wert MUSS gesetzt sein, sonst ValidationError beim App-Start. `get_settings()` via `@lru_cache` cached die Settings-Instanz – jede Änderung an Env-Vars erfordert App-Neustart. | Erfüllt Architecture R-5. Kein Soft-Fallback vorhanden. |
|
|||
|
|
| SEC-07 | **PASS** | DATABASE_URL | Enthält Credentials im Format `postgresql+asyncpg://crm_user:<PW>@<host>:5432/crm_db`. Wird via Coolify Env-Var `DATABASE_URL` gesetzt (nicht im Repo). Dev-Default `sqlite+aiosqlite:///./dev.db` enthält keine Credentials. In `COOLIFY_SETUP.md` dokumentiert: Passwort mit `secrets.token_urlsafe(24)` generieren. | Production-Passwort muss stark sein (≥ 16 Zeichen). Aktuelles Dev-Setup (SQLite) ist credential-frei. |
|
|||
|
|
| SEC-08 | **PASS** | Coolify-ENV-Vars | Alle erforderlichen Secrets in `COOLIFY_SETUP.md` dokumentiert: `DATABASE_URL`, `AUTH_SECRET`, `CORS_ORIGINS`, `ENVIRONMENT`, `LOG_LEVEL`, `BCRYPT_ROUNDS`, `JWT_ALGORITHM`, `JWT_EXPIRY_HOURS`. Bulk-Update-Skript via Coolify-API bereitgestellt. | Vollständig dokumentiert. Keine weiteren Secrets nötig. |
|
|||
|
|
| SEC-09 | **INFO** | Secrets-Rotation | Keine Rotation von `AUTH_SECRET` oder `DATABASE_URL`-Passwort in v1 vorgesehen. Token-Invalidierung bei Secret-Rotation würde alle aktiven Sessions beenden – kein Mechanismus dafür implementiert. | Für v1 akzeptabel. In v1.1: Secret-Rotation mit invalidierungs-Mechanismus planen. |
|
|||
|
|
| SEC-10 | **WARN** | dev.db im Repository | Datei `dev.db` (286.720 Bytes) existiert im Working-Tree, ist aber durch `.gitignore`-Regel `*.db` geschützt. `git ls-files` zeigt sie nicht an. Dennoch: SQLite-DB mit potenziell echten Testdaten sollte nie im Repo liegen. | Aktuell geschützt durch .gitignore. Vor Release: `dev.db` aus Working-Tree löschen und sicherstellen, dass `.git/info/exclude` oder `.gitignore` alle DB-Dateien blockiert. |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Summary: **PASS** ✅
|
|||
|
|
|
|||
|
|
Das Secrets-Handling ist sicher. `.env` ist korrekt exkludiert, `AUTH_SECRET` hat Hard-Fail-Validierung ohne Fallback, und alle Coolify-ENV-Vars sind dokumentiert. Keine kritischen Findings.
|
|||
|
|
|
|||
|
|
**Offene Punkte:** Secrets-Rotation ist für v1 nicht implementiert, und die lokale `dev.db` sollte vor Release aus dem Working-Tree entfernt werden.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Empfehlungen für Phase 7 (Quality-Reviewer)
|
|||
|
|
|
|||
|
|
1. **dev.db-Bereinigung** – Vor Release: `dev.db` aus Working-Tree löschen und `.gitignore` auf DB-Dateien prüfen.
|
|||
|
|
2. **Secrets-Rotation-Planung** – Dokumentieren, wie AUTH_SECRET und DB-Password in Coolify rotiert werden (v1.1 ToDo).
|
|||
|
|
3. **Environment-Parity-Check** – Sicherstellen, dass alle in `.env.example` dokumentierten Keys auch in Coolify gesetzt sind (und umgekehrt).
|
|||
|
|
4. **Secrets-Audit in CI/CD** – Optional: `detect-secrets` oder `git-secrets` Pre-Commit-Hook für automatische Secrets-Erkennung.
|