如果你是一名面向基础设施的安全专业人员，那么在目前的IT行业中只关注应用程序安全可能会让你感觉到自己跟不上形势。然而，在很多情况下应用安全专家还是要依靠基础设施小组来提供安全基础，命名和目录服务便是其中的一个典型例子。

　　在本文中，我们将探讨为何在保证了命名和目录服务、轻量级目录访问协议(LDAP)之后，有助于建立一个坚实的、应用程序可信任的平台。

　　LDAP基础

　　LDAP广泛用于内部和外部应用程序，提供基于多种平台的用户目录服务。LDAP能够提供用户验证服务;通过将成员身份表示为特定应用程序的角色，它有助于应用程序进行授权和访问控制决策;它还也可以用来存储用户的偏好和特权信息。

　　微软Active Directory提供了LDAP接口，它可以连接到Windows特定的用户数据，而Active Directory和Active Directory应用程序模式(ADAM)都被应用程序作为用户信息的主要数据存储区。用户目录服务其他的选项还包括OpenLDAP项目、企业软件(如IBM Lotus Domino和Novell的e-Directory)，它们往往通过使用LDAP进行扩展。

　　确保LDAP的安全

　　为了保证LDAP的安全，你需要对其进行一次初步的风险评估，从而获得它在特定应用环境中的使用情况。如果该协议用于验证或访问控制决策，那么一些潜在的威胁必须得到解决。在这种情况下，头号威胁包括LDAP通讯截取、用户证书的泄露、高级权级被匿名或普通用户所滥用，以及对LDAP数据过分依赖而导致的错误。

　　有一些方法可以用来强化LDAP的安装，从而防御来自这些方面的威胁。首先，所有的LDAP连接应限于仅在安全的传输层(通常是SSL)上使用，以防止证书被拦截。微软还通过包含客户端和服务器的完整配置选项来支持对LDAP查询和响应的加密。

　　不过，传输层加密并没有严格的服务器证书为客户端的相关政策进行验证，所以还不足以保护证书被 “中间人”攻击盗取。LDAP身份验证可以使用包括向服务器明文提交用户凭据、摘要式身份验证、Kerberos或挑战-应答在内的多种认证机制。建议使用Kerberos或challenge-response机制，特别是在不支持传输层加密的时候。

　　此外，如果LDAP的用户密码存储在数据存储区里(通常已对密码进行哈希处理)，如果权限设置的不正确，那么密码可以被LDAP目录中的任何人所检索到。而实际上只有具备相应权限的应用程序才能被允许查询此值，但也不能访问匿名的或普通用户的身份资料。

　　如果你安装了一个专用的LDAP，不打算提供给最终用户使用;或者，你所有的用户都在Active Directory这样单一认证平台上，那么你应该考虑禁用匿名绑定到LDAP目录。不这样做会导致信息泄露，包括用户信息;而在Active Directory下，一些有关数据存储的基本配置信息也会泄露。

　　当应用程序为了包括那些跟应用程序特定功能相关的数据域而对LDAP架构进行扩展时，用于访问LDAP的应用程序ID应该被加入到一个访问组中去。此访问组有权查询特定领域和拒绝其他用户和组织的访问。

　　有两个和目录结构和完整性相关的安全风险，为了解决这一问题需要应用程序组和基础设施安全专家进行协作。在这些情况下，整个LDAP使用团队需要一个审查过程和准则集。第一个问题是LDAP注入，类似SQL注入的应用层漏洞。如果程序接受用户输入，并直接连接LDAP查询，那么LDAP就可能存在该漏洞。

　　第二个问题是使用LDAP的访问控制决策，而不是使用用户身份、组成员身份和属性检索。LDAP的用户入口在向用户阐述访问控制决策时，还应该明确指出这个问题。开发人员应该保持访问控制列表对应用程序配置数据而言是本地的，并利用LDAP来识别用户和组成员身份，从而提供非安全用户身份的相关信息。

　　警示：当某个目录服务只能供两个应用程序使用时，这些资源往往不断成熟，从而为重要的应用程序承担更多的责任，并发挥关键的安全功能。因此，最好在部署的时候就设计一些安全控制，而不是在应用程序破坏后亡羊补牢。