Introduzione

La conversione di file pubblica è comoda, ma non è priva di questioni di sicurezza. I dati possono trapelare, la conservazione può essere poco chiara, gli obblighi di conformità possono aumentare e i file dannosi possono colpire parser complessi. Per i team .NET, queste preoccupazioni dovrebbero essere affrontate prima che un convertitore esterno diventi parte di un flusso di lavoro aziendale.

Doconut offre un visualizzatore .NET auto‑ospitato e un flusso di lavoro di conversione che può mantenere l'elaborazione dei documenti supportati all'interno dell'infrastruttura controllata dal proprietario dell'applicazione. Questo può ridurre la dipendenza da un convertitore pubblico, ma l'applicazione deve comunque implementare il controllo degli accessi, il trasporto sicuro, la politica di archiviazione, la pulizia, gli aggiornamenti e il monitoraggio.

Punti di controllo di sicurezza tra un documento confidenziale, un convertitore pubblico e un ambiente Windows controllato

Conversione sicura di file e crittografia per le app .NET

Perché la crittografia è importante

Quando lanci un file a un convertitore cloud, deve viaggiare su Internet pubblico. Se il trasporto non è bloccato, un hacker può inserirsi nel mezzo e rubare i dati—lo classico attacco “man‑in‑the‑middle”. Anche con HTTPS, molti strumenti gratuiti conservano comunque il file su un server condiviso senza crittografia aggiuntiva, lasciandolo esposto a minacce interne o a bucket di archiviazione mal configurati.

Cosa fanno realmente i due prodotti Doconut

Rispondono in modo diverso, e confonderli è il modo in cui le persone finiscono con un progetto di sicurezza che non regge.

Il Doconut SDK è installato nel tuo ambiente. Il rendering avviene sul tuo server, e il componente non effettua chiamate verso Doconut. Questo è l’intero argomento di sicurezza, ed è molto solido: il file non attraversa mai un confine che non controlli, quindi non c’è alcuna domanda di conservazione da parte di terzi a cui rispondere.

Ciò che l'SDK non fa è crittografare la tua archiviazione per te. Non esiste una funzionalità AES‑256‑at‑rest, né gestione delle chiavi e né log di audit integrato. Queste sono responsabilità della tua piattaforma, e quasi certamente le hai già—e questo è il punto. Chiunque affermi che una libreria di visualizzazione renda la tua applicazione pronta per l’audit sta vendendoti qualcosa.

Doconut.app è il nostro sito gratuito ospitato, ed è un vero upload: il file raggiunge i nostri server, viene renderizzato lì e viene eliminato al termine della sessione di visualizzazione. Il trasporto è HTTPS. Non c’è alcun account e nulla viene conservato successivamente. Per un documento che potresti leggere tranquillamente su un treno, va bene; per dati regolamentati non lo è, e preferiamo dirlo apertamente.

Eliminazione automatica dei file e gestione del ciclo di vita

Il pericolo nascosto dei file residui

Molti convertitori cloud promettono “eliminazione automatica dopo la conversione”, ma la definizione di “dopo” varia ampiamente. Alcuni servizi conservano i file per ore, giorni o addirittura settimane, creando una finestra in cui documenti confidenziali potrebbero essere accessibili da personale non autorizzato o recuperati tramite analisi forense. Per le imprese che gestiscono contratti, progetti di design o dati personali, quella finestra è inaccettabile.

La risposta definitiva di Doconut App

Su Doconut.app – Il file esiste per la durata della sessione di visualizzazione e viene eliminato al termine. Non esiste alcuna impostazione di conservazione da configurare, perché non ci sono account né amministratori; la tempistica è nostra. La stampa è disponibile per chiunque visualizzi, tramite Ctrl+P.
Nell'SDK – Il ciclo di vita è tuo. Il componente scrive l'output di rendering temporaneo in un luogo che configuri, e tu sei responsabile della pulizia. Questo è il passo più frequentemente saltato in un'integrazione, e i file di rendering orfani in una directory temporanea sono esattamente il problema dei file fantasma di cui avverte questa sezione. Controlla dove scrive e programma la pulizia.
La stampa controllata è parte del visualizzatore piuttosto che di un plugin separato, quindi limitare stampa e download per ruoli specifici è una questione di configurazione e permessi all'interno della tua applicazione.

Visualizzazione cloud‑based pronta per la conformità per settori regolamentati

Pressioni normative

Sanità (HIPAA), finanza (PCI DSS) e governo (FedRAMP) impongono tutti regole rigorose su come i dati vengono trasmessi, archiviati e distrutti. Un convertitore cloud che memorizza i file su un server multi‑tenant condiviso può rapidamente trasformarsi in un incubo di conformità, richiedendo costosi processi di eccezione o l'abbandono totale dello strumento.

Dove si colloca Doconut, dichiarato chiaramente

Non possediamo certificazioni. Nessun ISO 27001, nessun SOC 2, nessuna attestazione HIPAA, nessuna valutazione PCI DSS, nessuna autorizzazione FedRAMP. Né i siti gratuiti né l'SDK. Se un questionario del fornitore richiede un certificato, la risposta onesta è che non ne abbiamo uno da fornire.

Nessun componente software può rendere la tua applicazione conforme in alcun caso. Questi framework chiedono informazioni su processi, controllo degli accessi, conservazione, evidenze e persone. Una libreria di rendering è un controllo tra le decine.

Ciò che l'SDK offre in un ambiente regolamentato è più architetturale che documentale: poiché gira all'interno della tua infrastruttura e non chiama nulla di esterno, il documento non lascia mai il perimetro che hai già valutato. Per la maggior parte delle revisioni questa è la risposta più utile rispetto a un certificato appartenente a qualcun altro, ed è quella che puoi dimostrare autonomamente.

Doconut.app è il caso opposto e dovrebbe essere trattato come tale: un sito pubblico, infrastruttura condivisa, nessun contratto, nessun DPA e nessun BAA. Non inserire dati regolamentati attraverso di esso.

Prevenire malware e iniezione di codice nella conversione online di documenti

La minaccia nascosta dei payload dannosi

Formati di file come PDF, Office e CAD possono incorporare script, macro o dati malformati che attivano exploit in motori di rendering vulnerabili. Un servizio cloud che elabora file su un server condiviso può eseguire involontariamente codice dannoso, compromettendo il servizio e qualsiasi cliente a valle.

Come il modello di rendering influisce su questo

Sii preciso su dove avviene l'analisi, perché il modello di minaccia dipende interamente da questo: Doconut rende lato server. Il documento viene analizzato sul server e il browser riceve pagine renderizzate. Non è un visualizzatore WebAssembly lato client.

Ciò che ne consegue:

Il browser non è la superficie di attacco – nessun plugin, nessun ActiveX, e la macchina dell'utente non riceve mai il file sorgente, solo l'output renderizzato.
Il server è la superficie, ed è il tuo server quando esegui l'SDK. Un parser che elabora input non attendibili è un parser che elabora input non attendibili; eseguilo con i minimi privilegi, mantienilo aggiornato e tratta i byte caricati come ostili. Il vantaggio rispetto a un convertitore pubblico è che questa è la tua isolamento da progettare e verificare, non un'affermazione che devi accettare sulla base della fiducia.
Il rendering non è esecuzione – le macro in un .docm o .xlsm non vengono eseguite, e gli script in un PDF non sono eseguiti. Il visualizzatore disegna il documento.
L'elenco delle estensioni è una whitelist – i visualizzatori gratuiti accettano più di 70 estensioni e rifiutano tutto il resto al caricamento.

Niente di tutto ciò sostituisce la scansione dei caricamenti se la tua valutazione del rischio lo richiede. Aggiungi quel livello tu stesso; il visualizzatore non include la scansione dei malware.

Un visualizzatore che si adatta agli stili consolidati delle applicazioni .NET

La sfida dell'integrazione

Le aziende spesso utilizzano un mix di applicazioni ASP.NET Core, MVC, WebForms e più recenti applicazioni Blazor. Aggiungere un visualizzatore di terze parti solitamente significa destreggiarsi tra librerie JavaScript, gestire la compatibilità dei plugin e combattere le stranezze dei browser. Ogni dipendenza aggiuntiva introduce una nuova superficie di attacco e un onere di manutenzione.

Cosa fa l'SDK al riguardo

Zero‑plugin, puro HTML5 – Funziona su tutti i browser moderni (Chrome, Edge, Firefox, Safari) senza installare nulla sulla macchina client.
Integrazione Blazor – Coordina lo stato del visualizzatore da un componente mantenendo l'accesso ai file e l'elaborazione sul server. Segui la documentazione per la versione SDK installata.
UI personalizzabile – La barra degli strumenti, i colori e il branding del visualizzatore possono essere adattati per corrispondere alla tua applicazione, così da apparire come parte del tuo prodotto piuttosto che una finestra su quello di qualcun altro. Prendi i nomi delle opzioni dalla documentazione per la versione che hai installato.

Incorporare il visualizzatore

Aggiungi il pacchetto Doconut supportato, applica l'autorizzazione dei documenti nell'applicazione ASP.NET e inizializza il visualizzatore usando la documentazione ufficiale per quella versione. Non presumere che trasporto, crittografia, cancellazione o permessi UI siano automatici; verifica e configura ogni controllo nell'architettura distribuita.

Integrazione Blazor e valutazione

Doconut può partecipare ai flussi di lavoro delle applicazioni Blazor, ma il modello di componenti esatto e la configurazione dipendono dalla versione SDK installata. L'autenticazione, il trasporto sicuro, la protezione dell'archiviazione, la pulizia e l'isolamento dei processi devono essere verificati nell'architettura completa distribuita, piuttosto che presumere che siano abilitati automaticamente.

Per la valutazione, la pagina di download contiene la licenza di prova e la documentazione; i termini e ciò che include ogni edizione sono sulla pagina dei prezzi piuttosto che riassunti qui, dove potrebbero diventare obsoleti.

Se quello che vuoi prima è vedere come viene renderizzato un file particolarmente ingombrante, Doconut.app esegue lo stesso motore su un file alla volta, gratuitamente — e lo elimina successivamente.

Punti chiave

La proprietà di sicurezza dell'SDK è architetturale – funziona nel tuo ambiente e non chiama nulla di esterno, quindi il documento non lascia mai il tuo perimetro. Non include crittografia a riposo, gestione delle chiavi o registri di audit; questi rimangono a te.
Doconut.app è un vero upload – HTTPS in ingresso, renderizzato sui nostri server, eliminato al termine della sessione, senza account. Va bene per un file ordinario, ma non per dati regolamentati.
La conformità non è integrata – non possediamo certificazioni ISO 27001, SOC 2, HIPAA, PCI DSS o FedRAMP, e nessun componente può conferirne una.
Il rendering è lato server, non WebAssembly – il browser riceve pagine, mai il file sorgente. Il rendering non è esecuzione, quindi le macro non vengono eseguite.
Pulisci la tua directory temporanea – in una distribuzione self‑hosted, l'output di rendering orfano rappresenta il reale rischio di file fantasma.
Esperienza browser senza plugin – si integra con ASP.NET Core, MVC, WebForms e i flussi di lavoro Blazor.
Valuta nel tuo ambiente – la qualità del rendering è gratuita da verificare su Doconut.app; tutto il resto richiede la versione di prova sui tuoi server.

Domande comuni

D: Doconut.app conserva una copia del mio documento dopo la visualizzazione?
R: No. Viene renderizzato in una sessione temporanea legata al tuo browser e cancellato dai nostri server al termine della sessione. Non esiste alcun account a cui associarlo né alcuna libreria in cui potrebbe riapparire. In una distribuzione SDK self‑hosted la domanda equivalente riguarda la tua directory temporanea, e la risposta dipende dalla pulizia che configuri.

D: Posso abilitare il download o la stampa per utenti specifici?
R: Nell'SDK, sì — i controlli del visualizzatore sono configurabili e la stampa controllata fa parte del visualizzatore, non è un plugin aggiuntivo, quindi puoi concedere tali diritti per ruolo dalla tua applicazione. Sul sito gratuito di Doconut.app non ci sono ruoli né API: chiunque visualizzi può stampare con Ctrl+P.

D: Come gestisce file CAD di grandi dimensioni o immagini ad alta risoluzione?
R: Il motore renderizza DWG, DXF, DGN, PSD, TIFF e DNG dalla geometria e dai dati pixel anziché da un'anteprima incorporata, applica i profili ICC incorporati e consente di disattivare i layer CAD e misurare distanze e aree. Sul sito gratuito si applicano i limiti: 10 MB per CAD, che i disegni emessi superano, e 25 MB per PSD, TIFF e immagini. In modalità self‑hosted, il limite è la memoria del tuo server.

D: Il visualizzatore è compatibile con i browser mobili?
R: Sì. Poiché il rendering avviene sul server e il browser riceve HTML e immagini ordinari, funziona su iOS Safari, Android Chrome e qualsiasi browser mobile moderno — e un dispositivo poco potente non è uno svantaggio, poiché non esegue il lavoro.

D: Quanto costa?
R: Doconut.app è gratuito, senza livelli a pagamento, senza account e senza prova da scadere — questo è l'intero modello. L'SDK è una licenza commerciale con una prova gratuita; le edizioni attuali e i prezzi sono sulla pagina dei prezzi, che è l'autorità rispetto a questo articolo.

Considerazioni finali

Quando integri un convertitore di file basato su cloud in un'applicazione .NET aziendale, l'esposizione dei dati, i cicli di vita dei file incerti, le lacune di conformità e i payload dannosi sono rischi reali. Un flusso di lavoro Doconut self‑hosted può offrire ai team .NET basati su Windows un maggiore controllo su elaborazione e archiviazione, mentre l'applicazione circostante rimane responsabile della progettazione completa della sicurezza.

Decidere tra i due? Se i documenti sono ordinari, Doconut.app ne aprirà subito uno gratuitamente. Se non lo sono, l'argomento a favore dell'SDK è che il file rimane sui tuoi server — e il lavoro di dimostrarlo a un revisore resta a te, che è l'unica versione di questo che sopravvive a una vera revisione di sicurezza.