I’m writing a specification for a web app that will store sensitive user data, and the stakeholder asked that I consider a number of fairly standard security practices, but also including that the data be “encrypted at rest”, i.e. so that if someone gains physical access to the hard disk at some later date the user data can’t be retrieved.
The app is to be Node/Express on a VPS (probably against sqlite3), so since I would be doing that using an environmental variable stored in a file on that same computing instance, is that really providing any extra security?
I guess cloud big boys would be using key management systems to move the key off the local instance, and I could replicate that by using (Hashicorp Vault?) or building a service to keep the key elsewhere, but then I’d need secure access to that service, which once again would involve a key being stored locally.
What’s your thoughts, experience, or usual practice around this?
You must log in or register to comment.
“Physical access to the hard disk at a later date” sounds like the threat model they have in mind is someone forgetting to drill a hole through the drives after decom, in which case I’d guess they’re asking for fde that gets unlocked at spin up/keys stored in ram?
If I were you I’d go back to the stakeholder and make them clarify that part of the requirement/what they expect it to accomplish with it and what level of inconvenience they’re willing to accept.
I might be misinterpreting what you said, when I say that:
- I unfortunately don’t know how to provide Encryption at Rest on cloud based systems/services
My experience in providing data-at-rest_encryption aka Full Disk Encryption (FDE) is with LUKS2 on Arch Linux and NixOS
- you might want to verify with your stakeholder if ^this is what they’re looking for
hope the links help to provide a bit of clarification!
I guess cloud big boys would be using key management systems to move the key off the local instance
Yes, AWS uses KMS - by default everything like RDS is encrypted at rest through the AWS default KMS key (default for your account, not globally default). I’m still not entirely sure what the point is, since once you login to the AWS console, or connect to the database, everything is decrypted by default anyways. So I suppose the main thing it protects from is physical access.
You can make it more complicated by having more complicated KMS schemes, for example, see Demystifying KMS keys operations - That has a pretty good explanation of what KMS is, and the point of encrypted at rest (at AWS).
A reason customers could ask for encryption at rest could be that they want to be in control of the decryption key. Then at any point that would give them the ability to revoke the decryption key, and practically revoke your access to their data
But as @recursive_recursion mentioned, you should probably ask the stakeholder what the point is. 90% of the time the point is just some checkbox on a ISO27001 or SOC2 form. And “really providing any extra security” is not
So I suppose the main thing it protects from is physical access.
Yes, that’s about it AFAICT. Like if a service disposes of their disks incorrectly it shouldn’t expose the data.
