3.1 KiB
Kritische Architekturprobleme
1. Fataler Tenant-Isolation-Fehler
Das Datenmodell nennt sowohl organisation_id als auch tenant_id, aber ohne klare Abgrenzung. Dies ist ein kritischer Designfehler:
# Problem in data-model-v0.1.md:
"Von Anfang an vorbereiten:
- organisation_id
- tenant_id"
Warum kritisch:
- Unklare Hierarchie zwischen Organisation und Tenant
- Potenzielle Tenant-Leaks durch falsche Filterung
- Kein explizites Constraint-Modell definiert
Lösung erforderlich: Eine klare Entscheidung - entweder Organisation ODER Tenant, nicht beides halbherzig.
2. Secrets-Management ohne Implementierung
Das Security-Dokument behauptet:
"Secrets werden nur über einen Secret-Service gelesen/geschrieben"
Aber:
- Kein Secret-Service definiert
- Registrar-Account hat "Zugangsdaten/API-Referenzen" direkt im Modell
- Keine Encryption-at-Rest-Strategie
Risiko: Passwörter landen im Klartext in der Datenbank.
3. Audit-Log Hash-Chain ist Pseudo-Security
ADR 0014 schlägt eine Hash-Chain vor, aber:
- Kein Schutz gegen DB-Admin-Manipulation
- Hash-Algorithm nicht spezifiziert
- "V1 bereitet vor" = wird nicht implementiert
Problem: Security-Theater ohne echten Schutz. Ein DB-Admin kann die gesamte Chain neu berechnen.
4. Dead Letter Queue ohne Retention-Strategie
ADR 0017 fordert Dead Letter Queues, aber:
- Keine maximale Retention definiert
- Potenzielle Speicher-Explosion
- DSGVO-Konflikt bei personenbezogenen Daten in fehlgeschlagenen Jobs
5. Fehlende Core-Domain-Boundaries
Das Datenmodell mischt alles:
- Billing (Rechnung, Zahlung)
- Provisioning (Server, Hostingpaket)
- CRM (Kunde, Ticket)
- Registry (Domain, Registrar)
Problem: Keine Bounded Contexts = massive Kopplung, unmöglich zu skalieren.
6. Reconciliation ohne Event-Sourcing
ADR 0017 fordert Reconciliation, aber das Datenmodell hat keine Event-Historie. Wie soll man reconcilen ohne zu wissen, was passiert ist?
7. Security-Rollen ohne Scope-Definition
"Staff/Support" hat Zugriff auf "operative Daten" - was heißt das konkret?
- Kann Support Passwörter sehen?
- Kann Support Rechnungen ändern?
- Kann Support Server-Zugänge einsehen?
8. Single Point of Failure: tenant_id
Alles hängt an einem einzigen Feld. Ein fehlerhafter Query-Scope = Datenleck über alle Mandanten.
Fehlende Sicherheitsschicht:
- Kein Row-Level-Security auf DB-Ebene
- Keine Tenant-Context-Validierung
- Kein Fail-Safe-Mechanismus
9. Dokument-Objekt ohne Storage-Strategy
"Dokument" hat "Hashes" und "Archivinformationen", aber:
- Wo werden Dateien gespeichert?
- Wie wird Tenant-Isolation im Filesystem sichergestellt?
- Was passiert bei Löschanfragen?
10. Keine Migrationsstrategie für Multi-Tenancy
"V1 arbeitet als Single-Tenant" aber "Struktur vorbereitet" - das ist ein Widerspruch. Entweder man designed multi-tenant von Anfang an oder man plant eine Migration. Beides fehlt.
Fazit
Die Architektur versucht, zu viele Probleme gleichzeitig zu lösen, ohne eines davon richtig zu durchdenken. Kritischster Punkt: Die Tenant-Isolation ist nur oberflächlich geplant und wird mit hoher Wahrscheinlichkeit zu Datenleaks führen.