The challenge of Cloud security
Migrating business elements to cloud services can deliver significant cost and efficiency gains for organizations of all sizes. The Cloud enables enterprises to reinvent their business models, forge better relationships with customers, take significant costs out of their operations and get successful innovations to market ahead of competition. But, while multiplying opportunities, cloud computing can also multiply risks. The rise of cloud has led to a new breed of security vulnerabilities and amplified existing ones. I addressed some of those aspects in a previous blogpost, where I described the Cloud shared responsibility model, the need for a single pane-of-glass approach and for shifting left security.
Identities are the new perimeter & permissions are the new attack surface
Due to cloud migration, remote working, and remote objects connection to the organization systems, the organization network perimeter is disappearing.
Data is flowing between edge devices, employee devices and the organization cloud (applications remaining in Data center, those migrated to Infrastructure-as-a-Service providers and Software-as-a-service applications like Salesforce, ServiceNow, Workday, Office365, G Suite, Dropbox, Linkedin, …).
What defines its perimeter becomes the employees identities.
The protection of this data is relying on the access rights the enterprise has provided to its digital identities: users, applications, devices, objects, machines. Indeed, while users need access to applications in order to consume the data, the organization applications need also access to other external or internal applications to increase data value, and devices' needs to update and/or consume the data.
As a consequence, when stored in a public cloud environment (IaaS, PaaS or SaaS) your data is sitting one permission and authentication away from your users and systems, as well as from anyone and anything else in the world, people, applications, devices, objects, machines. A single permission mistake or credential leak provides direct access to your data.
In parallel, you might also be concerned that your data is stored on an environment shared with many others and to which one cloud service provider has full authority and access upon.
For all those reasons encrypting your data is a good idea. Indeed, should permissions to your data be bypassed for any reason, you might want to trust that only authorized users can decrypt them and read their clear text content. This is the main challenge driving sovereignty over your data when using cloud services.
Cloud service providers have understood this requirement and have invested in technologies allowing encryption of the data, applications, and systems they host for their customers.
However, this comes with technical challenges and requires proper understanding of all the various possibilities offered and level of trust they allow.
In a nutshell, there are 3 main categories of cloud encryption:
a/ Full cloud encryption: customer relies on the cloud service provider encryption solution and generation, storage and management of encryption keys. Some variants exist, like customer managed keys, which allow customer to manage encryption keys generated and stored by the cloud service provider.
b/ Bring your own key: still relying on the cloud service provider encryption solution, customer is in control of encryption keys generation, storage and management. It is important to clearly distinguish data encryption keys and key encryption keys.
- Key encryption keys are used to wrap (act of encrypting an encryption key)
- Data encryption keys being the ones encrypting the data.
It is important to be clear with the cloud service provider, on which of those keys are under full control of the customer.
c/ Bring your own encryption: customer chooses not to use the cloud service provider encryption solution. It will encrypt the data itself with a tool of its choice and also be in full control (generation, storage, management) of all the encryption keys (data encryption keys and/or key encryption keys). It is the most advanced solution for the customer, but it requires to implement an encryption system on top of its public cloud environment or to implement "Client-side encryption" or an "Encryption gateway" (cf. illustration below).
This third category still comes with some limitations like decryption of data in use when the application is deployed on an IaaS, but also loss of compatibility with some of the cloud service provider services. Some of those issues are being tackled by the cloud service providers, so they can address more sensitive use cases. As an example, confidential computing is promising additional protection for data in use, while, in a mid and long-term perspective, functional encryption and fully homomorphic encryption will allow applications and systems to perform operations on encrypted data without decrypting them.
In an upcoming blog I’ll go through best practices for cloud encryption and how the Atos Trustway DataProtect solution covers those while providing strong European sovereignty.