Security must take a high priority in this environment of hackers and crackers breaking into systems, planting worms and viruses, and generally causing mayhem just because they have no moral fiber and probably flunked kindergarten (you know, that part about playing well with others). It is a good practice to implement security-related patches as soon as possible. You should also frequently audit security implementations, including:
- Audit password, connectivity and the use of third party-tools for access.
- Automate auditing whenever possible.
- Maintain audit logs that track when auditing was done, findings and corrective actions.
Minimal privilege grants should be used within your applications. This means that users should be granted those database privileges and object grants required to do their job and no more. It is also considered a good practice to utilize Oracle Roles to group privileges, grants and other roles. Roles allow grouping of application privileges into job-related groups, then as a person is assigned a specific task or tasks the roles associated with that set of tasks is granted to them, no more and no less.
At the database level, encrypt important data within the database. I recently purchased some used fibre channel disks that were supposedly wiped clean of data -- yet several were still formatted and contained data. Besides external threats, encryption of key data prevents internal snooping.
It is also a good practice to implement password aging, expiry and degree-of-difficulty checking. Oracle has provided the Profile capability for this purpose, so use it. As part of this password verification, a table of commonly used (and therefore prohibited) passwords should be maintained and added to frequently. In addition, use profiles to verify that users are not using the same password over and over again. You should also implement the Profile options that lock out users that attempt to guess passwords and generate alerts when this happens.
It is a good practice from the security point of view to ensure Oracle Net is kept up to latest patch levels; no software is perfect, so by keeping software up-to-date the latest security issues are dealt with.
Even though Oracle provides these, it is considered a good practice to restrict the use of the DBA, RESOURCE and CONNECT roles, and develop application specific roles instead. The reasons for not using these Oracle-supplied roles are several-fold:
- DBA opens the database to virtually unrestricted access. Grant this only to DBAs.
- RESOURCE allows insert of tables into any tablespace. It grants many privileges that are only needed by high-level developers.
- CONNECT allows users to create tables and indexes, most users only to access already created objects.
It is a good practice to audit all third-party applications to prevent use of DBA, RESOURCE and CONNECT roles. Many third-party packages insist they need DBA or RESOURCE for the "application" users -- this usually means they had no real DBA support during development, and granting DBA was the easiest way to get around "all those grants." Send them packing until they can tell you what they really need.
Return to Mike Ault's Oracle "good practices."
About the author
Mike Ault is an Oracle database specialist at Quest Software and a recognized Oracle expert with over 16 years' experience as an Oracle DBA and consultant in a variety of industries and companies. A prolific author, Mike has published over 20 Oracle-related books including Oracle Administration and Management, Oracle DBA OCP ExamCram and Oracle10g Grid and RAC. He is a regular contributor to trade publications including Oracle magazine, and frequently presents at major Oracle conferences such as IOUG.
