What are the security advantages of installing the database of a web application on a server other than the one containing the web server?
Well the first obvious advantage is that if someone breaks the box that houses your application server, they are not guaranteed access to the same server that houses the database. Also, by separating this functionality you make it easier on the IT (software devs, admins, etc) to minimize code change impact / policy updates on different aspects of the environment. This does not in any way fix poor coding or weak security (SQL injection, default username/passwords). but it does facilitate a better security posture overall.
An internet facing web server has zero reason to have any access to the LAN/domain at all, and thus it should be completely forbidden from doing so. Ideally, it should be on a DMZ.
- This gives significant protections against an attacker who has 'owned' the internet facing web server attacking the rest of your network.
- You can have as many of these as you need, of course, for HA (high availability), DR (disaster recovery), and performance reasons.
- Medium: with strict rules for the WAN/DMZ boundary and complete prohibition of "To LAN" DMZ/LAN traffic, and strict rules for "To DMZ" DMZ/LAN traffic, or similar.
- Advanced: an "outer" DMZ with strict rules for both the WAN/OuterDMZ and OuterDMZ/InnerDMZ boundaries, or similar.
An internal facing web services host probably needs limited access to the LAN/domain (primarily to your database(s)
- If it's not using domain type authentication to the database, it still doesn't need to be on the domain
- You can have as many of these as you need, of course, for HA (high availability), DR (disaster recovery), and performance reasons. If you use really good password hashing (PBKDF2, bcrypt, scrypt) with high iteration counts, you'll need more processing and/or RAM here.
- While this is a better platform to attack your LAN with than the internet facing web server (unless they're the same box, or worse, the same site), it should still have very limited access - to the database box over a database port only, the ability to pull antivirus updates and push antivirus warnings, etc.
- Basic: This is the same OS instance that hosts the internet facing web server, or similar.
- Medium: This is also on the DMZ with complete protection of inbound traffic from the WAM, and strict rules for both the outbound to WAN WAN/DMZ boundary, and strict rules for the DMZ/LAN boundaries, or similar.
- Advanced: This is on an "inner" DMZ with strict rules for both the OuterDMZ/InnerDMZ and InnerDMZ/LAN boundaries, or similar.
A database server is likely to be on your LAN, making it a much more valuable target for an attacker; it probably needs to be backed up, needs to be accessed by a variety of programs in addition to the web, and so on and so forth.
- As always, SQL Injection lances straight from the Internet to your database; parameterize your SQL!
- Having multiple well-defined, minimum permission layers between this and other servers on your LAN and the Internet, with good design and implementation, helps increase the amount of effort it takes to attack the database server, much less succeed at the attack.
Internet ->Web site + services + DB means with one compromise of the OS, the attacker can control everything, including exfiltrating or destroying all your data in the database (or backups) directly - no need to go through the Web interface to do that.
Internet ->Web site + services ->DB means the attacker needs to compromise your database through the keyhole of your Web services, or needs to compromise more than one machine which have only some shared security holes.
Internet ->Web site -> Web services -> DB is better still - the attacker needs to compromise your database through the keyhole of your Web services as seen through the keyhole of your web site, or needs to compromise more than one (or two!) machine(s) which have some but not all shared security holes.
It goes without saying that at every level you should be as secure as you're allowed to be - up to date patches and antivirus, parameterized SQL to prevent SQL injection, whitelisting entries, long cryptographically random passwords, encrypted data, encrypted connections, strongly hashed passwords (PBKDF2, bcrypt, scrypt), good algorithm choices for encryption and hashing, only the minimum ports open between each layer, checking logs for traces of attacks, IDS/IPS software/applicances, and so on and so forth.
It does take either some planning or some playing (or both) set up.
Well, by separating the web server from the database server, if a user can exploit the web application and elevate their own privileges they can mess with your data, but only as much as the security model on the database server will let them. For instance, while they can read and write customer data - if they can reverse engineer how the web app does it - they can't bulk download the entire database, or delete it completely, or corrupt/compromise/otherwise degrade it by rewriting its schema. Moreover, new generation application-specific firewalls and IDS systems designed to protect your database server can detect and block unusual access based on known attack signatures and heuristics, protecting your data from compromised client access.
This comes in reeeeeal handy if the database server feeds a number of web servers.