Re^2: DBD::mysql to MariaDB with at rest encryption

DBD::mysql connects to MariaDB perfectly, I don't need an SSL connection (got that already). We want the data in the database encrypted. Which creates all kinds of issues when trying to retrieve data, run sorts and selects if you have to do it on a field by field basis. The mariaDB 10.1 release has the feature of encrypted at rest. So if someone got the actual DB file, it would be encrypted, but with the right key solution, the data becomes unencrypted and you can do all the normal DB things you want to do without dealing with encrypted fields.

The easiest comparison is that of a password protected zip file, without the password, the zip is useless with the password, internally you have files/folder structure just like an OS.

MariaDB was created as a true open source option to mysql now that Oracle has acquired the rights to mysql. It is much faster and is starting to get more of these very nice to have features, but all the mysql GUI and utilities still work with it.

Comment on Re^2: DBD::mysql to MariaDB with at rest encryption

Replies are listed 'Best First'.
Re^3: DBD::mysql to MariaDB with at rest encryption by Marshall (Canon) on Mar 24, 2016 at 15:27 UTC
The Mariadb page that talks about this is: https://mariadb.com/kb/en/mariadb/data-at-rest-encryption/. Looks to me like there are set of encryption files that are read at startup by some kind of utility that comes with Maria. Perl wouldn't have a role in that part. If you configure the DB to encrypt all files, looks like the DBI wouldn't know or care about that. However the default is to decide encryption on a table by table basis with some additional parms to CREATE TABLE or ALTER. Something like: `CREATE TABLE T (id int, value varchar(255)) ENCRYPTED=YES ENCRYPTION_KEY_ID=17;`. Whether or not these extra SQL parms work with the current DBI, I don't know. Sorry that I can't help further. It was an interesting question and I learned a bit of new stuff. update: Oh, you need MariaDB 10.1.4. Looks like once tables are created, this is pretty much transparent to the user except for a 3-5% performance hit, which is less than I would have thought. you write "My limited understanding is that you provide certain credentials (keyfile) at login", it appears that the key file is read by the DB when it starts, not supplied dynamically on a per login or connection basis. This at rest encryption just ensures that as long as you keep the keyfile and dbfile separate (presumably on different HD's or computers), even having the dbfile gets you nowhere. There is no protection from SQL injection attacks or unauthorized users. This protects against somebody who has access to the file system and could make a copy of the dbfile.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: DBD::mysql to MariaDB with at rest encryption
by Marshall (Canon) on Mar 24, 2016 at 15:27 UTC

https://mariadb.com/kb/en/mariadb/data-at-rest-encryption/

Looks to me like there are set of encryption files that are read at startup by some kind of utility that comes with Maria. Perl wouldn't have a role in that part. If you configure the DB to encrypt all files, looks like the DBI wouldn't know or care about that. However the default is to decide encryption on a table by table basis with some additional parms to CREATE TABLE or ALTER. Something like: CREATE TABLE T (id int, value varchar(255)) ENCRYPTED=YES ENCRYPTION_KEY_ID=17;. Whether or not these extra SQL parms work with the current DBI, I don't know. Sorry that I can't help further. It was an interesting question and I learned a bit of new stuff.

update: Oh, you need MariaDB 10.1.4. Looks like once tables are created, this is pretty much transparent to the user except for a 3-5% performance hit, which is less than I would have thought. you write "My limited understanding is that you provide certain credentials (keyfile) at login", it appears that the key file is read by the DB when it starts, not supplied dynamically on a per login or connection basis. This at rest encryption just ensures that as long as you keep the keyfile and dbfile separate (presumably on different HD's or computers), even having the dbfile gets you nowhere. There is no protection from SQL injection attacks or unauthorized users. This protects against somebody who has access to the file system and could make a copy of the dbfile.

[reply]
[d/l]