There are usually many security layers above that of the database, from a security standpoint, one cannot rely on any other layers or ignore others. This is true no matter where in the tech stack one’s core responsibility is located. When it comes to protecting sensitive data there are no shortcuts or any single catchall solutions.
A successful approach to securing data relies on a multifaceted and cross functional team approach at each layer of a solution, especially in the technological world today where data and identity theft are common news bytes. A single data breach can ruin a company in a moment.
There are a couple of really good industry standards that can be used as a very solid base to gravitate to in the analytical evaluation of a solution. Two primary starting points are SSAE 16 and PCI DSS. My personal opinion is that one should never stop in the endeavor in securing their systems or data by simply passing an audit.
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.
In my book, Migrating to MariaDB, I go into greater 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 book’s title that the database technology of topic is MariaDB and it’s evaluation from a security standpoint as a replacement for Oracle.
Audits are 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 or if there is something we can do better.
I prefer to look at it in terms of the second bullet point mentioned. An audit should not be looked at as an adversarial interaction. 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?
For many years the go-to solution for data encryption at rest has been Oracle’s ASO solution, which is only available with their Enterprise Edition of their DBMS and 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 cost. 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 to survive.
Other Open Source databases have 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. 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 the market. For years that market has been dominated by high cost proprietary closed systems. MariaDB 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 a bit arduous and can be accomplished, however reportedly the AWS plugin handles this well. MariaDB is currently working on improving their solution.
The Maxscale solution also adds some benefit by not only being a proxy for connection routing and failover, but from a security standpoint can also handle data masking, query filtering, and etc.
If you haven’t checked out the MariaDB product offerings, you should.