Quali funzionalità consentono di creare un confine di fiducia per l’IA domestica attorno ai file sensibili?

Un confine di fiducia per l’IA domestica si costruisce combinando crittografia dei dati inattivi, autorizzazioni con il minimo privilegio, sandboxing del runtime e isolamento del contesto; nessuna di queste funzionalità è sufficiente da sola.

Se mantieni un modello locale sullo stesso NAS che archivia dichiarazioni dei redditi, referti medici o documenti di famiglia, il modello e i file condividono la stessa macchina. È esattamente in questo caso che il confine è più importante: un indice RAG o un agente che utilizza strumenti può leggere molto più di quanto intendessi esporre. La variabile decisiva è quale di questi quattro livelli si trova effettivamente tra il processo AI e i dati sensibili.

Che cosa separa realmente un confine di fiducia in una configurazione AI domestica

Un confine di fiducia è il punto di applicazione in cui una richiesta di lettura proveniente da un’app AI viene autorizzata o negata prima che il contenuto del file raggiunga il modello. In un NAS domestico che esegue un LLM locale, questo punto si trova all’interno del sistema operativo, non nel modello, perché il modello vede soltanto ciò che il runtime inserisce nel suo contesto.

Ogni volta che l’IA lavora, attraversano quel punto tre elementi: l’identità del processo che richiede il file, la decisione di controllo degli accessi applicata dal kernel a quell’identità e la conseguente finestra di esposizione durante la quale i byte decrittografati o autorizzati possono essere letti. Quando tutti e tre sono allineati, il confine svolge il proprio compito; quando uno è configurato male, il confine si amplia silenziosamente.

Il sintomo osservabile di un confine debole è l’esposizione dell’indice di ricerca: l’indice AI restituisce passaggi di file che non avevi mai intenzione di condividere. Poiché il confine viene applicato nel sistema operativo anziché nel modello, la soluzione è una questione di funzionalità: quali funzionalità del sistema operativo e del runtime si trovano tra il processo e il file.

Crittografia dei dati inattivi: la prima linea che viene meno nella maggior parte dei sistemi di IA domestici

La crittografia dell’intero disco e del filesystem, come LUKS o la crittografia F2FS, protegge i dati quando la macchina è spenta, perché la chiave del volume è conservata dal kernel e viene rilasciata solo dopo lo sblocco. Questo rende la crittografia dei dati inattivi la prima linea di difesa contro il furto fisico e contro un secondo sistema operativo che legga direttamente l’unità.

Il limite è che un server AI in esecuzione mantiene il filesystem montato e decrittografato, quindi il runtime del modello può leggere i dati in chiaro proprio come qualsiasi altro utente locale. La crittografia protegge i byte sul disco, non quelli nella cache delle pagine o nell’indice AI; per questo, in pratica, un modello locale con accesso in lettura a un volume crittografato continua a vedere i file: il limite della crittografia dei dati inattivi.

Un modo pratico per osservare la differenza è crittografare un volume, montarlo ed eseguire al suo interno un’attività locale di generazione degli embedding: l’indice viene comunque creato. La crittografia dei dati inattivi è quindi importante in caso di arresto o furto, ma non sostituisce mai una decisione di accesso per il sistema attivo.

Permessi dei file e minimo privilegio: limitare il percorso di lettura

I bit dei permessi POSIX, le liste di controllo degli accessi e l’utente con cui viene eseguito un runtime IA costituiscono il secondo confine. Se il servizio del modello viene eseguito con un utente dedicato che dispone dell’accesso in lettura solo a una directory autorizzata, una richiesta che tenta di accedere a un file sensibile al di fuori di quella directory fallisce al controllo delle autorizzazioni prima che venga letto qualsiasi contenuto.

L’interazione consiste nel fatto che le autorizzazioni sono solide solo quanto l’identità utilizzata dal runtime. Eseguire il servizio IA come amministratore o come utente abituale annulla il confine, perché il processo eredita tutti i diritti di lettura di quell’identità, inclusi quelli sui file che la shell interattiva può aprire; è proprio il problema che il principio del minimo privilegio è progettato per prevenire.

Il test osservabile consiste nell’eseguire il servizio IA con il proprio utente, impostare una directory che non può leggere e chiedere al modello o ai suoi strumenti di aprire un file al suo interno. Un livello di autorizzazioni configurato correttamente restituisce un errore di accesso negato: è la prova verificabile più semplice che il percorso di lettura sia effettivamente limitato.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sandboxing e isolamento del runtime: limitare ciò che il processo IA può fare

Oltre ai bit dei permessi, container, filtri seccomp, profili AppArmor e regole Landlock limitano ciò che il processo IA può raggiungere anche quando la sua identità utente dispone di ampi privilegi. Un container che monta solo un dataset autorizzato esplicitamente non offre al runtime alcun percorso nel filesystem verso il resto dell’host, mentre una policy per le chiamate di sistema può bloccare i percorsi che verrebbero usati da un tentativo di evasione.

Il sandboxing interagisce con le autorizzazioni aggiungendo un secondo controllo indipendente: il kernel consulta la policy del sandbox oltre ai permessi dei file; le guide sull’isolamento a livello di kernel si applicano agli agenti IA. Questa stratificazione è importante perché una vulnerabilità nel server del modello, nel tokenizer o in una libreria per le chiamate agli strumenti potrebbe altrimenti trasformare una richiesta di lettura in una lettura arbitraria dell’intera directory home.

Il limite è che il sandboxing deve coprire sia il percorso di elaborazione dell’IA sia quello dei dati. I pesi del modello, le cache e i plugin degli strumenti risiedono sullo stesso volume, quindi una policy che autorizza esplicitamente la directory del modello ma dimentica l’archivio RAG lascia comunque raggiungibile l’indice sensibile; per questo l’isolamento è efficace solo quando ogni percorso montato è intenzionale.

Isolamento del contesto e del modello: mantenere i contenuti sensibili fuori dal prompt

Il confine più solido è quello che non invia mai contenuti sensibili al modello. Gli indici RAG con ambito definito, le regole di redazione e le directory escluse fanno sì che il passaggio di recupero selezioni esclusivamente da un corpus autorizzato, così il contesto del prompt non può contenere un file che non è mai stato indicizzato.

L'isolamento del contesto funge da controllo compensativo per i livelli sottostanti. Anche se la crittografia è applicata solo a riposo, un controllo dei permessi è configurato erroneamente o una sandbox presenta una lacuna, un ambito di recupero che semplicemente non include la directory sensibile impedisce a quei byte di raggiungere il contesto del modello, che è il punto evidenziato dalle linee guida sulla sicurezza degli LLM locali per il vector store.

La priorità è impedire al modello di divulgare o parafrasare contenuti che non ha mai ricevuto. Per questo l'isolamento del contesto è solitamente la funzionalità con il maggiore impatto in una configurazione domestica: trasforma una domanda aperta sull'accesso in una domanda chiusa sull'ambito di recupero, molto più facile da verificare rispetto alle policy del kernel.

Come interagiscono le funzionalità: una tabella decisionale per l'affidabilità dell'IA domestica

Nessuna singola funzionalità copre l'intero confine, perché ognuna protegge un punto diverso del percorso di lettura. La domanda utile non è quale funzionalità sia migliore, ma quale combinazione copra contemporaneamente la crittografia dei dati a riposo, l'insieme di lettura del processo, l'accesso del runtime e il contesto del modello.

La tabella decisionale associa ogni livello a ciò che protegge, al meccanismo alla base e al punto debole che un altro livello deve coprire. Leggendo le righe da sinistra a destra emerge lo stesso schema che si osserva nella pratica: il livello che protegge il disco non è quello che protegge il modello in esecuzione, quindi la copertura diventa completa solo quando ogni riga della tabella viene applicata contemporaneamente.

Il confine che resiste è quello stratificato: un errore di autorizzazione blocca la maggior parte dei tentativi, una sandbox limita il resto, un indice con ambito impedisce al modello di vedere del tutto i contenuti e la crittografia dei dati a riposo protegge il disco quando il sistema è spento. Eliminare uno qualsiasi di questi livelli lascia una lacuna che gli altri non possono colmare.

Un confine di attendibilità minimo per un server IA domestico

Un design iniziale praticabile per un NAS domestico che esegue un'IA locale si riassume in quattro punti: crea un utente di servizio dedicato per il runtime del modello, concedi a quell'utente l'accesso in lettura solo a una directory di dati, esegui il servizio in un container o con un profilo Landlock che monti solo quella directory e indirizza l'indice RAG a un corpus inserito in un elenco di autorizzazione che escluda la cartella sensibile.

I passaggi che lo rendono verificabile sono un test di negazione e un test del contesto. Per prima cosa, verifica che l'utente del servizio riceva un errore di autorizzazione negata quando tenta di aprire un file al di fuori della propria directory. In secondo luogo, verifica che il passaggio di recupero non restituisca nulla quando si cercano informazioni presenti esclusivamente nella cartella esclusa.

Il design non è perfetto contro un modello malevolo o una compromissione dell'utente root, ma è onesto riguardo al confine: blocca l'esposizione accidentale, contiene una chiamata a uno strumento difettosa e mantiene pulito il contesto del modello, che è la maggior parte di ciò a cui serve un confine di attendibilità domestico.

Domande frequenti

Un'IA locale può comunque leggere file crittografati sulla stessa macchina? Sì, se il runtime ha accesso in lettura al volume montato e decrittografato, perché la crittografia dei dati inattivi protegge il disco quando è spento, non il sistema in esecuzione. La protezione effettiva è il sandboxing con criterio di negazione predefinito più un indice con ambito limitato.

Cosa succede quando il modello ha davvero bisogno di accedere a un file sensibile? Fornisci al runtime una copia o un sottoinsieme inserito in un elenco di autorizzazione invece della directory originale, e aggiungi la redazione in modo che il prompt riceva solo il minimo necessario. Il confine tiene perché il modello non vede mai l'insieme più ampio: questo è il modello di definizione dell'ambito dell'indice RAG.

Una combinazione di funzionalità è sufficiente o serve una macchina separata? Per la maggior parte delle configurazioni domestiche è sufficiente una combinazione a più livelli; una macchina separata è utile solo quando serve un isolamento fisico o di gestione. La combinazione importante è il recupero con ambito limitato, un utente runtime con privilegi ridotti, la crittografia dei dati inattivi e i mount di sola lettura per i pesi del modello.