Le attuali leggi sulla Privacy (e il buon senso) richiedono che lo sviluppo applicativo sia fatto in modo da tutelare l’accesso ai dati sensibili alle persone che effettivamente ne abbiano l’autorizzazione. Secondo alcune linee guida, lo sviluppo prevede che si creino sul database viste e query che, in base al livello utente, diano l’accesso a un determinato set di informazioni. Questo tipo di approccio, secondo me, è molto oneroso in termini di risorse e visti i tempi di sviluppo effettivamente a disposizione, non è facilmente perseguibile. Quello che vi voglio proporre qui è un metodo alternativo per sviluppare applicazioni web che rispondano a suddette esigenze in modo rapido.
L’applicazione utilizza PHP come linguaggio di programmazione di esempio tuttavia può essere applicato a qualsiasi altro linguaggio di programmazione. Le query SQL riportate sono di MySQL.
La prima fase di questo sviluppo dovrebbe consistere nello sviluppo di una forte serie di funzioni che realizzino le funzioni di autenticazione ed autorizzazione. Questo insieme di funzioni devono svolgere i compiti di seguito proposti. Assegnerò ad alcune funzioni dei nomi, in modo da poterle richiamare nel codice di esempio che vado proponendo.
Funzione di autenticazione
Questa funzionalità deve essere presente sempre. Non la si può omettere, deve supportare un meccanismo di controllo che verifichi l’esistenza delle credenziali e la loro correttezza, lo stato attivato o meno dell’account. A livello di codice applicativo questa funzione può essere omessa in quanto la gestione delle credenziali può essere delegata al Web Server (autenticazione di base, ecc.) poiché più facilmente gestibile ed integrabile con altri sistemi di autenticazione o single sign on (per es. IIS ed Active Directory) che sono più facilmente controllabili e dispongono già di un forte sistema di controllo dell’accounting utente (scadenza password, complessità, ecc.)
Funzione di gestione delle autorizzazioni
Questa a differenza della suddetta componente, invece, è indispensabile. La funzione assegna all’utente un “livello” di autorizzazione che, trasversalmente su tutta l’applicazione, fornisce all’utente accesso a determinate componenti o contenuti. La funzione caricherà in sessione (non in cookie!!!) i livelli di autorizzazione dell’utente che devono essere sempre accessibili. Al logon utente il set di credenziali fornito verrà quindi confrontato con il livello dell’utente, e il suo “token” di autorizzazione verrà salvato in sessione. Ogni volta che si andrà a pubblicare una componente (un’ancora, un record, anche una singola etichetta) il programma andrà a verificare se l’utente è autorizzato o meno ad accedere a quella informazione usando il “token” come metodo di confronto.
Come gestiamo l’accesso ai dati?
Supponiamo di avere una tabella anagrafiche strutturata così:
CREATE TABLE tbl_pazienti (
ID_paziente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nome_paziente VARCHAR(45) NULL,
codice_fiscale CHAR(15) NULL,
indirizzo VARCHAR(45) NULL,
localita VARCHAR(255) NULL,
provincia CHAR(2) NULL,
stato CHAR(3) NULL DEFAULT “ITA”,
telefono VARCHAR(20) NULL,
codice_assistito CHAR(10) NULL,
PRIMARY KEY(ID_paziente)
);
Secondo le linee guida, per ogni “livello” di autorizzazione dovremmo creare una vista che dia accesso solo ad una limitata componente di dati. A livello di codice, poi, dovremmo fare una serie di strutture di controllo che, in base al livello utente, carica la vista opportuna. L’impegno per la gestione dei permessi diventa onero, mentre l’aggiunta di un nuovo livello di autorizzazione richiederebbe l’intervento almeno di un DBA (se il codice è stato strutturato opportunamente).
Implementando il metodo descritto nel presente articolo, invece, andiamo a gestire tutto a livello applicativo. Attraverso un pannello di configurazione è possibile configurare i parametri di “autorizzazione”. Il processo di creazione di un nuovo livello di autorizzazione prevede i seguenti passaggi:
- Creazione del livello di autorizzazione
- Per ogni tabella andiamo a definire quale colonna l’utente può visualizzare e quale no (un valore booleano)
- Salviamo le modifiche
La suddetta operazione può essere svolta tranquillamente da qualsiasi utente che abbia le opportune credenziali di accesso al pannello amministrativo, e non deve assolutamente essere né un DBA, né un programmatore. A livello di codice invece? Tutto esattamente uguale. Vediamo come.
Partendo dalla SELECT che interroga il database, supponiamo di caricare il record di un determinato paziente.
SELECT t.nome_paziente, t.codice_fiscale, t.indirizzo, t.localita,
t.provincia, t.stato, t.telefono, t.codice_assistito
FROM tbl_pazienti t
WHERE t.ID_paziente = 25
LIMIT 1;
La query restituisce un record solo con i dati anagrafici del paziente. Ora vediamo il codice applicativo.
La regola del RAD (Rapid Application Development) dice che per visualizzare i dati dobbiamo fare una struttura del tipo:
$q = “SELECT…..”;
$r = mysql_query( $q );
$data = mysql_fetch_array( $r );
# Altro codice
print( $data[ “nome_paziente” ] );
Non vogliamo stravolgere la regola dello sviluppo rapido delle applicazioni, anzi, lo vogliamo mantenere. Allora sostituiamo solo una sola funzione di tutto il set suddetto: la funzione print().
La nostra nuova funzione (che chiamerò “getElement” ) non fa altro che fare l’output del contenuto di un elemento $data, tuttavia prima di farlo, verifica se l’utente ha il permesso di visualizzare quel elemento. Secondo il suddetto esempio, pertanto, avremo che il codice da noi scritto sarà più simile al seguente esempio:
$sql = “SELECT ….”;
$obj->query( $sql );
# Altro codice
print $obj->getElement( “nome_paziente” );
Conclusioni
Il vantaggio di questo metodo di programmazione è che lo sviluppatore può sviluppare le applicazioni in modo rapido, senza più curarsi del concetto di autorizzazione. Il sistema descritto può essere applicato a qualsiasi elemento del programma come etichette, elementi dei form, ancore, ecc. Sviluppando delle guide all’interno dell’area di amministrazione si effettua una completa spaccatura tra Utente Finale che deve fruire di un’applicazione, e il gruppo di sviluppo che invece deve intervenire su di essa aggiungendo nuove funzionalità. Quando un utente finale necessita di modificare un livello di autorizzazione, con il sistema proposto è sufficiente che si rivolga alla persona che si occupa della gestione dei livelli la quale, normalmente, è una persona interna che conosce bene l’ottica aziendale. Se usassimo delle viste, invece, ci troveremmo a dover chiamare un DBA o lo sviluppatore, con la logica conseguenza di dover attendere un periodo di tempo più lungo per avere la modifica (e possibilmente anche dei bug poiché la modifica è eseguita sul codice).
Esistono degli aspetti sulla sicurezza e sulla privacy (questo esempio è legato al mondo sanitario che mi affascina molto ultimamente) che non ho contemplato nell’articolo poiché sono principalmente argomenti sistemistici. Questi elementi sono la comunicazione tra database e application server, e tra application server e client di rete, la crittografia dei dati sui dischi dei database, e l’eventuale crittografia dei dati all’interno delle tabelle dei database. Magari saranno argomento di un altro articolo 
Questa cosa non mi era ancora capitata. Lavorando ad uno script molto quick e very dirty per sistemare i problemi di profili roaming di Citrix mi sono trovato davanti ad un muro che mi ha sbarrato la strada per due giorni. In pratica uno script in VB.NET che funzionava perfettamente in locale, messo in produzione su un server 2003 continuava ad andare in Exception. E gira e rigira, riscrivi il programma in un altro modo. Ho preso e copiato del codice da un’applicazione che avevo sviluppato in passato e…. non funzionava piu’ in locale! Due giorni di debug e poi mi son detto… ma si… proviamo a fare questo.