Book: Expert Oracle Practices. Oracle Database Administration from the Oak Table.

Author: Pete Finnigan. ISBN-13 (pbk): 978-1-4302-2668-0

Chapter: User Security.

This chapter describes how to protect access to database user accounts. Providing security of user accounts should be one
of the first steps taken in securing an Oracle database.

Whether a database is brand new or it already exists, the tasks involved to secure the data are very similar. The database
isn’t just full of schema accounts, there are lots of other types of accounts, including normal business users, reporting
users, batch users, power users, database administrators, feed users, etc. A current problem is that there are still
databases with all types of users having excessive privileges or having weak passwords, in the same way, there are also
user security problems that must be understood and corrected when people share database accounts and when database
accounts are shared across multiple applications or administrative tasks or purposes.

The suggested strategy to protect access to database user accounts is listed to continuation: User enumeration, Feature
analysis, Reduction of accounts, Account password strength, Roles and privilege assessment, Password management and
Audit settings.

Assessing user account security is not a trivial task because of the complex relationships between the purposes of a user
account and who has access to the same user account, and the privileges assigned to that user account. The accounts that
Oracle installs such as SYS, SYSTEM, DBSNMP, etc., shouldn’t be modified by us since doing so may seem like a good
security solution, perhaps to remove a set of privileges from an account, but this may break existing functionality because
Oracle may use the account either directly or indirectly within some of its other features. It could be acceptable to lock
these accounts, but in reality the functionality that may be targeted by a hacker is not likely protected by locking because
simply logging in to an account is unnecessary to use the functionality provided by that account.

The first step in reviewing the strength of our database passwords should always be to use the PL/SQL cracker simply
because it’s much easier to use. When you need to assess passwords to a better level or simply have some of them to test,
a real password cracker is needed. The following list summarizes some of them: orabf, woraauthbf, checkpwd, cain and
abel, etc.

Securing user accounts within the database is not just technical, it’s also a process- or policy-driven problem. If a company
allows its users to share accounts within the database or to create database accounts for multiple purposes or, even worse,
to not even create a database account for a business purpose but then simply use a built-in account, then the problem is
procedurally related. Processes must be put in place to prevent procedural security problems hat are related to technical
user security types of problems.

Security, if done properly, is a time-consuming task, and contrary to popular belief is not simply a case of following hints
in a checklist but is a methodical and logical process: It’s important to work the steps in a methodical manner.