Authorisations and encryption/decryption within a database system establish the basic guidelines in protecting your database by guarding against malicious structural or data changes.
What are authorisations?
Authorisations are the access privileges that mainly control what a user can and cannot do on the database server for one or more databases. So consider this to be like granting a key to unlock specific doors. Think of this as more like your five star hotel smart card. It allows you access all facilities that are meant for you, but doesn’t let you open every door. Whereas, privileged staff have master keys which let them open any door.
Similarly, in the database world, granting permissions secures the system by allowing specific actions by specific users or user groups, yet it allows database administrator to perform whatever action(s) on the database he/she wishes. PostgreSQL provides user management where you can can create users, and grant and revoke their privileges.
Encryption
Encryption, decryption can protect your data, obfuscate schema structure and help hide code from prying eyes. Encryption/decryption hides the valuable information and ensures that there are no mischievous changes in the code or data that may be considered harmful. In almost all cases, data encryption and decryption happens on the database server. This is more like hiding your stuff somewhere in your room so that nobody can see it, but also making your stuff difficult to access.
PostgreSQL also provides encryption using pgcrypto (PostgreSQL extension). There are some cases where you don’t want to hide the data, but don’t want people to update it either. You can revoke the privileges to modify the data.
Data modifications
But what if an admin user modifies the data? How you can identify that data is changed? If somebody changes the data and you don’t know about, then it is more dangerous than you losing your data, as you are relying on data which may no longer be valid.
Logs in database systems allow us to track back changes and “potentially” identify what was changed—unless, those logs are removed by the administrator.
So consider if you can leave your stuff openly in your room and in case of any changes, you can identify that something was tampered with. In database terms, that translates to data without encryption, but with your very own signature. One option is to add a column to your database table which keeps a checksum for the data that is generated on the client side using the user’s own private key. Any changes in the data would mean that checksum doesn’t match anymore, and hence, one can easily identify if the data has changed. The data signing happens on the client-side, thereby ensuring that only users with the required private key can insert the data and anyone with a public key can validate.
Public/Private Keys
Asymmetric cryptographic system uses pairs of keys; public keys and private keys. Private keys are known only to the owner(s). It is used for signing or decrypting data. Public keys are shared with other stakeholders who may use it to encrypt messages or validate messages signed by the owner.
Generate Private / Public Key
Private Key
$ openssl genrsa -aes128 -passout pass:password -out key.private.pem Generating RSA private key, 2048 bit long modulus
Public Key
$ openssl rsa -in key.private.pem -passin pass:password -pubout -out key.public.pem writing RSA key
Signing Data
Create a sample table tbl_marks and insert a sample row in that. We’ll need to add additional columns for signature verification. This will understandably increase the table size as we are adding additional columns.
postgres=# CREATE TABLE tbl_marks (id INTEGER, name TEXT, marks INTEGER, hash TEXT);
Let’s add a row that we’d like to validate.
postgres=# INSERT INTO tbl_marks VALUES(1, 'Alice', 80);
We will select the data to store the value into into query buffer using
\gset
command (https://www.postgresql.org/docs/current/static/app-psql.html). The complete row will be saved into “row” psql variable.
postgres=# SELECT row(id,name,marks) FROM tbl_marks WHERE id = 1; row --------------- (1,Alice,80) (1 row) postgres=# \gset postgres=# SELECT :'row' as row; row --------------- (1,Alice,80) (1 row)
Now let’s generate signature for the data stored in “row” variable.
postgres=# \set sign_command `echo :'row' | openssl dgst -sha256 -sign key.private.pem | openssl base64 | tr -d '\n' | tr -d '\r'` Enter pass phrase for key.private.pem:
The signed hash is stored into the “sign_command” psql variable. Let’s now add this to the data row in tbl_marks table.
postgres=# UPDATE tbl_marks SET hash = :'sign_command' WHERE id = 1; UPDATE 1
Validating Data
So our data row now contains data with a valid signature. Let’s try to validate to it. We are going to select our data in “row” psql variable and the signature hash in “hash” psql variable.
postgres=# SELECT row(id,name,marks), hash FROM tbl_marks; Row hash ---------------+----------------------------------------------- (1,Alice,80) | U23g3RwaZmbeZpYPmwezP5xvbIs8ILupW7jtrat8ixA ... (1 row) postgres=# \gset
Let’s now validate the data using a public key.
postgres=# \set verify_command `echo :'hash' | awk '{gsub(/.{65}/,"&\n")}1' | openssl base64 -d -out v && echo :'row' | openssl dgst -sha256 -verify key.public.pem -signature v`
postgres=# select :'verify_command' as verify;
verify
-------------
Verified OK
(1 row)
Perfect! The data is validated and all this happened on the client side. Imagine somebody doesn’t like that Alice got 80 marks, and they decide to reduce Alice’s marks to 30. Nobody knows if the teacher had given Alice 80 or 30 unless somebody goes and checks the database logs. We’ll give Alice 30 marks now.
postgres=# UPDATE tbl_marks SET marks = 30; UPDATE 1
The school admin now decides to check that all data is correct before giving out the final results. The school admin has the teacher’s public key and tries to validate the data.
postgres=# SELECT row(id,name,marks), hash FROM tbl_marks; row | hash --------------+-------------------------------------------------- (1,Alice,30) | yO20vyPRPR+HgW9D2nMSQstRgyGmCxyS9bVVrJ8tC7nh18iYc... (1 row) postgres=# \gset
postgres=# \set verify_command `echo :'hash' | awk '{gsub(/.{65}/,"&\n")}1' | openssl base64 -d -out v && echo :'row' | openssl dgst -sha256 -verify key.public.pem -signature v`
postgres=# SELECT :'verify_command' AS verify;
verify
----------------------
Verification Failure
As expected, the validation fails. Nobody other than the teacher had the private key to sign that data, and any tampering is easily identifiable.
This might not be the most efficient way of securing a dataset, but it is definitely an option if you want to keep the data unencrypted, and yet easily detect any unauthorised changes. All the load is shifted on to the client side for signing and verification thereby reducing load on the server. It allows only users with private keys to update the data, and anybody with the associated public key to validate it.
The example used psql as a client application for signing but you can do this on any client which can call the required openssl functions or directly used openssl binaries for signing and verification.
To use Percona XtraBackup with keyring_vault plugin enabled you need to take some special measures to secure a working backup. This post addresses how to backup Percona Server for MySQL with keyring_vault plugin enabled. We also run through the steps needed to restore the backup from the master to a slave.