Aktuelle Sicherheitsarchitektur

Aktuelle Architektur der privaten Vorschau von Dossira

Dieses Dokument beschreibt das Verhalten, das wir derzeit im Anwendungscode verifizieren können. Es ist keine Liste geplanter Kontrollen.

1. Anwendungsumfang

Dossira baut derzeit auf einem organisationsgebundenen Datei-Workspace auf mit:

Durchsuchen von Ordnern und Dateien;
Upload, Vorschau und Download;
gängigen Dateioperationen;
interner Workspace-Mitgliedschaft;
vom Eigentümer erstellten externen Freigaben;
optionaler E2EE für unterstützte Dateiinhalt-Operationen.

Kommentare, Entscheidungen, ein Room-Aktivitätsprotokoll, Versiegelung, Audit-Export, Abrechnung und Durchsetzung von Quoten sind derzeit nicht Teil der Produktoberfläche der privaten Vorschau.

2. Authentifizierung und Empfängerzugriff

Interne Mitglieder

Registrierte interne Mitglieder können über das Host-Identitätssystem auf unterstützten Geräten eine Passkey wählen. Derselbe Anmeldeselektor bietet auch E-Mail-Passwort- und Magic-Link-Anmeldung, sodass Passkeys bevorzugt, aber nicht verpflichtend oder exklusiv sind.

Die Verfügbarkeit von Passkeys hängt von WebAuthn-Unterstützung und einem verfügbaren Authentifikator ab. Dossira veröffentlicht keine universelle Browser-, Gerätesynchronisierungs- oder Wiederherstellungsgarantie. Login-Passkeys sind außerdem von den persönlichen und Workspace-Schlüsseln zu unterscheiden, die von optionaler E2EE verwendet werden.

Externe Empfänger

Externe Empfänger verwenden derzeit:

bestätigte E-Mail-Freigabe mit PIN-Verifizierung; oder
einen ausdrücklich erstellten öffentlichen Link.

Externe Empfänger erhalten derzeit nicht denselben Mitglieder-Passkey-Flow. Ablauf, Widerruf, Verlängerung und erneute Ausstellung von Freigaben sind implementiert.

Widerruf stoppt späteren Zugriff über die Dossira-Freigabe. Er kann keine Dateien löschen, die bereits außerhalb des Dienstes heruntergeladen oder kopiert wurden.

3. Transport- und Infrastrukturverschlüsselung

Die geprüften Produktions-Web- und API-Endpunkte verwenden HTTPS. Die geprüfte Service-Mesh-Konfiguration nutzt striktes mTLS zwischen Mesh-Diensten, und die aktuelle Infrastrukturdokumentation weist verschlüsselte Festplatten für Anwendungs-, Datenbank-, Objekt-Storage-, Failover- und Backup-Server aus.

Diese Kontrollen schützen Daten während der Übertragung und auf den zugrunde liegenden Serverfestplatten. Sie sind von optionaler clientseitiger Datei-Payload-E2EE getrennt und bedeuten nicht, dass jedes gespeicherte Objekt einen kundengesteuerten Anwendungsschlüssel verwendet.

4. Optionale E2EE-Grenze

Die Anwendung unterstützt optionale Workspace-E2EE im Store-first-Dateipfad für Datei-Payload-Upload, Vorschau und Download.

Wichtige Grenzen:

E2EE ist optional, nicht das Standardverhalten jedes Workspace;
sie schützt unterstützte Datei-Payload-Operationen, nicht alle Workspace-Daten;
Dateinamen und Ordnermetadaten bleiben außerhalb der E2EE-Grenze;
Gastfreigabe-Flows bieten noch keine gleichwertige E2EE-Unterstützung;
mirror-backed Dateioperationen verwenden nicht denselben E2EE-Pfad.

Die Website behauptet daher nicht, dass Dossira für Dateinamen, alle Metadaten oder gastgeteilte Inhalte blind ist.

Zugriff auf verschlüsselte Workspace-Schlüssel und Wiederherstellung hängen vom konfigurierten Mitglieder- und Workspace-Schlüssel-Flow ab und müssen für die Bereitstellung getestet werden. Dossira veröffentlicht keine universelle Anbieter-Wiederherstellungs-, Anbieterblindheits- oder geräteübergreifende Garantie.

5. Hosting-Grenze

Dossira wird von einem norwegischen Unternehmen angeboten. Kundendaten und Benutzeridentitäten werden auf Hetzner-Infrastruktur in Deutschland und Finnland gehostet. Dossira nutzt für dieses Hosting weder AWS noch Microsoft Azure oder Google Cloud.

Für Verantwortlichen-/Auftragsverarbeiterrollen, Dienstleister und Übermittlungsinformationen siehe die Datenschutzerklärung und den Auftragsverarbeitungsvertrag.

6. Aktivitätsaufzeichnungen und Audit-Aussagen

Das zugrunde liegende System behält enge operative Aufzeichnungen:

Ressourcen und hochgeladene Versionen behalten Ersteller- und Zeitstempelfelder;
Freigabetickets behalten Details zu Erstellung, Aktualisierung, Ablauf und Widerruf;
bestätigte E-Mail-Challenges behalten Sende-, Versuch-, Verbrauchs- und Invalidierungsstatus.

Das aktuelle Produkt stellt kein vollständiges kundenorientiertes Ereignisprotokoll und keinen Audit-Export bereit. Insbesondere hat dieses Audit keine dauerhaften, für Kunden sichtbaren Ereignisse für jeden Room-Eintrag, fehlgeschlagenen Eintrag, jede Dateivorschau, jeden Dateidownload, jede Mitgliedschaftsänderung, jede Versiegelungs-/Schließaktion oder jeden Export verifiziert.

Wir behaupten daher derzeit nicht, dass:

jeder Zugriff in einem kunden sichtbaren Protokoll erfasst wird;
jede Schlüsselaktion für Audits verfügbar ist;
ein vollständiger Aktivitätsdatensatz exportiert werden kann.

7. Room-Lifecycle und Versiegelung

Ein Lebenszyklus zum Versiegeln einer Room oder zum Schließen und Exportieren ist nicht implementiert. Es gibt derzeit keinen schreibgeschützten Übergang auf Room-Ebene, keine durch Versiegelung ausgelöste Versionssperre, kein Abschlussmanifest oder Export, keine Wiedereröffnungsaktion, keine Abrechnungsregel und keinen Versiegelungsakteur/-zeitstempel. Schreibgeschützter externer Gastzugriff ist eine Freigabefähigkeit, keine Room-Versiegelung.

Aktuelle Workspaces dürfen nicht als versiegelt, unveränderlich, manipulationssicher, dauerhaft oder rechtlich abschließend beschrieben werden.

8. Eine Schwachstelle melden

Wenn Sie glauben, eine Schwachstelle gefunden zu haben, nutzen Sie die Kontaktseite und kennzeichnen Sie den Bericht als sicherheitsbezogen. Fügen Sie einem ersten Bericht keine vertraulichen Kundeninhalte bei.