Oracle Data Server Security
Enterprise User Security
Enterprise User Management Enhancements
Enterprise User Security is an Oracle Advanced Security feature. Oracle9i
complements certificate-based authentication with password-based authentication for
enterprise users. Enterprise user credentials and authorizations can be stored in Oracle
Internet Directory. This includes the username and encrypted password verifiers, enterprise
roles, and mappings to individual schemas on each database to which the user has access
rights.
Note: The installation and use of both SSL and Oracle wallets continue to be
a requirement on the server side, to establish a secure channel between the database
and Oracle Internet Directory.
Enterprise User Security Enhancements
Benefits of Enterprise User Security Enhancements
Because enterprise users now require only one username and password (stored in OID) to
access multiple databases, usability is improved. With the elimination of bi-directional
certificate matching, processing overhead is reduced and performance improves.
Security administrators can set up enterprise users to access multiple
databases with the same username and password. In addition, there is no
requirement to install SSL on the client side, and no requirement to set up and
maintain client-side wallets thereby simplifying enterprise user administration.
Because there is no requirement for SSL or Oracle wallets on the client, all prior Oracle
clients can function as enterprise users provided that they are password authenticated users.
In addition, Oracle Enterprise Login Assistant lets users change passwords and utilize single
sign-on whether they use Release 9i clients, Release 8i clients, or Release 8.0 or earlier
versions.
Oracle Enterprise Login Assistant
Oracle Enterprise Login Assistant
Oracle Enterprise Login Assistant is a client-side tool used to authenticate
users to the enterprise. It can download an Oracle wallet from the directory. It
can also decrypt the wallet and let users establish a seamless SSL
connection to all PKI-enabled applications and databases within the
enterprise, without requiring additional passwords. Enterprise Login Assistant can update
the directory password (OID only) and other related passwords stored in the directory, and it
can also upload an Oracle Wallet to the directory.
Enterprise User Security Management
Enterprise User Security Management
Oracle Wallet Manager can upload and retrieve wallets from Oracle Internet
Directory. Storing wallets in a directory store lets users access them from
multiple locations or devices, ensuring consistent and reliable user
authentication, while providing centralized wallet management throughout the wallet life
cycle. To prevent accidental overwrite of functional wallets, only wallets containing a
functional certificate can be uploaded.
Oracle Wallet Manager requires that enterprise users are already defined
and configured in the directory, to be able to upload or download wallets. If a
directory contains Oracle8i (or prior) users, they are automatically upgraded
to use the wallet upload/download feature upon first use. Oracle Wallet Manager
downloads a user wallet using a simple password-based connection to the directory.
However, for uploads it uses an SSL connection if the open wallet contains a certificate with
SSL Oracle PKI certificate usage.
Oracle Enterprise Login Assistant can open and close wallets, update
centrally managed wallets and passwords in OID, and enable or disable
secure SSL connections.
Update Passwords
Client Compatibility – Enterprise Users
The example above shows how older clients can participate in enterprise
user security, as well as how users on any client can update his passwords
on the directory using ASO (and specifically Enterprise Login Assistant).
Oracle9i password-authenticated enterprise users can use their local copy of
ELA, which is Oracle Internet Directory-enabled, to change their password.
Other clients can use a browser to connect to the Enterprise Login Assistant
Servlet, which is used to change the user’s password on the directory.
CONNECT INTERNAL De-support
De-Support of CONNECT INTERNAL
Why is CONNECT INTERNAL being de-supported in Oracle9i ?
o
To limit the methods by which an Oracle user can connect as a DBA user type
o
To maintain homogeneity across all Oracle product platforms
o
To provide stricter accountability of DBA user type connections
CONNECT INTERNAL syntax is no longer supported, not even for
backwards compatibility.
Virtual Private Database Enhancements
Virtual Private Database Enhancements
Oracle9i offers improved management of VPD policies through Oracle Policy
Manager, an easy-to-use graphical user interface accessed through Oracle
Enterprise Manager.
Oracle9i provides enhanced ability to partition security policy enforcement by
application, thus facilitating VPD deployment. Oracle9i enables partitioning of
Virtual Private Database through policy groups and a driving application
context. A driving application context securely determines which application
is accessing data, and policy groups facilitate managing the policies which
apply by application. Oracle9i also supports default policy groups, which
always apply to data access. Partitioned application context facilities
application development using VPD, because development groups no longer
need to collude; applications can have different security policies based upon
their individual application needs.
Many Web-based applications use connection pooling to achieve high scalability and
thereby support hundreds of thousands of users. These applications set up and reuse
connections instead of having different sessions for each user. Oracle9i VPD capabilities
facilitate connection pooling by allowing multiple connections to access one or more global
application contexts, instead of setting up an application context for each user session.
Partitioned Fine-Grained Access Control
Partitioned Fine Grained Access Control
In current state of application architecture where different products are tightly
integrated with each user. Sharing the same base tables and privileges, the
AND properties of fine grained access control policies at the base table can be cumbersome.
It requires sharing of information between products so that policies written for one product
may appropriately generate predicates for other products. Therefore, for ease of applying
fine-grained access control when multiple applications are sharing the same data, the idea of
partitioned fine grained access control is introduced to allow application driven security
policies.
For example, in case of a hosting environment, company A uses this feature
to host the BENEFIT table for company B and company C. The table is to be
accessed by two different applications, HR and FINANCE, each wanting to
enforce different security policies. HR application authorizes users based on
ranking in the company, and FINANCE application authorizes users based
on department. In Oracle8i, integrating these two policies into the BENEFIT
table would require joint development of policies between the two product
groups, not really a feasible option if two products come from rival companies.
Even if this is a configuration option it would be a nightmare to consider all
possible cases.
By defining an application context to drive the enforcement of a particular set
of policies to the base objects, each application can now implement a private
set of security policies.
Global Application Context
Global Application Context
Oracle9i VPD capabilities facilitate connection pooling by allowing multiple connections
to access one or more global application contexts, instead of setting up an application
context for each user session. Global application contexts provide additional flexibility for
Web-based applications to use Virtual Private Database, as well as enhanced
performance through reuse of common application contexts among multiple sessions
instead of setting up per-session application contexts.
Application user proxy authentication can be used with global application context for
additional flexibility and high performance in building eBusiness applications. This
provides performance improvements through session reuse, and through accessing
global application contexts set up once only, instead of having to initialize application contexts for
each session individually.
In order to decide the driving context for the current session to enforce fine grain access
control, the middle tier needs to set the application context for the session . The Global
Context allows the middle tier to store the various application context definitions in a
central place in the instance (SGA) and apply the context to a user session at session
creation time. This then becomes that session’s driving context. This will greatly reduce
the user session (application context setup) setup time in a application connection
pooling environment.
To support application managed session pooling by middle tier applications, the
DBMS_SESSION interface for managing application context has been enhanced. A client identifier is added
for each application context so that application context can be managed globally. Each client will see only
their assigned application context.
Managing Application Context
Managing Application Context
The middle tier application server can use SET_CONTEXT to set application context for a specific
client id. Then, when assigning a database connection to process the client request, the application server
needs to issue a SET_IDENTIFIER to denote the id of the application session. From then on, every time
the client invokes SYS_CONTEXT, only the context that was associated with the set identifier is returned.
Application Context Applied
Application Context Applied
The syntax for using DBMS_SESSION.SET_CONTEXT is:
DBMS_SESSION.SET_CONTEXT (
namespace VARCHAR2,
attribute VARCHAR2,
value
VARCHAR2,
username
VARCHAR2,
client_id VARCHAR2 );
namespace: The namespace of the application context to be set
attribute: The attribute of the application context to be set
Value: The value of the application context to be set
Username: The username attribute of the application context
client_id: The client_id attribute of the application context
The syntax for DBMS_SESSION.SET_IDENTIFIER is:
DBMS_SESSION.SET_IDENTIFIER (
VARCHAR2);
Where client_id is the application-specific identifier of the database session.
Application Context Applied (Continued)
Note that even if another database user ADAMS had logged into the
database, he cannot access the global context set by AS because application
server has specified that only the application with logged in user APPSMGR
can see the global context. If AS has used:
DBMS_SESSION.SET_CONTEXT('hr','id',
'scott',NULL,12345);
DBMS_SESSION.SET_CONTEXT('hr','dept','sales',NULL,12345);
Then, any user session, with client id set to 12345, can see the global context.
This is useful in that different users can share the same context. The users
should be aware of the security implication of different settings of global
context.
Basically, NULL in username means any user can access the global context;
and NULL client id in the global context means only session with uninitialized
client id can access the global context.
This feature has a negligible effect on the performance because this only
requires an additional hash table lookup of the driving context. Abuse of this
feature could cause concurrency problems, though, because of the nature of
synchronization access to the shared application context.
Application Context Initialized Globally
Application Context Utilizing Oracle Internet Directory
This feature should not be confused with application context that is accessed
globally (that is, the application context that is shareable in the SGA and which
enables application user proxy).
The main benefit of this feature is the ability to easily retrieve application
context attributes from Oracle Internet Directory on login.
Application context initialized globally utilizes the Oracle Internet Directory,
which is accessed through Lightweight Directory Access Protocol (LDAP).
Oracle Internet Directory stores a list of users to which this application is
assigned. Oracle9i can use Oracle Internet Directory as the directory service
for authentication and authorization of enterprise users. (Note that enterprise
user management requires Oracle Advanced Security.)
The LDAP object orclDBApplicationContext (a subclass of
groupOfUniqueNames) has been defined to store the application context
values in the directory. Note that an internal C function is required to retrieve
the orclDBApplicationContext value. A list of application context values is
returned to RDBMS
Oracle Label Security
Oracle Label Security
Oracle Label Security (OLS) is an add-on security option for the Oracle
Enterprise Edition. OLS provides sophisticated row level security. It adds a
secondary mediation check after the standard Oracle Object Privileges have
been verified. For example, if a user does not have select on a table, OLS will
not be invoked. OLS mediates access to rows by comparing sensitivity labels
attached to data rows with user label authorizations. OLS adds a column,
specified by an administrator, of datatype number(10) to individual tables or
all tables in a specified scheme. Using OLS you can restrict access based on
the sensitivity of data (confidential, secret, top secret), on the company name
in a hosting environment (ACME, Widget Inc), and the organization or
regional breakdown of data (ASIA, US, GLOBAL, EMEA). OLS is installed
using the Oracle9i custom install option.
Oracle Policy Manager
Oracle Policy Manager
For the tool to work properly users must have the appropriate privileges on
the corresponding data dictionary objects. Administration of Oracle Label
Security requires the LBAC_DBA role and execute on the following
packages:
sa_sysdba
sa_components
sa_label_admin
sa_user_admin
sa_session
Administration of Oracle Virtual Private Database using OPM requires
execute on the DBMS_RLS package.
Administration of Oracle Virtual Private Database using OPM requires select
on the following views:
all_policies
all_policy_groups
Administration of Application Context using OPM requires select on the
following views:
all_policy_contexts
dba_context
Oracle Policy Manager VPD Administration
VPD Administration
Oracle Policy Manager (OPM) is the new GUI administration tool for Oracle
Label Security, Oracle Virtual Private Database and Application Context. The
tool is invoked by typing oemapp opm at the operating system command
prompt.:
$ oemapp opm
API’s are available in place of the OPM. Please see the Oracle Label Security
Administrator's Guide and Application Developer's Guide - Fundamentals Policy-Based
Security.
Oracle Policy Manager Label Security
Administration
DBMS_OBFUSCATION_TOOLKIT Enhancements
DBMS_OBFUSCATION_TOOLKIT Enhancements
The DBMS_OBFUSCATION_TOOLKIT packages require an encryption key
as an attribute. If keys are weak (that is, easy to guess or predictable), it
makes encryption much easier to break through cryptanalysis. Time of day,
serial number of machines and the like are all predictable and thus cannot be
used as random numbers for cryptographic keys. DBMS_RANDOM in
particular cannot be used as a secure random number generator since a
given seed (input) will always produce the same output. In Oracle 9i, a FIPS
-140 certified random number generator (GetKey) makes secure random
number generation easier.
While key management is still programmatic, having a secure random
number generator means that the solution is much more likely to be secure
against cryptanalysis as long as keys are stored securely. That said, it would
be difficult to recover data using a brute force attack if the keys are securely
stored and randomly generated.
Fine Grained Auditing
Fine Grained Auditing
Auditing in the DBMS is often used to monitor data access. Audit records are
essential in proving the violation of access rights. Currently in Oracle, a fixed
set of facts (for example, userid, timestamp, object name) are recorded in the audit trail.
Previously, audit options could only be set to monitor access of privileges or objects. There
was no support for getting more specific information about the environment or query results,
nor any mechanism to specify audit conditions in order to minimize false audits. In many
cases, these access logs are insufficient to reconstruct the event, or even to determine
whether access rights have been violated.
The new value-based auditing mechanism addresses the issues of more granular level of
auditing. In general, the new auditing policy is to based on simple user-defined SQL
predicates on table objects as conditions for selective auditing.
In addition to value based, there are also cases where the administrators are
only interested in whether a certain column is being referenced or accessed.
In this regard, the idea of audit column is supported, that is, whenever a
column is selected in any part of a DML statement, Oracle will audit the
query.
Fine-grained Auditing
Fine-Grained Auditing Specifics
Fine-grained auditing is available only on SELECT statements with a WHERE
clause, and for one audit column only.
The triggering event above was not only that the user accessed employee
records for which salaries are greater than 10,000, but also that the salary
was actually returned to the user. This limits the audit information actually
logged and, of course, ensures relevancy. A record is written to the audit trail that includes
the complete SQL statement the user submitted, a timestamp, username, and other
information.
Fine-grained auditing does not automatically capture the statements returned to the user;
however, you may be able to use fine-grained auditing in conjunction with Flashback Query
to recreate the records returned to the user.
Fine-grained auditing can function as an intrusion detection system for the
database. For example, a developer could add an event handle to a policy to
page an administrator if certain events occur. Non-SQL access is not audited,
for example, if you use direct path load, which bypasses the SQL layer of the database,
the audit condition is not triggered.
Fine Grained Auditing Concepts
FGA Concepts
Fine grained auditing allows the monitoring of data access based on content.
More importantly, the monitoring does not depend on how it is done. A built-in
audit mechanism into the database that users cannot bypass is essential.
Oracle DBMS has already provided triggers capability for potentially
monitoring DML actions such as INSERT/UPDATE/DELETE. However, monitoring on
SELECT is costly and may not work for all cases. In addition, users may want to define their
own alert action in addition to just inserting an audit record into the audit trail. This feature
provides an extensible interface to audit SELECT/UPDATE/INSERT/DELETE on tables and
views.
Use DBMS_FGA PL/SQL package interface to apply policies to tables or views.
o
ADD_POLICY
o
DROP_POLICY
o
ENABLE_POLICY
o
DISABLE_POLICY
Adding a Policy
Adding a Policy
To audit queries against the EMPLOYEES table that access the salary of employees
belonging to department 10, you can issue the SQL statement above to initiate the auditing.
Triggering Audit Events
Audit Events
In general, fine-grained auditing policy is based on simple user-defined SQL
predicates (where clause) on table objects as conditions for selective auditing.
During fetching, whenever policy conditions are met for a returning row, the
query is audited. Later, Oracle executes user-defined audit event handlers
using autonomous transactions to process the event.
Fine-grained auditing can be implemented in user applications using the
DBMS_FGA package.
Fine Grained Auditing
Add a Policy with an Audit Event Handler
In the example above, when the first interested row is fetched, the audit event
record is recorded and stored in FGA_ AUD$ which has columns for SQL text, bind
variables and policy name. Finally, the audit function sec.log_id is fired.
Security of Default Accounts
Locking Default Accounts
Hackers love breaking into databases using unchanged default accounts and
passwords because it is so easy! There are 17 of them in Oracle8i. In
Oracle9i they numbered 32 at last count.
To make the database more secure, most default accounts are locked . The
SCOTT/TIGER account is unlocked so that the packaged demos will work.
Once users inspect the demos, we recommend that SCOTT be locked also
because there are grants to PUBLIC <by default> that can be put to ill use.
Default Account Security
Default Account Security
Passwords should be changed regularly as a general security principle.
When you unlock default accounts, change the password! Make the
passwords sufficiently complex, of sufficient length, and with numeric as well
as alphabetic characters.
There are many password-cracking tools available. L0phtcrack, a hacker
favorite, cracks passwords with amazing rapidity - less than four hours for
even a very complex password. Many of these cracking tools use a language
dictionary, so avoid using recognizable words or names in your passwords.
Random character mixes are best. Please keep that in mind when choosing
passwords
Summary