Cloud is a great thing. It allows us to access storage and compute with the click of a button. While this is helpful, it also poses significant challenges:
How can we make sure our files are safe?
How can we ensure that if due to a misconfiguration we allowed access to the blob storage, no one will be able to extract this data?
Can we trust the cloud vendor and their employees to not access our data?
When using Azure Blob, you can encrypt your objects in two ways:
Fire and forget – you click on the “encrypt” option when creating the blob. The files you write to the blob will be encrypted – or so Microsoft promises!
Supply a key (currently in preview) – you can send your object to a blob and specify the encryption key. Azure will encrypt the file with the given key and delete the key. Since you have the key, you will be able to decrypt the file – only if the workload that accesses the file has the key.
In addition to this, Microsoft has another security mechanism: the usage of access keys. Only workloads with appropriate access keys can access the relevant blob. You need to manage the keys (distribute, revoke, rotate, grant etc.) and if someone steals a key, they can access your data!
Throughout my 20 years in Cyber Security, I have never seen an organization that likes to share their encryption keys; not with 3rd parties, and not even with teams inside their organization.
How can you control the keys, and encrypt and decrypt files without sharing the keys?
How can we make sure that even if our workload is compromised, no one can steal our data?
And even if data is stolen, how can we ensure that it’s fully encrypted – thus useless for the attacker?
ARMO introduces the Encryption Gateway Guardian. The Encryption Gateway Guardian or EGG seamlessly blends into your Azure deployment. It provides the following robust capabilities:
Selective encryption: based on user, key, workload identification, time, or any other combination. This gives you the ability to control who can access the data and how data will be encrypted. For example, you can decide to allow users to write files to blob but read the data after an approval process for a window of 30 minutes.
Keyless encryption: ARMO can encrypt the data without the need to keep the entire encryption key. ARMO can split the key with you, where you will have half of the key and the other half will be stored in the ARMO management system. Once needed, the gateway will build the entire encryption key. This allows you to hold part of the key and give your customers the other half of the key, thus ensuring that no one can decrypt the data on their own.
Moving target: the encryption gateway keeps the keys (encryption and access) in a mask that’s constantly changing. Even if an attacker scans the encryption gateway memory, they will not be able to extract the encryption keys – as they are mathematically protected with a function that’s constantly changing, making it virtually impossible to reverse engineer.
Access policy: ARMO provides a strict access policy which is based on a strong identity and patented technology. You can define which workload can access (read or write) data to the security gateway. This will make sure that even if someone accesses your blob due to misconfiguration or by exploiting a workload, the data they can access is useless. This removes the burden of managing access keys.
No need to change your software: there is no need to change anything to get this magic working. The ARMO encryption gateway is installed on the storage explorer machine, and acts as a proxy for all read/write requests – making sure that data is treated based on the defined policy.
High level architecture:
The ARMO Encryption Gateway (a very thin application at just a few megabytes) is deployed on the machine that runs the storage explorer.
The gateway connects to a SaaS service which manages the solution. You can create the keys using the ARMO management system or use a command line (CACLI) utility to automate this.
Using the user interface or CACLI, you can define access policy based on workload identity.
Data is encrypted on write, and decrypted upon read.