In the fourth part of our series on data residency, we look at the various encryption techniques and examine their advantages and disadvantages. 

Messages and information have been encrypted since ancient times. However, modern times are setting new requirements. For maximum protection, it must start as close as possible to the user: Encryption must be user-friendly, function transparently and guarantee a high level of operational security.

In principle, data can be available in the cloud in two different forms:

• As a file (this can also be an e-mail) in an unstructured data store
  This data can be protected as a complete 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 store
  Fields are much more complex to protect because the application in the cloud has a precise idea of how this data should look. A date must be in a certain form and an email also has certain recognition features. If the field content does not meet these requirements, a field consistency error can occur: The application reports an error and refuses to save the data.

With increasing digitization, data will increasingly be stored as fields instead of files. It is therefore imperative that both forms are protected: Data in files as long as the cloud is primarily used as a "Platform as a Service" (PaaS), such as with SAP or Microsoft Azure, and data in fields if the cloud is increasingly used as "Software as a Service" (SaaS), such as with Microsoft 365.

Where can I encrypt? 

Encryption should be simple and user-friendly - ideally, end users should have nothing to do with it. The following locations can therefore be considered for encryption and decryption:

... on the endpoint in the browser

The encryption would probably be implemented as Java script or in a similar form. Since the browser would have to receive keys because the method would be delivered with the Java script and the browser is the location of the action, the solution is only as secure as the browser can protect the key and authenticate the user. This would in fact be possible, but is not usually done due to the high susceptibility to errors. In addition, it can be easily overridden via browser settings and malicious recording would not be particularly difficult either. From my point of view, protecting the endpoint makes no sense.

... via an active component close to the operating system

Software on the endpoint would be integrated into the file system (for files) on the one hand and into the network system (for fields) on the other. The invasive way in which this approach is pursued can hardly be operated in a stable manner: The systems under Windows, Mac, Android et al. are too fast, frequent and different.

... directly in an application

The application on the endpoint can handle the 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 is usually unaware of this and the process is fast. However, an "in-between" must be possible. While this usually works well with fields, it is somewhat more complicated with files. This has to do with how the file storage data in the cloud is synchronized between local and cloud. As a rule, the file is not moved in its entirety every time it is changed, but only the changed parts are copied. However, the encryption appliance cannot encrypt the entire file consistently if it only receives individual parts of it. With 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 now makes this information available via API, an active component such as a Cloud Access Security Broker (CASB) can obtain the unencrypted data via API and return the encrypted data via API. The problem here is that the provider has seen the unencrypted data and has usually stored it at least temporarily. It now depends on the implementation whether the unencrypted data is deleted quickly or not. Again, a question of trust, with no guarantee that this cannot 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. With this solution, it depends on where the key comes from, how good the encryption is and whether it is ensured that the data does not survive anywhere in an unencrypted state.

...at the provider in the application

The application is built right from the start in such a way that the data is encrypted after the logic layer before it is stored. Larger providers such as Salesforce or ServiceNow can do this, but smaller ones generally cannot. Retrofitting is complex, very expensive and data migration is a rather difficult task. In addition, this solution also depends on where the key comes from and how good the mechanism is. The provider is solely responsible for checking that this is done correctly. An unencrypted shadow copy could be created without any problems.

... 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. This solution must also be analyzed more closely with regard to the origin of the key, the mechanism used and the location of the event (location of the database/file server). Control lies exclusively with the provider.

Maximum security is provided by the option "Inline network component somewhere between user and provider"as the provider cannot see the unencrypted content. However, this solution also has its limitations: The provider can no longer "calculate" with the encrypted data and usually cannot perform any further, more complex functionality. This approach therefore allows data to be anonymized in the cloud. In most cases, this is sufficient.