Section 01
Simple Explanation
Stell dir Consortium Vault wie ein Hotel mit vielen privaten Zimmern vor. Jeder Kunde bekommt später sein eigenes Zimmer.
Der Kunde darf nur sein eigenes Zimmer betreten. Er darf nicht in andere Zimmer schauen. Genau das muss später der Server technisch kontrollieren.
Eine versteckte URL ist dafür nicht genug. Ein Kunde könnte den Link weiterleiten oder erraten. Deshalb muss jede Datei über eine echte Rechteprüfung geschützt werden.
Section 02
Role Model
| Rolle | Einfach erklärt | Darf später |
|---|---|---|
| Super Admin | Hauptverwalter des Systems. | Kunden, Admins, Dokumente und Zugriffe verwalten. |
| Admin | Interner Mitarbeiter mit eingeschränkter Verwaltung. | Kundenräume und Dokumente verwalten, wenn freigegeben. |
| Client User | Kundenbenutzer. | Nur eigene freigegebene Dokumente sehen. |
| Viewer | Sehr eingeschränkter Benutzer. | Nur bestimmte Dokumente ansehen, kein Upload. |
Section 03
Access Rules
| Regel | Bedeutung | Warum wichtig? |
|---|---|---|
| Kunde A sieht nur Kunde-A-Dokumente | Dokumente müssen eindeutig einem Kundenraum zugeordnet sein. | Verhindert Datenlecks zwischen Kunden. |
| Jede Datei wird serverseitig geprüft | Der Server entscheidet vor dem Öffnen, ob Zugriff erlaubt ist. | Schützt auch dann, wenn jemand einen Link kennt. |
| Keine sensiblen Dateien im Public-Ordner | Dateien dürfen nicht direkt öffentlich erreichbar sein. | Sonst kann ein Link die Datei ohne Secure Room öffnen. |
| Downloads werden kontrolliert | Downloadlinks sollten später zeitlich begrenzt oder servergesteuert sein. | Reduziert unkontrollierte Weitergabe. |
Section 04
Data Model
Später braucht das System eine Datenbank. Die Datenbank ist wie ein Register, in dem steht: Wer ist der Nutzer? Zu welchem Kunden gehört er? Welche Dokumente darf er sehen?
| Tabelle | Speichert | Einfach erklärt |
|---|---|---|
| users | Benutzerkonten | Wer kann sich einloggen? |
| clients | Kundenprofile | Welche Kundenräume gibt es? |
| client_users | Verbindung zwischen Kunde und Benutzer | Welcher Nutzer gehört zu welchem Kunden? |
| documents | Dokumenteninformationen | Welche Datei existiert im System? |
| document_permissions | Zugriffsrechte | Wer darf welches Dokument sehen? |
| activity_logs | Aktivitätsprotokoll | Wer hat wann was geöffnet oder geändert? |
Section 05
Unsafe vs Safe
| Unsicher | Besser | Grund |
|---|---|---|
| PDF in öffentlichen Ordner legen | PDF privat speichern und über Backend ausliefern | Öffentliche Dateien können ohne echte Prüfung geöffnet werden. |
| Link per WhatsApp senden | Secure Room + kontrollierter Zugriff | Links können weitergeleitet werden. |
| Kundennamen im Dateinamen | Neutrale interne Dateinamen | Reduziert Risiko bei Leaks oder Fehlversand. |
| Passwort im Code speichern | Passwort sicher gehasht in Datenbank speichern | Passwörter dürfen nie offen im Code stehen. |
Section 06
Next Step
Der nächste sinnvolle Schritt ist ein Upload-Preview. Dort entwerfen wir die spätere Oberfläche, über die ein Admin Dokumente hochladen und einem Kundenraum zuweisen kann.
Wichtig: Auch dieser Upload wird zuerst nur Design sein. Ein echter Upload darf später erst mit Backend, Dateiprüfung, Größenlimit, privatem Storage und Rechteprüfung gebaut werden.