What aspects should be considered in order to have a secure database?
Along with avoiding
sqlInjection, what else should be considered? What should not be done?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
Shut it down and wipe the disks....several times. Slightly less extreme is
Firstly secure the server, storage, network and OS level
Next you want to lock down user database access
Don't forget DR. While I was joking about wiping the disks, if your risk assessment is that someone would do very well putting you out of business for a few days (or permanently), burning down your data center is a security matter.
Here is a checklist for SQL Server security which seems focused on the configuration of the SQL server itself: http://www.sqlsecurity.com/FAQs/SQLSecurityChecklist/tabid/57/Default.aspx
Additionally (if you are unable to rely on the windows only security model) you would also want to go through the required excercise of encrypting connection strings.
A pretty open question.
A good start is to read some of the basics, Wikipedia has a nice article on it. Then you have to look into the details of your specific system. Nearly all database engines provide a heap of information how to specifically secure their systems. And don't forget to look over the horizon: not only has the database be "secured", also the system it runs on.
SQL Injection is a common, but one of many security concerns to be taken into notice.
In Oracle, a frequent design choice I see being made is that the application always logs in as a single database user/schema - the owner of all the objects for that application.
A better design is to have one user/schema that owns the objects for the application, then
REVOKE CREATE SESSION from that user. Then, create another user/schema which will own no objects (except perhaps for synonyms) that will be used by the application to log into the database. Then, issue the minimum necessary grants (SELECT, INSERT, UPDATE, DELETE, EXECUTE, etc) to the application user.
That way, you know that even if a bug in the application might allow a user to do something that they shouldn't (e.g. delete records from a table), your database privileges will ensure that it won't happen.
Otherwise, if the application logs in as the owner, it is not possible to
REVOKE any privileges on any of the objects.