Determining a Database Security Policy

Below is a list of some of the questions a DBA should ask (and answer!) when determining a database security policy.  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 administrator.

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 given user?
• 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 SQL*Net)?
• Should advanced security techniques be used (e.g, session encryption, authentication via certificates, operating system authentication, firewalls, etc.)?
• 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), or read-only?
• 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?

Audit Policy

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?

Other Questions

• 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 SQL statement, or both?
• What files (outside of the database) should be accessible by users using PL/SQL?
• How much memory (RAM from the SGA) can a user use per session?