Enclaver (and all secure enclaves) guarantees that any sensitive data inserted, processed or decrypted by the enclave can never be read by an attacker nor can it leave the enclave unless explictly allowed. This is the basis for the “magic formula” – trusted runtime, network policy, app code and identity.
In short, if you handled 100% of your plaintext or sensitive data within an enclave, you should be protected from an attacker that has exploited the infrastructure hosting the enclave. This is just like an attacker stealing your iPhone – they can’t obtain your fingerprint or FaceID.
It is your responsibility to ensure that only encrypted/hashed/tokenized data or summaries and non-sensitive result sets leave the enclave. Overall, the risk to your crown jewels, like encryption keys, is dramatically lower than using a regular virtual machine workflow.
Specifically Enclaver is focused on these threat reductions:
Application or infrastructure compromise
Unwanted Data Ingress
Unwanted Data Egress
Supply Chain Attacks
Reduced scope and footprint
Take care in returning data from the enclave to external parties and ensure your attestations are verfied, audited and specific. TODO: make this closing more specific
Existing tools for working with Nitro Enclaves provide awesome building blocks, but actually using those building blocks to run code in an enclave is challenging.
Enclaver makes it simple to put applications into Nitro Enclaves by automatically doing most of the heavy lifting, while encouraging best practices to keep enclaves “secure by default”.
With Enclaver, running a secure enclave feels just like a
docker run. More differences:
If you produce a container for the service or part of your app you’d like to run with Enclaver, all you need to do is add an additional build step. First, check in an enclave configuration into your code with parameters for running the enclave and the desired network policy.
In your continuous integration (CI) tool, after your container build is complete, run
enclaver build with a reference to the enclave configuration file. If desired, you can pass in the
from container image via flag or environment variable to reference the container you just built instead of using the configuration file. The result of your build is another container image, the enclave image, which you can push to your registry.
In your continuous deployment (CD) tool, update the references to the new enclave image. This is commonly in a systemd unit file and looks similar to
enclaver run registry.example.com/app:v1.0.1. It might be useful to consider a systemd drop-in for this purpose. After the unit is updated, execute a
systemctl daemon-reload to pick up the new unit file changes, and then
systemctl restart example.service to restart the enclave. When the restart is triggered, Enclaver will read the signal to stop the existing enclave, pull down the new enclave image and then start it based on the parameters in the embedded configuration file.