“We don’t need to have our own encryption keys, all of our data is in the cloud.”
Cloud services are a useful resource for shifting CapEx (capital expenditure) requirements to OpEx (operational expenditure). They remove the requirement to maintain expensive hardware infrastructure, and reduce the physical space an organisation needs to operate from.
There are three models of cloud computing. Each provides companies with the opportunity to transfer different amounts of responsibility to a central cloud provider, with differing associated costs and cost savings. Each model presents different levels of operational risk.
|Infrastructure as a Service (IaaS)||Shared hardware. Only data centre incidents are likely to affect multiple clients.|
|Platform as a Service (PaaS)||A solution for building and deploying applications. If the platform goes down the dependent applications do too.|
|Software as a Service (SaaS)||Everything except data is a shared resource. If it goes down for one, it probably goes down for all.|
But no matter how much responsibility an organisation transfers to the cloud, there are some things that cannot be transferred.
The cold, hard truth is this: in all models of cloud services, you remain responsible for your data.
So how safe is that data? What are you doing to protect it?
There’s a common line of thinking, among companies who make the transition to cloud, that if they use one of the major cloud providers then they don’t need to worry about security.
The assumption is that these larger corporations are super secure, because this is their whole business. While it is true that these cloud solutions, if the customer environment is properly set up, are likely more secure than a customer’s on-prem setup, they are not infallible. Ignoring the multitude of data breaches that occur due to customers incorrectly configuring their cloud environments, it is also important to remember that Cloud Service Providers (CSPs) are also companies reliant on people, and people are a point of weakness.
In recent years there have been a number of data breach incidents involving either the malicious actions of a CSP employee, or the targeting of a CSP employee’s account by external threat actors who then exploited their access. A couple of examples of this are:
- An AWS engineer hacked into the data storage of over 100 million AWS cloud customers and stole data. See GeekWire news article
- A Microsoft engineer’s account was compromised, resulting in threat actors gaining access to a signing key. This key was then used to attack high-profile customer accounts on both Azure and Exchange. See Duo’s news article
Our data’s encrypted so it’s all good. Right?
That depends. Who is looking after the key that unlocks it?
If the key is uploaded to the same cloud provider who holds the data, or is created by that cloud provider, then it is as secure as the cars in a valet parking lot. Access the keys, and you have access to everything they unlock.
What to do with your keys
As with all risk management decisions, there is no one-size-fits-all approach. Protecting confidentiality comes at a cost to operational availability. You need to strike a balance commensurate with your organisation’s risk appetite, risk tolerance and operational needs.
So what are the key management options, other than using the Cloud Service Provider (CSP)’s key?
|Options||Operational considerations||Security considerations|
|Client-Side Key Management Service (KMS):
Upload your own key to the CSP and use this for the encryption of your data.
|You remain responsible for all key generation and maintenance.
There is a risk that if the cloud provider is compromised, then the data will be too.
|Best operational option.
Common with SaaS applications.
Easiest for integration within the cloud environment.
|Remote Key Management Service:
Keys are held either by the organisation or by a third party separate to the cloud service provider.
|Good for security: Separation of duties between CSP and key management reduces risk that a compromise in one provider will lead to a data compromise.
Helps prevent vendor lock-in and improve portability
|There is a high availability requirement for the key, so if the connection to the KMS is lost, then the data is unusable.|
|Hold your own key:
Keys remain in the possession of the organisation at all times. Data is encrypted prior to uploading to the cloud and only decrypted once it is back on prem.
|Best for security: CSP does not have access to the key used to encrypt the data (so a compromise of the vendor does not result in a compromise of the data).
Prevents vendor lock-in and improves portability
|Time cost for decryption: Data must be brought back to on-prem and decrypted before use.|