The wisdom of exposing a database server on the internet?

Question

The leadership of the small company I work for has gotten very excited about SaaS and is pushing our product into a SaaS deployment - I have a concern about this because part of the functionality of the product is based on the users being able to use business intelligence tools to write reports against the application's underlying database.

When I ask about how we plan on providing that functionality in the SaaS model, I am greeted with blank stares and the response is simply that we will expose the database server on the internet and allow people to query the database as if it were running within their corporate network.

This scares the bejeebers out of me, but I don't know if I am just being paranoid, or if there is significant reason to be concerned.

So my question is: is it possible to appropriately harden the security of an Oracle database server so that we wouldn't need to be concerned about the fact that it will sit exposed on the internet? And if so, what resources should I be researching to learn to do this? The database will be storing proprietary information that our clients would not want to expose to the world, and yet a proposal to put this functionality behind a VPN has been squarely rejected.

My searches on hardening an oracle database have pretty much all included statements along the lines of "Never ever poke a hole in your firewall", so it could be that the correct answer here is "Update your resume as fast as possible", but I appreciate whatever advice you can give.

Answer 1

Exposing a database isn't really a giant issue compared to some of the other services that are often exposed to world+dog... except that it's a complicated system with a lot of potential vulnerabilities, including permissions escalation. I would make sure that you don't expose the database to public queries and run with SSL required, etc. I would say it's possible, but yes, you should be paranoid and you should maintain a separate database install for the public facing one. If your company's not willing to pay the licensing costs for that, yeah, skedaddle.

From the customer/support side, connecting directly to the database might be an issue if the customer's ISP blocks certain types of ports or traffic.

In a SaaS model, what you'll generally want your programmers to do is to write an API that can be queried from the application. APIs of this nature typically operate over https and provide data back to the application in the HTTP response. Added bonus: It works from anywhere where the web works, it is VERY easy to cache result sets using memcached or other caching technologies to reduce load on the db server, and http auth is pretty well supported and tested.

Answer 2

I would set up a second database server in the DMZ, and import dumps into that database, and make that database publicity available.

Answer 3

As I'm sure you'll agree, pretty much by definition access and security are a tradeoff. And you're being tasked with making sensitive data accessible.

The short answer is, you can mitigate a lot of the risk with firewall trickery, solid network architecture, updated patch sets, access auditing, and copious backups.

Password management also comes to mind as a tricky thing to accomplish, often application accounts have passwords that never expire, and physical/network access controls are put in place to ensure ex-employees with password knowledge can't gain access to the data. If your database server is exposed to the entire Internet, this seems like something that would be difficult to do.

You will probably also want to define a 'we've been compromised, what do we do now?' strategy, so that you level set expectations for everyone involved and have a plan of action for when your luck runs out.

Answer 4

I would say to use either the API's or web services, with web services preferred since there should be more flexibility in which end users (customers) connect to them.

Part 2, management will say "nuts to that, we need to get market NOW!" and don't want to spend money developing it.

Part 3, you need to convience management why exposing the database directly is bad, and then come up with a whole lot of white papers, security reports, etc. Plus also, if I was thinking about using your software and it is SaaS, I'd want to know all about your security, and as soon as I found out you're exposing the database the deal is off.

Answer 5

SaaS is goods.

Exposing a database Server to the Internet - not so good.

Why do they need it exposed? Is it because of RPC and they don't want to use Static RPC ports?

But there are some great application firewalls and if you lock down the DB's endmapper port and then firewall it - you can do some good stuff with ACLs, IP restrictions, etc.

And you will need to audit event logs, vulnerability scan, etc.

Answer 6

Keep the DB Server safely behind the firewall. If necessary, write web services that live on a public facing website that has a tunnel to the DB server. Make sure the web services have limited access to the DB. If the requirement is that they are doing reporting, then the web services only need read-only access. I'd probably create views of the data I wanted to present, and grant read access to them, not to the underlying tables themselves.

Like Rob said, audit everything, run vulnerability scans, include access logging in the web service apps themselves, so you can see who accessed what and when.

Answer 7

We use several SaaS application in the course of our business and they do this two ways.

1. Provide web-based reporting capabilities
2. Allow the export of the database in a standard format for the customer to write their own reports "offline" (CSV, MDB, etc)
3. Expose the underlying data through web services

Besides security, you have to worry about performance in a multi-tennant system. You do not want one user's poorly written report in Crystal to affect all of the other reporting users.