Below is a list of some of the questions a
should ask (and answer!) when determining a database security
Such a policy needs to be approved by management (who will often
provide most of the answers).
The policy should also be developed with input from the server's
system administrator(s) as well as the organization's network
The questions that must be addressed by the database security policy are
grouped by related questions.
Note there is some overlap between sections.
The questions are:
User Access to the Database
Every user must connect to the database with an authorized
userid and password.
Will users share one or more userids (it is common with some
vendor's applications all share the same userid)?
How should users be authenticated to the database?
(Typically passwords are used.)
Should passwords expire? After how long?
What password restrictions should be enforced
(e.g., mininum length, not a word, not an old password)?
Is there a limit for the number of concurrent sessions for a
Should some or all users be able to create their own objects?
Should access to DBA (or other privileged) accounts be restricted?
Will the database be accessible remotely (via
Should advanced security techniques be used (e.g, session encryption,
authentication via certificates, operating system authentication,
Will the database be used for distributed queries?
Is using partitions, should access by some users to some
partitions be restricted?
Read Sensitivity of the Data
By default the data in a table (or other schema object) is readable
to the userid that owns that table (or object), and users with the
SELECT ANY TABLE system privilege.
You need to decide who is allowed to access what data.
Should some data be accessible to all valid users of the database?
Should different levels of access be granted to different users?
Should additional access controls be employed (e.g, label
security, encryption, firewall, ...)?
Write Sensitivity of the Data
These questions determine who has access to add, modify, and delete data.
By default tables can be modified by the userid that owns the table, and
any user granted the appropriate privileges
(INSERT ANY TABLE, UPDATE ANY TABLE, and
DELETE ANY TABLE)
Will some tables be updatable, appendable-only (e.g., logs),
Will audit trails be required for some data?
(If so that rows should never be deleted or updated, only
marked as logically deleted or replaced, with a timestamp.)
Where (what tablespaces, schemas) will users be permitted to save data?
How much disk space will a user be allowed to used per tablespace?
These questions determine how much accountability you need.
Auditing will allow you to determine who has accessed which data,
when, and how (read, insert, update, delete).
For each set of data the DBA must decide:
Do we need to know who has selected from, inserted into, updated,
or deleted data?
Do you need to know the exact time of every access (or is knowing
the time of their session good enough)?
Do you need to know the specifice row and columns accessed, or
just the table?
Will privileges be granted to users or are they to be
grouped using roles?
Should user sessions have a time out?
If so, how long? Is there a time limit per session
or to sessions time-out after so many minutes of idel time?
Should sessions have a limit on the amount of
I/O they provide?
Should a limit be placed per session, per
What files (outside of the database) should be accessible by
users using PL/SQL?
How much memory
(RAM from the
can a user use per session?