Encryption helps to protect data in transit, as well as stored data. This section describes the following methods of data encryption:
Security design involves more than an authentication scheme for identifying users and an access control scheme for protecting information. You must also protect the integrity of information between servers and client applications while it is being sent over the network.
To provide secure communications over the network, you can use both the LDAP and DSML protocols over the Secure Sockets Layer (SSL). When SSL is configured and activated, clients connect to a dedicated secure port where all communications are encrypted after the SSL connection is established. Directory Server and Directory Proxy Server also support the Start Transport Layer Security (Start TLS) control. Start TLS allows the client to initiate an encrypted connection over the standard LDAP port.
For an overview of SSL and TLS in Directory Server, see Directory Server, see Chapter 2, Directory Server Security, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Directory Server Enterprise Edition provides various features to protect data at the access level, including password authentication, certificate-based authentication, SSL, and proxy authorization. However, the data stored in database files, backup files, and LDIF files must also be protected. The attribute encryption feature prevents users from accessing sensitive data while the data is stored.
Attribute encryption enables certain attributes to be stored in encrypted form. Attribute encryption is configured at the database level. Thus, after an attribute is encrypted, the attribute is encrypted in every entry in the database. Because attribute encryption occurs at the attribute level (not the entry level), the only way to encrypt an entire entry is to encrypt all of its attributes.
Attribute encryption also enables you to export data to another database in an encrypted format. The purpose of attribute encryption is to protect sensitive data only when the data is being stored or exported. Therefore, the encryption is always reversible. Encrypted attributes are decrypted when returned through search requests.
The following figure shows a user entry being added to the database, where attribute encryption has been configured to encrypt the salary attribute.
The attribute encryption feature supports a wide range of encryption algorithms. Portability across different platforms is ensured. As an additional security measure, attribute encryption uses the private key of the server’s SSL certificate to generate its own key. This key is then used to perform the encryption and decryption operations. To be able to encrypt attributes, a server must be running over SSL. The SSL certificate and its private key are stored securely in the database and protected by a password. This key database password is required to authenticate to the server. The server assumes that whoever has access to this key database password is authorized to export decrypted data.
Note that attribute encryption only protects stored attributes. If you are replicating these attributes, replication must be configured over SSL to protect the attributes during transport.
If you use attribute encryption, you cannot use the binary copy feature to initialize one server from another server.
While attribute encryption offers increased data security, this feature does impact performance. Use attribute encryption only to encrypt particularly sensitive attributes.
Sensitive data can be accessed directly through index files. Thus, you must encrypt the index keys corresponding to the encrypted attributes, to ensure that the attributes are fully protected. Indexing already has a performance impact, without the added cost of encrypting index keys. Therefore, configure attribute encryption before data is imported or added to the database for the first time. This procedure ensures that encrypted attributes are indexed as such from the outset.