126 lines
3.4 KiB
Markdown
126 lines
3.4 KiB
Markdown
## Kritische Architekturprobleme
|
|
|
|
### 1. **Fataler Tenant-Isolation-Fehler**
|
|
|
|
Das Multi-Tenancy-Konzept ist oberflächlich und gefährlich:
|
|
|
|
```sql
|
|
-- So wird es NICHT funktionieren:
|
|
SELECT * FROM customers WHERE tenant_id = ?
|
|
-- Vergessener tenant_id Filter = Datenleak!
|
|
```
|
|
|
|
**Problem:** Keine technische Enforcement-Ebene definiert. Laravel Policies allein reichen nicht - ein vergessener Scope und alle Kundendaten sind exponiert.
|
|
|
|
**Lösung erforderlich:**
|
|
- PostgreSQL Row Level Security (RLS) als Pflicht
|
|
- Automatische Query-Scopes auf Model-Ebene
|
|
- Tenant-Context in Session, nicht nur als Parameter
|
|
|
|
### 2. **Secrets-Management ist ein Luftschloss**
|
|
|
|
"Secrets werden nur über einen Secret-Service gelesen/geschrieben" - aber:
|
|
- Kein Service definiert
|
|
- Keine Rotation-Strategie
|
|
- Keine Verschlüsselung at-rest spezifiziert
|
|
- Registrar-Account speichert "Zugangsdaten/API-Referenzen" direkt?
|
|
|
|
Das ist ein Compliance-Alptraum und PCI-DSS-Verstoß.
|
|
|
|
### 3. **Audit-Log Hash-Chain ist Theatralik**
|
|
|
|
```python
|
|
# "Hash-Chain" ohne:
|
|
- Timestamp-Server
|
|
- Externe Verifikation
|
|
- Key-Management für Signierung
|
|
```
|
|
|
|
Eine selbstgebaute Hash-Chain beweist nichts. Jeder mit DB-Zugriff kann die gesamte Chain neu berechnen.
|
|
|
|
### 4. **Domain-Model ist naiv**
|
|
|
|
Domain-Objekt ohne:
|
|
- DNS-Record-Management
|
|
- DNSSEC-Status
|
|
- Transfer-Locks
|
|
- Auth-Codes verschlüsselt?
|
|
- Whois-Privacy-Settings
|
|
- Expiry-Notifications
|
|
|
|
Das ist kein produktionsfähiges Domain-Management.
|
|
|
|
### 5. **Fehlendes Event-Sourcing für kritische Flows**
|
|
|
|
Vertragsänderungen, Zahlungen und Kündigungen nur als CRUD?
|
|
|
|
```yaml
|
|
# Fehlende State-Machines für:
|
|
- Vertragsstatus-Übergänge
|
|
- Zahlungsflows
|
|
- Domain-Transfers
|
|
```
|
|
|
|
Inkonsistente Zustände sind vorprogrammiert.
|
|
|
|
### 6. **Adapter-Resilienz ohne Circuit Breaker**
|
|
|
|
ADR 0017 listet Retry/Backoff, aber:
|
|
- Kein Circuit Breaker Pattern
|
|
- Keine Health-Check Definition
|
|
- Keine Fallback-Strategien
|
|
- "Reconciliation" ohne Konfliktauflösung
|
|
|
|
### 7. **Customer vs Kunde - Inkonsistente Domänensprache**
|
|
|
|
Mal "Kunde", mal "Customer", mal "tenant_id", mal "organisation_id". Das führt zu:
|
|
- Verwirrung im Team
|
|
- Fehlerhaften Mappings
|
|
- Doppelten Konzepten
|
|
|
|
### 8. **Fehlende Bounded Contexts**
|
|
|
|
Alles in einem großen Datenmodell:
|
|
- Billing gehört nicht zu Hosting
|
|
- Tickets sind ein eigenes System
|
|
- Domains vs Server-Management vermischt
|
|
|
|
Monolithische Verkopplung statt modularer Architektur.
|
|
|
|
### 9. **Keine Versionierungsstrategie für Verträge/Produkte**
|
|
|
|
Was passiert wenn:
|
|
- Produktpreise sich ändern?
|
|
- Vertragsbedingungen angepasst werden?
|
|
- Alte Rechnungen reproduziert werden müssen?
|
|
|
|
### 10. **Dead Letter Queue ohne Retry-Limits**
|
|
|
|
Infinite Retry-Loops möglich. Keine Definition von:
|
|
- Max-Retry-Count
|
|
- Exponential Backoff Caps
|
|
- Alert-Thresholds
|
|
- Poison Message Handling
|
|
|
|
### 11. **GoBD-Compliance ist Wunschdenken**
|
|
|
|
- Keine Unveränderbarkeits-Garantie
|
|
- Keine Verfahrensdokumentation
|
|
- Hash-Chain != Revisionssicherheit
|
|
- Fehlende Archivierungsstrategie
|
|
|
|
### 12. **Superadmin als Backdoor**
|
|
|
|
"Systemweiter Zugriff" für Superadmin ohne:
|
|
- 4-Augen-Prinzip
|
|
- Break-Glass-Procedures
|
|
- Time-boxed Privileges
|
|
- Segregation of Duties
|
|
|
|
Das ist ein Insider-Threat-Paradies.
|
|
|
|
## Fazit
|
|
|
|
Diese Architektur wird in Produktion scheitern. Zu viele Kernkonzepte sind halbgar durchdacht. Besonders die Tenant-Isolation und das Secrets-Management sind brandgefährlich.
|
|
|
|
Empfehlung: Zurück ans Reißbrett. Mit einem erfahrenen Security-Architekten die Grundlagen neu aufsetzen. |