Sitting on my much delayed flight back home to Saint Louis, MO contemplating the results from attending the MariaDB conference in regards to the improvements, enhancements, and new technologies covered.

In this case, the results are positive. A lot of very exciting announcements, demos, sessions, and improvements being discussed.

The intrinsic value of a conference, such as MariaDB OpenWorks, to industry, technology workers, and managers is sometimes misunderstood. We were able to get in person time with people in various capacities and areas within the organization to talk about topics that just would not happen otherwise. The knowledge transfer and networking aspect that results from these events is often an overlooked and under appreciated asset.

For us, the benefits we shared with regards to RSA multi-token authentication via Maxscale connections to MariaDB were very important. Currently we allow internal direct connections to the database servers due to this limitation. With RSA logins enforced through Maxscale this will allow us to do a much better job at mitigating the impact caused by someone running crazy join queries as well as using application user accounts to log into the database.

An application user has full read/write access for processing, whereas our internal teams are limited to read only in some regions, most importantly in any that are customer facing. Sometimes instead of coming to the DBA team to make a change for them, they decide to take a short cut and use the application level user and password. This is of course a security violation, but it still happens and has even resulted in severely impacted databases.

The other hope is that encryption capabilities will become a much more important priority for MariaDB. Using the MariaDB built in encryption methods fulfill the bare minimums, except for the capability to easily rotate encryption keys. This is a huge limitation.

It seems that so often security features and encryption get overlooked, however look at the billions of dollars in untapped revenue that a solution like MariaDB could capitalize on. Governments, the financial industry, and military just to name a few all require a high level of encryption and security to function, maintain compliance, and safeguard their data.

That is a magnanimous amount of untapped revenue currently owned by other solutions to not be a priority.

For PCI DSS the mandated key life time is <= 2 years. This means one must be able to rotate keys approximately every 2 years in order to stay compliant. Any rotation mechanism must be well designed and vetted as there is the potential of turning one’s data into useless bytes of gibberish. For many years Oracle recommended against rotating keys if possible due to the risks involved.

I have always mandated full backups prior to a rotation and validating all data afterwards no matter how many improvements Oracle made to this process. It is good practice, one I would highly recommend, and would never change. No matter the vendor.

The other limitation is a viable and scalable HSM solution, possibly Open Source. There is Eperi, however it has a limitation of only providing the service to a maximum of 2 servers per Eperi instance. This is not viable, a licensing headache, and resource allocation nightmare to require 1 Eperi server for every 2 client servers. There are many hardware driven HSM solutions for Oracle and various other solutions, however most are very expensive.

If I had the time outside of work, family, and life it might be a great endeavor to write a software driven HSM solution that works with various solutions. I may have to put a hold on some of my personal projects and just make this happen. The next book in the Migrating to MariaDB series (“Evolution of the Solution”(TM)) may just have to wait, as well as another side project on Bowhunting.

An HSM solution does not have to be an Open Source solution, just one that is cost effective, scalable, and well vetted.