Negli scenari in cui si presenta la necessità di linkare dati, presenti all'interno di un database, e la nostra applicazione dobbiamo sempre poter garantire due fattori importantissimi.
Confidenza dei messaggi
I dati devono essere codificati e dobbiamo garantire che resteranno privati durante il viaggio.
Integrità del messaggio
I dati devono essere firmati per assicurarci che siano rimasti inalterati.
Esistono due categorie di scenari principali in cui questo dovrebbe essere applicato.
Full Security
In questo scenario TUTTI i dati trasmessi devono essere messi al sicuro.
Es: Internet Home Banking, in questo caso tutte le informazioni devono essere messe al sicuro.
Selected Security
Solo una selezionata parte dei dati viene messa al sicuro.
Es: Servizi rivolti al personale, in questo tipo di applicazioni, solo alcune parti devono essere messe al sicuro (Dati sensibili e Dlgs 196/2003 dovrebbe ricordarvi qualcosa).
E' bene tenere a mente che, nel caso in cui si utilizzi Sql Authentication, dobbiamo applicare un sistema di protezione per username e password, in modo tale da non comprometterle durante il viaggio (Sniffing).
Come e Cosa fare
Abbiamo due strade da seguire per garantire un livello di sicurezza accetabile.
- IPSec
- SSL
Come scegliere
Scegliere tra IPSec e SSL non è proprio una passeggiata, entrambi forniscono buoni livelli di protezione.. tutta via dovremmo prendere una decisione in base ad alcuni fattori importanti. Questi fattori, per esempio, si possono identificare in Versione del Sistema Operativo e versione del Database su cui sono contenuti i dati.
Connettersi con Privilegi Leasted
Connettersi al database con un utenza di tipo least significa stabilire una connessione in un ambiente in cui si hanno privilegi limitati alle proprie reali necessità. Se devo utilizzare il database A perchè devo vedere anche B e C e D? Va da se, che connettersi con l'account sa non è proprio la scelta più felice di questo mondo, così come connettersi con gli utenti appartenenti al gruppo sysadmins e db_owner.
Nel momento in cui disegniamo un database, pensiamo anche alle modalità in con cui ci connetteremo ad esso. Ecco due possibili vie.
1) Il Database crede nell'applicazione
2) Il Database e i pool basati su ruoli
Il Database crede nell'applicazione
Prendiamo come esempio una applicazione finanziaria. Questa applicazione è responsabile per la gestione degli accessi legati ad autentificazione e autorizzazione. In questo caso possiamo utilizzare le connessioni tramite un singolo account trusted ( il quale può corrispondere ad una login di SQL Server o ad un Account di Windows mappato in un login di SQL). Se stiamo utilizzando la Windows Authentication, questo vuol dire che stiamo dando il permesso al process identity (es: asp.net worker process) ad accedere al database.
Il Database e i pool basati su ruoli
Possiamo usare pool di connessione separati in base ai ruoli definiti dall'applicazione, per esempio possiamo utilizzare un pool per gli addetti di un call center, un pool per gli amministratori etc etc. E' bene specificare che questo tipo di connessioni non devono per forza basarsi su di una Windows Authentication. utilizzarle, significa non inviare le credenziali attraverso la rete. Ma ricordiamoci che utilizzarle può richiedere alcune particolari sfide che non sempre siamo pronti ad affrontare (es problematiche interne aziendali).