I want to load data (few encrypted fields) into Redshift and few users should have access to decrypt those encrypted fields. Please suggest the best approach to achieve the result.
I tried the below python udf but it did not work.
Redshift Python encrypt/decrypt UDF Error - String contains invalid or unsupported UTF8 codepoints
How should we enable to encryption/decryption at column/field level in Redshift
If you wish to secure the data by encrypting the data, you would need a way to pass the encryption key with the query, otherwise anybody with permissions to use the UDF could decrypt the data by simply calling the Decrypt UDF. Such encryption is only useful if you wish to enforce encryption at rest, which is easier done by configuring Redshift to encrypt all data at rest. (Note that this can have a performance impact.)
The recommended method of controlling access to columns is to restrict access to the underlying table, but grant access to a VIEW that contains only the permitted columns:
CREATE VIEW my_view AS SELECT col1, col3 from my_table;
GRANT SELECT ON my_view TO GROUP restricted_group;
REVOKE ALL ON my_table FROM GROUP restricted_group;
Related
I am facing an issue where I have to decrypt a db column in Snowflake.The transformation to decrypt the column is a unix command.How do I achieve this decryption in Snowflake.
If you have a row with normal data and one column that is encrypted, and
are not prepared to decrypt the column prior to loading the data into Snowflake
you are also not prepared to decrypt the column after returning result rows from Snowflake via a query.
Then point 2 would imply you ether cannot decrypt client side, OR you need the results to do some form of JOIN/Filtering on, that it would make sense to store the data non-encrypted.
When you refer to decrypt as a command line tool, implies to you are ether encrypting the whole file/pipe-stream with does not match your column reference.
But if you have to decrypt in Snowflake you will need to implement a Javascript UDF to do that. You might find the Using Binary Data doc's helpful.
You can't run unix commands in the Snowflake environment.
If you can't do client side decryption on the way in or out, you have to figure out what the unix command actually does and hopefully you will be able to recreate it using the Cryptographic/Checksum functions.
I'm create SQLite databse with DB Browser for SQLite (non encrypted) and open with FireDAC in delphi.(Can retrive data Eg. Select * from abc).
How encrypt this SQLite database with FireDAC? When enter username, password and encrypt get message "Cipher DB is not encrypdet"
Note:
When create SQLite database from Delphi FireDac I can use encryption!
To encrypt a database, use a TFDSQLiteSecurity Component. You'll also need a TFDSQLitePhysSQLiteDriverLink component to go along with it.
If a database is unencrypted, then its password is ''. So use '' as the OldPassword and create the new password in that case. Passwords are formatted as algorithm:PassPhrase. See documentation on the choices, I use aes-256. Also, the database needs to be closed when you do this.
...
//Change password
FDSQLiteSecurity1.Password := OldPassword;
FDSQLiteSecurity1.ToPassword := NewPassword; // example: 'aes-256:mypassword123'
FDSQLiteSecurity1.ChangePassword;
...
//Remove Password
FDSQLiteSecurity1.Password := OldPassword;
FDSQLiteSecurity1.ToPassword := '';
FDSQLiteSecurity1.RemovePassword;
...
From the Documentation
SQLite Encrypted Database
Approach
One of the distinctive SQLite
features is the high-speed strong database encryption. It allows you
to make database file content confidential and enforce integrity
control on the database file. The encrypted database format is not
compatible with other similar SQLite encryption extensions. This means
that you cannot use an encrypted database, encrypted with non-FireDAC
libraries. If you need to do this, then you have to decrypt a database
with an original tool and encrypt it with FireDAC.
Recent Delphi versions come with an example project for working with encryption on Sqlite databases, see this documentation. I have not used this myself, btw.
It includes this section
Encrypt DB
Encrypt: Encrypts the database according to the Encryption mode and the password provided.
The sampe uses TFDSQLiteSecurity.SetPassword to encrypt the database with the password provided.
The database password is the combination of <encryption algorythm>:<password>.
I have faced several challenges when first time tried to encrypt SQLite database for use with Embarcadero FireDAC. Also all information is published by Embarcadero question pops up again and again on different forums. My case was solved based on community support, but when time has permitted simple Delphi application was assembled and available on Sourceforge. Hope it will make encryption/decryption slightly easier particularly for the newbie
https://sourceforge.net/projects/sqlite-sequrity-for-delphi/
FMDB version (2.6.2)
Problem:
I am testing FMDB and SQLCipher, and find a tricky problem.
I encrypt a db with password 'test001' successfully, and I export it and open the db with DB Brower, with 'test001' I open it without any problem. Then in Xcode I try to open the DB with password 'test002'(I do this to test if FMDB will tell me that I use a wrong password), however the setkey() return YES. I check db.lastErrorMessage, it returns nil, which means FMDB thinks I give the right key.Then I try to read data from the DB using executeQuery(), the function returns NO, and the NSLog shows 'file is encrypted or is not a database'.
Anyone has the same problem? Is it a bug of sqlite or I use it in a wrong way?
setkey() return YES
executeQuery() return NO due to decrypt error
The call to setKey(…)does not verify the password provided is valid for current database, rather it just causes the database to attach a codec context within SQLCipher. The next SQL command that you issue following the keying of the database will cause key derivation to occur (so long as you are not using a raw hex key), and will generally validate whether SQLCipher is able to use the key to access your database. We generally recommend you attempt to execute the following query to validate the password is valid as the sqlite_master table will always be present, regardless of your schema.
SELECT count(*) FROM sqlite_master;
I have set up table-level InnoDB database encryption on MariaDB.
I'd like to know if there is any way to confirm that the data is truly encrypted. I've tried searching /var/lib/mysql/ibdata1 for sample data in the tables, but I don't know if that's a reliable test or not.
I posted this question on mariadb.com, and the suggestion there was to perfom a grep for some known data.
A DBA at Rackspace suggested using the strings command instead, to better handle the binary data, for example:
strings /var/lib/mysql/sample_table/user.ibd | grep "knownuser"
This approach returns no results on an encrypted table and does return results on an unencrypted table (assuming both have "knownuser" loaded into them).
You can query information_schema.innodb_tablespaces_encryption. When innodb tablespace is encrypted it is present in the table.
SELECT * FROM information_schema.INNODB_TABLESPACES_ENCRYPTION
WHERE NAME LIKE 'db_encrypt%';
source
My advice for testing is to copy the full dataset to another node without the encryption keys in place and try to start MySQL and query the encrypted tables. I'm making an (big) assumption that they will not be readable since the valid encryption keys are missing.
To parse the files on disk as they lay may prove difficult unless you have a special tool to do this. Maybe something like Jeremy Cole's innodb_ruby would be another litmus test https://github.com/jeremycole/innodb_ruby.
[probably don't works if you change the key which encrypts the log.]
Stop the database server.
BACKUP the keyfile
Change a key in the keyfile. (don't delte - it still has to remain a valid key otherwiese the server can't restart)
Start MariaDB again.
Try to read the table (e.g. with phpMyAdmin).
If encrypted correctly there is an answer: "The table is encrypted..." when trying to read the encryted table.
Stop Maria
Restore the backup
Restart Maria
I have a general question to sqlcipher.. where is the advantage of sqlcipher against directly encrypting the database with GnuPG or openssl?
Everytime when I want to encrypt/decrypt with sqlcipher I must open the database, attach a new database, encrypt/decrypt it, export it in the new database and deattach it. For example like this:
echo "PRAGMA key='$1';select count(*) from sqlite_master;ATTACH DATABASE '$2/mydb-decrypt.db' AS plaintext KEY '';SELECT sqlcipher_export('plaintext');DETACH DATABASE plaintext;" | sqlcipher $2/mydb.db
This is pretty bloated isn't it?
With openssl or gnupg I can just decrypt/encrypt it directly with one command..
so why using sqlcipher?
The conflict you are seeing is likely in how you are using it versus how it is more commonly used. SQLCipher decrypts and encrypts data on the fly for user access. That is to say that once you have provided SQLCipher with the key material, only the pages of data that contain your data are decrypted. This does not require you to decrypt the entire database to plain text and write to disk in order to access your data as you model above. I would recommend you review the additional details on the SQLCipher design here.