Motivi per veicolare il contesto utente fino al database

Ho sempre piacevolmente apprezzato le implicazioni dell’autenticazione integrata windows e nelle mie applicazioni, a meno che non mi sia esplicitamente richiesto, cerco sempre di portare il contesto di sicurezza dell’utente più avanti possibile nelle sue varie componenti.

Per esempio: il browser viene eseguito nel contesto di sicurezza dell’utente che si logga al computer, poi l’utente si autentica al Web server e le pagine chiamate ed i componenti software che le sottintendono sono eseguiti nel contesto di sicurezza dell’utente stesso. Similmente accade per l’autenticazione e la fruizione di altri servizi di rete o della connessione al database (anche in cascata tramite linked servers).

La seguente figura rappresenta tale scenario.

Authenticatione and Delegation

Dopo aver effettuato un brevissimo e sintetico excursus sui concetti di base, che verranno dati per scontati nei miei prossimi articoli, comincerò a descriverne l’implementazione. Nei prossimi articoli descriverò come implementare questa funzionalità in un ambiente distribuito per mezzo del modello di impersonazione e delega.

Autenticazione integrata

Non mi dilungo a descrivere cos’é l’autenticazione integrata offerta dalla tecnologia Microsoft Windows, se non per porre l’enfasi sui principali vantaggi e benefici:

  • per l’utente è principalmente il single sign-on ovvero la fruizione implicita dei servizi e delle applicazioni dopo l’unico login (il famoso Ctrl-Alt-Canc) !
  • per gli amministratori dell’infrastruttura di un’organizzazione, e quindi di un dominio o meglio di foreste Active Directory, è la drastica diminuzione del carico di lavoro, potendo gestire gli account degli utenti (che possono facilmente superare la migliaia di unità anche per una media azienda) e le policies in un unico punto.
  • per l’organizzazione l’aumento implicito della sicurezza e dell’affidabilità

 

Autorizzazioni sulle risorse

Le autorizzazioni sono concesse sulle risorse, che siano esse files e cartelle sul filesystem, share di rete, stampanti, virtual directory e URI (cfr. IIS), appartenenza a ruoli applicativi (cfr. Authorization Manager), mailbox (cfr. Exchange), oggetti di Active Directory,  GPO, ecc.

Le best practices e Microsoft consigliano, ove possibile, di assegnare tali autorizzazioni non direttamente ai singoli utenti, ma ai gruppi (security groups) che li contengono. Con le ultime features di Active Directory è possibile effettuare il nesting dei gruppi in svariati livelli.

Web applications e IIS 

Il Web, come piattaforma, è diventato sempre più importante per le aziende, non solo perchè permette di ridurre i tempi e i costi di deployment delle applicazioni, ma anche perché è diventato implicitamente strumento di produttività e collaborazione (cfr. Microsoft Sharepoint) anche tramite i consueti strumenti Office che vi si connettono per pubblicare e condividere documenti.

Nelle organizzazioni che utilizzano i sistemi Microsoft l’accesso e la fruizione delle risorse dell’Intranet aziendale (e dell’Extranet) deve essere il più semplice possibile e può beneficiare con IIS del single sign-on, grazie dell’autenticazione integrata.

Il beneficio dell’autenticazione integrata Windows è duplice, cioé gli utenti vengono riconosciuti e autenticati automaticamente:

  • in modo trasparente per gli utenti, senza che debbano inserire alcuna credenziale
  • e senza sforzo da parte degli sviluppatori e amministratori che non devono implementare e manutenere alcun archivio degli utenti, essendo questo integrato in Active Directory

L’autenticazione di IIS

IIS può autenticare quindi gli utenti di dominio in modo trasparente tramite l’integrazione con Active Directory; i prerequisiti sono i seguenti:

  1. Browser IE recente (5.5 o superiore), se è abilitata tra le opzioni avanzate “Abilita autenticazione windows integrata” e se il dominio relativo all’URL viene censito tra i siti dell’ “Intranet locale”
  2. sul server IIS, il site (o la virtual directory) deve essere impostato nelle opzioni di sicurezza per accettare solo l’autenticazione integrata

N.B. in un ambiente Corporate il primo punto può essere ottenuto con estrema facilità con le Group Policies o con gli script di Logon.

 Impersonificazione

 Generalmente il codice legato ad una pagina web, e quindi l’accesso alle risorse, viene eseguito nel contesto di sicurezza di IIS (di default IUSR_servername) o dell’Application Pool (solitamente NETWORK SERVICE o LOCAL SYSTEM), a seconda che si tratti di una pagina html/.asp o di una pagina aspx/.NET.

In qualche caso è utile che il codice venga eseguito nel contesto di sicurezza dell’utente chiamante, ovvero che il servizio/pool impersonifichi il chiamate (impersonate).

Per esempio se utilizzassimo l’impersonazione:

  • l’accesso ai documenti del filesystem, verrebbe così regolato dalle DACL impostate sul filesystem; non avremmo bisogno di costruirci le strutture dati per replicare tale funzionalità
  • similmente verrebbe regolato l’accesso alle risorse e agli oggetti di rete
  • anche l’utilizzo di oggetti COM/DCOM potrebbe essere regolato dalle autorizzazioni già applicate per quell’utente o ai gruppi ai queli l’utente stesso appartiene

 Per abilitare l’impersonazione in un’applicazione .NET, basta impostare la seguente configurazione nel web.config:

    <system.web>
        <authentication mode="Windows" />
        <identity impersonate="true"/>
    </system.web>

 

 Accesso al database SQL Server

Un’applicazione web può accedere in due modi ad un database, tramite autenticazione SQL (standard security) oppure tramite autenticazione integrata (trusted connection). In particolare quindi, se si utilizza una SqlConnection .NET, le stringhe di connessione (connection strings) possono essere rispettivamente:

Data Source=myServer;Initial Catalog=dbName;User Id=username;Password=password;

Data Source=myServer;Initial Catalog=dbName;Integrated Security=SSPI;

nel primo caso la connessione avverrà tramite la login specificata, nel secondo con le credenziali dell’utente autenticato da IIS.

Due modelli di sicurezza a confronto

Bisogna fare alcune considerazioni nell’utilizzo dei due modelli,
ovvero il modello che utilizza un’utenza o login fissa per connettersi al database (trusted subsystem) e quello che utilizza l’impersonificazione ed una trusted connection (impersontation/delegation);
entrambi i modelli hanno vantaggi e svantaggi.

I vantaggi del trusted subsystem, cioè quello in cui il database si fida della login utilizzata dall’applicazione indipendentemente dall’utente originale, sono:

  • scalabilità. il connection pool è molto efficiente, poichè il contesto di sicurezza rimane sempre lo stesso
  • gestione minima delle ACL, che sono configurate solo per una singola identità.
  • l’utente non ha accesso diretto ai dati

e gli svantaggi:

  • l’auditing è difficile, non potendo distinguere l’utente chiamante effettivo
  • rischio elevato se l’application server viene compromesso, poichè ad esso viene garantito elevato accesso alle risorse.

Invece i vantaggi del modello ad impersonazione/delega sono:

  • Auditing semplice tramite le features offerte dal sistema operativo
  • Auditing a livello di tutti gli strati dell’applicazione
  • Accesso granulare, impostabile anche fino a livello utente

Gli svantaggi sono:

  • Il connection pool non è utilizzato efficientemente, poichè ogni connessione ha il suo specifico contesto
  • Il carico amministrativo è superiore, dovendo eventualmente essere gestite le ACL per utente.

Nel modello ad impersonazione, è come se l’utente facesse una connessione al database, e quindi venisse riconosciuto dallo stesso. Le funzioni o le stored procedures potrebbero restituire risultati diversi a seconda dell’utente che le sta eseguendo; e le viste potrebbero restituire dati diversi (partizionati orrizontalmente) sempre in funzione dell’utente.

Un esempio pratico banale: se nella tabella MOVIMENTI ci fossero le movimentazioni in denaro in funzione dell’utente, allora la vista potrebbe ritornare solo le movimentazioni dell’utente collegato

CREATE VIEW v_movimenti AS SELECT * FROM movimenti WHERE utente = system_user;

e questo ci eviterebbe la noia di creare più viste…

Motivazioni per veicolare il contesto utente

Anche da ciò che è stato prima esposto, si può capire come le più comuni ragioni per portare il contesto dell’utente chiamante fino al database siano:

  • Necessità di effettuare l’auditing a livello di utenza, in contrapposizione all’auditing a livello applicativo.
  • Necessità di avere un accesso granulare al database e specifiche restrizioni sui suoi oggetti: specifici utenti possono leggere o eseguire alcuni oggetti, mentre altri possono scrivere su altri.
  • Necessità di filtrare i risultati a livello database in funzione dell’utente connesso, utilizzando anche il codice in view, funzioni e stored procedures
  • Maggior sicurezza in caso di application server compromessi
  • L’accesso al database è effettuato da diversi canali ( applicazioni web, applicazioni client/server, connessioni dirette tramite client sql, ecc.) per i quali devono essere garantite le autorizzazioni e la visibilità in funzione dell’utente connesso.

Da tenere in considerazione gli aspetti legati alla minor scalabilità e il carico derivante dal fatto di applicare i permessi direttamente sulle utenze, e non sui ruoli.

 Conclusioni

Riassumendo, le condizioni per poter veicolare il contesto di sicurezza del chiamante fino al database, sono le seguenti:

  1. il browser deve essere Interne Explorer e deve essere abilitata l’Autenticazione Integrata Windows
  2. il sito chiamato deve trovarsi tra i siti dell’Intranet
  3. l’applicazione ospitata dall’IIS deve aver abilitata solo l’Autenticazione Integrata
  4. nel caso di applicazioni .NET, l’applicazione deve Impersonare l’utente
  5. la connessione al database SQL Server deve essere trusted
  6. ovviamente l’utente deve essere abilitato a connettersi allo specifico database

Le precedenti condizioni sono solo necessarie, nel senso che non bastano in tutti gli scenari; diventano anche sufficienti quando il sistema viene interamente implementato su un singolo server, ovvero l’IIS e il SQL Server risiedono sulla stesso server oppure quando l’IIS ha abilitata la basic authentication (punto 3; ovviamente si perde la feature del single sign-on).

Se viceversa si volesse implementare questa feature in un sistema distribuito, allora bisognerebbe modificare leggermente il modello affinché l’IIS possa impersonare l’utente anche al di fuori della stessa macchina (impersonate & delegate)

Questa voce è stata pubblicata in Active Directory, SQL Server, Web e contrassegnata con , , , , , . Contrassegna il permalink.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


*