In general, security is an area in which directory servers have typically surpassed other types of network data repositories, or at the very least in which clients have more commonly taken advantage of more of the security functionality that the server has to offer. For example, whereas applications using a relational database generally use a single account for all interactions with the database, most well-written LDAP applications issue requests under the authorization of the end user so that a request performed on behalf of a user will be subject to whatever restrictions are enforced for that user. At the very least, most directories have some kind of password policy mechanism that can be used to provide some safeguards and constraints around authentication processing, and some kind of access control mechanism that can be used to restrict what individual users are allowed to do. But this is not nearly enough to adequately protect your data in the modern world.
While directory servers do tend to have better authentication support than most other kinds of databases, most directory vendors really haven't done much to improve authentication support in recent years, and most LDAP authentication is still dependent upon passwords. It's important to provide alternatives to password-based authentication, or at least to augment password-based authentication with a second form of credentials. The UnboundID Directory Server provides direct support for multifactor authentication by allowing users to combine their static account passwords with either time-based one-time passwords (the algorithm that Google Authenticator uses) or one-time passwords that are delivered to the end user through some out-of-band mechanism like email or SMS. We also provide an extensible framework that allows you to integrate support for other custom authentication mechanisms into the server so that you aren't restricted to just passwords, and we've used this framework ourselves to implement support for authentication with YubiKey-generated one-time passwords.
Similarly, while most directory servers have some kind of access control support that can restrict what users are allowed to access, it typically doesn't go far enough. For example, most directories have some kind of a "root" account that isn't subject to access control restrictions. If a bad guy gets access to that root account, or if a trusted administrator turns out to be a bad guy, then access control alone may not be enough to prevent them from accessing sensitive data. In the UnboundID Directory Server, it's possible to define restrictions around access to a specified set of attributes that will be enforced even for root users. You can also enforce hard restrictions based on what the server knows about the client (e.g., limit access to the server configuration and other administrative data to a specific internal network) as an additional layer of protection.
And on the subject of root users, the UnboundID Directory Server doesn't need to have just one root account, and not all root accounts need to have identical capabilities. The server supports multiple root accounts so that each administrator that needs root access can have their own account with their own credentials, which makes it much easier to audit the activities of the individual administrators. Further, "root" isn't a single concept in the UnboundID Directory Server because the server uses a privilege system to make it possible to grant specific elevated capabilities to individuals on an as-needed basis (e.g., so you can grant someone the ability to trigger an online backup without giving them the ability to bypass access control restrictions).
While the server has many features designed to prevent unauthorized data access, it's vital to pair this with the ability to verify what has been accessed and by whom. Fortunately, the UnboundID server software has an extremely capable logging subsystem to help with this. Server access logs can be used to provide a complete record of all operations processed and data accessed, but we also offer a filtered logging capability that makes it possible to create custom logs for specific auditing or debugging purposes (e.g., a log with information about just failed operations, operations that accessed a specified set of attributes, or operations that required special privileges). The server can cryptographically sign log files to ensure that they haven't been altered since they were written for greater assurance of their validity, and it's also possible to log to external systems (e.g., using a mechanism like syslog or recording operations in a relational database) to make it even harder for bad guys to cover their tracks. And we provide an API for parsing log messages that you can use for programmatic analysis of log contents.
In the midst of all these features to protect and audit online access, it's also vital to be able to secure the data in transit and at rest. We provide full support for using SSL/TLS (up to TLS 1.2) to secure all communication, and TLS certificates can be stored in FIPS 140-2-certified PKCS #11-compliant hardware tokens to ensure that they are protected. We also provide support for full data encryption so that entry data is protected even from people with raw access to the database files, and this encryption support covers not only the entries themselves but also references to entry and operation data that might be stored in the replication database or LDAP-accessible changelog. Plus, backups and LDIF exports can be encrypted to protect their contents while still allowing them to be seamlessly restored to any server in the replication topology. Once the data is in the server, you can ensure that it is never exposed in the clear.
Stay tuned for Part 3 of this blog series where I’ll explain how our UnboundID server software allows you to take an instance offline without impacting the overall availability of the service and much more around internet-grade availability.