Your data is always private thanks to CipherDB. So in most cases none of the additional measures listed below are strictly required. Having said that, security in layers (or defense in depth) combined with good security hygiene can help security compliance as well as promote security-conscious thinking within your organization. Some of those good practices would be:
- Firewall your database server
Although CipherDB, by itself, always protects your database for privacy, it is good security hygene to firewall your database server(s). - Use strong passwords to log into the database server
Have a strong username and password for accounts, either human or program/machine, that log onto the database server. - Always use SSL when connecting to the database server
Although the data itself is encrypted by CipherDB, enabling SSL for connections encrypt everything that goes between your application and the database – including any database control commands. SSL also verifies the certificate of the remote database server, so you can be sure that the remote party is indeed the party you wish to talk to (prevents man-in-the-middle attack). - Patch your application / web / database servers
Ensuring that all security patches are applied to your servers and workstations is a good way to limit the possible weaknesses that can be exploited.
Additionally, enterprise customers running the self-hosted version of the Crypteron Security Platform are also advised to:
- Control the distribution of the CipherDB certificate private key
CipherDB’s builds its trust zone out of the CipherDB certificate and its corresponding elliptic curve private key. Keep that private key secure and control it’s distribution. Some suggestions:- If the private key is on an application server or web server or a workstation, you should keep that server secured (patched, access controls in place etc). This is very similar to protecting the private key stored on SSL/HTTPS servers.
- Have only trusted personnel handle the private key. If such a person is exporting the certificate and private key, always use a strong password to encrypt the export
.PFXfile. Further, when installing the PFX file, mark the private key an non-exportable so additional downstream exports are contained.
- Limit access the keychain file
The CipherDB keychain is a strongly encrypted NoSQL database that itself protects all CipherDB keys. In other words, the encryption keys are themselves encrypted. This means in theory one could very well leave the keychain publically accessible without any loss of informational assurance. However, for true practitioners of “Deference in Depth” we suggest:- If the keychain is stored in Azure Blob Storage, make the blob container non-public and keep the Azure Storage account name and account keys safely. The Azure Blob storage security add an extra layer of protection.
- If the keychain is stored on the file system of the application or web server or even a workstation, limit access to the file with either webserver configuration or OS file system security
