Section 01
Simple Explanation
Stell dir einen öffentlichen Web-Ordner wie einen Raum mit offener Tür vor. Wer den Link kennt, kann hineinsehen.
Für vertrauliche Kundendokumente brauchen wir später einen privaten Raum ohne direkte öffentliche Tür. Der Kunde fragt den Server nach einer Datei. Der Server prüft zuerst den Secure Room und die Rechte. Erst danach liefert der Server die Datei aus.
Genau deshalb ist privater Storage ein Kernpunkt für Consortium Vault.
Section 02
Public vs Private Storage
| Storage-Art | Einfach erklärt | Risiko / Vorteil |
|---|---|---|
| Public Folder | Dateien liegen direkt im Web-Ordner und können über Link geöffnet werden. | Für vertrauliche Kundendaten nicht ausreichend sicher. |
| Hidden URL | Der Link ist schwer zu erraten, aber technisch trotzdem direkt erreichbar. | Kein echter Zugriffsschutz, weil der Link weitergegeben werden kann. |
| Private Storage | Dateien liegen außerhalb des öffentlichen Web-Ordners. | Besser, weil der Server vor Zugriff prüfen kann. |
| Backend-Controlled Download | Der Server liefert die Datei nur nach erfolgreicher Rechteprüfung aus. | Professioneller Ansatz für echte Kundendokumente. |
Section 03
Recommended Structure
Später auf dem VPS sollte es eine klare Trennung geben zwischen öffentlichen Webseiten-Dateien und privaten Kundendateien.
| Bereich | Beispiel | Zweck |
|---|---|---|
| Public App | /var/www/consortium-vault/public | Öffentliche App-Dateien wie HTML, CSS, JS und Bilder. |
| Backend App | /var/www/consortium-vault/app | Serverlogik, Secure Room, Rollenprüfung und Dokumentenprüfung. |
| Private Storage | /srv/consortium-vault/private-documents | Vertrauliche Kundendateien, nicht direkt öffentlich erreichbar. |
| Backups | /srv/consortium-vault/backups | Sicherungen, später verschlüsselt und sauber getrennt. |
Section 04
Download Logic
Später darf ein Download nicht einfach ein direkter Link auf eine Datei sein. Der Ablauf muss ungefähr so aussehen:
| Schritt | Was passiert? | Warum? |
|---|---|---|
| 1 | Nutzer klickt auf „Dokument öffnen“. | Der Nutzer fordert eine Datei an. |
| 2 | Server prüft, ob der Nutzer eingeloggt ist. | Ohne Secure Room kein Zugriff. |
| 3 | Server prüft, ob die Datei diesem Kunden zugeordnet ist. | Kunde A darf keine Kunde-B-Dateien sehen. |
| 4 | Server liefert die Datei kontrolliert aus. | Die Datei bleibt privat gespeichert. |
| 5 | System schreibt einen Audit-Log-Eintrag. | Später ist nachvollziehbar, wer was geöffnet hat. |
Section 05
File Naming Rules
Dateinamen dürfen später nicht unnötig sensible Informationen enthalten. Ein Dateiname kann bei Fehlern, Logs oder Backups sichtbar werden.
| Schlecht | Besser | Grund |
|---|---|---|
| roman-passport-final.pdf | doc_8f31a9_passport.pdf | Weniger persönliche Daten im Dateinamen. |
| client-a-wallet-proof.pdf | doc_72bc11_verification.pdf | Reduziert Datenleck-Risiko. |
| contract-ubs-deal-real.pdf | doc_9d20ef_agreement.pdf | Keine sensiblen Deal-Hinweise im Dateinamen. |
| kunde-mueller-bankdaten.pdf | doc_a81c30_financial.pdf | Keine Kundennamen oder Bankhinweise im Dateinamen. |
Section 06
Backup Position
Backups sind wichtig, aber Backups können auch ein Risiko sein. Wenn sensible Dateien gesichert werden, müssen auch die Backups geschützt werden.
- Backups dürfen nicht öffentlich erreichbar sein.
- Backups sollten später verschlüsselt werden.
- Backup-Zugriff sollte streng begrenzt sein.
- Wiederherstellung muss getestet werden.
- Alte Backups müssen kontrolliert gelöscht werden.
Section 07
Next Step
Der nächste sinnvolle Schritt ist ein Local Prototype Index Audit. Dort prüfen wir alle bisherigen Seiten, Links, Versionen und Sicherheitswarnungen, bevor wir in Richtung echtes Backend oder VPS-Vorbereitung gehen.
Danach können wir entscheiden, ob wir zuerst die Oberfläche weiter veredeln oder mit einem einfachen echten Backend-Grundsystem starten.