News & Insights by Atakama

Cloud Encryption: Who is Responsible for The Keys?

Written by Atakama Team | May 10, 2022 5:27:02 PM

Cloud adoption continues to rise as enterprises move more of their workloads and data to cloud infrastructure. When it comes to protecting the sensitive crown jewel data stored by organizations in cloud systems, encryption remains a critical security mechanism. However, confusion over who should assume responsibility for key management or how to best approach it can hamper encryption efforts and put cloud data at risk. In fact, the majority of respondents in one survey indicated just 21-40 percent of their sensitive data in the cloud is encrypted.

Whether the data contains IP and trade secrets or personal information about customers, you need to make this information unreadable to threat actors, even when they somehow manage to get their hands on the files stored in the cloud. Only encryption can provide the necessary data security. This article explores cloud encryption and delves into the primary management dilemma to explore what the most secure choice is. 

Encrypting Data at Rest in the Cloud

Malicious outsiders can try to intercept individual data packets moving between public cloud servers and user devices or moving between data centers in an attempt to compromise sensitive information. Alternatively, they can target data at rest, stored in cloud systems. 

Data in motion is relatively secure using TLS encryption, which works well and doesn’t introduce cloud-specific key management complexities. For data at rest in the cloud, an immediate initial challenge that reveals itself is who takes control of managing the keys used to encrypt and decrypt the data. 

The default model of cloud-based encryption is unworkable for many enterprises because it involves delegating ownership of encryption keys to the cloud provider. In other words, a third party company (the cloud vendor) generates, stores, and manages the keys used to encrypt your company’s most sensitive data. This happens in a cloud provider’s own key management server. It’s what allows all permissioned users within the organization to have instant and simultaneous access to files stored in the cloud.

The lack of visibility into how key management happens under this responsibility model understandably deters some companies. Even if most well-known cloud service providers are reputable organizations, not having control and ownership over the encryption keys that can unlock the door to your most sensitive information assets is an unpalatable prospect that may well go against corporate policy. 

With many cloud vendors operating a multinational data center infrastructure, there are also potential data sovereignty, regulatory, and legal risks, such as in the case of a subpoena issued to the cloud provider seeking your sensitive data. With the cloud provider in control of the keys, they’d be able to comply with the subpoena even without your knowledge.

Ultimately, this is a trust model that many organizations are simply not interested in.

BYOK and HYOK 

There are two main options presented to organizations that want greater control and responsibility over keys when encrypting data in the cloud.

1. Bring your own key (BYOK) 

The BYOK encryption key management concept allows businesses to generate and manage their own keys outside of the cloud provider. The attractiveness of this model is that it removes any opacity from the key generation process through your business using its own process and systems for creating and managing encryption keys. 

While the control BYOK provides is superior to relying on the cloud provider’s key management, the control is in reality fictitious. That’s because even though it’s your key, you don’t have actual control over how and who uses the key. Your control is limited to key generation only. Once the key has been transferred to the cloud provider and their key management systems, you no longer control the key.

BYOK is also resource-heavy for the organization. 

2. Hold your own key (HYOK)

HYOK goes further than BYOK by ensuring encryption keys are always under your control and stay in your environment. In practice, this means you encrypt data before it gets uploaded to the cloud and never pass the keys to the cloud provider. Data is only decrypted when it moves back to on-premise systems from the cloud. 

Since sensitive data never gets decrypted in the cloud, HYOK assures higher confidentiality and control out of the key management options for cloud encryption and is a better option for highly regulated industries like banking or healthcare. 

Like BYOK, HYOK is resource heavy to the organization. It also creates a central point of failure and attack that can expose the organization.

The Problem with Centralized Key Storage

While both BYOK and HYOK key management methods provide a far more attractive alternative than the cloud storage provider potentially seeing your data or disclosing it to a third party, accidentally or otherwise, they can both become security risks when their implementation depends on centralized key storage. 

The reason is that centralized key storage in a key management system is typically dependent on identity and access management controls (i.e., Active Directory) policies that control access permissions to encryption keys. Identity and access management (IAM) is a set of processes, policies, and tools for defining and managing the roles and access privileges of individual network entities (users and devices) to a variety of cloud and on-premises applications.

If someone manages to escalate privileges, break into an admin account, or otherwise exploit identity and access management misconfigurations, they get access to your encryption keys. So, in the process of apparently seizing back control over your sensitive data with BYOK or HYOK, you end up creating a new problem by storing all keys centrally and controlling access to them with your identity and access control systems that act as a single point of failure. 

Atakama and Decentralized Key Architecture

A better alternative to avoid the pitfall of centralized key management is to instead turn to a decentralized solution and one that does not tie encryption to identity and access management controls. By desegregating your encryption KMS from identity and access management control systems, you remove that point of failure.    

Atakama’s multifactor encryption solution enables your business to embrace greater responsibility and control over key management for cloud encryption through BYOK or HYOK without the risks posed by central key stores. Atakama works at the file level by generating a unique encryption key for each file, splitting encryption keys into pieces, and storing each key fragment on at least two separate user devices (usually a workstation and a smartphone). Only authorized users can open encrypted files by approving a request in real-time on their registered mobile device.  

A decentralized and distributed key management architecture means there is no central key store. Since keys are split into pieces over multiple devices, protected files can’t be decrypted without physical access and compromise of several devices. This contrasts with a central key store implementation in which compromising one server may well provide unfettered access to your most sensitive data assets. 

Atakama is a solution that operates completely independently of IAM systems. Users become Atakama-authorized within the solution itself rather than by tying this access into your IAM controls. There are no backdoors for remote access or administration of any kind. Your sensitive data always stays protected even if threat actors manage to compromise your perimeter security and control someone’s IAM privileges. 

Using Atakama’s decentralized architecture, you can encrypt cloud data securely and with complete independence from IAM for broader levels of protection. 

Contact us today to strengthen protection for your most sensitive data assets in the cloud.