Oracle® Database Security Guide 10g Release 2 (10.2) Part Number B14266-08 |
|
|
PDF · Mobi · ePub |
The Oracle Database 10g Release 2 (10.2) security features and enhancements described in this section comprise the overall effort to provide superior access control, privacy, and accountability with this release of the database.
The following sections describe new security features of Oracle Database 10g Release 2 (10.2) and provide pointers to additional information:
To provide enhanced access control, privacy, and performance, the following enhancements have been added to Virtual Private Database (VPD), a feature of the Enterprise Edition:
Column-level VPD and Column-masking
Column-level VPD policies provides more fine-grained access controls on data. With column-level VPD, security policies can be applied only where a particular column or columns are accessed in the user's query. This means that when a user has rights to access the object itself, VPD can limit the individual rows returned only if the columns the user accesses contain sensitive information, such as salaries or national identity numbers.
The default behavior of column-level VPD restricts the number of rows returned when a query addresses columns containing sensitive data. In contrast, column-masking behavior allows all rows to be returned for a query against data protected by column-level VPD, but the columns that contain sensitive information are returned as NULL
values. With column-masking, users see all the data they are supposed to see, but privacy is not compromised.
See Also:
"Column-Level VPD" for conceptual information about these new features
"Adding Policies for Column-Level VPD" for information about how to add column-level VPD to your applications
Static, Context-Sensitive, and Shared VPD Policy Types
Static and context-sensitive policy types optimize VPD for significant performance improvements because the policy function does not execute for every SQL query. Static policies maintain the same predicate for queries, updates, inserts, and deletes throughout a session. (However application context or attributes such as SYSDATE
can change the value returned by the predicate.) They are particularly useful for hosting environments where you always need to apply the same predicate. With context-sensitive policies, the predicate can change after statement parse time, but VPD reexecutes the policy function only if the application context changes. This ensures that any changes to the predicate since the initial parsing are captured. Context-sensitive policies are useful when VPD policies must enforce two or more different predicates for different users or groups.
Both static and context-sensitive policies can be shared across multiple database objects, so that queries on another database object can use the same cached predicate. Shared policies enable you to further decrease the overhead of reexecuting policy functions for every query, reducing any performance impact.
See Also:
"DBMS_RLS.ADD_POLICY Procedure Policy Types" for more information about these new policy types and how to use them in applications.Application context support for parallel queries
In this release, if you use SYS_CONTEXT
inside a SQL function that is embedded in a parallel query, then the function picks up the application context.
See Also:
"Using SYS_CONTEXT in a Parallel Query" for information about using this enhancement.Oracle Database 10g Release 2 (10.2) includes the following new auditing features:
Improved fine-grained auditing
This release enhances the security of fine-grained auditing. In addition, fine-grained audit records can now be redirected to the same operating system file that receives standard audit records in XML format.
See Also:
"Fine-Grained Auditing" for more information about these new featuresXML audit records
Audit records can now be written to the operating system as XML files. A new dynamic view, V$XML_AUDIT_TRAIL
, provides enhanced usability by making XML audit records available to DBAs through a SQL query.
See Also:
"Operating System Audit Trail" for more information about this new viewSyslog audit records
Audit records can now be written to the operating system using a syslog audit trail. A potential security vulnerability to an operating system audit trail is that a privileged user such as a DBA can modify or delete audit records. In order to minimize this risk, you can use syslog, which is a standard protocol on UNIX-based systems for logging information from different components of a network.
See Also:
"Syslog Audit Trail" for more information about this new viewIn this release, the DBA_COMMON_AUDIT_TRAIL
view has been added, which presents both the standard and the fine-grained audit log records in a single view.
See Also:
"Database Audit Trail Contents" for more information about this new viewIn this release, a new flexible interface, DBMS_CRYPTO
, is provided to encrypt especially sensitive stored data, or it can also be used in conjunction with PL/SQL programs running network communications. This new interface provides support for the following features:
Keyed hash (MAC, or Message Authentication Code) algorithms (such as SHA-1)
DBMS_CRYPTO
is intended to replace the DBMS_OBFUSCATION_TOOLKIT
, providing greater ease of use and support for a range of algorithms to accommodate new and existing systems.
See Also:
Chapter 17, "Developing Applications Using Data Encryption" for information about how to use this package