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?
Related
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 ?
The postgres docs on "Encryption Options" say:
Encryption For Specific Columns
The pgcrypto module allows certain fields to be stored encrypted. This is useful if only some of the data is sensitive. The client supplies the decryption key and the data is decrypted on the server and then sent to the client.
The decrypted data and the decryption key are present on the server for a brief time while it is being decrypted and communicated between the client and server. This presents a brief moment where the data and keys can be intercepted by someone with complete access to the database server, such as the system administrator.
"pgcrypto" is linked to the pgcrypto docs, which discuss a variety of available hashing and encryption functions.
But it's not clear to me how I'm meant to put them together to implement the solution the "Encryption Options" docs suggested, to allow certain fields (ie columns) to be stored encrypted. I am having trouble finding any docs or examples.
Can anyone point me to doc or examples explaining how you use pgcrypto to allow certain fields to be stored encrypted?
I'm trying to understand if there is a default encrypt/decrypt functions available in Tableau in any version(14/15/18).
Can we create customized function to encrypt/decrypt data?
As of version 2018, Tableau doesn't come with any Encrypt/Decrypt functions.
Here is a screenshot of all available type of functions in Tableau.
Some of the database drivers for Tableau allow you to specify an encrypted connection to the database (so the data is encrypted in transit). Some of the same databases can store data in encrypted form(so the data is encrypted at rest).
These features vary depending on the functionality of the data source.
So if you are talking to a text file, you don’t have encryption options, but most of the major databases do to a degree — maybe with SSL in transit. You can set up a virtual private database with Oracle for instance.
You asked about a function for encrypting data. Tableau doesn’t have a specific function beyond what I’ve described above, but you can also use the SCRIPT_STR() function and its cousins to call functions in R, Python or Matlab - so you can call an external encryption function if desired.
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.
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.