Defense in depth and the local server
Yesterday I gave a webinar about Database Security in a Hostile World and I got a really interesting question at the end:
If your RavenDB and app are on the same server, would you recommend using certificates?
The premise of the talk was that you should always run in a secured mode, even if you are running on a supposedly secured network. That is still very much relevant if you are running on a single server.
Consider the following deployment model:
(Icons from https://www.flaticon.com/)
As you can see, both the application and the server are running on the same machine. We can usually assume that there is no possibility for an attacker not running on the same machine to eavesdrop on the communication. Can we skip encryption and authentication in this case?
The answer is no, even for this scenario. That may be a viable model if you are running on your development machine, with nothing really valuable in terms of data, but it isn’t a good model everywhere else.
Why is that? The answer is quite simple, there are two issues that you have to deal with:
- At some future time, the firewall rules will be relaxed (by an admin debugging something, not realizing what they are doing) and the “local” server may be publicly exposed.
- Even if you are listening only to port 127.0.0.1, without authentication, you are exposed to anything that is local that can be tricked to contact you. That is a real attack.
In short, for proper security, assume that even if you are running on the local network, with no outside access, you are still in a hostile environment. The key reason for that is that things change. In two years, as the system grows, you’ll want to split the database & application to separate servers. How certain are you that the person doing this split (assume that you are no longer involved) will do the Right Thing versus the minimum configuration changes needed to make it “work”?
Given that the whole design of RavenDB’s security was to make it easy to do the right thing, we should apply it globally.
Comments
This.
We just upgraded one of our old on-prem databases - version upgrade. The box was also used as an app server, so the apps were moved at the same time to a dedicated box (obviously a mistake to do both at the same time, but that's par for the course).
It was a database that has been there for many years, had tcp/winsock for odbc etc etc. In addition to ftp, smb, and who knows what else, each of which doubtless has its own security weakness.
Peter,
One of the problems with old systems is that they were often developed in another era. If you had a local only network (with little or no internet connectivity), you had a completely different perspective on the security threat model. It used to be the case that you would deploy windows apps to client machines that would connect to the shared database directly, with either no password, hard coded password or windows auth. For files, you had a file share, etc.
You trusted your own environment, basically. Taking the same systems and trying to deploying them on modern systems is ... hard.
Comment preview