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.
Related
As part of GDPR requirement we need to encrypt data at rest.
We are planning to use Postgres and from the below links looks like TDE can be achieved in Postgres as well.
https://www.enterprisedb.com/blog/postgres-and-transparent-data-encryption-tde
https://www.cybertec-postgresql.com/en/products/postgresql-transparent-data-encryption/
When we have multiple schema in Postgres, is it possible to apply TDE only in a particular schema?
Unfortunately it is not possible to just encrypt a schema because, when you install PostgreSQL TDE, you initialize the whole database with the encryption key.
Like you can see in the picture here:
there is a reason for this: if we allow encryption on a per-table level (or per schema or per database, doesn't matter) we got to manage an infinite number of keys. this is especially true during point-in-time-recovery and all that. this is why we decided to do the encryption on the instance level. one key. the core advantage is: we can easily encrypt all parts of the instance including the WAL, temp files, and so on (basically everything but the clog).
don't expect this to change - go for full encryption.
we can help you with that.
cheers from cybertec :)
i hope you like the feature :)
hans
All,
I have to BULK Insert data into AzureSQL from a Azure Blob Storage Account. I know one way is to use SAS keys but are there more secure ways to load data from T-SQL?
For example, is there a way to use the users AAD account to connect to the Storage? Would Managed Identity work? I have not come across an example in the Internet that uses anything other than SAS Keys.
Gopi
azure data factory generally serves this purpose. You can build a pipeline that grabs data from blob and massages it / loads it into sql, kind of what it's designed for. However if you do not wish to use that,
the recommended way is SAS because it can be temporary and revoked at any time. Why do you think SAS is less secure?
as per the documentation: https://learn.microsoft.com/en-us/sql/t-sql/statements/create-external-data-source-transact-sql?view=sql-server-ver15#credential--credential_name if you were to create an external data source with blob_storage type the identity/credentials MUST be SAS, as it doesn't support any other authentication type. as such, that means you cannot use any other auth method to a blob storage using tsql.
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 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.