10

Implementing Oracle Database Security

Copyright © 2005, Oracle. All rights reserved.

 Objectives

After completing this lesson, you should be able to

do the following:
• Describe your DBA responsibilities for security
• Implement security by applying the principle of
least privilege
• Manage default user accounts
• Implement standard password security features
• Describe database auditing
• Describe Virtual Private Database (VPD)

10-2 Copyright © 2005, Oracle. All rights reserved.

 Industry Security Requirements

• Legal:
– Sarbanes-Oxley Act (SOX)
– Health Information Portability and Accountability
Act (HIPAA)
– California Breach Law
– UK Data Protection Act
• Auditing

10-3 Copyright © 2005, Oracle. All rights reserved.

 Security Requirements
Full Notes Page

10-4 Copyright © 2005, Oracle. All rights reserved.

 Separation of Responsibilities

• Users with DBA privileges must be trusted.

Consider:
– Abuse of trust
– Audit trails protect the trusted position.
• DBA responsibilities must be shared.
• Accounts must never be shared.
• The DBA and the system administrator must be
different people.
• Separate operator and DBA responsibilities.

10-5 Copyright © 2005, Oracle. All rights reserved.

 Database Security

A secure system ensures the confidentiality of the data

that it contains. There are several aspects of security:
• Restricting access to data and services
• Authenticating users
• Monitoring for suspicious activity

10-6 Copyright © 2005, Oracle. All rights reserved.

 Database Security
Full Notes Page

10-7 Copyright © 2005, Oracle. All rights reserved.

 Principle of Least Privilege

• Install only required software on the machine.

• Activate only required services on the machine.
• Give OS and database access to only those users
that require access.
• Limit access to the root or administrator account.
• Limit access to the SYSDBA and SYSOPER
accounts.
• Limit users’ access to only the database objects
required to do their jobs.

10-8 Copyright © 2005, Oracle. All rights reserved.

 Applying the Principle of Least Privilege

• Protect the data dictionary:

O7_DICTIONARY_ACCESSIBILITY=FALSE
• Revoke unnecessary privileges from PUBLIC:
REVOKE EXECUTE ON UTL_SMTP, UTL_TCP, UTL_HTTP,
UTL_FILE FROM PUBLIC;

• Restrict the directories accessible by users.

• Limit users with administrative privileges.
• Restrict remote database authentication:
REMOTE_OS_AUTHENT=FALSE

10-9 Copyright © 2005, Oracle. All rights reserved.

 Apply the Principle of Least Privilege
Full Notes Page

10-10 Copyright © 2005, Oracle. All rights reserved.

 Managing Default User Accounts

• DBCA expires and

locks all accounts,
except:
– SYS
– SYSTEM
– SYSMAN
– DBSNMP
• For a manually
created database,
lock and expire any
unused accounts.

10-11 Copyright © 2005, Oracle. All rights reserved.

 Implementing Standard Password
Security Features

Password Account
history locking

User Setting up
profiles

Password aging and Password

expiration complexity
verification

10-12 Copyright © 2005, Oracle. All rights reserved.

 Password Security
Full Notes Page

10-13 Copyright © 2005, Oracle. All rights reserved.

 Supplied Password Verification Function:
VERIFY_FUNCTION

The supplied password verification function enforces

these password restrictions:
• The minimum length is four characters.
• The password cannot be the same as the
username.
• The password must have at least one alphabetic,
one numeric, and one special character.
• The password must differ from the previous
password by at least three letters.
Tip: Use this function as a template to create
your own customized password verification.

10-14 Copyright © 2005, Oracle. All rights reserved.

 Creating a Password Profile

10-15 Copyright © 2005, Oracle. All rights reserved.

 Assigning Users to a Password Profile

Select Administration > Schema > Users & Privileges >

Users.

10-16 Copyright © 2005, Oracle. All rights reserved.

 Where We Are

• Comparing security aspects

• Applying the principle of least privilege
• Managing default user accounts
• Implementing standard password security features
• Creating and using password profiles
• Auditing
• Virtual Private Database (VPD)

10-17 Copyright © 2005, Oracle. All rights reserved.

 Monitoring for Suspicious Activity

Monitoring or auditing must be an integral part of your

security procedures. Review the following:
• Mandatory auditing
• Standard database auditing
• Value-based auditing
• Fine-grained auditing (FGA)
• DBA auditing

10-18 Copyright © 2005, Oracle. All rights reserved.

 Enterprise Manager Audit Page

10-19 Copyright © 2005, Oracle. All rights reserved.

 Standard Database Auditing

(1) Enable
database
Parameter
DBA auditing. User
file executes
(2) Specify audit options. command.

Database
Server
process
Audit
Generate
options
audit trail.

(3) Review audit Audit

trail OS or XML
information.
audit
(4) Maintain audit trail.
trail

10-20 Copyright © 2005, Oracle. All rights reserved.

 Uniform Audit Trails

STATEMENTID,
AUDIT_TRAIL=DB,EXTENDED
ENTRYID

DBA_AUDIT_TRAIL DBA_FGA_AUDIT_TRAIL

EXTENDED_TIMESTAMP,
PROXY_SESSIONID, GLOBAL_UID,
INSTANCE_NUMBER, OS_PROCESS,
TRANSACTIONID, SCN, SQL_BIND, SQL_TEXT

DBA_COMMON_AUDIT_TRAIL

10-21 Copyright © 2005, Oracle. All rights reserved.

 Enhanced Enterprise User Auditing

Exclusive schema Shared schema

Standard audit Standard audit

USERNAME USERNAME
GLOBAL_UID

Fine-grained audit Fine-grained audit

DB_USER DB_USER
GLOBAL_UID

10-22 Copyright © 2005, Oracle. All rights reserved.

 Value-Based Auditing

A user makes a Trigger fires. Audit record is

change. created by the trigger.

User’s change And it is inserted into

is made. an audit trail table.

10-23 Copyright © 2005, Oracle. All rights reserved.

 Value-Based Auditing
Full Notes Page

10-24 Copyright © 2005, Oracle. All rights reserved.

 Fine-Grained Auditing

• Monitors data access on the basis of content

• Audits SELECT, INSERT, UPDATE, DELETE, and
MERGE
• Can be linked to a table or view, to one or more
columns
• May fire a procedure
• Is administered with the DBMS_FGA package
Policy: AUDIT_EMPS_SALARY
SELECT name, salary
FROM employees
WHERE
department_id = 10; employees

10-25 Copyright © 2005, Oracle. All rights reserved.

 FGA Policy
dbms_fga.add_policy (
object_schema => 'HR',
object_name => 'EMPLOYEES',
• Defines: policy_name => 'audit_emps_salary',
– Audit criteria audit_condition=> 'department_id=10',
audit_column => 'SALARY',
– Audit action handler_schema => 'secure',
• Is created with handler_module => 'log_emps_salary',
enable => TRUE,
DBMS_FGA statement_types => 'SELECT' );
.ADD_POLICY

SELECT name, job_id

FROM employees;

SELECT name, salary

FROM employees SECURE.LOG_
WHERE EMPS_SALARY
department_id = 10;
employees

10-26 Copyright © 2005, Oracle. All rights reserved.

 FGA Policy
Full Notes Page

10-27 Copyright © 2005, Oracle. All rights reserved.

 Audited DML Statement: Considerations

• Records are audited if FGA predicate is satisfied

and relevant columns are referenced.
• DELETE statements are audited regardless of any
specified columns.
• MERGE statements are audited with the underlying
INSERT or UPDATE generated statements.
UPDATE hr.employees
SET salary = 10
WHERE commission_pct = 90;

UPDATE hr.employees
SET salary = 10
WHERE employee_id = 111;

10-28 Copyright © 2005, Oracle. All rights reserved.

 FGA Guidelines

• To audit all statements, use a null condition.

• Policy names must be unique.
• The audited table or view must already exist when
you create the policy.
• If the audit condition syntax is invalid, an ORA-
28112 error is raised when the audited object is
accessed.
• If the audited column does not exist in the table,
no rows are audited.
• If the event handler does not exist, no error is
returned and the audit record is still created.

10-29 Copyright © 2005, Oracle. All rights reserved.

 DBA Auditing

Users with the SYSDBA or SYSOPER privileges can

connect when the database is closed:
• Audit trail must be stored outside the database.
• Connecting as SYSDBA or SYSOPER is always
audited.
• Enable additional auditing of SYSDBA or SYSOPER
actions with audit_sys_operations.
• Control audit trail with audit_file_dest.

10-30 Copyright © 2005, Oracle. All rights reserved.

 Maintaining the Audit Trail

The audit trail should be maintained. Follow best

practice guidelines:
• Review and store old records
• Prevent storage problems
• Avoid loss of records

10-31 Copyright © 2005, Oracle. All rights reserved.

 Quiz: What Is Audited?

Type of Audit What Is What Is in the

Audited? Audit Trail?
Standard database auditing
Value-based auditing
Fine-grained auditing (FGA)
Match the following text, “A” to “What is Audited?”, and “T” to
“What is in the Audit Trail?”.
A1: Data changed by DML statements
A2: SQL statements (insert, update, delete, select, and merge)
based on content)
A3: Privilege use including object access
T1: Fixed set of data including the SQL statement
T2: Fixed set of data
T3: N/A

10-32 Copyright © 2005, Oracle. All rights reserved.

 Where We Are

• Comparing security aspects

• Applying the principle of least privilege
• Managing default user accounts
• Implementing standard password security features
• Describing auditing:
– Mandatory auditing
– Standard database auditing
– Value-based auditing
– Fine-grained auditing
– DBA auditing
• Virtual Private Database (VPD)

10-33 Copyright © 2005, Oracle. All rights reserved.

 Virtual Private Database: Overview

• Virtual Private Database (VPD) consists of:

– Fine-grained access control
– Secure application context
• VPD uses policies to add conditions to SQL
statements that protect sensitive data.
• VPD provides row-level access control.
• Application attributes defined inside an
application context are used by fine-grained
access policies.

10-34 Copyright © 2005, Oracle. All rights reserved.

 VPD Example

Business rule: Employees outside the HR department

are only allowed to see their own EMPLOYEES record.
A salesman enters the following query:
SELECT * FROM EMPLOYEES;
The function implementing the security policy returns
the predicate employee_id='my_emp_id' and the
database rewrites the query and executes the
following:
SELECT * FROM EMPLOYEES
WHERE employee_id='my_emp_id‘;

10-35 Copyright © 2005, Oracle. All rights reserved.

 Creating a Column-Level Policy

BEGIN
dbms_rls.add_policy(object_schema => 'hr',
object_name => 'employees',
policy_name => 'hr_policy',
function_schema =>'hr',
policy_function => 'hrsec',
statement_types =>'select,insert',
sec_relevant_cols=>'salary,commission_pct');
END;
/

10-36 Copyright © 2005, Oracle. All rights reserved.

 Column-Level VPD: Example

• Statements are not always rewritten.

• Consider a policy protecting the SALARY and
COMMISSION_PCT columns of the EMPLOYEES
table. The fine-grained access control is:
– Not enforced for this query:

SQL> SELECT last_name FROM employees;

– Enforced for these queries:

SQL> SELECT last_name, salary
2 FROM employees;

SQL> SELECT * FROM employees;

10-37 Copyright © 2005, Oracle. All rights reserved.

 Security Updates

• Oracle posts security alerts on the Oracle

Technology Network Web site at:
http://www.oracle.com/technology/deploy/security/alerts.htm
• Oracle database administrators and developers
can also subscribe to be notified about critical
security alerts via e-mail by clicking the
“Subscribe to Security Alerts Here” link.

10-38 Copyright © 2005, Oracle. All rights reserved.

 Applying Security Patches

• Use the Critical Patch Update process.

• Apply all security patches and workarounds.
• Contact the Oracle security products team.

10-39 Copyright © 2005, Oracle. All rights reserved.

 Summary

In this lesson, you should have learned how to:

• Describe your DBA responsibilities for security
• Apply the principle of least privilege
• Manage default user accounts
• Implement standard password security features
• Describe database auditing
• Describe Virtual Private Database (VPD)

10-40 Copyright © 2005, Oracle. All rights reserved.

 Practice Overview:
Implementing Oracle Database Security

This practice covers the following topics:

• Expiring passwords every 60 days
• Locking accounts after a grace period of 10 days
• Not allowing the reuse of passwords for 1,800 days
• Forcing accounts to lock for 10 minutes after four
failed login attempts

10-41 Copyright © 2005, Oracle. All rights reserved.

 Full Notes Page

10-42 Copyright © 2005, Oracle. All rights reserved.