Dispensa in PDF - Dipartimento di Scienze Ambientali, Informatica e ...

Carnielli Efrem: Programmazione a componenti
Applicazioni Client-Server e database
l’interrogazione e raccolgono i dati risultanti, uso i dati ed infine rilascio la
connessione. Ha senso usare un Prepared Statement per una connessione così
rapida? E inoltre quando questi vengono inseriti nella connessione?
La soluzione consiste nel creare connessioni per compiti specifici, quindi per una
data tipologia di richieste, ad esempio connessioni solo per le richieste di dati (o
solo per l’inserimento...), quindi la richiesta di connessione al pool dovrà prevedere
anche l’inserimento di un parametro legato alla tipologia di connessione che
desidero a seconda del motivo per cui voglio la connessione.
Il pool di connessione è legato a login e password. Ma chi si occupa di tutto?
Per un utente che fa logon ad un DB gli si deve fare subito almeno una
connessione, il pool non serve più!
Da qui ho principalmente due problemi, il primo è che una connessione per ogni
utente è troppo (il numero degli utenti è generalmente elevato), mentre potrei
usare un pool che ne gestisce solo un numero sufficiente.
Il secondo è che nel DB gestisco i dati, in un’applicazione funzionalità operative,
l’utente è l’attore che usa dei casi d’uso. Se la logica di sicurezza dei dati è relegata
al gestore del DB io non posso creare niente di sicurezza applicativa, ma ho solo
sicurezza dei dati.
Ad esempio non basta assicurare che lo studente che compila il test non possa
crearlo.
La soluzione è che l’applicazione diventa un utente del DB, si crea un pool di
connessione e per ogni connessione crea login e password: in questo caso avrò un
unico utente per ogni applicazione. I vari utenti dell’applicazione sono gestiti
dall’applicazione come attori diversi.
Login e password nell’applicativo, da qualche parte ci sarà una sequenza di codice
dove ci sarà: createConnection createConnection createConnection (l,p).
(l,p).
Ho tipologie diverse di connessioni assegnate a diversi utenti.
Lo sviluppatore non può gestire le credenziali di accesso al DB.
Lo sviluppatore in buona o cattiva fede può danneggiare o tenere informazioni
critiche dal DB per cui sta facendo l’applicazione.
Deve essere il responsabile applicativo della base di dati che ha la responsabilità di
controllare che al db vengano fatte richieste consentite.
Lo sviluppatore però potrebbe fare quello che vuole perchè basta che faccia la
connessione di tipo “modifica” per danneggiare il DB.
Qui interviene la responsabilità del team di autoregolarsi al suo interno.
Bisognerebbe fare in modo che lo sviluppatore che sviluppa un dato caso d’uso
non possa accedere a dati che non hanno inerenza con quello che devo fare.
Il pool di connessione deve capire chi è l’attore che richiede la connessione.
Ci devono essere i responsabili che decidono cosa un ruolo può fare o no. Si tratta
di sicurezza applicativa di primo livello.
Se lo sviluppatore svolge il caso d’uso “compila questionario” è il meccanismo di
152