Encrypting data at rest

AI-generated summary

The discussion revolves around encrypting data at rest in a private financial forum using Discourse. dhyasama initiated the conversation, considering options such as column-specific, whole database, and whole disk encryption at the database level. They also plan to use server-side S3 encryption for attachments.

sam recommends disabling S3 and handling all data personally or enabling full disk encryption on the Linux server. codinghorror suggests using Postgres encryption, which covers most data stored in the database but not uploads, images, or attachments.

The conversation further explores encryption options, including data partition encryption, which can be layered on top of a file system mount using a “loopback device” on Linux. sam notes that encryption for specific columns requires application-level changes.

sam eventually recommends the following:

  • For AWS users, rely on AWS features like DB encryption at rest and S3 server-side encryption.
  • For self-hosting on Digital Ocean, use OS-level encryption, such as LUKS.

A relevant article for AWS users on DB encryption at rest is also shared by dhyasama.

For a variety of reasons I’d like to encrypt all data at rest in our private financial forum. What are the options and issues?

At the database level, common approaches are column-specific, whole database, and whole disk. Are any of these possible with Discourse? If so, what are the pros and cons?

For attachments, I’m uploading to S3 and plan to turn on server-side S3 encryption which should be transparent to Discourse. Has anyone tried this yet?

1 Like

I would recommend

  1. Disabling S3 and handling all data yourself
  2. Enabling full disk encryption on your linux server

I would strongly recommend not trying to hack the app to support this edge case, its a solved problem.

4 Likes

Option #3 there, to enable Postgres encryption, is also a good possibility. But doesn’t cover uploads, images, or attachments of course.. only things stored in the database, which is most stuff in Discourse.

1 Like

That is basically #2

Data Partition Encryption
On Linux, encryption can be layered on top of a file system mount using a “loopback device”. This allows an entire file system partition be encrypted on disk, and decrypted by the operating system. On FreeBSD, the equivalent facility is called GEOM Based Disk Encryption, or gbde.

This mechanism prevents unencrypted data from being read from the drives if the drives or the entire computer is stolen. This does not protect against attacks while the file system is mounted, because when mounted, the operating system provides an unencrypted view of the data. However, to mount the file system, you need some way for the encryption key to be passed to the operating system, and sometimes the key is stored somewhere on the host that mounts the disk.

The other option for encryption is not applicable

Encryption For Specific Columns requires application level changes

Oh wow Postgres doesn’t offer table level encryption?

yeah you would need to do it column by column, but the general approach is just to do this at filesystem level. simpler.

Relevant article for AWS users:

4 Likes

Our current recommendation is:

  1. If you are on AWS, rely on AWS features like DB encryption at rest and S3 server side encryption.

  2. If you are self hosting on digital ocean, use OS level encryption, for example LUKS.

9 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.