Passa al contenuto principale

6. Considerazioni sulla sicurezza

Le questioni di sicurezza sono discusse in tutto il documento. La conclusione, non sorprendente, è che la sicurezza è parte integrante e necessaria di LDAP. Questa sezione discute una serie di considerazioni sulla sicurezza relative a LDAP.

6.1. Considerazioni generali sulla sicurezza di LDAP​

LDAP stesso non fornisce alcuna sicurezza né protezione dall'accesso o dall'aggiornamento della directory con mezzi diversi dal protocollo LDAP, ad esempio dall'ispezione dei file di database del server da parte degli amministratori di database.

Dati sensibili possono essere trasportati in quasi qualsiasi messaggio LDAP, e la loro divulgazione può essere soggetta a leggi sulla privacy o ad altre normative legali in molti paesi. Gli implementatori dovrebbero adottare misure adeguate per proteggere i dati sensibili dalla divulgazione a entità non autorizzate.

Una sessione su cui il client non ha stabilito servizi di integrità e riservatezza dei dati (ad esempio tramite StartTLS, IPsec o un meccanismo SASL adeguato) è soggetta ad attacchi man-in-the-middle volti a visualizzare e modificare le informazioni in transito. Gli implementatori di client e server DOVREBBERO (SHOULD) adottare misure per proteggere i dati sensibili nella sessione LDAP da questi attacchi usando i servizi di protezione dei dati discussi in questo documento. Client e server dovrebbero offrire la possibilità di essere configurati per richiedere tali protezioni. Un resultCode

confidentialityRequired indica che il server richiede l'instaurazione di una protezione (più forte) della riservatezza dei dati per eseguire l'operazione richiesta.

Il controllo degli accessi dovrebbe essere sempre applicato quando si leggono informazioni sensibili o si aggiornano informazioni di directory.

Vari fattori di sicurezza, tra cui le informazioni di autenticazione e autorizzazione e i servizi di sicurezza dei dati, possono cambiare nel corso della sessione LDAP, o persino durante l'esecuzione di una particolare operazione. Le implementazioni dovrebbero essere robuste nella gestione di fattori di sicurezza mutevoli.

6.2. Considerazioni sulla sicurezza di StartTLS​

Tutta la sicurezza acquisita con l'uso dell'operazione StartTLS è acquisita con l'uso di TLS stesso. L'operazione StartTLS, da sola, non fornisce alcuna sicurezza aggiuntiva.

Il livello di sicurezza fornito dall'uso di TLS dipende direttamente sia dalla qualità dell'implementazione TLS usata sia dal modo in cui tale implementazione è utilizzata. Inoltre, un attaccante man-in-the-middle può rimuovere l'operazione estesa StartTLS dall'attributo 'supportedExtension' del DSE radice. Entrambe le parti DOVREBBERO (SHOULD) accertare e accettare indipendentemente il livello di sicurezza raggiunto una volta stabilito TLS e prima di iniziare a usare la sessione protetta da TLS. Ad esempio, il livello di sicurezza del livello TLS potrebbe essere stato negoziato al ribasso fino al testo in chiaro.

I client DEVONO (MUST) o avvisare l'utente quando il livello di sicurezza raggiunto non fornisce un livello accettabile di protezione della riservatezza e/o dell'integrità dei dati, oppure essere configurabili per rifiutare di procedere senza un livello di sicurezza accettabile.

Come affermato nella sezione 3.1.2, un server può usare una politica di sicurezza locale per determinare se completare con successo la negoziazione TLS. Le informazioni nel certificato dell'utente emesse o verificate dall'autorità di certificazione dovrebbero essere usate dall'amministratore della politica nel configurare la politica di identificazione e autorizzazione.

Gli implementatori di server DOVREBBERO (SHOULD) consentire agli amministratori del server di scegliere se e quando sono richieste la riservatezza e l'integrità dei dati, nonché di scegliere se è richiesta l'autenticazione del client durante l'handshake TLS.

Gli implementatori dovrebbero conoscere e comprendere le considerazioni sulla sicurezza di TLS discusse nella specifica TLS [RFC4346].

6.3. Considerazioni sulla sicurezza dell'operazione Bind​

Questa sezione discute diverse considerazioni sulla sicurezza rilevanti per l'autenticazione LDAP tramite l'operazione Bind.

6.3.1. Considerazioni sulla sicurezza del meccanismo non autenticato​

L'esperienza operativa mostra che i client possono (e spesso effettivamente lo fanno) fare un uso improprio del meccanismo di autenticazione non autenticata del metodo Bind semplice (vedere la sezione 5.1.2). Ad esempio, un programma client può decidere di concedere l'accesso a informazioni non di directory sulla base del completamento con successo di un'operazione Bind. Le implementazioni server LDAP possono restituire una risposta di successo a una richiesta Bind non autenticata. Ciò può lasciare erroneamente il client con l'impressione che il server abbia autenticato con successo l'identità rappresentata dal nome distinto, quando in realtà è stato stabilito uno stato di autorizzazione anonimo. I client che usano i risultati di un'operazione Bind semplice per prendere decisioni di autorizzazione dovrebbero rilevare attivamente le richieste Bind non autenticate (verificando che la password fornita non sia vuota) e reagire in modo appropriato.

6.3.2. Considerazioni sulla sicurezza del meccanismo nome/password​

Il meccanismo di autenticazione nome/password del metodo Bind semplice divulga la password al server, il che costituisce un rischio di sicurezza intrinseco. Esistono altri meccanismi, come SASL DIGEST-MD5 [DIGEST-MD5], che non divulgano la password al server.

6.3.3. Considerazioni sulla sicurezza relative alle password​

LDAP consente attributi password multivalore. Nei sistemi in cui si prevede che le voci abbiano una e una sola password, dovrebbero essere previsti controlli amministrativi per imporre questo comportamento.

L'uso di password in chiaro e di altre credenziali di autenticazione non protette è fortemente sconsigliato su reti aperte quando il servizio di trasporto sottostante non può garantire la riservatezza. Le implementazioni LDAP NON DOVREBBERO (SHOULD NOT) supportare per impostazione predefinita metodi di autenticazione che usano password in chiaro e altre credenziali di autenticazione non protette, a meno che i dati sulla sessione siano protetti con TLS o altra protezione della riservatezza e dell'integrità dei dati.

La trasmissione di password in chiaro — tipicamente per autenticazione o modifica — comporta un rischio di sicurezza significativo. Tale rischio può essere evitato usando meccanismi di autenticazione SASL [RFC4422] che non trasmettono password in chiaro, oppure negoziando servizi di riservatezza dei dati a livello di trasporto o di sessione prima di trasmettere i valori di password.

Per attenuare i rischi di sicurezza associati al trasferimento di password, un'implementazione server che supporta un meccanismo di autenticazione basato su password che trasmette password in chiaro DEVE (MUST) supportare un meccanismo di politica che, al momento dell'autenticazione o della modifica della password, richieda che:

     sia stato installato con successo un livello TLS.

     OPPURE

     sia stato fornito un altro meccanismo di riservatezza dei dati che protegge il valore della password dall'intercettazione.

     OPPURE

     il server restituisca un resultCode confidentialityRequired per l'operazione (ossia Bind nome/password con valore di password, Bind SASL che trasmette un valore di password in chiaro, add o modify che includono un valore userPassword e così via), anche se il valore della password è corretto.

Le implementazioni server potrebbero anche voler fornire meccanismi di politica per invalidare o altrimenti proteggere gli account nelle situazioni in cui un server rileva che la password di un account è stata trasmessa in chiaro.

6.3.4. Considerazioni sulla sicurezza delle password con hash​

Alcuni meccanismi di autenticazione (ad esempio DIGEST-MD5) trasmettono un hash del valore della password che può essere vulnerabile ad attacchi di dizionario offline. Gli implementatori dovrebbero aver cura di proteggere tali valori di password con hash durante la trasmissione usando TLS o altri meccanismi di riservatezza.

6.4. Considerazioni sulla sicurezza di SASL​

Finché non è installato un servizio di integrità dei dati su una sessione LDAP, un attaccante può modificare i valori trasmessi della risposta all'attributo 'supportedSASLMechanisms' e degradare così l'elenco dei meccanismi SASL disponibili fino a includere solo il meccanismo meno sicuro. Per rilevare questo tipo di attacco, il client può recuperare i meccanismi SASL che il server rende disponibili sia prima sia dopo l'installazione del servizio di integrità dei dati su una sessione LDAP. Se il client rileva che l'elenco protetto dall'integrità (l'elenco ottenuto dopo l'installazione del servizio di integrità dei dati) contiene un meccanismo più forte di quelli dell'elenco ottenuto in precedenza, il client dovrebbe presumere che l'elenco ottenuto in precedenza sia stato modificato da un attaccante. In questo caso si raccomanda che il client chiuda la connessione di trasporto sottostante e si riconnetta per ristabilire la sessione.

6.5. Considerazioni sulla sicurezza correlate​

Si applicano ulteriori considerazioni sulla sicurezza relative ai vari metodi e meccanismi di autenticazione discussi in questo documento, che si trovano in [RFC4422], [RFC4013], [RFC3454] e [RFC3629].