Oracle logo

On using Toad against a database

June 7th, 2011 by igogo

I got this question once again today in a previous post.

What’s wrong by using Toad against a database?

The worst case scenario:

– some non-technical staff is clicking around in your production database with read-write access

The best-case scenario :

– nobody has access to your database

Here is a short list on how you could protect your data :

– Give the right privilege to the right person. DBA role to the DBA, CREATE TABLE/CREATE INDEX to the developer, INSERT/UPDATE/DELETE to the application

– Restrict access to your database server. Use some firewall. Allow only the dba workstation and the application server to the Production environment

What if the end-user PC needs access to the Production database with a powerfull user? This often happend in real world. A fat client is installed on the PC, the password is somehow hardcoded, the privileges granted to the hardcoded user are uterly generous…

It is not a bad practice in this case to block access to the database server to Toad/SQLPLUS and thelike. This will very ineffeciently prevent some garage-hacker from corrupting your database, but it will prevent your sales / marketing colleagues from deleting data, locking tables and degrading performance. This could be done by some login triggers or, my preference, some administrative measures like information, auditting and sanctions.

Article source: http://laurentschneider.com/wordpress/2011/06/on-using-toad-against-a-database.html

Leave a Reply