Leveraging Security Features in eDirectory 8.8
Novell Cool Solutions: AppNote
By Garg Shailesh, Jaimon Jose
Digg This -
Posted: 14 Dec 2005
This document describes how to leverage two new security features of eDirectory 8.8. A brief introduction to the Encrypted Attributes and Encrypted Replication features is provided, followed by a discussion of how to leverage these features to enhance the security of critical data. A small case study is also discussed to understand how these features are configured in eDirectory 8.8.
Topics: Security, eDirectory 8.8
Products: eDirectory 8.8
Audience: eDirectory Administrators
There have been a growing number of cases of information theft over the past few years. While electronic security measures increase to protect people's possessions and information, corporations and governments around the world are formulating new regulations that mandate confidential data be kept encrypted both on disk and on the wire.
System administrators can use these two new features to ensure the confidentiality of sensitive data. Administrators can encrypt specific attribute data stored on the disk as well as specific partitions' data when transmitted between eDirectory 8.8 servers. The default policies in eDirectory 8.8 ensure that sensitive data flagged as encrypted can only be retrieved over a secure channel.
Data in any directory service needs to be protected. eDirectory 8.8 has many different ways for protecting access to directory data. The encrypted attributes feature is designed to provide an additional layer of data privacy beyond that provided through the use of in-directory access controls by encrypting the data within the storage subsystem.This feature is configured at a database level; once you decide you want to encrypt an attribute, that particular attribute will be encrypted for every entry in the database on the specified server.
Government regulations and organizational security policies may mandate that sensitive data such as bank account number, social security number, credit card information, and salary information be encrypted on all storage media. The encrypted attributes feature is designed with meeting this type of compliance requirement in mind.
Guidelines for Configuring Encrypted Attributes
Use the following guidelines while configuring EA policies:
Deciding on Critical Data
The security policies of an organization - which may in turn be defined by government regulations - define which data needs to be secure. Novell recommends limiting the number of attributes that will be encrypted. The default configuration specifies that encrypted attributes can only be read through a secured channel, such as LDAPS or secure NCP.
When enabling encryption on an existing DIB, there is a possibility that the unencrypted data may remain behind in the file system; this data is sometimes referred to as ghost data. This happens because often when data is encrypted, it requires more space to store than when it was unencrypted. When the data is written back, if the block it was read from is not large enough to house the encrypted data, the data must be written to another location on the disk. The unencrypted data is not overwritten, and remains visible on disk when using forensic tools. If you want to encrypt the attributes that are already stored in the DIB and ensure that no ghost data is left in the disk in an unencrypted format, take the following precautions:
1. Rebuild the Database. If you already have a database and you want to mark existing attributes in the DIB for EA, we recommend that you complete the following steps:
- Configure the EA policy and mark the desired attributes for EA using iManager.
- Go to ndstrace to see the EA status and to check whether
encryption is completed for all the attributes in the DIB.
- Enable the Record Manger (RECM) and Limber (LMBR) option.
- Run, set ndstrace=*L
- Rebuild the database with the following command :
root:~/# ndsrepair -R -d
2. After rebuilding the database, either the size of the database is same as before or it will be reduced. So in both cases, we recommend you to overwrite the free space in the file system by creating a temporary file. This ensures that no critical data is left in the file system:
root:~/# dd if=/dev/zero of=temp.txt
root:~/# rm -f temp.txt
For a newly installed eDirectory 8.8 server, it is advisable to configure the encrypted attributes before populating the directory server. This ensures that data is being encrypted while writing to the DIB and reduces the amount of data that might be left unencrypted on disk as ghost data.
When configuring encrypted attributes, the following decisions need to be made:
1. Choice of Encryption Algorithms : eDirectory 8.8 provides the following encryption schemes for attribute encryption.
- Data Encryption Standard (DES)
- Triple Data Encryption Standard (Triple DES)
- Advanced Encryption Standard (AES)
The choice of encryption algorithm depends on various factors, such as how securely you want to store the attributes, what the security policies of your organization are, and if any government regulations require the use of a particular algorithm. Individual attributes can be configured to use any of the above encryption schemes; for example, you could encrypt a Social Security Number attribute with AES, and the user's telephone number with DES.
2. Encryption at Different Channels : Administrators need to consider data security at different level for a secure directory.
- Encrypting the attribute data in the DIB: Configure the attributes to be encrypted for a server.
- Requiring a secure connection to read or write data to encrypted attributes: It is important to note that data should be secure on wire for a secure directory. eDirectory 8.8 provides a server level configuration to ensure that encrypted attributes are not transmitted in clear text over the wire. iManager provides an interface to configure the “Always Require Secure Channel” option. This configuration ensures that encrypted attributes are always sent on a secure channel. There are two such scenarios:
- Directory client requests: Client requests should be on secure channel (for example, LDAPS) to read encrypted attribute values.
- Directory server requests: This does not include server-to-server communications, but includes scenarios where one server is acting as a client or on behalf of a client, such as when chaining LDAP requests from another server. If replication traffic needs to be encrypted, the Encrypted Replication feature needs to be explicitly enabled for the partition.
- Server Level Policy: Encrypted Attributes configuration is server-specific. This can be configured based on the security policies of the company in that geographic location. For example, if the security policy of a company is to have AES in a server located in Santiago and Triple DES in a server located in Frankfurt due to the regulations governing the security policies in that geographic location, it is possible to create two policy objects and associate them with respective server objects.
Case Study for Encrypted Attributes
ABC Finance stores the Customer Account Number in eDirectory. The corporate security policy requires critical customer information be stored in encrypted form on all media. The master replica is in Frankfurt, and local government regulations require the Customer Account Number be encrypted using the 3DES algorithm.
Complete the following steps to enable EA to meet the above requirements:
- Log in to iManager.
- Go to the eDirectory Encryption -> Encrypted Attributes task.
- Select Create, Edit and Assign policy.
- Click on Next.
Step 2: Enter the Policy Name as Frankfurt_EA_Policy. Choose the Server Context, where you want to store this policy Object, enter the Server Context as Servers.Organization. Click on Next.
Step 3: Choose Account Number in the "Attribute" dropdown list and Triple Data Encryption Standard (Triple DES) in the "Select Encryption Type" dropdown list. Click on Modify.
The following screen is displayed:
Step 4: Select "Always require Secure channel for Client access". Click Next.
Step 5: Enter the NCP Servers as Frankfurt-Server1.server.organization, which is the FDN of the Frankfurt server. Click Finish
|NOTE: Remember that if the requirement also dictated that the attribute always be encrypted on the wire, we would have to enable Encrypted Replication for the partition. We examine how to do that in our next case study.|
The Encrypted Replication feature encrypts data that is transmitted between two or more eDirectory 8.8 servers. Prior to eDirectory 8.8, only the synchronization data - as opposed to the entire communication - for the private key attributes was encrypted. With eDirectory 8.8, synchronization between any two servers or synchronization in an entire replica ring can be configured to be on a secure channel. Encrypted replication ensures that critical data on wire is always encrypted and secure.
Guidelines for Configuring Encrypted Replication
Use the following guidelines while configuring ER policies:
1. Unsecured communication channels: Encrypted Replication can be used in the following scenarios:
- ER can be configured to have secure communication between two servers. This configuration is useful in the following situations:
- If the directory servers are spread across geographical locations through WAN and the Internet, and there is a need to encrypt sensitive data on wire.
- If you require encrypted replication between specific replicas of a partition that contain sensitive data.
- The partition level server policy can be used in the following scenarios:
- All servers in a replica ring need to have secure communication due to the nature of data stored in that partition. However, partition level policy can not be used if there is a pre-eDirectory 8.8 server in the replica ring.
- If you feel the network in your setup is hostile, you might want to protect sensitive data during replication.
2. Encryption Strength: Encrypted replication uses the server certificate to encrypt the data and make the transport secure. The encryption strength is determined by the server certificate. The encryption used for replication leverages Transport Layer Security (TLS).
3.Encryption Granularity: In Encrypted Replication, the encryption granularity is at the replica and partition level. This is designed to take care of the security principle of maximum security - that is all the synchronization data will be encrypted when marked for ER regardless of whether the data is encrypted on disk (using the EA feature) or not.
Case Study for Encrypted Replication
ABC Finance stores critical information of the organization on the Finance partition. The replicas of these partitions are present on the servers present in different geographic location. The security policy of ABC Finance mandates that all the critical data should be encrypted when it is transmitted on the wire.
Complete the following steps to enable Encrypted Replication to meet the above requirements:
- Login to iManager
- Go to eDirectory Encryption -> Encrypted Replication
- Enter Finance.Frankfurt.Kep-SRS (This is the FDN of the partition which holds the sensitive information)
- Click Next.
Step 2: Select Encrypt all Replica synchronizations. This ensures that synchronization between all replicas of the Finance.Frankfurt.Kep-SRS partition is encrypted.
Step 3: Click Finish.
Performance Implications of Using EA and ER
Encryption adds to the security of the data, which cannot be compromised at any cost. Encryption also adds processing overhead which in turn will affect performance; as such, performance with encryption will always be slower. It is important to factor in the additional overhead for the encryption features and to use them only where they are necessary. Because of the number of customer and server-specific factors that affect not only the performance impact of EA and ER but also the overall performance of the server, we encourage you to perform your own testing in order to understand the impact for a specific implementation.
The Encrypted Attributes and Encrypted Replication features are needs that move with the times; as identity theft has increased the need for higher levels of security of identity data, Novell has introduced these features to help protect identity data from unauthorized access. These features are designed so that the policies can be configured with a high degree of granularity; if configured with a detailed understanding of the security requirements of an organization, then you will optimize their usage for both security and performance.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com