After assessing the server's security, check the database connections, access controls and the table access controls, because any weaknesses will negate the hardening measures performed on the server. Also, any applications that connect to the database should use an encrypted link, even if the database resides in a controlled network, because desktop workstations really have to be considered untrusted given the amount of malware in circulation. If information security policies require data to be encrypted, then the database connection must not allow clear text access to the data. All data, including connection strings, should be encrypted using SSL or SSH, for example, to protect it during transit. Also, encrypted data should not store the encryption key on the database server. Applications and users that connect to the database should only have the minimum privileges required to complete their tasks, and access to system level resources should be controlled with access control lists (ACL). It is also important to check that different database connections are used for users for application administration and normal user activities. Data should only be accessible through stored procedures as they provide another layer of data access control.
As far as protecting your database server from penetration, , there should be a firewall protecting access to it and, if possible, the data supplied by the server should not be live production data. Production databases can be mirrored to separate servers so the Web server can provide access to the data without risk of contaminating production data. If this is not feasible, your firewall and other access controls take on even greater importance, as do mechanisms for rollback and recovery if production data is altered. On the server side, you can use IP Security Protocol (IPSec) policies to provide host restrictions to restrict server-to-server communication.
This was first published in April 2006