When an encryption-settings definition is compromised, all data encrypted with that definition is vulnerable, and you must stop using the definition immediately.
If an encryption-settings definition becomes compromised, such as an unauthorized individual obtaining access to the encryption key, then any data encrypted with that definition is vulnerable because it can be decrypted using that key. It's important that the encryption-settings database is protected to ensure that its contents remain secure. For example, using file permissions or file system access control lists (ACLs).
In the event that an encryption-settings definition is compromised, stop using the definition immediately. You must re-encrypt any data encrypted with the compromised key with a new definition or purged from the server. Do this on one server at a time to avoid an environment-wide downtime and complete it as quickly as possible on all servers that used this definition at any point in the past to minimize the risk of data exposure.
To respond to a compromised encryption settings definition:
- Create a new encryption-settings definition and make it the preferred definition for new writes.
Ensure that client traffic is routed away from the server instance to be updated.
If the server is accessed through a server, then you can set the
health-check-stateconfiguration property for any LDAP external server definitions that reference that server to have a value of
To ensure that external clients are not allowed to write operations in the server instance, set the
writability-modeglobal configuration property to have a value of
Look at the monitor entries with the
ds-replication-server-handler-monitor-entryobject class to ensure that the value of the
update-sentattribute is no longer increasing.
This signals that all outstanding local changes are replicated out to other servers.
- Stop the server instance.
Delete the replication server database by removing all files in the
changeLogDb directory below the server root.
As long as all local changes have been replicated out to other servers, this does not result in any data loss in the replication environment.
- Export the contents of all local DB and changelog backends to LDIF.
Re-import the data from LDIF.
This causes the data to be encrypted using the new preferred encryption settings definition.
Export the compromised key from the encryption settings database.
For precautionary measures, do this to back up the key in case you need it in the future, such as if some remaining data was later found to have been encrypted with the key contained in that definition.
- To no longer allow the server instance to use the key, delete the key from the encryption settings database.
- Start the server instance.
- Allow replication to bring the server back up-to-date with any changes processed while it was offline.
To re-allow externally-initiated write operations, change the value of the global
writability-modeconfiguration property to
To allow client traffic to be routed again to that server instance, reconfigure the
An example is changing the value of the
health-check-stateproperty in the corresponding LDAP external instance definitions in the server instances back to