I got a few questions like the ones below that I’d like to address to avoid further confusion.
How exactly secure is ClouSE for MySQL, the first secure database in the cloud? Am I protected against standard application level security attacks or even accidental admin mistakes?
With the help of ClouSE I get instantaneous backup for my database on the highly durable cloud storage. But how would I protect my data in case a malicious attack or an accident did occur?
I’ve got a comment pointing out that data encryption on the storage level doesn’t protect from SQL injections. Of course, data encryption does not protect from SQL injections (as long as there is SQL involved, there will be a risk of a SQL injection). Neither does it protect from the infinite number of attack vectors that can happen at any layer of the application stack: PHP, Apache, MySQL, Linux, application code, application users, etc.
ClouSE is a Storage Engine for MySQL (like InnoDB), and the beauty of this approach is that it seamlessly fits into MySQL ecosystem. Thus most practices, tools and solutions (and problems :-)) that apply to MySQL in general, also apply to MySQL + ClouSE. The application code needs to be written to prevent SQL injections, the firewalls need to be set up to prevent undesirable network connections, MySQL accounts need to be properly secured, Linux accounts need to be properly secured, etc. There is a ton of information on the topic; there are companies that offer training on this topic, etc. So I didn’t feel that I’d need to write an article on that topic.
I wrote an article that focuses on aspects that are specific to ClouSE, with all other things being equal. It goes into threat analysis of the cloud storage part of the solution, covers some implementation details, and arrives at the conclusion that MySQL + ClouSE is currently the only cloud-based database solution (and approach) that provides data confidentiality in the cloud. As such, it’s currently the only fully secure cloud-based database solution (because other cloud-based database solutions currently lack the data confidentiality aspect). In the future, there will likely be solutions that use a similar approach; so in the future, ClouSE won’t be the only fully secure cloud-based database solution, but it will continue be the first (in the order of appearance).
The article is technical, has a lot of unique content and worth reading. I encourage you to read the article and if you find an incorrect statement, please let me know, and I’ll either correct it or explain why it’s correct.
Cloud storage is super-reliable and provides storage durability and availability. For point-in-time recovery, you can still use the standard MySQL ways – they are all still there with ClouSE, that’s the beauty of it. But it’s going to be much better after the Beta. ClouSE is a Beta product and still has not-yet-implemented features. One of the incomplete features is a built-in point-in-time recovery. ClouSE won’t be declared GA (or even RC) until this feature is finished. We are pretty serious about data protection.
With built-in point-in-time recovery, ClouSE will allow the user to go back in time in case of a gross accidental or malicious data mismanagement on MySQL level (up to a configurable data retention period, 24 hours by default). This will provide a reliable, built-in, default way to protect the data all around.
Data protection is going to be provided where it’s meant to be – by the database itself, not by a set of external tools, practices and idioms. With ClouSE, there will not be no “I wish I had a later backup” or “I wish I had a recoverable backup” – it will simply deliver on the promise that is implied by a “database management”, by design, by default. Think about modern mobile and web applications: they don’t have a “backup” concept or even a “save” button – the data is always “saved”. ClouSE is doing the same for the databases. That’s real working functionality, and it’s likely to set the standard of painless data protection and continuity in DBMS.
Got more questions? Feel free to contact us.