Privilege Controls
At first, controls on user rights and privileges were nearly non-existent. Within a few years, Oracle introduced the concept of roles. Three roles were rigidly defined: CONNECT, RESOURCE, and DBA. Users could be assigned roles, but these roles could not be modified, nor could custom roles be created. All privileges were assigned directly to the roles, never to users. This continued until version 6 of the database was released, when Oracle introduced the capability to grant privileges to users. This was a significant improvement in the security system, allowing administrators to have much more granular control in giving out access to data on an as-needed basis. The CONNECT, RESOURCE, and DBA roles remained statically defined until version 7 of Oracle was released and the concept of user-defined roles was introduced. User-defined roles revolutionized the privilege control system in Oracle, allowing for efficient and flexible management of permissions by allowing them to be grouped together and assigned or removed in bulk. The Oracle7 role system remains in use today and will likely not be changed with the future release of Oracle11g. We'll cover using roles and privileges in detail in Chapter 4.
One more major development in the privilege control system came in Oracle8i: invoker rights procedures. Stored procedures have been around for quite some time, and were commonly used as they are today, to group complex functionality into a single procedure and then offer easy access through a simple interface. For a long time, all procedures were run with definer rights. This means that when a procedure is called, it runs at the privilege level of the definer (the user who owns the procedure), often the DBA. Invoker rights procedures are different. They run at the privilege level of the invoker (the user who ran the procedure). This offers flexibility to database developers who can now create procedures that access data and database functions without the worry of a user getting access to data they should never see.
Networking
Until version 5 of the database, Oracle offered no networking features. Database access was only permitted by directly connecting from the host operating system (OS). This required users to be able to access the server on which Oracle ran, making it impossible to implement any kind of distributed computing system. In version 5, SQL*Net 1.0 was introduced and with it came a dramatic change in how Oracle was used and how it was secured. It was no longer necessary to access the host OS to log in to the database; all that was needed was a network connection and some client software and the database could be accessed remotely. The introduction of SQL*Net had an important side effect. Users could now interact directly and exclusively with Oracle's immature user authentication system and could completely bypass the mature authentication features offered by the database host OS.
Oracle Advanced Networking Option

The Oracle Advanced Networking Option (ANO) was released with version 7.3 of the database in 1996. ANO was the first Oracle product to offer strong security for a networked database; its two primary features were network security and single sign-on.

Network Security
In Oracle's terms, network security means both confidentiality and integrity protection. The confidentiality part ensures that nobody can read the data as it crosses the network, while the integrity protection part ensures that nobody can change the data as it moves. Confidentiality was implemented using the symmetric key encryption algorithms Ron's Code 4 (RC4) and Data Encryption Standard (DES). The integrity protection was implemented with a cryptographic hash or message digest function called Message Digest 5 (MD5). Oracle chose strong algorithms and made attacks against the data as it traverses the network very difficult to execute.

Single Sign-on
In an attempt to simplify password management for organizations, Oracle began to integrate with third-party providers of single sign-on (SSO) authentication systems. The intention was to integrate Oracle databases into enterprise SSO systems, allowing users to set a single strong password in one place, and then use the same account to access all systems. This allowed users to remember only one password, and it allowed administrators to force the use of strong passwords on their users. Furthermore, SSO makes user provisioning and password management simple, as all credentials is managed centrally. In the initial release, Oracle offered support for a number of SSO systems, including Kerberos, CyberSAFE, SecurID, Biometric, and DCE GSSAPI.

Auditing

Oracle has offered auditing features in the database since very early on. Capabilities were provided to audit log-ins, object access, and database actions (defined as anything that makes a change to a database object, such as CREATE TABLE or ALTER DATABASE). Each event would be captured and labeled as successful or failed. Early versions of Oracle auditing were somewhat limited. Database actions could only be audited by role (CONNECT, RESOURCE, and DBA), not by individual user. SYSDBA activities could not be audited at all. Audit data was stored inside the database in the SYS.AUD$ table, and needed to be periodically truncated by the DBA. However, Oracle has supported auditing of access to SYS.AUD$ from the beginning.

With the Oracle7 release, database triggers were introduced. This new functionality was useful in many areas, audit in particular. The built-in Oracle auditing system records only those events that have occurred; it does not record before and after values for data changes. Triggers could be used to do just that, triggering on an update or delete to capture the old value before replacing or removing it. While a trigger-based audit system had to be implemented manually, it was a useful and powerful addition to the native auditing capabilities of the database.

Oracle7 also brought about the capability to write audit data directly to a flat file instead of into the database. This provided administrators with needed flexibility and allowed for tighter access controls on the audit data. The restrictions on database action auditing were lifted, allowing auditing by an individual user instead of by role.

Oracle8 came with its own set of improvements to the audit system. Things got much more granular with the capability to enable auditing at the object, schema, and system level. Oracle also added several views to allow for simpler review and analysis of the stored audit data.

Password Management

Oracle has included its own authentication and password management system since the very beginning. At first, the system was barebones. Each user got a password; the password was assigned and set by the DBA. Users had no means to change their own password, and Oracle had no automated controls for password management. Passwords never expired, never needed to be changed, and could be as simple or as complex as the DBA chose. Initially, the problem with this system was password distribution. Since the DBA had to set each user's password, they would also have to distribute the password to each user. This could be a challenge in a large organization with dozens or even hundreds of database users. Hand written notes, phone calls, and personal visits were commonly used to distribute the passwords, but that took time and users had to wait their turn to get their new password before being allowed into the database. At the time, it was not entirely uncommon for a DBA to simply give each user the same password. This made it easy to distribute the passwords, but created new security nightmares. Anyone with access could essentially log in with anybody else's account and privilege level. Things needed to change.

Before long, Oracle gave users the ability to alter their own password. This was a big improvement. The distribution problem was almost solved. DBAs still needed to set each user's initial password, and the same problems apply to distributing those initial passwords. However, the scope of the issue was drastically reduced. DBAs would instruct each user to change their initial password the first time they logged in to the database. They could even use the auditing system to ensure that a password change had been made. However, Oracle's password controls were still well behind those offered by the popular OSes of the time, which started to become a legitimate concern when Oracle databases began to accept connections from across the network.

Data Compartmentalization

In the database world, compartmentalization of data is something that is uniquely offered by Oracle. The concept involves classifying data elements, and then controlling access to those elements based on the classification and a user's access or security level. By assigning a security level and compartment to each row of data in the database, access can be tightly controlled on a row-by-row basis, even when permissions have been granted on the entire table. When queries are issued, the system compares the security level and compartments on the data being accessed with the security authorizations of the user executing the query. Only the rows that match the user's authorizations are accessible, enforcing mandatory access control. My Sumber Articles