Manage Learn to apply best practices and optimize your operations.

How to keep your data and database secure

In this Ask the Expert Q&A, Michael Cobb discusses why having a Web-based application that resides on the same server as the database can be problematic, and, what you can do to keep your data safe.

We have a Web-based application that resides on the same server as the database. Could this be problematic?

Yes. The only time this may be acceptable is if the database contains non-personally identifiable data and is of trivial nature, such as a database of sports clubs for example. Because your Web server is accessible from the Internet, potential attackers are constantly trying to work there way in. For this reason, data that has value should be placed on its own server. If the two remain on the same server and a hacker successfully launches an attack, they would have immediate access to your database and its contents. Placing your database on a separate server, preferably shielded from the Web server by a router or firewall, makes it harder for an attacker to reach the database by providing defense-in-depth.

To provide the appropriate amount of protection for your data, you'll need to address the following issues:

  • Database server security
  • Database connections and access
  • Database table access control

Data server security means ensuring that the server itself is hardened and actual access to it is limited. If your database server supplies information to a Web server, it should be limited to only answering information requests from the known IP address of the Web server -- there shouldn't be an anonymous connection. On a Windows-based system, you should use IP Security Protocol (IPSec) policies to restrict server-to-server communication. If users are going to make updates to the database via a Web page, you should authenticate users before they connect to your database via the Web server. Execution privileges on procedures should be tightly coupled to users, so they only gain database access within the scope of the procedure. To prevent attacks, such as SQL injection, you should also run sanity checks and filter all input data received via the Web.

Access to system-level resources such as files, folders, registry keys, etc. also needs to be restricted. This applies to both Web and database servers. IIS Web permissions apply to all resources requested over HTTP regardless of the user. However, they do not provide protection if an attacker manages to log on to the server, so you'll need to use NTFS permissions, which allow you to specify per user access control lists. You can use Windows Access Control Lists (ACLs) to restrict which users can access what resources and the types of operations they can perform. Pay particular attention to anonymous Internet user accounts; lock these down with ACLs on resources that explicitly deny access to anonymous users.

In addition to ACLs, you can use table access control to limit who can read, change and add data to specific tables. This is an often-underutilized form of database security. For example, if a table is only used for system reference, it should have read permission only. Finally, even if you do move your database onto a separate server, don't store highly sensitive data, such as customer credit card numbers, as the risk is too high. If you're using a payment gateway provider for credit card processing, there's no real need to store the card numbers.

This was last published in November 2005

Dig Deeper on Database security