Cloud trust paradox: three scenarios where encryption keys are not stored in the cloud
In articles “On the paradox of trust in cloud platforms” and “secure management of encryption keys“We noted that in some situations, encryption keys should not be stored with the cloud provider. Such situations, albeit rare, do occur. Moreover, when this happens, it is usually a very serious problem or important data.
In this article, we will look at 3 scenarios where keys need to be stored outside the cloud, despite all the benefits of the cloud.
Scenario 1: Data that is best not to be stored in the cloud
Most organizations today prefer to process information in the cloud, but there is always data for which this method is not suitable, whether it be confidential information or data subject to the most stringent internal security requirements.
Every industry and every company has data that falls into this category. For example, one international organization has very strict rules regarding the storage of keys. To use cloud platforms for this, she needs to obtain special permission. Another organization is guided by its own version of the PCI DSS standard. In addition, it has internal requirements for managing master keys using a FIPS 140-2 Level 3 hardware security module.
Given the risks and the need to comply with the rules and requirements, this data is sometimes difficult or even impossible to send for storage and processing in a public cloud service. Typically, these problems are faced by large organizations whose activities are highly regulated (for example, medical, financial and manufacturing companies). They may have access to patient data or financial transaction information.
However, an organization can agree to send data to the cloud if it is encrypted and the encryption keys are stored only with them. Thus, after assessing the risks and the level of trust in a particular platform, as well as listening to the opinion of auditors, the client can still transfer data to the cloud. Or he can keep the keys with him, referring to specific points of the rules.
You might argue that some data should never be stored in the cloud under any circumstances. Maybe. However, the conventional wisdom today is that the digital transformation needs to take advantage of the benefits of cloud platforms. Therefore, it is worth looking for some compromise solutions.
Scenario # 2: Local Legislation Requirements and Related Issues
With the development of cloud technologies, the order of their use largely depends on the requirements of the legislation in certain countries. In this scenario, an organization wants to use a cloud platform from another country, but is not happy with the service provider having encryption keys for all data. If unencrypted data is processed in the same cloud, the service provider will have access to it too. Some organizations also do not want to store keys on cryptographic devices (such as hardware security modules) managed by the service provider (physically or through software). They rightly believe that this approach is not consistent with the Hold Your Own Key (HYOK) principle.
Problems can be associated with both legal requirements and the reasons described above. In addition, regulators in the EU, Russia, Japan, India, Brazil and other countries are constantly adopting new regulations prohibiting the storage of unencrypted data and / or encryption keys abroad. Examples include industry standards (such as TISAX in Europe) that state or imply that a cloud provider cannot, under any circumstances, have access to data, and in many cases, encryption keys. but preliminary survey results indicate that options are possible when the encryption keys are only with the client (while the encrypted data can be stored abroad).
Another option involves storing keys for data associated with certain countries directly in these countries under the control of officials or ordinary citizens. It can be applied to banking data and assume that there are encryption keys for each set of data stored in a specific country. Example: A bank that insists that all of its encryption keys be stored under a specific mountain in Switzerland. Another example: legal or internal requirements that mandate the collection of information about key administrators and maintain an internal log of access to keys.
According to Thomas Curian, “data sovereignty allows customers to deny access to their information to service providers, unless the customers themselves deem necessary. For example, the Google Cloud platform allows customers store and use encryption keys outside the cloud… They can provide access to keys only if absolutely necessaryconfident that the data used is protected… As a result, the client can independently dispose of access to his data. “
Thus, this scenario allows organizations to use the Google Cloud platform and store encryption keys in a location of their choice under their physical and administrative control.
Scenario 3. Centralized management of encryption keys
In this scenario, we do not need to consider any covert threats or obscure regulatory requirements. The focus here is on operational efficiency. According to the company Gartner, eliminating redundant key management tools will result in keys being stored in a single system spanning multiple cloud and on-premises environments.
As trivial as it sounds, over-complexity often hurts security. The more centralized systems for individual tasks, be it managing logs or encryption keys, the more sources of potential vulnerabilities.
Therefore, the desire to use a single system (cloud or local) for most encryption keys is absolutely understandable. Few organizations today use cloud services for all encryption-related tasks. Most people prefer to store keys locally. An additional benefit of this approach is that one provider provides additional access control and rules. It’s easier to work with one set of keys. And if one system provides the appropriate level of security and redundancy, then there is no need for additional systems.
In addition, this scenario allows you to gain complete control over data processing by controlling access to encryption keys. If a customer can simply click a button to disable the cloud service provider’s access to the keys, no one can steal the data.
Finally, centralized key management allows the user of the cloud service to set rules for accessing keys and, therefore, inactive data.
All of these scenarios imply a situation where the encryption keys are not under the physical and administrative control of the cloud provider. This means that a hardware security module that is operated by the customer, but located on the premises of the cloud service provider, cannot be used.
Read the this article about managing encryption keys in the cloud.
Assess the risks to your data based on vulnerabilities, regulations, country-to-country relationships, and more.
Explore these three scenarios and see how they apply to you. Analyze cloud computing using a threat model and see if you can store keys in the cloud or not.
Check out services from Google Cloud EKM (External Key Manager) and partners (Ionic, Fortanix, Thales, etc.) to move key management from the cloud to on-premises.
We remind you that when you first sign up for Google Cloud: you have $ 300 worth of bonuses available, and more than 20 free products are always available. More on special link…
We also express our gratitude for their help in preparing the material to our colleagues: Anton Chuvakin, Il Song Li, Zviad Kardava