Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data security at record level #724

Open
martijndeb opened this issue Oct 16, 2017 · 2 comments
Open

Data security at record level #724

martijndeb opened this issue Oct 16, 2017 · 2 comments

Comments

@martijndeb
Copy link
Member

martijndeb commented Oct 16, 2017

Description

As mentioned on the generic Slack channel; @julianguyen replied to this already.

Data in the database is of poor encryption value. The password field for users is hashed, but that's about it. I can't look if postgresql is configured to encrypt using pgp certificates at the live server, but that's something often overlooked.

Data should be encrypted at the record level as well in case of data theft / server breach. This might even be required in some countries. (For example, the Netherlands is thinking about that). And some organisations might require it before endorsing the if-me application.

As mentioned in the channel as well this might be accomplished using a transparant encryption engine. Crypt_keeper looks nice, but not sure if it's compatible with Rails 5. (https://github.com/jmazzi/crypt_keeper) also attr-encrypted might proof to be another option (https://github.com/attr-encrypted/attr_encrypted).

Also crypt_keeper is able to encrypt current tables on the fly, which would make sure that all data can be migrated quite easily.

Let's keep data secure!


Please assign yourself (via the Assignees dropdown), if you do want to work on this issue. Can't find yourself? You need to join our organization.

Check out our Picking Up Issues guide if you haven't already!

@HashNotAdam
Copy link
Collaborator

The challenge with this is that the database should already be firewall protected from communicating with any server other than the web server. This means that, if you wanted to steal the database, you would need to compromise the web server and, if you can compromise the web server, you could just download the database via Rails... which is going to need to be able to decrypt the data.

@martijndeb
Copy link
Member Author

That's not entirely true. Different threats need to be mitigated in a different way.
Say for instance postgres runs as a different user, and somehow postgres user was compromised or the interface exposes raw data on the web, you would still need application logic to decrypt the data.

What you are proposing is elevated access, but one wouldn't always get elevated access when breaching a machine. So say this is what happened, then you wouldn't require record level encryption, but the postgresql pgp encryption would suffice. But I don't see any configuration for that in the repo for that neither.

Enabling postgresql pgp certificates would still make the service prone to memory leaking errors, but if you are able to pull that off you probably have elevated access as well.

I still think this is a great improvement, and still a requirement for some organisations / law in different countries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants