In the fourth part of our series on data residency, we discuss the different encryption techniques and highlight their pros and cons.
Messages and information have been encrypted since ancient times. However, modern times set new requirements. For maximum protection, the encryption must take place as close as possible to the user: Encryption must be user-friendly, operate transparently and ensure a high level of operational reliability.
Basically, data can be available in two different forms in the cloud:
- As a file (this can also be an e-mail) in an unstructured data storage
This data can be protected as an entire set by encrypting the file as a whole.
- As a field in a record (such as a
row or a table entry) of a structured data storage Fields are much more complex to protect because the application in the cloud has a precise idea of what this data should look like. A date must be in a certain form and an e-mail also has certain identifying features. If the field content does not meet these expectations, a field consistency error can occur: The application reports an error and refuses to save it.
With increasing digitalization, data will increasingly be stored as fields instead of files. Both forms should therefore be protected: data in files, as long as the cloud is primarily used as a “Platform as a Service” (PaaS) as with SAP or Microsoft Azure, and data in fields if the cloud is increasingly used as “Software as a Service” (SaaS) such as Microsoft 365.
Where can I encrypt?
Encryption should be simple and user-friendly – ideally, end users have nothing to do with it. The following locations are suitable for encryption and decryption:
… on the endpoint in the browser
The encryption would probably be implemented as Java script or in a similar form. If the encryption method lies within the Java Script, the browser would need to have the keys; thus, the solution is only as secure as the browser is capable of protecting the key and authenticating the user. Although this method would be feasible, it is prone to error and therefore not very common. In addition, it can be easily tilted via browser settings and malicious recording would not be particularly difficult. From my point of view, protecting the endpoint doesn’t make sense.
… via an active component close to the operating system
A software on the endpoint would integrate into the file system (for files) on the one hand and into the network system (for fields) on the other. Due to its invasive way, this approach can hardly be operated stably: The systems under Windows, Mac, Android et al are too fast and too different from one another.
… directly in an application
The application on the endpoint can handle encryption. Microsoft, for example, does this with its Rights Management for Files. However, this approach does not work for fields via a web application. It is therefore primarily possible with files.
… in an inline network component somewhere between user and provider
The communication between the user and the provider is intercepted in between and encrypted and decrypted there. The user usually doesn’t notice any of this, and the process is fast. However, an “in-between” must be possible. While this usually works well with fields, it’s a bit more complicated with files. This has to do with the way the data in the cloud is synchronized between on-premises and the cloud. As a rule, the file is not moved as a whole with each change, but only the changed parts are copied. However, the encryption appliance can poorly encrypt the entire file consistently if it only gets individual parts of it. For fields, however, this usually works very well.
… in an active component that talks to the provider
The data arrives at the provider unencrypted (apart from the transport encryption). If the provider makes this information available via API, an active component such as a Cloud Access Security Broker (CASB) can obtain the unencrypted data and return the encrypted data both via API. The problem with this approach: the provider sees the unencrypted data and usually stores it at least temporarily. It actually depends on the implementation whether the unencrypted data is deleted quickly or not. Again, a question of trust: nobody can guarantee that the way unencrypted data is handled will not be changed in the future.
… at the provider before the application
The provider offers encryption directly in front of its user interface. This is still rarely done. The success of this solution depends on who supplies the key, how good the encryption is and whether it is ensured that the data does not survive somewhere in an unencrypted state.
… at the provider within the application
Right from the start, the application is built in such a way that the data is encrypted according to the logic layer before it is stored. While this is feasible for larger providers such as Salesforce or ServiceNow, it would usually not be possible for smaller ones. Retrofitting is complex, very expensive and data migration is a rather difficult task. Moreover, everything depends on the origin of the key and the quality of the encryption mechanism. The provider has ultimately control over these processes. It woud be easy to create an unencrypted shadow copy.
… at the provider at rest
The provider encrypts the data when it is stored in the database or as a file on its file container. Even in this solution, it is important to know the key origin, the mechanism used and the location (location of the database/file server). The control lies exclusively with the provider.
The option «inline network component somewhere between user and provider»provides the maximum of security, because the provider does not see the unencrypted content. However, this solution also has its limitations: The provider can no longer “calculate” with the encrypted data and usually cannot execute any further, more complex functionality. This approach allows the best anonymization of the data in the cloud, which is sufficient in the most cases.
The decisive factor is where the data is encrypted, with which mechanism, and who keeps the key in their hands.
Who controls my encryption?
There are three important elements involved in encryption:
- The key should not end up in the hands of third parties. Bad keys create weak encryption, and if a key falls into the hands of third parties, they can decrypt the data and even maliciously change it or fake new data.
- The encryption mechanism should be good. There is extensive literature on the various mechanisms, their strengths, weaknesses and ideal uses. But a modified mechanism can be used against you in that while the key is good, the mechanism is weak and does not produce good encryption. Therefore, a quality mechanism is key, as well as a trustworthy code used for it.
- Of course, where the encryption takes place is also important. If it does not take place locally, no one can prevent the replacement of keys or mechanisms with a debilitating version.
Encryption is only under control if all three elements can be controlled. If an element falls into the hands of third parties, your encryption may be exploited by that third party, its employees, suppliers, foreign states or cyber criminals. So there is very little room for manoeuvre here.
BYOK stands for “bring your own key”. The key is usually handed over to the provider, who then uses a mechanism of his choice at a location of his choice. This mechanism is often proclaimed as a “safe solution”. In fact, it only increases the effort of the customer (who is now responsible for the key management) without significantly increasing the protection. A deceptive package from the provider’s marketing department.
A BYOE-solution (“bring your own encryption”) is generally better. Here, the key, mechanism and location are controlled by the customer and are therefore much more trustworthy. This option also has the potential to solve the residency aspects of your protection needs. This is one thing most other approaches can’t achieve.
Which encryption is right for me?
- Optimal protection is provided by BYOE, i.e. local encryption. Providers only receive encrypted information. There are few alternatives for multi-cloud surroundngs. As for the residency problem, this approach is able to use dedicated keys per country. This functionality is commonly offered by encrypting CASB solutions such as centraya.com.
- The encryption may also take place locally, but on the provider’s software – such as Microsoft’s Double Key Encryption or ServiceNow Edge Encryption. However, this approach compromises in the control of the mechanism.
- “Hold your own Key” (HYOK) is an approach in which you as a customer do not give up your key. Typically, you also need local infrastructure, which makes HYOK encryption a provider-binding local encryption. For a single provider or a single application, this is a secure approach. If different providers are used, each one usually needs a dedicated HYOK solution. Cross-provider or cross-application solutions create significant infrastructure complexity in your data center.
- We speak of a “provider managed key” solution when the provider manages one dedicated key per customer. The key remains under the control of the provider, who also chooses mechanism and location. De facto, the customer has no control over the encryption. Provider Managed Key is the most common solution offered by providers. Basically, they only provide information that some kind of encryption does take place. Key, mechanism and location are controlled exclusively by the provider.
Only 1-3 significantly increase your security. 4, on the other hand, has a small interference potential for the provider functionality. It remains a matter of balancing security vs. functionality. In multi-cloud environments, we recommend a class 1 solution with the focus on “Person Identifying Information” (PII). This keeps the protection of personal data high while and the potential for disruption of the functionality is small.
You have to be aware of one thing: as soon as you no longer store (sensitive) data only locally – and this has long been a reality for most companies – you give up control over your data. Good-sounding terms for the types of encryption offered by providers, such as “Bring your own key”, intuitively inspire trust in users, but offer no real guarantee for data security. The decisive factor is the place where the data is encrypted, the mechanism used, and who keeps the key in their hands.
If the cloud is your strategy, don’t miss the next blog in this series. There, we will have a look at the multi-cloud-environment and its special needs. Cheers.