Doconut Viewer diventa parte del perimetro di sicurezza della tua applicazione non appena visualizza contratti, fatture, disegni tecnici o registri dei clienti. Doconut fornisce lo strato di visualizzazione; l'applicazione circostante deve comunque decidere chi può aprire un file, dove è archiviata la sorgente, per quanto tempo i dati derivati rimangono disponibili e cosa viene registrato per le indagini.

L'articolo di Doconut su pratiche sicure di visualizzazione dei documenti descrive il rendering lato server come uno strato in un design a difesa in profondità. Questo articolo si concentra quindi sulle responsabilità dell'applicazione intorno a Doconut e indirizza i dettagli di implementazione alla documentazione del prodotto mantenuta.
Inizia con un modello di minaccia
“Private” e “secure” non sono configurazioni. Definisci gli eventi che devi prevenire o rilevare prima di scegliere i controlli.
| Rischio | Esempio | Controllo dell'applicazione |
|---|---|---|
| Accesso non autorizzato | Un utente modifica un identificatore del documento nell'URL | Autorizzazione a livello di oggetto su ogni richiesta |
| Cross-over tra tenant | Un utente valido richiede il file di un altro cliente | Ambito del tenant incluso nella decisione di autorizzazione |
| Esposizione della sorgente | Un percorso di archiviazione o il file originale viene restituito direttamente | Flusso di ricerca e rendering controllato dal server |
| Accesso obsoleto | Un link rimane utilizzabile dopo che un ruolo o un caso è cambiato | Durata breve della sessione più rivalidazione dell'autorizzazione |
| Conservazione eccessiva | Input o output temporanei si accumulano | Job di ciclo di vita espliciti con risultati osservabili |
| Log sensibili | Token o percorsi dei file appaiono nei log | Redazione strutturata e telemetria solo con identificatori |
Prioritizza i rischi in base ai documenti e agli utenti nel tuo sistema. Una biblioteca di brochure pubbliche e un portale di prove legali non dovrebbero condividere la stessa politica solo perché usano lo stesso visualizzatore.
Il caso d'uso di Doconut per la revisione di documenti legali è un riferimento utile per il ruolo del prodotto all'interno di flussi di lavoro autenticati di casi, contratti, prove e conformità. Rafforza inoltre il confine architetturale: permessi, archiviazione, registri dei clienti e regole di business rimangono vicini all'applicazione host.
Autorizza prima di aprire il documento
Esegui l'autenticazione e l'autorizzazione a livello di oggetto prima di aprire il documento con Doconut. La guida di configurazione .NET 6 o superiore mostra come il visualizzatore è configurato e come un documento lato server è aperto; inserisci l'identità della tua applicazione, il tenant e i controlli di permesso del documento prima di quel passaggio del prodotto.
Ripeti la stessa regola di autorizzazione per ogni operazione correlata che la tua applicazione espone, incluse pagine, miniature, ricerca, annotazioni, conversione, download e stampa. Nascondere un pulsante non protegge la richiesta sottostante.
Evita di accettare un percorso di file system, una chiave di archiviazione o un URL remoto direttamente dal browser. Risolvi un ID documento di proprietà dell'applicazione nella sua posizione di archiviazione sul server, quindi conferma che l'oggetto risolto appartenga al tenant e al flusso di lavoro autorizzati.
Separare il visualizzatore dalla politica di archiviazione
Il visualizzatore non dovrebbe definire il tuo periodo di conservazione. Documenta ogni classe di archiviazione e proprietario:
- Documento sorgente — controllato dalla tua politica primaria di contenuti o registri.
- File di lavoro temporanei — creati per l'elaborazione e rimossi da un ciclo di vita programmato e osservabile.
- Pagine renderizzate o cache — limitate alla durata minima utile e protette come la sorgente.
- Esportazioni e file pronti per la stampa — creati solo quando l'utente ha l'autorizzazione corrispondente.
- Log ed eventi di audit — contengono identificatori e risultati, non il contenuto del documento o credenziali.
La crittografia in transito e a riposo dipende dal tuo server web, provider di archiviazione, gestione delle chiavi e impostazioni di distribuzione. Verifica tali controlli nell'ambiente reale; non inferirli dalla presenza di una libreria di visualizzatore.
Usa con attenzione riferimenti a breve durata
Un riferimento a breve durata può ridurre il tempo disponibile per un replay, ma non sostituisce l'autorizzazione. Se il tuo design utilizza una rotta firmata o un token di sessione:
- Associare a un documento e all'operazione prevista.
- Assegnargli una durata limitata basata sul flusso di lavoro.
- Evitare di inserire claim sensibili o percorsi di archiviazione in chiaro.
- Rivalidare l'autorizzazione per operazioni privilegiate.
- Definire cosa significa revoca prima della scadenza naturale.
- Mantenere i token fuori da analytics, referrer, messaggi di eccezione e screenshot.
Quando una sessione del browser scade, mostra un messaggio neutro e offri un modo sicuro per ri‑autenticarsi. Non esporre se un altro tenant possiede il documento.
Comprendere cosa i controlli lato client possono e non possono fare
Rimuovere i controlli di download o stampa può migliorare il flusso di lavoro previsto, ma non garantisce la riservatezza. Un utente che può vedere il contenuto può comunque catturare lo schermo, fotografarlo o usare funzionalità del browser al di fuori del visualizzatore.
Considera le restrizioni lato client come misure di usabilità e deterrenza. Controlli più forti derivano dal mantenere i file sorgente dietro il server, applicare l'autorizzazione a ogni richiesta correlata, limitare le esportazioni e usare filigrane visibili quando la tua politica lo richiede.
Non trasformare le funzionalità del prodotto in affermazioni di conformità
La conformità normativa dipende dallo scopo, dalle categorie di dati, dalla base legale, dai contratti, dal trattamento regionale, dalla conservazione, dalla risposta agli incidenti e dalle procedure organizzative. Un visualizzatore può supportare un design conforme, ma non rende l'applicazione conforme da solo.
Per una valutazione GDPR, documenta almeno:
- Dove i file sorgente e derivati sono elaborati e archiviati
- Chi agisce come titolare e responsabile del trattamento per ogni servizio
- Quali sub‑responsabili e trasferimenti sono coinvolti
- Come le richieste di cancellazione raggiungono ogni classe di archiviazione e la politica di backup
- Quali eventi sono registrati e per quanto tempo i log rimangono disponibili
- Come vengono eseguite le revisioni di accesso e la risposta agli incidenti
Fai convalidare queste decisioni da stakeholder di privacy e legali per il tuo deployment.
Aggiungi intestazioni di sicurezza e regole di cache
Per le rotte di anteprima autenticate, valuta una Content Security Policy restrittiva, una policy di framing, protezione MIME‑sniffing e una policy di referrer. Se l'anteprima appare dentro un iframe, rendi esplicite le origini genitore previste.
Scegli le intestazioni di cache in base alla sensibilità e al percorso di rendering. no-store può essere appropriato per alcune risposte, ma può influire sulle prestazioni e non elimina contenuti già catturati altrove. Testa il comportamento di browser, proxy e CDN invece di fare affidamento su un'intestazione isolata.
Registra decisioni, non segreti
Un evento di audit utile potrebbe contenere:
- Identificatori di utente e tenant
- Identificatore del documento
- Operazione richiesta
- Risultato dell'autorizzazione
- Timestamp e ID di correlazione
- Esito della conservazione o della pulizia
Evita di registrare token grezzi, stringhe di query, URL di archiviazione, nomi di documento contenenti dati personali o testo estratto. Proteggi i log di audit da modifiche e limita l'accesso ai team che ne hanno bisogno.
Verifica il flusso completo
I test di sicurezza dovrebbero includere casi negativi:
- Modificare l'ID del documento rimanendo autenticati.
- Riutilizzare un URL di anteprima da un altro utente o tenant.
- Chiamare direttamente gli endpoint di pagina, miniatura, stampa ed esportazione.
- Scadere la sessione durante un'anteprima lunga.
- Rimuovere il permesso di un utente mentre un documento è aperto.
- Inviare input non supportati, troppo grandi, danneggiati o protetti da password.
- Confermare che i job di pulizia rimuovano i dati idonei e segnalino i fallimenti.
- Ispezionare log, analytics e pagine di errore per valori sensibili.
Automatizza i casi stabili e mantieni una revisione manuale per la configurazione di archiviazione, la policy del browser e le modifiche alla versione del visualizzatore.
Conclusione
Un'integrazione attenta alla sicurezza ha una chiara proprietà. Doconut fornisce la capacità di visualizzazione dei documenti descritta dalla sua documentazione ufficiale; la tua applicazione fornisce autenticazione, autorizzazione, controlli di archiviazione, conservazione, monitoraggio e risposta agli incidenti. Tenere esplicite queste responsabilità produce controlli più forti e affermazioni sulla privacy più oneste.