Proteggi i documenti Collabora CODE a riposo con la crittografia dell'archiviazione.

Per crittografare i documenti a riposo quando si utilizza Collabora Online Development Edition (CODE), è necessario abilitare la crittografia nella piattaforma di archiviazione file o sul disco sottostante, non nell'editor CODE. Collabora apre i documenti forniti da un host di archiviazione WOPI, mentre l'host è responsabile della protezione delle copie salvate. Il risultato dovrebbe essere un'archiviazione crittografata, modifiche funzionanti e file recuperabili.

Identifica il sistema che effettivamente memorizza i file

Una tipica implementazione utilizza Nextcloud o un altro servizio compatibile con WOPI per l'archiviazione dei file e CODE per la modifica tramite browser. Un documento viene spostato tra questi componenti durante una sessione di modifica autorizzata; l'attivazione di HTTPS protegge la connessione ma non crittografa la copia memorizzata. La panoramica sulla sicurezza di Collabora descrive l'archiviazione come controllata dall'integrazione, mentre il suo modello di configurazione del server documenta WOPI, TLS e le impostazioni opzionali di cache e quarantena.

Prima di apportare qualsiasi modifica, annota dove l'host WOPI scrive i file dei documenti, se utilizza dischi locali o storage a oggetti esterno e dove viene eseguito CODE. Includi backup, snapshot, anteprime, swap e volumi dei container: le copie al di fuori della directory principale potrebbero rimanere non protette.

Scegliete una crittografia adeguata al rischio.

Per i documenti presenti sul disco locale di un server Linux, la crittografia del disco o del volume, ad esempio tramite LUKS, è solitamente l'opzione più semplice. Protegge l'archiviazione sottostante quando il volume è bloccato, anche contro il furto di un'unità spenta. La documentazione di Ubuntu sulla crittografia completa del disco descrive LUKS come una crittografia a livello di blocco, non come un'impostazione dell'applicazione. Utilizzare un nuovo volume crittografato o una migrazione testata: l'inizializzazione di LUKS può causare la perdita di dati esistenti.

Se Nextcloud archivia i file su storage di terze parti e il provider di storage non deve poter leggere il loro contenuto, la crittografia lato server (SSE) di Nextcloud potrebbe essere la soluzione migliore. Questa tecnologia crittografa il contenuto dei file supportati prima di salvarli nello storage di backend. Le chiavi rimangono in Nextcloud, quindi un server o un amministratore compromesso può accedere ai file decrittografati. Nextcloud consiglia di valutare la crittografia del disco per lo storage locale.

Se persino l'amministratore dell'applicazione non è in grado di leggere un documento, né la crittografia del disco sbloccato né la normale crittografia SSE soddisfano tale requisito. Valutare un flusso di lavoro di crittografia lato client o end-to-end supportato e verificare che la modifica tramite browser rimanga disponibile; non dare per scontato che ogni documento crittografato possa essere aperto in modo collaborativo in CODE.

Abilitare la crittografia sull'host di archiviazione

Opzione A: Crittografare il volume locale

Per una nuova implementazione Linux, eseguire il provisioning dei dati dei file e dei volumi di servizio pertinenti su storage crittografato prima di importare i documenti. Conservare la chiave segreta di sblocco e le informazioni di ripristino al di fuori del server, limitare l'accesso amministrativo e testare la procedura di riavvio o di sblocco. Per i sistemi esistenti, verificare i backup ed eseguire la migrazione durante i periodi di inattività. Configurare la crittografia per i volumi cloud o lo storage a oggetti con il provider.

Utilizzare questo strumento lsblk -fper identificare i tipi di dispositivi a blocchi e findmnt -T /path/to/document/datail filesystem che supporta la directory dati effettiva. Verificare il percorso dalla directory dati al dispositivo crittografato: la cryptsetupsola installazione non crittografa un filesystem.

Opzione B: Abilitare la crittografia lato server di Nextcloud

Quando Nextcloud SSE è appropriato, segui la relativa guida alla crittografia lato server . Esegui il backup della configurazione di Nextcloud, del database, dei file e delle chiavi di crittografia prima di apportare modifiche. Decidi la modalità della chiave prima di crittografare il contenuto; la guida attuale descrive una chiave master controllata dal server come impostazione predefinita per la maggior parte delle implementazioni.

1. Abilita il modulo di crittografia predefinito di Nextcloud nelle app, quindi abilita la crittografia lato server nelle impostazioni di amministrazione oppure utilizza i occcomandi documentati.
2. Su un'installazione Linux convenzionale, esegui i comandi dalla directory di installazione di Nextcloud come account del server web: sudo -E -u www-data php occ app:enable encryption, quindi sudo -E -u www-data php occ encryption:enable. Adatta l'utente e il metodo di esecuzione al tuo pacchetto; le implementazioni Docker utilizzano i comandi all'interno del container appropriato.
3. Eseguire il programma sudo -E -u www-data php occ encryption:statusper confermare la funzionalità e il modulo selezionato. Non interpretare un flag di attivazione come prova che ogni file preesistente sia crittografato.
4. Pianifica una finestra di manutenzione senza accesso ai file utente ed esegui l'operazione sudo -E -u www-data php occ encryption:encrypt-allper risolvere i problemi relativi ai file preesistenti. Questa operazione può richiedere tempo e la documentazione ufficiale dei comandi di crittografia specifica che gestisce la modalità di manutenzione e richiede un terminale interattivo.

SSE esclude nomi di file, cartelle, file presenti nel cestino, alcune versioni precedenti, miniature, anteprime, indici di ricerca e determinati dati dell'applicazione. Se necessario, proteggere separatamente gli elementi esclusi. Proteggere i backup delle chiavi di crittografia; la perdita di chiavi essenziali o segreti di istanza può impedire definitivamente il ripristino.

Proteggi l'host di CODE e mantieni sicuro il percorso di modifica

Anche quando l'host WOPI crittografa i documenti archiviati, è necessario valutare la macchina CODE in modo indipendente. Collabora descrive la gestione attiva dei documenti come orientata alla memoria e non posiziona CODE come repository permanente dei documenti. Tuttavia, il coolwsd.xmlmodello pubblicato include impostazioni per la quarantena e i file memorizzati nella cache opzionali, quindi è consigliabile esaminare l'implementazione effettiva anziché presumere l'assenza di ogni artefatto temporaneo. Proteggere l'archiviazione runtime del container, i volumi montati, lo swap di sistema, i dump di arresto anomalo e i backup con controlli di crittografia o conservazione appropriati.

Mantieni il protocollo HTTPS tra i browser, CODE e il servizio WOPI e limita gli host WOPI che possono connettersi. La documentazione di configurazione di Nextcloud per Office raccomanda di limitare le richieste WOPI agli indirizzi IP previsti per i server Collabora. Questi controlli di accesso non sostituiscono la crittografia dei dati a riposo, ma contribuiscono a impedire che il sistema di archiviazione crittografato consegni il testo in chiaro a un utente non autorizzato.

Non abilitare la modalità di archiviazione su file system locale di Collabora per l'ambiente di produzione come scorciatoia; il suo SDK ufficiale descrive l'archiviazione su file system come un'opzione da utilizzare solo per i test e raccomanda WOPI. Mantieni attiva la normale integrazione con i sistemi di archiviazione in modo che il comportamento di autorizzazione e salvataggio rimanga coerente.

Verifica se il risultato è sufficientemente buono

Per il test di accettazione, utilizzare un file di esempio non sensibile. Caricarlo tramite il servizio di archiviazione, aprirlo in CODE, modificare una riga, salvare, chiudere l'editor e riaprirlo. Un'operazione di andata e ritorno andata a buon fine conferma che la modifica funziona ancora; non dimostra la crittografia dei dati a riposo.

• Prova di archiviazione: verificare che la directory dei documenti effettiva corrisponda al volume crittografato previsto o che il servizio di archiviazione segnali la configurazione di crittografia prevista. Per SSE, verificare se i dati memorizzati nel backend risultano illeggibili senza le chiavi dell'applicazione di archiviazione, utilizzando un test controllato e un accesso autorizzato al backend.
• Copertura dei file precedenti: confermare la migrazione o encryption:encrypt-allil completamento con successo; non testare solo un file appena caricato.
• Copie secondarie: verificare che backup, snapshot, dati di anteprima, registri e spazio di archiviazione dell'host CODE soddisfino gli stessi requisiti di protezione.
• Recuperabilità: ripristinare un campione e le relative chiavi necessarie in un ambiente di test separato, quindi verificare che il documento si apra e si salvi tramite CODE.

Si ricorre a soluzioni alternative qualora il provider di archiviazione o l'applicazione non siano in grado di decrittografare i contenuti, se una categoria di dati protetti rimane al di fuori del perimetro di crittografia o se non è possibile dimostrare il recupero della chiave. La crittografia dei dati a riposo limita principalmente l'esposizione derivante dalla perdita di dati e da letture non autorizzate del backend; non può da sola impedire a un server attivo compromesso, a un utente autorizzato di scaricare un file o a un account rubato di leggere un documento aperto.