Die Flask-Version installierte Werkzeug ungepinnt; Werkzeug >= 3 erzeugt
standardmaessig scrypt-Hashes ('scrypt:32768:8:1$salt$hex') statt
pbkdf2:sha256. Bestandskonten aus dieser Aera (u. a. der Produktiv-Admin)
konnten sich nach dem Rust-Cutover nicht anmelden, weil verify_password nur
pbkdf2 und Argon2 kannte.
- security.rs: verify_werkzeug_scrypt() (Parameter aus dem Hash-String,
dklen aus der Digest-Laenge, Konstantzeit-Vergleich); wie bei pbkdf2 wird
beim ersten erfolgreichen Login transparent auf Argon2id rehasht
- Unit-Test mit gegen hashlib.scrypt reproduziertem Referenzvektor
- Cargo.toml: scrypt 0.11 (RustCrypto, ohne Default-Features)
|
||
|---|---|---|
| deploy | ||
| src | ||
| static | ||
| templates | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Dockerfile | ||
| README.md | ||
| schema.sql | ||
README.md
ITSM
ITSM-Plattform (Service-Katalog, Tickets, Wissensdatenbank, CMDB) -- AES ist ein buchbarer Service darin. Eigenstaendiges Produkt, mandantenfaehig.
Stack: Rust (axum + tokio-postgres + askama), PostgreSQL 16. Rust-Rewrite 2026-07-15; zuvor Python/Flask -- Bestandsdaten (inkl. Passwort- Hashes) werden ohne Migration weiterverwendet, alte Werkzeug-PBKDF2-Hashes werden beim ersten Login transparent auf Argon2id umgestellt.
ITIL-Ausrichtung (v3-Prozesse / v4-Practices)
- Rollen: admin (Service Owner/IT-Leitung), change_manager (Change Enablement/CAB), agent (Service Desk), user (Requester/Self-Service: eigene Tickets, nur freigegebene Wissensartikel).
- Incident/Service Request: getrennte Kategorien; Statusmodell mit erzwungenen Uebergaengen (Offen -> In Bearbeitung -> Warten/Geloest -> Geschlossen; Reopen von Geloest).
- Prioritaet: automatisch aus der Impact-x-Urgency-Matrix (v3 SO 4.2.5.4).
- Change Enablement: Standard (vorautorisiert) / Normal (CAB-Freigabe durch change_manager/admin) / Emergency (sofort, nachtraegliche ECAB-Freigabe). Umsetzung + Repo-Aenderungen erst nach Freigabe.
- Problem Management: Incident-Problem-Verknuepfung, Known-Error-Status.
- SLA (Service Level Management): Antwort-/Loesungsfristen mit Zeitstempeln (erste Reaktion, Loesung, Schliessung), Ueberfaelligkeit.
- Knowledge Management: Freigabe-Workflow (Entwurf -> Freigegeben).
- SACM/CMDB: CIs, Beziehungen, Ticket-CI-Verknuepfung.
- Continual Improvement: Dashboard mit SLA-Erfuellung, MTTR, Verteilungen.
Sicherheit
- Serverseitige Sessions in PostgreSQL (Cookie enthaelt nur ein Zufallstoken, DB speichert dessen SHA-256; Logout/Sperrung widerruft sofort).
- CSRF-Schutz fuer alle zustandsaendernden Requests (Formular-Feld/Header).
- Login-Rate-Limit (pro E-Mail und IP, DB-gestuetzt), Audit-Log aller sicherheitsrelevanten Aktionen (ISO 27001 A.12.4 / DSGVO Art. 30).
- Argon2id-Passwoerter, Policy: min. 12 Zeichen.
- Security-Header (CSP ohne Inline-JS, X-Frame-Options, nosniff, HSTS bei ITSM_HTTPS=1); X-Forwarded-For nur bei ITSM_TRUSTED_PROXY_COUNT > 0.
- SSRF-Guard fuer Service-Endpoint-URLs (Link-Local/Metadaten blockiert, Anlegen admin-only); Erreichbarkeitspruefung parallel + gecacht.
- Repo-Bearbeitung aus Tickets (Forge-Contents-API, phase-008): nur admin/change_manager, nur aus freigegebenen Change-Tickets, jede Aenderung zwingend im Worklog dokumentiert.
- DSGVO-Retention: automatische Bereinigung von Tickets/Audit-Log gemaess Mandanten-Fristen; Login-Versuche nach 7 Tagen, abgelaufene Sessions sofort.
Betrieb
# Entwicklung
DATABASE_URL=postgresql://itsm:pw@localhost:5432/itsm cargo run
# Produktion: siehe deploy/docker-compose.yml (Multi-Stage-Build,
# kein Code-Pull beim Container-Start mehr)
ENV-Variablen: siehe src/config.rs. Schema-Migrationen laufen idempotent beim Start (schema.sql). Backup: deploy/backup.sh (taeglicher pg_dump, 14 Tage).
Tests
cargo test # ITIL-Statusmodell, Prioritaetsmatrix, Change-Gate,
# Argon2/Werkzeug-Hash-Verifikation, SSRF-Guard, Policy