Open Wilfongjt opened 5 years ago
Any personal, personally-identifiable "data-at-rest" data should be encrypted, imo. I don't know what you're keeping on people, but things like birthdays, email addresses, passwords (especially), etc. would qualify. Publicly-available information probably wouldn't qualify. And by encrypted, I really mean hashed.
Can Postgres be encrypted? Anything can be encrypted. It's the mechanism for storing and retrieving it (in the development platform) that matters, not where you're storing it.
I recently encrypted (again, hashed) passwords in a SQL-server database. It took all of a couple minutes to enlarge the size of the field to hold the hashed password, as well as to implement the one-way hash-and-match algorithm(s) (they were built into the language).
Pros include security. Cons include increased data storage, a small-to-medium one-time effort to implement, and a tiny performance hit.
The passwords are currently being hashed.
Database Encryption
Encryption became a thing for me after a year of hardening State of Michigan (SOM) data servers due to the embarrassing theft of South Carolinian tax records by hackers in 2012 https://www.nytimes.com/2012/11/21/us/more-details-of-south-carolina-hacking-episode.html .
The SOM project focused on data-in-transit and data-at-rest. Data-in-transit is data transferred from one system to another (eg, browser to and heroku). Data-at-rest is data that sits on hard drive ( eg, a database).
Currently, AAD is NOT encrypting data-in-trasnit nor data-at-rest. We have initiated the encryption of data-in-transit for AAD but we have no plan to encrypt data-at-rest. Please forgive my directness but encription at rest keeps the DBA honest. A majority of breaches are 'inside jobs' folks with access selling personal data.
My subsequent PTSD from that SOM experience makes me want to encrypt everything. Before I give into to my reflexes, please offer advice or opinion on encrypting the Postgres database.