Regolare l’accesso ai Servizi
L’interesse diffuso per la rete Internet dipende essenzialmente dalla moltitudine di servizi fruibili attraverso questa infrastruttura di comunicazione.
È esperienza quotidiana per ogni utente che, per accedere a un generico servizio, occorre presentare opportune credenziali, le quali stabiliscono l’identità e i diritti di chi richiede il servizio.
In passato, molti gestori per minimizzare il carico di lavoro necessario a configurare e amministrare i server, utilizzavano procedure di controllo delle richieste di accesso elementari (quando non addirittura assenti).
Oggi, solo i servizi di pubblica fruizione non prevedono l’uso di credenziali.
Tutti gli altri implementano procedure di autenticazione più o meno robuste, in grado di tenere lontani utenti illegittimi e hacker dalle informazioni critiche e/o riservate.
Per realizzare una procedura di autenticazione robusta esistono numerose alternative, basate su schemi spesso profondamente diversi.
La prassi prevede che durante la procedura di autenticazione siano verificate le credenziali dell’utente richiedente il servizio (client).
Esistono però situazioni in cui può essere utile o necessario autenticare anche il server. In questi casi è richiesta la presenza di uno schema che consenta la mutua autenticazione di entrambi i partecipanti.
Anche se l’interesse per la sicurezza ha rapidamente contagiato molti utenti e amministratori di servizi, è impensabile implementare lo stesso livello di sicurezza in tutte le applicazioni.
Un elevato grado di sicurezza si traduce immancabilmente nell’adozione di sistemi crittografici, anche molto complessi, che rallentano le prestazioni e la velocità di accesso al singolo servizio.
Per questo, i servizi che non coinvolgono utenti e dati di particolare interesse per un hacker, sono sprovvisti di sistemi crittografici a vantaggio di una maggiore fruibilità.
In tutti gli altri casi, l’accesso alle informazioni deve essere invece regolato con strumenti crittografici moderni e affidabili.
Indipendentemente dall’adozione di soluzioni crittografiche, indispensabili anche per proteggere l’integrità e la riservatezza delle informazioni scambiate, ogni gestore dovrebbe, prima di consentirne l’accesso, stabilire cosa serve conoscere riguardo il richiedente il servizio.
Alcuni servizi non prevedono di determinare l’identità del richiedente e consentono accesso anonimo a tutti (apertura completa).
Altri prevedono di stabilire addirittura l’identità fisica dell’utente onde evitare possibili scenari di ripudio delle operazioni effettuate attraverso un determinato servizio.
In uno scenario di apertura completa, esistono due semplici soluzioni:
- adottare un protocollo applicativo che non prevede l’identificazione dei partecipanti (in modo particolare del client);
- impiegare un protocollo applicativo che prevede l’identificazione dei partecipanti, ma configurando il server in modo da consentire l’accesso in maniera anonima.
Un esempio riconducibile alla prima proposta è la versione originale del protocollo HTTP, utilizzato nell’ambito del servizio WWW.
Alla seconda proposta è invece riconducibile il servizio per lo scambio anonimo di file (FTP anonymous).
Ricorrere al protocollo FTP, che prevede l’identificazione del richiedente, ma disattivando tale funzionalità, può sembrare un’aperta violazione delle più elementari norme di sicurezza. Rappresenta invece, il metodo generalmente più diffuso per la realizzazione di un servizio per il downloading di informazioni di pubblico dominio (trasferimento dati dal server al client).
Per accedere al server FTP in modalità anonima, è sufficiente che il richiedente specifichi come identità il nome convenzionale anonymous e come credenziali utente (di seguito indicate con il termine password) una qualsiasi stringa alfanumerica.
Il server consente l’accesso al servizio FTP indipendentemente dalla password presentata, offrendo all’utente un sottoinsieme di comandi per il downloading di file contenuti in apposite directory pubbliche.
Per semplicità, l’identità convenzionale può essere sottointesa, e come credenziale utente può essere accettata anche la sequenza NULL.
Usare uno di questi approcci, nella realizzazione di un servizio Internet di pubblico accesso, ha il fascino della semplicità, non richiede l’ideazione di un nuovo protocollo e neanche la sostanziale modifica di uno esistente.
Il servizio così realizzato è più semplice da accedere e da gestire senza la pesantezza di dover gestire liste di utenti autorizzati di dimensione crescente, all’aumentare della popolarità del servizio stesso.
Poiché in tali liste a ogni utente è associata una o più password, l’accesso in lettura e scrittura alle stesse deve essere protetto accuratamente.
Per evitare che l’amministratore del sistema (o un hacker che ha guadagnato in maniera illegittima diritti pari a quelli dell’amministratore del sistema) possa ricavare una password, semplicemente osservando il contenuto del repository contenente le credenziali, tale informazione non viene memorizzata in chiaro dal sistema.
In alcuni sistemi operativi l’informazione memorizzata nel file è il risultato dell’applicazione di una funzione di digest a un ingresso ottenuto dalla concatenazione della password e di un seme pseudocasuale legato al nome utente.
In altri sistemi la password viene usata come chiave per codificare una sequenza prestabilita con algoritmi di cifratura simmetrici.
L’aggiunta di un seme pseudocasuale scongiura l’eventualità che password uguali di utenti diversi producano uguali risultati all’uscita della funzione crittografica prescelta.
Generalmente, servizi che non adottano una procedura esplicita per stabilire l’identità del richiedente, mettono a disposizione solo un sottoinsieme di comandi, per il trasferimento delle informazioni in una sola direzione (di solito dal server al client).
I servizi internet che oggi rinunciano completamente all’uso di procedure per individuare l’identità degli utenti, stanno diventando un’eccezione.
L’uso di risorse di calcolo, l’accesso a banche dati ristrette, il commercio elettronico sono solo alcuni esempi di applicazioni che richiedono l’adozione di un completo schema di sicurezza, in cui stabilire l’identità dell’utente, rappresenta solo la fase preliminare.
Una corretta politica di accesso al servizio prevede, infatti, di stabilire l’identità degli utenti richiedenti, ma anche di definire in maniera particolareggiata quello che essi possono fare, una volta all’interno del sistema, inclusa la possibilità di tracciare le azioni effettivamente compiute dagli utenti durante la fruizione del servizio.
La funzione che consente di stabilire l’identità dei partecipanti viene definita come funzione di autenticazione (authentication).
Nei moderni servizi Internet ad essa sono affiancate funzioni di autorizzazione (authorization) e di Accounting.
La funzione di autorizzazione consente di stabilire cosa l’utente può richiedere tramite il servizio, fornendo di fatto la possibilità di creare diversi profili utente supportati dallo stesso servizio.
La funzione di registrazione o Accounting, consiste invece nell’azione di registrare tutto quello che l’utente, precedentemente autorizzato, effettivamente compie durante l’accesso al servizio.
Una politica di accesso al servizio veramente completa si compone di tutte e tre le funzioni.
Una politica che implementa tutte e tre le componenti viene indicata conforme allo schema AAA (Authentication, Authorization, Accounting).
Come già avviene nelle procedure che consentono di determinare l’integrità dei dati scambiati, anche nelle procedure di autenticazione possono essere utilizzate sia funzioni di digest sia funzioni crittografiche simmetriche o asimmetriche, per produrre credenziali univocamente riconducibili a uno dei partecipanti.
Il risultato del processo di codifica viene denominato authentication code.
Il codice usato come credenziale di autenticazione deve essere univoco per ogni utente che fa richiesta di accesso al servizio.
L’integrità e l’origine del messaggio trasmesso deve poter essere verificata dal ricevente per poterlo utilizzare all’interno di uno schema AAA.
