|
When reviewing database security, it's crucial to concentrate on two areas: how well the system has been hardened, and how the data and database access is controlled. Most hackers target the data held in a database, therefore the server, where the database resides, needs to be hardened and protected, both physically and logically. Ideally, the database will be on its own dedicated machine, but should never reside on a public-facing server, such as a Web server. Naturally, all system and database program patches should be installed, and unnecessary features should be removed or disabled. Most database programs have several default accounts and passwords, all of which need to be changed. One of the best ways to determine how well these hardening procedures have been implemented is to run the appropriate Center for Internet Security (CIS) Benchmarks and Scoring Tools against both the server OS and the database. The Benchmarks are best practice standards for security configurations that help to determine how your systems measure up. These Benchmarks and Scoring Tools are available for most OSes, Oracle and Microsoft's SQL Server databases and can be downloaded for free at http://www.cisecurity.org/bench.html. The Benchmarks are accepted by U.S. government agencies for FISMA compliance, and by auditors for compliance with the ISO 17799 standard, GLB, SOX, HIPAA,FIRPA and other regulatory requirements for information security.
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.
|
