Why Databases are Still Getting Hacked

RavenDB Secure by Default NoSQL Database keeps your information safe in transit, at rest, and on the internet

It costs five times more to replace a customer than to retain one. Why should you lose business because the database you bought couldn’t protect your customer’s data?

Starting in 2017, a wave of attacks on MongoDB servers affected most MongoDB databases facing the internet. Since then, there have been multiple data breaches of MongoDB instances exposing hundreds of millions of emails and private information.

Just recently, a hacker was able to wipe out the database of NewsBlur, demanding ransom from the company to restore 250 GB of data that was taken.

Your database provider must protect your good name with the same diligence that it will protect its own. Why should your reputation be damaged because of an unsecured database?

What Puts Your Database at Risk

How does a database vulnerability that began in 2017 continue over four and a half years later?

If the security documentation is over 60 pages, it will be a task and a half to cover it all. If security is easy to set up, you are more likely to get all the bolts fastened super tight.

Safeguards need to be put in place for things that cannot be automated.

When a project first begins, it will start on a developer machine safely installed well inside an organization’s firewall. Not wanting or needing to pour over security documentation and eager to get started coding, database security will not likely be installed.

Once the project is ready to go live and onto the public internet, the step to enable database security can be overlooked, exposing a database to anyone who wants to help themselves to your information.

These are serious problems that put your database at risk.

The Standard for a Secure Database

RavenDB makes sure you don’t have to worry about these issues.

Whether on-prem or using our DbaaS Managed Cloud Service or in a hybrid environment, you can set up and secure a database cluster in minutes.

You get security for data in transit and at rest. We use TLS 1.2, which gives you encrypted data over the wire and allows for mutual authentication at the highest level. It’s also something that you can configure on your own without requiring an administrator to intervene.

You also have X509 Certificates for the primary authentication system so you can automate a lot and still maintain the security properties you need.

RavenDB protocols guarantee you cannot go from a developer machine to the public internet without safeguards. When you leave a developer environment, your database will not let you complete this step until you do one of the following:

1. Install your own security.
2. Use RavenDB’s security.
3. Acknowledge that you are happy with your current security layer and want to continue.

Read-only Certification

A client certificate with a user security clearance can grant different levels of access for different databases. These access levels are Admin, Read/Write, and Read Only.

The Read-Only access level allows you to read data from a database but not write data. You cannot update existing documents, change configurations, or define ongoing tasks or static indexes. The database will continue to create auto-indexes in response to client queries.

Security should be easy to set up, impenetrable, and packed with protocols to keep your information safe in transit, at rest, and on the internet.

Take a live private demo of RavenDB and start protecting your data today!