Doconut Viewer wird Teil der Sicherheitsgrenze Ihrer Anwendung, sobald es Verträge, Rechnungen, technische Zeichnungen oder Kundendaten anzeigt. Doconut liefert die Anzeige‑Schicht; die umgebende Anwendung muss weiterhin entscheiden, wer eine Datei öffnen darf, wo die Quelle gespeichert ist, wie lange abgeleitete Daten verfügbar bleiben und was für Untersuchungen protokolliert wird.

Ein geschütztes Dokument, umgeben von geschichteten Zugriffskontrollen und einem Prüfpfad

Der Artikel von Doconut zu sicheren Dokumentanzeige‑Praktiken beschreibt serverseitiges Rendering als eine Schicht in einem Defense-in-Depth‑Design. Dieser Beitrag konzentriert sich daher auf die Anwendungs‑Verantwortlichkeiten rund um Doconut und verweist für Implementierungsdetails auf die gepflegte Produktdokumentation.

Beginnen Sie mit einem Bedrohungsmodell

„Privat“ und „sicher“ sind keine Konfigurationen. Definieren Sie die Ereignisse, die Sie verhindern oder erkennen müssen, bevor Sie Kontrollen auswählen.

Risiko	Beispiel	Anwendungskontrolle
Unbefugter Zugriff	Ein Benutzer ändert einen Dokumenten‑Identifier in der URL	Objekt‑basierte Autorisierung bei jeder Anforderung
Mandanten‑Überschneidung	Ein gültiger Benutzer fordert die Datei eines anderen Kunden an	Mandanten‑Scope in die Autorisierungsentscheidung einbezogen
Quellen‑Exposition	Ein Speicherpfad oder die Originaldatei wird direkt zurückgegeben	Server‑gesteuerter Lookup‑ und Rendering‑Flow
Veralteter Zugriff	Ein Link bleibt nach Rollen‑ oder Falländerungen nutzbar	Kurze Sitzungsdauer plus erneute Autorisierungsprüfung
Übermäßige Aufbewahrung	Temporäre Eingaben oder Ausgaben häufen sich	Explizite Lebenszyklus‑Jobs mit beobachtbaren Ergebnissen
Sensibles Logging	Tokens oder Dateipfade erscheinen in Logs	Strukturierte Redaktion und nur Kennzeichen‑Telemetry

Priorisieren Sie Risiken nach den Dokumenten und Benutzern in Ihrem System. Eine öffentliche Broschüren‑Bibliothek und ein rechtliches Evidenz‑Portal sollten nicht dieselbe Richtlinie teilen, nur weil sie denselben Viewer verwenden.

Der rechtliche Dokument‑Review‑Anwendungsfall von Doconut ist ein nützliches Referenzbeispiel für die Rolle des Produkts innerhalb authentifizierter Fall‑, Vertrags‑, Evidenz‑ und Compliance‑Workflows. Er verdeutlicht zudem die architektonische Grenze: Berechtigungen, Speicher, Kundendaten und Geschäftsregeln bleiben nahe an der Host‑Anwendung.

Autorisieren Sie, bevor Sie das Dokument öffnen

Führen Sie Authentifizierung und objektbasierte Autorisierung durch, bevor Sie das Dokument mit Doconut öffnen. Der offizielle .NET 6‑ oder höher‑Einrichtungsleitfaden zeigt, wie der Viewer konfiguriert wird und wie ein serverseitiges Dokument geöffnet wird; platzieren Sie die Identität, den Mandanten und die Dokument‑Berechtigungsprüfungen Ihrer Anwendung vor diesem Produktschritt.

Wenden Sie dieselbe Autorisierungsregel für jede verwandte Operation an, die Ihre Anwendung bereitstellt, einschließlich Seiten, Thumbnails, Suche, Anmerkungen, Konvertierung, Download und Druck. Das Verstecken eines Buttons schützt die zugrunde liegende Anforderung nicht.

Vermeiden Sie es, einen Dateisystem‑Pfad, Speicher‑Schlüssel oder eine Remote‑URL direkt aus dem Browser zu akzeptieren. Lösen Sie eine anwendungs‑eigene Dokument‑ID zu ihrem Speicherort auf dem Server auf und prüfen Sie anschließend, ob das aufgelöste Objekt zum autorisierten Mandanten und Workflow gehört.

Trennen Sie den Viewer von der Speicher‑Richtlinie

Der Viewer sollte Ihre Aufbewahrungsfrist nicht bestimmen. Dokumentieren Sie jede Speicherklasse und den jeweiligen Eigentümer:

Quell‑Dokument — gesteuert durch Ihre primäre Inhalts‑ oder Aufzeichnungs‑Richtlinie.
Temporäre Arbeitsdateien — für die Verarbeitung erstellt und durch einen geplanten, beobachtbaren Lebenszyklus entfernt.
Gerenderte Seiten oder Caches — auf die minimal nützliche Lebensdauer begrenzt und wie die Quelle geschützt.
Exporte und druckfertige Dateien — nur erstellt, wenn der Benutzer die entsprechende Berechtigung besitzt.
Logs und Audit‑Ereignisse — enthalten Kennzeichen und Ergebnisse, nicht den Dokumenteninhalt oder Anmeldedaten.

Verschlüsselung in Bewegung und im Ruhezustand hängt von Ihrem Web‑Server, Speicher‑Provider, Schlüssel‑Management und Deployment‑Einstellungen ab. Verifizieren Sie diese Kontrollen in der tatsächlichen Umgebung; schließen Sie nicht daraus, dass ein Viewer‑Bibliothek sie impliziert.

Verwenden Sie kurzlebige Referenzen vorsichtig

Eine kurzlebige Referenz kann die Zeit für Replay‑Angriffe reduzieren, ersetzt aber nicht die Autorisierung. Wenn Ihr Design eine signierte Route oder ein Sitzungs‑Token nutzt:

Binden Sie es an ein Dokument und die beabsichtigte Operation.
Geben Sie ihm eine enge Lebensdauer, die sich nach dem Workflow richtet.
Platzieren Sie keine sensiblen Ansprüche oder Speicherorte im Klartext.
Validieren Sie die Autorisierung für privilegierte Operationen erneut.
Definieren Sie, was Widerruf bedeutet, bevor die natürliche Ablaufzeit erreicht ist.
Halten Sie Tokens aus Analysen, Referrern, Ausnahme‑Meldungen und Screenshots heraus.

Wenn eine Browsersitzung abläuft, zeigen Sie eine neutrale Meldung und bieten Sie einen sicheren Weg zur erneuten Authentifizierung an. Geben Sie nicht preis, ob ein anderer Mandant das Dokument besitzt.

Verstehen Sie, was clientseitige Kontrollen können und nicht können

Das Entfernen von Download‑ oder Druck‑Steuerelementen kann den gewünschten Workflow verbessern, ist jedoch keine Vertraulichkeitsgarantie. Ein Benutzer, der den Inhalt sehen kann, kann dennoch den Bildschirm aufnehmen, fotografieren oder Browser‑Funktionen außerhalb des Viewers nutzen.

Betrachten Sie clientseitige Einschränkungen als Usability‑ und Abschreckungs‑Maßnahmen. Stärkere Kontrollen ergeben sich aus dem Verbleib der Quelldateien hinter dem Server, der Anwendung von Autorisierung auf jede zugehörige Anforderung, der Begrenzung von Exporten und dem Einsatz sichtbarer Wasserzeichen, wenn Ihre Richtlinie dies vorsieht.

Verwandeln Sie Produkt‑Features nicht in Compliance‑Behauptungen

Regulatorische Compliance hängt von Zweck, Datenkategorien, Rechtsgrundlage, Verträgen, regionaler Verarbeitung, Aufbewahrung, Incident‑Response und organisatorischen Verfahren ab. Ein Viewer kann ein konformes Design unterstützen, macht eine Anwendung jedoch nicht von selbst konform.

Für eine DSGVO‑Bewertung dokumentieren Sie mindestens:

Wo Quell‑ und abgeleitete Dateien verarbeitet und gespeichert werden
Wer als Verantwortlicher und Auftragsverarbeiter für jeden Dienst auftritt
Welche Unter‑Auftragsverarbeiter und Datenübertragungen beteiligt sind
Wie Löschanfragen jede Speicherklasse und Backup‑Richtlinie erreichen
Welche Ereignisse protokolliert werden und wie lange Logs verfügbar bleiben
Wie Zugriffs‑Reviews und Incident‑Response durchgeführt werden

Lassen Sie Datenschutz‑ und Rechtsexperten diese Entscheidungen für Ihre Bereitstellung validieren.

Fügen Sie Sicherheits‑Header und Cache‑Regeln hinzu

Für authentifizierte Vorschau‑Routen sollten Sie eine restriktive Content‑Security‑Policy, Frame‑Policy, MIME‑Sniffing‑Schutz und Referrer‑Policy evaluieren. Wenn die Vorschau in einem iframe erscheint, machen Sie die beabsichtigten übergeordneten Ursprünge explizit.

Wählen Sie Cache‑Header nach Sensitivität und Rendering‑Route. no-store kann für manche Antworten passend sein, kann jedoch die Performance beeinflussen und löscht nicht bereits anderweitig erfasste Inhalte. Testen Sie das Verhalten von Browser, Proxy und CDN, anstatt sich ausschließlich auf einen Header zu verlassen.

Protokollieren Sie Entscheidungen, nicht Geheimnisse

Ein nützliches Audit‑Ereignis könnte enthalten:

Benutzer‑ und Mandanten‑Kennzeichen
Dokumenten‑Identifier
Angeforderte Operation
Ergebnis der Autorisierung
Zeitstempel und Korrelations‑ID
Aufbewahrungs‑ oder Bereinigungs‑Ergebnis

Vermeiden Sie das Protokollieren von Roh‑Tokens, Query‑Strings, Speicher‑URLs, Dokumentnamen mit personenbezogenen Daten oder extrahiertem Text. Schützen Sie Audit‑Logs vor Manipulation und beschränken Sie den Zugriff auf die Teams, die sie benötigen.

Verifizieren Sie den kompletten Ablauf

Sicherheitstests sollten negative Fälle einschließen:

Ändern Sie die Dokument‑ID, während Sie authentifiziert bleiben.
Wiederverwenden Sie eine Vorschau‑URL von einem anderen Benutzer oder Mandanten.
Rufen Sie Seiten‑, Thumbnail‑, Druck‑ und Export‑Endpunkte direkt auf.
Lassen Sie die Sitzung während einer langen Vorschau ablaufen.
Entfernen Sie die Berechtigung eines Benutzers, während ein Dokument geöffnet ist.
Senden Sie nicht unterstützte, zu große, beschädigte oder passwortgeschützte Eingaben.
Bestätigen Sie, dass Bereinigungs‑Jobs berechtigte Daten entfernen und Fehler melden.
Untersuchen Sie Logs, Analysen und Fehlermeldungen auf sensible Werte.

Automatisieren Sie die stabilen Fälle und behalten Sie eine manuelle Prüfung für Speicher‑Konfiguration, Browser‑Richtlinien und Viewer‑Version‑Änderungen bei.

Fazit

Eine sicherheitsbewusste Integration hat klare Eigentumsverhältnisse. Doconut liefert die Dokument‑Anzeige‑Funktionalität, wie in seiner offiziellen Dokumentation beschrieben; Ihre Anwendung liefert Authentifizierung, Autorisierung, Speicher‑Kontrollen, Aufbewahrung, Monitoring und Incident‑Response. Diese Verantwortlichkeiten explizit zu halten, erzeugt stärkere Kontrollen und ehrlichere Datenschutz‑Behauptungen.