跳到主要内容

6. 安全考虑 (Security Considerations)

安全问题贯穿本文档的讨论. 不出意料的结论是: 安全是 LDAP 一个不可分割且必要的组成部分. 本节讨论若干与 LDAP 相关的安全考虑.

6.1 一般 LDAP 安全考虑 (General LDAP Security Considerations)​

LDAP 本身不提供任何安全或保护, 以防范经由 LDAP 协议以外的方式对目录进行访问或更新, 例如数据库管理员对服务器数据库文件的检视.

敏感数据可能出现在几乎任何 LDAP 消息之中, 其披露在许多国家可能受隐私法律或其他法规的约束. 实现者应当采取适当措施, 保护敏感数据不被披露给未授权的实体.

客户端尚未建立数据完整性与隐私服务 (例如通过 StartTLS, IPsec 或合适的 SASL 机制) 的会话, 容易受到中间人攻击以查看和修改传输中的信息. 客户端和服务器实现者应当采取措施, 通过使用本文档讨论的数据保护服务, 保护 LDAP 会话中的敏感数据免受这些攻击. 客户端和服务器应当提供可配置为要求这些保护的能力. 结果码 confidentialityRequired 表示: 服务器要求建立 (更强的) 数据保密性保护才能执行所请求的操作.

在读取敏感信息或更新目录信息时, 应当始终应用访问控制.

各种安全因素, 包括认证与授权信息以及数据安全服务, 可能在 LDAP 会话期间, 甚至在一次特定操作的执行期间发生变化. 实现在处理变化的安全因素时应当保持健壮.

6.2 StartTLS 安全考虑 (StartTLS Security Considerations)​

经由使用 StartTLS 操作获得的所有安全都来自 TLS 本身的使用. StartTLS 操作本身不提供任何额外的安全.

使用 TLS 所提供的安全级别, 直接取决于所用 TLS 实现的质量以及该实现的使用方式. 此外, 中间人攻击者可以从根 DSE 的 'supportedExtension' 属性中移除 StartTLS 扩展操作. 双方都应当在 TLS 建立之后、开始使用受 TLS 保护的会话之前, 各自独立地确认并同意所达到的安全级别. 例如, TLS 层的安全级别可能被协商降级到明文.

当所达到的安全级别不能提供可接受的数据保密性和/或数据完整性保护时, 客户端必须警告用户, 或者可配置为在安全级别不可接受时拒绝继续.

如第 3.1.2 节所述, 服务器可以使用本地安全策略来决定是否成功完成 TLS 协商. 在配置标识与授权策略时, 策略管理员应当使用用户证书中由认证机构发起或验证的信息.

服务器实现者应当允许服务器管理员选择是否以及何时要求数据保密性和完整性, 并选择是否要求在 TLS 握手期间对客户端进行认证.

实现者应当了解并理解 TLS 规范 [RFC4346] 中讨论的 TLS 安全考虑.

6.3 Bind 操作安全考虑 (Bind Operation Security Considerations)​

本节讨论与经由 Bind 操作进行 LDAP 认证相关的若干安全考虑.

6.3.1 未认证机制安全考虑 (Unauthenticated Mechanism Security Considerations)​

运营经验表明, 客户端能够 (而且经常) 滥用简单 Bind 方法的未认证认证机制 (见第 5.1.2 节). 例如, 客户端程序可能以成功完成一次 Bind 操作为依据, 决定授予对非目录信息的访问. LDAP 服务器实现可能对未认证 Bind 请求返回成功响应. 这可能错误地让客户端以为服务器已经成功认证了该可辨识名称所表示的身份, 而实际上建立的却是一个匿名授权状态. 使用简单 Bind 操作的结果来做授权决策的客户端, 应当主动检测未认证 Bind 请求 (通过验证所提供的口令非空) 并做出恰当反应.

6.3.2 名称/口令机制安全考虑 (Name/Password Mechanism Security Considerations)​

简单 Bind 方法的名称/口令认证机制把口令透露给服务器, 这是一种固有的安全风险. 还存在其他一些不向服务器透露口令的机制, 例如 SASL DIGEST-MD5 [DIGEST-MD5].

LDAP 允许多值口令属性. 在期望条目有且仅有一个口令的系统中, 应当提供管理控制来强制这一行为.

当底层传输服务无法保证保密性时, 强烈不鼓励在开放网络上使用明文口令和其他未受保护的认证凭证. LDAP 实现默认不应当支持使用明文口令和其他未受保护认证凭证的认证方法, 除非会话上的数据受到 TLS 或其他数据保密性与数据完整性保护.

以明文传输口令 -- 通常用于认证或修改 -- 构成重大的安全风险. 可以通过使用不以明文传输口令的 SASL 认证机制 [RFC4422], 或者在传输口令值之前协商传输层或会话层数据保密性服务, 来避免这一风险.

为减轻与口令传输相关的安全风险, 支持任何以明文传输口令的基于口令的认证机制的服务器实现, 必须支持这样一种策略机制: 在认证或口令修改时, 要求满足以下条件之一:

  • 已成功安装 TLS 层.

  • 或者

  • 已提供保护口令值免遭窃听的某些其他数据保密机制.

  • 或者

  • 服务器对该操作返回结果码 confidentialityRequired (即带口令值的名称/口令 Bind, 以明文传输口令值的 SASL Bind, 包含 userPassword 值的 add 或 modify 等), 即便口令值是正确的.

服务器实现可能还想提供策略机制, 在服务器检测到某账户的口令已被明文传输的情况下, 使该账户失效或以其他方式保护该账户.

6.3.4 哈希口令安全考虑 (Hashed Password Security Considerations)​

某些认证机制 (例如 DIGEST-MD5) 传输口令值的哈希, 该哈希可能易受离线字典攻击. 实现者应当注意在传输过程中使用 TLS 或其他保密机制保护此类哈希口令值.

6.4 SASL 安全考虑 (SASL Security Considerations)​

在 LDAP 会话上安装数据完整性服务之前, 攻击者可以修改 'supportedSASLMechanisms' 属性响应的传输值, 从而把可用 SASL 机制列表降级为只包含最不安全的机制. 为检测这种类型的攻击, 客户端可以在 LDAP 会话上安装数据完整性服务之前和之后, 分别检索服务器提供的 SASL 机制. 如果客户端发现受完整性保护的列表 (安装数据完整性服务之后获得的列表) 包含比先前获得列表中的机制更强的机制, 客户端应当假定先前获得的列表已被攻击者修改. 在这种情况下, 建议客户端关闭底层传输连接, 然后重新连接以重建会话.

与本文档讨论的各种认证方法和机制相关的其他安全考虑同样适用, 可在 [RFC4422], [RFC4013], [RFC3454] 和 [RFC3629] 中找到.