Press "Enter" to skip to content

1 – Lavorare con i dati – filosofia della sicurezza

blogs.dotnetwork.it/…/diamoci-un-contesto-parte-2

In questo articolo, intendo rispondere ad alcune domande che mi sono state poste da chi segue il mio blog, riguardo la creazione di applicazioni line of business. Ho deciso di dare alcune informazioni a carattere generale su quello che nella mia esperienza è opportuno fare per assicurarsi che i dati delle vostre applicazioni siano gestiti correttamente e accessibili agli utenti solo in modo corretto, ovvero in modo autorizzato e tramite la vostra applicazione.

Ovviamente si tratta solo di osservazioni personali derivate dalla mia esperienza, pertanto chi ha lavorato in campi diversi può avere modi di lavorare, e di pensare molto diversi. Al lettore viene lasciato modo di riflettere e decidere in modo personale cosa può essergli utile e cosa invece non è adatto alle applicazioni che sviluppa e agli utenti che queste servono.

  • Una osservazione importante, i dati di una applicazione sono del cliente che la usa, pertanto il cliente deve essere in grado di accedervi, di usarli e se decidesse di non usare più la nostra applicazione, deve poterli estrarre dal contenitore in cui decideremo di salvarli. Se lo dico è perché più di qualche volta mi sono trovata a dover aiutare a reinserire dati da zero perché in origine imprigionati in una applicazione ormai obsoleta. Non è etico, e soprattutto è controproducente usare simili mezzucci per tenere un cliente legato ad una software house.
  • Se dobbiamo gestire una quantità molto limitata di dati e stiamo implementando una applicazione per singolo utente, non è il caso di implementare sistemi di sicurezza particolari, se lo riteniamo realmente necessario, possiamo utilizzare un sistema per crittografare i dati prima di salvarli su un file su disco, utilizzando i sistemi di serializzazione XML o JSON uniti alla crittografia che sono stati ampiamente trattati su questo sito. In queste soluzioni può essere anche consigliabile l’uso di database relazionali “single user” per così dire, come Sql Server compact scaricabile su MSDN, oppure Sqlite, o anche un database Access.
  • Se dobbiamo gestire una quantità di dati non limitata, in una applicazione che dovrà lavorare per anni e a cui accederanno più persone, è opportuno utilizzare un sistema già dotato di sistemi di gestione di accesso ai dati, in particolare, possiamo pensare ad un database relazionale, come SQL Server, Oracle, DB2 o MySql e ne cito solo alcuni a me noti, ve ne sono molti altri.
  • Per la gestione degli accessi e della sicurezza, è opportuno utilizzare i sistemi di sicurezza del database relazionale, assieme alla sicurezza di Windows, in modo tale da evitare gli accessi non voluti ai dati, sia per supportare la privacy che per ovviare a qualsiasi manipolazione effettuata al di fuori della nostra applicazione da parte di utenti non autorizzati.

Come utilizzare la sicurezza dei database relazionali in modo corretto

Inizio parlando di SQL Server, visto che è il database primario che utilizzo per il mio lavoro, ma sono certa che lo stesso possa essere applicato agli altri database relazionali disegnati per applicazioni aziendali con più utenti.

SQL Server ha 2 diverse modalità di gestire la sicurezza, una di esse mappa gli Utenti o i Gruppi di Windows sui Login di SQL Server. Questo tipo di sicurezza, permette di impostare l’accesso ai dati di un database in modalità granulare, dando al DBA (DataBase Administrator), modo di dare accesso in lettura e scrittura, o negare accesso ai dati del database anche in scenari molto complessi.

Ha però anche un effetto “negativo” per così dire, infatti, pur dando maggiore sicurezza perché non vi è la necessità di passare credenziali in chiaro a SQL Server per l’accesso ai dati perché tutta la sicurezza viene gestita dalla sicurezza di Windows, l’uso di questo tipo di sicurezza da agli utenti accesso ai dati a cui sono autorizzati con qualsiasi mezzo in grado di collegarsi a SQL Server, pertanto, i dati potrebbero essere manipolati non solo tramite la nostra applicazione, ma anche con l’uso di mezzi di connessione diretta al database, il più banale, SQL Management Studio, il più semplice da usare, Excel, o anche Access.

Potrebbe essere il modo migliore di gestire l’accesso ad un database aziendale, qualora più applicazioni ne dovessero fare uso oppure potrebbe non essere adatto. Dipende dai contenuti e dall’uso degli stessi da parte degli utenti.

Il secondo metodo di accesso, è utilizzando quella che si chiama la Sicurezza di SQL Server, ove i permessi vengono assegnati ad un Login formato da uno Username e da una Password, considerato meno sicuro, visto che le credenziali devono essere fornite alla connessione a SQL Server per ogni query, e vengono trasmesse in chiaro sul canale di comunicazione TCP/IP pertanto potrebbero essere “sniffate” da un hacker.

Il vantaggio di questo metodo di accesso, posto che la sicurezza interna della rete sia, come ci aspettiamo, buona, è che se le credenziali sono note solo all’applicazione e non all’utente, non c’è modo che l’utente possa accedere a SQL server se non tramite l’applicazione.

Questo è l’approccio che io preferisco utilizzare, in modo tale da evitare di dare agli utenti più smaliziati accesso diretto ai dati delle mie applicazioni.

L’obiezione che mi può venire fatta è che se l’applicazione deve fornire UserName e Password in chiaro, queste devono essere memorizzate in un file accessibile all’utente, quindi torniamo al caso precedente. E’ un obiezione corretta, la mia soluzione alla cosa ha 2 diversi livelli, in base a quanto è delicato l’accesso ai dati che si vuole effettuare.

  1. Se i dati di connessione sono forniti dal DBA in un file crittografato che solo l’applicazione sa come decrittografare, l’utente non ha bisogno di conoscerli per usare l’applicazione, e salvo il fatto di utilizzare degli Sniffer di rete, non potrà conoscere queste credenziali.
  2. Nel caso si voglia essere certi che l’utente non acceda ai dati di connessione memorizzati sul suo computer, è possibile utilizzare una sicurezza a due livelli, ovvero le credenziali che l’utente può trovare sul proprio computer e decrittografare possono dare accesso solo alle tabelle indispensabili all’applicazione per identificare un utente autorizzato e farsi rilasciare dal database stesso le credenziali di secondo livello che contengono i permessi per la modifica e l’accesso a tutti i dati applicativi.

In SQL Server, esistono anche quelli che si chiamano Application Roles, Su questo articolo in MSDN trovate maggiori informazioni sul loro funzionamento, sfortunatamente anche gli application roles necessitano di trasmettere la password in chiaro a SQL Server, quindi sono intercettabili in rete.

Il solo fatto che vi sia il pericolo che le credenziali siano “sniffate” in una intranet, implica anche che vi sia un intento “criminale” per così dire da parte di qualcuno che ha accesso alla rete, quindi il dolo da parte di un dipendente. Contro questo non vi sono protezioni sicure al 100 per 100, quello che noi programmatori possiamo fornire è semplicemente un sistema che abbia due funzionalità specifiche:

  1. Evitare che i dati possano essere manomessi all’esterno della nostra applicazione da personale o da applicazioni non autorizzate.
  2. Evitare l’accesso non autorizzato ai dati permettendolo solo tramite la nostra applicazione in modo da ottemperare a tutti i requisiti richiesti dalla normativa privacy e sicurezza attualmente in vigore in Italia.

Se volete costruire un sistema per la memorizzazione di credenziali SQL Server con adeguata User Interface, vi consiglio di leggere i seguenti articoli su questo Blog:

  • Diamoci un contesto (Parte1) e la successiva (Parte2)
  • Ed i 7 articoli che illustrano la costruzione di un controllo per gestire la memorizzazione delle Connection String che iniziano con Questo articolo i link ai successivi sono in fondo all’articolo stesso, e questi articoli sono anche indicizzati sulla Categoria “Connetions Control” che trovate a piè pagina del Blog accanto al Tag Cloud.

Ricordo a chi legge che la versione Express di SQL Server è gratuita e gestisce database fino a 10GB pertanto è certamente in grado di supportare qualsiasi vostra applicazione anche professionale, e il passaggio alla versione Full può poi essere effettuato quando necessario in modo trasparente.

Se invece volete usare MySQL non ci sono problemi, e anche MySQL può essere configurato nel modo che ho descritto qui sopra per fare in modo che sia accessibile solo alla nostra applicazione.

Creare accessi autorizzati alla nostra applicazione

Un’altra opposizione che potete fare al mio metodo di lavoro è la seguente:

Se l’applicazione ha accesso al file delle credenziali, tutti gli utenti possono accedere alla mia applicazione e vedere tutti i dati quindi la sicurezza intrinseca va a farsi un giro.

Obiezione corretta, il modo più semplice per evitare questo tipo di  problema è il seguente:

  • Ogni utente che accede alla macchina o alle macchine su cui è installata l’applicazione deve accedere alla macchina con uno Username e una Password di Windows personale e non nota ad alcun altro (come viene stabilito dalla normativa italiana sulla sicurezza e probabilmente anche da quella sulla privacy).
  • Se viene implementata la precedente condizione, basta che il file crittografato con i dati di connessione sia copiato sulla cartella privata dei soli utenti autorizzati e il problema di accessi non autorizzati è risolto.

Se lavorate in una rete di personal computer e non avete creato un dominio (o non sapete cos’è un dominio) è opportuno che andiate a fare una ricerca sul vostro motore di ricerca preferito e convinciate i proprietari del sistema a crearne uno in modo da fare un passo per entrare nel 21° secolo e a soddisfare i suddetti criteri di sicurezza minimi in modo professionale.

Se ho fatto la dichiarazione al paragrafo precedente è a causa della seconda obiezione che mi potrebbe venir fatta:

Ma se io ho una rete di pc ed i miei utenti si spostano su diverse macchine, devo aggiornare le credenziali di tutti gli operatori su tutte le macchine è un problema.

Il problema di cui sopra non esiste se il file con le credenziali viene inserito opportunamente su una cartella di proprietà dell’utente mappata su un percorso di rete, funzionerebbe anche senza il dominio. pertanto non dovrebbe essere così difficile da implementare nelle vostre applicazioni, credo che su questo blog vi siano svariati articoli che parlano della creazione di “Setting” personalizzati per le nostre applicazioni adatti sia alla configurazione di parametri applicativi (a livello di macchina) che di parametri utente. Memorizzare il percorso del file di configurazione dell’utente su un path generato in modo “meccanico” dall’applicazione non dovrebbe essere complicato.

Ma risolto un problema me ne potreste presentare uno diverso:

Bello che i miei utenti possano accedere alla tua applicazione da ogni PC aziendale, ma “potrei volere che un utente dell’amministrazione possa usarla quando è in magazzino, perché se il magazziniere la vede…”

In questo caso, il fatto di avere un dominio e di fare in modo che le persone usino sempre il proprio Login al dominio per accedere a qualsiasi macchina aziendale, ci aiuta di nuovo, infatti, per fare in modo di autorizzare l’accesso alla nostra applicazione solo a determinati utenti su specifici PC aziendali, può essere molto semplicemente gestito utilizzando una tabella di mapping sul database dell’applicazione.

In questa tabella potremo ad esempio inserire una lista dei computer autorizzati a usare l’applicazione, una lista degli utenti di dominio autorizzati ad usare l’applicazione, aggiungere anche i consulenti esterni, che usano un pc che non fa parte del nostro dominio (noi siamo questi signori) e, se davvero necessario, accoppiare utenti e macchine autorizzate in modo che la segretaria dell’amministratore delegato, non possa usare il PC del magazziniere anche se la nostra applicazione vi fosse installata.

Sono stata sufficientemente nebulosa da farvi venire il mal di testa? Bene, era questo il mio scopo.

L’ultima opposizione:

Bellissimo quello che mi hai detto, ma voglio comunque che i miei utenti possano accedere alla mia applicazione tutti con lo stesso utente windows (Username: Administrator, Password: password saranno sicuramente le credenziali che tutti utilizzeranno), però la mia applicazione deve essere sicura. Se è questo il caso, potrebbero per certo disinstallare SQL Server o semplicemente copiarsi il database e attaccarlo ad un SQL Server a casa propria per farvi quel che vogliono, ma, posto che vi sia una reale necessità per cui l’utente windows è uno solo per tutti (nel 21° secolo tutto questo non esiste, neppure sulle macchine con windows 10 home edition!) e che tale utente sia gestito con le corrette credenziali su tutte le macchine ed autorizzato a fare solo quanto a lui necessario ecco la soluzione:

Potete creare una bella tabella sul vostro database, contenente Username e Password (con la password crittografata) e implementare una maschera di Login che faccia loggare gli utenti alla vostra applicazione utilizzando lo Username e la Password da voi preferita.

Utilizzando le tecniche sopra illustrate, potrete combinare il tutto anche per fare in modo che:

  • Solo gli utenti di windows da voi autorizzati abbiano accesso all’applicazione
  • Tutti gli utenti debbano comunque qualificarsi con username e password all’applicazione.
  • Ovviamente tutti gli utenti potranno utilizzare lo stesso username e password sulla vostra applicazione anche se con diversi utenti windows.

Quest’ultima opzione la cito assieme a tutte le altre semplicemente perché tutto quello di cui ho parlato è una lista di cose che sfortunatamente ho sperimentato sul campo, perché ovviamente noi italiani siamo assolutamente bravissimi a fare l’ufficio complicazione affari semplici e non sempre, soprattutto nelle piccole imprese dove “tanto ci conosciamo tutti e tutti facciamo tutto” si capisce una cosa che è invece ben chiara a qualsiasi azienda nel resto del mondo: Dominio, Username e Password, ovvero identificare chi usa un computer o una applicazione, servono per responsabilizzare le persone, e per poter loggare esattamente chi fa che cosa. Compreso ad esempio copiare una lista di tutti i clienti aziendali da portare con se in una nuova azienda. Ma anche senza voler parlare di possibile dolo, limitare quello che le persone vedono e possono fare in base al loro ruolo in azienda, serve ad evitare che un errore cancelli dati fondamentali, che sicuramente non saranno presenti su alcun Backup aziendale, e dovranno essere ricostruiti dalle fotocopie dell’archivio cartaceo (e per fortuna che abbiamo stampato tutto).

Conclusioni

Non credo di aver mai fatto un articolo senza codice, ma direi che mi fermo qui, prendete tutto questo “Dump” di memoria che ho fatto come una serie di osservazioni da cui prendere spunto. Usatele a vostra discrezione e create le vostre applicazioni come meglio credete. Come dice il saggio:

  • Keep it simple (fate cose semplici)
  • Keep it clean (fate cose pulite, usualmente semplice è anche pulito per default)
  • Non inventate l’acqua calda
  • Usate prima quello che vi forniscono gli strumenti che utilizzate e solo se necessario aggiungete complessità.

matrixy