Qualifying Observation Integrity for Selective Authorization in PostgreSQL

Nel mondo digitale, i database fungono da memoria centrale per tutto, dai conti bancari ai carrelli della spesa online. Essi memorizzano lo stato attuale del mondo: quanto denaro è presente in un conto, quali articoli sono a magazzino o se un utente ha il permesso di entrare in un edificio. Quando un programma perimetrale chiede a un database il permesso di eseguire un'azione, il database controlla i fatti attuali. Se i fatti sono cambiati dall'ultimo controllo, la risposta potrebbe essere diversa. Ad esempio, un acquisto potrebbe essere approvato quando un utente ha abbastanza denaro, ma se un'altra transazione spende quel denaro un istante dopo, l'approvazione dovrebbe essere revocata. Per garantire la sicurezza, i sistemi spesso ricontrollano i fatti ogni singola volta che un'azione sta per accadere. Questo è affidabile, ma può essere lento, specialmente quando gli stessi fatti vengono controllati migliaia di volte di seguito senza cambiare.

I ricercatori cercano da tempo modi per velocizzare questo processo ricordando l'ultima volta che i fatti sono stati controllati. Se il sistema può dimostrare che i dati sottostanti non sono cambiati, può riutilizzare il vecchio permesso senza chiedere di nuovo. Questo è chiamato autorizzazione selettiva. Tuttavia, questa scorciatoia funziona solo se il sistema può essere assolutamente certo che i dati non siano realmente cambiati. Se il sistema viene ingannato facendogli credere che i dati siano stabili quando in realtà stanno cambiando, potrebbe concedere il permesso per una transazione che dovrebbe essere bloccata. La sfida principale non è solo controllare i dati, ma verificare che i meccanismi stessi progettati per tracciare i cambiamenti stiano funzionano correttamente e siano visibili alle persone giuste.

Un ricercatore di nome Aleksandar Mihajlovic ha sviluppato un metodo per verificare questi meccanismi di tracciamento all'interno di un tipo specifico di sistema database chiamato PostgreSQL. L'obiettivo era creare un insieme rigoroso di regole che un'installazione di database debba seguire per essere affidata a questa scorciatoia. Il sistema, chiamato OntoCommit, agisce come un guardiano. Prima che un database sia autorizzato a riutilizzare le vecchie decisioni di permesso, questo guardiano ispeziona il codice e la configurazione per garantire che ogni modifica ai dati sia registrata correttamente e che la persona che controlla i record possa effettivamente vedere quei record. La ricerca si concentra su un confine specifico: il momento in cui viene effettuata una modifica e il momento in cui viene osservata. Se esiste un divario tra i due, la sicurezza dell'intero sistema è compromessa.

Lo studio è iniziato identificando quanto fosse facile rompere questa fiducia, anche quando il codice appariva corretto in superficie. Il ricercatore ha scoperto due modi specifici in cui un sistema poteva fallire silenziosamente. Nel primo caso, una funzione di supporto progettata per aggiornare un contatore di modifiche aveva i nomi dei suoi input scambiati. Il codice girava ancora, e i tipi di dati che accettava erano corretti, ma poiché i nomi erano confusi, il contatore per un tipo di modifica veniva aggiornato mentre il contatore per un altro tipo rimaneva bloccato. Era come un sistema di semafori in cui il sensore per la corsia nord-sud era stato accidentalmente collegato al pulsante est-ovest; le luci sarebbero cambiate, ma non per le auto che ne avevano bisogno. Nel secondo caso, il sistema era configurato con una funzione di sicurezza che nascondeva determinate righe di dati agli utenti regolari. Il contatore delle modifiche veniva aggiornato correttamente dall'amministratore di sistema, ma la persona che controllava il permesso era bloccata dal vedere quell'aggiornamento. Per il controllore, il contatore appariva pari a zero, anche se in realtà era aumentato. Ciò creava un falso senso di sicurezza.

Per prevenire questi fallimenti, il ricercatore ha costruito uno strumento di qualifica che controlla l'installazione del database prima che sia autorizzata a usare la scorciatoia. Questo strumento non si limita a cercare la presenza di codice; verifica l'esatta associazione dei nomi delle funzioni, la proprietà delle tabelle e le impostazioni di visibilità per ogni ruolo utente. Esige che il codice responsabile dell'aggiornamento dei contatori delle modifiche corrisponda esattamente alla firma prevista dal sistema. Inoltre, proibisce l'uso della sicurezza a livello di riga (row-level security) sulle tabelle specifiche che tracciano tali modifiche, garantendo che la persona che controlla il permesso possa sempre vedere lo stato reale del contatore. Lo strumento agisce come un ispettore rigoroso, rifiutando qualsiasi installazione che tenti di usare variazioni non supportate o che nasconda le prove del cambiamento.

Il ricercatore ha testato questo approccio utilizzando un ambiente controllato che simulava un processo di acquisto completo. Il sistema è stato impostato per gestire uno scenario in cui un utente tenta di acquistare qualcosa, controllando il saldo del proprio conto e qualsiasi eventuale blocco sui propri fondi. L'esperimento ha confrontato due metodi: uno in cui il sistema rivaluta l'intera policy da zero ogni volta, e un altro in cui il sistema utilizza la scorciatoia dell'autorizzazione selettiva. I test sono stati eseguiti su una versione standard del software database, ma all'interno di un ambiente informatico simulato per garantire un controllo preciso sulle condizioni. Lo studio ha incluso un set di centottanta diverse coppie di configurazioni, alcune progettate per essere sicure e altre per essere insicure, per vedere se lo strumento di qualifica potesse distinguere la differenza.

I risultati hanno mostrato che lo strumento di qualifica era altamente efficace nell'identificare le configurazioni insicure. Ha rifiutato con successo tutti e cinque i setup deliberatamente insicuri, inclusi quelli con nomi dei parametri scambiati e righe di dati nascoste. Allo stesso tempo, ha accettato tutte le quarantotto configurazioni valide e sicure. Ha inoltre rifiutato correttamente due configurazioni che erano sicure ma non rientravano nelle regole rigide dello strumento, dimostrando che dà priorità alla sicurezza rispetto alla comodità. Nei test di prestazione, il metodo dell'autorizzazione selettiva si è rivelato significativamente più veloce quando i dati rimanevano invariati. Per un dataset di diecimila righe, il sistema che utilizzava la scorciatoia ha completato il ciclo in un tempo mediano di sessantasei millisecondi, mentre il sistema che ricontrollava tutto impiegava ottantasette millisecondi. Ciò rappresentava una riduzione del tempo del ventiquattro percento. Tuttavia, lo studio ha anche rilevato che quando i dati cambiavano effettivamente, la scorciatoia non offriva alcun vantaggio di velocità e poteva persino essere leggermente più lenta, poiché il sistema doveva rivalutare la policy.

La ricerca ha anche evidenziato i limiti dei test. Il ricercatore ha dimostrato che limitarsi a eseguire alcuni test per vedere se il sistema funziona non è sufficiente a garantire che funzionerà sempre. È possibile costruire uno scenario in cui un sistema supera ogni test ma fallisce comunque sotto una specifica condizione non vista. Lo studio ha mostrato che un sistema può superare una serie di controlli pur continuando a nascondere un cambiamento critico all'osservatore. Ciò significa che l'unico modo per garantire la sicurezza è imporre regole rigide su come il sistema viene costruito, piuttosto che fare affidamento esclusivamente sui test per trovare errori. Lo strumento non pretende di provare che il sistema sia perfetto in ogni universo possibile, ma fornisce un contratto verificabile che l'installazione segua un modello specifico e sicuro.

In conclusione, il lavoro fornisce un metodo pratico per rendere i database più veloci senza sacrificare la sicurezza. Definendo un insieme chiaro di regole su come il tracciamento delle modifiche debba essere implementato e verificato, il ricercatore ha creato un modo per fidarsi del fatto che il database dica la verità sul proprio stato. Lo studio non pretende di risolvere ogni problema nella sicurezza dei database, né suggerisce che questo metodo debba essere usato in ogni situazione. È una soluzione specializzata per un tipo specifico di configurazione di database, una che scambia parte della flessibilità con un grado maggiore di certezza. I risultati suggeriscono che per le applicazioni in cui velocità e sicurezza sono entrambe critiche, come le transazioni finanziarie, un sistema correttamente qualificato può offrire una scorciatoia affidabile. La ricerca conclude che la sicurezza di queste scorciatoie dipende interamente dall'integrità del percorso di osservazione, dal momento in cui avviene una modifica al momento in cui viene vista, e che questo percorso deve essere controllato con lo stesso rigore dei dati stessi.