The new MySQL 5.7.6 developer milestone 16 features noteworthy security upgrades, but others propose more radical approaches to database security. One method puts applications in charge of testing and reporting on their own security, while another separates the app from all security responsibility by placing each in its own virtual machine.
When a database release claims to improve performance over its predecessors by a factor of two to three times, you take notice. That’s what Kay Ewbank claims in a March 12, 2015, post on the iProgrammer site about MySQL 5.7.6 developer milestone 16. The new version was released on March 9, 2015, and is available for download (its source code can be downloaded from GitHub).
In a March 10, 2015, post on the MySQL Server blog, Geir Hoydalsvik lists milestone 16’s many new features and fixes. (Prepare to give your mouse scroll wheel a workout: the list is long.) Ewbank points in particular to the InnoDB data engine’s CREATE TABLESPACE syntax for creating general tablespaces in which you can choose your own mapping between tables and tablespaces. This allows you to group all the tables of one customer in a single tablespace, for example.
(Note Hoydalsvik’s warning that the milestone release is “for use at your own risk” and may require data format changes or a complete data dump.)
One of the update’s security enhancements relates to the way the server checks the validity of the secure_file_priv system variable, which is intended to limit the effects of data import and export operations. In the new release, secure_file_priv can be set to null to disable all data imports and exports. Also, the default value now depends on the INSTALL_LAYOUT CMake option.
Apps that continuously test and report on their own security
Data security generally entails scanning applications to spot problems and missing patches. In a March 5, 2015, article on InformationWeek’s Dark Reading site, Jeff Williams proposes building security into the application via “instrumentation,” which entails continuous testing and reporting by the app of its own security status.
Instrumentation collects security information from the apps without requiring scans because the programs test their own security and report the results back to the server. Williams provides the example of reports identifying all non-parameterized queries in an organization based on a common SQL injection defense: requiring that all queries be parameterized.
The opposite extreme: Separating security from the application
Another novel approach to database security is exemplified in Waratek AppSecurity for Java, which is reviewed by SC Magazine’s Peter Stephenson in a March 2, 2015, article. The premise is that security is too important to be left to the application’s developers. Instead, create a sandbox for Java, similar to a firewall but without the tendency to report false positives.
Waratek’s product assigns each app the equivalent of its own virtual container, complete with a hypervisor. The container holds its own security rules, which frees developers to focus solely on their applications. Stephenson offers the example of a container that defends against a SQL injection attack on a MySQL database.
Application security is at the core of the new Morpheus Virtual Appliance. With the Morpheus database-as-a-service (DBaaS) you can provision, deploy, and monitor heterogeneous MySQL, MongoDB, Redis, and ElasticSearch databases from a single point-and-click console. Morpheus lets you work with your SQL, NoSQL, and in-memory databases across public, private, and hybrid clouds in just minutes. Each database instance you create includes a free full replica set for built-in fault tolerance and fail over.
In addition, the service allows you to migrate existing databases from a private cloud to the public cloud, or from public to private. A new instance of the same database type is created in the other cloud, and real-time replication keeps the two databases in sync. Visit the Morpheus site to create a free account.