MongoDB Inc, developer of the NoSQL MongoDB document-based database management product, has announced the latest version, 4.2. The primary new features are distributed transactions, an updated Kubernetes Operator, and client-side field level encryption.
The encryption is particularly relevant in the modern regulatory climate. Because the encryption and decryption are performed locally, the server — whether on-prem or in the cloud — never sees either the keys or unencrypted data. If the server is compromised and the data stolen, it will only ever be encrypted data.
The EU’s General Data Protection Regulation (GDPR) is frequently used as a blueprint or guide for new data protection and privacy legislation around the world. It is therefore a good test for general compliance. GDPR (unlike some regulations like PCI) does not require encryption but does mention it as an example of an appropriate technical measure (article 32) for data protection. Strictly speaking, personal data remains personal data whether it is encrypted or not.
This raises a question over the practical business-level value of encryption for GDPR compliance. It is generally held, however, that regulators will be less strict over lost personal data if it is encrypted. For example, the UK’s regulator (the Information Commissioner) has stated, “It is possible that, where data is lost or destroyed and it was not encrypted, regulatory action may be pursued (depending on the context of each incident).” The IC doesn’t say that action won’t be taken if it is encrypted, but implies that action is more likely if it is not encrypted.
The new field level encryption was developed with the help of third-party encryption experts. “We partnered with two of the world’s leading authorities on database cryptography, including a co-author of the IETF Network Working Group Draft on Authenticated AES encryption, to develop Field Level Encryption,” said Lena Smart, CISO at MongoDB. “Drawn from academia and industry, these teams have provided expert guidance on MongoDB’s Field Level Encryption design and reviewed the Field Level Encryption software implementation.”
Because it is client-side encryption, key management is done locally. This has an immediate effect on access issues. Where — as is the case for many other databases — the encryption is performed at the server, local administrators (and there are usually too many) are able to access the database instance itself, even if they have no client access privileges. MongoDB 4.2 changes that. It doesn’t eliminate the insider threat, but reduces the chance for opportunistic unsanctioned access.
The encryption/decryption process is automatic and transparent. “It’s the driver that, when it sees an encrypted field is involved in a write or query command, gets appropriate keys from the key manager, encrypts the data, and sends it to the server,” explains DJ Morgan-Walker in an associated blog. “The server then only sees ciphertext and has no knowledge of the keys. When results are returned from the server, that ciphertext is sent by the server to the driver and it’s there that the driver, which already has the keys, decrypts it. From an application’s point of view, this mechanism is completely transparent.”
The new encryption is certainly good for data security, and almost certainly good for compliance. There is one area, however, that most definitely benefits compliance — or more specifically the ‘right to be forgotten’ that is increasingly appearing in privacy-based legislation. Many legacy, relational databases that offer encryption do so in columns. This makes the isolation and removal of individual fields following a compliance-driven personal data removal request a difficult and complex operation.
Removal of individual fields in MongoDB 4.2 becomes simple — you simply delete the key relating to the field in question. The content of the field then becomes irrecoverable garbage. And since decryption is only performed at the client with keys stored at the client, writes Morgan-Walker, “It also means that you can safely use a managed service like MongoDB Atlas, knowing that the data is never visible unencrypted in logs, memory or any other part of the infrastructure.”
Related: Consent Control and eDiscovery: Devils in GDPR Detail
Related: One Year on, EU’s GDPR Sets Global Standard for Data Protection
Related: Unprotected MongoDB Instance Exposes 800 Million Emails
Related: MongoDB Tightens Security Amid New Database Attacks
