this post was submitted on 08 Jun 2024
17 points (100.0% liked)

Learn Programming

1631 readers
1 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
 

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?

top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 7 points 5 months ago

"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.

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago)

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!

[–] [email protected] 2 points 5 months ago (1 children)

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

[–] [email protected] 1 points 5 months ago

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.