Probably the most overlooked aspect of database design is security, when it should be a major consideration. By not securing your database and thereby your data, you are asking for trouble.
Not all data is intended for everyone’s eyes, and not everyone should have the ability to manipulate your data and definitely not your database’s structure. The majority of your database users will only need and should only be granted read (or select) access.
When designing your database, you should establish a list of policies and users for your database.
A database user is anyone who needs access to any part of your database. The highest level of user is the database administrator who will have access to all database objects and data.
Other users will only have access to certain objects and data. The average end user will only
have access to certain objects, but should never have the ability to alter your database structure.
It never ceases to amaze us how many organizations have one “global” user that has complete control of the database. This is typically a bad scenario, not because people are intentionally malicious, but because they are people and no one is perfect.
The impact of a simple mistake can take hours and even days to reverse, if reversal is possible at all.
Policies are basically rules that define which actions a user can perform on your database.
Most RDMSs enable you to assign a separate set of policies, or rights, for each object in your database. User rights generally fall into one of six different categories:
SELECT enables the user to view data.
INSERT enables the user to create new data.
UPDATE enables the user to modify existing data.
DELETE enables the user to delete data.
EXECUTE enables the user to execute a stored procedure.
ALTER enables the user to alter database structure.
Each user in a database should have a unique user name and password combination. This will enable your RDMS to enforce the security policies you have established for the user.
28
RELATED POST
NORMALIZATION IN DOT NET DATA BASE
ASP.NET SECURITY ASPECTS
No comments:
Post a Comment