Aller au contenu principal

6. Considérations de sécurité

Les questions de sécurité sont examinées tout au long du présent document. La conclusion, peu surprenante, est que la sécurité est une partie intégrante et nécessaire de LDAP. La présente section examine un certain nombre de considérations de sécurité liées à LDAP.

6.1. Considérations générales de sécurité relatives à LDAP​

LDAP lui-même n'offre aucune sécurité ni protection contre l'accès ou la mise à jour de l'annuaire par des moyens autres que le protocole LDAP, par exemple contre l'inspection des fichiers de base de données du serveur par les administrateurs de bases de données.

Des données sensibles peuvent être transportées dans presque n'importe quel message LDAP, et leur divulgation peut être soumise à des lois sur la protection des données ou à d'autres réglementations juridiques dans de nombreux pays. Les implémenteurs devraient prendre des mesures appropriées pour protéger les données sensibles contre la divulgation à des entités non autorisées.

Une session sur laquelle le client n'a pas établi de services d'intégrité et de confidentialité des données (par exemple via StartTLS, IPsec ou un mécanisme SASL approprié) est exposée à des attaques de l'homme du milieu (man-in-the-middle) visant à consulter et modifier les informations en transit. Les implémenteurs de clients et de serveurs DEVRAIENT (SHOULD) prendre des mesures pour protéger les données sensibles de la session LDAP contre ces attaques en utilisant les services de protection des données examinés dans le présent document. Les clients et les serveurs devraient offrir la possibilité d'être configurés pour exiger ces protections. Un resultCode de

confidentialityRequired indique que le serveur exige l'établissement d'une protection (plus forte) de la confidentialité des données afin d'effectuer l'opération demandée.

Un contrôle d'accès devrait toujours être appliqué lors de la lecture d'informations sensibles ou de la mise à jour d'informations d'annuaire.

Divers facteurs de sécurité, notamment les informations d'authentification et d'autorisation et les services de sécurité des données, peuvent changer au cours de la session LDAP, voire pendant l'exécution d'une opération particulière. Les implémentations devraient être robustes dans le traitement de facteurs de sécurité changeants.

6.2. Considérations de sécurité relatives à StartTLS​

Toute la sécurité acquise par l'utilisation de l'opération StartTLS est acquise par l'utilisation de TLS lui-même. L'opération StartTLS, à elle seule, n'apporte aucune sécurité supplémentaire.

Le niveau de sécurité offert par l'utilisation de TLS dépend directement à la fois de la qualité de l'implémentation TLS utilisée et de la manière dont cette implémentation est utilisée. En outre, un attaquant de l'homme du milieu peut retirer l'opération étendue StartTLS de l'attribut 'supportedExtension' du DSE racine. Les deux parties DEVRAIENT (SHOULD) vérifier indépendamment le niveau de sécurité atteint et y consentir une fois TLS établi, et avant de commencer à utiliser la session protégée par TLS. Par exemple, le niveau de sécurité de la couche TLS peut avoir été négocié à la baisse jusqu'au texte en clair.

Les clients DOIVENT (MUST) soit avertir l'utilisateur lorsque le niveau de sécurité atteint n'offre pas un niveau acceptable de protection de la confidentialité et/ou de l'intégrité des données, soit être configurables pour refuser de poursuivre sans un niveau de sécurité acceptable.

Comme indiqué à la section 3.1.2, un serveur peut utiliser une politique de sécurité locale pour déterminer s'il convient de mener à bien la négociation TLS. Les informations du certificat de l'utilisateur qui sont émises ou vérifiées par l'autorité de certification devraient être utilisées par l'administrateur de la politique lors de la configuration de la politique d'identification et d'autorisation.

Les implémenteurs de serveurs DEVRAIENT (SHOULD) permettre aux administrateurs de serveur de choisir si et quand la confidentialité et l'intégrité des données sont exigées, ainsi que de choisir si l'authentification du client pendant la poignée de main TLS est exigée.

Les implémenteurs devraient connaître et comprendre les considérations de sécurité de TLS telles qu'examinées dans la spécification TLS [RFC4346].

6.3. Considérations de sécurité relatives à l'opération Bind​

La présente section examine plusieurs considérations de sécurité relatives à l'authentification LDAP via l'opération Bind.

6.3.1. Considérations de sécurité relatives au mécanisme non authentifié​

L'expérience opérationnelle montre que les clients peuvent (et font fréquemment) un mauvais usage du mécanisme d'authentification non authentifié de la méthode Bind simple (voir la section 5.1.2). Par exemple, un programme client peut décider d'accorder l'accès à des informations autres que celles de l'annuaire sur la base de la réussite d'une opération Bind. Les implémentations de serveur LDAP peuvent renvoyer une réponse de succès à une demande Bind non authentifiée. Cela peut laisser à tort le client avec l'impression que le serveur a authentifié avec succès l'identité représentée par le nom distingué, alors qu'en réalité un état d'autorisation anonyme a été établi. Les clients qui utilisent les résultats d'une opération Bind simple pour prendre des décisions d'autorisation devraient détecter activement les demandes Bind non authentifiées (en vérifiant que le mot de passe fourni n'est pas vide) et réagir de manière appropriée.

6.3.2. Considérations de sécurité relatives au mécanisme nom/mot de passe​

Le mécanisme d'authentification nom/mot de passe de la méthode Bind simple divulgue le mot de passe au serveur, ce qui constitue un risque de sécurité inhérent. Il existe d'autres mécanismes, tels que SASL DIGEST-MD5 [DIGEST-MD5], qui ne divulguent pas le mot de passe au serveur.

6.3.3. Considérations de sécurité relatives aux mots de passe​

LDAP autorise les attributs de mot de passe à valeurs multiples. Dans les systèmes où les entrées sont censées avoir un et un seul mot de passe, des contrôles administratifs devraient être prévus pour imposer ce comportement.

L'utilisation de mots de passe en clair et d'autres informations d'authentification non protégées est fortement déconseillée sur les réseaux ouverts lorsque le service de transport sous-jacent ne peut garantir la confidentialité. Les implémentations LDAP NE DEVRAIENT PAS (SHOULD NOT) prendre en charge par défaut des méthodes d'authentification utilisant des mots de passe en clair et d'autres informations d'authentification non protégées, à moins que les données de la session ne soient protégées au moyen de TLS ou d'une autre protection de la confidentialité et de l'intégrité des données.

La transmission de mots de passe en clair — généralement pour l'authentification ou la modification — présente un risque de sécurité important. Ce risque peut être évité en utilisant des mécanismes d'authentification SASL [RFC4422] qui ne transmettent pas les mots de passe en clair, ou en négociant des services de confidentialité des données au niveau du transport ou de la session avant de transmettre les valeurs de mot de passe.

Pour atténuer les risques de sécurité associés au transfert de mots de passe, une implémentation de serveur qui prend en charge un mécanisme d'authentification fondé sur un mot de passe transmettant les mots de passe en clair DOIT (MUST) prendre en charge un mécanisme de politique qui, au moment de l'authentification ou de la modification du mot de passe, exige que :

     Une couche TLS ait été installée avec succès.

     OU

     Un autre mécanisme de confidentialité des données protégeant la valeur du mot de passe contre l'écoute clandestine ait été fourni.

     OU

     Le serveur renvoie un resultCode de confidentialityRequired pour l'opération (c'est-à-dire un Bind nom/mot de passe avec une valeur de mot de passe, un Bind SASL transmettant une valeur de mot de passe en clair, un add ou un modify incluant une valeur userPassword, etc.), même si la valeur du mot de passe est correcte.

Les implémentations de serveur peuvent également souhaiter fournir des mécanismes de politique visant à invalider ou autrement protéger les comptes dans les situations où un serveur détecte qu'un mot de passe de compte a été transmis en clair.

6.3.4. Considérations de sécurité relatives aux mots de passe hachés​

Certains mécanismes d'authentification (par exemple DIGEST-MD5) transmettent un hachage de la valeur du mot de passe qui peut être vulnérable à des attaques par dictionnaire hors ligne. Les implémenteurs devraient veiller à protéger ces valeurs de mot de passe hachées pendant la transmission, au moyen de TLS ou d'autres mécanismes de confidentialité.

6.4. Considérations de sécurité relatives à SASL​

Tant qu'un service d'intégrité des données n'est pas installé sur une session LDAP, un attaquant peut modifier les valeurs transmises de la réponse à l'attribut 'supportedSASLMechanisms' et ainsi dégrader la liste des mécanismes SASL disponibles pour n'y laisser que le mécanisme le moins sûr. Pour détecter ce type d'attaque, le client peut récupérer les mécanismes SASL que le serveur met à disposition à la fois avant et après l'installation du service d'intégrité des données sur une session LDAP. Si le client constate que la liste protégée par l'intégrité (la liste obtenue après l'installation du service d'intégrité des données) contient un mécanisme plus fort que ceux de la liste obtenue précédemment, le client devrait supposer que la liste obtenue précédemment a été modifiée par un attaquant. Dans ce cas, il est recommandé que le client ferme la connexion de transport sous-jacente, puis se reconnecte pour rétablir la session.

6.5. Considérations de sécurité connexes​

Des considérations de sécurité supplémentaires relatives aux diverses méthodes et mécanismes d'authentification examinés dans le présent document s'appliquent et figurent dans [RFC4422], [RFC4013], [RFC3454] et [RFC3629].