Blog
EU Data Protection (GDPR) and encryption
The EU Data protection act (GDPR) regulates the responsibilities of organizations that collect, hold, and process data related to individuals. Many companies use Next as an important component in their infrastructure for handling such data. That is why we collect and share knowledge on the practical implications of implementing GDPR when using Next. One of the themes often mentioned in connection with GDPR is encryption, as encryption is considered one of the possible measures to protect sensitive data.
The GDPR wording
“In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected. In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.”
When you discuss encryption in relation to GDPR, you most often distinguish between 'data in rest', and 'data in transit'.
Encryption of data at rest
The task at hand, is to secure that data stored on a media is rendered unreadable in case the content of the media is made available to unauthorized persons.
 |
To encrypt or not encrypt Please note that GDPR does not require or recommend encryption, it merely state encryption as one potential measure. GDPR specifically requires you to evaluate also the risk of losing data. Introducing encryption also introduces a new risk to losing data. In case your organization loses the principal key (by human, software or hardware error) the data is lost for ever. If you decide that the benefits from encryption outways the risks, the you should consider the options for encrypting data in Next. |
When introducing encryption af data in rest you have several options:
- Infrastructure level encryption
- Document level encryption
Infrastructure level encryption
Enabling full disk encryption is a standard feature in all major operating systems. In Windows, bitlocker is build in. Next operates smoothly on top of any such system, but of course the requirements for available hardware resources increases to support the additional process of encrypting and decrypting data.
Infrastructure encryption has the advantage of being optimized for low overhead and offers good protection of all data (including indexes and metadata), from unauthorized access to "lost" devices or media. In general, infrastructure level encryption offers no protection against unauthorized access to data by user with legit access to the infrastructure - typically server operators.
Document level protection, third party
Several customers have implemented third party encryption for selected documents stored in Next. One example is Adobe Acrobat.
Implementing document level protection also protects the content of documents from users with administrative rights to the infrastructure. The document level encryption does not protect metadata, and does not allow for automatic extraction of data for contextual search.
Document level encryption, embedded
The Next storage engine is prepared for implementing an embedded document level encryption option. Such an embedded document level encryption will protect the documents data, against unauthorized access from e.i. server operators - a feature full disk encryption does not offer. An embedded document level encryption will not protect metadata and search indices, but will allow Next to extract data to generate these. An embedded encryption will add to the hardware requirements for the solution.
As of now, Next does not offer an embedded document level encryption option. Future availability of such an option depends solely on the market potential.
|
Multi layer encryption If you deem the benefits from encryption bigger than the drawbacks, our recommendation would be to consider a multi layer encryption setup. Combining infrastructure level encryption with document level encryption for selected document types, gives you the maximum protection of your data. |
 |
Operational consequences The secret key is the central component in any encryption scheme. Keeping this a secret, demands that the secret must be revealed prior the decryption of data. Therefore the physical human key-master(s) must be available during startup of the system being protected - this is true for both infrastructure encryption and embedded document encryption. |
Encryption of data in transit
The task at hand, is to secure that in case data flowing between the application (Next) and the end user (person or system) is intercepted, then this data is rendered unreadable.
With encryption of data in transit there is no tradeoff between risk of losing data, and risk of exposing data. Even on internal and 'secure' LANs, we recommend implementing encryption.
For transport level encryption, Next offers the latest and most secure version of SSL/TLS. Currently SSL/TLS1.2 (SSL3.3).
