Un sistema RAG privato può cercare nei documenti crittografati senza decrittografarli quando sono inattivi?

Sì, se “senza decrittarli quando sono inattivi” significa che i documenti restano cifrati nell’archiviazione e vengono decrittati solo all’interno di un processo affidabile quando devono essere indicizzati o recuperati. Questo è un design realistico per un sistema RAG domestico privato. Tuttavia, la ricerca semantica ordinaria non può semplicemente indirizzare un modello di embedding verso un testo cifrato opaco e comprenderne il contenuto.

L’architettura pratica prevede quindi l’archiviazione cifrata dei dati inattivi, la decrittazione controllata in memoria, indici derivati cifrati o soggetti a controllo degli accessi e una rigorosa separazione delle chiavi. La ricerca direttamente sul testo cifrato è possibile solo con tecniche crittografiche specializzate, che non sostituiscono direttamente un normale database vettoriale.

«Crittografato a riposo» non significa «mai decrittato»

La crittografia dei dati inattivi protegge i file quando sono archiviati su un disco, un SSD, una destinazione di backup o un dispositivo spento. Un processo con la chiave corretta può comunque decrittare i dati quando è necessario svolgere operazioni legittime.

Documento cifrato sul disco
          |
          | lettura autorizzata
          v
Memoria del processo RAG affidabile
  ├─ decritta
  ├─ analizza / crea chunk
  ├─ genera embedding
  └─ recupera
          |
          v
Indice cifrato / database protetto

È simile al funzionamento di molti database e filesystem cifrati: i supporti di archiviazione non contengono testo in chiaro utile, ma le applicazioni possono visualizzarlo dopo l’autorizzazione.

Questo design è compatibile con un assistente IA privato su un NAS. La chiave è definire dove il testo in chiaro può esistere e per quanto tempo.

Perché la ricerca vettoriale tradizionale non può cercare testo cifrato grezzo

Un modello di embedding ha bisogno di caratteristiche significative del testo, delle immagini o dell’audio. La crittografia convenzionale distrugge intenzionalmente i pattern visibili, affinché il testo cifrato non conservi le relazioni semantiche necessarie al modello.

Se due frasi in chiaro sono simili, i relativi testi cifrati con crittografia sicura non dovrebbero apparire convenientemente simili. Altrimenti si divulgherebbero informazioni sugli originali.

Un normale processo di ingestione RAG procede quindi così:

1. Autentica il processo.
2. Decritta il documento in memoria o in un’area temporanea strettamente controllata.
3. Estrai e normalizza i contenuti.
4. Crea chunk ed embedding.
5. Archivia i dati di ricerca derivati secondo una propria policy di protezione.
6. Elimina il testo temporaneo in chiaro al termine dell'acquisizione.

La frase «i documenti crittografati rimangono crittografati quando sono inattivi» può essere ancora vera durante tutto questo flusso di lavoro, perché il testo in chiaro non deve mai diventare un file persistente sul disco.

Gli embedding non sono uguali al documento originale, ma sono comunque sensibili

Un errore comune consiste nel crittografare i PDF lasciando non protetti embedding, testo dei segmenti, nomi dei file, metadati e snapshot del database vettoriale. In questo modo si sposta il problema della privacy invece di risolverlo.

L'attuale documentazione sulla sicurezza di Qdrant sottolinea che una distribuzione self-hosted deve essere protetta esplicitamente. La crittografia dello storage è una responsabilità dell'infrastruttura negli ambienti gestiti autonomamente, non qualcosa da dare per scontato perché il database è locale.

Per un sistema di ricerca privato, considera gli embedding parte della base di conoscenza protetta, non semplici file di cache innocui.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Dove devono essere conservate le chiavi di decrittografia?

Non archiviare la chiave di decrittografia accanto ai documenti crittografati in un file di configurazione leggibile da chiunque. L'obiettivo è fare in modo che il furto del disco o la copia di un backup non siano sufficienti per recuperare i dati.

Un design più sicuro per un laboratorio domestico separa:

• volume dati: documenti e file di database crittografati;
• materiale delle chiavi: portachiavi del sistema operativo, archivio delle chiavi basato su hardware o archivio di segreti protetto separatamente;
• identità del servizio: il processo RAG riceve solo le chiavi di cui ha bisogno;
• chiavi di backup: conservate separatamente dall'unica copia del backup crittografato.

La sola crittografia del disco non può proteggere un server in esecuzione e completamente sbloccato da una compromissione a livello di amministratore. Protegge da una minaccia diversa: unità sottratte, copie offline, hardware dismesso e accesso non autorizzato ai supporti di backup.

Come evitare i file temporanei in chiaro?

Molti parser di documenti creano silenziosamente file temporanei. Le pipeline OCR possono decomprimere le pagine, i convertitori per documenti d'ufficio possono scrivere formati intermedi e gli strumenti PDF possono memorizzare nella cache gli elementi estratti.

Verifica il percorso di acquisizione e scegli uno dei tre modelli:

• trasmetti direttamente i byte decrittografati al parser;
• usa un file system temporaneo basato sulla RAM per i file intermedi;
• posiziona l'archiviazione temporanea su un volume crittografato ed eliminala subito dopo l'elaborazione.

Controlla anche i log. Un log di “debug” che stampa il testo dei documenti, i prompt, i frammenti recuperati o gli argomenti degli strumenti può diventare la copia non crittografata più grande della knowledge base.

La crittografia omomorfica può cercare nei documenti senza decrittografarli?

La crittografia omomorfica è la tecnologia a cui ricorre la maggior parte delle persone quando desidera eseguire calcoli su dati crittografati. La documentazione di SEAL di Microsoft spiega che gli schemi omomorfici possono eseguire determinati calcoli mentre i valori restano crittografati.

Ma afferma anche una limitazione importante: la crittografia omomorfica comporta un notevole sovraccarico prestazionale e supporta in modo efficiente solo determinate operazioni. Microsoft SEAL supporta operazioni aritmetiche come addizione e moltiplicazione crittografate; i confronti generici, l'ordinamento e le espressioni regolari in genere non sono pratici allo stesso modo dei calcoli sul testo in chiaro.

I calcoli approssimati delle distanze possono essere realizzati con schemi come CKKS, quindi la ricerca sui vettori con tutela della privacy è un ambito di ricerca reale. Ciò non rende la ricerca semantica crittografata equivalente all'installazione di Qdrant, pgvector o Weaviate e all'attivazione di un'opzione “query crittografata”.

Un design RAG privato più sicuro

Per la maggior parte delle abitazioni e dei piccoli team, il miglior rapporto tra sicurezza e complessità è il seguente:

Dataset NAS crittografato
      |
      | chiave con ambito limitato al servizio
      v
Container di acquisizione RAG
      |
      +-- solo testo in chiaro in memoria / temporaneo crittografato
      |
      +-- incorporamenti + metadati
      v
Volume del database vettoriale crittografato
      |
      v
Servizio di recupero locale
      |
      | frammenti recuperati minimi
      v
Modello locale o modello cloud approvato

Se è coinvolto un modello cloud, lo storage può rimanere perfettamente crittografato mentre il testo recuperato lascia comunque la rete domestica all’interno del prompt. La crittografia dello storage e il controllo dell’uscita dei dati sono problemi distinti. La guida ai confini di attendibilità dell’IA locale è utile in questo caso: il componente autorizzato a decrittografare i dati non dovrebbe essere automaticamente autorizzato anche a trasmetterli.

Checklist per la crittografia di un RAG privato

• Crittografa il volume dei documenti di origine.
• Proteggi anche lo storage, le istantanee e i backup del database vettoriale.
• Conserva le chiavi al di fuori delle normali directory dei documenti.
• Concedi al servizio RAG solo l’accesso minimo necessario alle chiavi e ai percorsi.
• Evita le cache persistenti per l’estrazione in chiaro.
• Controlla le directory temporanee di OCR, conversione e debug.
• Non registrare per impostazione predefinita i segmenti privati recuperati.
• Separa le autorizzazioni per il recupero locale da quelle per l’invio al cloud.
• Testa il ripristino prima di ruotare o eliminare le chiavi di crittografia.

La guida alla ricerca documentale e al RAG può aiutare ad applicare questo livello di sicurezza all’estrazione, alla suddivisione in segmenti, alla creazione degli embedding e al recupero.

Domande frequenti

Un database vettoriale può indicizzare direttamente un PDF crittografato con AES?

No. Il contenuto deve essere decrittografato da un processo autorizzato prima che un normale modello di embedding testuale o multimodale possa estrarne il significato.

La crittografia dell’intero disco protegge un server RAG in esecuzione?

Solo parzialmente. Una volta sbloccato il volume, i processi con privilegi possono leggerlo. La crittografia dell’intero disco offre la protezione più efficace contro gli accessi offline, i dischi rubati e i supporti copiati.

Gli embedding devono essere crittografati?

Per le conoscenze private sensibili, sì: proteggi lo storage che contiene embedding e indici, limita l’accesso al database e includi questi file nella stessa revisione di sicurezza dei documenti di origine.

Verdetto finale

Un sistema RAG privato può mantenere i documenti crittografati a riposo senza rinunciare alla normale ricerca semantica. Il modello realistico prevede una decrittografia controllata e temporanea nella memoria attendibile, non una ricerca magica su testo cifrato opaco. Proteggi gli embedding derivati e gli indici, separa le chiavi dai dati, elimina i file temporanei in chiaro e considera la ricerca omomorfica un progetto crittografico specializzato, non una funzione standard per un RAG domestico.