Section 01
Upload Overview
Der spätere Upload-Bereich soll es einem Admin ermöglichen, Dokumente in Consortium Vault hochzuladen und sie einem bestimmten Kundenraum zuzuweisen.
Wichtig ist: Hochladen allein reicht nicht. Das System muss später auch prüfen, wer die Datei sehen darf, wo die Datei gespeichert wird und ob die Datei sicher ist.
Section 02
Upload Form Preview
| Feld | Demo-Wert | Späterer Zweck |
|---|---|---|
| Dokumenttitel | Private Client Report | Saubere Bezeichnung im Kundenportal |
| Dokumenttyp | HTML / PDF / Vault File | Unterscheidung der Dateikategorie |
| Kunde | Demo Client A | Zuweisung zu einem Kundenraum |
| Zugriffsstatus | Draft / Active / Locked | Steuerung der Sichtbarkeit |
| Datei | No real upload | Später echte Datei mit Sicherheitsprüfung |
Section 03
Client Assignment
Jedes Dokument muss später eindeutig einem Kundenraum oder einer bestimmten Berechtigungsgruppe zugeordnet werden.
| Dokument | Zugewiesen an | Sichtbarkeit | Status |
|---|---|---|---|
| Private Client Briefing | Demo Client A | Client User + Admin | Demo Active |
| Due Diligence Package | Demo Client A | Admin Only | Locked |
| Source of Funds Register | Demo Client B | Admin Only | Locked |
| Access Instructions | Demo Client C | Client User | Draft |
Section 04
Security Checks
Ein echter Upload-Bereich ist sicherheitskritisch. Eine hochgeladene Datei kann falsch benannt, zu groß, beschädigt oder gefährlich sein. Deshalb muss später jeder Upload geprüft werden.
| Prüfung | Einfach erklärt | Warum wichtig? |
|---|---|---|
| Dateityp prüfen | Nur erlaubte Dateitypen akzeptieren. | Reduziert gefährliche oder falsche Dateien. |
| Dateigröße begrenzen | Zu große Dateien ablehnen. | Schützt Server und Speicher. |
| Dateiname bereinigen | Keine gefährlichen Sonderzeichen oder Kundendaten im Dateinamen. | Reduziert technische und Datenschutzrisiken. |
| Privat speichern | Dateien nicht direkt öffentlich ablegen. | Verhindert Zugriff ohne Secure Room. |
| Audit Log | Speichern, wer wann welche Datei hochgeladen hat. | Wichtig für Nachvollziehbarkeit. |
Section 05
Unsafe vs Safe Upload
| Unsicher | Sicherer Ansatz | Grund |
|---|---|---|
| Datei direkt in öffentlichen Ordner laden | Datei privat speichern | Öffentliche Dateien können ohne Secure Room geöffnet werden. |
| Original-Dateiname übernehmen | Internen sicheren Dateinamen erzeugen | Verhindert Datenlecks und technische Probleme. |
| Alle Dateitypen erlauben | Nur definierte Dateitypen erlauben | Reduziert Malware- und Missbrauchsrisiko. |
| Keine Protokollierung | Upload im Audit Log speichern | Später muss nachvollziehbar sein, wer was getan hat. |
Section 06
Next Step
Der nächste sinnvolle Schritt ist ein Storage Blueprint. Dort legen wir fest, wo Dokumente später liegen dürfen und warum sensible Dateien nicht im öffentlichen Web-Ordner gespeichert werden sollten.
Danach können wir entscheiden, ob wir zuerst weiter HTML-Prototypen bauen oder langsam in Richtung echtes Backend gehen.