第 10 章 配置属性加密


目录服务器提供许多机制来保护对敏感数据的访问,如访问控制规则,以防止未授权用户读取条目或属性中的某些条目或属性,以防止数据在不信任的网络上破坏和篡改。但是,如果服务器数据库文件的副本应属于未授权的个人,他们可能会从这些文件中提取敏感信息。由于数据库中的信息以纯文本形式存储,一些敏感信息(如政府身份标识号或密码)可能无法通过标准访问控制措施进行保护。
对于高敏感信息,这些信息丢失的潜在可能会带来重大安全风险。为了删除该安全风险,目录服务器允许加密部分数据库。加密后,即使攻击者拥有服务器数据库文件的副本,数据也会安全。
数据库加密允许在数据库中加密属性。加密和加密密码每个后端都可配置每个属性。配置后,特定属性的每个实例(甚至索引数据)会针对该数据库中存储的每个条目加密。
属性加密的另一个优点是,加密值只能发送到大于 1 的安全 Strength Factor (SSF)的客户端。
注意
加密数据有一个例外:作为条目的 RDN 的任何值都不会在条目 DN 中加密。例如,如果 uid 属性被加密,则该值会在条目中加密,但显示在 DN 中:
dn: uid=jsmith1234,ou=People,dc=example,dc=com
...
uid:: Sf04P9nJWGU1qiW9JJCGRg==
Copy to Clipboard Toggle word wrap
这将允许某人发现加密值。
条目 DN 中使用的任何属性都无法有效地加密,因为它将始终显示在 DN 中。请注意,使用哪些属性来构建 DN 并相应地设计属性加密模型。
索引的属性可以加密,属性加密与 eqpres indexing 完全兼容。通常派生自属性值的索引文件的内容也被加密,以防止攻击者从索引分析中恢复部分或所有加密数据。
由于服务器在为加密属性查找索引前预加密所有索引,因此对服务器性能对使用加密索引有一些影响,但其效果不够严重,但其效果不足以方便使用索引。

10.1. 加密密钥

要使用属性加密,必须为 TLS 配置服务器并启用了 TLS,因为属性加密使用服务器的 TLS 加密密钥和与 TLS 相同的 PIN 输入法。PIN 必须在服务器启动时手动输入,或者必须使用 PIN 文件。
随机生成的对称密码密钥用于加密和解密属性数据。每个配置的密码都会使用单独的密钥。这些密钥使用服务器的 TLS 证书中的公钥进行 嵌套,生成的嵌套密钥存储在服务器的配置文件中。属性加密的有效优势不高于用于嵌套的服务器 TLS 密钥的强度。在无法访问服务器的私钥的情况下,无法从嵌套的副本恢复对称密钥。
警告
没有恢复丢失密钥的机制。因此,安全地备份服务器的证书数据库非常重要。如果服务器证书丢失,则无法解密存储在其数据库中的任何加密数据。
警告
如果 TLS 证书过期并需要续订,请在续订前导出加密的后端实例。更新证书,然后重新导入导出的 LDIF 文件。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat