Mariadb – the point of encryption at rest

I have dealt a lot with PCI and HIPAA recently since we've developed the ApexSQL Audit compliance tool (some details about the tool can be found here), and during a few years of working on the tool and demoing the tool, I was engaged in numerous discussions about the status of DBA in relation to compliance rules. PCI and HIPAA are not developed to deal with "trust" but to eliminate "trust someone" as a category, so PCI DSS is quite strict in that. DBA usually is not the one who is allowed to have access to data related to compliance, and lot of customers are using our tool to place the control of the DBA as well... not because they "don't have a trust" in DBA, but because the specific compliance say/recommend that he shouldn't be trusted. Most of the security breaches are inside jobs, so PCI DSS is there to prevent inside jobs as well

Quite often question was how to prevent DBA to access the data. There are active and passive methods to do that, like segregation of duties between the DBA or attempt to limit the DBA access to some specific tables/views... but so far it seems that passive methods are more efficient. Auditing all user activities and especially activities on objects that stores the sensitive data are the crucial things (including the SELECT)... of course all security related operations (including anything related to keys) must be audited as well as most DDL activities, especially the ones related to triggers and stored procedures must be tracked as they are based on procedural programming language where someone can hide the malicious code that would otherwise be invisible

When somebody want to do something bad, he want to stay unnoticed, and if you establish the auditing of all activities which can be used for some malicious job, and ensure that nothing can go unnoticed, than your passive method in fact became the active method, or better say the pro-active method. If you can be alerted immediately on the desired events, than you can react immediately as well to deal with any security treat and prevent a damage

Just want to state that I'm working for ApexSQL and this is the reason that I mentioned our tool, but there is a bunch of other tools that dealing with compliance and auditing as well

Encryption at rest can't address server breaches, it is only intended to mitigate cases of

• physical data storage theft, and
• data access by unauthorised people, e.g. cloud technicians.

MariaDB encryption wouldn't be able effectively deal with either, because stealing the drives would effectively provide root access to the system, including access to the encryption keys and complete unrestricted access to the database. This is also the case with cloud technicians, who can access backup copies of the system or peer into the filesystem by analysing the underlying datastore. MariaDB encryption can minimise the risk of intrusion, however in order to access the drive or mysql files, the attacker would have to have either root or at least mysql user privileges, and would access not only the files but also the encryption keys in that case.

A good way to ensure encryption at rest is using dm-crypt (or equivalent) to have the OS encrypting the partition where the database files are located, and entering the password manually by an authorised operator at system or RDBMS startup time (i.e. no keys stored in the system at all). This system is not particularly effective against server breaches, but it makes the data completely secure in case of physical storage theft, or access to system backups or underlying datastores.