The cloud computing paradigm has gained increasing attention from both industries and academia due to the almost-unlimited scaling potential through a lean and dynamic utilization of resources (ISC² Cloud Security Report, 2020). As identified by the National Institute of Standards and Technology (NIST), cloud computing possesses the following essential characteristics:
1. Broad network access
2. Rapid elasticity
3. Measured service
4. On-demand self-service
5. Resource pooling.
NIST also specifies three service models,  Software as a Service (SaaS),  Platform as a Service (PaaS) and  Infrastructure as a Service (IaaS), and four general deployment models, [a] public cloud, [b] private cloud, [c] hybrid cloud and [d] community cloud (csrc.nist.gov/Projects/Cloud-Computing).
With technological progress making computing machines more powerful, it is not by chance that the most successful organizations in the last decade have been those which managed to fully exploit the properties of the cloud: as computation cost per unit decreased exponentially, cloud computing has been turned into a utility paradigm, since the possibility of sharing resources considerably lowers operational expenses (OpEx) and the initial upfront capital needed as investment (CapEx). Moreover, the ubiquity of data in the cloud makes access and retrieval easy and cheap enough to be considered almost instantaneous, thus giving the possibility to create subscription-based services that can be consumed directly online.
Companies not only store huge amount of data in the cloud, they also develop platforms where software can be deployed and run. Unfortunately, security concerns are often being understood as strictly related to the service model adopted, while in truth much more attention should be placed to the risk assessment of the ecosystem as a whole: cyber-related risk management should finally find its way to board meetings’ agendas, discussing a clear strategy and an allocated budget to support it, especially with multi-cloud setups, where organizations use more than one service from more than one cloud provider in a single network architecture. In reality, deploying applications in a hybrid manner is an increasing trend, with 46% of respondents to the ESG Master Survey confirming their container-based applications are deployed across a combination of public cloud platforms and private datacenters (Leveraging DevOps to secure cloud-native applications, 2019). According to a recent survey, 83% of organizations globally use more than 10 different cloud environments simultaneously (Thales Data Threat Report, 2020). So, while cloud adoption has created a series of configuration management challenges, due to a substantial lack of visibility of how operations should be organized in environments with shared responsibilities, multi-cloud setups have exacerbated these challenges, introducing new obstacles (Oracle & KPMG, Cloud Threat Report 2020).
How can you protect data in the cloud?
Encrypting data is one of the most important requirements for a safe storage, transfer and processing in the cloud. Obfuscations techniques transform plaintext data into unreadable ciphertext, thus preserving the CIA triad: confidentiality, integrity, and availability. And while encryption does not represent an insurmountable task per se, as it follows standards like the AES, managing the lifecycle of cryptographic keys (generation, usage, storage, archiving, and deletion) becomes non-trivial and error-prone in multi-cloud setups: in fact, secure management of cryptographic keys across different clouds imposes real challenges, as highlighted by 76% of the respondents to the KeyFactor and Ponemon Institute survey on PKI and digital certificates management practices (The Impact of Unsecured Digital Identities, 2020). And with most cloud service providers having their own key management system, trying to create a harmonized approach across clouds often results in higher complexity, inconsistency and misconfigurations, leading to increased security risks. Adding to the argument, physical location of data and keys constitutes another serious risk since it involves compliance issues: depending on the geographies, data ownership and privacy are governed by different jurisdictions with different laws, such as the GDPR, BDSG or the CCPA, as well as industry-specific regulations like HIPAA and PCI DDS.
Managing cryptographic keys is usually implemented either through Hardware Security Modules (HSMs) or Key Management Service (KMSs). HSMs are physical computing devices with a dedicated cryptographic processor which safeguards cryptographic keys. These hardened and tamper-resistant devices exploit the principle of non-extractability: keys are stored within the hardware while encryption and decryption are executed securely within the module.
Obviously, HSMs provide the highest physical security in the market and companies typically choose to have HSMs on-premise while CSPs offer the possibility to use their HSMs as a service. In the former case, these very expensive setups are exposed to issues such as connection latency during encryption and decryption processes, in the latter instead, key management complexity often shifts responsibility to the CSPs entirely.
To mitigate these limitations, Key Management Services (KMSs) have now become part of the CSPs offering, thus giving companies the opportunity to bring their own cryptographic keys into the cloud: namely, customers generate their cryptographic keys using their on-premise HSMs and successively upload them to the cloud KMS. Such model is commonly referred to as Bring Your Own Key (BYOK), and even though it is generally thought to increase the security level of operations in the cloud, it actually requires considerable caution. More precisely, BYOK is only valid for the Customer Master Key (CMK), which by nature is not used to protect sensitive data, rather used to generate and/or encrypt other cryptographic keys which in turn will protect data.
Another crucial hurdle is presented by the lack of standards, that is scarce interoperability among different cloud providers in a multi-cloud scenario: the CMK needs to be distributed safely to each one of the clouds used, and each cloud having diverse structures and logics makes it very complicated to apply the BYOK model correctly. On top of this, it is rather unclear how the encryption mechanisms would be used across different CSPs. In fact, even though organization might come up with a sound architecture that nicely distributes the same CMK to the various cloud environments, data encrypted in one cloud would still require the following intermediate steps before it can be transferred to another cloud:
- decryption of the encrypted data in the original cloud
- encryption to protect the data in transit from the original cloud to the destination cloud
- decryption of the encrypted data upon arrival at the cloud of destination
- final encryption of the data in the cloud of destination, according to the cloud’s own KMS (which is different from the original cloud’s KMS)
To correctly execute this non-trivial process aimed at protecting both data-at-rest and data-in-transit in/to all clouds, qualified personnel with the expertise and the appropriate knowledge is needed. Even though industries are still struggling to find professionals with competencies that could fill the cybersecurity skills gap, it is not by chance that current trends show multi-cloud setups have quickly become the preferred model chosen by most organizations (ESG Master Survey, Technology Spending Intentions Review 2020). Adopters do not feel locked-in with only one cloud vendor anymore, they rarely experience significant service downtimes and they can comply with privacy regulations and data governance more efficiently by storing their data in different geographical locations. Obviously, due to their complexity, multi-cloud setups also pose a handful of challenges: data ownership, control and responsibility are shared among different CSPs and different regions, leaving open the door to misconfigurations and increasing the attack surface available to malicious actors.