i want to encrypt data inside a table in postgresql, i may encrypt a few column or all column data in that table.
if i do query directly from sql client (DBeaver, Adminer) then i can retrieve the column value but it's not readable (because it's encrypted)
if my application (web apps) query the table data, it will show the readable data. web apps have the correct key to decrypt.
Question :
assuming i encrypt using a symmetric key (pgcrypto), how can i regularly rotate the symmetric key ?
can i implemented above case at AWS ?
Related
A third-party sends us a large CSV, an export from their (non-SQL Server) database. Several encrypted columns from their database were exported to CSV without being decrypted first. Separately, they sent us the symmetric key which they used to encrypt those columns of data.
We can decrypt those columns of data using a .NET program and the AesManaged classes before we import it into SQL Server; but is it possible to skip that step and decrypt those columns of data using T-SQL with their symmetric key after the data has been imported? Are there any decryption utilities in SQL Server that accept an AES_256 key as a parameter?
How can I encrypt just a single table data in redshift database?
I see that encryption is a cluster level setting. But I need to encrypt just 1 table and not all the tables of the database.
I have user personal information in the table that I want to encrypt.
No. As you say, encryption is a cluster-level setting.
You could encrypt the data in the table yourself, but this makes it hard to write useful SQL queries.
I need to encrypt some columns in a PostgreSQL 9.6 database. The data being encrypted is inherently sensitive; however, the data are not passwords or other authentication credentials. This data will need to be decrypted for statistical analysis and consumption by users.
After reading several questions and answers:
Storing encrypted data in Postgres
https://dba.stackexchange.com/questions/24370/how-to-use-aes-encryption-in-postgresql
https://dba.stackexchange.com/questions/59942/secure-postgresql-database-encryption
... and considering these comments:
... it seems the biggest problem with using the pgcrypto module is the storage of keys in the same database.
This begs the question:
Is it consistent with best practices to store the key in a different database and access it via a foreign data wrapper, such as Postgresql_FDW?
Secret storage is a common issue when using crypto mecanisms.
pgcrypto does not povide key storage, you are free to store the key where you want and protect it as you can.
Storing the key in another database, if managed by the same DBA does not provide much security as DBA may access it the same way.
Ideally, you would store the key in a secure vault and request it from your application in order to construct the queries. It will still be visible from DBA while the request is running through select * from pg_stat_activity.
You may set the key for a SQL session wide use through set session my.vars.cryptokey = 'secret'; then use it into your queries with the following syntax : current_setting('my.vars.cryptokey')::text
To be (almost) transparent from the application point of view, PostgreSQL rules may help for translating secure_column to the call to decrypt function with the session stored key. For inserting, a pre-insert trigger would be required.
I am coming from MySQL, and in MySQL you can use AUTOINCREMENT for a row's unique id as the primary key.
I find that there is no AUTOINCREMENT in Postgresql, only SEQUENCE or UUID.I have read somewhere that we can use UUID as the primary key of a table. This has the added advantage of masking other user's id (as I want to build APIs that take the ID in as a parameter). Which should I use for Postgresql?
A sequence in PostgreSQL does exactly the same as AUTOINCREMENT in MySQL. A sequence is more efficient than a uuid because it is 8 bytes instead of 16 for the uuid. You can use a uuid as a primary key, just like most any other data type.
However, I don't see how this relates to the masking of a user ID. If you want to mask the ID of a certain user from other users, you should carefully manage the table privileges and/or hash the ID using - for instance - md5().
If you want to protect a table with user data from snooping hackers that are trying to guess other IDs, then the uuid type is an excellent choice. Package uuid-ossp has several flavours. The version 4 is then the best choice as it has 122 random bits (the other 6 are used for identification of the version). You can create a primary key like this:
id uuid PRIMARY KEY DEFAULT uuid_generate_v4()
and then you will never have to worry about it anymore.
PostgreSQL 13+
You can now use the built-in function gen_random_uuid() to get a version 4 random UUID.
For many years I developed applications for databases using PKs and FKs as numerical sequential values. This has worked perfectly, but in recent years when creating cloud applications where information will be exchanged between applications and we will have integrations between various applications developed by us, we realized that the use of sequential IDs in our APIs ended up creating an effort.
In some applications we have to find the ID (of the target application) to be sent via the API call, on the other hand our database tables, in all our applications have, in addition to the sequential PK / FK column, a UUID column, which was not used in API calls. In this scenario we decided to rewrite the APIs so that the UUID column was used.
This solved some of the problems because one of our desktop applications would have their data migrated to another cloud application, this cloud application also used PK / FK columns. When migrating this data we had to change the values of the PKs / FKs for new sequences as the sequences could clash between the values of the desktop application and the values of the cloud application. With this in mind we chose to switch cloud application PKs / FKs to UUID, since data coming from the desktop application had a UUID column.
The problem then was to convert the cloud application tables by turning the INT columns (PKs and FKs) into UUID columns without losing the table information. That was a big task, but it was made easier because I ended up building an application that makes this change easer. The application changes every PK / FK integer column to UUID, keeping the data and relationships. Anyone interested follows the link:
https://claytonbonelli.github.io/int_pk2uuid_pk/
You can use UUID as primary key in your table as it will be unique. However do keep in mind that UUID will occupy a bit more space as compared to SEQUENCE. And also they are not very fast. But yes they are for sure unique and hence you are guaranteed to get a consistent data.
You can also refer:
UUID Primary Keys in PostgreSQL
UUID vs. Sequences
The document here: http://www.postgresql.org/docs/8.2/static/encryption-options.html describes several approaches to encrypting data when using postgresql.
I would like to know if there's any security advantage to encrypting specific columns using pgcrypto instead of simply encrypting the entire partition on which the database resides. It seems to me that pgcrypto is cumbersome to use(instead of just using SQL queries without having to worry about things being encrypted) so there should be a reason for its existence. Is it simply that people may not have the ability to manage the database server(shared hosts/etc...) so they would have to make-do with pgcrypto, or is there a security reason?
In my particular case, the application code and the database are on the same host, so compromising the server itself while it is live would result in the data being leaked either way(one could look for the encryption key in the code in one case, or simply retrieve the data from the mounted volume in the other).
Edit: I forgot to mention, also in this particular case, the data is used by the server not the client, ie, the client can't provide the key at run-time it would have to be on the server in the application code.
You can give the DBA SQL level access without compromising data.
You can have separate encryption keys for different data
Your backups (dumps) are encrypted
If the client provides the encryption keys, The server does not have to be trusted
If You separate the app server from the DB server, the encryption keys can be on the app server only.
You can encrypt only a part of the data.
Last but not the least: There is more to pgcrypto than symmetric single-key encryption, like asymmetric encryption, cryptographic hashing, cryto-safe PRNG, password-hashing.