Encrypt sensitive data within the 389DS database

389-SH-001 - severity: high

Field	Value
Control ID	`389-SH-001`
Severity	high
Type	preventive
Owner	IT Operations
Status	authored
NIST 800-53	SC-28, SC-28(1)
DISA SRG	SRG-APP-000231, SRG-APP-000428

Rationale¶

Data stored in the 389DS database files can be read directly from disk or from backup media if those files are obtained by an unauthorized party. Without attribute-level encryption, an attacker who steals a database volume, a cold backup, or a snapshot gains immediate access to all plaintext attribute values stored in that backend - bypassing all access controls and network-layer protections entirely. Attribute encryption protects individual sensitive attributes at rest by encrypting their values before they are written to the underlying LMDB/BDB database. Note that userPassword is already stored hashed by 389DS; attribute encryption adds a second layer of defense-in-depth by protecting the stored hash from offline extraction. For custom attributes that lack strong hashing - such as social-security numbers, PINs, or other custom identifiers defined in your schema - attribute encryption is the primary protection, ensuring offline disclosure of database files does not expose their unprotected values. This control directly satisfies the protection-of-information-at-rest requirements of NIST SP 800-53 SC-28 and SC-28(1), and is assessed by DISA SRG-APP-000231 (data at rest) and SRG-APP-000428 (cryptographic protections).

Check¶

List attributes currently configured for encryption on the backend.

dsconf <instance> backend attr-encrypt --list <backend_name>

Remediation¶

Enable attribute encryption for sensitive attributes on the backend, then restart.

dsconf <instance> backend attr-encrypt --add-attr userPassword <backend_name>
dsctl <instance> restart

References¶

Red Hat Directory Server - Securing Data

Implementation Notes¶

Attribute encryption requires TLS to be configured on the instance beforehand, because the server's certificate is used to wrap the symmetric key that protects the encrypted attributes. Apply this control per-backend: each directory suffix has its own backend database (e.g., userRoot), and --add-attr must be run against each backend that holds sensitive data. After enabling encryption, only newly written or replicated entries are automatically encrypted; existing entries must be re-encrypted by exporting and reimporting the database (or via replication from an encrypted replica) as documented in the Red Hat Directory Server administration guide. A server restart is required after modifying attribute encryption configuration.