There are many security layers above that of the database, from a security standpoint, however one cannot rely on the other layers alone when it comes to protecting sensitive data. In my book, Migrating to MariaDB, I go into detail on this, specifically in regards to evaluating a potential database solution for deployment in a secure environment with sensitive data. Of course one can gather from the title that the database technology of topic is MariaDB and it’s evaluation from a security, auditing, and potential as a replacement for Oracle.

There are a couple of really good industry standards that can be used as a very solid base to gravitate to and those are SSAE 16 and of course PCI DSS. My personal opinion is that one should never stop in the endeavor in securing their systems or data. In this day and age where data and identity theft seem to be regular news bytes, data breaches can ruin a company in a moment.

SSAE 16 primarily deals with physical location and data access control standards of which the majority of are handled above the database administrator level, however as a Database Admin one must remain fully aware of those standards and how they relate to their systems and that a viable DBMS solution must support.

PCI DSS, which is the Payment Card Industry Data Security Standard, has a much broader impact on the selection of a potential DBMS and on the day to day operations on a database team. A primary focus of the standard is the encryption of data, both at rest and in transit, both to and from the DBMS, and the ability to rotate encryption keys within standard time periods.

My personal viewpoint is that one should consider audits a starting point and not a stopping point. The benefits of having an accredited compliance auditor evaluate your facility, systems, and processes is worth every penny. There are essentially two ways one can look at the process of going through an audit:

• Why am I here dealing with all this useless, redundant, and silly stuff. Is it over yet?
• This is an excellent exercise to validate our systems and security controls in order to find out if we missed anything.

I prefer to look at it in terms of the last bullet point mentioned. These folks are here to help. They know the compliance standards inside and out, so learn everything you can from them in order to protect your data, your customers data, and ultimately your business. Sure, they are asking questions and trying to poke holes in one’s day to day processes, but isn’t it much better for them to find a potential problem than the alternative? Again, an audit definitely should not be treated as an adversarial interaction.

For many years the go to solution for data encryption at rest has been Oracle’s ASO, which is only available with their Enterprise Edition of their DBMS. It works. Combine that with Real Application Clusters and you have a high speed secure solution with excellent fail-over capabilities, but it comes at a steep price. This price is not one meant for smaller companies with limited budgets or startups where the first few years are crucial when fighting for every penny of revenue.

Other Open Source databases had offered an attempt at encrypting data at rest, but it always meant heavy code side alterations using encryption calls both when inserting data into a column as well as selecting it. This was never a viable option for optimum code efficiency and reuse. Then in 2015 MariaDB announced that their latest version of 10.1 supported encryption at rest at the table level. Since then other Open Source Database Management Systems(OSDBMS) have followed suit.

I like to keep things simple and there is great benefit to being able to encrypt an entire table or table space. If there is one item that is PII/PCI scoped in a table definition then complexity can be minimized by encrypting it in its entirety. The performance impact is negligible in comparison to the time sink involved with keeping track of specific column level encryption, as well my experience has been that if there is a table that has one datum that should be encrypted there are generally more or there will be in future iterations of that table.

MariaDB has produced a perfectly viable alternative to a market that for years has been dominated by high cost proprietary closed systems. It is cost effective, but most importantly it satisfies auditing requirements via its encryption capabilities for anyone dealing with secure data. Data can be encrypted at rest within the database and in transit via network communications over SSL. Encryption key rotation is also built in along with many other beneficial capabilities, especially when leveraging the Maxscale solution in combination with Mariadb and Galera Clustering.

If you haven’t checked out the MariaDB product offerings, you should.