Is The Public Cloud “Possibly” Now More Secure and Resilience Than On-Premise?

The answer is mainly, “Yes”

Photo by John Salvino on Unsplash

Is The Public Cloud “Possibly” Now More Secure and Resilient Than On-Premise?

The answer is mainly, “Yes”

Often there’s a carrot-and-a-stick approach to implementing information security. With a carrot approach, we hope that companies will look after customer data — because it is a good thing to do. Overall, they will generally gain the trust of their shareholders, and from their customers, and thus strengthen their brand. The stick approach, though, is where we must force companies through audit/compliance approaches, along with stiff fines for data breaches. Unfortunately, the latter one is often still the case, and where companies need to be “forced” to improve their security.

A core decision for any company is the move into the public cloud, and where security is often seen as one of the greatest concerns. Performance, cost (mainly for CapEx v Pay-as-you-go), resilience and useability have all been addressed well with this move, but security is still one of the main reasons that a company may retain its on-premise infrastructure.

So can security actually be better in the public cloud?

So, is our on-premise security actually worse than using the public cloud? At the core of good security should be strong access controls and in the usage of encryption. Basically, it is like having good locks on your doors and making sure that only the right people have the keys to your locks. Imagine purchasing a house, and finding out that there were no locks on the doors, and being told, “Ah, doors locks are an optional extra”.

And so we must ask ourselves, “Does your company have an encryption-by-default”?”, and “As a bare minimum, is all our customer data encrypted and limited in its access?”.

Over the past decade, security in the public cloud has improved massively, especially as developers have made full use of the features that have been added. Every data breach in the Cloud does not look good for Cloud providers, and so they have generally pushed customers towards good security practices. But, where do you store your encryption keys in a public cloud environment?

HMS and KSM: What’s the options?

Well, at the core of cloud security is the Hardware Security Module (HSM). This is a place that generates, processes, and stores encryption keys. In there, the secret keys are never exposed, so no one can steal them — and where we can lock down their access. But, it is also where to can encrypt and sign data without exposing our keys.

In AWS, we have AWS HSM and in Azure we have KeyVault. For simpler and less costly solutions, we have AWS KMS (Key Management Solution). For HSM, we pay per hour, but for KMS, we just pay for the usage of the keys. Along with this, both AWS and Azure offer a place to store secrets (such as database and API passwords), such as for AWS SecretManager service. The downside of KSM is that the encryption options are limited to the most popular ones, but where the HSM can implement a wider range of methods.

Symmetric key in the Cloud

In AWS KMS, we get one type of symmetric key encryption (AES GCM), and which is typically the best around. If you need something like ChaCha20 or 3DES, then HSM is an alternative:

Public key encryption in the Cloud

For asymetric key encryption (aka public key encryption), it basically supports only RSA for 2K, 3K and 4K key sizes:

Again, RSA is probably the best choice for most corporate systems (and where only ECIES would come near RSA in its usage).

Digital signatures in the Cloud

When it comes to digital signing, there are many more options. This includes RSA and ECDSA signing, but with no EdDSA or Schnorr signatures. A great feature of the KMS in AWS is that it supports the secp256k1 curve (and this can integrate with Bitcoin and Ethereum transactions):

Resilience of keys

And, of course, resilience is a key factor of working in Cloud, and where the HSM is backed-up every 24 hours, and where we can cluster the HSMs into a single logical HSM. These are then replicated into AWS regions. With KSM, the keys are placed in more than one availability zones within an AWS region, so a failure of one data centre will not cause the keys to fail. For Azure, the keys are automatically replicated into a secondary region which is at least 150 miles away, but in the same geography.

But, what happens if an intruder gets one of our keys, well for this, AWS uses envelope encryption, and where we generate unique keys to encrypt our data elements and encrypt this with a root key.

Go do some crypto in the Cloud

So, if you are interested, here are some labs on using encryption within AWS:

  • S3 buckets. Go. A lab to set up S3 for bucket creation and deletion, along with the encryption of buckets and files on S3 storage.
  • Symmetric Key Encryption. Go. A lab to outline the usage of symmetric key encryption using KMS.
  • Public Key Encryption (RSA). Go. A lab to outline the usage of public key encryption using RSA, and in storing the key pair in KMS.
  • Public Key Signing (RSA). Go. A lab to outline the usage of public key encryption using RSA, and in storing the key pair in KMS.
  • Public Key Signing (RSA) and OpenSSL. Go. A lab to outline the usage of public key signing using RSA, and storing the key pair in KMS.
  • Digital Signing with ECDSA. Go. A lab to outline the usage of public key encryption in generating an ECDSA signature, and in storing the key pair in KMS.
  • HMAC. Go. A lab to outline the usage of an HMAC signature, in KMS.
  • Secrets Manager. Go. A lab to outline the usage of secrets manager in KMS.
  • Envelpope Encryption. Go. A lab to outline the usage of envelope encryption in KMS.

Conclusions

No excuses for companies to secure their cloud infrastructures. AWS KMS provides the “best in practice” encryption methods, and if you need more you can have HSM. S3 buckets now have encryption-by-default, and time-limited shares. No matter if you use Azure or AWS, there’s an encryption solution that should be fairly easy to implement. As with many things in the Cloud, it comes with a cost, but the cost of leaking data or intellectual property is probably a lot more costly than a few dollars a month in additional costs.

If you’re a CEO, consider a policy of encryption-by-default, as your company needs to move its security into the 21st Century sometime … non-encryption of data is so 20th Century!