1. Introduction
Data and user security have always been important considerations for small to large enterprises during the deployment of their database or application servers. PostgreSQL today has rich support for many network level and user level security features. These include TLS to secure database connections, internal user authentication, integration with external user authentication services such as RADIUS, LDAP and GSSAPI, and TLS certificate based user authentication …etc. However, it does not yet support Transparent Data Encryption (TDE) feature where all the database files and logs have an option to be encrypted before written to disk or decrypted when retrieving from the disk. This adds extra security measure to protect against disk theft.
All these features have something in common; they all use cryptographic keys (either symmetrical or asymmetrical, statically generated or exchanged on the fly using Diffie Hellman) in some ways to achieve the security goals. It is quite common for an organization to focus entirely on the actual data encryption part but pay minimal attention to the cryptographic keys that make the encryption possible. In fact, data encryption is the easy part, the protection of the cryptographic keys is often the hardest as it has several levels of complexities.
A group of members (including myself) from the PostgreSQL community are actively working on TDE and internal KMS features towards PG14 and there has been some good work done on the internal KMS module with future support of integrating with an external KMS already in discussion. You may find the current status and the work in progress from these links below:
PostgreSQL TDE Wiki Page
Internal KMS for PostgreSQL
Today I would like to discuss the benefits of external key management system over the internal.
2. Compliance
Perhaps one of the biggest benefits of having an external KMS is compliance. For organizations that are mandated by the government to have the FIPS 140-2 compliance certification, the external KMS could potentially help them achieve FIPS 140-2 level 3 (tamper resistant key storage) certification. Internal KMS, on the other hand, may provide FIPS 140-2 level 1 (stop the use of unsafe algorithms) and at most up to FIPS 140-2 level 2 (store keys in tamper proof evident hardware).
Depending on the industry governance, there may be a strict requirement that any key materials and encrypted data must be stored separately. For example, in the Payment Card Industry Data Security Standard (PCI DSS) requires that the cardholder data and encryption keys must be protected and stored separately.
For this reason alone, certain data sensitive organizations cannot consider PostgreSQL as their choice of database due to lack of support to external KMS.
3. Deployment Flexibility
Another benefit of external KMS is the flexibility in deployment. When deploying their IT infrastructure, many organizations face the decision whether to maintain all applications including key management system on site or host them in a dedicated data center or even to the cloud. With external KMS, it is possible for these organizations to have a future proof deployment where all the cryptographic keys are centrally managed and will ensure their solution will work in any of the deployment scenarios. With internal KMS, these organizations will not have the flexibility in the deployment because the application will be tied to the storage space within itself.
Taking PostgreSQL as an example, each database cluster has a different storage space. With the internal KMS, each cluster manages its own set of cryptographic keys. In a larger deployment scenario where multiple PG instances will be deployed, it will become very difficult to manage the life cycle of the cryptographic keys used in each cluster.
4. Complete Life Cycle Management for Encryption Keys
Normally, a complete life cycle of an encryption key is very likely involved in the following phases. Depending on the business cases, some phases can be omitted.
- Key generation
- Key registration
- Key storage
- Key distribution and installation
- Key usage
- Key rotation
- Key backup
- Key recovery
- Key revocation
- Key suspension
- Key destruction
It is possible for an Internal KMS to support all of the phases within its storage space and allows an user to manage the key life cycle but this process will not scale as scope requirement increases. External KMS, on the other hand, provides a centralized life cycle management of all the keys that it is managing. This is a much simpler approach to manage all the key materials in a larger deployment scenario. While it is not a security best practice, it is quite common to start a project with the internal KMS and later migrate to external one. Many of the key manager software vendors have support for key migration.
5. Security Audit
This is again a requirement for certain corporate and industry compliance where there must be a detailed audit log capturing all the key usages, rotations, who accessed the key and at what time. Depending on the requirement, certain alert mechanism may be required to be implemented to alert the key administrator about any potential issues that could rise from the cryptographic key operations. With an external KMS system, it tends to be much easier to streamline the key audit reports for all the keys it is managing and easier to prove to customers or potential auditors that the keys are indeed very secured and closely monitored.
Taking the PostgreSQL as an example and it’s current work on internal KMS, it is quite difficult to prove that the keys are stored securely without the auditing mechanism to closely monitor the key usages and their lifecycles. Even if there is a complete suite of auditing mechanism in place, the auditing is still a difficult and costly operation to perform especially when there are multiple servers deployed. This would result in all storage systems to be audited individually.
6. Key Management Duty Separation
Normally, the key administrators of an external KMS has the ability to configure permissions for all the cryptographic keys that it manages. Permissions such as intended purpose, owner, validity period and other user attributes. PostgreSQL and the current work on internal KMS, on the other hand, does not have this level of granularity in administrative roles. The database administrator is also the encryption key administrator. This may be an issue in certain compliance requirement like HIPAA where it is required that both roles must be separated for proper data access.
7. Conclusion
External KMS indeed has several more benefits over the internal KMS as it provides additional management, compliance and control. It is an increasing trend that more security-conscious organizations are driving their integrations and deployments with an external KMS in the design. However, it does not mean the internal KMS should not be used at all. For smaller organziation and deployment, it is quite normal to start with the internal KMS and later migrate the key to an external KMS as the deployment gets larger in size.
There is an active internal KMS development in PostgreSQL community and it can achieve basic key life cycle management and the next big focus would be on Transparent Data Encryption (TDE) and eventually an extension that supports communication to an external KMS.
Key Management Interoperability Protocol (KMIP) is a communication standard set out by Organization for the Advancement of Structured Information Standards (OASIS) to enable a secured communication between key management systems and cryptographically-enabled applications such as PostgreSQL. There is not many C-based open source KMIP client implementations today that can be utilized to develop a PostgreSQL extension that acts as a KMIP client to talk to external KMS, but I am sure as externa key management becomes a mainstream, there will be many different versions of implementation emerging in the market.
