Server security = Perhaps the most important of all security practices -- the process of limiting access to the database server itself. Only trusted IP addresses should be allowed to view the database (following the logic of "you can't mess up what you can't see" principle).

In addition of limiting database access to a few trusted IP addresses, there must be some check on the user's identity as well. So, create individual user accounts. While the sharing of accounts is possible, it is important for each user to maintain his/her own account. This way, unauthorized use can be easily traced to the culprit and proper disciplinary action taken. Each user will need to present a valid username and password to the system, and have the correct access rights/privileges to be able to access the database itself.

Sometimes password controls and privileges are seen as secondary and unimportant. This has leads to features normally expected from a secure operating system, password expiry, minimum length passwords, password re-use controls etc. being absent. But in a world of computer hackers and privileged information, you can never be too careful.

 

Take me back to the main page!!

 

Database Connections = Only system administrators should be allowed to modify or update a database. Delegating this responsibility to unqualified people may result in unwarranted and/or unsafe modifications. This is one of the easiest things to prevent -- so, don't get all lazy and allow unauthorized updates to pollute your database.

 

Take me back to the main page!!

 

Table Access Control = Keep the permissions as tight as possible. You can do this by using restricted views to tables thereby restricting the information a user is presented with. Without this a user will still be able to modify data in field even if they cannot view the said field.

Add permissions through this statement:

GRANT <permissions>
[ON <table>]
TO <user/role>
[WITH GRANT OPTION]

For example, company Foozle has just hired Mary. As a new employee she is given access to the database. She should be allowed to modify the Customers table -- but no other! We would accomplish this through the following command:

GRANT SELECT, INSERT, UPDATE, DELETE
ON Customers
TO DataEntry

 

Uh-oh! You have given Mary too many privileges. She should not be allowed to delete customers from the database. But you are using SQL, and it is easy to modify permissions.

You can remove permissions in a similar manner:

REVOKE [GRANT OPTION FOR] <permissions>
ON <table>
FROM <user/role>

For our purposes, the command would be:

REVOKE DELETE
ON Customers
FROM Mary

Now, suppose Mary is fired from the company (she embezzled funds and was an all-around bad person). In the interest of security, you must bar her from the database.

The syntax to do this is:

DENY <permissions>
ON <table>
TO <user/role>

And, being the wise SQL programmer that you are, the entry would look like this:

DENY DELETE, SELECT, INSERT, UPDATE
ON Customers
TO Mary

 

Take me back to the main page!!

 

Restricting Database Access = All these security measures result in one thing -- baring unauthorized users from the database. A combination of server, database, and table security is needed. Do things like allowing only trusted IP addresses access to the database, baring a user after three failed password attempts, or use special tools to send an alert when there is an attempt at a security breach. These restrictions work together to help secure your database. Rejoice, Oracle already has many programs that do just that. A few of these authentication tools are:

 

Take me back to the main page!!