PK j?oa,mimetypeapplication/epub+zipPKj?iTunesMetadata.plistE artistName Oracle Corporation book-info cover-image-hash 716077816 cover-image-path OEBPS/dcommon/oracle-small.JPG package-file-hash 868657956 publisher-unique-id E16543-04 unique-id 740032234 genre Oracle Documentation itemName Oracle® Database Security Guide, 11g Release 2 (11.2) releaseDate 2010-10-25T15:31:23Z year 2010 PKJEPKj?META-INF/container.xml PKYuPKj?OEBPS/index.htm Index

Index

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X 

A

access control
encryption, problems not solved by, 8.1.1
enforcing, 10.9.1
object privileges, 4.5.1
password encryption, 3.2.1
access control list (ACL)
examples
external network connection for e-mail alert, 9.5.9.1
external network connections, 4.11.6
wallet access, 4.11.6
external network services
about, 4.11.1
adding more users or privileges, 4.11.4.1
advantages, 4.11
affect of upgrade from earlier release, 4.11.3
creating ACL, 4.11.4
DBMS_NETWORK_ACL_ADMIN package, general process, 4.11.4
e-mail alert for audit violation tutorial, 9.5.9.1
finding information about, 4.11.12
hosts, assigning, 4.11.4.2
network hosts, using wildcards to specify, 4.11.7
ORA-24247 errors, 4.11.3
order of precedence, hosts, 4.11.8
port ranges, 4.11.9
privilege assignments, about, 4.11.10
privilege assignments, database administrators checking, 4.11.10.1
privilege assignments, users checking, 4.11.10.2
setting precedence, multiple roles, 4.11.11
setting precedence, multiple users, 4.11.11
syntax for creating, 4.11.4.1
hosts
local host, 4.11.4.2
localhost setting, 4.11.4.2
wallet access
about, 4.11.2
advantages, 4.11.2
client certificate credentials, using, 4.11.5
finding information about, 4.11.12
non-shared wallets, 4.11.5
password credentials, 4.11.5
password credentials, using, 4.11.5
shared database session, 4.11.5
wallets with sensitive information, 4.11.5
wallets without sensitive information, 4.11.5
account locking
example, 3.2.3.5
explicit, 3.2.3.5
password management, 3.2.3.5
PASSWORD_LOCK_TIME initialization parameter, 3.2.3.5
ad hoc tools
database access, security problems of, 4.4.7.1
ADM_PARALLEL_EXECUTE_TASK role
about, 4.4.2
ADMIN OPTION
about, 4.6.1.1
revoking privileges, 4.7.1
revoking roles, 4.7.1
roles, 4.4.5.1
system privileges, 4.3.4
administrative user passwords
default, importance of changing, 10.5
administrator privileges
access, 10.9.2
operating system authentication, 3.3.2
passwords, 3.3.3, 10.5
SYSDBA and SYSOPER access, centrally controlling, 3.3.1, 3.3.1
write, on listener.ora file, 10.9.2
adump audit files directory, 9.6.2
adx_SID.txt file from XML audit trail
about, 9.3.2.2
alerts, used in fine-grained audit policy, 9.5.9.1
"all permissions", 10.3
ALTER privilege statement
SQL statements permitted, 5.8.2
ALTER PROCEDURE statement
used for compiling procedures, 4.5.6.6
ALTER PROFILE statement
password management, 3.2.3.1
ALTER RESOURCE COST statement, 2.4.4.2
ALTER ROLE statement
changing authorization method, 4.4.3
ALTER SESSION statement
schema, setting current, 5.7.1
ALTER USER privilege, 2.3
ALTER USER statement
AUTHENTICATION USER PASSWORD clause deprecated, Preface
default roles, 4.10.2
explicit account unlocking, 3.2.3.5
GRANT CONNECT THROUGH clause, 3.10.1.3
passwords, changing, 2.3.1
passwords, expiring, 3.2.3.7
profiles, changing, 3.2.3.7
REVOKE CONNECT THROUGH clause, 3.10.1.3
user profile, 3.2.3.1
altering users, 2.3
ANSI operations
Oracle Virtual Private Database affect on, 7.5.3
ANY system privilege
guidelines for security, 10.6
application contexts
about, 6.1.1
as secure data cache, 6.1.4
benefits of using, 6.1.4
bind variables, 7.1.4
components, 6.1.2
DBMS_SESSION.SET_CONTEXT procedure, 6.3.3.6, 6.3.3.6
driving context, 6.6
editions, affect on, 6.1.5
finding errors by checking trace files, 6.6
finding information about, 6.6
global application contexts
authenticating user for multiple applications, 6.4.3.5
creating, 6.4.2
logon trigger, creating, 6.3.4
Oracle Virtual Private Database, used with, 7.1.4
performance, 7.4.2.8
policy groups, used in, 7.3.5.1
returning predicate, 7.1.4
session information, retrieving, 6.3.3.2
support for database links, 6.3.6
types, 6.2
users, nondatabase connections, 6.4.1, 6.4.3.6
where values are stored, 6.1.3
See also client session-based application contexts, database session-based application contexts, global application contexts
application developers
CONNECT role change, 10.11.3.2
application security
restricting wallet access to current application, 4.11.5
sharing wallet with other applications, 4.11.5
specifying attributes, 6.3.2
application users who are database users
Oracle Virtual Private Database, how it works with, 7.5.8
applications
about security policies for, 5.1
database users, 5.2.1
enhancing security with, 4.4.1.2
object privileges, 5.8.1
object privileges permitting SQL statements, 5.8.2
One Big Application User authentication
security considerations, 5.2.2
security risks of, 5.2.1
Oracle Virtual Private Database, how it works with, 7.5.4
password handling, guidelines, 5.3.1.2
password protection strategies, 5.3
privileges, managing, 5.4
roles
multiple, 4.4.1.3.1
privileges, associating with database roles, 5.6
security, 4.4.7, 5.2.2
security considerations for use, 5.2
security limitations, 7.5.4
security policies, 7.3.5.3
validating with security policies, 7.3.5.5
AQ_ADMINISTRATOR_ROLE role
about, 4.4.2
AQ_USER_ROLE role
about, 4.4.2
archiving
operating system audit files, 9.8.3.4
standard audit trail, 9.8.2.5
timestamping audit trail, 9.9.3.4
attacks
See security attacks
AUDIT EXECUTE PROCEDURE statement, 9.3.12.2
audit files
activities always written to, 9.1.5
directory, 9.6.2
file names, form of, 9.6.2
operating system audit trail
archiving, setting timestamp, 9.9.3.4
audited actions in common with database audit trail, 9.3.3
operating system file
advantages of using, 9.3.4.3
appearance of text file, 9.3.4.2
appearance of XML file, 9.3.4.2
archiving, 9.8.3.4
contents, 9.3.4.1
directory location, 9.3.4.5
how it works, 9.3.4.4
if becomes too full, 9.8.3.1
standard audit trail
archiving, setting timestamp, 9.9.3.4
audited actions in common with operating system audit trail, 9.3.3
records, archiving, 9.8.2.5
where written to, 9.6.2
AUDIT statement
about, 9.3.1.1
schema objects, 9.3.10.5
audit trail
about, 9.8.1
archiving, 9.8.2.5
deleting views, 9.10.3
finding information about, 9.10.1
interpreting, 9.10.2
types of, 9.8.1
See also standard audit trail, SYS.AUD$ table, SYS.FGA_LOG$ table
AUDIT_FILE_DEST initialization parameter
about, 9.3.4.5
setting for OS auditing, 9.3.4.5
AUDIT_SYS_OPERATIONS initialization parameter
auditing SYS, 9.6.2
AUDIT_SYSLOG_LEVEL initialization parameter
how it affects mandatory audit records, 9.1.5
AUDIT_TRAIL initialization parameter
about, 9.3.2.1
auditing SYS, 9.6.2
database, starting in read-only mode, 9.3.2.2
DB (database) setting, 9.3.2.2
DB, EXTENDED setting, 9.3.2.2
disabling, 9.3.2.2
OS (operating system) setting, 9.3.2.2
setting, 9.3.2.1
values, 9.3.2.2
XML setting, 9.3.2.2
XML, EXTENDED setting, 9.3.2.2
auditing
administrators
See standard auditing
audit options, 9.2
audit records, 9.8.1
audit trail, sensitive data in, 10.10.1
audit trails, 9.8.1
before-and-after changes, recording with triggers, 9.7
committed data, 9.3.6.2, 10.10.3
database user names, 3.5
default auditing, enabling, 9.4.1
distributed databases and, 9.1.6
finding information about, 9.10.1
fine-grained
See fine-grained auditing
functions, 9.3.12.1
functions, Oracle Virtual Private Database, 9.3.12.1
general steps for, 9.2
guidelines for security, 10.10
historical information, 10.10.3
keeping information manageable, 10.10.2
LOBs, auditing
user-defined columns, 9.5.2
logon and logoff events, 9.3.7.3
middle-tier systems, real user actions, 3.10.1.10
multitier environments
See standard auditing
network
See standard auditing
object columns, 9.5.2
objects
See standard auditing
One Big Application User authentication, compromised by, 5.2.1
operating system files
appearance, 9.3.4.2
configuring, 9.3.2.2
managing, 9.8.3
operating-system user names, 3.5
Oracle Virtual Private Database policy functions, 9.3.12.1
packages, 9.3.12.1
performance, 9.1.7
PL/SQL packages, 9.3.12.1
privileges
See standard auditing
procedures, 9.3.12.1
range of focus, 9.2
recommended settings, 10.10.5
Sarbanes-Oxley Act
auditing, meeting compliance through, 9.1.1
schema objects
See standard auditing
schema objects created in the future, 9.3.10.5
SQL statements
See standard auditing
standard
See standard audit trail, standard auditing
statements
See standard auditing
STMT_AUDIT_OPTION_MAP table, 9.3.3
suspicious activity, 10.10.4
SYS user, 9.6.2
SYS.FGA_LOG$ table, 9.5.4
SYSTEM user, 9.6.1
SYSTEM_PRIVILEGE_MAP table, 9.3.3
triggers, 9.3.12.1
triggers used for, 9.7
UNIX syslog, 9.1.5
views
active object options, 9.10.2.3
active privilege options, 9.10.2.2
active statement options, 9.10.2.1
default object options, 9.10.2.4
when audit options take effect, 9.3.1.3
XML files
appearance, 9.3.4.2
configuring, 9.3.2.2
See also SYS.AUD$ table, SYS.FGA_LOG$ table, standard auditing, standard audit trail, fine-grained auditing
auditing, purging records
about, 9.9.1
cancelling archive timestamp, 9.9.6.7
clearing database audit trail batch size, 9.9.6.8
creating audit trail
purge job, 9.9.3
creating the purge job, 9.9.3.5
database audit trail
purging subset of records, 9.9.5
deleting a purge job, 9.9.6.6
disabling purge jobs, 9.9.6.4
enabling purge jobs, 9.9.6.4
example, 9.9.7
general steps for, 9.9.2
initializing
cancelling, 9.9.6.3
initializing cleanup operation, 9.9.3.3
initializing, checking if done, 9.9.6.1
purging audit trail manually, 9.9.4
purging records in batched groups, 9.9.3.6
roadmap, 9.9.2
scheduling the purge job, 9.9.3.5
setting archive timestamp, 9.9.3.4
time interval for all purge jobs, 9.9.6.2
time interval for named purge job, 9.9.6.5
AUTHENTICATEDUSER role, 4.4.2
authentication
about, 3.1
administrators
operating system, 3.3.2
passwords, 3.3.3
SYSDBA and SYSOPER access, centrally controlling, 3.3.1
by database, 3.4
by SSL, 3.7.1.1
client, 10.9.1
client-to-middle tier process, 3.10.1.5
database administrators, 3.3
databases, using
about, 3.4.1
advantages, 3.4.2
procedure, 3.4.3
directory service, 3.7.1
directory-based services, 3.6.2
external authentication
about, 3.8.1
advantages, 3.8.2
operating system authentication, 3.8.4
user creation, 3.8.3
global authentication
about, 3.7
advantages, 3.7.2
user creation for private schemas, 3.7.1.1
user creation for shared schemas, 3.7.1.2
middle-tier authentication
proxies, example, 3.10.1.7
multitier, 3.9
network authentication
Secure Sockets Layer, 3.6.1
third-party services, 3.6.2
One Big Application User, compromised by, 5.2.1
operating system authentication
about, 3.5
advantages, 3.5
disadvantages, 3.5
proxy user authentication
about, 3.10.1
expired passwords, 3.10.1.3
public key infrastructure, 3.6.2
RADIUS, 3.6.2
remote, 10.9.1, 10.9.1
specifying when creating a user, 2.2.3
strong, 10.5
SYSDBA on Windows systems, 3.3.2
Windows native authentication, 3.3.2
See also passwords, proxy authentication
AUTHID DEFINER clause
used with Oracle Virtual Private Database functions, 7.1.3
authorization
about, 4
changing for roles, 4.4.3
global
about, 3.7
advantages, 3.7.2
multitier, 3.9
omitting for roles, 4.4.3
operating system, 4.4.4.3.1
roles, about, 4.4.4
automatic reparse
Oracle Virtual Private Database, how it works with, 7.5.5
Automatic Storage Management (ASM)
SYSASM privilege, Preface

B

banners
auditing user actions, configuring, 5.9.5
unauthorized access, configuring, 5.9.5
batch jobs, authenticating users in, 3.2.5.1
BFILEs
guidelines for security, 10.6
bind variables
application contexts, used with, 7.1.4
information captured in audit trail, 9.3.2.2
BLOBS
encrypting, 8.2.6
BY ACCESS clause
about, 9.3.6.5
benefits of using, 9.3.6.5
finding statement audit options, 9.10.2.1
NOAUDIT statement non-support of, 9.3.6.7
using, 9.3.6.5

C

CAPI_USER_ROLE role, 4.4.2
cascading revokes, 4.7.3
CATNOAUD.SQL script
about, 9.10.3
audit trail views, deleting with, 9.10.3
certificate key algorithm
Secure Sockets Layer, 10.9.3
change_on_install default password, 10.5
character sets
role names, multibyte characters in, 4.4.3
role passwords, multibyte characters in, 4.4.4.1
cipher suites
Secure Sockets Layer, 10.9.3
client connections
guidelines for security, 10.9.1
secure external password store, 3.2.5.3
securing, 10.9.1
client identifier
setting for applications that use JDBC, 3.10.2.3
client identifiers
about, 3.10.2
auditing users, 9.3.9
consistency between DBMS_SESSION.SET_IDENTIFIER and DBMS_APPLICATION_INFO.SET_CLIENT_INFO, 3.10.2.4
global application context, independent of, 3.10.2.3
setting with DBMS_SESSION.SET_IDENTIFIER procedure, 6.4.1
See also nondatabase users
client session-based application contexts
about, 6.5.1
CLIENTCONTEXT namespace, clearing value from, 6.5.4
CLIENTCONTEXT namespace, setting value in, 6.5.2
retrieving CLIENTCONTEXT namespace, 6.5.3
See also application contexts
CLIENT_IDENTIFIER USERENV attribute
setting and clearing with DBMS_SESSION package, 3.10.2.4
setting with OCI user session handle attribute, 3.10.2.3
See also USERENV namespace
CLIENTID_OVERWRITE event, 3.10.2.4
column masking behavior, 7.3.4.3
column specification, 7.3.4.3
restrictions, 7.3.4.3
columns
granting privileges for selected, 4.6.2.3
granting privileges on, 4.6.2.3
INSERT privilege and, 4.6.2.3
listing users granted to, 4.12.3
privileges, 4.6.2.3
pseudo columns
USER, 4.5.5.3
revoking privileges on, 4.7.2.2
command line recall attacks, 5.3.1.1, 5.3.1.4
committed data
auditing, 9.3.6.2, 10.10.3
configuration
guidelines for security, 10.8
configuration files
listener.ora, 10.9.2
sample listener.ora file, 10.9.2
server.key encryption file, 10.9.3
tsnames.ora, 10.9.3
typical directory, 10.9.3, 10.9.3
CONNECT role
about, 10.11
applications
account provisioning, 10.11.2.2
affects of, 10.11.2
database upgrades, 10.11.2.1
installation of, 10.11.2.3
script to create, 4.4.2
users
application developers, impact, 10.11.3.2
client-server applications, impact, 10.11.3.3
general users, impact, 10.11.3.1
how affects, 10.11.3
why changed, 10.11.1
CONNECT role, privilege available to, 4.4.1.1
connection pooling
about, 3.9
global application contexts, 6.4.1
nondatabase users, 6.4.3.6
proxy authentication, 3.10.1.5
connections
SYS privilege, 10.3
CPU time limit, 2.4.2.3
CREATE ANY PROCEDURE system privilege, 4.5.6.5
CREATE ANY TABLE statement
non-administrative users, 10.3
CREATE CONTEXT statement
about, 6.3.2
example, 6.3.2
CREATE PROCEDURE system privilege, 4.5.6.5
CREATE PROFILE statement
account locking period, 3.2.3.5
failed login attempts, 3.2.3.5
password aging and expiration, 3.2.3.7
password management, 3.2.3.1
passwords, example, 3.2.3.7
CREATE ROLE statement
IDENTIFIED EXTERNALLY option, 4.4.4.3
CREATE SCHEMA statement
securing, 5.7.1
CREATE SESSION statement, 4.4.1.1
CONNECT role privilege, 10.4
securing, 5.7.1
CREATE USER statement
explicit account locking, 3.2.3.5
IDENTIFIED BY option, 2.2.3
IDENTIFIED EXTERNALLY option, 2.2.3
passwords, expiring, 3.2.3.7
user profile, 3.2.3.1
CSW_USR_ROLE role, 4.4.2
CTXAPP role, 4.4.2
cursors
reparsing, for application contexts, 6.3.4
shared, used with Virtual Private Database, 7.1.4
custom installation, 10.8, 10.8
CWM_USER role, 4.4.2

D

data definition language (DDL)
roles and privileges, 4.4.1.6
standard auditing, 9.3.7.2
data dictionary
protecting, 10.6
securing with O7_DICTIONARY_ACCESSIBILITY, 4.3.2.1
data dictionary views
See views
data files, 10.6
guidelines for security, 10.6
data manipulation language (DML)
privileges controlling, 4.5.4.1
standard auditing, 9.3.7.2
data security
encryption, problems not solved by, 8.1.3
database administrators (DBAs)
access, controlling, 8.1.2
authentication, 3.3
malicious, encryption not solved by, 8.1.2
database audit trail
audited actions in common with operating system audit trail, 9.3.3
batch size for records during purging, 9.9.3.6
protecting, 9.1.3
tablespace, moving to one other than SYSTEM, 9.8.2.3
Database Configuration Assistant (DBCA)
default passwords, changing, 10.5
user accounts, automatically locking and expiring, 10.3
database links
application context support, 6.3.6
application contexts, 6.3.3.5
auditing, 9.3.10.2
authenticating with Kerberos, 3.6.2
authenticating with third-party services, 3.6.2
global user authentication, 3.7.2
object privileges, 4.5.3
operating system accounts, care needed, 3.5
session-based application contexts, accessing, 6.3.3.5
database session-based application contexts
about, 6.3.1
cleaning up after user exits, 6.3.1
components, 6.3.1
creating, 6.3.2
database links, 6.3.3.5
dynamic SQL, 6.3.3.3
externalized, using, 6.3.8
how to use, 6.3
initializing externally, 6.3.6
initializing globally, 6.3.7.1
ownership, 6.3.2
parallel queries, 6.3.3.4
PL/SQL package creation, 6.3.3
session information, setting, 6.3.3.6
SYS_CONTEXT function, 6.3.3.2
trusted procedure, 6.1.2
tutorial, 6.3.5.1
See also application contexts
database upgrades and CONNECT role, 10.11.2.1
databases
access control
password encryption, 3.2.1
additional security resources, 1.2
authentication, 3.4
database user and application user, 5.2.1
default audit settings
about, 9.4.1
DBCA-created databases, 9.4.1
manually-created databases, 9.4.1
default password security settings, 3.2.3.4
DBCA-created databases, 3.2.3.4
manually-created databases, 3.2.3.4
default security features, summary, 1.1
granting privileges, 4.6
granting roles, 4.6
limitations on usage, 2.4.1
read-only mode, starting in, 9.3.2.2
security and schemas, 5.7
security embedded, advantages of, 5.2.2
security policies based on, 7.1.2.1
DATAPUMP_EXP_FULL_DATABASE role, 4.4.2
DATAPUMP_IMP_FULL_DATABASE role, 4.4.2
DB_EXTENDED setting in AUDIT_TRAIL initialization parameter, Preface
DBA role
about, 4.4.2
DBA_NETWORK_ACL_PRIVILEGES view, 4.11.10
DBA_ROLE_PRIVS view
application privileges, finding, 5.4
DBMS_APPLICATION.SET_CLIENT_INFO procedure
DBMS_SESSION.SET_IDENTIFIER value, overwriting, 3.10.2.4
DBMS_CRYPTO package
about, 8.3
encryption algorithms supported, 8.3
examples, 8.5.1
DBMS_FGA package
about, 9.5.8.1
ADD_POLICY procedure, 9.5.8.2
DISABLE_POLICY procedure, 9.5.8.3
DROP_POLICY procedure, 9.5.8.4
ENABLE_POLICY procedure, 9.5.8.3
DBMS_OBFUSCATION_TOOLKIT package
backward compatibility, 8.3
See also DBMS_CRYPTO package
DBMS_RLS package
about, 7.3.1
DBMS_RLS.ADD_CONTEXT procedure, 7.3.1
DBMS_RLS.ADD_GROUPED_POLICY procedure, 7.3.1
DBMS_RLS.ADD_POLICY
sec_relevant_cols parameter, 7.3.4.1
sec_relevant_cols_opt parameter, 7.3.4.3
DBMS_RLS.ADD_POLICY procedure
about, 7.3.1
DBMS_RLS.CREATE_POLICY_GROUP procedure, 7.3.1
DBMS_RLS.DELETE_POLICY_GROUPS procedure, 7.3.1
DBMS_RLS.DISABLE_GROUPED_POLICY procedure, 7.3.1
DBMS_RLS.DROP_CONTEXT procedure, 7.3.1
DBMS_RLS.DROP_GROUPED_POLICY procedure, 7.3.1
DBMS_RLS.DROP_POLICY procedure, 7.3.1
DBMS_RLS.ENABLE_GROUPED_POLICY procedure, 7.3.1
DBMS_RLS.ENABLE_POLICY procedure, 7.3.1
DBMS_RLS.REFRESH_GROUPED_POLICY procedure, 7.3.1
DBMS_RLS.REFRESH_POLICY procedure, 7.3.1
DBMS_SESSION package
client identifiers, using, 3.10.2.4
global application context, used in, 6.4.3
SET_CONTEXT procedure
about, 6.3.3.6
application context name-value pair, setting, 6.3.3.1
DBMS_SESSION.SET_CONTEXT procedure
about, 6.3.3.6
syntax, 6.3.3.6
username and client_id settings, 6.4.3.3
DBMS_SESSION.SET_IDENTIFIER procedure
client session ID, setting, 6.4.1
DBMS_APPLICATION.SET_CLIENT_INFO value, overwritten by, 3.10.2.4
DBMS_SQLHASH encryption package
about, 8.4.1
GETHASH function, 8.4.2
DBSNMP user account
password usage, 10.5
DDL
See data definition language
default passwords, 10.5, 10.5, 10.5, 10.5
change_on_install or manager passwords, 10.5
changing, importance of, 3.2.3.2
finding, 3.2.3.2
default permissions, 10.6
default profiles
about, 3.2.3.3
default roles
setting for user, 2.2.8
specifying, 4.10.2
default users
accounts, 10.3, 10.3
Enterprise Manager accounts, 10.3
passwords, 10.5
defaults
tablespace quota, 2.2.5
user tablespaces, 2.2.4
definer's rights
about, 4.5.6.3
procedure privileges, used with, 4.5.6.3
procedure security, 4.5.6.3
secure application roles, 5.5.2
used with Oracle Virtual Private Database functions, 7.1.3
DELETE privilege
SQL statements permitted, 5.8.2
DELETE_CATALOG_ROLE role
about, 4.4.2
SYS schema objects, enabling access to, 4.3.2.2
denial-of-service (DoS) attacks
bad packets, preventing, 5.9.1
networks, securing, 10.9.2
denial-of-service attacks
about, Glossary
denial-of-service(DoS) attacks
audit trail, writing to operating system file, 9.3.4.3
deprecated security features, Preface
dictionary protection mechanism, 4.3.2.1
directory authentication, configuring for SYSDBA or SYSOPER access, 3.3.1.1
directory object auditing
configuring, 9.3.11.2
removing, 9.3.11.3
directory objects
auditing, 9.3.11.1
granting EXECUTE privilege on, 4.6.1
directory-based services authentication, 3.6.2
disabling unnecessary services
FTP, TFTP, TELNET, 10.9.2
dispatcher processes (Dnnn)
limiting SGA space for each session, 2.4.2.5
distributed databases
auditing and, 9.1.6
DML
See data manipulation language
driving context, 6.6
DROP PROFILE statement
example, 2.4.4.2
DROP ROLE statement
example, 4.4.6
security domain, affected, 4.4.6
DROP USER statement
about, 2.5
schema objects of dropped user, 2.5
DUAL table
about, 6.3.3.2
dynamic Oracle Virtual Private Database policy types, 7.3.6.2
DYNAMIC policy type, 7.3.6.2

E

editions
application contexts, how affects, 6.1.5
fine-grained auditing packages, results in, 6.4.3.2
global application contexts, how affects, 6.4.3.2
Oracle Virtual Private Database packages, results in, 6.4.3.2
EJBCLIENT role, 4.4.2
e-mail alert example, 9.5.9.1
encryption
access control, 8.1.1
backup media, reason why to encrypt, 3.2.4
BLOBS, 8.2.6
challenges, 8.2
data security, problems not solved by, 8.1.3
data transfer, 10.9.2
DBMS_CRYPTO package, 8.3, 8.3
deleted encrypted data, 10.6
examples, 8.5.1
finding information about, 8.6
indexed data, 8.2.1
key generation, 8.2.2
key storage, 8.2.4
key transmission, 8.2.3
keys, changing, 8.2.5
malicious database administrators, 8.1.2
network traffic, 10.9.2
problems not solved by, 8.1
transparent data encryption, 8.2.4.4
transparent tablespace encryption, 8.2.4.4
enterprise directory service, 4.4.4.4
Enterprise Edition, 10.5
Enterprise Manager
granting roles, 4.4.5
statistics monitor, 2.4.3
enterprise roles, 3.7, 4.4.4.4
enterprise user management, 5.2.1
Enterprise User Security
application context, globally initialized, 6.3.7.3
proxy authentication
Oracle Virtual Private Database, how it works with, 7.5.8
enterprise users
centralized management, 3.7
global role, creating, 4.4.4.4
One Big Application User authentication, compromised by, 5.2.1
proxy authentication, 3.10.1
shared schemas, protecting users, 5.7.2
errors
ORA-01720, 4.5.5.2
ORA-06512, 9.5.9.6
ORA-24247, 4.11.3, 9.5.9.6
ORA-28009, 4.3.2.1
ORA-28031, 4.10.2
ORA-28040, 3.4.1
ORA-28132, Preface
examples
access control lists
external network connections, 4.11.6
wallet access, 4.11.6
account locking, 3.2.3.5
audit trail, purging, 9.9.7
audit trigger to record before-and-after values, 9.7
data encryption
encrypting and decrypting BLOB data, 8.5.3
encrypting and decrypting procedure with AES 256-Bit, 8.5.2
directory objects, granting EXECUTE privilege on, 4.6.1
encrypting procedure, 8.5.1
Java code to read passwords, 5.3.4
locking an account with CREATE PROFILE, 3.2.3.5
login attempt grace period, 3.2.3.7
nondatabase user authentication, 6.4.3.6
O7_DICTIONARY_ACCESSIBILITY initialization parameter, setting, 4.3.2.1
passwords
aging and expiration, 3.2.3.7
changing, 2.3.1
creating for user, 2.2.3
privileges
granting ADMIN OPTION, 4.6.1.1
views, 4.12
procedure privileges affecting packages, 4.5.6.7, 4.5.6.7
profiles, assigning to user, 2.2.7
roles
altering for external authorization, 4.4.3
creating for application authorization, 4.4.4.2
creating for external authorization, 4.4.4.3
creating for password authorization, 4.4.3
default, setting, 4.10.2
using SET ROLE for password-authenticated roles, 4.4.4.1
views, 4.12
secure external password store, 3.2.5.2
session ID of user
finding, 2.5
terminating, 2.5
system privilege and role, granting, 4.6.1
tablespaces
assigning default to user, 2.2.4
quota, assigning to user, 2.2.5
temporary, 2.2.6
type creation, 4.5.7.5
users
account creation, 2.2.1
creating with GRANT statement, 4.6.1.2
dropping, 2.5
middle-tier server proxying a client, 3.10.1.3
naming, 2.2.2
object privileges granted to, 4.6.2
proxy user, connecting as, 3.10.1.3
See also tutorials
exceptions
WHEN NO DATA FOUND, used in application context package, 6.3.5.4
WHEN OTHERS, used in triggers
development environment (debugging) example, 6.3.4
production environment example, 6.3.4
exclusive mode
SHA-1 password hashing algorithm, enabling, 3.2.4
EXECUTE privilege
SQL statements permitted, 5.8.2
EXECUTE_CATALOG_ROLE role
about, 4.4.2
SYS schema objects, enabling access to, 4.3.2.2
execution time for statements, measuring, 7.3.6.2
EXEMPT ACCESS POLICY privilege
Oracle Virtual Private Database enforcements, exemption, 7.5.7.2
EXP_FULL_DATABASE role
about, 4.4.2
expiring a password
explicitly, 3.2.3.7
exporting data
direct path export impact on Oracle Virtual Private Database, 7.5.7.2
policy enforcement, 7.5.7.2
external authentication
about, 3.8.1
advantages, 3.8.2
network, 3.8.5
operating system, 3.8.4, 3.8.4
user creation, 3.8.3
external network services, fine-grained access to
See access control list (ACL)
external tables, 10.6

F

failed login attempts
account locking, 3.2.3.5
password management, 3.2.3.5
resetting, 3.2.3.5
features, new security
See new features, security
files
adx_SID.txt
about, 9.3.2.2
BFILEs
operating system access, restricting, 10.6
BLOB, 8.2.6
data
operating system access, restricting, 10.6
external tables
operating system access, restricting, 10.6
keys, 8.2.4.2
listener.ora file
guidelines for security, 10.9.2, 10.9.3
log
audit file location for Windows, 9.6.2
audit file locations, 9.3.4.5
operating system access, restricting, 10.6
restrict listener access, 10.9.2
server.key encryption file, 10.9.3
symbolic links, restricting, 10.6
tnsnames.ora, 10.9.3
trace
operating system access, restricting, 10.6
fine-grained access control
See Oracle Virtual Private Database (VPD)
fine-grained auditing
about, 9.5.1
activities always recorded, 9.5.4
advantages, 9.5.2, 9.5.2
alerts, adding to policy, 9.5.9.1
archiving audit trail, 9.8.2.5
columns, specific, 9.5.8.2
creating audit trail for, 9.5.6
DBMS_FGA package, 9.5.8.1
edition-based redefinitions, 9.5.5
editions, results in, 6.4.3.2
finding errors by checking trace files, 9.10
how audit records are generated, 9.5.7
how to use, 9.5.1
non-SYS activities audited, 9.1.4
policies
adding, 9.5.8.2
disabling, 9.5.8.3
dropping, 9.5.8.4
enabling, 9.5.8.3
modifying, 9.5.8.2
where created, 9.5.8.2
privileges needed, 9.5.3
records
archiving, 9.8.2.5
See also SYS.FGA_LOG$ table
firewalls
advice about using, 10.9.2
database server location, 10.9.2
ports, 10.9.3
supported types, 10.9.2
flashback query
auditing, used with, 9.8.2.1
Oracle Virtual Private Database, how it works with, 7.5.6
foreign keys
privilege to use parent key, 4.5.4.2
FTP service, 10.9.2
functions
auditing, 9.3.12.1
Oracle Virtual Private Database
components of, 7.2.1
privileges used to run, 7.1.3
privileges for, 4.5.6.1
roles, 4.4.1.5

G

GATHER_SYSTEM_STATISTICS role, 4.4.2
global application contexts
about, 6.4.1
authenticating nondatabase users, 6.4.3.6
components, 6.4.1
editions, affect on, 6.4.3.2
example of authenticating nondatabase users, 6.4.3.6
example of authenticating user moving to different application, 6.4.3.5
example of setting values for all users, 6.4.3.4
Oracle RAC instances, 6.4.1
ownership, 6.4.2
PL/SQL package creation, 6.4.3.1
process, lightweight users, 6.4.6.2
process, standard, 6.4.6.1
sharing values globally for all users, 6.4.3.4
system global area, 6.4.1
tutorial for client session IDs, 6.4.5.1
used for One Big Application User scenarios, 7.5.8
user name retrieval with USER function, 6.4.3.3
uses for, 7.5.8
See also application contexts
global authentication
about, 3.7
advantages, 3.7.2
user creation for private schemas, 3.7.1.1
user creation for shared schemas, 3.7.1.2
global authorization
about, 3.7
advantages, 3.7.2
role creation, 4.4.4.4
roles, 3.7
global roles
about, 4.4.4.4
global users, 3.7
GLOBAL_AQ_USER_ROLE role, 4.4.2
grace period for login attempts
example, 3.2.3.7
grace period for password expiration, 3.2.3.7
GRANT ALL PRIVILEGES statement
SELECT ANY DICTIONARY privilege, exclusion of, 10.6
GRANT ANY OBJECT PRIVILEGE system privilege, 4.6.2.2, 4.7.2.1
GRANT ANY PRIVILEGE system privilege, 4.3.4
GRANT CONNECT THROUGH clause
consideration when setting FAILED_LOGIN_ATTEMPTS parameter, 3.2.3.3
for proxy authorization, 3.10.1.3
GRANT statement, 4.6.1
ADMIN OPTION, 4.6.1.1
creating a new user, 4.6.1.2
object privileges, 4.6.2, 5.8.1
system privileges and roles, 4.6
when takes effect, 4.10
WITH GRANT OPTION, 4.6.2.1
granting privileges and roles
about, 4.3.3
finding information about, 4.12
specifying ALL, 4.5.2
guidelines for security
auditing, 10.10
custom installation, 10.8, 10.8
data files and directories, 10.6
encrypting sensitive data, 10.6
installation and configuration, 10.8
networking security, 10.9
operating system accounts, limiting privileges, 10.6
operating system users, limiting number of, 10.6
Oracle home default permissions, disallowing modification, 10.6
ORACLE_DATAPUMP access driver, 10.7
passwords, 10.5
Secure Sockets Layer
mode, 10.9.3
TCPS protocol, 10.9.3
symbolic links, restricting, 10.6
user accounts and privileges, 10.3

H

hackers
See security attacks
HS_ADMIN_EXECUTE_ROLE role
about, 4.4.2
HS_ADMIN_ROLE role
about, 4.4.2
HS_ADMIN_SELECT_ROLE role
about, 4.4.2
HTTP authentication
See access control lists (ACL), wallet access
HTTPS
port, correct running on, 10.9.3

I

IMP_FULL_DATABASE role
about, 4.4.2
INDEX privilege
SQL statements permitted, 5.8.2
indexed data
encryption, 8.2.1
indirectly granted roles, 4.4.1.1
initialization parameters
application protection, 5.9
AUDIT_FILE_DEST, 9.1.5, 9.6.2
AUDIT_SYS_OPERATIONS, 9.6.2
AUDIT_SYSLOG_LEVEL, 9.3.5.4
AUDIT_TRAIL
about, 9.3.2.1
using, 9.3.2.2
current value, checking, 9.3.2.1
FAILED_LOGIN_ATTEMPTS, 3.2.3.3
MAX_ENABLED_ROLES, 4.10.3
O7_DICTIONARY_ACCESSIBILITY, 4.3.2.1
OS_AUTHENT_PREFIX, 3.8.1
OS_ROLES, 4.4.4.3.1
PASSWORD_GRACE_TIME, 3.2.3.3, 3.2.3.7
PASSWORD_LIFE_TIME, 3.2.3.3, 3.2.3.7
PASSWORD_LOCK_TIME, 3.2.3.3, 3.2.3.5
PASSWORD_REUSE_MAX, 3.2.3.3, 3.2.3.6
PASSWORD_REUSE_TIME, 3.2.3.3, 3.2.3.6
REMOTE_OS_AUTHENT, 10.9.1
RESOURCE_LIMIT, 2.4.4
SEC_CASE_SENSITIVE_LOGIN, 3.2.3.9
SEC_MAX_FAILED_LOGIN_ATTEMPTS, 5.9.3
SEC_PROTOCOL_ERROR_FURTHER_ACTION, 5.9.2
SEC_PROTOCOL_ERROR_TRACE_ACTION, 5.9.1
SEC_RETURN_SERVER_RELEASE_BANNER, 5.9.4
SEC_USER_AUDIT_ACTION_BANNER, 5.9.5
SEC_USER_UNAUTHORIZED_ACCESS_BANNER, 5.9.5
INSERT privilege
granting, 4.6.2.3
revoking, 4.7.2.2
SQL statements permitted, 5.8.2
installation
guidelines for security, 10.8
intruders
See security attacks
invoker's rights
about, 4.5.6.4
procedure privileges, used with, 4.5.6.3
procedure security, 4.5.6.4
secure application roles, 5.5.2
secure application roles, requirement for enabling, 5.5.2
IP addresses
falsifying, 10.9.2

J

JAVA_ADMIN role, 4.4.2
JAVA_DEPLOY role, 4.4.2
JAVADEBUGPRIV role, 4.4.2
JAVAIDPRIV role, 4.4.2
JAVASYSPRIV role, 4.4.2
JAVAUSERPRIV role, 4.4.2
JDBC connections
JDBC Thin Driver proxy authentication
configuring, 3.10.1
with real user, 3.10.1.5
JDBC/OCI proxy authentication, 3.10.1
multiple user sessions, 3.10.1.5
Oracle Virtual Private Database, 7.5.8
JMXSERVER role, 4.4.2

K

Kerberos authentication, 3.6.2
configuring for SYSDBA or SYSOPER access, 3.3.1.2
password management, 10.5
key generation
encryption, 8.2.2
key storage
encryption, 8.2.4
key transmission
encryption, 8.2.3

L

LBAC_DBA role, 4.4.2
least privilege principle, 10.3
about, 10.3
granting user privileges, 10.3
middle-tier privileges, 3.10.1.6
lightweight users
example using a global application context, 6.4.5.1
Lightweight Directory Access Protocol (LDAP), 7.4.2.8
listener
not an Oracle owner, 10.9.2
preventing online administration, 10.9.2
restrict privileges, 10.9.2, 10.9.2
secure administration, 10.9.2
listener.ora file
administering remotely, 10.9.2, 10.9.2
default location, 10.9.3
online administration, preventing, 10.9.2
TCPS, securing, 10.9.3
LOBS
auditing, 9.5.2
lock and expire
default accounts, 10.3
predefined user accounts, 10.3
log files
auditing, default location, 9.3.4.5
owned by trusted user, 10.6
Windows Event Viewer, 9.6.2
logical reads limit, 2.4.2.4
logon triggers
auditing current session, 9.3.7.3
examples, 6.3.4
externally initialized application contexts, 6.3.4
secure application roles, 4.4.8
LOGSTDBY_ADMINISTRATOR role, 4.4.2

M

malicious database administrators
See also security attacks
manager default password, 10.5
mandatory auditing
about, 9.1.5
syslog, written to, 9.1.5
memory
users, viewing, 2.6.5
MERGE INTO statement, affected by DBMS_RLS.ADD_POLICY statement_types parameter, 7.3.3
methods
privileges on, 4.5.7
MGMT_USER role, 4.4.2
middle-tier systems
auditing real user actions, 3.10.1.10
client identifiers, 3.10.2.1
enterprise user connections, 3.10.1.9.2
password-based proxy authentication, 3.10.1.9.1
privileges, limiting, 3.10.1.6
proxies authenticating users, 3.10.1.7
proxying but not authenticating users, 3.10.1.8
reauthenticating user to database, 3.10.1.9
USERENV namespace attributes, accessing, 6.3.6.3
monitoring user actions
See also auditing, standard auditing, fine-grained auditing
multiplex multiple-client network sessions, 10.9.2
My Oracle Support
security patches, downloading, 10.2.1

N

Net8
See Oracle Net
network auditing
about, 9.3.13.1
removing, 9.3.13.3
network authentication
external authentication, 3.8.5
guidelines for securing, 10.5
roles, granting using, 4.9
Secure Sockets Layer, 3.6.1
smart cards, 10.5
third-party services, 3.6.2
token cards, 10.5
X.509 certificates, 10.5
network connections
denial-of-service (DoS) attacks, addressing, 10.9.2
guidelines for security, 10.9, 10.9.1, 10.9.2
securing, 10.9.2
network IP addresses
guidelines for security, 10.9.2
new features, security, Preface
NOAUDIT statement
audit options, removing, 9.3.6.7
default object audit options, disabling, 9.3.10.6
network auditing, removing, 9.3.13.3
object auditing, removing, 9.3.10.6
privilege auditing, removing, 9.3.8.4
statement auditing, removing, 9.3.7.4, 9.3.7.4
nondatabase users
about, 6.4.1
audit record information, 9.8.1
auditing, 9.5.10.1
clearing session data, 6.4.3.7
creating client session-based application contexts, 6.5.1
global application contexts
package example, 6.4.3.6
reason for using, 6.4.1
setting, 6.4.3.6
tutorial, 6.4.5.1
One Big Application User authentication
about, 7.5.8
features compromised by, 5.2.1
security risks, 5.2.1
Oracle Virtual Private Database
how it works with, 7.5.8
tutorial for creating a policy group, 7.4.3.1
See also application contexts, client identifiers

O

O7_DICTIONARY_ACCESSIBILITY initialization parameter
about, 4.3.2.1
auditing privileges on SYS objects, 9.1.3, 9.3.1.2
data dictionary protection, 10.6
default setting, 10.6
securing data dictionary with, 4.3.2.1
object columns
auditing, 9.5.2
object privileges, 10.3
about, 4.5.3
granting on behalf of the owner, 4.6.2.2
managing, 5.8
revoking, 4.7.2
revoking on behalf of owner, 4.7.2.1
schema object privileges, 4.5.3
See also schema object privileges
objects
applications, managing privileges in, 5.8
granting privileges, 5.8.2
privileges
applications, 5.8.1
managing, 4.5.7
protecting in shared schemas, 5.7.2
protecting in unique schemas, 5.7.1
SYS schema, access to, 4.3.2.2
OEM_ADVISOR role, 4.4.2
OEM_MONITOR role, 4.4.2
OLAP_DBA role, 4.4.2
OLAP_USER role, 4.4.2
OLAP_XS_ADMIN role, 4.4.2
OLAPI_TRACE_USER role, 4.4.2
One Big Application User authentication
See nondatabase users
operating system audit trail
age, controlling, 9.8.3.3
audited actions in common with database audit trail, 9.3.3
size, controlling, 9.8.3.2
operating systems
accounts, 4.9.2
authentication
about, 3.5
advantages, 3.5
disadvantages, 3.5
roles, using, 4.9
authentication, external, 3.8.4
default permissions, 10.6
enabling and disabling roles, 4.9.5
operating system account privileges, limiting, 10.6
role identification, 4.9.2
roles and, 4.4.1.7
roles, granting using, 4.9
users, limiting number of, 10.6
ORA-01720 error, 4.5.5.2
ORA-06512 error, 9.5.9.6
ORA-1536 error, 2.2.5.1
ORA-24247 error, 4.11.3, 9.5.9.6
ORA-28009 error, 4.3.2.1
ORA-28031 error, 4.10.2
ORA-28040 error, 3.4.1
ORA-28132 error, Preface
Oracle Advanced Security
network authentication services, 10.5
network traffic encryption, 10.9.2
user access to application schemas, 5.7.2
Oracle Call Interface (OCI)
application contexts, client session-based, 6.5.1
proxy authentication, 3.10.1
Oracle Virtual Private Database, how it works with, 7.5.8
proxy authentication with real user, 3.10.1.5
security-related initialization parameters, 5.9
Oracle Connection Manager
securing client networks with, 10.9.2
Oracle Enterprise Security Manager
role management with, 3.6.2
Oracle home
default permissions, disallowing modification, 10.6
Oracle Internet Directory (OID)
authenticating with directory-based service, 3.6.2
SYSDBA and SYSOPER access, controlling, 3.3.1
Oracle Java Virtual Machine (OJVM)
permissions, restricting, 10.3
Oracle Label Security (OLS)
Oracle Virtual Private Database, using with, 7.5.7.1
Oracle Net
firewall support, 10.9.2
Oracle Real Application Clusters
archive timestamp for audit records, 9.9.3.4
global contexts, 6.4.1
Oracle Technology Network
security alerts, 10.2.1
Oracle Virtual Private Database
edition-based redefinitions, 7.5.1
Oracle Virtual Private Database (VPD)
about, 7.1.1
ANSI operations, 7.5.3
application contexts
tutorial, 7.4.2.1
used with, 7.1.4
applications
how it works with, 7.5.4
users who are database users, how it works with, 7.5.8
applications using for security, 5.2.2
automatic reparsing, how it works with, 7.5.5
benefits, 7.1.2
column level, 7.3.4.1
column masking behavior
enabling, 7.3.4.3
restrictions, 7.3.4.3
column-level display, 7.3.4.1
components, 7.2
configuring, 7.3
cursors, shared, 7.1.4
editions, results in, 6.4.3.2
Enterprise User Security proxy authentication, how it works with, 7.5.8
exporting data, 7.5.7.2
finding information about, 7.6
flashback query, how it works with, 7.5.6
function
auditing, 9.3.10.2
components, 7.2.1
how it is executed, 7.1.3
JDBC proxy authentication, how it works with, 7.5.8
MERGE INTO, ORA-28132 error, Preface
nondatabase user applications, how works with, 7.5.8
OCI proxy authentication, how it works with, 7.5.8
Oracle Label Security
exceptions in behavior, 7.5.7.2
using with, 7.5.7.1
outer join operations, 7.5.3
performance benefit, 7.1.2.2
policies, Oracle Virtual Private Database
about, 7.3.1
applications, validating, 7.3.5.5
attaching to database object, 7.3.2
column display, 7.3.4.1
column-level display, default, 7.3.4.2
dynamic, 7.3.6.2
multiple, 7.3.5.4
optimizing performance, 7.3.6.1
privileges used to run, 7.1.3
SQL statements, specifying, 7.3.3
policy groups
about, 7.3.5.1
benefits, 7.3.5.1
creating, 7.3.5.2
default, 7.3.5.3
tutorial, implementation, 7.4.3.1
policy types
context sensitive, about, 7.3.6.6
context sensitive, when to use, 7.3.6.8
context-sensitive, audited, 9.3.12.1
DYNAMIC, 7.3.6.2
dynamic, audited, 9.3.12.1
shared context sensitive, about, 7.3.6.7
shared context sensitive, when to use, 7.3.6.8
shared static, about, 7.3.6.4
shared static, when to use, 7.3.6.5
static, about, 7.3.6.3
static, audited, 9.3.12.1
static, when to use, 7.3.6.5
summary of features, 7.3.6.9
SELECT FOR UPDATE statements in policies, 7.5.2
tutorial, simple, 7.4.1.1
user models, 7.5.8
Web-based applications, how it works with, 7.5.8
Oracle Wallet Manager
X.509 Version 3 certificates, 3.6.2
Oracle wallets
authentication method, 3.6.2
Oracle Warehouse Builder
roles, predefined, 4.4.2
ORACLE_DATAPUMP access driver
guidelines for security, 10.7
OracleMetaLink
See My Oracle Support
ORAPWD password utility
case sensitivity in passwords, 3.2.3.9
password file authentication, 3.3.3
permissions to run, 3.3.3
ORDADMIN role, 4.4.2
OS_ROLES initialization parameter
operating system role grants, 4.9.5
operating-system authorization and, 4.4.4.3.1
REMOTE_OS_ROLES and, 4.9.6
using, 4.9.2
outer join operations
Oracle Virtual Private Database affect on, 7.5.3
OWB$CLIENT role, 4.4.2
OWB_DESIGNCENTER_VIEW role, 4.4.2
OWB_USER role, 4.4.2

P

packages
auditing, 9.3.12.1
examples, 4.5.6.7
examples of privilege use, 4.5.6.7
privileges
divided by construct, 4.5.6.7
executing, 4.5.6.1, 4.5.6.7
parallel execution servers, 6.3.3.4
parallel query, and SYS_CONTEXT, 6.3.3.4
pass phrase
read and parse server.key file, 10.9.3
password files
case sensitivity, effect on SEC_CASE_SENSITIVE_LOGON parameter, 3.2.3.9
how used to authenticate administrators, 3.3.3
PASSWORD statement
about, 2.3.1
PASSWORD_LIFE_TIME initialization parameter, 3.2.3.7
PASSWORD_LOCK_TIME initialization parameter, 3.2.3.5
PASSWORD_REUSE_MAX initialization parameter, 3.2.3.6
PASSWORD_REUSE_TIME initialization parameter, 3.2.3.6
passwords
about managing, 3.2.3.1
account locking, 3.2.3.5, 3.2.3.5
administrator
authenticating with, 3.3.3
guidelines for securing, 10.5
aging and expiration, 3.2.3.7
ALTER PROFILE statement, 3.2.3.1
altering, 2.3.1
application design guidelines, 5.3.1.2
applications, strategies for protecting passwords, 5.3
brute force attacks, 3.2.1
case sensitivity setting, SEC_CASE_SENSITIVE_LOGIN, 3.2.3.9
case sensitivity, configuring, 3.2.3.9
changing for roles, 4.4.3
complexity verification
about, 3.2.3.8
guidelines for security, 10.5
complexity, guidelines for enforcing, 10.5
connecting without, 3.5
CREATE PROFILE statement, 3.2.3.1
danger in storing as clear text, 10.5
database user authentication, 3.4.1
default profile settings
about, 3.2.3.3
default user account, 10.5
default, finding, 3.2.3.2
delays for incorrect passwords, 3.2.1
duration, 10.5
encrypting, 3.2.1, 10.5
examples of creating, 3.2.2
expiring
explicitly, 3.2.3.7
procedure for, 3.2.3.7
proxy account passwords, 3.10.1.3
with grace period, 3.2.3.7
failed logins, resetting, 3.2.3.5
grace period, example, 3.2.3.7
guidelines for security, 10.5
history, 3.2.3.6, 3.2.3.6, 10.5
Java code example to read passwords, 5.3.4
length, 10.5
lifetime for, 3.2.3.7
lock time, 3.2.3.5
management rules, 10.5
managing, 3.2.3
maximum reuse time, 3.2.3.6
ORAPWD password utility, 3.2.3.9
password complexity verification, 3.2.3.8
password file risks, 3.3.3
PASSWORD_LOCK_TIME initialization parameter, 3.2.3.5
PASSWORD_REUSE_MAX initialization parameter, 3.2.3.6
PASSWORD_REUSE_TIME initialization parameter, 3.2.3.6
policies, 3.2.3
privileges for changing for roles, 4.4.3
privileges to alter, 2.3
protections, built-in, 3.2.1
proxy authentication, 3.10.1.9.1
requirements, 3.2.2
reusing, 3.2.3.6, 10.5
reusing passwords, 3.2.3.6
roles authenticated by passwords, 4.4.3
roles enabled by SET ROLE statement, 4.4.4.1
secure external password store, 3.2.5.1
security risks, 3.3.3
SYS and SYSTEM, 10.5, 10.5
used in roles, 4.4.1.2
UTLPWDMG.SQL password script
password management, 3.2.3.8
verified using SHA-1 hashing algorithm, 3.2.4, 3.2.4
See also authentication, and access control list (ACL), wallet access
performance
application contexts, 6.1.3
auditing, 9.1.7
database audit trail, moving to different tablespace, 9.8.2.3
Oracle Virtual Private Database policies, 7.1.2.2
Oracle Virtual Private Database policy types, 7.3.6.1
resource limits and, 2.4.1
permissions
default, 10.6
run-time facilities, 10.3
PKI
See public key infrastructure (PKI)
PL/SQL
auditing of statements within, 9.3.1.3
roles in procedures, 4.4.1.5
PL/SQL functions
auditing, 9.3.12.2
PL/SQL packages
auditing, 9.3.12.1, 9.3.12.2
PL/SQL procedures
auditing, 9.3.12.2
setting application context, 6.3.3.1
PMON background process
application contexts, cleaning up, 6.3.1
positional parameters
security risks, 5.3.1.4
principle of least privilege, 10.3
about, 10.3
granting user privileges, 10.3
middle-tier privileges, 3.10.1.6
privileges
about, 4.1
access control lists, checking for external network services, 4.11.10
altering
passwords, 2.3.1
users, 2.3
altering role authentication method, 4.4.3
applications, managing, 5.4
audited when default auditing is enabled, 9.4.2
auditing use of, 9.3.8.1, 9.3.8.3
auditing, recommended settings for, 10.10.5
cascading revokes, 4.7.3
column, 4.6.2.3
compiling procedures, 4.5.6.6
creating or replacing procedures, 4.5.6.5
creating users, 2.2.1
dropping profiles, 2.4.4.2
finding information about, 4.12
granting
about, 4.3.3, 4.6
examples, 4.5.6.7, 4.5.6.7
object privileges, 4.5.3.1, 4.6.2
system, 4.6.1
system privileges, 4.6
grants, listing, 4.12.1
grouping with roles, 4.4
managing, 5.8
middle tier, 3.10.1.6
object, 4.5.1, 4.5.2, 5.8.2
granting and revoking, 4.5.3.1
on selected columns, 4.7.2.2
procedures, 4.5.6.1
creating and replacing, 4.5.6.5
executing, 4.5.6.1
in packages, 4.5.6.7
reasons to grant, 4.2
revoking privileges
about, 4.3.3
object, 4.7.2
object privileges, cascading effect, 4.7.3.2
object privileges, requirements for, 4.7.2
schema object, 4.5.3.1
revoking system privileges, 4.7.1
roles
creating, 4.4.3
dropping, 4.4.6
restrictions on, 4.4.1.6
roles, why better to grant, 4.2
schema object, 4.5.3
DML and DDL operations, 4.5.4
packages, 4.5.6.7
procedures, 4.5.6.1
SQL statements permitted, 5.8.2
system
granting and revoking, 4.3.3
SELECT ANY DICTIONARY, 10.6
SYSTEM and OBJECT, 10.3
system privileges
about, 4.3.1
trigger privileges, 4.5.6.3
used for Oracle Virtual Private Database policy functions, 7.1.3
view privileges
creating a view, 4.5.5.2
using a view, 4.5.5.3
views, 4.5.5.1
See also access control list (ACL) and system privileges.
procedures
auditing, 9.3.10.4, 9.3.12.1
compiling, 4.5.6.6
definer's rights
about, 4.5.6.3
roles disabled, 4.4.1.5.1
examples of, 4.5.6.7
examples of privilege use, 4.5.6.7
invoker's rights
about, 4.5.6.4
roles used, 4.4.1.5.2
privileges for procedures
create or replace, 4.5.6.5
executing, 4.5.6.1
executing in packages, 4.5.6.7
privileges required for, 4.5.6.5
security enhanced by, 4.5.6.3
process monitor process (PMON)
cleans up timed-out sessions, 2.4.2.5
PRODUCT_USER_PROFILE table, 4.4.7.2
SQL commands, disabling with, 4.4.7.2
products and options
install only as necessary, 10.8
profiles, 2.4.4
about, 2.4.4
creating, 2.4.4.1
dropping, 2.4.4.2, 2.4.4.2
finding information about, 2.6.1
managing, 2.4.4
password management, 3.2.3.1
privileges for dropping, 2.4.4.2
specifying for user, 2.2.7
viewing, 2.6.4
proxy authentication
about, 3.10.1, 3.10.1.1
advantages, 3.10.1.2
auditing actions on behalf of real user, 3.10.1.10
auditing operations, 3.9.1
auditing users, 9.3.9
client-to-middle tier sequence, 3.10.1.5
middle-tier
authorizing but not authenticating users, 3.10.1.8
authorizing to proxy and authenticate users, 3.10.1.7
limiting privileges, 3.10.1.6
reauthenticating users, 3.10.1.9
passwords, expired, 3.10.1.3
secure external password store, used with, 3.10.1.4
security benefits, 3.10.1.2
users, passing real identity of, 3.10.1.5
PROXY_USER attribute, 6.3.6.3
PROXY_USERS view, 3.10.1.3
pseudo columns
USER, 4.5.5.3
PUBLIC
procedures and, 4.8
user group, 4.8
public key infrastructure (PKI)
about, 3.6.2
PUBLIC user group
about, 4.4.1.4
granting and revoking privileges to, 4.8
security domain of users, 4.4.1.4
PUBLIC_DEFAULT profile
profiles, dropping, 2.4.4.2

Q

quotas
tablespace, 2.2.5
temporary segments and, 2.2.5
unlimited, 2.2.5.2
viewing, 2.6.3

R

RADIUS authentication, 3.6.2
read-only mode, affect on AUDIT_TRAIL parameter, 9.3.2.2
reads
limits on data blocks, 2.4.2.4
RECOVERY_CATALOG_OWNER role
about, 4.4.2
redo log files
auditing committed and rolled back transactions, 10.10.3
REFERENCES privilege
CASCADE CONSTRAINTS option, 4.7.2.3
revoking, 4.7.2.2, 4.7.2.3
SQL statements permitted, 5.8.2
remote authentication, 10.9.1, 10.9.1
REMOTE_OS_AUTHENT initialization parameter
guideline for securing, 10.9.1
setting, 3.8.4
remote_os_authentication, 10.9.1
REMOTE_OS_ROLES initialization parameter
OS role management risk on network, 4.9.6
setting, 4.4.4.3.2
resource limits
about, 2.4.1
call level, limiting, 2.4.2.2
connection time for each session, 2.4.2.5
CPU time, limiting, 2.4.2.3
determining values for, 2.4.3
idle time in each session, 2.4.2.5
logical reads, limiting, 2.4.2.4
private SGA space for each session, 2.4.2.5
profiles, 2.4.4, 2.4.4
session level, limiting, 2.4.2.1
sessions
concurrent for user, 2.4.2.5
elapsed connection time, 2.4.2.5
idle time, 2.4.2.5
SGA space, 2.4.2.5
types, 2.4.2
RESOURCE privilege
CREATE SCHEMA statement, needed for, 5.7.1
RESOURCE role, 4.5.7.1
about, 4.4.2
REVOKE CONNECT THROUGH clause
revoking proxy authorization, 3.10.1.3
REVOKE statement
system privileges and roles, 4.7.1
when takes effect, 4.10
revoking privileges and roles
cascading effects, 4.7.3
on selected columns, 4.7.2.2
REVOKE statement, 4.7.1
specifying ALL, 4.5.2
when using operating-system roles, 4.9.4
role identification
operating system accounts, 4.9.2
ROLE_SYS_PRIVS view
application privileges, 5.4
ROLE_TAB_PRIVS view
application privileges, finding, 5.4
roles
about, 4.1, 4.4.1
ADM_PARALLEL_EXECUTE_TASK role, 4.4.2
ADMIN OPTION and, 4.6.1.1
advantages in application use, 5.4
application, 4.4.1.3.1, 4.4.7, 5.6, 5.6, 5.8
application privileges, 5.4
applications, for user, 5.6
AQ_ADMINISTRATOR_ROLE role, 4.4.2
AQ_USER_ROLE role, 4.4.2
AUTHENTICATEDUSER role, 4.4.2
authorization, 4.4.4
authorized by enterprise directory service, 4.4.4.4
CAPI_USER_ROLE role, 4.4.2
changing authorization for, 4.4.3
changing passwords, 4.4.3
CONNECT, 4.4.1.1
CONNECT role
about, 4.4.2
create your own, 10.4
CSW_USR_ROLE role, 4.4.2
CTXAPP role, 4.4.2
CWM_USER role, 4.4.2
database role, users, 5.6.1
DATAPUMP_EXP_FULL_DATABASE role, 4.4.2
DATAPUMP_IMP_FULL_DATABASE role, 4.4.2
DBA role, 4.4.2
DDL statements and, 4.4.1.6
default, 4.10.2
default, setting for user, 2.2.8
definer's rights procedures disable, 4.4.1.5.1
DELETE_CATALOG_ROLE role, 4.4.2
dependency management in, 4.4.1.6
disabling, 4.10.1
dropping, 4.4.6
EJBCLIENT role, 4.4.2
enabled or disabled, 4.4.1.1, 4.4.5
enabling, 4.10.1, 5.6
enterprise, 3.7, 4.4.4.4
EXECUTE_CATALOG_ROLE role, 4.4.2
EXP_FULL_DATABASE role, 4.4.2
finding information about, 4.12
functionality, 4.2, 4.4.1.1
functionality of, 4.4.1.1
GATHER_SYSTEM_STATISTICS role, 4.4.2
global authorization, 4.4.4.4
about, 4.4.4.4
global roles
about, 3.7
creating, 4.4.4.4
external sources, and, 4.4.4.3
GLOBAL_AQ_USER_ROLE role, 4.4.2
GRANT statement, 4.9.5
granted to other roles, 4.4.1.1
granting roles
about, 4.6
methods for, 4.4.5
system, 4.6.1
system privileges, 4.3.3
guidelines for security, 10.4
HS_ADMIN_EXECUTE_ROLE role, 4.4.2
HS_ADMIN_ROLE role, 4.4.2
HS_ADMIN_SELECT_ROLE role, 4.4.2
IMP_FULL_DATABASE role, 4.4.2
in applications, 4.4.1.2
indirectly granted, 4.4.1.1
invoker's rights procedures use, 4.4.1.5.2
JAVA_ADMIN role, 4.4.2
JAVA_DEPLOY role, 4.4.2
JAVADEBUGPRIV role, 4.4.2
JAVAIDPRIV role, 4.4.2
JAVASYSPRIV role, 4.4.2
JAVAUSERPRIV role, 4.4.2
JMXSERVER role, 4.4.2
job responsibility privileges only, 10.4
LBAC_DBA role, 4.4.2
listing grants, 4.12.2
listing privileges and roles in, 4.12.6
listing roles, 4.12.5
LOGSTDBY_ADMINISTRATOR role, 4.4.2
management using the operating system, 4.9
managing roles
about, 4.4
categorizing users, 5.8
managing through operating system, 4.4.1.7
maximum number a user can enable, 4.10.3
MGMT_USER role, 4.4.2
multibyte characters in names, 4.4.3
multibyte characters in passwords, 4.4.4.1
naming, 4.4.1
network authorization, 4.4.4.3.2
network client authorization, 4.4.4.3.2
OEM_ADVISOR role, 4.4.2
OEM_MONITOR role, 4.4.2
OLAP_DBA role, 4.4.2
OLAP_USER role, 4.4.2
OLAP_XS_ADMIN role, 4.4.2
OLAPI_TRACE_USER role, 4.4.2
One Big Application User, compromised by, 5.2.1
operating system, 4.9.2
operating system authorization, 4.4.4.3.1
operating system granting of, 4.9.5
operating system identification of, 4.9.2
operating system management and the shared server, 4.9.6
operating system-managed, 4.9.3, 4.9.4
operating-system authorization, 4.4.4.3
ORDADMIN role, 4.4.2
OWB$CLIENT role, 4.4.2
OWB_DESIGNCENTER_VIEW role, 4.4.2
OWB_USER role, 4.4.2
predefined, 4.4.2
privileges for creating, 4.4.3
privileges for dropping, 4.4.6
privileges, changing authorization method for, 4.4.3
privileges, changing passwords, 4.4.3
RECOVERY_CATALOG_OWNER role, 4.4.2
RESOURCE role, 4.4.2
restricting from tool users, 4.4.7
restrictions on privileges of, 4.4.1.6
REVOKE statement, 4.9.5
revoking, 4.4.5, 4.7.1
revoking ADMIN option, 4.7.1
SCHEDULER_ADMIN role, 4.4.2
schemas do not contain, 4.4.1
security domains of, 4.4.1.4
SELECT_CATALOG_ROLE role, 4.4.2
SET ROLE statement, 4.9.5
setting in PL/SQL blocks, 4.4.1.5.2
SNMPAGENT role, 4.4.2
SPATIAL_CSW_ADMIN role, 4.4.2
SPATIAL_WFS_ADMIN role, 4.4.2
unique names for, 4.4.3
use of passwords with, 4.4.1.2
user, 4.4.1.3.2, 5.8
users capable of granting, 4.4.5.1
uses of, 4.4.1.1, 4.4.1.3
WFS_USR_ROLE role, 4.4.2
WITH GRANT OPTION and, 4.6.2.1
without authorization, 4.4.3
WKUSER role, Preface
WM_ADMIN_ROLE role, 4.4.2
XDB_SET_INVOKER roles, 4.4.2
XDB_WEBSERVICES role, 4.4.2
XDB_WEBSERVICES_OVER_HTTP role, 4.4.2
XDB_WEBSERVICES_WITH_PUBLIC role, 4.4.2
XDBADMIN role, 4.4.2
See also secure application roles
root file paths
for files and packages outside the database, 10.3
row-level security
See fine-grained access control, Oracle Virtual Private Database (VPD)
RSA private key, 10.9.3
run-time facilities, 10.3
restriction permissions, 10.3

S

Sample Schemas
remove or relock for production, 10.8
test database, 10.8
sample schemas, 10.8
Sarbanes-Oxley Act
auditing to meet compliance, 9.1.1
SCHEDULER_ADMIN role
about, 4.4.2
schema object auditing
enabling, 9.3.10.5
removing, 9.3.10.6
schema object privileges, 4.5.3
schema objects
audit options, removing, 9.3.10.6
auditing, 9.3.10.1
auditing procedures or functions, 9.3.10.5
cascading effects on revoking, 4.7.3.2
default audit options, 9.3.10.5
default tablespace for, 2.2.4
dropped users, owned by, 2.5
enabling audit options on, 9.3.10.5
granting privileges, 4.6.2
privileges
DML and DDL operations, 4.5.4
granting and revoking, 4.5.3.1
view privileges, 4.5.5.1
privileges on, 4.5.3
privileges to access, 4.5.2
privileges with, 4.5.2
removing audit options, 9.3.8.4
revoking privileges, 4.7.2
schema-independent users, 5.7.2
schemas
auditing, recommended settings for, 10.10.5
private, 3.7.1.1
shared among enterprise users, 3.7.1.2
shared, protecting objects in, 5.7.2
unique, 5.7
unique, protecting objects in, 5.7.1
SCOTT user account
restricting privileges of, 10.4
script files
audit trail views, removing, 9.10.3
CATNOAUD.SQL, 9.10.3
scripts, authenticating users in, 3.2.5.1
SEC_CASE_SENSITIVE_LOGIN initialization parameter, 3.2.3.9
SEC_MAX_FAILED_LOGIN_ATTEMPTS initialization parameter, 5.9.3
SEC_PROTOCOL_ERROR_FURTHER_ACTION initialization parameter, 5.9.2
SEC_PROTOCOL_ERROR_TRACE_ACTION initialization parameter, 5.9.1
sec_relevant_cols_opt parameter, 7.3.4.3
SEC_RETURN_SERVER_RELEASE_BANNER initialization parameter, 5.9.4
SEC_USER_AUDIT_ACTION_BANNER initialization parameter, 5.9.5
SEC_USER_UNAUTHORIZED_ACCESS_BANNER initialization parameter, 5.9.5
secconf.sql script
audit settings, 9.4.3
password settings, 3.2.3.4
secure application roles
about, 4.4.8
creating, 5.5.1
creating PL/SQL package, 5.5.2
finding with DBA_ROLES view, 4.12
invoker's rights, 5.5.2
invoker's rights requirement, 5.5.2
package for, 5.5.2
SET ROLE statement, 5.5.2
user environment information from SYS_CONTEXT SQL function, 5.5.2, 5.5.2
using to ensure database connection, 4.4.8
secure external password store
about, 3.2.5.1
client configuration, 3.2.5.3
examples, 3.2.5.2
how it works, 3.2.5.2
proxy authentication, used with, 3.10.1.4
Secure Sockets Layer (SSL)
about, 3.6.1
certificate key algorithm, 10.9.3
cipher suites, 10.9.3
configuration files, securing, 10.9.3
configuring for SYSDBA or SYSOPER access, 3.3.1.3
global users with private schemas, 3.7.1.1
guidelines for security, 10.9.3, 10.9.3
listener, administering, 10.9.2
mode, 10.9.3
pass phrase, 10.9.3
RSA private key, 10.9.3
securing SSL connection, 10.9.3
server.key file, 10.9.3
TCPS, 10.9.3
version support, Preface
security
application enforcement of, 4.4.1.2
default user accounts
locked and expired automatically, 10.3
locking and expiring, 10.3
domains, enabled roles and, 4.4.5
enforcement in application, 5.2.2
enforcement in database, 5.2.2
multibyte characters in role names, 4.4.3
multibyte characters in role passwords, 4.4.4.1
passwords, 3.4.1
policies
applications, 5.1
SQL*Plus users, restricting, 4.4.7
tables or views, 7.1.2.1
procedures enhance, 4.5.6.3
resources, additional, 1.2
roles, advantages in application use, 5.4
See also security risks
security alerts, 10.2.1
security attacks
access to server after protocol errors, preventing, 5.9.2
application context values, attempts to change, 6.3.2
application design to prevent attacks, 5.3
command line recall attacks, 5.3.1.1, 5.3.1.4
denial of service, 10.9.2
denial-of-service
bad packets, addressing, 5.9.1
denial-of-service attacks through listener, 10.9.2
disk flooding, preventing, 5.9.1
eavesdropping, 10.9.1
encryption, problems not solved by, 8.1.2
falsified IP addresses, 10.9.1
falsified or stolen client system identities, 10.9.1
hacked operating systems or applications, 10.9.1
intruders, 8.1.2
non-SYS activities audited, 9.1.4
password cracking, 3.2.1
password protections against, 3.2.1
preventing malicious attacks from clients, 5.9
preventing password theft with proxy authentication and secure external password store, 3.10.1.4
session ID, need for encryption, 6.4.4.3
shoulder surfing, 5.3.1.4
SQL injection attacks, 5.3.1.2
unlimited authenticated requests, preventing, 5.9.3
user session output, hiding from intruders, 6.3.4
See also security risks
security domains
enabled roles and, 4.4.1.1
security patches
about, 10.2.1
downloading, 10.2.1
security policies
See Oracle Virtual Private Database, policies
security risks
ad hoc tools, 4.4.7.1, 4.4.7.1
application users not being database users, 5.2.1
applications enforcing rather than database, 5.2.2
audit records being tampered with, 9.3.5.1
bad packets to server, 5.9.1
database audit trail, protecting, 9.1.3
database version displaying, 5.9.4
encryption keys, users managing, 8.2.4.3
password files, 3.3.3
passwords exposed in large deployments, 3.2.5.1
passwords, exposing in programs or scripts, 5.3.1.4
positional parameters in SQL scripts, 5.3.1.4
privileges carelessly granted, 4.3.5
privileges granted to PUBLIC user group, 4.3.5
remote user impersonating another user, 4.4.4.3.2
sensitive data in audit trail, 10.10.1
server falsifying identities, 10.9.3
users with multiple roles, 5.6.1
See also security attacks
security settings scripts
audit settings
secconf.sql, 9.4.3
password settings
secconf.sql, 3.2.3.4
undoaud.sql, 9.4.3
undopwd.sql, 3.2.3.4
SELECT ANY DICTIONARY privilege
data dictionary, accessing, 10.6
exclusion from GRANT ALL PRIVILEGES privilege, 10.6
SELECT FOR UPDATE statement in Virtual Private Database policies, 7.5.2
SELECT privilege
SQL statements permitted, 5.8.2
SELECT_CATALOG_ROLE role
about, 4.4.2
SYS schema objects, enabling access to, 4.3.2.2
separation of duty concepts, Glossary
sequences
auditing, 9.3.10.2
server.key file
pass phrase to read and parse, 10.9.3
service-oriented architecture (SOA)
security enhancements for Oracle XML DB, Preface
SESSION_ROLES view
queried from PL/SQL block, 4.4.1.5.1
sessions
listing privilege domain of, 4.12.4
memory use, viewing, 2.6.5
time limits on, 2.4.2.5
when auditing options take effect, 9.3.1.3
SET ROLE statement
application code, including in, 5.6.2
associating privileges with role, 5.6.1
disabling roles with, 4.10.1
enabling roles with, 4.10.1
secure application roles, 5.5.2
when using operating-system roles, 4.9.5
SGA
See System Global Area (SGA)
SHA-1 hashing algorithm
about, 3.2.4
enabling exclusive mode, 3.2.4
how it increases password safety, 3.2.4
recommended by Oracle, 3.2.4
Shared Global Area (SGA)
See System Global Area (SGA)
shared server
limiting private SQL areas, 2.4.2.5
operating system role management restrictions, 4.9.6
shoulder surfing, 5.3.1.4
SHOW PARAMETER command, 9.3.2.1
smart cards
guidelines for security, 10.5
SNMPAGENT role
about, 4.4.2
SOA
See service-oriented architecture
SPATIAL_CSW_ADMIN role, 4.4.2
SPATIAL_WFS_ADMIN role, 4.4.2
SQL injection attacks, 5.3.1.2
SQL statements
audited when default auditing is enabled, 9.4.2
auditing
about, 9.3.7.1
configuring, 9.3.7.3
removing, 9.3.7.4
when records generated, 9.3.1.3
dynamic, 6.3.3.3
object privileges permitting in applications, 5.8.2
privileges required for, 4.5.3, 5.8.2
resource limits and, 2.4.2.2
restricting ad hoc use, 4.4.7.1, 4.4.7.1
SQL*Net
See Oracle Net
SQL*Plus
connecting with, 3.5
restricting ad hoc use, 4.4.7.1, 4.4.7.1
statistics monitor, 2.4.3
SSL
See Secure Sockets Layer
standard audit trail
activities always recorded, 9.1.5
AUDIT SQL statement, 9.3.6.1
auditing standard audit trail, 9.8.2.4
controlling size of, 9.8.2.2
disabling, 9.3.2.1
enabling, 9.3.2.1
maximum size of, 9.8.2.2
NOAUDIT SQL statement, 9.3.6.7
records, purging, 9.8.3.4
size, reducing, 9.9.5
transaction independence, 9.3.1.3
when created, 9.3.1.3
standard auditing
about, 9.3.1.1
administrative users on all platforms, 9.6.2
affected by editions, 9.3.10.3
archiving audit trail, 9.8.2.5
audit option levels, 9.3.6.1
audit trails
database, 9.8.2.1
auditing
default auditing, enabling, 9.4.1
cursors, affect on auditing, 9.3.6.4
database audit trail records, 9.8.2.1
DDL statement auditing, 9.3.7.2
default options, 9.3.10.5
default options, disabling, 9.3.10.6
directory object auditing
about, 9.3.11.1
configuring, 9.3.11.2
removing, 9.3.11.3
disabling options versus auditing, 9.3.6.7
DML statements, 9.3.7.2
information stored in operating system file, 9.3.4.1
mandatory auditing, 9.1.5
network auditing
about, 9.3.13.1
configuring, 9.3.13.2
error types recorded, 9.3.13.1
removing, 9.3.13.3
non-SYS activities audited, 9.1.4
object auditing
See standard auditing, schema object
operating system audit trail, 9.3.4.1
file location, 9.3.4.5
operating system audit trail using, 9.3.4.3
privilege auditing
about, 9.3.8.1
configuring, 9.3.8.3
multitier environment, 9.3.9
options, 9.3.8.3
removing, 9.3.8.4
types, 9.3.8.2
privileges needed, 9.3.1.2
procedures or functions, 9.3.10.5
range of focus, 9.3.6
records
archiving, 9.8.2.5
removing, 9.3.6.7
schema object auditing
about, 9.3.10.1
enabling, 9.3.10.5
example, 9.3.10.5
options, 9.3.10.4
removing, 9.3.10.6
types, 9.3.10.2
SQL statement
See standard auditing, statement auditing
statement auditing
about, 9.3.7.1
all statements for individual users, 9.3.7.3
all statements for the current session, 9.3.7.3
configuring, 9.3.7.3
multitier environment, 9.3.9
removing, 9.3.7.4
SQL statement shortcuts by individual users, 9.3.7.3
statement level, 9.3.7.3
types you can audit, 9.3.7.2
statement executions, number of, 9.3.6.3
successful or unsuccessful, 9.3.6.2
setting, 9.3.6.2
SYS users, 9.6.2, 9.6.2
syslog audit trail on UNIX systems, 9.3.5
user, 9.3.6.6
See also auditing, standard audit trail, SYS.AUD$ table
standard auditing, schema object
objects created in the future, 9.3.10.7
statement_types parameter of DBMS_RLS.ADD_POLICY procedure, 7.3.3
STMT_AUDIT_OPTION_MAP table, 9.3.3
storage
quotas and, 2.2.5
unlimited quotas, 2.2.5.2
stored procedures
using privileges granted to PUBLIC, 4.8
strong authentication
centrally controlling SYSDBA and SYSOPER access to multiple databases, 3.3.1
guideline, 10.5
symbolic links
restricting, 10.6
synonyms
inheriting privileges from object, 4.5.3.3
SYS account
policy enforcement, 7.5.7.2
SYS and SYSTEM
passwords, 10.5, 10.5
SYS schema
objects, access to, 4.3.2.2
SYS_CONTEXT function
about, 6.3.3.1
auditing current session, 9.3.7.3
auditing nondatabase users with, 9.5.10.3
database links, 6.3.3.5
dynamic SQL statements, 6.3.3.3
example, 6.3.3.6
parallel query, 6.3.3.4
STATIC policies, 7.3.6.5
syntax, 6.3.3.2, 6.3.3.2
validating users, 5.5.2
SYS_DEFAULT Oracle Virtual Private Database policy group, 7.3.5.3
SYSASM privilege, Preface
SYS.AUD$ table
about, 9.8.2.1
archiving, 9.8.2.5
audit records, writing to, 9.3.2.2
contents, 9.8.2.1
data values in audited statement, 9.8.2.1
location in Oracle Database Vault environment, 9.1.3
modifying manually, dangers of, 9.7
non-SYS actions audited, 9.1.4
purging, 9.8.2.5
too full or unavailable, 9.8.2.1
See also standard auditing
SYSAUX tablespace
moving database audit trail tables to, 9.8.2.3
SYS.FGA_LOG$
fine-grained auditing, 9.5.4
SYS.FGA_LOG$ table
about, 9.8.2.1
archiving, 9.8.2.5
contents, 9.8.2.1
data values in audited statement, 9.8.2.1
non-SYS actions audited, 9.1.4
purging, 9.8.2.5
too full or unavailable, 9.8.2.1
SYS.FGA_LOGS$ table
See also fine-grained auditing
syslog audit trail
about, 9.3.5.1
appearance, 9.3.5.3
configuring, 9.3.5.4
format, 9.3.5.2
format when AUDIT_TRAIL is set to XML, 9.3.2.2
mandatory audit records written to, 9.1.5
SYSMAN user account, 10.5, 10.5
SYS-privileged connections, 10.3
System Global Area (SGA)
application contexts, storing in, 6.1.3
global application context information location, 6.4.1
limiting private SQL areas, 2.4.2.5
system privileges, 10.3
about, 4.3.1
ADMIN OPTION, 4.3.4
ANY
guidelines for security, 10.6
ANY system privileges, 4.3.2
GRANT ANY OBJECT PRIVILEGE, 4.6.2.2, 4.7.2.1
GRANT ANY PRIVILEGE, 4.3.4
granting, 4.6.1
granting and revoking, 4.3.3
power of, 4.3.1
restriction needs, 4.3.2
revoking, cascading effect of, 4.7.3.1
SELECT ANY DICTIONARY, 10.6
SYSASM privilege, Preface
SYSTEM_PRIVILEGE_MAP table, 9.3.3

T

tables
auditing, 9.3.10.2
privileges on, 4.5.4
tablespaces
assigning defaults for users, 2.2.4
default quota, 2.2.5
quotas for users, 2.2.5
quotas, viewing, 2.6.3
temporary
assigning to users, 2.2.6
unlimited quotas, 2.2.5.2
TCPS protocol
Secure Sockets Layer, used with, 10.9.2
tnsnames.ora file, used in, 10.9.3
TELNET service, 10.9.2
TFTP service, 10.9.2
time measurement for statement execution, 7.3.6.2
token cards, 10.5
top-level SQL statements, 9.2
trace files
access to, importance of restricting, 10.6
bad packets, 5.9.1
location of, finding, 6.6
transparent data encryption, 8.2.4.4
transparent tablespace encryption, 8.2.4.4
triggers
audit data, recording, 9.7
auditing, 9.3.10.4, 9.3.12.1, 9.3.12.2
CREATE TRIGGER ON, 5.8.2
logon
examples, 6.3.4
externally initialized application contexts, 6.3.4
privileges for executing, 4.5.6.3
roles, 4.4.1.5
WHEN OTHERS exception, 6.3.4
troubleshooting
finding errors by checking trace files, 6.6
trusted procedure
database session-based application contexts, 6.1.2
tsnames.ora configuration file, 10.9.3
tutorials
application context, database session-based, 6.3.5.1
auditing
creating policy to audit nondatabase users, 9.5.10.1
creating policy using e-mail alert, 9.5.9.1
external network services, using e-mail alert, 9.5.9.1
global application context with client session ID, 6.4.5.1
nondatabase users
creating Oracle Virtual Private Database policy group, 7.4.3.1
global application context, 6.4.5.1
Oracle Virtual Private Database
policy groups, 7.4.3.1
policy implementing, 7.4.2.1
simple example, 7.4.1.1
See also examples
types
creating, 4.5.7.5
privileges on, 4.5.7
user defined
creation requirements, 4.5.7.4

U

UDP and TCP ports
close for ALL disabled services, 10.9.2
UGA
See User Global Area (UGA)
Ultra Search
deprecated role and schemas, Preface
undoaud.sql script, 9.4.3
undopwd.sql script, 3.2.3.4
UNIX systems
audit data written to syslog, 9.1.5
UNIX systems, auditing users on, 9.3.5
UNLIMITED TABLESPACE privilege, 2.2.5.2, 2.2.5.2
UPDATE privilege
revoking, 4.7.2.2
user accounts
administrative user passwords, 10.5
default user account, 10.5
password guidelines, 10.5
passwords, encrypted, 10.5
USER function
global application contexts, 6.4.3.3
User Global Area (UGA)
application contexts, storing in, 6.1.3
user names
schemas, 5.7
USER pseudo column, 4.5.5.3
user sessions, multiple within single database connection, 3.10.1.5
user-defined columns
auditing, 9.5.2
USERENV function, 6.3.3.2, 8.3
USERENV namespace
about, 6.3.3.2
client identifiers, 3.10.2
See also CLIENT_IDENTIFIER USERENV attribute
users
administrative option (ADMIN OPTION), 4.6.1.1
altering, 2.3
application users not known to database, 3.10.2
assigning unlimited quotas for, 2.2.5.2
auditing, 9.3.6.6
database role, current, 5.6.1
default roles, changing, 2.2.8
default tablespaces, 2.2.4
dropping, 2.5, 2.5
dropping profiles and, 2.4.4.2
dropping roles and, 4.4.6
enabling roles for, 5.6
enterprise, 3.7, 4.4.4.4
enterprise, shared schema protection, 5.7.2
external authentication
about, 3.8.1
advantages, 3.8.2
operating system, 3.8.4
user creation, 3.8.3
finding information about, 2.6.1
finding information about authentication, 3.11
global, 3.7
hosts, connecting to multiple
See external network services, fine-grained access to
information about, viewing, 2.6.2
listing roles granted to, 4.12.2
memory use, viewing, 2.6.5
network authentication, external, 3.8.5
nondatabase, 6.4.1, 6.4.3.6
objects after dropping, 2.5
operating system external authentication, 3.8.4
password encryption, 3.2.1
privileges
for changing passwords, 2.3
for creating, 2.2.1
granted to, listing, 4.12.1
of current database role, 5.6.1
profiles
creating, 2.4.4.1
specifying, 2.2.7
proxy authentication, 3.10.1
proxy users, connecting as, 3.10.1.1
PUBLIC group, 4.8
PUBLIC user group, 4.4.1.4
quota limits for tablespace, 2.2.5.1
restricting application roles, 4.4.7
roles and, 4.4.1.2
for types of users, 4.4.1.3.2
schema-independent, 5.7.2
schemas, private, 3.7.1.1
security domains of, 4.4.1.4
security, about, 2.1
tablespace quotas, 2.2.5
tablespace quotas, viewing, 2.6.3
user accounts, creating, 2.2.1
user models and Oracle Virtual Private Database, 7.5.8
user name, specifying with CREATE USER statement, 2.2.2
views for finding information about, 2.6
UTLPWDMG.SQL
about, 3.2.3.8
guidelines for security, 10.5

V

V$LOGMNR_CONTENTS data dictionary view, 9.8.2.1
valid node checking, 10.9.2
views
about, 4.5.5.1
access control list data
external network services, 4.11.12
wallet access, 4.11.12
application contexts, 6.6
audit trail, 9.10.1, 9.10.1
auditing, 9.3.10.2, 9.3.10.4
authentication, 3.11
DBA_COL_PRIVS, 4.12.3
DBA_NETWORK_ACL_PRIVILEGES, 4.11.10, 4.11.12
DBA_NETWORK_ACLS, 4.11.12
DBA_ROLE_PRIVS, 4.12.2
DBA_ROLES, 4.12.5
DBA_SYS_PRIVS, 4.12.1
DBA_TAB_PRIVS, 4.12.3
DBA_USERS_WITH_DEFPWD, 3.2.3.2
DBA_WALLET_ACLS, 4.11.12
encrypted data, 8.6
Oracle Virtual Private Database policies, 7.6
privileges, 4.5.5.1, 4.12
profiles, 2.6.1
ROLE_ROLE_PRIVS, 4.12.6
ROLE_SYS_PRIVS, 4.12.6
ROLE_TAB_PRIVS, 4.12.6
roles, 4.12
security applications of, 4.5.5.3
SESSION_PRIVS, 4.12.4
SESSION_ROLES, 4.12.4
USER_NETWORK_ACL_PRIVILEGES, 4.11.12
users, 2.6.1
Virtual Private Database
See Oracle Virtual Private Database
VPD
See Oracle Virtual Private Database
vulnerable run-time call, 10.3
made more secure, 10.3

W

Wallet Manager
See Oracle Wallet Manager
wallets
authentication method, 3.6.2
See also access control lists (ACL), wallet access
Web applications
user connections, 6.4.1, 6.4.3.6
Web services
security enhancements for Oracle XML DB, Preface
Web-based applications
Oracle Virtual Private Database, how it works with, 7.5.8
WFS_USR_ROLE role, 4.4.2
WHEN OTHERS exceptions
logon triggers, used in, 6.3.4
WHERE clause, dynamic SQL, 7.2.1
Windows native authentication, 3.3.2
WKUSER role, Preface
WM_ADMIN_ROLE role, 4.4.2

X

X.509 certificates
guidelines for security, 10.5
XDB_SET_INVOKER role, 4.4.2
XDB_WEBSERVICES role, 4.4.2
XDB_WEBSERVICES_OVER_HTTP role
about, 4.4.2
XDB_WEBSERVICES_WITH_PUBLIC role, 4.4.2
XDBADMIN role, 4.4.2
XML
adx_SID.txt file
about, 9.3.2.2
AUDIT_TRAIL XML setting, 9.3.2.2
AUDIT_TRAIL XML, EXTENDED setting, 9.3.2.2
XML, EXTENDED AUDIT_TRAIL setting
used with DB in AUDIT_TRAIL, 9.3.2.2
used with XML in AUDIT_TRAIL, 9.3.2.2
PK7T^xxPKj? OEBPS/toc.htm Table of Contents

Contents

List of Examples

List of Figures

List of Tables

Title and Copyright Information

Preface

What's New in Oracle Database Security?

1 Introducing Oracle Database Security

2 Managing Security for Oracle Database Users

3 Configuring Authentication

4 Configuring Privilege and Role Authorization

5 Managing Security for Application Developers

6 Using Application Contexts to Retrieve User Information

7 Using Oracle Virtual Private Database to Control Data Access

8 Developing Applications Using the Data Encryption API

9 Verifying Security Access with Auditing

10 Keeping Your Oracle Database Secure

Glossary

Index

PK,϶PKj?OEBPS/img_text/cncpt082.htme Description of the illustration cncpt082.gif

This graphic illustrates the use of roles. From left to right, top to bottom, there are four categoroies, which are as follows:

PK PKj?OEBPS/img_text/adfns001.htmQ Description of the illustration adfns001.gif

Surrounding text describes this figure.

PK=PKj?#OEBPS/img_text/audit_proxy_user.htm$ Description of the illustration audit_proxy_user.gif

This figure illustrates the environment in which you can audit proxy users. In this figure, from left to right, top to bottom, are the following components:

PK*Ž)$PKj?OEBPS/img_text/admin024.htmQ Description of the illustration admin024.gif

Surrounding text describes this figure.

PK(!PKj?$OEBPS/img_text/client_identifier.htm" Description of the illustration client_identifier.gif

This figure illustrates an environment in which you can audit the client identifier of a user. From left to right, top to bottom, top to bottom, are the following components:

PKraPKj?OEBPS/img_text/cncpt137.htm* Description of the illustration cncpt137.gif

This figure illustrates the process flow for multier authentication. The text in the following section describes each of the steps that take place in this process.

PKX/*PKj? OEBPS/loe.htm(N List of Examples

List of Examples

PK܃+((PKj?OEBPS/authorization.htm Configuring Privilege and Role Authorization

4 Configuring Privilege and Role Authorization

This chapter contains:

About Privileges and Roles

Authorization includes primarily two processes:

  • Permitting only certain users to access, process, or alter data.

  • Applying varying limitations on user access or actions. The limitations placed on (or removed from) users can apply to objects such as schemas, tables, or rows or to resources such as time (CPU, connect, or idle times).

A user privilege is the right to run a particular type of SQL statement, or the right to access an object that belongs to another user, run a PL/SQL package, and so on. The types of privileges are defined by Oracle Database.

Roles are created by users (usually administrators) to group together privileges or other roles. They are a way to facilitate the granting of multiple privileges or roles to users.

This section describes the following general categories:

Who Should Be Granted Privileges?

You grant privileges to users so they can accomplish tasks required for their jobs. You should grant a privilege only to a user who requires that privilege to accomplish the necessary work. Excessive granting of unnecessary privileges can compromise security. For example, you never should grant SYSDBA or SYSOPER privilege to users who do not perform administrative tasks.

A user can receive a privilege in two ways:

Because roles allow for easier and better management of privileges, you should usually grant privileges to roles and not to specific users.


See Also:


Managing System Privileges

This section contains:

Why Is It Important to Restrict System Privileges?

Because system privileges are so powerful, by default the database is configured to prevent typical (non-administrative) users from exercising the ANY system privileges (such as UPDATE ANY TABLE) on the data dictionary. See "Guidelines for Securing User Accounts and Privileges" for additional guidelines about restricting system privileges.

Restricting System Privileges by Securing the Data Dictionary

To secure the data dictionary, set the O7_DICTIONARY_ACCESSIBILITY initialization parameter to FALSE, which is the default value. This feature is called the dictionary protection mechanism.

The O7_DICTIONARY_ACCESSIBILITY initialization parameter controls restrictions on system privileges when you upgrade from Oracle Database release 7 to Oracle8i and later releases. If the parameter is set to TRUE, then access to objects in the SYS schema is allowed (Oracle Database release 7 behavior). Because the ANY privilege applies to the data dictionary, a malicious user with ANY privilege could access or alter data dictionary tables.

To set the O7_DICTIONARY_ACCESSIBILTY initialization parameter, modify it in the initSID.ora file. Alternatively, you can log on to SQL*Plus as user SYS with the SYSDBA privilege and then enter an ALTER SYSTEM statement, assuming you have started the database using a server parameter file (SPFILE).

Example 4-1 shows how to set the O7_DICTIONARY_ACCESSIBILTY initialization parameter to FALSE by issuing an ALTER SYSTEM statement in SQL*Plus.

When you set O7_DICTIONARY_ACCESSIBILITY to FALSE, system privileges that enable access to objects in any schema (for example, users who have ANY privileges, such as CREATE ANY PROCEDURE) do not allow access to objects in the SYS schema. This means that access to the objects in the SYS schema (data dictionary objects) is restricted to users who connect using the SYSDBA privilege. Remember that the SYS user must log in with either the SYSDBA or SYSOPER privilege; otherwise, an ORA-28009: connection as SYS should be as SYSDBA or SYSOPER error is raised. If you set O7_DICTIONARY_ACCESSIBILITY to TRUE, then you would be able to log in to the database as user SYS without having to specify the SYSDBA or SYSOPER privilege.

System privileges that provide access to objects in other schemas do not give other users access to objects in the SYS schema. For example, the SELECT ANY TABLE privilege allows users to access views and tables in other schemas, but does not enable them to select dictionary objects (base tables of dynamic performance views, regular views, packages, and synonyms). You can, however, grant these users explicit object privileges to access objects in the SYS schema.

See Oracle Database Reference for more information about the O7_DICTIONARY_ACCESSIBILITY initialization parameter.

About ANY and PUBLIC Privileges

System privileges that use the ANY keyword enable you to set privileges for an entire category of objects in the database. For example, the CREATE ANY PROCEDURE system privilege allows a user to create a procedure anywhere in the database. The behavior of an object created by users with the ANY privilege is not restricted to the schema in which it was created. For example, if user MALCOEUR has the CREATE ANY PROCEDURE privilege and creates a procedure in the schema JONES, then the procedure will run as JONES. However, JONES may not be aware that the procedure MALCOEUR created is running as him (JONES). If JONES has DBA privileges, letting MALCOEUR run a procedure as JONES could pose a security violation.

You can grant privileges to the PUBLIC role, which then makes the privileges available to every user in the Oracle database. Be careful about granting privileges to the PUBLIC role, particularly powerful privileges such as the ANY privileges and system privileges. For example, if MALCOEUR has the CREATE PUBLIC SYNONYM privilege, he could redefine an interface that he knows everyone else uses, and then point to it with the PUBLIC SYNONYM that he created. Instead of accessing the correct interface, users would access the interface of MALCOEUR, which could possibly perform illegal activities such as stealing the login credentials of users.

These types of privileges are very powerful and could pose a security risk if given to the wrong person. Be careful about granting privileges using ANY or PUBLIC. As with all privileges, you should follow the principles of "least privilege" when granting these privileges to users.

To protect the data dictionary (the contents of the SYS schema) against users who have one or more of the powerful ANY system privileges, set the O7_DICTIONARY_ACCESSIBILITY initialization parameter to FALSE. You can set this parameter by using an ALTER SYSTEM statement (see Example 4-1, "Setting O7_DICTIONARY_ACCESSIBILITY to FALSE") or by modifying the initSID.ora file. See "Guidelines for Securing a Database Installation and Configuration" for additional guidelines.

Managing User Roles

This section contains:

About User Roles

Managing and controlling privileges is easier when you use roles, which are named groups of related privileges that you grant as a group to users or other roles. Within a database, each role name must be unique, different from all user names and all other role names. Unlike schema objects, roles are not contained in any schema. Therefore, a user who creates a role can be dropped with no effect on the role.

This section contains:

The Functionality of Roles

Roles are useful for quickly and easily granting permissions to users. Although you can use Oracle Database-defined roles, you have more control and continuity if you create your own roles that contain only the privileges pertaining to your requirements. Oracle may change or remove the privileges in an Oracle Database-defined role, as it has with the CONNECT role, which now has only the CREATE SESSION privilege. Formerly, this role had eight other privileges.

Roles have the following functionality:

Properties of Roles and Why They Are Advantageous

Table 4-2 describes the properties of roles that enable easier privilege management within a database.

Database administrators often create roles for a database application. You should grant a secure application role all privileges necessary to run the application. You then can grant the secure application role to other roles or users. An application can have several different roles, each granted a different set of privileges that allow for more or less data access while using the application.

The DBA can create a role with a password to prevent unauthorized use of the privileges granted to the role. Typically, an application is designed so that when it starts, it enables the proper role. As a result, an application user does not need to know the password for an application role.


See Also:

"How Roles Aid or Restrict DDL Usage" for information about restrictions for procedures

How Roles Aid or Restrict DDL Usage

A user requires one or more privileges to successfully execute a DDL statement, depending on the statement. For example, to create a table, the user must have the CREATE TABLE or CREATE ANY TABLE system privilege. To create a view of a table that belongs to another user, the creator requires the CREATE VIEW or CREATE ANY VIEW system privilege and either the SELECT object privilege for the table or the SELECT ANY TABLE system privilege.

Oracle Database avoids the dependencies on privileges received by way of roles by restricting the use of specific privileges in certain DDL statements. The following rules describe these privilege restrictions concerning DDL statements:

  • All system privileges and object privileges that permit a user to perform a DDL operation are usable when received through a role. For example:

    • System privileges: CREATE TABLE, CREATE VIEW, and CREATE PROCEDURE privileges

    • Object privileges: ALTER and INDEX privileges for a table

      You cannot use the REFERENCES object privilege for a table to define the foreign key of a table if the privilege is received through a role.

  • All system privileges and object privileges that allow a user to perform a DML operation that is required to issue a DDL statement are not usable when received through a role. The security domain does not contain roles when a CREATE VIEW statement is used. For example, a user who is granted the SELECT ANY TABLE system privilege or the SELECT object privilege for a table through a role cannot use either of these privileges to create a view on a table that belongs to another user. This is because views are definer's rights objects, so when creating them you cannot use any privileges (neither system privileges or object privileges) granted to you through a role. If the privilege is granted directly to you, then you can use the privilege. However, if the privilege is revoked at a later time, then the view definition becomes invalid ("contains errors") and must recompiled before it can be used again.

The following example further clarifies the permitted and restricted uses of privileges received through roles.

Assume that a user is:

  • Granted a role that has the CREATE VIEW system privilege

  • Directly granted a role that has the SELECT object privilege for the employees table

  • Directly granted the SELECT object privilege for the departments table

Given these directly and indirectly granted privileges:

  • The user can issue SELECT statements on both the employees and departments tables.

  • Although the user has both the CREATE VIEW and SELECT privilege for the employees table through a role, the user cannot create a view on the employees table, because the SELECT object privilege for the employees table was granted through a role.

  • The user can create a view on the departments table, because the user has the CREATE VIEW privilege through a role and the SELECT privilege for the departments table directly.

How Roles Work in a Distributed Environment

When you use roles in a distributed database environment, ensure that all needed roles are set as the default roles for a distributed (remote) session. These roles cannot be enabled when the user connects to a remote database from within a local database session. For example, the user cannot execute a remote procedure that attempts to enable a role at the remote site.

Predefined Roles in an Oracle Database Installation

Oracle Database provides a set of predefined roles to help in database administration. These roles, listed in Table 4-3, are automatically defined for Oracle databases when you run the standard scripts that are part of database creation. If you install other options or products, then other predefined roles may be created. You can grant privileges and roles to, and revoke privileges and roles from, these predefined roles in the same way as you do with any role you define.

Table 4-3 Oracle Database Predefined Roles

Predefined RoleDescription

ADM_PARALLEL_EXECUTE_TASK

Provides privileges to update table data in parallel by using the DBMS_PARALLEL_EXECUTE PL/SQL package.

See Also: Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_PARALLEL_EXECUTE PL/SQL package.

AQ_ADMINISTRATOR_ROLE

Provides privileges to administer Advanced Queuing. Includes ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, and MANAGE ANY QUEUE, SELECT privileges on Advanced Queuing tables and EXECUTE privileges on Advanced Queuing packages.

AQ_USER_ROLE

Obsolete, but kept mainly for release 8.0 compatibility. Provides EXECUTE privileges on the DBMS_AQ and DBMS_AQIN packages.

AUTHENTICATEDUSER

Used by the XDB protocols to define any user who has logged in to the system.

CAPI_USER_ROLE

Provides access to packages used for implementing Information Lifecycle Management (ILM) and hierarchical storage and other applications.

See Also: Oracle Database SecureFiles and Large Objects Developer's Guide

CONNECT

Provides the CREATE SESSION system privilege.

This role is provided for compatibility with previous releases of Oracle Database. You can determine the privileges encompassed by this role by querying the DBA_SYS_PRIVS data dictionary view.

Note: Oracle recommends that you design your own roles for database security rather than relying on this role. This role may not be created automatically by future releases of Oracle Database.

See Also: Oracle Database Reference for a description of the DBA_SYS_PRIVS view

CSW_USR_ROLE

Provides user privileges to manage the Catalog Services for the Web (CSW) component of Oracle Spatial.

See Also: Oracle Spatial Developer's Guide for more information

CTXAPP

Provides privileges to create Oracle Text indexes and index preferences, and to use PL/SQL packages. This role should be granted to Oracle Text users.

See Also: Oracle Text Application Developer's Guide for more information

CWM_USER

Provides privileges to manage Common Warehouse Metadata (CWM), which is a repository standard used by Oracle data warehousing and decision support.

See Also: Oracle Database Data Warehousing Guide for more information

DATAPUMP_EXP_FULL_DATABASE

Provides privileges to export data from an Oracle database using Oracle Data Pump.

Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.

See Also: Oracle Database Utilities for more information

DATAPUMP_IMP_FULL_DATABASE

Provides privileges to import data into an Oracle database using Oracle Data Pump.

Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.

See Also: Oracle Database Utilities for more information

DBA

Provides all system privileges that were created with the ADMIN option.

This role is provided for compatibility with previous releases of Oracle Database. You can determine the privileges encompassed by this role by querying the DBA_SYS_PRIVS data dictionary view.

Note: Oracle recommends that you design your own roles for database security rather than relying on this role. This role may not be created automatically by future releases of Oracle Database.

See Also: Oracle Database Reference for a description of the DBA_SYS_PRIVS view

DELETE_CATALOG_ROLE

Provides the DELETE privilege on the system audit table (AUD$).

EJBCLIENT

Provides privileges to connect to EJBs from a Java stored procedure.

EXECUTE_CATALOG_ROLE

Provides EXECUTE privileges on objects in the data dictionary.

EXP_FULL_DATABASE

Provides the privileges required to perform full and incremental database exports using the Export utility (later replaced with Oracle Data Pump). It includes these privileges: SELECT ANY TABLE, BACKUP ANY TABLE, EXECUTE ANY PROCEDURE, EXECUTE ANY TYPE, ADMINISTER RESOURCE MANAGER, and INSERT, DELETE, and UPDATE on the tables SYS.INCVID, SYS.INCFIL, and SYS.INCEXP. Also the following roles: EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE.

This role is provided for convenience in using the export and import utilities.

Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.

See Also: Oracle Database Utilities for more information

GATHER_SYSTEM_STATISTICS

Provides privileges to update system statistics, which are collected using the DBMS_STATS.GATHER_SYSTEM_STATISTICS procedure

See Also: Oracle Database Performance Tuning Guide for more information about managing optimizer statistics

GLOBAL_AQ_USER_ROLE

Provides privileges to establish a connection to an LDAP server, for use with Oracle Streams AQ.

See Also: Oracle Streams Advanced Queuing User's Guide for more information

HS_ADMIN_EXECUTE_ROLE

Provides the EXECUTE privilege for users who want to use the Heterogeneous Services (HS) PL/SQL packages.

See Also: Oracle Database Heterogeneous Connectivity Administrator's Guide for more information

HS_ADMIN_ROLE

Provides privileges to both use the Heterogeneous Services (HS) PL/SQL packages and query the HS-related data dictionary views.

See Also: Oracle Database Heterogeneous Connectivity Administrator's Guide for more information

HS_ADMIN_SELECT_ROLE

Provides privileges to query the Heterogeneous Services data dictionary views.

See Also: Oracle Database Heterogeneous Connectivity Administrator's Guide for more information

IMP_FULL_DATABASE

Provides the privileges required to perform full database imports using the Import utility (later replaced with Oracle Data Pump). Includes an extensive list of system privileges (use view DBA_SYS_PRIVS to view privileges) and the following roles: EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE.

This role is provided for convenience in using the export and import utilities.

Caution: This is a very powerful role because it provides a user access to any data in any schema in the database. Use caution when granting this role to users.s.

See Also: Oracle Database Utilities for more information

JAVADEBUGPRIV

Provides privileges to run the Oracle Database Java applications debugger.

See Also: Oracle Database Java Developer's Guide for more information about managing security for Oracle Java applications

JAVAIDPRIV

Deprecated for this release.

JAVASYSPRIV

Provides major permissions to use Java2, including updating Oracle JVM-protected packages.

See Also: Oracle Database Java Developer's Guide for more information about managing security for Oracle Java applications

JAVAUSERPRIV

Provides limited permissions to use Java2.

See Also: Oracle Database Java Developer's Guide for more information about managing security for Oracle Java applications

JAVA_ADMIN

Provides administrative permissions to update policy tables for Oracle Database Java applications.

See Also: Oracle Database Java Developer's Guide for more information about managing security for Oracle Java applications

JAVA_DEPLOY

Provides privileges to deploy ncomp DLLs into the javavm/admin directory using the ncomp and deployns utilities. Without this role, the javavm/deploy and javavm/admin directories can be accessible.

See Also: Oracle Database Advanced Application Developer's Guide for more information

JMXSERVER

Provides privileges to start and maintain a JMX agent in a database session.

See Also: Oracle Database Java Developer's Guide for more information about managing Oracle Java applications

LBAC_DBA

Provides permissions to use the SA_SYSDBA PL/SQL package.

See Also: Oracle Label Security Administrator's Guide for more information

LOGSTDBY_ADMINISTRATOR

Provides administrative privileges to manage the SQL Apply (logical standby database) environment.

See Also: Oracle Data Guard Concepts and Administration for more information

MGMT_USER

Grants the SELECT privilege on the different views used for the SYSMAN schema.

OEM_ADVISOR

Provides privileges to create, drop, select (read), load (write), and delete a SQL tuning set through the DBMS_SQLTUNE PL/SQL package, and to access to the Advisor framework using the ADVISOR PL/SQL package.

See Also: Oracle Database Performance Tuning Guide for more information

OEM_MONITOR

Provides privileges needed by the Management Agent component of Oracle Enterprise Manager to monitor and manage the database.

See Also: Oracle Database Performance Tuning Guide for more information

OLAPI_TRACE_USER

Provides privileges to perform OLAP API tracing. Contact Oracle Support for more information.

OLAP_DBA

Provides administrative privileges to create dimensional objects in different schemas for Oracle OLAP.

See Also: Oracle OLAP User's Guide for more information

OLAP_USER

Provides application developers privileges to create dimensional objects in their own schemas for Oracle OLAP.

See Also: Oracle OLAP User's Guide for more information

OLAP_XS_ADMIN

Provides privileges to administer security for Oracle OLAP.

See Also: Oracle OLAP User's Guide for more information

ORDADMIN

Provides privileges to administer Oracle Multimedia DICOM.

See Also: Oracle Multimedia DICOM Developer's Guide

OWB$CLIENT

Provides privileges to perform standard client-related tasks for Oracle Warehouse Builder, such as creating projects, modules, tables, views, maps, and so on. Warehouse Builder automatically grants this role to all workspace owners and users. (That is, you do not need to explicitly grant it to anyone who must use Warehouse Builder.) For security reasons, the OWB$CLIENT role is not a default role for Warehouse Builder users: Oracle Warehouse Builder enables this role only when it is needed.

See Also: Oracle Warehouse Builder Installation and Administration Guide for more information

OWB_DESIGNCENTER_VIEW

Provides privileges from the database level for any registered Oracle Warehouse Builder user to query the Warehouse Builder public views, such as ALL_IV_PROJECTS. A Warehouse Builder administrator can use the ACCESS_PUBLICVIEW_BROWSER system privilege from the Warehouse Builder security level to control an Warehouse Builder user's access to those public views.

See Also: Oracle Warehouse Builder Installation and Administration Guide for more information

OWB_USER

Provides privileges to create and own an Oracle Warehouse Builder workspace. When a workspace owner registers other database users to this workspace, Oracle Database grants this role to these users. Users with this role also have access to Warehouse Builder Control Center public views and other Control Center utilities. Oracle Warehouse Builder grants this role to all Warehouse Builder users.

See Also: Oracle Warehouse Builder Installation and Administration Guide for more information

RECOVERY_CATALOG_OWNER

Provides privileges for owner of the recovery catalog. Includes: CREATE SESSION, ALTER SESSION, CREATE SYNONYM, CREATE VIEW, CREATE DATABASE LINK, CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE TRIGGER, and CREATE PROCEDURE

RESOURCE

Provides the following system privileges: CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE.

This role is provided for compatibility with previous releases of Oracle Database. You can determine the privileges encompassed by this role by querying the DBA_SYS_PRIVS data dictionary view.

Note: Oracle recommends that you design your own roles for database security rather than relying on this role. This role may not be created automatically by future releases of Oracle Database.

See Also: Oracle Database Reference for a description of the DBA_SYS_PRIVS view

SCHEDULER_ADMIN

Allows the grantee to execute the procedures of the DBMS_SCHEDULER package. It includes all of the job scheduler system privileges and is included in the DBA role.

See Also: Oracle Database Administrator's Guide for more information about the DBMS_SCHEDULER package

SELECT_CATALOG_ROLE

Provides SELECT privilege on objects in the data dictionary.

SNMPAGENT

Used by the Enterprise Manager Management Agent.

SPATIAL_CSW_ADMIN

Provides administrative privileges to manage the Catalog Services for the Web (CSW) component of Oracle Spatial.

See Also: Oracle Spatial Developer's Guide for more information

SPATIAL_WFS_ADMIN

Provides administrative privileges to manage the Web Feature Service (WFS) component of Oracle Spatial.

See Also: Oracle Spatial Developer's Guide for more information

WFS_USR_ROLE

Provides user privileges for the Web Feature Service (WFS) component of Oracle Spatial.

See Also: Oracle Spatial Developer's Guide for more information

WM_ADMIN_ROLE

Provides administrative privileges for Oracle Workspace Manage. This enables users to run any DBMS_WM procedures on all version enabled tables, workspaces, and savepoints regardless of their owner. It also enables the user to modify the system parameters specific to Workspace Manager.

See Also: Oracle Database Workspace Manager Developer's Guide for more information

XDBADMIN

Allows the grantee to register an XML schema globally, as opposed to registering it for use or access only by its owner. It also lets the grantee bypass access control list (ACL) checks when accessing Oracle XML DB Repository.

See Also: Oracle XML DB Developer's Guide for information about XML schemas and the XML DB Repository

XDB_SET_INVOKER

Allows the grantee to define invoker's rights handlers and to create or update the resource configuration for XML repository triggers. By default, Oracle Database grants this role to the DBA role but not to the XDBADMIN role.

See Also: Oracle XML DB Developer's Guide for information about Oracle Database XML repository triggers

XDB_WEBSERVICES

Allows the grantee to access Oracle Database Web services over HTTPS. However, it does not provide the user access to objects in the database that are public. To allow public access, you need to grant the user the XDB_WEBSERVICES_WITH_PUBLIC role. For a user to use these Web services, SYS must enable the Web service servlets.

See Also: Oracle XML DB Developer's Guide for information about Oracle Database Web services

XDB_WEBSERVICES_OVER_HTTP

Allows the grantee to access Oracle Database Web services over HTTP. However, it does not provide the user access to objects in the database that are public. To allow public access, you need to grant the user the XDB_WEBSERVICES_WITH_PUBLIC role.

See Also: Oracle XML DB Developer's Guide for information about Oracle Database Web services

XDB_WEBSERVICES_WITH_PUBLIC

Allows the grantee access to public objects through Oracle Database Web services.

See Also: Oracle XML DB Developer's Guide for information about Oracle Database Web services



Note:

Each installation should create its own roles and assign only those privileges that are needed, thus retaining detailed control of the privileges in use. This process also removes any need to adjust existing roles, privileges, or procedures whenever Oracle Database changes or removes roles that Oracle Database defines. For example, the CONNECT role now has only one privilege: CREATE SESSION. Both CONNECT and RESOURCE roles will be deprecated in future Oracle Database releases.

Creating a Role

You can create a role using the CREATE ROLE statement, but you must have the CREATE ROLE system privilege to do so. Typically, only security administrators have this system privilege.

After you create a role, the role has no privileges associated with it. Your next step is to grant either privileges or other roles to the new role.

You must give each role you create a unique name among existing user names and role names of the database. Roles are not contained in the schema of any user. In a database that uses a multibyte character set, Oracle recommends that each role name contain at least one single-byte character. If a role name contains only multibyte characters, then the encrypted role name and password combination is considerably less secure. See Guideline 1 in "Guidelines for Securing Passwords" for password guidelines.

Example 4-2 creates the clerk role.

The IDENTIFIED BY clause specifies how the user must be authorized before the role can be enabled for use by a specific user to which it has been granted. If you do not specify this clause, or if you specify NOT IDENTIFIED, then no authorization is required when the role is enabled. Roles can be specified to be authorized by:

  • The database using a password

  • An application using a specified package

  • Externally by the operating system, network, or other external source

  • Globally by an enterprise directory service

These authorizations are discussed in the following sections.

You can set or change the authorization method for a role using the ALTER ROLE statement. Remember that you can only directly grant secure application roles or password-authenticated roles to a user.

Example 4-3 shows how to alter the clerk role to specify that the user must have been authorized by an external source before enabling the role.

To alter the authorization method for a role, you must have the ALTER ANY ROLE system privilege or have been granted the role with ADMIN option.


See Also:

Oracle Database SQL Language Reference for syntax, restrictions, and authorization information about the SQL statements used to manage roles and privileges

Specifying the Type of Role Authorization

The methods of authorizing roles are presented in this section. A role must be enabled for you to use it.

This section contains:


See Also:

"When Do Grants and Revokes Take Effect?" for a discussion about enabling roles

Authorizing a Role by Using an External Source

You can define the external role locally in the database, but you cannot grant the external role to global users, to global roles, or to any other roles in the database. You can create roles that are authorized by the operating system or network clients.

Example 4-6 creates a role named accts_rec and requires that the user is authorized by an external source before it can be enabled:

Granting and Revoking Roles

You can grant system or object privileges to a role, and any role can be granted to any database user or to another role (but not to itself). However, a role cannot be granted circularly, that is, role X cannot be granted to role Y if role Y has previously been granted to role X.

To provide selective availability of privileges, Oracle Database permits applications and users to enable and disable roles. Each role granted to a user is, at any given time, either enabled or disabled. The security domain of a user includes the privileges of all roles currently enabled for the user and excludes the privileges of any roles currently disabled for the user.

A role granted to a role is called an indirectly granted role. You can explicitly enable or disable it for a user. However, whenever you enable a role that contains other roles, you implicitly enable all indirectly granted roles of the directly granted role.

You grant roles to (or revoke roles from) users or other roles by using either of the following methods:

Privileges are granted to and revoked from roles using the same options.

Restricting SQL*Plus Users from Using Database Roles

This section describes features that you can use to restrict SQL*Plus users from using database roles and thus, prevent serious security problems.

Limiting Roles Through the PRODUCT_USER_PROFILE Table

You can use the PRODUCT_USER_PROFILE table, which is in the SYSTEM schema, to disable certain SQL and SQL*Plus commands in the SQL*Plus environment for each user. SQL*Plus, not the Oracle Database, enforces this security. You can even restrict access to the GRANT, REVOKE, and SET ROLE commands to control user ability to change their database privileges.

The PRODUCT_USER_PROFILE table enables you to list roles that you do not want users to activate with an application. You can also explicitly disable the use of various commands, such as SET ROLE.

For example, you could create an entry in the PRODUCT_USER_PROFILE table to:

  • Disallow the use of the clerk and manager roles with SQL*Plus

  • Disallow the use of SET ROLE with SQL*Plus

Suppose user Marla connects to the database using SQL*Plus. Marla has the clerk, manager, and analyst roles. As a result of the preceding entry in PRODUCT_USER_PROFILE, Marla is only able to exercise her analyst role with SQL*Plus. Also, when Ginny attempts to issue a SET ROLE statement, she is explicitly prevented from doing so because of the entry in the PRODUCT_USER_PROFILE table prohibiting use of SET ROLE.

Be aware that the PRODUCT_USER_PROFILE table does not completely guarantee security, for multiple reasons. In the preceding example, while SET ROLE is disallowed with SQL*Plus, if Marla had other privileges granted to her directly, then she could exercise these using SQL*Plus.


See Also:

SQL*Plus User's Guide and Reference for more information about the PRODUCT_USER_PROFILE table

Using Stored Procedures to Encapsulate Business Logic

Stored procedures encapsulate the use of privileges with business logic so that privileges are only exercised in the context of a well-formed business transaction. For example, an application developer can create a procedure to update the employee name and address in the employees table, which enforces that the data can only be updated in normal business hours. Also, rather than grant a human resources clerk the UPDATE privilege on the employees table, a security administrator may grant the privilege on the procedure only. Then, the human resources clerk can exercise the privilege only in the context of the procedures, and cannot update the employees table directly.

Securing Role Privileges by Using Secure Application Roles

A secure application role is a role that can be enabled only by an authorized PL/SQL package (or procedure). The PL/SQL package itself reflects the security policies needed to control access to the application.

This method of role creation restricts the enabling of this type of role to the invoking application. For example, the application can perform authentication and customized authorization, such as checking whether the user has connected through a proxy.

This type of role strengthens security because passwords are not embedded in application source code or stored in a table. This way, the actions the database performs are based on the implementation of your security policies, and these definitions are stored in one place, the database, rather than in your applications. If you need to modify the policy, you do so in one place without having to modify your applications. No matter how users connect to the database, the result is always the same, because the policy is bound to the role.

To enable the secure application role, you must execute its underlying package by invoking it directly from the application when the user logs in, before the user exercises the privileges granted by the secure application role. You cannot use a logon trigger to enable a secure application role, nor can you have this type of role be a default role.

When you enable the secure application role, Oracle Database verifies that the authorized PL/SQL package is on the calling stack, that is, it verifies that the authorized PL/SQL package is issuing the command to enable the role.

You can use secure application roles to ensure the existence of a database connection. Because a secure application role is a role implemented by a package, the package can validate that users can connect to the database through a middle tier or from a specific IP address. In this way, the secure application role prevents users from accessing data outside an application. They are forced to work within the framework of the application privileges that they have been granted.

Managing Object Privileges

This section contains:

Managing Object Privileges

An object privilege grants permission to perform a particular action on a specific schema object.

Different object privileges are available for different types of schema objects. The privilege to delete rows from the departments table is an example of an object privilege.

Some schema objects, such as clusters, indexes, triggers, and database links, do not have associated object privileges. Their use is controlled with system privileges. For example, to alter a cluster, a user must own the cluster or have the ALTER ANY CLUSTER system privilege.

The following sections discuss granting and revoking such privileges:

The following sections discuss object privileges that apply to specific schema objects:

Who Can Grant Object Privileges?

A user automatically has all object privileges for schema objects contained in his or her schema. A user with the GRANT ANY OBJECT PRIVILEGE can grant any specified object privilege to another user with or without the WITH GRANT OPTION clause of the GRANT statement. A user with the GRANT ANY OBJECT PRIVILEGE can also use that privilege to revoke any object privilege that was granted either by the object owner or by some other user with the GRANT ANY OBJECT PRIVILEGE privilege. Otherwise, the grantee can use the privilege, but cannot grant it to other users.


See Also:

Oracle Database SQL Language Reference for information about GRANT and GRANT ANY OBJECT PRIVILEGE

Managing Table Privileges

Object privileges for tables enable table security at the DML (data manipulation language) or DDL (data definition language) level of operation.

The following sections discuss table privileges and DML and DDL operations:

Managing View Privileges

This section contains:

Increasing Table Security with Views

To use a view, the user must have the appropriate privileges but only for the view itself, not its underlying objects. However, if access privileges for the underlying objects of the view are removed, then the user no longer has access. This behavior occurs because the security domain that is used when a user queries the view is that of the definer of the view. If the privileges on the underlying objects are revoked from the view's definer, then the view becomes invalid, and no one can use the view. Therefore, even if a user has been granted access to the view, the user may not be able to use the view if the definer's rights have been revoked from the view's underlying objects.

For example, suppose User A creates a view. User A has definer's rights on the underlying objects of the view. User A then grants the SELECT privilege on that view to User B so that User B can query the view. But if User A no longer has access to the underlying objects of that view, then User B no longer has access either.

Views add two more levels of security for tables, column-level security and value-based security, as follows:

Managing Procedure Privileges

This section contains:

Procedure Execution and Security Domains

A user with the EXECUTE object privilege for a specific procedure can execute the procedure or compile a program unit that references the procedure. Oracle Database performs a run-time privilege check when any PL/SQL unit is called. A user with the EXECUTE ANY PROCEDURE system privilege can execute any procedure in the database. Privileges to run procedures can be granted to a user through roles.


See Also:

Oracle Database PL/SQL Language Reference for more information about how Oracle Database checks privileges at run-time

How Procedure Privileges Affect Definer's Rights

The owner of a procedure, called the definer, must have all the necessary object privileges for referenced objects. If the procedure owner grants to another user the right to use that procedure, then the privileges of the procedure owner (on the objects referenced by the procedure) apply to the grantee user's exercise of the procedure. The privileges of the procedure's definer must be granted directly to the user, not granted through roles. These are termed definer's rights.

The user of a procedure who is not its owner is called the invoker. Additional privileges on referenced objects are required for invoker's rights procedures, but not for definer's rights procedures.

A user of a definer's rights procedure requires only the privilege to execute the procedure and no privileges on the underlying objects that the procedure accesses. This is because a definer's rights procedure operates under the security domain of the user who owns the procedure, regardless of who is executing it. The owner of the procedure must have all the necessary object privileges for referenced objects. Fewer privileges have to be granted to users of a definer's rights procedure. This results in stronger control of database access.

You can use definer's rights procedures to control access to private database objects and add a level of database security. By writing a definer's rights procedure and granting only EXECUTE privilege to a user, the user can be forced to access the referenced objects only through the procedure.

At run time, Oracle Database checks whether the privileges of the owner of a definer's rights stored procedure allow access to that procedure's referenced objects, before the procedure is executed. If a necessary privilege on a referenced object was revoked from the owner of a definer's rights procedure, then the procedure cannot be run by the owner or any other user.

How Procedure Privileges Affect Invoker's Rights

An invoker's rights procedure executes with all of the invoker's privileges. Oracle Database enables the privileges that were granted to the invoker through any of the invoker's enabled roles to take effect, unless a definer's rights procedure calls the invoker's rights procedure directly or indirectly. A user of an invoker's rights procedure needs privileges (granted to the user either directly or through a role) on objects that the procedure accesses through external references that are resolved in the schema of the invoker.

The invoker needs privileges at run time to access program references embedded in DML statements or dynamic SQL statements, because they are effectively recompiled at run time.

For all other external references, such as direct PL/SQL function calls, Oracle Database checks the privileges of the owner at compile time, but does not perform a run-time check. Therefore, the user of an invoker's rights procedure does not need privileges on external references outside DML or dynamic SQL statements. Alternatively, the developer of an invoker's rights procedure must only grant privileges on the procedure itself, not on all objects directly referenced by the invoker's rights procedure.

You can create a software bundle that consists of multiple program units, some with definer's rights and others with invoker's rights, and restrict the program entry points (controlled step-in). A user who has the privilege to run an entry-point procedure can also execute internal program units indirectly, but cannot directly call the internal programs. For very precise control over query processing, you can create a PL/SQL package specification with explicit cursors.


See Also:


How Procedure Privileges Affect Packages and Package Objects

A user with the EXECUTE object privilege for a package can execute any public procedure or function in the package, and can access or modify the value of any public package variable. You cannot grant specific EXECUTE privileges for individual constructs in a package. Therefore, you may find it useful to consider two alternatives for establishing security when developing procedures, functions, and packages for a database application. The following examples describe these alternatives.

Procedure Privileges and Packages and Package Objects: Example 1

Example 4-10 shows four procedures created in the bodies of two packages.

The following GRANT EXECUTE statements enable the big_bosses and little_bosses roles to run the appropriate procedures:

GRANT EXECUTE ON hire_fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses; 

Note:

Granting EXECUTE privilege for a package provides uniform access to all package objects.

Procedure Privileges and Packages and Package Objects: Example 2

This example shows four procedure definitions within the body of a single package. Two additional standalone procedures and a package are created specifically to provide access to the procedures defined in the main package.

CREATE PACKAGE BODY employee_changes AS 
  PROCEDURE change_salary(...) IS BEGIN ... END; 
  PROCEDURE change_bonus(...) IS BEGIN ... END; 
  PROCEDURE insert_employee(...) IS BEGIN ... END; 
  PROCEDURE delete_employee(...) IS BEGIN ... END; 
END employee_changes; 
 
CREATE PROCEDURE hire 
  BEGIN 
    employee_changes.insert_employee(...) 
  END hire; 
 
CREATE PROCEDURE fire 
  BEGIN 
    employee_changes.delete_employee(...) 
  END fire; 
 
PACKAGE raise_bonus IS 
  PROCEDURE give_raise(...) AS 
    BEGIN 
      employee_changes.change_salary(...) 
    END give_raise; 
 
  PROCEDURE give_bonus(...) 
    BEGIN 
      employee_changes.change_bonus(...) 
    END give_bonus; 

Using this method, the procedures that actually do the work (the procedures in the employee_changes package) are defined in a single package and can share declared global variables, cursors, on so on. By declaring top-level procedures, hire and fire, and an additional package, raise_bonus, you can grant selective EXECUTE privileges on procedures in the main package:

GRANT EXECUTE ON hire, fire TO big_bosses; 
GRANT EXECUTE ON raise_bonus TO little_bosses; 

Managing Type Privileges

The following sections describe the use of privileges for types, methods, and objects:

Object Privileges

The only object privilege that applies to named types is EXECUTE. If the EXECUTE privilege exists on a named type, then a user can use the named type to:

  • Define a table

  • Define a column in a relational table

  • Declare a variable or parameter of the named type

The EXECUTE privilege permits a user to invoke the methods in the type, including the type constructor. This is similar to the EXECUTE privilege on a stored PL/SQL procedure.

Method Execution Model

Method execution is the same as any other stored PL/SQL procedure.

Privileges Required to Create Types and Tables Using Types

To create a type, you must meet the following requirements:

  • You must have the CREATE TYPE system privilege to create a type in your schema or the CREATE ANY TYPE system privilege to create a type in the schema of another user. These privileges can be acquired explicitly or through a role.

  • The owner of the type must be explicitly granted the EXECUTE object privileges to access all other types referenced within the definition of the type, or have been granted the EXECUTE ANY TYPE system privilege. The owner cannot obtain the required privileges through roles.

  • If the type owner intends to grant access to the type to other users, then the owner must receive the EXECUTE privileges to the referenced types with the GRANT OPTION or the EXECUTE ANY TYPE system privilege with the ADMIN OPTION. If not, then the type owner has insufficient privileges to grant access on the type to other users.

To create a table using types, you must meet the requirements for creating a table and the following additional requirements:

  • The owner of the table must have been directly granted the EXECUTE object privilege to access all types referenced by the table, or has been granted the EXECUTE ANY TYPE system privilege. The owner cannot exercise the required privileges if these privileges were granted through roles.

  • If the table owner intends to grant access to the table to other users, then the owner must have the EXECUTE privilege to the referenced types with the GRANT OPTION or the EXECUTE ANY TYPE system privilege with the ADMIN OPTION. If not, then the table owner has insufficient privileges to grant access on the table.


See Also:

"Managing Table Privileges" for the requirements for creating a table

Privileges on Type Access and Object Access

Existing column-level and table-level privileges for DML statements apply to both column objects and row objects.

Table 4-5 lists the privileges for object tables.

Similar table privileges and column privileges apply to column objects. Retrieving instances does not in itself reveal type information. However, clients must access named type information to interpret the type instance images. When a client requests type information, Oracle Database checks for the EXECUTE privilege on the type.

Consider the following schema:

CREATE TYPE emp_type (
    eno NUMBER, ename CHAR(31), eaddr addr_t);
CREATE TABLE emp OF emp_t;

In addition, consider the following two queries:

SELECT VALUE(emp) FROM emp;
SELECT eno, ename FROM emp;

For either query, Oracle Database checks the SELECT privilege of the user for the emp table. For the first query, the user must obtain the emp_type type information to interpret the data. When the query accesses the emp_type type, Oracle Database checks the EXECUTE privilege of the user.

The second query, however, does not involve named types, so Oracle Database does not check type privileges.

In addition, by using the schema from the previous section, user3 can perform the following queries:

SELECT tab1.col1.attr2 FROM user2.tab1 tab1;
SELECT attr4.attr3.attr2 FROM tab3;

Note that in both SELECT statements, user3 does not have explicit privileges on the underlying types, but the statement succeeds because the type and table owners have the necessary privileges with the GRANT OPTION.

Oracle Database checks privileges on the following events, and returns an error if the client does not have the privilege for the action:

  • Pinning an object in the object cache using its REF value causes Oracle Database to check for the SELECT privilege on the containing object table.

  • Modifying an existing object or flushing an object from the object cache causes Oracle Database to check for the UPDATE privilege on the destination object table.

  • Flushing a new object causes Oracle Database to check for the INSERT privilege on the destination object table.

  • Deleting an object causes Oracle Database to check for the DELETE privilege on the destination table.

  • Pinning an object of a named type causes Oracle Database to check EXECUTE privilege on the object.

Modifying the attributes of an object in a client third-generation language application causes Oracle Database to update the entire object. Therefore, the user needs the UPDATE privilege on the object table. Having the UPDATE privilege on only certain columns of the object table is not sufficient, even if the application only modifies attributes corresponding to those columns. Therefore, Oracle Database does not support column-level privileges for object tables.

Type Dependencies

As with stored objects, such as procedures and tables, types being referenced by other objects are called dependencies. There are some special issues for types on which tables depend. Because a table contains data that relies on the type definition for access, any change to the type causes all stored data to become inaccessible. Changes that can cause this are when necessary privileges required to use the type are revoked, or the type or dependent types are dropped. If these actions occur, then the table becomes invalid and cannot be accessed.

A table that is invalid because of missing privileges can automatically become valid and accessible if the required privileges are granted again. A table that is invalid because a dependent type was dropped can never be accessed again, and the only permissible action is to drop the table.

Because of the severe effects that revoking a privilege on a type or dropping a type can cause, the SQL statements REVOKE and DROP TYPE, by default, implement restricted semantics. This means that if the named type in either statement has table or type dependents, then an error is received and the statement cancels. However, if the FORCE clause for either statement is used, then the statement always succeeds. If there are depended-upon tables, then they are invalidated.


See Also:

Oracle Database Reference for details about using the REVOKE, DROP TYPE, and FORCE clauses

Granting a User Privileges and Roles

This section contains:

It is also possible to grant roles to a user connected through a middle tier or proxy. This is discussed in "Using a Middle Tier Server for Proxy Authentication".

Granting System Privileges and Roles

You can use the GRANT SQL statement to grant system privileges and roles to users and roles. The following privileges are required:

  • To grant a system privilege, a user must be granted the system privilege with the ADMIN option or must be granted the GRANT ANY PRIVILEGE system privilege.

  • To grant a role, a user must be granted the role with the ADMIN option or was granted the GRANT ANY ROLE system privilege.

Example 4-11 grants the system privilege CREATE SESSION and the accts_pay role to the user jward.

Example 4-11 grants the EXECUTE privilege on the exec_dir directory object to the user jward.


Note:

Object privileges cannot be granted along with system privileges and roles in the same GRANT statement.

Granting Object Privileges

You can use the GRANT statement to grant object privileges to roles and users. To grant an object privilege, you must fulfill one of the following conditions:

  • You own the object specified.

  • You have been granted the GRANT ANY OBJECT PRIVILEGE system privilege. This privilege enables you to grant and revoke privileges on behalf of the object owner.

  • The WITH GRANT OPTION clause was specified when you were granted the object privilege.


    Note:

    System privileges and roles cannot be granted along with object privileges in the same GRANT statement.

Example 4-15 grants the SELECT, INSERT, and DELETE object privileges for all columns of the emp table to the users jfee and tsmith.

To grant all object privileges on the salary view to user jfee, use the ALL keyword as shown in the following example:

GRANT ALL ON salary TO jfee;

Note:

A grantee cannot regrant access to objects unless the original grant included the GRANT OPTION. Thus in the example just given, jfee cannot use the GRANT statement to grant object privileges to anyone else.

Granting Object Privileges on Behalf of the Object Owner

The GRANT ANY OBJECT PRIVILEGE system privilege enables users to grant and revoke any object privilege on behalf of the object owner. This privilege provides a convenient means for database and application administrators to grant access to objects in any schema without requiring that they connect to the schema. Login credentials do not need to be maintained for schema owners who have this privilege, which reduces the number of connections required during configuration.

This system privilege is part of the Oracle Database supplied DBA role and is thus granted (with the ADMIN option) to any user connecting AS SYSDBA (user SYS). As with other system privileges, the GRANT ANY OBJECT PRIVILEGE system privilege can only be granted by a user who possesses the ADMIN option.

The recorded grantor of access rights to an object is either the object owner or the person exercising the GRANT ANY OBJECT PRIVILEGE system privilege. If the grantor with GRANT ANY OBJECT PRIVILEGE does not have the object privilege with the GRANT OPTION, then the object owner is shown as the grantor. Otherwise, when that grantor has the object privilege with the GRANT OPTION, then that grantor is recorded as the grantor of the grant.


Note:

The audit record generated by the GRANT statement always shows the actual user who performed the grant.

For example, consider the following scenario. User adams possesses the GRANT ANY OBJECT PRIVILEGE system privilege. He does not possess any other grant privileges. He issues the following statement:

GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION;

If you examine the DBA_TAB_PRIVS view, then you will see that hr is shown as the grantor of the privilege:

SELECT GRANTEE, GRANTOR, PRIVILEGE, GRANTABLE
  FROM DBA_TAB_PRIVS 
  WHERE TABLE_NAME = 'EMPLOYEES' and OWNER = 'HR';

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT      YES       

Now assume that user blake also has the GRANT ANY OBJECT PRIVILEGE system. He issues the following statement:

GRANT SELECT ON HR.EMPLOYEES TO clark;

In this case, when you query the DBA_TAB_PRIVS view again, you see that blake is shown as being the grantor of the privilege:

GRANTEE  GRANTOR  PRIVILEGE  GRANTABLE
-------- -------- ---------  ----------
BLAKE    HR       SELECT     YES       
CLARK    BLAKE    SELECT     NO        

This occurs because blake already possesses the SELECT privilege on HR.EMPLOYEES with the GRANT OPTION.

Revoking Privileges and Roles from a User

This section contains:

Revoking Object Privileges

To revoke an object privilege, you must fulfill one of the following conditions:

  • You previously granted the object privilege to the user or role.

  • You possess the GRANT ANY OBJECT PRIVILEGE system privilege that enables you to grant and revoke privileges on behalf of the object owner.

You can only revoke the privileges that you, the person who granted the privilege, directly authorized. You cannot revoke grants that were made by other users to whom you granted the GRANT OPTION. However, there is a cascading effect. If the object privileges of the user who granted the privilege are revoked, then the object privilege grants that were propagated using the GRANT OPTION are revoked as well.

Assuming you are the original grantor of the privilege, the following statement revokes the SELECT and INSERT privileges on the emp table from users jfee and psmith:

REVOKE SELECT, INSERT ON emp FROM jfee, psmith;

The following statement revokes all object privileges for the dept table that you originally granted to the human_resource role:

REVOKE ALL ON dept FROM human_resources;

Note:

The GRANT OPTION for an object privilege cannot be selectively revoked. Instead, revoke the object privilege and then grant it again but without the GRANT OPTION. Users cannot revoke object privileges from themselves.

Revoking Object Privileges on Behalf of the Object Owner

The GRANT ANY OBJECT PRIVILEGE system privilege enables you to revoke any specified object privilege where the object owner is the grantor. This occurs when the object privilege is granted by the object owner, or on behalf of the owner by any user holding the GRANT ANY OBJECT PRIVILEGE system privilege.

In a situation where the object privilege was granted by both the owner of the object and the user executing the REVOKE statement (who has both the specific object privilege and the GRANT ANY OBJECT PRIVILEGE system privilege), Oracle Database only revokes the object privilege granted by the user issuing the REVOKE statement. This can be illustrated by continuing the example started in "Granting Object Privileges on Behalf of the Object Owner".

At this point, user blake granted the SELECT privilege on HR.EMPLOYEES to clark. Even though blake possesses the GRANT ANY OBJECT PRIVILEGE system privilege, he also holds the specific object privilege, thus this grant is attributed to him. Assume that user HR also grants the SELECT privilege on HR.EMPLOYEES to user clark. A query of the DBA_TAB_PRIVS view shows that the following grants are in effect for the HR.EMPLOYEES table:

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT       YES       
CLARK    BLAKE    SELECT       NO        
CLARK    HR       SELECT       NO        

User blake now issues the following REVOKE statement:

REVOKE  SELECT ON HR.EMPLOYEES FROM clark;

Only the object privilege for user clark granted by user blake is removed. The grant by the object owner, HR, remains.

GRANTEE  GRANTOR PRIVILEGE    GRANTABLE
-------- ------- -----------  ----------
BLAKE    HR       SELECT      YES       
CLARK    HR       SELECT      NO        

If blake issues the REVOKE statement again, then this time the effect is to remove the object privilege granted by adams (on behalf of HR), using the GRANT ANY OBEJCT PRIVILEGE system privilege.

Cascading Effects of Revoking Privileges

Depending on the type of privilege, there may be cascading effects when a privilege is revoked. This is discussed in the following sections:

Cascading Effects When Revoking Object Privileges

Revoking an object privilege can have cascading effects. Remember the following:

  • Object definitions that depend on a DML object privilege can be affected if the DML object privilege is revoked. For example, assume that the body of the test procedure includes a SQL statement that queries data from the emp table. If the SELECT privilege on the emp table is revoked from the owner of the test procedure, then the procedure can no longer be executed successfully.

  • When a REFERENCES privilege for a table is revoked from a user, any foreign key integrity constraints that are defined by the user and require the dropped REFERENCES privilege are automatically dropped. For example, assume that user jward is granted the REFERENCES privilege for the deptno column of the dept table. This user now creates a foreign key on the deptno column in the emp table that references the deptno column of the dept table. If the REFERENCES privilege on the deptno column of the dept table is revoked, then the foreign key constraint on the deptno column of the emp table is dropped in the same operation.

  • The object privilege grants propagated using the GRANT OPTION are revoked if the object privilege of a grantor is revoked. For example, assume that user1 is granted the SELECT object privilege with the GRANT OPTION, and grants the SELECT privilege on emp to user2. Subsequently, the SELECT privilege is revoked from user1. This REVOKE statement is also cascaded to user2. Any objects that depend on the revoked SELECT privilege of user1 and user2 can also be affected, as described earlier.

Object definitions that require the ALTER and INDEX DDL object privileges are not affected if the ALTER or INDEX object privilege is revoked. For example, if the INDEX privilege is revoked from a user that created an index on a table that belongs to another user, then the index continues to exist after the privilege is revoked.

Granting to and Revoking from the PUBLIC User Group

You can grant and revoke privileges and roles from the user group PUBLIC. Because PUBLIC is accessible to every database user, all privileges and roles granted to PUBLIC are accessible to every database user.

Security administrators and database users should grant a privilege or role to PUBLIC only if every database user requires the privilege or role. This recommendation reinforces the general rule that, at any given time, each database user should have only the privileges required to accomplish the current group tasks successfully.

Revoking a privilege from PUBLIC can cause significant cascading effects. If any privilege related to a DML operation is revoked from PUBLIC (for example, SELECT ANY TABLE or UPDATE ON emp), then all procedures in the database, including functions and packages, must be reauthorized before they can be used again. Therefore, be careful when you grant and revoke DML-related privileges to or from PUBLIC.


See Also:


Granting Roles Using the Operating System or Network

This section contains:

About Granting Roles Using the Operating System or Network

Instead of a security administrator explicitly granting and revoking database roles to and from users using GRANT and REVOKE statements, the operating system on which Oracle Database runs can grant roles to users at connect time. Roles can be administered using the operating system and passed to Oracle Database when a user creates a session. As part of this mechanism, the default roles of a user and the roles granted to a user with the ADMIN option can be identified. If the operating system is used to authorize users for roles, then all roles must be created in the database and privileges assigned to the role with GRANT statements.

Roles can also be granted through a network service.

The advantage of using the operating system to identify the database roles of a user is that privilege management for an Oracle database can be externalized. The security facilities offered by the operating system control user privileges. This option may offer advantages of centralizing security for several system activities, such as the following situation:

  • MVS Oracle administrators want RACF groups to identify database user roles.

  • UNIX Oracle administrators want UNIX groups to identify database user roles.

  • VMS Oracle administrators want to use rights identifiers to identify database user roles.

The main disadvantage of using the operating system to identify the database roles of a user is that privilege management can only be performed at the role level. Individual privileges cannot be granted using the operating system, but they can still be granted inside the database using GRANT statements.

A second disadvantage of using this feature is that, by default, users cannot connect to the database through the shared server or any other network connection if the operating system is managing roles. However, you can change this default as described in "Using Network Connections with Operating System Role Management".


Note:

The features described in this section are available only on some operating systems. See your operating system-specific Oracle Database documentation to determine if you can use these features.

Using Operating System Role Identification

To cause a database to use the operating system to identify the database roles of each user when a session is created, set the initialization parameter OS_ROLES to TRUE (and restart the instance, if it is currently running). When a user tries to create a session with the database, Oracle Database initializes the user security domain using the database roles identified by the operating system.

To identify database roles for a user, the operating system account for each Oracle Database user must have operating system identifiers (these may be called groups, rights identifiers, or other similar names) that indicate which database roles are to be available for the user. Role specification can also indicate which roles are the default roles of a user and which roles are available with the ADMIN option. No matter which operating system is used, the role specification at the operating system level follows the format:

ora_ID_ROLE[[_d][_a][_da]]

In this specification:

  • ID has a definition that varies on different operating systems. For example, on VMS, ID is the instance identifier of the database; on VMS, it is the computer type; and on UNIX, it is the system ID.


    Note:

    ID is case-sensitive to match your ORACLE_SID. ROLE is not case-sensitive.

  • ROLE is the name of the database role.

  • d is an optional character that indicates this role is to be a default role of the database user.

  • a is an optional character that indicates this role is to be granted to the user with the ADMIN option. This allows the user to grant the role to other roles only. Roles cannot be granted to users if the operating system is used to manage roles.


    Note:

    If either the d or a character is specified, then precede that character by an underscore (_).

For example, an operating system account might have the following roles identified in its profile:

ora_PAYROLL_ROLE1
ora_PAYROLL_ROLE2_a
ora_PAYROLL_ROLE3_d
ora_PAYROLL_ROLE4_da

When the corresponding user connects to the payroll instance of Oracle Database, role3 and role4 are defaults, while role2 and role4 are available with the ADMIN option.

When Do Grants and Revokes Take Effect?

Depending on what is granted or revoked, a grant or revoke takes effect at different times:

  • All grants and revokes of system and object privileges to anything (users, roles, and PUBLIC) take immediate effect.

  • All grants and revokes of roles to anything (users, other roles, PUBLIC) take effect only when a current user session issues a SET ROLE statement to reenable the role after the grant and revoke, or when a new user session is created after the grant or revoke.

You can see which roles are currently enabled by examining the SESSION_ROLES data dictionary view.

Specifying Default Roles

When a user logs on, Oracle Database enables all privileges granted explicitly to the user and all privileges in the default roles of the user.

You can set and alter a list of default roles for a user by using the ALTER USER SQL statement. The ALTER USER statement specifies roles that are to be enabled when a user connects to the database. The user must have been directly granted the roles with a GRANT statement, or the roles must have been created by the user with the CREATE ROLE privilege. For information about the restrictions of the DEFAULT ROLE clause of the ALTER USER statement, see Oracle Database SQL Language Reference.

Example 4-18 sets the default roles payclerk and pettycash for user jane:

You cannot set default roles for a user in the CREATE USER statement. When you first create a user, the default user role setting is ALL, which causes all roles subsequently granted to the user to be default roles. Use the ALTER USER statement to limit the default user roles.


Caution:

When you create a role (other than a global role or an application role), it is granted implicitly to you, and your set of default roles is updated to include the new role. You can grant as many roles as you want to a user, but remember that the user can have no more than 148 roles enabled by default. Otherwise, the user will be unable to log in to the database and an ORA-28031: maximum of 148 enabled roles exceeded error is raised. When aggregate roles, such as the DBA role, are granted to a user, the roles granted to the role are included in the number of roles the user has. For example, if a role has 20 roles granted to it and you grant that role to the user, then the user now has 21 additional roles. Therefore, when you grant new roles to a user, use the DEFAULT ROLE clause of the ALTER USER statement to ensure that not too many roles are specified as that user's default roles.

Managing Fine-Grained Access in PL/SQL Packages and Types

You can configure user access control to external network services and wallets through the UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR PL/SQL packages, the DBMS_LDAP PL/SQL package, and the HttpUriType type.

This section contains:

About Fine-Grained Access Control to External Network Services

To configure fine-grained access control to external network services, you create an access control list (ACL), which is stored in Oracle XML DB. You can create the access control list by using Oracle XML DB itself, or by using the DBMS_NETWORK_ACL_ADMIN and DBMS_NETWORK_ACL_UTILITY PL/SQL packages. This guide explains how to use these packages to create and manage the access control list. To create an access control list by using Oracle XML DB and for general conceptual information about access control lists, see Oracle XML DB Developer's Guide.

This feature enhances security for network connections because it restricts the external network hosts that a database user can connect to using the PL/SQL network utility packages UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR, the DBMS_LDAP PL/SQL package, and the HttpUriType type. Otherwise, an intruder who gained access to the database could maliciously attack the network, because, by default, the PL/SQL utility packages are created with the EXECUTE privilege granted to PUBLIC users. These PL/SQL network utility packages, and the DBMS_NETWORK_ACL_ADMIN and DBMS_NETWORK_ACL_UTILITY packages, support both IP Version 4 (IPv4) and IP Version 6 (IPv6) addresses. This guide explains how to manage access control to both versions. For detailed information about how the IPv4 and IPv6 notation works with Oracle Database, see Oracle Database Net Services Administrator's Guide.


See Also:

"Tutorial: Adding an E-Mail Alert to a Fine-Grained Audit Policy" for an example of configuring access control to external network services for e-mail alerts

Creating an Access Control List for External Network Services

When you create access control lists for network connections, you should create one access control list dedicated to a group of common users, for example, users who need access to a particular application that resides on a specific host computer. For ease of administration and for good system performance, do not create too many access control lists. Network hosts accessible to the same group of users should share the same access control list.

To create the access control list by using the DBMS_NETWORK_ACL_ADMIN package, follow these steps:

Step 1: Create the Access Control List and Its Privilege Definitions

Use the DBMS_NETWORK_ACL_ADMIN.CREATE_ACL procedure to create the content of the access control list. It contains a name of the access control list, a brief description, and privilege settings for one user or role that you want to associate with the access control list. In an access control list, privileges for each user or role are grouped together as an access control entry (ACE). An access control list must have the privilege settings for at least one user or role.


Note:

You cannot import or export the access control list settings by using the Oracle Database import or export utilities such as Oracle Data Pump.

for example:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl          => 'file_name.xml', 
  description  => 'file description',
  principal    => 'user_or_role',
  is_grant     => TRUE|FALSE, 
  privilege    => 'connect|resolve',
  start_date   => null|timestamp_with_time_zone,
  end_date     => null|timestamp_with_time_zone); 
END;

In this specification:

To add more users or roles to the access control list, or grant additional privileges to one user or role, use the DBMS_NETWORK_ACL.ADD_PRIVILEGE procedure. The syntax is as follows:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( 
  acl         => 'file_name.xml', 
  principal   => 'user_or_role',
  is_grant    => TRUE|FALSE, 
  privilege   => 'connect|resolve', 
  position    => null|value, 
  start_date  => null|timestamp_with_time_zone,
  end_date    => null|timestamp_with_time_zone);
END;

As you can see, the parameters to add the privilege are the similar to those in the CREATE_ACL procedure, except that description is not included and the position parameter, which sets the order of precedence for multiple users or roles, was added. Because you now are adding more than one user or role, you may want to consider setting their precedence. "Setting the Precedence of Multiple Users and Roles in One Access Control List" provides more information.

Other DBMS_NETWORK_ACL_ADMIN procedures that are available for this step are DELETE_PRIVILEGE and DROP_ACL.

At this stage, you have created an access control list that defines the privileges needed to connect to a network host. However, the access control list has no effect until you complete Step 2: Assign the Access Control List to One or More Network Hosts.

Step 2: Assign the Access Control List to One or More Network Hosts

After you create the access control list, then you are ready to assign it to one or more network host computers. You can use the DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL procedure to do so.

For example:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
  acl         => 'file_name.xml',
  host        => 'network_host', 
  lower_port  => null|port_number,
  upper_port  => null|port_number); 
END;

In this specification:

Only one access control list can be assigned to any host computer, domain, or IP subnet, and if specified, the TCP port range. When you assign a new access control list to a network target, Oracle Database unassigns the previous access control list that was assigned to the same target. However, Oracle Database does not drop the access control list. You can drop the access control list by using the DROP_ACL procedure. To remove an access control list assignment, use the UNASSIGN_ACL procedure.

Depending on how you create and maintain the access control list, the two steps may overlap. For example, you can create an access control list that has privileges for five users in it, and then apply it to two host computers. Later on, you can modify this access control list to have different or additional users and privileges, and assign it to different or additional host computers.

All access control list changes, including the assignment to network hosts, are transactional. They do not take effect until the transaction is committed.

You can find information about existing privileges and network connections by using the data dictionary views described in Table 4-6, "Data Dictionary Views That Display Information about Access Control Lists".

For information about using the DBMS_NETWORK_ACL_ADMIN package, see Oracle Database PL/SQL Packages and Types Reference.

Configuring Access Control to a Wallet

This method lets you grant access to the passwords and client certificates that are stored in an Oracle wallet to users to authenticate themselves to an external Web server. This enables the user to retrieve protected Web pages from the Web server.

This section contains:

Step 2: Create an Access Control List that Grants the Wallet Privileges

After you have created the wallet, you are ready to create the access control list that will assign the password or client certificate privilege the user needs to use password credentials in the wallet for HTTP authentication.

For example:

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl         => 'file_name.xml',
  description => 'description',
  principal   => 'user_or_role',
  is_grant    => TRUE|FALSE,
  privilege   => 'privilege';
...
END;

In this specification:

  • acl: Enter a name for the ACL, and make a note of this name. You will need this name in Step 3: Assign the Access Control List to the Wallet, next. Oracle Database creates this file relative to the /sys/acls directory in the XML DB Repository in the database. Include the .xml extension. For example:

    acl         => 'hr_access_wallet_acl.xml',
    
  • description: Enter a brief description of the purpose of this file. For example:

    description => 'Wallet ACL for the hr_access application',
    
  • principal: Enter the user account or role being granted or denied privileges. For example:

    principal   => 'HR_CLERK',
    

    Enter this name using case sensitive characters. For example, if the database stores the role name HR_CLERK in all capital letters, entering it in mixed or lower-case letters will not work. You can find the user accounts and roles in the current database instance by querying the DBA_USERS and DBA_ROLES data dictionary views. Typically, user names and roles are stored in upper-case letters.

    If you want to add multiple users, or if you want to grant this user an additional privilege, you can use the DBMS_NETWORK_ACL.ADD_PRIVILEGE procedure after you have created this access control list XML file.

  • is_grant: Enter either TRUE or FALSE, to indicate whether the privilege is to be granted or denied. For example:

    is_grant    => TRUE,
    
  • privilege: Enter one of the following settings using lowercase letters and hyphens. Remember that the privilege name is case-sensitive.

    • use-passwords to give the user permission to use passwords in the wallet

    • use-client-certificates to authenticate the user with a client certificate in the wallet

    For example:

    privilege    => 'use-client-certificates');
    

Step 3: Assign the Access Control List to the Wallet

In this step, you assign this access control list to the wallet you created earlier. Afterward, you can check your settings by querying the DBA_WALLET_ACLS data dictionary view.

For example:

BEGIN
...
 DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL (
  acl         => 'file_name.xml',
  wallet_path => 'file:path_to_directory_containing_wallet');
END;

In this specification:

Step 4: Make the HTTP Request with the Passwords and Client Certificates

In this step, you use the UTL_HTTP PL/SQL package to create a request context object that is used privately with the HTTP request and its response. For detailed information about the UTL_HTTP package, see Oracle Database PL/SQL Packages and Types Reference.

For example:

DECLARE
 req_context UTL_HTTP.REQUEST_CONTEXT_KEY;
 req         UTL_HTTP.REQ;
BEGIN
 req_context := UTL_HTTP.CREATE_REQUEST_CONTEXT (
              wallet_path          => 'file:path_to_directory_containing_wallet',
              wallet_password      => 'wallet_password'|NULL);
 req := UTL_HTTP.BEGIN_REQUEST( 
              url                  => 'URL_to_application',
              request_context      => 'request_context'|NULL);
 ...
END;

In this specification:

  • req_context: Use the UTL_HTTP.CREATE_REQUEST_CONTEXT_KEY datatype to create the request context object. This object stores a randomly-generated numeric key that Oracle Database uses to identify the request context. The UTL_HTTP.CREATE_REQUEST_CONTEXT function creates the request context itself.

  • req: Use the UTL_HTTP.REQ datatype to create the object that will be used to begin the HTTP request. You will refer to this object later on, when you set the user name and password from the wallet to access a password-protected Web page.

  • wallet_path: Enter the path to the directory that contains the wallet. Ensure that this path is the same path you specified when you created access control list in Step 3: Assign the Access Control List to the Wallet in the previous section.You must include file: before the directory path. Do not use environment variables, such as $ORACLE_HOME.

    For example:

    wallet_path     => 'file:/oracle/wallets/hr_access_access',
    
  • wallet_password: Enter the password used to open the wallet. The default is NULL, which is used for auto-login wallets. For example:

    wallet_password      => NULL);
    
  • url: Enter the URL to the application that uses the wallet.

    For example:

    url                  => 'www.hr_access.example.com',
    
  • request_context: Enter the name of the request context object that you created earlier in this section. This object prevents the wallet from being shared with other applications in the same database session.

    For example:

    request_context      => req_context);
    

Using a Request Context to Hold the Wallet When Sharing the Session with Other Applications

You should use a request context to hold the wallet when the database session is shared with other applications. If your application has exclusive use of the database session, you can hold the wallet in the database session by using the SET_WALLET procedure instead.

For example:

DECLARE
 req         UTL_HTTP.REQ;
BEGIN
 UTL_HTTP.SET_WALLET(
              path          => 'file:path_to_directory_containing_wallet',
              password      => 'wallet_password'|NULL);
 req := UTL_HTTP.BEGIN_REQUEST( 
              url           => 'URL_to_application');
 ...
END;

If the protected URL being requested requires the user name and password to authenticate, then use the SET_AUTHENTICATION_FROM_WALLET procedure to set the user name and password from the wallet to authenticate.

Using Only a Client Certificate to Authenticate

If the protected URL being requested requires only the client certificate to authenticate, the BEGIN_REQUEST function sends the necessary client certificate from the wallet. assuming the user has been granted the use-client-certificates privilege in the ACL assigned to the wallet. The authentication should succeed at the remote Web server and the user can proceed to retrieve the HTTP response by using the GET_RESPONSE function.

Using the Password to Authenticate

If the protected URL being requested requires the username and password to authenticate, you should use the SET_AUTHENTICATION_FROM_WALLET procedure to set the username and password from the wallet to authenticate.

For example:

DECLARE
 req_context UTL_HTTP.REQUEST_CONTEXT_KEY;
 req         UTL_HTTP.REQ;
BEGIN
...
 UTL_HTTP.SET_AUTHENTICATION_FROM_WALLET(
  r               => HTTP_REQUEST,
  alias           => 'alias_to_retrieve_credentials_stored_in_wallet',
  scheme          => 'AWS|Basic', 
  for_proxy       => TRUE|FALSE);
END;

In this specification:

  • r: Enter the HTTP request defined in the UTL_HTTP.BEGIN_REQUEST procedure that you created above, in the previous section. For example:

    r               => req,
    
  • alias: Enter the alias used to identify and retrieve the user name and password credential stored in the Oracle wallet. For example, assuming the alias used to identify this user name and password credential is hr_access.

    alias           => 'hr_access',
    
  • scheme: Enter one of the following:

    • AWS: Specifies the Amazon Simple Storage Service (S3) scheme. Use this scheme only if you are configuring access to the Amazon.com Web site. (Contact Amazon for more information about this setting.)

    • Basic: Specifies HTTP basic authentication. The default is Basic.

    For example:

    scheme          => 'Basic',
    
  • for_proxy: Specify whether the HTTP authentication information is for access to the HTTP proxy server instead of the Web server. The default is FALSE.

    For example:

    for_proxy       => TRUE);
    

The use of the user name and password in the wallet requires the use-passwords privilege to be granted to the user in the ACL assigned to the wallet.

Examples of Creating Access Control Lists

The following examples demonstrate how to create access control lists.


See Also:

Oracle Database Vault Administrator's Guide for a tutorial that demonstrates how to use an access control list when an administrator must use the UTL_MAIL PL/SQL package to configure an e-mail alert

Example of an Access Control List for a Single Role and Network Connection

Example 4-19 shows how you would create an access control list called us-example-com-permissions.xml to grant users who have the ACCT_MGR role access to network services that run on the host us.example.com.

This example creates the us-example-com-permissions.xml file in the /sys/acls directory, which is the default location. The XML file appears as follows:

<acl description="Network connection permission for ACCT_MGR" 
  xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
  xmlns:plsql="http://xmlns.oracle.com/plsql" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
  xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd    http://xmlns.oracle.com/xdb/acl.xsd">
  <security-class>plsql:network</security-class>
  <ace>
    <grant>true</grant>
    <principal>ACCT_MGR</principal>
    <privilege><plsql:connect/></privilege>
 </ace>
</acl>

The xmlns and xsi elements are fixed and should not be modified, for example, in a text editor.

You can check the contents of the access control list in SQL*Plus. See Oracle XML DB Developer's Guide for examples.

Example of an Access Control List with Multiple Roles Assigned to Multiple Hosts

Example 4-20 shows how to create a slightly more complex version of the us-example-com-permissions.xml access control list. In this example, you specify multiple role privileges and their precedence position, and assigned to multiple host computers.

See"Specifying a Group of Network Host Computers" and "Precedence Order for a Host Computer in Multiple Access Control List Assignments" for more information about host names. See also "Setting the Precedence of Multiple Users and Roles in One Access Control List" to determine the order of multiple ACE elements in the access control list XML file.

The us-example-com-permissions.xml appears as follows:

<acl description="Network connection permission for ACCT_MGR and ACCT_CLERK" 
  xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
  xmlns:plsql="http://xmlns.oracle.com/plsql" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
  xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd    http://xmlns.oracle.com/xdb/acl.xsd">
  <security-class>plsql:network</security-class>
  <ace>
    <grant>true</grant>
    <principal>ACCT_MGR</principal>
    <privilege><plsql:resolve/></privilege>
  </ace>
  <ace>
    <grant>true</grant>
    <principal>ACCT_CLERK</principal>
    <privilege><plsql:connect/></privilege>
  </ace>
</acl>

Example 4-21 shows how the DBA_NETWORK_ACL_PRIVILEGES data dictionary view displays the privilege granted in the previous access control list.


Example 4-22 shows how the DBA_NETWORK_ACLS data dictionary view displays the host assignment of the access control list.

In these examples, the ACCT_MGR role has the resolve privilege to the first host, and the ACCT_CLERK role has the connect privilege to the first and second target hosts. The ACCT_MGR role does not have the resolve privilege to the second host because a port range is specified in the assignment to the second host.

To check the contents of the access control list in SQL*Plus, see Oracle XML DB Developer's Guide for examples.

Example of an Access Control List for Using Passwords in a Non-Shared Wallet

Example 4-23 configures wallet access for two Human Resources department roles, hr_clerk and hr_manager. These roles use the use-passwords privilege to access passwords stored in the wallet. In this example, the wallet will not be shared with other applications within the same database session.

Example 4-23 Configuring ACL Access Using Passwords in a Non-Shared Wallet

/* 1. At a command prompt, create the wallet. The following example uses the 
      user name hr_access as the alias to identify the user name and password 
      stored in the wallet. You must use this alias name when you call the
      SET_AUTHENTICATION_FROM_WALLET procedure later on. */ 
$ mkstore -wrl $ORACLE_HOME/wallets/hr_access_access -create
Enter password: password
Enter password again: password
$ mkstore -wrl $ORACLE_HOME/wallets/hr_access_access -createCredential hr_access hr_usr 
Your secret/Password is missing in the command line
Enter your secret/Password: password
Re-enter your secret/Password: password
Enter wallet password: password

/* 2. In SQL*Plus, create an access control list to grant privileges for the 
      wallet. The following example grants the use-passwords privilege to the
      hr_clerk and hr_manager roles, and then it assigns this ACL to the wallet.*/ 
BEGIN
  DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(
    acl         => 'hr_access_wallet_acl.xml', 
    description => 'Wallet ACL for hr_access application',
    principal   => 'HR_CLERK', -- Must be in upper case
    is_grant    => TRUE,
    privilege   => 'use-passwords');
 
  DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
    acl         => 'hr_access_wallet_acl.xml', 
    principal   => 'HR_MANAGER',
    is_grant    => TRUE,
    privilege   => 'use-passwords');
 
  DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL(
    acl         => 'hr_access_wallet_acl.xml', 
    wallet_path => 'file:/oracle/wallets/hr_access_access');
END;
/
COMMIT;

/* 3. Create a request context and request object, and then set the 
      authentication for the wallet. */
DECLARE
  req_context  UTL_HTTP.REQUEST_CONTEXT_KEY;
  req          UTL_HTTP.REQ;

BEGIN
 req_context := UTL_HTTP.CREATE_REQUEST_CONTEXT(
     wallet_path          => 'file:/oracle/wallets/hr_access_access',
     wallet_password      => NULL,
     enable_cookies       => TRUE,
     max_cookies          => 300,
     max_cookies_per_site => 20);
  req := UTL_HTTP.BEGIN_REQUEST(
     url                  => 'www.hr_access.example.com',
     request_context      => req_context);
  UTL_HTTP.SET_AUTHENTICATION_FROM_WALLET(
     r                    => req,
     alias                => 'hr_access'),
     scheme               => 'Basic', 
     for_proxy            => FALSE);
END;
/

Example of an Access Control List for Wallets in a Shared Database Session

Example 4-24 is almost the same as Example 4-23, except that it configures the wallet to be used for a shared database session; that is, all applications within the current database session will have access to this wallet.

Example 4-24 Configuring ACL Access for a Wallet in a Shared Database Session

/* Follow these steps:
   1. Use Oracle Wallet Manager to create the wallet and add the client
      certificate. See Oracle Database Advanced Security Administrator's Guide 
      for detailed information about using Oracle Wallet Manager. 

   2. In SQL*Plus, create an access control list to grant privileges for the 
      wallet. The following example grants the use-client-certificates privilege 
      to the hr_clerk and hr_manager roles, then it assigns this ACL to the 
      wallet. */
BEGIN
  DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(
    acl         => 'hr_access_wallet_acl.xml', 
    description => 'Wallet ACL for hr_access application',
    principal   => 'HR_CLERK', -- Must be in upper case
    is_grant    => TRUE,
    privilege   => 'use-client-certificates');
 
  DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
    acl         => 'hr_access_wallet_acl.xml', 
    principal   => 'HR_MANAGER',
    is_grant    => TRUE,
    privilege   => 'use-client-certificates');
 
  DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL(
    acl         => 'hr_access_wallet_acl.xml', 
    wallet_path => 'file:/oracle/wallets/hr_access_access');
END;
/
COMMIT;

/* 3. Create a request object to handle the HTTP authentication for the wallet.*/
DECLARE
  req  UTL_HTTP.req;
BEGIN
  UTL_HTTP.SET_WALLET(
   path            => 'file: $ORACLE_HOME/wallets/hr_access_access',
   password        => NULL);
 req := UTL_HTTP.BEGIN_REQUEST(
   url             => 'www.hr_access.example.com',
   method          => 'POST',
   http_version    => NULL,
   request_context => NULL);
END;
/

Precedence Order for a Host Computer in Multiple Access Control List Assignments

For multiple access control lists that are assigned to the host computer and its domains, the access control list that is assigned to the host computer takes precedence over those assigned to the domains. The access control list assigned to a domain has a lower precedence than those assigned to the subdomains.

For example, Oracle Database first selects the access control list assigned to the host server.us.example.com, ahead of other access control lists assigned to its domains. If additional access control lists were assigned to the sub domains, their order of precedence is as follows:

  1. server.us.example.com

  2. *.us.example.com

  3. *.example.com

  4. *.com

  5. *

Similarly, for multiple access control lists that are assigned to the IP address (both IPv4 and IPv6) and the subnets it belongs to, the access control list that is assigned to the IP address takes precedence over those assigned to the subnets. The access control list assigned to a subnet has a lower precedence than those assigned to the smaller subnets it contains.

For example, Oracle Database first selects the access control list assigned to the IP address 192.0.2.3, ahead of other access control lists assigned to the subnets it belongs to. If additional access control lists were assigned to the subnets, their order of precedence is as follows:

  1. 192.0.2.3 (or ::ffff:192.0.2.3)

  2. 192.0.2.3/31 (or ::ffff:192.0.2.3/127)

  3. 192.0.2.3/30 (or ::ffff:192.0.2.3/126)

  4. 192.0.2.3/29 (or ::ffff:192.0.2.3/125)

  5. ...

  6. 192.0.2.3/24 (or ::ffff:192.0.2.3/120 or 192.0.2.*)

  7. ...

  8. 192.0.2.3/16 (or ::ffff:192.0.2.3/112 or 192.0.*)

  9. ...

  10. 192.0.2.3/8 (or ::ffff:192.0.2.3/104 or 192.*)

  11. ...

  12. ::ffff:192.0.2.3/95

  13. ::ffff:192.0.2.3/94

  14. ...

  15. *

Checking Privilege Assignments That Affect User Access to a Network Host

Database administrators can use the DBA_NETWORK_ACL_PRIVILEGES data dictionary view to query network privileges that have been granted to or denied from database users and roles in the access control lists, and whether those privileges take effect during certain times only. Using the information provided by the view, you may need to combine the data to determine if a user is granted the privilege at the current time, the roles the user has, the order of the access control entries, and so on. To simplify this privilege evaluation, you can use the following DBMS_NETWORK_ACL_ADMIN functions to check the privilege granted to a user in an access control list:

  • CHECK_PRIVILEGE: Checks if the specified privilege is granted to or denied from the specified user in an access control list. This procedure identifies the access control list by its path in the XML DB Repository. Use CHECK_PRIVILEGE if you want to evaluate a single access control list with a known path.

  • CHECK_PRIVILEGE_ACLID: Similar to the CHECK_PRIVILEGE procedure, except that it enables you to specify the object ID of the access control list. Use CHECK_PRIVILEGE_ACLID if you need to evaluate multiple access control lists, when you query the DBA_NETWORK_ACLS data dictionary view. For better performance, call CHECK_PRIVILEGE_ACLID on multiple access control lists rather than using CHECK_PRIVILEGE on each one individually.

Users without database administrator privileges do not have the privilege to access the access control lists or to invoke those DBMS_NETWORK_ACL_ADMIN functions. However, they can query the USER_NETWORK_ACL_PRIVILEGES data dictionary view to check their privileges instead.

Database administrators and users can use the following DBMS_NETWORK_ACL_UTILITY functions to determine if two hosts, domains, or subnets are equivalent, or if a host, domain, or subnet is equal to or contained in another host, domain, or subnet:

  • EQUALS_HOST: Returns a value to indicate if two hosts, domains, or subnets are equivalent

  • CONTAINS_HOST: Returns a value to indicate if a host, domain, or subnet is equal to or contained in another host, domain, or subnet, and the relative order of precedence of the containing domain or subnet for its ACL assignments

If you do not use IPv6 addresses, database administrators and users can use the following DBMS_NETWORK_ACL_UTILITY functions to generate the list of domains or IPv4 subnet a host belongs to and to sort the access control lists by their order of precedence according to their host assignments:

  • DOMAINS: Returns a list of the domains or IP subnets whose access control lists may affect permissions to a specified network host, subdomain, or IP subnet

  • DOMAIN_LEVEL: Returns the domain level of a given host

The following sections explain how database administrators and users can check permissions for the user to connect to a network host or to perform domain name resolutions:

How a DBA Can Check User Network Connection and Domain Privileges

A database administrator can query the DBA_NETWORK_ACLS view to determine which access control lists are present for a specified host computer. This view shows the access control lists that determine the access to the network connection or domain, and then determines if each access control list grants (GRANTED), denies (DENIED), or does not apply (NULL) to the access privilege of the user. Only the database administrator can query this view.

The following sections provide examples that demonstrate how the database administrator can check user privileges for network connections and domain name resolution.

Database Administrator Checking User Connection Privileges

Example 4-25 shows how a database administrator can check the privileges for user preston to connect to www.us.example.com. Remember that the user name you enter for the user parameter in the CHECK_PRIVILEGE_ACLID procedure is case sensitive. In this example, entering the user name preston is correct, but entering Preston or preston is incorrect.

You can find the users in the current database instance by querying the DBA_USERS data dictionary view, for example:

SELECT USERNAME FROM DBA_USERS;

In this example, user preston was granted privileges for all the network host connections found for www.us.example.com. However, suppose preston had been granted access to a host connection on port 80, but then denied access to the host connections on ports 3000–3999. In this case, you need to create one access control list for the host connection on port 80, and a separate access control list for the host connection on ports 3000–3999.

Database Administrator Checking User Privileges for Domain Name Resolution

Example 4-26 shows how a database administrator can check the privileges of user preston to perform domain name resolution for the host www.us.example.com. In this example, only the access control lists assigned to hosts without a port range because the resolve privilege has no effect to those with a port range. (Remember that the user name you enter for the user parameter in CHECK_PRIVILEGE_ACLID is case sensitive.)

How Users Can Check Their Network Connection and Domain Privileges

Users can query the USER_NETWORK_ACL_PRIVILEGES view to check their network and domain permissions. The USER_NETWORK_ACL_PRIVILEGES view is PUBLIC, so all users can select from it.

This view hides the access control lists from the user. It evaluates the permission status for the user (GRANTED or DENIED) and filters out the NULL case because the user does not need to know when the access control lists do not apply to him or her. In other words, Oracle Database only shows the user on the network hosts that explicitly grant or deny access to him or her. Therefore, the output does not display the *.example.com and * that appear in the output from the database administrator-specific DBA_NETWORK_ACLS view.

The following sections provide examples that demonstrate how a database administrator can check user permissions for network connections and domain name resolution.

User Checking His or Her Network Connection Privileges

Example 4-27 shows how user preston can check her privileges to connect to www.us.example.com.

User Checking Own Privileges for Domain Name Resolution

Example 4-26 shows how the user preston can check her privileges to perform domain name resolution for www.us.example.com:

Setting the Precedence of Multiple Users and Roles in One Access Control List

By default, Oracle Database grants or denies privileges to users and roles based on their physical position in the access control list. The first user or role listed is granted or denied privileges first, followed the second user or role, and so on. For instance, suppose the code in Example 4-20 defined one role, ACCT_MGR, and two users, sebastian and preston, and the access control list XML file ordered these three as follows:

<acl ...>
  ...
  <ace>
    <principal>ACCT_MGR</principal>
    <grant>true</grant>
    <privilege><plsql:connect/></privilege>
   </ace>
  <ace>
    <principal>SEBASTIAN</principal>
    <grant>false</grant>
    <privilege><plsql:connect/></privilege>
  </ace>
  <ace>
    <principal>PRESTON</principal>
    <grant>false</grant>
    <privilege><plsql:connect/></privilege>
  </ace>
</acl>

ACCT_MGR is granted permissions first, followed by permission denials for sebastian and then preston. However, if sebastian and preston have been granted the ACCT_MGR role, they still could log in, because the ACCT_MGR role appears first in the list.

Even though these two users were granted the acct_mgr role, their specific jobs do not require them to have access to the www.example.com host. If the positions were reversed—the acct_mgr role listed after sebastian and preston—they would be denied the privilege of connecting to the network. To set the order of precedence of the ACE elements irrespective of their physical location in the CREATE_ACL and ADD_PRIVILEGE statements, you can use the position attribute.

For example, the following statements set the ACE elements in the resultant XML file in this order:

  1. The ACE element for sebastian appears first.

  2. The ACE element for preston appears second.

  3. The acct_mgr role appears last.

In this case, neither of these users will be able to connect, because their grant privileges, which are set to FALSE, are evaluated before the acct_mgr role.

BEGIN
 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
  acl          => 'us-example-com-permissions.xml', 
  description  => 'Network connection permission for ACCT_MGR and users', 
  principal    => 'ACCT_MGR',
  is_grant     => TRUE,
  privilege    => 'connect');
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( 
  acl          => 'us-example-com-permissions.xml', 
  principal    => 'SEBASTIAN', 
  is_grant     => FALSE, 
  privilege    => 'connect',
  position     => 1); 
 DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( 
  acl          => 'us-example-com-permissions.xml', 
  principal    => 'PRESTON', 
  is_grant     => FALSE, 
  privilege    => 'connect',
  position     => 2); 
END;
/

Finding Information About Access Control Lists Configured for User Access

Table 4-6 lists data dictionary views that you can use to find information about existing access control lists. See Oracle Database Reference for more information about these views.

Table 4-6 Data Dictionary Views That Display Information about Access Control Lists


ViewDescription

DBA_NETWORK_ACLS

Shows the access control list assignments to the network hosts. The SELECT privilege on this view is granted to the SELECT_CATALOG_ROLE role only.

DBA_NETWORK_ACL_PRIVILEGES

Shows the network privileges defined in all access control lists that are currently assigned to network hosts. The SELECT privilege on this view is granted to the SELECT_CATALOG_ROLE role only.

DBA_WALLET_ACLS

Lists wallets that have been assigned access control lists.

USER_NETWORK_ACL_PRIVILEGES

Shows the status of the network privileges for the current user to access network hosts. The SELECT privilege on the view is granted to PUBLIC.

ViewDescription

ALL_COL_PRIVS

Describes all column object grants for which the current user or PUBLIC is the object owner, grantor, or grantee

ALL_COL_PRIVS_MADE

Lists column object grants for which the current user is object owner or grantor.

ALL_COL_PRIVS_RECD

Describes column object grants for which the current user or PUBLIC is the grantee

ALL_TAB_PRIVS

Lists the grants on objects where the user or PUBLIC is the grantee

ALL_TAB_PRIVS_MADE

Lists the all object grants made by the current user or made on the objects owned by the current user.

ALL_TAB_PRIVS_RECD

Lists object grants for which the user or PUBLIC is the grantee

DBA_COL_PRIVS

Describes all column object grants in the database

DBA_EPG_DAD_AUTHORIZATION

Describes the database access descriptors (DAD) that are authorized to use a different user's privileges.

DBA_TAB_PRIVS

Lists all grants on all objects in the database

DBA_ROLES

Lists all roles that exist in the database, including secure application roles

DBA_ROLE_PRIVS

Lists roles directly granted to users and roles

DBA_SYS_PRIVS

Lists system privileges granted to users and roles

ROLE_ROLE_PRIVS

Lists roles granted to other roles. Information is provided only about roles to which the user has access.

ROLE_SYS_PRIVS

Lists system privileges granted to roles. Information is provided only about roles to which the user has access.

ROLE_TAB_PRIVS

Lists object privileges granted to roles. Information is provided only about roles to which the user has access.

USER_COL_PRIVS

Describes column object grants for which the current user is the object owner, grantor, or grantee

USER_COL_PRIVS_MADE

Describes column object grants for which the current user is the grantor

USER_COL_PRIVS_RECD

Describes column object grants for which the current user is the grantee

USER_EPG_DAD_AUTHORIZATION

Describes the database access descriptors (DAD) that are authorized to use a different user's privileges.

USER_ROLE_PRIVS

Lists roles directly granted to the current user

USER_TAB_PRIVS

Lists grants on all objects where the current user is the grantee

USER_SYS_PRIVS

Lists system privileges granted to the current user

USER_TAB_PRIVS_MADE

Lists grants on all objects owned by the current user

USER_TAB_PRIVS_RECD

Lists object grants for which the current user is the grantee

SESSION_PRIVS

Lists the privileges that are currently enabled for the user

SESSION_ROLES

Lists the roles that are currently enabled to the user


This section provides some examples of using these views. For these examples, assume the following statements were issued:

CREATE ROLE security_admin IDENTIFIED BY password;

GRANT CREATE PROFILE, ALTER PROFILE, DROP PROFILE,
    CREATE ROLE, DROP ANY ROLE, GRANT ANY ROLE, AUDIT ANY,
    AUDIT SYSTEM, CREATE USER, BECOME USER, ALTER USER, DROP USER
    TO security_admin WITH ADMIN OPTION;

GRANT SELECT, DELETE ON SYS.AUD$ TO security_admin;

GRANT security_admin, CREATE SESSION TO swilliams;

GRANT security_admin TO system_administrator;

GRANT CREATE SESSION TO jward;

GRANT SELECT, DELETE ON emp TO jward;

GRANT INSERT (ename, job) ON emp TO swilliams, jward;

See Also:

Oracle Database Reference for a detailed description of these data dictionary views

PK@7PKj?OEBPS/intro.htmg Introducing Oracle Database Security

1 Introducing Oracle Database Security

This chapter contains:

About Oracle Database Security

You can use the default Oracle Database features to configure security in the following areas for your Oracle Database installation:

In addition, Chapter 10, "Keeping Your Oracle Database Secure," provides guidelines that you should follow when you secure your Oracle Database installation.

Additional Database Security Resources

In addition to the security resources described in this guide, Oracle Database provides the following database security products:

  • Advanced security features. See Oracle Database Advanced Security Administrator's Guide for information about advanced features such as transparent data encryption, wallet management, network encryption, and the RADIUS, Kerberos, Secure Sockets Layer authentication.

  • Oracle Label Security. Oracle Label Security secures database tables at the row level, allowing you to filter user access to row data based on privileges. See Oracle Label Security Administrator's Guide for detailed information about Oracle Label Security.

  • Oracle Database Vault. Oracle Database Vault provides fine-grained access control to your sensitive data, including protecting data from privileged users. Oracle Database Vault Administrator's Guide describes how to use Oracle Database Vault.

  • Oracle Audit Vault. Oracle Audit Vault collects database audit data from sources such as Oracle Database audit trail tables, database operating system audit files, and database redo logs. Using Oracle Audit Vault, you can create alerts on suspicious activities, and create reports on the history of privileged user changes, schema modifications, and even data-level access. Oracle Audit Vault Administrator's Guide explains how to administer Oracle Audit Vault.

  • Oracle Enterprise User Security. Oracle Enterprise User Security enables you to manage user security at the enterprise level. Oracle Database Enterprise User Security Administrator's Guide explains how to configure Oracle Enterprise User Security.

In addition to these products, you can find the latest information about Oracle Database security, such as new products and important information about security patches and alerts, by visiting the Security Technology Center on Oracle Technology Network at

http://www.oracle.com/technology/deploy/security/index.html

PK[RDl g PKj? OEBPS/toc.ncxk Oracle® Database Security Guide, 11g Release 2 (11.2) Cover Table of Contents List of Examples List of Figures List of Tables Oracle Database Security Guide 11g Release 2 (11.2) Preface What's New in Oracle Database Security? Introducing Oracle Database Security Managing Security for Oracle Database Users Configuring Authentication Configuring Privilege and Role Authorization Managing Security for Application Developers Using Application Contexts to Retrieve User Information Using Oracle Virtual Private Database to Control Data Access Developing Applications Using the Data Encryption API Verifying Security Access with Auditing Keeping Your Oracle Database Secure Glossary Index Copyright PK劦PKj?OEBPS/cover.htm Cover

Oracle Corporation

PKJPKj?OEBPS/users.htm Managing Security for Oracle Database Users

2 Managing Security for Oracle Database Users

This chapter contains:

Creating User Accounts

This section contains:

For guidelines about creating and managing user accounts and passwords, see the following sections:

Creating a New User Account

You create a database user with the CREATE USER statement. To create a user, you must have the CREATE USER system privilege. Because it is a powerful privilege, a database administrator or security administrator is usually the only user who has the CREATE USER system privilege.

Example 2-1 creates a user and specifies the user password, default tablespace, temporary tablespace where temporary segments are created, tablespace quotas, and profile. It also grants the user the minimum privilege, CREATE SESSION, to log in to the database session.

Replace password with a password that is secure. See "Minimum Requirements for Passwords" for more information.

A newly created user cannot connect to the database until you grant the user the CREATE SESSION system privileges. So, immediately after you create the user account, use the GRANT SQL statement to grant the user these privileges. If the user must access Oracle Enterprise Manager, you should also grant the user the SELECT ANY DICTIONARY privilege.


Note:

As a security administrator, you should create your own roles and assign only those privileges that are needed. For example, many users formerly granted the CONNECT privilege did not need the additional privileges CONNECT used to provide. Instead, only CREATE SESSION was actually needed, and in fact, that is the only privilege CONNECT presently retains.

Creating organization-specific roles gives an organization detailed control of the privileges it assigns, and protects it in case Oracle Database changes the roles that it defines in future releases. For example, both CONNECT and RESOURCE roles will be deprecated in future Oracle Database releases. Chapter 4, "Configuring Privilege and Role Authorization," discusses how to create and manage roles.


Assigning a Default Tablespace for the User

Each user should have a default tablespace. When a schema object is created in the user's schema and the DDL statement does not specify a tablespace to contain the object, Oracle Database stores the object in the default user's tablespace.

The default setting for the default tablespaces of all users is the SYSTEM tablespace. If a user does not create objects, and has no privileges to do so, then this default setting is fine. However, if a user is likely to create any type of object, then you should specifically assign the user a default tablespace, such as the USERS tablespace. Using a tablespace other than SYSTEM reduces contention between data dictionary objects and user objects for the same data files. In general, do not store user data in the SYSTEM tablespace.

You can use the CREATE TABLESPACE SQL statement to create a permanent default tablespace other than SYSTEM at the time of database creation, to be used as the database default for permanent objects. By separating the user data from the system data, you reduce the likelihood of problems with the SYSTEM tablespace, which can in some circumstances cause the entire database to become nonfunctional. This default permanent tablespace is not used by system users, that is, SYS, SYSTEM, and OUTLN, whose default permanent tablespace is SYSTEM. A tablespace designated as the default permanent tablespace cannot be dropped. To accomplish this goal, you must first designate another tablespace as the default permanent tablespace. You can use the ALTER TABLESPACE SQL statement to alter the default permanent tablespace to another tablespace. Be aware that this will affect all users or objects created after the ALTER DDL statement commits.

You can also set a user default tablespace during user creation, and change it later with the ALTER USER statement. Changing the user default tablespace affects only objects created after the setting is changed.

When you specify the default tablespace for a user, also specify a quota on that tablespace.

In the following CREATE USER statement, the default tablespace for user jward is data_ts, and his quota on that tablespace is 500K:

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk;

Assigning a Tablespace Quota for the User

You can assign each user a tablespace quota for any tablespace (except a temporary tablespace). Assigning a quota accomplishes the following:

  • Users with privileges to create certain types of objects can create those objects in the specified tablespace.

  • Oracle Database limits the amount of space that can be allocated for storage of a user's objects within the specified tablespace to the amount of the quota.

By default, a user has no quota on any tablespace in the database. If the user has the privilege to create a schema object, then you must assign a quota to allow the user to create objects. At a minimum, assign users a quota for the default tablespace, and additional quotas for other tablespaces in which they can create objects.

The following CREATE USER statement assigns the following quotas for the test_ts and data_ts tablespaces:

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk;

You can assign a user either individual quotas for a specific amount of disk space in each tablespace or an unlimited amount of disk space in all tablespaces. Specific quotas prevent a user's objects from using too much space in the database.

You can assign quotas to a user tablespace when you create the user, or add or change quotas later. (You can find existing user quotas by querying the USER_TS_QUOTAS view.) If a new quota is less than the old one, then the following conditions remain true:

  • If a user has already exceeded a new tablespace quota, then the objects of a user in the tablespace cannot be allocated more space until the combined space of these objects is less than the new quota.

  • If a user has not exceeded a new tablespace quota, or if the space used by the objects of the user in the tablespace falls under a new tablespace quota, then the user's objects can be allocated space up to the new quota.

Assigning a Temporary Tablespace for the User

You should assign each user a temporary tablespace. When a user executes a SQL statement that requires a temporary segment, Oracle Database stores the segment in the temporary tablespace of the user. These temporary segments are created by the system when performing sort or join operations. Temporary segments are owned by SYS, which has resource privileges in all tablespaces.

In the following, the temporary tablespace of jward is temp_ts, a tablespace created explicitly to contain only temporary segments.

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk;

To create a temporary tablespace, use the CREATE TEMPORARY TABLESPACE SQL statement.

If you do not explicitly assign the user a temporary tablespace, then Oracle Database assigns the user the default temporary tablespace that was specified at database creation, or by an ALTER DATABASE statement at a later time. If there is no default temporary tablespace explicitly assigned, then the default is the SYSTEM tablespace or another permanent default established by the system administrator. Do not store user data in the SYSTEM tablespace. Assigning a tablespace to be used specifically as a temporary tablespace eliminates file contention among temporary segments and other types of segments.


Note:

If your SYSTEM tablespace is locally managed, then users must be assigned a specific default (locally managed) temporary tablespace. They may not be allowed to default to using the SYSTEM tablespace because temporary objects cannot be placed in locally managed permanent tablespaces.

You can set the temporary tablespace for a user at user creation, and change it later using the ALTER USER statement. If you are logged in as user SYS, you can set a quota for the temporary tablespace, and other space allocations. (Only user SYS can do this, because all space in the temporary tablespace belongs to user SYS.) You can also establish tablespace groups instead of assigning individual temporary tablespaces.


See Also:


Altering User Accounts

Users can change their own passwords. However, to change any other option of a user security domain, you must have the ALTER USER system privilege. Security administrators are typically the only users that have this system privilege, as it allows a modification of any user security domain. This privilege includes the ability to set tablespace quotas for a user on any tablespace in the database, even if the user performing the modification does not have a quota for a specified tablespace.

You can alter user security settings with the ALTER USER SQL statement. Changing user security settings affects the future user sessions, not current sessions.

Example 2-2 shows how to use the ALTER USER statement to alter the security settings for the user avyrros:

The ALTER USER statement here changes the security settings for the user avyrros as follows:

  • Authentication is changed to use the operating system account of the user avyrros.

  • The default and temporary tablespaces are explicitly set for user AVYRROS.

  • The user avyrros is given a 100M quota for the DATA_TS tablespace.

  • The quota on the test_ts is revoked for the user avyrros.

  • The user avyrros is assigned the clerk profile.

Changing the User Password

Most users can change their own passwords with the PASSWORD statement, as follows:

PASSWORD andy
Changing password for andy
New password: password
Retype new password: password

No special privileges (other than those to connect to the database and create a session) are required for a user to change his or her own password. Encourage users to change their passwords frequently. "Guidelines for Securing Passwords" provides advice on the best ways to secure passwords. You can find existing users for the current database instance by querying the ALL_USERS view.

Users can also use the ALTER USER SQL statement change their passwords. For example:

ALTER USER andy 
 IDENTIFIED BY password

However, for better security, use the PASSWORD statement to change the account's password. The ALTER USER statement displays the new password on the screen, where it can be seen by any overly curious coworkers. The PASSWORD command does not display the new password, so it is only known to you, not to your co-workers. In both cases, the password is encrypted on the network.

Users must have the PASSWORD and ALTER USER privilege to switch between methods of authentication. Usually, only an administrator has this privilege.


See Also:


Configuring User Resource Limits

This section contains:

Types of System Resources and Limits

Oracle Database can limit the use of several types of system resources, including CPU time and logical reads. In general, you can control each of these resources at the session level, call level, or both, as discussed in the following sections:

Limiting Other Resources

Oracle Database provides for limiting several other resources at the session level:

Managing Resources with Profiles

A profile is a named set of resource limits and password parameters that restrict database usage and instance resources for a user. You can assign a profile to each user, and a default profile to all others. Each user can have only one profile, and creating a new one supersedes an earlier version.

You need to create and manage user profiles only if resource limits are a requirement of your database security policy. To use profiles, first categorize the related types of users in a database. Just as roles are used to manage the privileges of related users, profiles are used to manage the resource limits of related users. Determine how many profiles are needed to encompass all types of users in a database and then determine appropriate resource limits for each profile.

In general, the word profile refers to a collection of attributes that apply to a user, enabling a single point of reference for any of multiple users that share those exact attributes. User profiles in Oracle Internet Directory contain attributes pertinent to directory usage and authentication for each user. Similarly, profiles in Oracle Label Security contain attributes useful in label security user administration and operations management. Profile attributes can include restrictions on system resources. You can use Database Resource Manager to set these types of resource limits.

Profile resource limits are enforced only when you enable resource limitation for the associated database. Enabling this limitation can occur either before starting up the database (using the RESOURCE_LIMIT initialization parameter) or while it is open (using the ALTER SYSTEM statement).

Though password parameters reside in profiles, they are unaffected by RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled. In Oracle Database, Database Resource Manager primarily handles resource allocations and restrictions.


See Also:


Deleting User Accounts

When you drop a user account, Oracle Database removes the user account and associated schema from the data dictionary. It also immediately drops all schema objects contained in the user schema, if any.


Notes:

  • If a user schema and associated objects must remain but the user must be denied access to the database, then revoke the CREATE SESSION privilege from the user.

  • Do not attempt to drop the SYS or SYSTEM user. Doing so corrupts your database.


A user that is currently connected to a database cannot be dropped. To drop a connected user, you must first terminate the user sessions using the SQL statement ALTER SYSTEM with the KILL SESSION clause. You can find the session ID (SID) by querying the V$SESSION view.

Example 2-3 shows how to query V$SESSION and displays the session ID, serial number, and user name for user ANDY.

Example 2-4 shows how to stop the session for user andy.


You can drop a user from a database using the DROP USER statement. To drop a user and all the user schema objects (if any), you must have the DROP USER system privilege. Because the DROP USER system privilege is powerful, a security administrator is typically the only type of user that has this privilege.

If the schema of the user contains any dependent schema objects, then use the CASCADE option to drop the user and all associated objects and foreign keys that depend on the tables of the user successfully. If you do not specify CASCADE and the user schema contains dependent objects, then an error message is returned and the user is not dropped.

Before dropping a user whose schema contains objects, thoroughly investigate which objects the schema contains and the implications of dropping them. You can find the objects owned by a particular user by querying the DBA_OBJECTS view.

Example 2-5 shows how to find the objects owned by user andy.

(Enter the user name in capital letters.) Pay attention to any unknown cascading effects. For example, if you intend to drop a user who owns a table, then check whether any views or procedures depend on that particular table.

Example 2-6 drops the user andy and all associated objects and foreign keys that depend on the tables owned by andy.


See Also:

Oracle Database Administrator's Guide for more information about terminating sessions

Finding Information About Database Users and Profiles

This section contains:

Using Data Dictionary Views to Find Information About Users and Profiles

Table 2-1 lists data dictionary views that contain information about database users and profiles. For detailed information about these views, see Oracle Database Reference.

The following sections present examples of using these views. These examples assume that the following statements have been run:

CREATE PROFILE clerk LIMIT
    SESSIONS_PER_USER 1
    IDLE_TIME 30
    CONNECT_TIME 600;

CREATE USER jfee
    IDENTIFIED BY password
    DEFAULT TABLESPACE users
    TEMPORARY TABLESPACE temp_ts
    QUOTA 500K ON users
    PROFILE clerk;

CREATE USER dcranney
    IDENTIFIED BY password
    DEFAULT TABLESPACE users
    TEMPORARY TABLESPACE temp_ts
    QUOTA unlimited ON users;

CREATE USER userscott
     IDENTIFIED BY password;

Listing All Users and Associated Information

To find all users and their associated information as defined in the database, query the DBA_USERS view. For detailed information on the DBA_USERS view, see Oracle Database Reference.

For example:

SELECT USERNAME, PROFILE, ACCOUNT_STATUS, AUTHENTICATION_TYPE FROM DBA_USERS;
 
USERNAME        PROFILE         ACCOUNT_STATUS   AUTHENTICATION_TYPE
--------------- --------------- ---------------  -------------------
SYS             DEFAULT         OPEN             PASSWORD
SYSTEM          DEFAULT         OPEN             PASSWORD
USERSCOTT       DEFAULT         OPEN             PASSWORD
JFEE            CLERK           OPEN             GLOBAL
DCRANNEY        DEFAULT         OPEN             EXTERNAL 

Listing All Tablespace Quotas

Use the DBA_TS_QUOTAS view to list all tablespace quotas specifically assigned to each user. (For detailed information on this view, see Oracle Database Reference.) For example:

SELECT * FROM DBA_TS_QUOTAS;

TABLESPACE    USERNAME    BYTES     MAX_BYTES    BLOCKS    MAX_BLOCKS
----------    ---------  --------   ----------   -------   ----------
USERS         JFEE              0       512000         0          250
USERS         DCRANNEY          0           -1         0           -1

When specific quotas are assigned, the exact number is indicated in the MAX_BYTES column. This number is always a multiple of the database block size, so if you specify a tablespace quota that is not a multiple of the database block size, then it is rounded up accordingly. Unlimited quotas are indicated by -1.

Listing All Profiles and Assigned Limits

The DBA_PROFILE view lists all profiles in the database and associated settings for each limit in each profile. (For detailed information on this view, see Oracle Database Reference.) For example:

SELECT * FROM DBA_PROFILES
   ORDER BY PROFILE;

PROFILE             RESOURCE_NAME              RESOURCE   LIMIT             
-----------------   ---------------            ---------- --------------
CLERK               COMPOSITE_LIMIT            KERNEL     DEFAULT
CLERK               FAILED_LOGIN_ATTEMPTS      PASSWORD   DEFAULT
CLERK               PASSWORD_LIFE_TIME         PASSWORD   DEFAULT
CLERK               PASSWORD_REUSE_TIME        PASSWORD   DEFAULT
CLERK               PASSWORD_REUSE_MAX         PASSWORD   DEFAULT
CLERK               PASSWORD_VERIFY_FUNCTION   PASSWORD   DEFAULT
CLERK               PASSWORD_LOCK_TIME         PASSWORD   DEFAULT
CLERK               PASSWORD_GRACE_TIME        PASSWORD   DEFAULT
CLERK               PRIVATE_SGA                KERNEL     DEFAULT
CLERK               CONNECT_TIME               KERNEL     600    
CLERK               IDLE_TIME                  KERNEL     30     
CLERK               LOGICAL_READS_PER_CALL     KERNEL     DEFAULT
CLERK               LOGICAL_READS_PER_SESSION  KERNEL     DEFAULT
CLERK               CPU_PER_CALL               KERNEL     DEFAULT
CLERK               CPU_PER_SESSION            KERNEL     DEFAULT
CLERK               SESSIONS_PER_USER          KERNEL     1      
DEFAULT             COMPOSITE_LIMIT            KERNEL     UNLIMITED
DEFAULT             PRIVATE_SGA                KERNEL     UNLIMITED
DEFAULT             SESSIONS_PER_USER          KERNEL     UNLIMITED
DEFAULT             CPU_PER_CALL               KERNEL     UNLIMITED
DEFAULT             LOGICAL_READS_PER_CALL     KERNEL     UNLIMITED
DEFAULT             CONNECT_TIME               KERNEL     UNLIMITED
DEFAULT             IDLE_TIME                  KERNEL     UNLIMITED
DEFAULT             LOGICAL_READS_PER_SESSION  KERNEL     UNLIMITED
DEFAULT             CPU_PER_SESSION            KERNEL     UNLIMITED
DEFAULT             FAILED_LOGIN_ATTEMPTS      PASSWORD   10
DEFAULT             PASSWORD_LIFE_TIME         PASSWORD   180
DEFAULT             PASSWORD_REUSE_MAX         PASSWORD   UNLIMITED
DEFAULT             PASSWORD_LOCK_TIME         PASSWORD   1
DEFAULT             PASSWORD_GRACE_TIME        PASSWORD   7
DEFAULT             PASSWORD_VERIFY_FUNCTION   PASSWORD   UNLIMITED
DEFAULT             PASSWORD_REUSE_TIME        PASSWORD   UNLIMITED
32 rows selected. 

Viewing Memory Use for Each User Session

To find the memory use for each user session, query the V$SESSION view. (For detailed information on this view, see Oracle Database Reference. The following query lists all current sessions, showing the Oracle Database user and current User Global Area (UGA) memory use for each session:

SELECT USERNAME, VALUE || 'bytes' "Current UGA memory"
   FROM V$SESSION sess, V$SESSTAT stat, V$STATNAME name
WHERE sess.SID = stat.SID
   AND stat.STATISTIC# = name.STATISTIC-#
   AND name.NAME = 'session uga memory';

USERNAME                       Current UGA memory
------------------------------ ---------------------------------------------
                               18636bytes
                               17464bytes
                               19180bytes
                               18364bytes
                               39384bytes
                               35292bytes
                               17696bytes
                               15868bytes
USERSCOTT                      42244bytes
SYS                            98196bytes
SYSTEM                         30648bytes

11 rows selected.

To see the maximum UGA memory allocated to each session since the instance started, replace 'session uga memory' in the preceding query with 'session uga memory max'.

PK˥TPKj?OEBPS/img/cncpt082.gif9GIF89a???ߟ___oooOOO///!,`dihlp,tmx<pH,Ȥrl:ШtJZج nxL.sW8x|N~{BkA ^iEAfGШˋ\ӫUR>s r(@PxP4` ƃ,lhames :N1a bV1r Q Rރ&7aʔ3U̢4o%[ RIӞL.9GO0IYRUNHCTc.nڇ>Gx2ߌavb8 bM Eqc&!~7:PU0hz˫M$鹄S#i`jkGvzvP *|[>H|ˠVr>[M[ nuOCy'YtB) : |M@݉_~+E @A D"h yN<6;M pwPz'Hban~NuN<6AZ iPIW?:1#:LHQI2H < 0DInNBach 1qgJddĠ9DlйFoIf*5@C)O WIHۦtF@&M'ğj9Ol 7.PEp*zΫFz鐙~7S$ss&4#xΰ `NH;j1.F"足U徂b; L7 iDnl\B'\Dhʴ lB}JG2{C{#0G5;^mde>IJ H8bAN]ޢl`7<$6Do !PtI`MDᕗ-h'VNvfꎷF8g==0+92?J/I룩=[::Z-.ϗ9GL Yb +M$H&00{z Ma4 ipmQVWy!шX }G̡HC%`(F$G9rlĔȀ"3)# BP{'0MFH($BE d": x@|ADMetI3*×Dx󭱊éDi\L Lb[2@ \^:ESPs 3 ΃ Kġв/|j"py <멏{aB9%K uE%d38YZ2 tBHN# J͇  MP|JD$I]Oɠ& P~6IGO- PI"!Z'OZTq)M̠@ iEzj(X(Xj"uHd4$&1>zdh2j(y#%k+էM߷wSȱ me ZlK<1SR՟B%LhPYȱ(P#n+jݹR bx\@ KLrbOP.W+cmЛw¹rʳ=6\ؕ{_JwNo=4`a+} a(0YnH8tnK sW|[!+% z'ťE@#Bo'T٥@r9dYfƝz`91kNq2fK8aMxcg wTsݜg8Sm 7{~(hKcٵC.ElGPV-KkETAg\.jg}eprShW3;HTC^W[w,n _NBHfc,=ֶ;^[VN Ey,M EFl› k_e8Ulʾ4' VLD{4`ty^=f"BMx/8>}Q|ό% I /܁-ǹ2%|5?Zv-| ;"I skzIOm}.Pn`G: K`MQIiRJX@%+r>%=E}afBn2'lY S9>x%ނ'2A]‹DϹc?0X/_?ןPO_҃8-0,[w =!4 8 / ~  _o , }1}a.F ; sueI'x  =Kbw7SXi`M X y`fR Tc8- h [L2hchdFO( x P)w琅Z %^h S[qxd+h=nX W%h%gF9 Xb7vg!5d px Um8 SUЈL#"H8bY(##7hpbIЋ8~GbH hh Hfh hxI ~8ɐu 萾pXؐ  i`e0WQ 9d3y"%i6Tda` yx5QّɁNIc[89bEidq s0tFyy|ٗg~9Yyqr甌}טi ȀzPSP7Q*{*^M<@Z[|`|qꤧ},Z\yOƀd2ʵj P\plWRl5Ǒ9 ɔ|Ѡɜɞɠ <□5tZʬ # @Yoɵ@א7iSɸl c0X/4c 3yhdH М AW?8#` 2A8Ta@3\`7-#VFͬCL<Z0O ̓\g *(}} %_@6mH\=ҞT`+,kUX%,3 A<qSe@R ԚA@sWDd8"HzկlDݢk 1O` a͡hM`(oxP=cmumqs }mȆ}Ȉ،:9ؒ-<ٖ- q 1'/ ٖ,Qx]ףץ}ƫשͰ{#ۚw^#RYUP5 !Cd;C_inˉ[C+{=ݭ׋ Oa#g[`&7Q΁j bڶC m` !~[tHH+ XQJ༤2W|`]ـ̟nPP! +(;QEF `۴XAAis[~ѻ`xorȯ?:U[&(C-w*~o(^YE"mz'\=@ r)sƻ- ^L0kߊPA|  0F|R^ tq'trl..ӫ! TnuA}![ AQ K"RmzELҶDL}u, 7.# 23g7f[N5q!{^ d^[X7Mevp2'?!@PPX E4eoj20BͩJ[w\Ī&H|"Ag,kD[#Ҥ=K(=Z=7o:H_Dj':iުu>QiBTP&.7 ej3ƾ}śU@,_ ٠- h±<ӵ}㹾 &9"%|B) b,1Y("5 ` 8ng<)"$2E(1$4RVZ]j"GKO'>? # tG,9w9P/›:غiԿi TgI/Vjx|k#ICKHG%ʖ+ST̘6לIPM>S'BS ӦNlyԪVb TF מbϢUEkڶnmO+ӂ2eaWn|}&&š"n,YbKہx Z4;07\KxMÛ'|i #{H N*\E6.A)h "!\1ڢjR$ MOҞ .Z(]0NU趏gG  |$ p|>\A H\Ch"& 0|p%GZv;Zo?\%0ջǥl ElNM[ 䧍AK#o}Sb)oD 4 @X- 6Km`$0a`@v2  i֠4$qX vxb`0=BP~ T.eD DE : BqPL!K`a'yP,'z]CρO+9PE @?Qz]~?( 8= p0 )0z!]& @sX'ٛ+`P9 xlyȁph>̨"Ѐ+:t]e#e_b#p0r*эa@ @JKCApq=ZG @%"C&7E4``T6lq0B@N6^XS`v!@/9 39&p3e ~x |#"i!J%C%: fC@z@B16Ѐ5zԪbNK*/0`=6@"d݌7(s,0 5&cl+|a ,2Cl`SZӞvx3`&A)pDظ~ɆbxA` /3C{ N y  ZkCApq`8/P·+L*78堓’d'aMX_&n3H4$)Izs6)5*L6g5 `!k-|l!|]A{WmHoz+fM*mAl| ? `4K2j1KJjЃ#Y p ")Y`'O . a e2J6YA7j+2MK14.%_rMXcф 0=7#vdG*yn?J| &8hVsbT@rsv/-.jkn UVX]^`FFHlebghkӣvwzڬ|~GGIUVX־ˆpqt`ac]^`_`b^_a545`ad[\_434\]_EEFˋRRTģkloŲΐ[[^CCD×vx{φDDF,Fõӯ H;*\Ȱ0#JH!Ċ3j"Ǐ Ctqɓ(S*˗"YœIB6sIg2N9IQW>pjFУPMzliӧRj}IUSN8@ကRD,ʝ{޵N@PRD1A D˸r &B0%aCYaEHP@"8pѸs+L8a.mУw 80 .*sG 1VpŒ!8! Aހ.0. 22 V$p]vˁ(bOvh,NWb06&@4UW8d 0 "P039CN Hz@ ؈P\z9ifhfl pvfhviV95= |r0LЁ/G-58L@ـL]d{=6cWPl$`¸J/]<|Ӹ1:Xy E;<@7Q@Tn[NB 0 }n:-> ¹ gbNG;z/cp)>`-j|Ұmn^.э@˦o׭|t |oڂ \@*w;w4]Wፀ tCRKA8q`\q;owAѣ(dƻ  J)aH,dRbN< |^eHpφ1/P BxV$qv"_>o5Ģnf.Z%p&EFqc);:Q;0qb)c,W;&l (AE:fT-"8zW iB# =4NlIJSfQ88ZCE,iI K~ &_=_wCXEp]јA)Sǹ1yX\0@,)lRu,XFBs,%:R\,;_F a@=KJ₟,~rR$s.T. =E&k3AL0H@@F}gt0 .GZ%4P3D.1E8 /`h !PP[40-HT`x04X*^5+YE" $XHj<TZkQIOY5ڜ+KTVV]Bh(2n / @*`yQ:p^u+nI %e#BUe(/  &@P@'bUO l< $XU+\9$l3xM?ZW @r.ѯ= kSȺ6!Ar@e+C(x`p )eժncavm"+pa7UvivQ)/@2cUf۪? ^ҏ(b@ɋeO~rj *Yp!c. Y>W`p?(8ru2(zrT|xsWgOÜU=v4!mI\K&YtgeP'~6%|jݕ}WW*}Wq~]wzxz$v&F[[qWsXRoƷqW̧xCetAVI(@ugw2Ѝ m U $0CTWSy d7v1I.10%@p$.+`0<[E(w l~SH&7!!MiԄ#tNP)pڳPuj>y/fQi~GWJH}ACz{ѶeXVɗ.v)‹q*~s!T"KFwY$^JxaazfCl 'p 'X @ pȚ<ژ_+P,SP`z8\ 8r: - +֮B.xp$01ryR'@GcFym..#`-yi<3R,0#:B9, p"L#3"p@y!(a+\vmI'H0j 3<#G$׍- u 1S$H_1E$*6n 7@ 11Pu{yv˷z۷{i-I{"zʴ  .19C(>! x?5_65pPO p!% P,$ s9-‹0N `Բ^ (@# `EaA@@U$i$L%p$Z/ )$`0 Δ7p:{/p:ۿ<\l"lqO .5_ y$P(1%©PŌT8c Zk,-j.0 4@5Kk$P`t3@šPÿ{ú.`DscHm~ż gi2p$7_E$"J$ JKR/Ų1pi6@Ȭ%O)7؞bzQ\ : .Ӳ$4$% @ :0`"0?@+@S7, "^A j)EcӜ#=WX9 0S01Ѭ / ЪХ: <:ܿ:p:0`#p#K&60Q=Q}.f>Ӳ!9/(Zϧ`6"p@ !PuD S].@l1a 6 8M 9؊،M`XqR&gGAЖ0qՆ1|C3بP0=2a xj h}l 0c-@ (Ʊ־̆ ؄IۻͧF!gxH&}'`3P;l|M,P) # L2wwuwƣ 1g!=@ҭ) `k1nïsh:<>@Br^HNu1gޫ*UN81%@ OA-Xc榀~@bmNStv˾~n:~Ͱ@2< ˮ@fֿ,7MP>>N3_ /o ގqH{> B?D_$ns(o1"XX\^M뮉j,jl@%H/%iM3O*N*պ=dPV2p%j!>$eu? ,H!m#}뚑q[ =20`1 +; 0  Ys칟޹~6P+: @|"B !`00IYiy *:JZjzc)*+`{ ۀ!|@|q|qp0Mbm == Ҡ *03(HC/?O_o/.H Q"8+q <0… Q )VY*ڥׯ`0$ ٲgRTv-@!AON 8<{ 4f(8`A (`ԩTZzN_͂eQ^#XH̜Av50륚\H@ >8ŌX@h!͜;{a-stEiV/ƤHd@|4 Po\0>l@c6ވc:c>yudJVB XHDd(^j& V3ťK@T-7 x0An grIgv)%t K hƒ%VUGŀ2|6- عfb'JL   KxUfġyjmzmQZ\)ArN*Pj $ y !lMIp0AB:枋.'P= -42֌@SM:P fbGl /"9 kpIh@PeIS9P8p2|l. P@TDV !MB @ H| ]P@fp`$%$x 5f!8lD1].pH-(Y @@ .,Py^ p@ ,TS~Ar|!~P 6# A7|NA V<{ ߢ51 BTc=`i@QsP@M]S11h8j0QBa8OQe8YW@F)3ZTH&XȀ|5E肂>9u h1J;VBVS!Aq32pњآ\Ap &1[R-8+ybwR$Q=EuI4u$`Ԕ`q < &@ tܥ.mH! `*殫مi7+LAyzDzX)*.+kݬ8(o/ tl\ln6Eon pR 0ZL` |@ fК@ H&Q" x2b}>ġ(KZ`%͠f"4h$ߞ$Y$vad95jUZL pJ%8*[ $  @@JPmPIH EYP[Y" [E@$g8zid`Вe1qH`U`1D`@% 0D-YdK6o2.lʚD Ao@sٓj {vUw:M'nv?[SHA7`IuX\rYL-;廧[rlmT5'uu+7*l L{/ ֍n/t? owŔ+tH jl"rc'fXIWX;!4޼&Hzԫ uZ-gQxhJ(^v?Nu&)|]__Ր*e@EqTx,0^dpqg$uq%eQ V p$E;=c%61m@zW:3 LKՉW )WyO^Pcgi.)ceunU^6 ~WY :nFp0 J gH,9S`:SUe3U# *0p:hk .PX=DcOX7u..e7 =&xxg :* lP?܆ZiI5P$FZR@W0Bc<ln@(Y lҙMv"HU [.g60Vu~(@Kix6DHq7`jͨ" =y{'l`M{ `b ֕3p!+U00{5 )`G$~Ž| 9uExmw'KRbhuH$bt%U_Z: lmqZ[ wCd]\xXPyW*A5 gDY}%#` PZ, AGf[;W"7Նuy US{G{$^* Q-淖ilG'b93`l ]`ӊbz.ne6`2(X%A[.:2鏪2\zÔq&мQѭmqk :'Ш"z旇T\n wQ )`|Ok" Fޚ;Mӄ͛ֆ&̆p28=D[msiT[u~غw{E2pgd3S̳q&b#`r`Y" (57 U$Х֙rX `.`2QDl I 8 W>5Y][h#KCz[h\ = /o: h~$K.M b~!~.@7zEWe^x ڶqWg,{&-d&ԩnFGnvHWVWntQjaAov!G$o6+j8=m=37t+88l=m@,$%0cE~)2Pr+ݎʾ.kl20uxGkl=}u0 1`)૕ǖCBl9= `U~_>('s,\:>X 7.p\0h:0F>lGw)yQ֗tYECtsy'\ 'H0f ']FQ!)hIHF Y 4 2PuH .$el@CbW9+4][{ZvvX[@ʤ1 Х -ezTWo.߰OFbi %u%(^u3[ , 3 3!/"3 :+$"#,1%3-. %$!$h(ƒy8#PcAXB`8DB5\Wa4(C-&&Onڴϟ@ JT(y@@e4J-s*5VjʵWH @ˢ~ Zu1nʝK]`4S{7\[p La|g[7ǐ#Kx23t[٫2FiVzZ1s5M8Pb9\* @ ֵE+;L T&\+6xQK!,?&!l7֧ǭ}e<8AÌ @/3(o$Ԁ3@Ñ0A)4i.l'0ЁsP*D;JV%` q_tE}D 3p8 P5 F BHpT Gx֗ax (0B!(AOZSf:P9)ܡ.8'\>7?ZCul$S ( S.,JH0A.+I O|:+7"9 cp. )7+l8ҶW~*l$!  (I]L pJ ΀ڋ A #\ڂ #0 DB+e) qb}z0[@   `@辉@:c('xA @B& 0 #\rS)?r}-wrt?6窄rT(̠'-6Ɗ ʌ'6 w'pÌM)2&&- ̽\ rz)Jyt;[\]-@*" <[PL27 3o\T]<3 \'4`H',7 ":.6s b;.(@0 81P  " <dp.Ћ:,LdWr-RB}J, }Pۦ P+<Hp9bV*Z1.PF9#EP` c.NbLBF˘Q*h\ؕ6NE#$lvSH81P#txŎ#QǠ8`'`i*WV` FG#Clj F2( x %.E A/dMt@@Vz '`(8vy liګP #c35̻DS4q ` MB `+VV "_J$3mAFLL ddBXZ^u _N*Q`QH=Ls\` @O<#Dx~&?y,hE@`pD \4 L@(؍ *)_I$P/ bJU":NЂ`AC(@^OW `V@ @xg=;+x`<``22?* "MnZ]@h'kE,t$\X-4h^0n:3rg xb}jV# C H9ExD2xm\7_4Cy1`%M.` @pB` 'P@ vZ|iv㹺d">U>axlh" VSª@`3 &`HON|RyekK8zLfpr)=;s QZbuȳ<7Z](f?!6`  [l`&.%Od2\p\ @KeN&=N[5_bx:o)!Af`D9Z"t=$@i38H bPtx VMTo@ӥкŮIEY{T^bAc?'G? KyX5 +\bP~JWe@$ӘrcnxgCLNJ/P|PƣA . %A:0BP KbbGsAbF߭\0 FkhP>P%>x@/ c ySy\3 :zp S^T@wJS>YgN'P xL oE:^'' V:6{DM'on9 6߀6H  Za~~;a|Ǘ '0##z}4V!+ @e L"/`Uy9sDa5~~_ ^4}N<wnbC0qSQ5viĂ}$ Vc󷃍+0 MB(X6+z3I5D [S(|\D| x $" T)tzL>?jH u?(QC5%tDwaစ8>0) @zbHo!#0L!k Pkؠ]I56xXFz($|؇Š*BG`Mפ'@kt8.pt0(Xh&0/^5з+tCva{ːd#ّp!HH0 3A/@ D6:ˆ237Cقfbu!@tdƀVYXJ\ɕzzpcY798=Ɂ:uu1DLIN P9GR9  ViYJ[[yPai6hmɆx{9} )G٨ّX)ٕ9Iiy:8nٙw2 Y y 9h95r0kTW2؈tPщ5eIi) Y7Ui빜\ 9y8yɝٟ⛙"_6@` ɞ ژ1*)pYؙɡnsw$6) h)ʙٜ ٙ?Z$ J7DZ*)sĉ*x.ZXzZ^ \ 2f:Zzڨ*%* )dyʧ}D@zrQf*hSiNڢ Iy5ZzƚȺڬ:Zz֪Ra k OTciٹyaԭ @ PJ*dM3:Xxz{ڣzE:p: sک kڰxh1S. z dj 55X>ڙ<ڲ1+.0[Ӏ P8@౩ɑy-+17 ;V@+Ktd ()PSYc5nt=zZc{uc 3{% ݔ@)1Pٹk @pBZCu rTEP!"^3"FH4)m ");V7D;+iVnK eB:6&O9pS`N2 `/3p5H)=9=P)ɽ;Cq@! $0"n:>   H٣YLS ib7M{6ܐi ڑ|Ӫ]ҏYY8HNLc 9}m+!p[JPh2g ЋG٥e=|ӵ=ѢJ:  = >9/`yW+uH2ْG}b=؂M7QMo]rJ/ D+'09p t=@B6$|-=M-Bjp \ڑ]`s 339Q;OH٠ >gͤS =k(xLfH"/(:ދ94\!#w nv/!$l_ `*,> T-w 36A 0%Z"MM ҩzaRÛ>3  »%@uG^IpN7/AjJNBI!ՑM0TZsY R3f +paPw8c^}jPz֮=TOU ; .QNJ芰ј@  3>NվH ~1lj.)Mϓy'I%6M_* 0 !3X":Ϝک;[Ԫeb`:p p$%$/> *u tBh_$ <WGs!_gK:&ؤLD g"|Gߞ!o6jA;S @Xhx)9IYix"(٩"** Pڀڀz;Kqp rY\a M)M]m}}yB9zjڐ!K۞ ҋڴ  'Nđ2U.ժhapwV\"_@~K:լ~ [ڠشkXqMO9Ű-,7P =:@ҫKE@ 7ż]du (ͨӿܟl2NՎX eVQ Գs_:b߄#8DSwEt=Weev{1܅.ZX2R߆|CpXKqW &\$|16 2 `#V6NH^PC*p Qiۓh) }%"aeJfq z8栆*XEnWe:d;Hdf &xrhK*jH!wAhte  Pj. 6jwtvWi@ \l'L}ZjOy~I(@l^P ܵc¥a{Pp>eHE @F Xe !m!!m}?*@:Pa\ 8 #@ԠfsV \r`%B8@!< <Π917=KR xQ @7AM-`R|/h9ۀ1? ,`PC<d t.E4- _D0X!hi@ţ=QiYI>b^P` ʏ=3!v0iT*| 8X$4L2B,P'6f9}r6C=h7K|d"& l, Ɂq@"V+Bc u h ZRn|&{[X(n| V <"^ Z خlbdokv1*0]HFdP1M&(O@s$؀ ![0C( xGOC&Zs3 9N$)$@c,56\G璼< brή#/)y3y1ؘE'Ё]W@ ,_ a94h=h 7=ᕒ`n@Y^~P D@6Py_jPQ߾ꐏHNhUD!!|Hlv S{qgJqhK#,; ?F^& 7kSqKbL4RuJUH^@J4P)J+-L"J P^$x{Ε1M'x @0st B`̴8hlŀ x6  @Qd5DE:Pro@܄Q- E`E"pOaYxSKD5J5uS%ebL6p]QIPp^Z8@>0fD_Ymf6x:Ul4[ SHGc)/wdp FDQKxh$quH-%E Xd& di0'^!y&[`&rdPZ0W(_@GHf5}}G5P]xU471](W Sh9J p_%R'Cih^]%vC @6ޕ7dUPt4ccQx +S!`0İb~@6v6d h1p8TLe M PXooJ'e6l9uJO3te3YDgxycGP3pA 1Ch3PVY K .0jFg&H(gjm2cNq@m5Kճ\0[Qg.P=tUG ˜ >l?F&G 4yEf`3 ]I˴i%%opv,_i0qoZ BL9CE*P=x4 '0hذM90Mpuu0*Ts -! ttpoHJu2)*0w@U‡k(YO H2kG"0rpP=@ु%%@Bv":hS4)ysJ角@#zXxR~+J0*А:( 𩣺& `KѐicEje jgPU kY _Rx 10SpMQ WK$(h"1bX;D3CxKNF $ s HHh  @zD$2yK`JpHEgCG2cƵDxHP)0]&adGuLZG6p[j/ҶͰ;R@(`II P,c j*$U6[UIP @P$s(\V($^qL./Wܰ0%B:zJ&GVPJ{! o8Hd zkD%RX%5E(4 u arS&&kN3peAT@2l$7jr†D@DShEsw;9Di'wZED*E{`Y ɛ[GG |ʀkW pl wm[%GXa2Oƃuc! s ZR &6y,em& TE00,)R/` v*M_Ǹ9EbDmnE9'egś\KT  Hn}uHL/$usH%sZ_bh@iG^׋*v ;dNWSj+H@4R)#jZ,PwE%E%%Sgxp->Nѷ 'lHkCQ=՛YmRQ__]aM d{cMֱa֕X>Ѱ8 u0 voP}k&mM ͐!00ˊ ];ԐM ׍PƠֆ]= LǼg, ` $LTB$@E?4[1KD0L <;ٰפ}v4J}q3E&`NZ @s}MPhmڃڒ`;Qإ"+TR,',T"@u3R6UV6GU^%(8u Nu "ԆLF:fQ@̀mdYCXM ( > ]qߑ03fElYpR<fkQf p5[ UtNUMˤ!Æ-.#"H,/y;Yh.ЅeJ<5hJ;jR5gv  ѯw*Q+Š,1JNN_( 9) + ͬΘ,33!ٸ!.:6  :.!. H`HP d`$f18X 680ȲKH^P A/& 8V.TrA B0!0lܺQ#ׯ 0xpÌB]V[L (5b\(!3"A! :x wLl@ BjθXʖK$L4kւh iX\"0!$p0s#9#0RL@ 0@;7NuZ?Ds PJ3ه@K=2  [qut^KۼjnPۈ`PI 0O+g}wՎv!9fu3# <ڗ}7, <8]ࡇ z A |@ep Mν|<QP| Ȯ}{ӻdO?v(t& @Bl |asFXj9܉/a{ 3F @J`6l`'8 @B"@Hpp2wd 8D`gpԝ΂%‚ܠ&"C+bl XXb jpc8"v,f`ЍKl֤E,x sCno@L#(HeD7('%,Q 8|h2R_hd-ֈa0*0BG \Qm/n>dD PR4H&ґP cyE-bҋ_˗lDT҉h+_L+걖}%'naf!br|iNK>Ӗ\g5٬wgHLF$8c9=B3!5=yPa&"hz.}d9 L45g47M]r(N?М4&U"JSL;& ȁU:}*'zMy*+R[Xu}B%3P0# pV$a5}7aFrW'XWwC vW!-/!mrg&NV<;0Wc{W"qJoZ', 0i0$%vQ4i<0b-pxzT$؄pFgT80dz !a@)P!qc~pBB(9i؉n pVO?Q!>.S:4@RcAM'V80]TN !$ xV)TBP^XXtNus 43 (UrHdLprG]q`$@ TWwRXET.L_rŌX S> 6!CPG=SUfۣ ؐÄ(irF 0@7ȴU]HQj#6wwp Vpr'8!)PA pʑ/Hq8&vБ.T$V$3;X$Aܒ-Q)fpc9 Tb\Uq;u|7]UA v`0=(]`-@F9D4(ؘ3A棁\9)}qbacwC 0cbud9=}I 0&;-&( i*iP  @ fӹA0%eI@7p @4 my^{Ee&ff vW`1G0! QVIC 0 9 |w5XDNFzuCa5~C '6p$# Ԑ >JʩS.`$taGIzP-IQ7BS9@l<(ibN)e$jh |pK'70/14 JI^e*ÜJP5e¨`| @ |b02@%wg0j)`c3(`:xأ:YEګf(j>5y(`+Sa (yeQrQ|Y z)-@2d)vZEZNѹ_PQTN`OJ`@Qp9"$p'IPj  Rr"UEx\Ca#;$X3M5oV(N/OYGBK ڶ6+ LyH(WXGq~XJ7ˎTT;Ly; +KEtȤU]5GjKmPrqijY3V#!4 !+![ kӛ#뫄SVEUNEBP;S22  SMofOiD{uл.ԹTFtve!x@. ;L9˸)1c%""1, K d$[G ! B<2Â%VKXI(;YX ElM`=»`b*nisk\ mM%e8rOD7G; dzل1!0mԵ\) O@!lY#3) UK,D8ʶu(9IseE{\! _%(| ŒS3ygit_w%KL @rJ3!`O"Sv#IyZD@'B'@͂5`=`vĕtA` m[? B$&&щp !-\8}d9hu}J}BJNmPC=TV};ZK\!`b=\fmhk,npr=t]v}xz|~׀؂=؄]؆}؈؊،-؁;PKyj}jPKj?OEBPS/img/client_identifier.gifNkGIF89aKHJ̟溹URS⮮ust=:;ۓ{z{ݾZWXljkbab֝hef1-.ϳٱQOPұ\Z[-*+~ªWTUƌԘѯwx{nnp~}OLNuuweegqoq`^`^^aDACǴ闖ihiomn# 𿾿`^_WVXywxONO篯!,(˽HÇ#Jpŋ3jtXqǏ@0 ȓ(;\iq0cʜI͛0 `ʞJѣH" ..=bHJիX*xׇ?TBٳhӪ]˶-[ ڀB2x˷߾\b4*raǐ#KL/˹['1i~T^ͺd&37m ]4] :67ͷ{y<~ íny {l2N7&B" ߳ \P_q3C}D*@ƒDq ޅyކǡy P(bH`7F`AF  B]tX@ц#\vy*ݙ*0H8ȣ@ IH*de@)SW%9^ @J5裐F*餔Vj饗bgP[)1X9AYI.9ARzww8P 2C&9m*IXwh "& &YƩ* i+Vȫ ^,["l gsjygzJpmo BO]'2Kqb\mg/'ۖ6&`6>$K[#{1n-s pQ}شQFQף@4Slj|ohR8bwx!񘭌ۈS$mo۱,t61C.褗npwP8Gđ[M7Ʊ+ =V?`zɁ_1.WeNSL ( &bsv+^0Ak)@Uar\Rr53Nگ:nW2Ҥb.+K}*aͬe]xy -QFOv]EW^ڲ|r9 ,[h~ \|&$wP~}_K 5gMgBR8UE_++c36ljP#  ,>q2) [_miq`&Xaޅ,3:0" 'G&=b]wp j(c:t֭@Ȗ?MN|VS;+hn.ˌ30F~,熹+sGX͝EbsC y!{%Gh r @Q"ҡ0{\ n: mL;Yfal/uk"蔶֛(cSmX7BA1!Y֑#낪o^, cScH"&GoC*CX5k$.bk!φs|%pZVL^,Ǎ[Wc5nnkXAtP<0W:5hU$w0JVjUбbgCqtØpYuҮ$\fܣ ޷`ǹ:}Ǒ䀺[֎ pc?ce'=2`fxT9/sHO_0dT Cˁ0?a177>zُ/x"Hc/Kr_K"B wr<52~c~|=ЀW Ʋ.쒁p& ;|uBsր> D0{8AXu()8:<؃>(2O"fЀ L؄L|xR0Ra?ׂZy\%^2dX&{D gbd`pr8tXuxa|ȅ|ȇ^Qp׆Q¡Y؇؂b!G8+؅)khv8XXP|ȉ@0`  RЀ[(1BP&؊ LGP'0; @SK0EpC,p>h G\,(Ӹ0Tȍ%(TUPS@ ;0 cp'яַcAXAO V9 1 09VWPZA) 8<ɑᑾGLٔNPRWʀCهEiV 1@Зj|=\^ip(\tYvyxyY ~ n>QW|a YI8I X٘[8) eYEspzyV`)CҐɈIe`C\\&Q[)B`VC(`6CWšn9% } Y;Udf>on&g jܹuIA@ g 1yypӣHPCy^&2p\՟y,ڢ. <( Ri\j|E! & ;^P"YNe1%0TZVzXZJ;(MX\PD(I1P?94[6{8 2z*-벥QD{?) ڰE2GFLR0#[m<2[*cc0G2 zD& 0o2Θmɩ`F` )#usjHdHJ]ԃ(!N]ÒQkENZI$ k;0t v-wվ0S&~)~".~ -P4n 3~L <>㿐BE^A~`J DPnR>kX>[>ZpS` _>bPh>kj]runt~zn80plz~ |~穬\g=\ ~缙VK#p^ܘ>&V NEݥN ~s.&ñN賾׷v.콠9ky?)ĞHn,\;7X4^2'{>ʄ`L8DQe4: @ K$c^NP^_,+6^90uc jP ߅)`xbaxl?@tov9< %c^0>{/`,e0 `/_- ` ؉ͮ (_eݑy1io q˟ w1 1_jc&e] `1 \e  e  Fǿ .و㎤`ecc\AAB⦰Ç#n2SfI܈)hz1E^<`2(0ZB\”za09Ƙ/F|CNJJ5ŋXeՐ 1 "^4# m˷^ghݥVfDcWpP+^̘լUmmp&.u ezy傞DI4 A{9)kKߴHȓ+_\ wrR[/ |@Â( `_7s ȟo{{⭿ 1h& B tj"&\e]/I.|l)yQ^!2Y/ Q!s4_<*F  DiHFɍp!>.TY|g8x.Tty0pNHIxXt*蠄J=4'6\pAf#4 vOI1qCx{)10|~)@jόP.͝+8 p irI {\Kvh дVk/@kR)qIJld1eaJo,!l/!l\.. q@obh!dԾ 1M0AZ0,c<.J '( .kpƗlLH @l4Iq' <-GcFvԐG\A-3 A$t) 5pIuY]7#Zs͵>@D=6gB /$6}MEvs۶#y-`B0(UF`4;I>yE7s]監=P gQ@ C$꫷N~:O=]/6|gb3BF|0@1@]ؠc^pi{\ rw>4d Ƞ+&Ġ`Ѐ*Єa 5p@.E0@ w f l`C `TZȢ0 )IA >! mؿMO4잆#ڱ1C$*·$O E)Rop8r $*@X2nAϘn X@p|H >檎#9&2Sb"GF%3I3vraȶ2ДJX;#bl|k9'd#uIIĤ&ψF5~HC=2) CUOagemMCR9ad#߸y63v̧H$(MiT:y[KhM 2h/`<;7*Jf1{!RA 6:PecD)P~g9yNaZFC GՀI]\yպFUH"ȫ^׾bXK7U27NӲh29*뵴Nf;Tz =FKҚ lvWNCsVfUg1۩խVf7K\q}ֳDhr:W2P5 +K%*m#ӉV-2IQ~M6:{.LUA6`X}j u4[MWx"M9@ [#47P(x &RFL .ߟJϋԀ{<!07(@0Vv4% r'?\~Y|J̓˭|!'@NDeq*sO:)rP@,H< "u{MyYL* VxB FܢGݚyDx9}K,p)@U_  XqYD$]wgz.j~/0XwA D@! R_חϮېԱho}|HTQF5?|YwGgosE0E(LF|U9ZS!w(*,W}hdwHj!p2P,+W-x~xs3'}2d 0'P%#084v30JAdeT@q7Ӏ|WⴁԁF zG5IuqrXdxzF ÆP&քx`$Gr@x%PD0@@'UxYs$w#F_G`8I‰HxX74uwLY{؈ hGͨ(EhxDhx7{z'"5veGVx[v]a8eg@[tv8LB6ӓ;؃IA8g X玲2Dhy؇7Ҏv7 )PGXu픍Iw,'#)}eV5*C{~~)(XD)W!wPvX7(F3Op㒰ؕsr]hfK@Dnpysr9x V+<@XKɍz TPUBxDžXCY0(011BZ>B:DZFZâ6j$5Dr/:0J!X^`p0pfj'jzЦqp _Ѕ0Pux\*ЧdhVpwL:R!d !i+H4u_N;__A%Y[ M cjOPZ%E]V[VJi ʫ'֝?3֥uKX__JT:^m֭^(9zGMN@ Ŭ8zњJC8+ 7Ŋ gVڮĪu[ߥ[:^:6ڢ5![pv U[ VVck3{D MwBo6olxV1*_XeY0;T2[Y&C8z#t*0 ֣| Pu]P˲ڴ/;1`t1ϒmG}~k+e^}}-5gN`Oͻ]{\jۘTڔ۪]s5ڽ0ˈLIէ Ff%܍A_+g lk '-5E]ڽY]m I5/mSl52XlЫ3/uF>Y܊ߚ5TQ+>1gL L5M'9g3 %pFװ1*0Y,bo>W[MFݺ lw"MlIS^e`{6{mņ`v' @ z oznUmvro{쭇U*REܳ߂m\Q}ve|@RR`^hdnFAz|7۵>Z[=zA:cۣ. n =A(]KS䟌 dc^̄pĚȬ̃<* >i 7~ld>eͳwsvߨt,Ɲ'@,ŕ./]>Є )WAK^8"xԣζȄȒ6,#C 5no@}D\T/R@gv= qtg;֫ >YC?Rѹ:UZJϙiq_ t?Oɟv9lsl?Wn/ 3sߠ :h MϟY} Jz#/W ]3 /M`_n+ o T!͂'$ ,*=rO/(ܓ+Oe^g*&ɑʄ\ӗϞԽeւ^e\^* Xk*oÇHd ɻȱc=IRFeK\ $;0cv<,̛8 O4ITPB<*]%ӧPQ%JjŽZ݊P\Êeس\]6Sa) Bݻx˷߿ LÈ"GmbJ׆ k̹ϠC06vzdd P@8Ӻ3P(Xֶo{@I^P;s I~Hl~;Q JԶ.m {k&.r*&;6 XjhƂTrx 26A~5ǂ`ʊ{fOxPu@8 f"_#8C}SO  &zհc*u}Z"v jPV++Z ּ &) Z5!>qsz  \Ӟak[k<m @ PxV,I@+\0ͥVF%w$#zr+p}wAq- (GIJlLe1GuQHDɖp-QA,wBPԯ\֥Q]´?Pd nqMw^+lĒϤ@iΜR:$ .:I@ p@7ŌBeb@ъZ0ю@(`h=t"/I^,RJ7gpX7#< NwӞ^p0P)ODPTʅLX  LL k1OVQ$j*kRM⥬i jH1xͫ^{.\F4A꘨+FzkPY@Zd1YF \Wc--ruJ| \YRd;K\jlhsHR|bK0k.@>4"pK㒷*&@犥\ {f0RV$=of7+˦8{r(2K F0w_).5/C Zb-\0S )'mR`;.@A%.EU 31+L2`D;a+A&Ŭ\6бe`.ɑcSuA_{f= gRqt~_x2?i>-à3\x7=Re8/Z&| HGc-o<.XN j` &S#(%[V3u)MrNv@>@p? 6Opl x( V ĸ FA2K ?P NS 6ֆ5ɫm[G}9j^SQ?`9/p X79^b>̂ީ yG,\>( 4goFй]uO [M}0`߹>aH^qG#K%B&Otcm{a%sdgqG0 sA7rͦss ~@Pxu 1aG&~w*2wS^ivhSrOwq WhWj9uESD7Z {{Zb^{,q!xyVVu]0x`@GtX{@TW\%'A+8m ߧo(!k#1^ 0ȅLJc!*]Nc @w0ea(fxȅ}X^!%]@Vl8c0<6Pz^c(APDkFpɘ_m׌+p%ՍhH8@P|W^/RGrh`x# )$`a7c]W@ ِ(\i\i"ɑhwQy85^@}9,ɐ8fxv8:<ٓ? OF P3g}b ]`NPْS&G[]G1a )da p4Ppb5 itYw 0WY$悅~y_ّ阑 fm`o0Z{pwn >iN隰鐲Ie dYxcq>٘9yojp7:kPPYdP p pٝIQ|i5iPUOE@雉=)9Yȩ:Ud ٠y))yjii9٢*j9ʝ;ZȱThu:b$Ij!ʤ#i+Y03ʥ a:{Ip~T[ 88O68qsZMzP*,ڧ/z2 4jʠʣ*@JWH Js*J)SVYZ[`꣊pںܺ [QJQZ(Jz.ڬʪz ڣJ;ۭ֭="p Xg ʧڪzZ:a9(K[pֲ./ksJuɮT: Ԋʯc*Le0L;Jjz%Jyjꧪ:*^KA ap晲PSP2@X EG9ĊƱr,MƖ+duK{:psY,H zvlnܭ4:Ŏ +ɳKMl l:yʰ˲c,2HkiʃL JHO IАʼ YM`J/Ⱥ<\|j̭P_"@>d`wKP'P\t{K͆ͷ %(8@L-<|-PqS#\f|hϘ<' P#08L(9p,]E);T`\Ig|* 0mUm5D]F}LЧ:Zܩv):m.~ÌJmW!،-٪TXn,>.DNNn[35CP LU~}=PB NI@#7װ ~ΑtTw~܌~-`N ˎKEc.؍0`Hl씀$&'MzRڴLLOTD[ n/HNpS0yjQWn[Gg0@$ ( o N: ?>_%(]簠~.K`1(MPH 0?> q. p1[ڊIik/ mdրA!myxOP 0 RE_00}@J*p1q`p?4P¹{ڳڱc+Ҁvϻ o X\^Eݟ ^Phflmmooj77::kk`d n? >> ii]6/w!!Rڍee*6IBQNZUY`jkW_r,ٲH@ L(S\ɲ˗0c֋IS { PE2J+WdѲKW/_3L2f!G3]5ÊKٳegI!RN:z $PF&(ӋQ5RZ)(@ǐ#KL٥)8OL>(CNljF;Zb+&tǥA.9ȓ+_| P瀛DEHtQJ#2u^56˟O>!@8.@Uwz&jUFɶ^Hp^~.7(@"lh$Uhb6u iZx}kGVWDV8V0xfEVYV:(8a\^xx^l-meyPPp@= I*ڧ $Ʌ@ 'a"p q"]}j~)cm!lJ!^ 0}6qEs^@!gʪrnaB2$`ez`j2Ȧ\AAG' ҆IF[cD`V Y[G* w4i9&.l(%[*` bxJoNԨe[hA6W}+)PQ|G]%Z h0.8lP[vB>7(ndB@vGnj]#@pfx&i E@S]ݒ}dvUp,F ܴe@T">K{"g(ePFр qaT܊@݊|evCB0 p N MS !t K'#,|% G/xAf̒p'/ nq!넄 SÖh@ r&. 6bd*ZFܔ!C+z"H2QfLטB4izHG1K[|L>/$ZBrr)#C:5#$'IJF2̤&7IV e!$'GIJFxJe)WJAS*[IKNH(DW^jKg( T/ "U-p—[iLa8ffL3Mm6ǜB59rz3l&8uSٴ&5)x~SD/z5%ae؆PڿlNi(#ո9ԢDCntr4Ў)H)*SҔEiL[Êtf5(Gqz¯cj0QRZ1R)r%XJ0ƲhMCZZn5UVȫvkᵯe+Kb=b2e+fs͂UUNgCUǒ݆iSZHImumd +[k-n{yAp pKMr:Ѝt ? @7y xKMz5/1=-ߓvSE@^ 8%Syנ-8&SɃ$)xȏ2q%RɅ8>Kp̩LgZݥp1+ g.{)^0ҩ1/t#f$i=fkna2;A(O4'! 0CS3"l$MvL6 J:Gǁy iQUԄ0Zbeq-kpaBQ/`5 3 TX8R% e p/WV(թZƗ3 [=-:%Bң )owTk:! pAdZ|-%7§"nAn88=Ԋ79) )(!NHPXS==VnSCK{zMZ0$̙>ŸB8w)nr_ EP}Ztx$ q0 =חvHHIqF\pಸkh≲Gst Zd;"q.vD\Z5NoѪӥlkBx-OڂO=yB}foܠf-XqnJ[x͔0_[飼 -ߓgceq8w\^@;/yN7~Jic N9d5w{:<;ܬ۶-,+oqsןȢ20/C@@khhSQQЮtqqZ\^_`c" zxxb__׼hikLJJɍlno532!,Vn)nV)įӱƦ $o ,Ç1Hŋ&bȱGT?I`Ȓ(S|rO0sEx85kP#XHDĵU vHXCg :3dUT״8'[qrĆ=k΢#G ɔ4lʎIv^fAWx&IM,v T%zq?Р* dWU9>BV6]‭ *&K0eUHB!n&d)`j1D Ĝ >ͮIʉ%AB,0G± ́ hpoB*u$!m1C.,[ZXqt`amt\q =pJ u \)]*;TQ* !G&CV *d@"=z'pDU? =40Cp+Maam* @%` Us4:tUL zTÔ:D:S\ W0+p#`\ ?$2Kd$P??a ~*80DIaGF} >`|XQ]%QI!0RB`Wpә"`+a#,Ѓ}JāG9PF $1>A9PbD<P'>ЃeTqou9 \7);|8 ,a? T9`޼y#$8\aݙ4d*= `FsV`@}0!R TBT:? aW4qe.|Qu-+} *p@vq@U\kU'<0xÃ7 8뷃+ #x p}0|N[&Tƥqp*$CRA8 H *'Pt`Ѐ5UI ~Ѐ*` %hC)XBa~!wG8 ! vx a 84+74#` !$Ay(WBa*ɩ=Bhb ` a0Fؤh\ J@X -\*9TX rx%PPS SaDs H-#J, $X ' . 4-ztS*/ FdhzCJ`@)T`͡Cb?&3HΪ0HҒ8 aP乞0<6)~!@AcU  oi@1TCA}zTCX  #x*]k:Hz$4Ԡ*HiAη_cr`Yx`u+`*tT xYJćDl[a(,H # ܂0`TbqPEQ?UwBYp =,V;E,6B,`WXo4\\E`r D5` V@RW]CH>C Bր @%kP) M8Pȱ|5hԹi.hkȏ+Ђ@LXɧ wšPA^Q!) 8%.˼ Pnv @f)],C%#|F4[cΩE"U@WЛ?$@St*.=9P2¯EРX:,h`ͱ(+iqDIsuChI0zQTfJ[Eg[J;ljB 浔ŝسP{;=V*Zy9yӾ =B<'CzpɁGL '-:,V,P+(EA6hSE˗v 0 M@&".dhbHm.8;TC?UqAvPPQ)|4rr0t qb`T(MU #0@~`)qpP$$O(6XW 9'3d?IXepGTp~B؆ 6 a?`V0gep AP* \USo 0B>\8spV+ف CB{0 0pXPWYA8KR +-Mrf %]p:3*;`TS2o3|O>$dpq bN^|P/_!{/IC(@YZ9%>%( 8]ydkq@4j0*0b }cMw 4q`3 kp$ 9]WeMtZyN2p_v吜0?a`x[k  *џ9zZz(1ѠZ Zp$+: ":P"q)*z,.00Q%>V=qdcAj11#EH$ :^K,hDZ)_e_Lh`IY`pYFp5n`nȦpps {@v9a|X꤀:` 0jt`Xp91.`, Kv  KU:1`^>a𦓚~oJ`ɟ u a``H4 :E c fu Z Vњn1(`1qp꯮(tp:N~@E\-c&{(*,۲.02˲[b BQ<۳>@B;D[F{@+1pd$RPR;T N U`_0 Ljl۶npr;t[v O:P;[{KKn@[{ O h@;[y pL;[{ۻ[")PN: E ʻۼ;[ۼ4 4p;ۼE : :"PK4P_<\| <4@< ,&|( @4\6,` ˿(0~B\ -!t%y+XC` z"*{(MSpOSe a -SN]7\pȂ=΄]>Н!@[. .!Sh*@'00t,b<=1W i`5o^A٪ňE{~ ~n 3SS.d(&`0U Q)vqLmת.L} .10*Iv`(0/I0n}Pmq rwq-z.1yP0ýK<ׁjnW۠*a~?&"`?c@p`i^ecĞjt- ON<ppWm'>@>\} U`y<ew30>o 4` `y6҇1Q+4\PDQB 0 @=bL@~4@10P0c,&`~%YUc U@j_~Ѵ_۹/˄O䵎" s1cGlM1m"c1"b~~7bMSDCY7@M~E>CϽ1a,,a1Ъ`hIe!Q'%1Th'4S&[$\'Y~b&0("@A;\<5Ԕ)TB$Gj">!/>nhz0?'DFOE¡^!U-:審8P} U-[tq}:&pbmlOiԪ]&rLDCG!@@S f DO@;w`1` ~81 0L;2Ec0A$iJv[ڻfƨ !TȔAk[D6ν{X 50 o}TB6D\(@)+ @V7V 1Jg Ӄpc!@Uvlyv-)d34PĠzUB&/ u٢tvq "X2H+CC X.x_2@H#Q&NcP+~` !4p7h$1P ZGf,ufZv alj*(wUa 蛎w2!Hrhԙk4A9YQ1%wqvRl@4p [WB5M~{E \(`!`$3@`b+pEtz`pXq *0abo@Vҍd,UlFlt4Ed@h1"Z' M`aL4LrAHB=i~"M7\̠8*u;Ƃ(Pg4 FxXa?1 /6 hdHל$H%,Sv>Us8 3؁7a[d`?`@34(`&D!XXen;5튔4 Aq 8 j @$dZ9d* $B712gd.e'.Y3  T@+Ppp ~18QL$lj!bz[K2p( 6 h0A`p % *4* T\@@P0!(@dC(*Pܠ.8Tf>s%QP180L6hx !0d4\X Ft9`P\5OMc qÖ8iV֓ kTW"X[eHlihZĤZD|Tyʌtܙ`_,$ @0$ P0!!k@%0y2D% =VVf9j&%f؉]& \ 77@]dЩN,/È ] )oJrΟ|q)<̠EAhu:Y !A NC`Ѐ`GA# P哥i`*֭4eNS`f/2M=!! 8*f[ P5hBVf}uMi묖EZ֢+0GPJX@2`\0! xH#^A(F`;Y+2W ?˕-9ԡo&R7Zi.IDbW8ifs.i]s㻣Zǚ }+}s;Nv )EgGauX,̷Ac)ᇟA]`pح\aC6~ƅs|c Ş0 Hc8>2/vdbQ'n])Ko_bx˭h!e0kfW4n d8g.2jpvLf!{Fd[@y5$ft%}i='Zyr=s,i3SzϖvuiMC`~5cY֩o hOz>g[_؇6v=je& IK-otxfh)z˘vZuosőh@O;7xn517{ GNw<5*09"\%f< :AF X;PԧN[N/Єj4 2NhOJ`2&(xϻw ]cmXd@[ϼ7{<jA ЀWֻgOB n}pjaW@ 3O[Ͼ{O{_O}Ͽ_8Xx} ؀ⷀXxH؁ ǁ"X&x($,؂.084X6X}2x:<9؃@B?8FxHH)`npNPR8TXVxXZ\؅^`b8dXfxhjHn`;PK Ti!!PKj?OEBPS/img/audit_proxy_user.gif"BݽGIF89aLIJVST>:;Ķvst뽼|{|ۅZWXb`blkmʦ1-.hefݼQOPר~\Z[-*+Ϻ·ᕖPMNƀ}}YVWywxwvxmnp^^`DACxz}qop# 񉇈WVX`^_gfh@>?PNPނomn!,'""ҹ޺f! HC8PƟÇ}جL*2jȱǏ UPІɓ(SMLyL ;1bʜI͛7mtϟV qH*]ʴӥ N†: jʵׯ_,ٳR0۷pʝK. cڈ߿ L0e*^'M63ǫN .\H\0\lУíJ79 Bd=p7n@&L.ކ{*1ǐ[ٔ7?SZ-Q1{hd qPF^`@:H  /l2<0 6gg㎲Pu􄠂 :Zz$,hu3^S`#*@ 4 NXn!X) Wr\e8)@2$j馒q6I'wNXh9ifIO)eUe{)l~km2ji&o.)uF'{y22i+iZnei͖Ѻ6mumD{*,2+/¢Zl&[)Κ\S.\(.l冷.{N=0p elI17:죪Kr,]$L7PG@5lC93>+\>/GOQ@lWǍOdlsL.NS_g'⌟@@rG^vu6J^=xW xѕ\`Œ[7Й[L P*5cOcγΰDwĄ0,)ox73O\Cx"AYą v:ݠݪwo6z D@uuL4$H}moÝ mP,LX`!((2s+鰄 ba8GOKgFJ䊲b Xa0aH94 b7D{ˠiHNȓ%5  I^z< 8h0|0][r۟Xy0W`0يborL*39:q '8p$d5lDHFz oK>IKXD%gOuMBjO(0R 2D"A, P@Ғ(E rfjEO]`DdHw1@ P*ӥH-psFg:\:NCU4INl;OyΓ=N`nRxkH! iҍ `K=l]S:ֱ|0ʢc7J6hghg?klg+[@/ͭBWF^ H P?:WwP.PX"X@Qm LEQp08KB*!KXp j؃)ԃ~7 3(Hz7Mp"Dal t>0g`*2). Wp 0.18B0.$C0p7d  kA[#-nm?e`3p[Xβohp~KҌ4j{F}Mh(hiF;#.`1!(, Ql[3oVғ_/ij:4C Qԛ Z3ٞYCW_^?=Q8AEM`0+FSe ,\qі6-MtY[6Oz҆ D>EJц:!eHnL{30Oיw3*67q]c(I@$[B +Z*0;|ݤ&H@sph⻋Zl,)`AR+u)B"XoΊ3hA p=( #Aa楃tXH `i RwN+6aߘǼ|`GOқHh r X81?:Mo f~y a.{f|`w&O @Aۓ[Ͼ}$ ~>t?4P  i)߉`{|@#zv5pz lP wUsIw~ 7G ?uv|`7p'޷v }4X6XnUnunpyN$ 'n,|.e)ՄNP(; m  UagxօNgIB\ p~@?6^6aHi.ePw@P6bi{wB7PrI׈~nHh>us,P'6sȆg{w ,0>0hHLgCcp5'Eh,؀T00E_p8tUu0\  "$h')@xx e95<IP;3 piHvb H>N(@,J%bRbDa&8X C /ЇPvq~Q7>{")$i"zFWFR' K 0@Uk@X3f #X )uO u^'`7H>E(`z:<2OQ!uayx1zY 0o mȡ{֗ЗV YC1EN`$0X`_i!HeVgY `ocp^Otُ/W99YQ9 6q6y 9rE\9v^$q&! yQ|y)>hP fЎ` "`p1@%  Fc"X'W '܀ 14hHx J m$Io) + cA<hݖl@Q7c ݖ]X U =NI>lV 緔e097gX)p@uFK)0 ЕBڧ~7S8+XT|Xj5p+Z Wǩ3rzk:t ;repUx IyoajV ])mW䷥fp{WD欇(j3zղ*9J-r3Rz5+;1[g檰ү. ;aR"۱<±"+0&{%, &$!12[68%0:ҳ#@[y [ `D!2B9ʴ(KEA0J#벻2rtZ[TyaK0Urg۲ktߓm\K-:f;5YE)z+Tk[;kr[p@{@ڸ_iq7oH771p6gn{ =w,0 Zp,)ꊺh18,3q2+gN &m@!0 FnP} ڻ۽+<nY@N{;[q]pf +kgѾrDY(? `X0n]* l,(a@ l:#4\+ hZ@q*Ve3lJ! ?B\??:=X&~J==x)&~awLl <\CVlXmll'*>Au,wK ԈIǎl0v\*|_ FLq(8  5, ݻ&<`Gq< ng&˾+)+ܽޫPsA٫ތ3\# < ~ (pɱ4l`l ),c@笽;H~@ 0=1ʺ@r0a*07n |n䫥zL>e pkia1'a]ulBPw|[`/~|c5a0Iq 0D`*~䛝&P.“7;^?nA~r a=H}>0LB/a-@۵0p'=9"i3D}[+xl~~pNM.l.C\P˓n hN r&.Nϭ޽~\bz2^븞, Aa& `<* H^PT7ή""^ˢ ,  0Q\X½6('>sc뉮_ߎ0 kr@[TܷK:<1qrPN~~ڜh Bp !iWW`Q5 u""D@"w2^Cl>$G !&lN&ro!L!~!*^&"n뤊Dq/J!vxz!})?'7'"/g.ђ FrtM{P9__'p]}r_KNrO4MO ſ{{hhddpmj lqgoa^ii:Dk]/23U&""!6ް1Xc󄅇tjTSV*֬ZrŋAȱ`پ6ɓ(SD1Ǘ*zl B)b$J,aPaDy!e*U\m-\2t= ׯ6KXȑha۷p#]ٻdvfx6/?"Ui¨ >1Įx3kdziGMӤ]z&k&_8GPE &5!ԅ PZY+Ww䬼:СKV׹j66?ۇe}X,|XF eM ` A zC66$E#¢*"`]?S)ehhNZ! % ^)B*)hi|a2fgު0@`lAD*ASp ڞh_SXDvfpbA莫(ނnr;X.^_cb05r`@hW*Gqpx1 JP/F iurf %b||'<5AHSRedLL&5L*[C`+N۵uYRCu#_}jZQ6 Ԡ|H( 1$-ֵm0⛹ 9GH hAZu K\g8Hm㩗w?a{1A JLh6{;/}'AJA />[1B|'_㬋[4{dCH@ h&`_H ga \BpYp ;ر:`9۠W'BfnaCbbDe WwtTNk'L R T03 ~Ȍ\PHE)Ώ!fˡ>JUn*`Cp%@.G n7arvxwhA즀%<~-pT&A@J#=$,)FtD;n%S2b cɐYP^tY0_"3/$e60jh*h$$`@ND~@8YM,()?r6x '9Ht3"r- xl e=LL )fUGoD#ޱ03 ÍʰY(CC꺑&"WH*$%IIKM$\'o* 6nLi4=Y9ӁQW)Ӹ6ScTTAuO=SUZԕ+=KQҳ)Z@ŭ)e!FJtxYbQR1z` fOA RPKkbXƶJek7!utƎ)ZeLzec2)|-,Y:, 5+nf88πF܁)NF;ѐtOgA7ik*@h}M 2V Ո$eZ7ָn@Z ^z!R@lb,@{ָ(@͑dMO㏡G1iol2YX-gCcڥq)`[6>~mܬ<1OoГ8WH3c< v0'N[h.F|c6spƜ1>8qpa-2qE8ϹG팜 A:m"xF**o Ѓl0yַT*CߎN흐1KɟnpL&TznZsN>qne?Y8.0gnL>pCHwтswr]ë^e`bo{t;܏g~O\g ޯ^WW.|aϸʔ/1 qBs,@ؑ?vͧ="T> \7 . @0O@toohn}vw"ptsW2W' z, p.)0#,0X/ m"q=gp=~;W"vfgXI؃b(C hm|7{iwk{x2`9 ޲!1(frYE"fҡ uWY#P@Q%*X,'y08#:ڣ>7MbBJO3z5IKjMzy< Elhr Vڥ^Hb:a:weZfX.fSulڦ&L5tZCeM҆kZ da~'e(ae6)PvXFbwƨSeYfThB֩j *yew[vOG*U{ /;wy"zҫǫ") :/z¬vqƪ‡&Қ*zZyܚ/ZyZ fڧ*/bbGzzy*h"; [' V*Z{^u[ʱ#J"{d ($k۲*2{8ʳ@*D=CkZ;[Y ghH K}$V{XZ\۵^`b;d;$Hb9lYPpr;t[v{r˒g/K"[ Qe,p R)SuSW#ifؘp0%6 +w빘pKqzZk1)WcrVɐy;w-fʘhI Xh#9(bkDh ۽p.ًk XGFlAh~*  镔2c;˙Ր .[c(׺g`Z+fк b,{"( w0(*W(k 3HhB[ N ~}.اĢw@ð(x;  .e:,.˰”#-Ǜ2+ fǑ`f\~m mpe"0kaHLb(AY\P6l)!ɄiahlZ^r< )P} ٜXQ}0<#髾Zmtl@fl)(_<|zI :hׄy!f@PmƘ [X ʯ-raoJſ@$#2Xjqҍ ~ȵ- ,=iԔ2u{8l#/d>蠷f)Ѐ.m 呎М[ǻǐ ht.7ξ)jݻu5G.En̆ 꺎E(w h[,ٻ΋(Q^-:/Ѡ^6mلIϟ,0~WcpoȎ؄8)pL-z , ɱe_~ ;ܫ= N }sM?ݧbއi㯬 ނEْ{P_R˳- jɧyyRb..|ǃgLݠ proB! >߯,j_?F?/Bo?Sz?9[ lİWKħ\hXФ~̏nο(X,0z[$G/)Hh !@@)uh",)""!mm'''X"!!Xf",e!ȗʓm̤"ۄff!fXe,cK/b*K cR8̅1ʜ!vq d"D ݭRi8sɳVb)pBXt"R=ղɬBKOSŽjvjŋ2B1MWnR2ZOwmMa`j#c8mdی٧6װ^ͺkR-!HX@Ί؞P,ZVj7T&%myPW-6,. !@ JŻBwh]x,x&=ps5*aVYc$cVJMVSl O3S! 0B t{ČR]u$^?: \ߜ$bU%HfC:b}~i0% m(#@R,8^Z}ixWUB-SZOCfꀉBU K*+v"tQZ#2S(p-f'U~E@\X2o28 ŠB} `p6Ze !&)vbx"tJ@)GHI z%. M%9(K"8\&n,,WJpqY'PܶQ>`ÓmĻ5¨CbK"I$%B.)Ի x%NHA1\07ܱ8֗g B`,hq tÏwB>cF-uN2<"O5&_˲j! [/WӲ%~:&Xۚ4jO'4W؝\ ~de$xx2pl6[Yeh͵~_mw6z){޴@=vLf ;>!מ/w:7G/ԣ(B* R bA A {a<8 H "Ub0I>C` ?{ĘEWU fQRѕgd*CZ97tFlUJC Q٪! &`IC' 3eIьT')N5cQ5J32;QːSH[aJ-ᦪN7 $s\eH-Β!kˆz>5Co\QwJtOa\Q>4#M(DqDJu^fKa hD; G&Y1f)OҊM2?m+~7m)hG%pCD@?ټ~(GbAiRZPnT&0j^G?Ue8$JM2!a (ZBTq롐2Ϭg_1m [Z ƵskLj/{&^U R~6`P*[suDmB[{<뚘5af!Т`5l[y9jx2} -.){-Z=w8-nބ7Zs , PlDDaL܍á9s_,H+_O$rCPqh,ݸHNr(dPn2<'S2g-{فZ,2/fZ3l7NrIjN5yAoNѐ#GSү-tc@qGIz&7&@l U4)4]cY:֚ij^K'׾ ǂM자 Şhftm -Rc А&{ R@.7 %O67Eҝ[~-O;'N[ϸ5~[w#(OW0gN8WJ~!ٸЇNHO҅n%vċ};T'EyY[Oz(uÚݵf'\Ƿۇ蹿 㖶j; ?hS{ yܦ/a'@y̝mq@ q=V9ٻ8tU%Wn)wb&]Ui94 =vkC,۵(cᯊpLeP",I\[b%=:E !n(b}K!/J[!['~B/;#= @&/ &'p%g&kJV8a1%UteK1"͠uVK2*TS0!5'8"'pn0n0U1` ""?wmi%T2d!AQf(K2"4uC1#qU i ޡ@G',9B` PLj9BV+B3n14b}-a}W@$hwaHa(g{aϵN=HW)x"}zF^ h$PUB%x8O7T ]X{Q"+`։sShpu > 5;,N75/}5X7tM{Y~"Aq+JD!Xx&ԖVfK4W E YWQҐSd -YYVpq@.#q !-kRE1" >lDD; Up@A'AR<#ttT1bD;<&"/B@w(Ε]XC{X?CBfo#9E>TpI;j*} }{)H~U ]ǡ G#j/\`t "4 +p2fhapZ\;]פ(^ 6ȫl5 3HP:R( 6U]KUHw )3̡WPS6 NwF8,Yקcxe5QȑJ, w誌iG)ǝ ^ FDw\g\LuNsL1eڊtULbj*!A' jX02 ð~#ySH1ңP+|-CU t䫑WnA\F;lL  a kX;"s/IQ,ۘPnI(Wjx9B#LGKpAJVBj+`Pa+=iIAK{Mەg0% V=66NJ2- 9:ҾC9M-{٘ak y{Ab;PpmBBZ<'}$ +zl)iB1?)sp`wks}i YV>؂}VMi}ؑ،o ؐ=֋|z; 7=bْSBzK8<_a|p3`>ٍN ~T ^ 5$/QC-^1Z8\^梀E4Y@ۊ>3\B\Z!ğq;jSW]1: (M˻==*>Q#QҊ< :}%m:n]w=L;lMI~ |6ŏk=)Ep_nHq9[:5 6)BȐƮnȞ삻Ξd~g>StvΉn5s_Ny~N}j.FDpiF^>=ƓOe(x e6Yl:RcxަMvnx)` _dFCrgw%'?%vgw/JS#oyQt@B?D_FpvYbPR?T_VXZ\^`?=7_uvfxjenr_RCva~?_/q?_;PKƣo'B"BPKj?OEBPS/img/adfns001.gif$iGIF89akDlllvvv666^^^˰QQQzzzCCC???߇KJJ___oooOOO(((।xwwtss///ZYYihhA@@ (''444gffNMM-,,ZZZ<;;}}}hhh!D,k>DCAUB*\Ȱ #j&b aǏ6$&rd@&S+r˖Pœ9eJ43Α?{)-GteJEBbT}>tW(pPCVcXZ!Dcokv,Qb $D 6lPm j >Z Z C2: %B0xpBʗO"  G0D CV7v5松 }_A  7PaD66]鑃^E7%wt8 1 F'D坈C8Y}1mh!0Q̈́>R6/G  Nq #Q@Uinu w2w5&LA6d3yެ JnTȉ'P9ݹ')*(=碊h0I4I*Ч*jB:iiOjpJ4޺8k lO.;:l(Km2Ulq[Ӷ޲3Ш`fj){ʹ L1lRCPB/W.?kd!f{o ^ZAXLd?q`p/DUc[B%HmBoq vJKRt4rDP޿^36=/ ݛфQ1xia3XGt}a`СxLOaecYbVAa%t#F")Lga>A\EwhSA/;nפZB.;k㻮9ǧ{k+̼I[=H?t:|~诿~ r3G@\o) @OrvY`H> wnW6س:Ѓ`Fch. D,06Lº-LF i4xL, &=08\@* qsq2V[sxc 3)ˆZ 9>*L$aDx``.&8AxP ej=@:#GH2w!jFB`>!m>Ru64|g8(/0ЖPi,d$6`8PYSi#&J`-@"0GKSs0eY5 :O3v;(:`B ~rl3_(eZ, FV(PtsQ3Gmҡ)QE'Rf-S>F,)M%Ҙfz:PSσ 4TV MuJU~UjS*8徬RHCMZֶ$Dv u_-亩U^z%_ 6\Ubq?-UTc_AMOEUfv9mS%] Vٸ%skZQ#mmX+[PVUI<ے֊UMoZb 7M2:S] uf]f(Mst~(=n]u6F RA"S sMwj^6h.6\;P+}8He^žY1(DTxTcu8*g1d&cѩ E0eqAV"9葇<1̽-pym+@/h9N`i){Y曝`KYH s+Ol#c# $1KNR 8t53#0<"J4!0uD;HqCR!P3G|Ch]9ckgCGy\l4m/`tHlЂ+9g.!uC@Gjá#@Gf-K"oāa`dh EC7ԏ(h "7!qZ %Gf74./s.i+D9Ht/Ue_ZG =)?)#7J"kf2 bf9A#c_EK`9 Z)1n9D76Lıe$}gr<6`{ٗvM&QDKtN<a-RLAŗWJ58 4:$wKڔFDh?0h e[C8' #1d""CI7* Ui%Q#ᙛ6tuCP(J7OlrA1$Y6i %c| K)"e9 "a(dhZ+ nu|mW*<'9)Uvcڬ&3 OC 6:Jސt_!e9R =O PÀ5^cښPp(<$$X!:qeگ: ք I";v;*0$qRH|ñ!#P9G€˯1;3[CBpF+HEPpsPCpZQ{yZ\^df˫Q%hp r t[Iqސz˦| ~0RڴѸKk;!a૘{ ڶǹk*ᷪZJ[}Ww+[:[$뺸+K׻D{k~ċwAż]ԋz$![l;T/սD1^CK[i۾'F/뾭bwq1K@4a0˾: mZ=|ɗ | E2jZ\2}A  J z5;(# &c2\:6) ! ?s5* %@ {0ADp$Ԥ+["GkES /ۗUJMc pQO+jpEX@\COl x{!IC_!&A @9zi9d9z$6ċl I B]L+}\|N]N |$M 8m^m4Ծ^+ )&/ lծ*\ʮTo<^~Z" T-5{.-K︕^.  ?_;0^&(*, $2?4_6dh1>@Bo:/CJL']\HT_VmxS^`..1]/hjd#_= p 0z/ | PwyU=1qzyO 0p.-]ғO:Wf  ']0 /q N @ B00  *]   /* P.   BBB    B  B  CAD   Bp0+$P-P9z!_  ` A=r TtpF4X@0T uH:tA,Gbi ,=Jp`A!<@AY\eǁx7Q=Z.=w n$.s N$G6P le,=gH!R`gօQnA@.KKc=[L^&YMְ׃`dSۃ>:`;= J-k A;[9]dd1 caC,6  E ;O X @%(F @F<PqJb\Q/̨ 8zWiK(LBdX&a5@W@*PRax ?2*VYoEVl9IG$%yz!']P܄`9@(arjВdթ;Ҩ2PH @Ө ꨗb4+k,`)6F+%k:Rj/"jN_ګk.a^θ´[| P7 po!w2 E2;&uo. Q/e0Q޽r @]QBWo6 ),1, ۈ!:^Uʯe%k.Ɯ;bˮ([dIw W6/Y 0B࿦HIɭfL&^S5!-`%'eJq@V5]B`7aS<;AܟZn7O#-ҁ1gG$#X˜oXʤ#b#e=.li$•fdi5C-2i<# JAMB=E_IǼ e&dI&.%{b&XY*- ?nS4) Aи4{E_HX+pq|?4khܴK rb,6HL6(nS(zwD880} g!^rHb$ ͨ)$ V<:K6~5y$F:"iJZ$Nz&Ǒf1% *Wo2BT/vk"%)O -^@vrµȤ+KY)0ِhR$P6 i7K8٬eƒ1b?"* X<AĶ>qU) -^w0$YHЃb)>'JQ\5*юZ0"9=JҒҜ&MJUR_s5Fvfg+ͩ8[ Pze:qN$CL/#TBX$O;U$L/{IRvKF(6MW“2x V9LT<"@fī&LJxl*pGg(SbD'! @JpAJOq -K^HU,pKN MnnK[eΦ>o(ͮ.˩"oYR,U0ӎ M宂ȝdM JGqBCǵ Xע;HuUp'd& Z+@/cϴ7Xr]L ;hUDsgy1:WTŃ KC*CnIB4! ⃐j8326u`O%APnx@P(B bb+| Ub(UMo C]Ό¯ESi'֘0TWZoKY +>6r-jgζJ-FFMi2ώ]1F º`uuFۉv;HFQ?LGn TC7AMGii>tcEh*Tu\AʲN~L!+^o]<&> hfe [V;5yMS%NTH^%> %$L+ *D_}+[:pgC)Na[ĚIh,*dgRg$؎#sf /gP={70%<6szwQ φN@iQ[~+A-A~Q9đ02h=" ꖋP##Rf5ֽ'nvK?R g=2b *R'%q]Ckj)\@.6E rA yaY39fkN&S QMYuZO 5xv0:Zz4P6`G(9 ga6BXFz*e dw@K'>nd *ˣtA>#Aבuăvx<6SEXd=8PQpX]VxDd"QDQdGBg< 4Q c283S!7J*Ѩ ? A D&DEDFA2| ,.Dk'm$T*nDU*t%`qo;PA8 WCu%D':_EG#Y(5ђ6WPe@EP5=AAy}<W$&BUFBBC*y /T/V{Qrz,]uHԂ`ĢH7$y~dwǛJ -Yi,Ǚ,d@@9Yyؙڹٝ9Yy虞y?9Yyٟ:Rz ڠZZzz ": p(*,ڢ.02:4Z6z8:<ڣ>@ @> FzHJLڤNPR:TZVzXZ\ڥ^PJ;PK%$$PKj?OEBPS/auditing.htm Verifying Security Access with Auditing

The script content on this page is for navigation purposes only and does not alter the content in any way.

9 Verifying Security Access with Auditing

This chapter contains:


See Also:

"Guidelines for Auditing" for general guidelines to follow for auditing your system

About Auditing

This section contains:


See Also:

Oracle Audit Vault Administrator's Guide for information about Oracle Audit Vault, which provides advanced auditing features

Why Is Auditing Used?

You typically use auditing to perform the following activities:

  • Enable accountability for actions. These include actions taken in a particular schema, table, or row, or affecting specific content.

  • Deter users (or others, such as intruders) from inappropriate actions based on their accountability.

  • Investigate suspicious activity. For example, if a user is deleting data from tables, then a security administrator might decide to audit all connections to the database and all successful and unsuccessful deletions of rows from all tables in the database.

  • Notify an auditor of the actions of an unauthorized user. For example, an unauthorized user could be changing or deleting data, or the user has more privileges than expected, which can lead to reassessing user authorizations.

  • Monitor and gather data about specific database activities. For example, the database administrator can gather statistics about which tables are being updated, how many logical I/Os are performed, or how many concurrent users connect at peak times.

  • Detect problems with an authorization or access control implementation. For example, you can create audit policies that you expect will never generate an audit record because the data is protected in other ways. However, if these policies generate audit records, then you will know the other security controls are not properly implemented.

  • Address auditing requirements for compliance. Regulations such as the following have common auditing-related requirements:

    • Sarbanes-Oxley Act

    • Health Insurance Portability and Accountability Act (HIPAA)

    • International Convergence of Capital Measurement and Capital Standards: a Revised Framework (Basel II)

    • Japan Privacy Law

    • European Union Directive on Privacy and Electronic Communications

Protecting the Database Audit Trail

When auditing for suspicious database activity, you should protect the integrity of the audit trail records to guarantee the accuracy and completeness of the auditing information.

Oracle Database writes the database audit trail to the SYS.AUD$ and SYS.FGA_LOG$ tables. Audit records generated as a result of object audit options set for the SYS.AUD$ and SYS.FGA_LOG$ tables can only be deleted from the audit trail by someone who has connected with administrator privileges. Remember that administrators are also audited for unauthorized use. See "Auditing SYS Administrative Users" for more information.

Other ways to protect the database audit trail are as follows:

Activities That Are Always Audited for All Platforms

Oracle Database always audits certain database-related operations and writes them to the operating system audit files. It includes the actions of any user who is logged in with the SYSDBA or SYSOPER privilege. This is called mandatory auditing. Even if you have enabled the database audit trail (that is, setting the AUDIT_TRAIL parameter to DB), Oracle Database still writes mandatory records to operating system files.

By default, the operating system files are in the $ORACLE_HOME/admin/$ORACLE_SID/adump directory on UNIX systems. On Windows systems, Oracle Database writes this information to the Windows Event Viewer. You can change the location of this directory by setting the AUDIT_FILE_DEST initialization parameter, which is described in "Specifying a Directory for the Operating System Audit Trail".

Mandatory auditing includes the following operations:


Note:

If you set the AUDIT_SYSLOG_LEVEL initialization parameter, mandatory actions are written the to the UNIX syslog. See "Using the Syslog Audit Trail on UNIX Systems" for more information about the syslog audit trail. See also your operating system-specific Oracle Database documentation for more information about the operating system and syslog audit trail.

Selecting an Auditing Type

Table 9-1 provides a roadmap for selecting and using the different audit options available.

Table 9-1 Selecting an Auditing Type

What Do You Want to Audit?About This Type of Auditing

General activities

You can audit SQL statements, privileges, schema objects, functions, procedures, packages, triggers, and network activity. For example, you can audit each time a particular user performs an UPDATE or a DELETE SQL statement.

Location of audit records: Oracle Database writes these audit records to the location based on the AUDIT_TRAIL initialization parameter. See also "About Audit Records".

General steps:

  1. See "Auditing General Activities with Standard Auditing" to understand more about auditing general activities.

  2. Decide whether you want to write audit records to the database audit trail or to an operating system file. See "Managing the Database Audit Trail".

  3. Set the AUDIT_TRAIL initialization parameter to enable auditing and to select the audit trail destination (database audit trail or operating system audit trail). See "Configuring Standard Auditing with the AUDIT_TRAIL Initialization Parameter".

  4. Use the AUDIT and NOAUDIT SQL statements to audit the general activities. See the relevant categories under "Auditing General Activities with Standard Auditing".

  5. To monitor audit activities, periodically check the operating system records you configured, or query the audit trail data dictionary views. See "Finding Information About Audited Activities".

  6. Perform maintenance on the audit trail. See "Managing Audit Trail Records".

  7. Periodically archive and purge the contents of the audit trail. See "Purging Audit Trail Records".

Default, security-relevant SQL statements and privileges

Oracle Database provides a set of default audit settings that you can enable for commonly used security-relevant SQL statements and privileges.

Location of audit records: Oracle Database writes these audit records to the location based on the AUDIT_TRAIL initialization parameter. See also "About Audit Records".

General steps:

  1. Follow the instructions in "Using Default Auditing for Security-Relevant SQL Statements and Privileges" to enable default auditing.

    To understand more about the database audit trail, see "Managing Audit Trail Records".

  2. To monitor audit activities, periodically query the database audit trail data dictionary views. See "Finding Information About Audited Activities".

  3. Perform maintenance on the database audit trail. See "Managing the Database Audit Trail".

  4. Periodically archive and purge the contents of the audit trail. See "Purging Audit Trail Records".

Specific, fine-grained activities

You can audit at the most granular level, data access, and actions based on content, using Boolean measures, such as value > 7800 or the IP address from which an action occurred.

Location of audit records: You can write the audit records to either the database audit trail or an operating system audit trail in XML format. See also "About Audit Records".

General steps:

  1. See "Auditing Specific Activities with Fine-Grained Auditing" to understand more about auditing specific activities.

  2. Decide whether you want to write audit records to the database audit trail or to an operating system file. See "Managing the Database Audit Trail".

  3. Use the DBMS_FGA PL/SQL package to configure fine-grained auditing policies. The DBMS_FGA.ADD_POLICY procedure provides the audit_trail parameter, which you use to select the audit trail type. You can choose between a database audit trail or an operating system audit trail using XML files. See the following sections:

    "Creating an Audit Trail for Fine-Grained Audit Records"

    "Using the DBMS_FGA Package to Manage Fine-Grained Audit Policies"

  4. To monitor audit activities, periodically check the operating system records you configured, or query the audit trail data dictionary views. See "Finding Information About Audited Activities".

  5. Perform maintenance on the audit trail. See "Managing Audit Trail Records".

  6. Periodically archive and purge the contents of the audit trail. See "Purging Audit Trail Records".

SYS administrative users

You can audit the top-level SQL statements issued by users who have connected using the SYSDBA or SYSOPER privilege. (Top-level refers to statements directly issued by a user. Statements run from a PL/SQL procedure or function are not considered top-level.)

Location of audit records: Oracle Database writes these audit records to an operating system audit trail only. On Windows, Oracle Database writes the SYS audit records to the Windows Event log by default. For UNIX systems, you can write records to a syslog file. See also "About Audit Records".

General steps:

  1. See "Auditing SYS Administrative Users" to configure administrative auditing.

  2. To understand more about the operating system audit trail, see Managing the Operating System Audit Trail.

  3. To monitor audit activities, periodically check the operating system or syslog records you configured. If you are writing to an XML file, you can query the V$XML_AUDIT_TRAIL and DBA_COMMON_AUDIT_TRAIL views. See "Finding Information About Audited Activities".

  4. Perform maintenance on the audit trail. See "Managing Audit Trail Records"

  5. Periodically archive and purge the contents of the audit trail. See "Purging Audit Trail Records".


Auditing General Activities with Standard Auditing

This section contains:


See Also:


About Standard Auditing

This section contains:

Configuring Standard Auditing with the AUDIT_TRAIL Initialization Parameter

This section contains:

Enabling or Disabling the Standard Audit Trail

You enable the standard audit trail by setting the AUDIT_TRAIL initialization parameter. This setting determines whether to create the audit trail in the database audit trail, write the audit activities to an operating system file, or to disable auditing.

To enable or disable the standard audit trail, log in to SQL*Plus with administrative privileges, and use the ALTER SYSTEM statement. Afterwards, you need to restart the database instance.

To check the current value of the AUDIT_TRAIL parameter, use the SHOW PARAMETER command in SQL*Plus.

Example 9-1 shows how to check the AUDIT_TRAIL parameter setting.

Example 9-2 shows how to log onto SQL*Plus, enable the standard audit trail, and then restart the database instance.

This example uses the SCOPE clause because the database instance had been started using a server parameter file (SPFILE). Starting the database with a server parameter file is the preferred way of starting a database instance. See Oracle Database Administrator's Guide for information about creating configuring server parameter files.

Settings for the AUDIT_TRAIL Initialization Parameter

Table 9-2 lists the settings you can use for the AUDIT_TRAIL initialization parameter.

Table 9-2 AUDIT_TRAIL Initialization Parameter Settings

AUDIT_TRAIL ValueDescription

DB

Directs audit records to the database audit trail (the SYS.AUD$ table), except for mandatory and SYS audit records, which are always written to the operating system audit trail. (Table 9-1 describes the location of the audit records for each type of auditing.) Use this setting for a general database for manageability. DB is the default setting for the AUDIT_TRAIL parameter.

If the database was started in read-only mode with AUDIT_TRAIL set to DB, then Oracle Database internally sets AUDIT_TRAIL to OS. Check the alert log for details.

See also "Managing the Database Audit Trail".

DB, EXTENDED

Behaves the same as AUDIT_TRAIL=DB, but also populates the SQL bind and SQL text CLOB-type columns of the SYS.AUD$ table, when available.

DB,EXTENDED enables you to capture the SQL statement used in the action that was audited. You can capture both the SQL statement that caused the audit, and any associated bind variables. However, be aware that you only can capture data from the following column datatypes: CHAR, NCHAR, VARCHAR, VARCHAR2, NVARCHAR2, NUMBER, FLOAT, BINARY_FLOAT, BINARY_DOUBLE, LONG, ROWID, DATE, TIMESTAMP, and TIMESTAMP WITH TIMEZONE. Also be aware that DB, EXTENDED can capture sensitive data, such as credit card information. See also "Auditing Sensitive Information".

If the database was started in read-only mode with AUDIT_TRAIL set to DB, EXTENDED, then Oracle Database internally sets AUDIT_TRAIL to OS. Check the alert log for details.

You can specify DB,EXTENDED in either of the following ways:

ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL='DB','EXTENDED' SCOPE=SPFILE;

However, do not enclose DB, EXTENDED in quotes, for example:

ALTER SYSTEM SET AUDIT_TRAIL='DB, EXTENDED' SCOPE=SPFILE;

OS

Directs all audit records to an operating system file.

Oracle recommends that you use the OS setting, particularly if you are using an ultra-secure database configuration. See "Advantages of the Operating System Audit Trail" for more information. See also Example 9-3, "Text File Operating System Audit Trail".

If you set AUDIT_TRAIL to OS, then set the following additional initialization parameters:

  • AUDIT_FILE_DEST, which specifies the location of the operating system audit record file. On UNIX systems, the default location is $ORACLE_HOME/admin/$ORACLE_SID/adump. For better performance on UNIX systems, set the AUDIT_FILE_DEST parameter to a directory on a disk that is locally attached to the host running the Oracle Database instance. On Windows, the OS setting writes the audit trail to the Application area of the Windows Event Viewer.

  • AUDIT_SYS_OPERATIONS, if you want to audit the top-level SQL statements directly issued by users who have connected with the SYSDBA or SYSOPER privilege. To enable this auditing, set AUDIT_SYS_OPERATIONS to TRUE.

    If you set AUDIT_SYS_OPERATIONS to TRUE and AUDIT_TRAIL to XML or XML,EXTENDED, then Oracle Database writes SYS audit records operating system files in XML format.

  • AUDIT_SYSLOG_LEVEL, which writes SYS and standard OS audit records to the system audit log using the SYSLOG utility. This option only applies to UNIX environments. See "Configuring Syslog Auditing" for more information.

See also "Managing the Operating System Audit Trail".

XML

Writes to the operating system audit record file in XML format. Records all elements of the AuditRecord node given by the XML schema in http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-11_2.xsd except Sql_Text and Sql_Bind to operating system XML audit files. (This .xsd file represents the schema definition of the XML audit file. An XML schema is a document written in the XML Schema language.)

See also "Advantages of the Operating System Audit Trail" and Example 9-4, "XML File Operating System Audit Trail".

If you set the XML value, then also set the AUDIT_FILE_DEST parameter. For all platforms, including Windows, the default location for XML audit trail records is $ORACLE_HOME/admin/$ORACLE_SID/adump.

In addition to XML files, Oracle Database creates a text index file that lists the XML files that were generated by the XML auditing. The file is named adx_$ORACLE_SID.txt (for example, adx_ORCL.txt). The adx_$ORACLE_SID.txt is only used when you query the V$XML_AUDIT_TRAIL data dictionary view. Deleting this file does not interfere with auditing, except that you will not see the audit records from the files that are not present in adx_$ORACLE_SID.txt at the time of the query.

The XML AUDIT_TRAIL value does not affect syslog audit file. In other words, if you have set the AUDIT_TRAIL parameter to XML, then the syslog audit records will still be in text format, not XML file format.

You can control the output for SYS and mandatory audit records as follows:

  • To write SYS and mandatory audit files to operating system files in XML format: Set AUDIT_TRAIL to XML or XML,EXTENDED, set AUDIT_SYS_OPERATIONS to TRUE, but do not set the AUDIT_SYSLOG_LEVEL parameter.

  • To write SYS and mandatory audit records to syslog audit files and standard audit records to XML audit files: Set AUDIT_TRAIL to XML or XML,EXTENDED, set AUDIT_SYS_OPERATIONS to TRUE, and set the AUDIT_SYSLOG_LEVEL parameter.

XML, EXTENDED

Behaves the same as AUDIT_TRAIL=XML, but also includes SQL text and SQL bind information in the operating system XML audit files.

You can specify XML,EXTENDED in either of the following ways:

ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL='XML','EXTENDED' SCOPE=SPFILE;

However, do not enclose XML, EXTENDED in quotes, for example:

ALTER SYSTEM SET AUDIT_TRAIL='XML, EXTENDED' SCOPE=SPFILE;

See also the following sections:

NONE

Disables standard auditing.


Note the following:

  • You do not need to restart the database after you run the AUDIT or NOAUDIT statements. You only need to restart the database if you made a universal change, such as changing the AUDIT_TRAIL initialization parameter.

  • You do not need to set AUDIT_TRAIL to enable either fine-grained auditing or SYS auditing. For fine-grained auditing, you add and remove fine-grained audit policies as necessary, applying them to the specific operations or objects you want to monitor. To enable SYS auditing, set the AUDIT_SYS_OPERATIONS parameter to TRUE.

What Do the Operating System and Database Audit Trails Have in Common?

The operating system and database audit trails both capture many of the same types of actions. Table 9-3 lists the operating system audit trail records. Most map to equivalent columns in the DBA_AUDIT_TRAIL view. For a description of these columns, see Oracle Database Reference.

Footnote 1 For example, if the ACTION value is 104 (for AUDIT) or 105 (for NOAUDIT), then the SYS$OPTIONS number represents an audit option listed in the STMT_AUDIT_OPTION_MAP table. If the ACTION value is 108 (for GRANT) or 109 (for REVOKE), then the number represents a privilege listed in the SYSTEM_PRIVILEGE_MAP table.

Using the Operating System Audit Trail

This section contains:

What Do Operating System Audit Trail Records Look Like?

The operating system audit trail files are in either text or XML file format. Be aware that the contents of the text and XML operating system files have some differences, and that the formats may change across different releases. With each release of Oracle Database, new enhancements, such as the audit type, have been made to the XML file, but not the text file. The text operating system file has a different presentation for the timestamp, for example:

Wed May  6 00:57:36 2009 -07:00

However, this timestamp does not appear in the event log or syslog, which have their own format for timestamps. The timestamp string only appears in the text operating system audit files.

Example 9-3 shows a typical text operating system audit trail for a logon operation on an Oracle database that is installed on Microsoft Windows. (The text in the actual record wraps around, but for this manual, each item is separated onto its own line for easier readability.)

In this example:

  • LENGTH refers to the total number of bytes used in this audit record. This number includes the trailing newline bytes (\n), if any, at the end of the audit record.

  • [] brackets indicate the length of each value for each audit entry. For example, the USERID entry, DBSNMP, is 6 bytes long.

  • SESSIONID indicates the audit session ID number. You can also find the session ID by querying the AUDSID column in the V$SESSION data dictionary view.

  • ENTRYID indicates the current audit entry number, assigned to each audit trail record. The audit ENTRYID sequence number is shared between fine-grained audit records and regular audit records.

  • STATEMENT is a numeric ID assigned to the statement the user runs. It appears for each statement issued during the user session, because a statement can result in multiple audit records.

  • ACTION is a numeric value representing the action the user performed. The corresponding name of the action type is in the AUDIT_ACTIONS table. For example, action 100 refers to LOGON.

  • RETURNCODE indicates if the audited action was successful. 0 indicates success. If the action fails, the return code lists the Oracle Database error number. For example, if you try to drop a non-existent table, the error number is ORA-00903 invalid table name, which in turn translates to 903 in the RETURNCODE setting.

  • COMMENT$TEXT indicates additional comments about the audit record. For example, for LOGON audit records, it can indicate the authentication method.It corresponds to the COMENT_TEXT column of the DBA_COMMON_AUDIT_TRAIL data dictionary view.

  • DBID is a database identifier calculated when the database is created. It corresponds to the DBID column of the V$DATABASE data dictionary view.

  • ECONTEXT_ID indicates the application execution context identifier.

  • PRIVS$USED refers to the privilege that was used to perform an action. To find the privilege, query the SYSTEM_PRIVILEGE_MAP table. For example, privilege 5 refers to -5 in this table, which means CREATE SESSION. PRIVS$USED corresponds to the PRIV_USED column in the DBA_COMMON_AUDIT_TRAIL, which lists the privilege by name.

Other possible values are as follows:

  • SCN (for example, SCN:8934328925) indicates the System Change Number (SCN). Use this value if you want to perform a flashback query to find the value of a setting (for example, a column) at a time in the past. For example, to find the value of the ORDER_TOTAL column of the OE.ORDERS table based on the SCN number, use the following SELECT statement:

    SELECT ORDER_TOTAL 
    FROM OE.ORDERS
    AS OF SCN = 8934328925
    WHERE ORDER_TOTAL = 86;
    
  • SES_ACTIONS indicates the actions that took place during the session. This field is present only if the event was audited with the BY SESSION clause. Because this field does not explain in detail the actions that occurred during the session, you should configure the audit event with the BY ACCESS clause.

    The SES_ACTIONS field contains 16 characters. Positions 14, 15, and 16 are reserved for future use. In the first 12 characters, each position indicates the result of an action. They are: ALTER, AUDIT, COMMENT, DELETE, GRANT, INDEX, INSERT, LOCK, RENAME, SELECT, UPDATE, and FLASHBACK. For example, if the user had successfully run the ALTER statement, the SES_ACTIONS setting is as follows:

    S---------------
    

    The S, in the first position (for ALTER), indicates success. Had the ALTER statement failed, the letter F would have appeared in its place. If the action resulted in both a success and failure, then the letter is B.

  • SES$TID indicates the ID of the object affected by the audited action.

  • SPARE2 indicates whether the user modified SYS.AUD$ table. 0 means the user modified SYS.AUD$; otherwise, the value is NULL.

Similarly, Example 9-4 shows how an XML audit trail record appears. The text wraps around in the actual record, but for this manual, each element appears on its own line for easier readability. To find all the tags that appear in the XML audit file, you can view its schema in a Web browser at

http://www.oracle.com/technology/oracleas/schema/dbserver_audittrail-11_2.xsd

In this example:

  • AuditRecord element contains the entire audit record. (See Example 9-3 for more information about the elements within the Audit_Record element.)

  • Audit_Type indicates the type of audit trail. Possible values are as follows:

    • 1: Standard audit record

    • 2: Fine-grained audit record

    • 4: SYS audit record

    • 8: Mandatory audit record

    This field only appears in the XML audit files, not the OS text audit files.

  • Extended_Timestamp indicates the time of the audited operation (timestamp of user login for entries created by AUDIT SESSION), in Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). This field only appears in the XML audit files, not the OS text audit files.

  • Instance_Number indicates the instance number to which the user is connected, for an Oracle Real Application Clusters environment. In this example, the number is 0, which is used for single-instance database installations. The INSTANCE_NUMBER initialization parameter specifies this number.

The following values can appear if you set the AUDIT_TRAIL parameter to XML, EXTENDED. Both are listed in the DBA_COMMON_AUDIT_TRAIL data dictionary view.

  • Sql_Bind (for example, <Sql_Bind>#1(5):89</Sql_Bind>) shows the value of the bind variable. The syntax is as follows:

    VariablePosition(LengthOfVariableValue):ValueofBindVariable
    

    The example #1(5):89 indicates that there is 1 bind variable; its value is 5 characters long; and the value of the bind variable is 89.

  • Sql_Text (for example, <Sql_Text>begin procedure_one(:num); end; </Sql_Text>) appears if you have set the AUDIT_TRAIL parameter to XML, EXTENDED. It shows the SQL text that the user entered.

Advantages of the Operating System Audit Trail

Using the operating system audit trail offers these advantages:

How the Operating System Audit Trail Works

The operating system audit trail writes the audit data to an operating system file. You can enable this feature by setting the AUDIT_TRAIL initialization parameter to one of the following values:

  • OS: Writes the audit trail records to a text operating system file on UNIX systems and to the applications Event Viewer on Microsoft Windows.

  • XML: Writes the audit trail records to an XML file.

  • XML, EXTENDED: Writes the audit trail records to an XML file and includes SQL text and SQL bind information in the operating system XML audit files.

The AUDIT_FILE_DEST initialization parameter sets the location of the operating system audit file. If you want to audit top-level statements issued by users who log in to the database with the SYSDBA or SYSOPER privilege, then set the AUDIT_SYS_OPERATIONS parameter to TRUE. See Table 9-2, "AUDIT_TRAIL Initialization Parameter Settings" for more information about these settings.

The records that are written to an operating system file are not recorded to the SYS.AUD$ and SYS.FGA_LOG$ tables. You can still view the contents of the XML operating system audit files by querying the DBA_COMMON_AUDIT_TRAIL data dictionary views. Querying this view parses all XML files (all files with an .xml extension) in the AUDIT_FILE_DEST directory, and then presents them in relational table format. Because XML is a standard document format, many utilities are available to parse and analyze XML data. Consult the operating system-specific Oracle Database documentation to find if this feature has been implemented on your operating system.

Specifying a Directory for the Operating System Audit Trail

Use the AUDIT_FILE_DEST initialization parameter to specify an operating system directory into which the audit trail is written, when the AUDIT_TRAIL initialization parameter is set to OS, XML, or XML, EXTENDED. You must set AUDIT_FILE_DEST to a valid directory with permissions restricted to the owner of the Oracle software and the DBA group. Mandatory auditing information also goes into that directory, as do audit records for user SYS if the AUDIT_SYS_OPERATIONS initialization parameter is specified. You can change the AUDIT_FILE_DEST parameter by using the following ALTER SYSTEM statement, which enables the new destination to be effective for all subsequent sessions.

ALTER SYSTEM SET AUDIT_FILE_DEST = directory_path DEFERRED;

To find the current setting of the AUDIT_FILE_DEST parameter, issue the following command:

SHOW PARAMETER AUDIT_FILE_DEST

The location of the operating system files depends on the following:

  • If the database is not running and you have not set the AUDIT_FILE_DEST parameter, then the operating system files are placed in the first default location $ORACLE_BASE/admin/$ORACLE_SID/adump directory.

  • If the database is not running and the first default location, the $ORACLE_BASE/admin/$ORACLE_SID/adump directory, is inaccessible or cannot be written to, or the Oracle process cannot identify the environment variables, then the second default location, $ORACLE_HOME/rdbms/audit is used.

  • When the database is open and Oracle Database reads the initialization file (initSID.ora) for the database instance, the value of AUDIT_FILE_DEST parameter is used as the operating system audit file directory.

  • For UNIX and Solaris systems, all operating system files are written to a directory in the operating system. For Windows, the operating system text records are available from the Windows Event Viewer, but operating system XML files are available from an operating system directory, as explained in the preceding bulleted items.


Notes:

For platforms other than UNIX, Solaris, and Windows, check the platform documentation to learn the correct target directory for operating system files.

Using the Syslog Audit Trail on UNIX Systems

On UNIX systems, you can audit the activities of users, including privileged users, and record these activities in a syslog file by creating a syslog audit trail.

This section contains:

About the Syslog Audit Trail

A potential security vulnerability for the operating system audit trail is that a privileged user, such as a database administrator, can modify or delete database audit records. To minimize this risk, you can use a syslog audit trail. Syslog is a standard protocol on UNIX-based systems for logging information from different components of a network. Applications call the syslog() function to log information to the syslog daemon, which then determines where to log the information. You can configure syslog to log information to a file or to a dedicated host by editing the syslog.conf file. You can also configure syslog to alert a specified set of users when information is logged.

Because applications, such as an Oracle process, use the syslog() function to log information to the syslog daemon, a privileged user would not have permissions to the file system where syslog messages are logged. For this reason, audit records stored using a syslog audit trail can be more secure than audit records stored using an operating system audit trail. In addition to restricting permissions to a file system for a privileged user, for a syslog audit trail to be secure, neither privileged users nor the Oracle process should have root access to the system where the audit records are written.


Caution:

You should have a strong understanding of how to work with syslog before enabling syslog auditing. See the following references for more information about syslog:
  • Oracle Database Reference for information about the AUDIT_SYSLOG_LEVEL initialization parameter

  • The UNIX man page for the syslogd utility for more information about the facility.priority settings and their directory paths


Configuring Syslog Auditing

To enable syslog auditing, follow these steps:

  1. Assign the value of OS to the AUDIT_TRAIL initialization parameter, as described in "Enabling or Disabling the Standard Audit Trail".

    For example:

    ALTER SYSTEM SET AUDIT_TRAIL=OS SCOPE=SPFILE;
    
  2. Manually set the AUDIT_SYSLOG_LEVEL parameter to the initialization parameter file, initsid.ora.

    Set the AUDIT_SYSLOG_LEVEL parameter to specify a facility and priority in the format AUDIT_SYSLOG_LEVEL=facility.priority.

    • facility: Describes the part of the operating system that is logging the message. Accepted values are user, local0local7, syslog, daemon, kern, mail, auth, lpr, news, uucp, and cron.

      The local0local7 values are predefined tags that enable you to sort the syslog message into categories. These categories can be log files or other destinations that the syslog utility can access. To find more information about these types of tags, refer to the syslog utility MAN page.

    • priority: Defines the severity of the message. Accepted values are notice, info, debug, warning, err, crit, alert, and emerg.

    The syslog daemon compares the value assigned to the facility argument of the AUDIT_SYSLOG_LEVEL parameter with the syslog.conf file to determine where to log information.

    For example, the following statement identifies the facility as local1 with a priority level of warning:

    AUDIT_SYSLOG_LEVEL=local1.warning
    

    See Oracle Database Reference for more information about AUDIT_SYSLOG_LEVEL.

  3. Log in to the computer that contains the syslog configuration file, /etc/syslog.conf, with the superuser (root) privilege.

  4. Add the audit file destination to the syslog configuration file syslog.conf.

    For example, assuming you had set the AUDIT_SYSLOG_LEVEL to local1.warning, enter the following:

    local1.warning /var/log/audit.log
    

    This setting logs all warning messages to the /var/log/audit.log file.

  5. Restart the syslog logger:

    $/etc/rc.d/init.d/syslog restart
    

    Now, all audit records will be captured in the file /var/log/audit.log through the syslog daemon.

  6. Restart the database instance:

    CONNECT SYS / AS SYSOPER
    Enter password: password
    
    SHUTDOWN IMMEDIATE
    STARTUP
    

How the AUDIT and NOAUDIT SQL Statements Work

This section contains:


See Also:

Oracle Database SQL Language Reference for a description of the AUDIT statement syntax

Auditing Statement Executions: Successful, Unsuccessful, or Both

For statement, privilege, and schema object auditing, Oracle Database permits the selective auditing of successful executions of statements, unsuccessful attempts to execute statements, or both. This enables you to monitor actions even if the audited statements do not complete successfully. Monitoring unsuccessful SQL statement can expose users who are snooping or acting maliciously, though most unsuccessful SQL statements are neither.

This method of auditing is also useful in that it reduces the audit trail, helping you to focus on specific actions. This can aid in maintaining good database performance.

The options are as follows:

For example:

AUDIT CREATE TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

Benefits of Using the BY ACCESS Clause in the AUDIT Statement

By default, Oracle Database writes a new audit record for every audited event, using the BY ACCESS clause functionality. To use this functionality, either include BY ACCESS in the AUDIT statement, or if you want, you can omit it because it is the default. (As of Oracle Database 11g Release 2 (11.2.0.2), the BY ACCESS clause is the default setting.)

Oracle recommends that you audit BY ACCESS and not BY SESSION in your AUDIT statements. The benefits of using the BY ACCESS clause in the AUDIT statement are as follows:

  • The audit records generated through the BY ACCESS audit option have more information, such as execution status (return code), date and time of execution, the privileges used, the objects accessed, the SQL text itself and its bind values. In addition, the BY ACCESS audit option captures the SCN for each execution and this can help flashback queries.

  • Oracle Database records separately each execution of a SQL statement, the use of a privilege, and access to the audited object. Given that the values for the return code, timestamp, SQL text recorded are accurate for each execution, this can help you find how many times the action was performed.

  • The BY ACCESS audit records have separate LOGON and LOGOFF entries, each with fine-grained timestamps.

For example:

AUDIT SELECT TABLE BY ACCESS;

In this scenario:

  • The user jward connects to the database and issues five SELECT statements against the table named departments and then disconnects from the database.

  • The user swilliams connects to the database and issues three SELECT statements against the departments table and then disconnects from the database.

The audit trail contains eight records, one recorded for each SELECT statement.

Auditing SQL Statements

This section contains:

Configuring SQL Statement Auditing

Use the AUDIT statement to configure SQL statement auditing. You must have the AUDIT SYSTEM system privilege before you can enable auditing. Typically, only the security administrator is granted this system privilege.

Example 9-7 shows how to audit the SELECT TABLE SQL statement.

If you plan to audit all SQL statements, individual user connections, or references to non-existent objects, follow these guidelines:

See Oracle Database SQL Language Reference for detailed information about the AUDIT SQL statement.

Auditing Privileges

This section contains:

Types of Privileges That Can Be Audited

You can audit the use of any system privilege. Similar to statement auditing, privilege auditing audits the activities of all database users or only a specified list.

If you set similar audit options for both statement and privilege auditing, then only a single audit record is generated. For example, if the statement clause TABLE and the system privilege CREATE TABLE are both audited, then only a single audit record is generated each time a table is created.

Privilege auditing does not occur if the action is already permitted by the existing owner and object privileges. Privilege auditing is triggered only if the privileges are insufficient, that is, only if what makes the action possible is a system privilege. For example, suppose that user SCOTT has been granted the SELECT ANY TABLE privilege and the SELECT ANY TABLE is being audited. If SCOTT selects his own table (for example, SCOTT.EMP), then the SELECT ANY TABLE privilege is not used. Because he performed the SELECT statement within his own schema, no audit record is generated. On the other hand, if SCOTT selects from another schema (for example, the HR.EMPLOYEES table), then an audit record is generated. Because SCOTT selected a table outside his own schema, he needed to use the SELECT ANY TABLE privilege.

Privilege auditing is more focused than statement auditing, because each privilege auditing option audits only specific types of statements, not a related list of statements. For example, the statement auditing clause, TABLE, audits CREATE TABLE, ALTER TABLE, and DROP TABLE statements. However, the privilege auditing option, CREATE TABLE, audits only CREATE TABLE statements, because only the CREATE TABLE statement requires the CREATE TABLE privilege.

See the listing of system privileges in the GRANT SQL statement section of Oracle Database SQL Language Reference.

Removing Privilege Auditing

The following statement removes all privilege audit options:

NOAUDIT ALL PRIVILEGES;

This example disables the audit settings from Example 9-11:

NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE;

To disable privilege auditing options, you must have the AUDIT SYSTEM system privilege. Usually, only the security administrator is granted this system privilege.

Auditing SQL Statements and Privileges in a Multitier Environment

You can use the AUDIT statement to audit the activities of a client in a multitier environment. In a multitier environment, Oracle Database preserves the identity of a client through all tiers. Thus, you can audit actions taken on behalf of the client by a middle-tier application, by using the BY user clause in your AUDIT statement. The audit applies to all user sessions, including proxy sessions.

The middle tier can also set the user client identity in a database session, enabling the auditing of end-user actions through the middle-tier application. The end-user client identity then shows up in the audit trail.

Example 9-12 shows how to audit SELECT TABLE statements issued by the user jackson.

You can audit user activity in a multitier environment. Once audited, you can verify these activities by querying the DBA_AUDIT_TRAIL data dictionary view.

Figure 9-1 illustrates how you can audit proxy users by querying the COMMENT_TEXT, PROXY_SESSIONID, ACTION_NAME, and SESSION_ID columns of the DBA_AUDIT_TRAIL view. In this scenario, both the database user and proxy user accounts are known to the database. Session pooling can be used.

Figure 9-2 illustrates how you can audit client identifier information across multiple database sessions by querying the CLIENT_ID column of the DBA_AUDIT_TRAIL data dictionary view. In this scenario, the client identifier has been set to CLIENT_A. As with the proxy user-database user scenario described in Figure 9-1, session pooling can be used.


See Also:

"Preserving User Identity in Multitiered Environments" for more information about user authentication in a multitiered environment

Auditing Schema Objects

This section contains:

Schema Object Audit Options for Views, Procedures, and Other Elements

The definitions for views and procedures (including stored functions, packages, and triggers) reference underlying schema objects. Because of this dependency, some unique characteristics apply to auditing views and procedures, such as the likelihood of generating multiple audit records.

Views and procedures are subject to the enabled audit options on the base schema objects, including the default audit options. These options also apply to the resulting SQL statements.

Consider the following series of SQL statements:

AUDIT SELECT ON HR.EMPLOYEES BY ACCESS; 
 
CREATE VIEW employees_departments AS 
  SELECT employee_id, last_name, department_id
    FROM employees, departments
    WHERE employees.department_id = departments.department_id;
 
AUDIT SELECT ON employees_departments BY ACCESS; 

SELECT * FROM employees_departments; 

As a result of the query on the employees_departments view, two audit records are generated: one for the query on the employees_departments view and one for the query on the base table employees (indirectly through the employees_departments view). The query on the base table departments does not generate an audit record because the SELECT audit option for this table is not enabled. All audit records pertain to the user that queried the employees_departments view.

In the given example, if the AUDIT SELECT ON HR.EMPLOYEES; statement is omitted, then using the employees_departments view does not generate an audit record for the EMPLOYEES table.

Configuring Schema Object Auditing

You can use the AUDIT statement to configure object auditing in the current edition. Oracle Database SQL Language Reference lists valid object audit options for AUDIT and the schema object types for which each option is available.

A user can set any object audit option for the objects contained in his or her schema. The AUDIT ANY system privilege is required to set an object audit option for an object contained in another user schema or to set the default object auditing option. Usually, only the security administrator is granted the AUDIT ANY privilege.

Figure 9-2 shows how to audit all successful and unsuccessful DELETE statements on the laurel.emp table.

Example 9-14 shows how to audit all successful SELECT, INSERT, and DELETE statements on the dept table owned by user jward.

Example 9-15 shows how you can use the ON DEFAULT clause to apply to any new objects (tables, views, and sequences) that are created after you set the AUDIT statement. In this example, new objects that are created in the future will be audited for all unsuccessful SELECT statements:

Example 9-16 shows how to audit the execution of PL/SQL procedure or function.

Auditing Functions, Procedures, Packages, and Triggers

This section contains:

Removing the Auditing of Functions, Procedures, Packages, and Triggers

Use the NOAUDIT statement to remove the auditing of functions, procedures, and triggers. For example:

NOAUDIT EXECUTE PROCEDURE;

NOAUDIT EXECUTE PROCEDURE BY psmith;

NOAUDIT EXECUTE ON sales_data.checkwork;

Auditing Network Activity

This section contains:

About Network Auditing

You can use the AUDIT statement to audit unexpected errors in network protocol or internal errors in the network layer. Network auditing captures errors that occur during communication with the client on the network. These are errors thrown by the SQL*Net driver. There can be several causes of network errors. For example, an internal event set by a database engineer for testing purposes can cause a network error. Other causes include conflicting configuration settings for encryption, such as the network not finding the information required to create or process expected encryption. The errors that network auditing uncovers (such as ACTION 122 Network Error) are not connection failures: network auditing is only concerned with data as it travels across the network.

The audit record for network auditing lists the authentication type and SQL*Net address of the client (if available) in the COMMENT_TEXT field of the audit record, using the following format:

Authenticated by: authentication_type; Client Address: SQLNetAddress_of_client

The Client Address: SQLNetAddress_of_client portion only appears if this information is available.

Table 9-5 shows how to remedy four common error conditions.

Using Default Auditing for Security-Relevant SQL Statements and Privileges

This section contains:

Auditing Specific Activities with Fine-Grained Auditing

This section contains:

About Fine-Grained Auditing

Fine-grained auditing enables you to create policies that define specific conditions that must take place for the audit to occur. This enables you to monitor data access based on content. It provides granular auditing of queries, and INSERT, UPDATE, and DELETE operations. For example, a central tax authority must track access to tax returns to guard against employee snooping, with enough detail to determine what data was accessed. It is not enough to know that SELECT privilege was used by a specific user on a particular table. Fine-grained auditing provides this deeper functionality.

In general, fine-grained audit policies are based on simple, user-defined SQL predicates on table objects as conditions for selective auditing. During fetching, whenever policy conditions are met for a row, the query is audited.

You can use fine-grained auditing to audit the following types of actions:

  • Accessing a table between 9 p.m. and 6 a.m. or on Saturday and Sunday

  • Using an IP address from outside the corporate network

  • Selecting or updating a table column

  • Modifying a value in a table column

Fine-grained auditing records are stored in the SYS.FGA_LOG$ table. To find the records have been generated for the audit policies that are in effect, you can query the DBA_FGA_AUDIT_TRAIL view. The DBA_COMMON_AUDIT_TRAIL view combines both standard and fine-grained audit log records. In addition, you can use the V$XML_AUDIT_TRAIL view to find fine-grained audit records that were written in XML formatted files. For detailed information about these views, see Oracle Database Reference.


Note:

  • Fine-grained auditing is supported only with cost-based optimization. For queries using rule-based optimization, fine-grained auditing checks before applying row filtering, which could result in an unnecessary audit event trigger.

  • Policies currently in force on an object involved in a flashback query are applied to the data returned from the specified flashback snapshot (based on time or system change number (SCN).


Advantages of Fine-Grained Auditing

Fine-grained auditing creates a more meaningful audit trail, one that includes only very specific actions that you want to audit. It excludes unnecessary information that occurs if each table access was recorded. Fine-grained auditing has the following advantages over standard auditing:

Creating an Audit Trail for Fine-Grained Audit Records

You designate the audit trail format for fine-grained auditing by setting the audit_trail parameter for the DBMS_FGA.ADD_POLICY policy (not to be confused with the AUDIT_TRAIL initialization parameter) when you create the audit policy. Setting this parameter to XML or XML+EXTENDED writes the records to the operating system files in XML format. If you prefer to write the fine-grained audit records to the SYS.FGA_LOG$ table, then set the audit_trail parameter for the DBMS_FGA.ADD_POLICY parameter to DB or DB+EXTENDED. For a list of reasons why writing audit records to operating system files is beneficial, see "Advantages of the Operating System Audit Trail".

You can use the V$XML_AUDIT_TRAIL data dictionary view to make audit records from XML files available to DBAs through a SQL query, providing enhanced usability. Querying this view causes all XML files (all files with an .xml extension) in the AUDIT_FILE_DEST directory to be parsed and presented in relational table format.

The DBA_COMMON_AUDIT_TRAIL view includes the contents of the V$XML_AUDIT_TRAIL dynamic view for standard and fine-grained audit records.

Because the audit XML files are stored in files with the .xml extension on all platforms, the dynamic view presents audit information similarly on all platforms. See Oracle Database Reference for detailed information about the V$XML_AUDIT_TRAIL view contents.


Note:

If you audit tables that have sensitive data, remember that DB+EXTENDED and XML+EXTENDED settings for the <code>DBMS_FGA.ADD_POLICY audit_trail parameter will capture this data. See "Auditing Sensitive Information" for ways to handle this scenario.

Using the DBMS_FGA Package to Manage Fine-Grained Audit Policies

This section contains:

About the DBMS_FGA PL/SQL Package

To manage a fine-grained audit policy, you use the DBMS_FGA PL/SQL package. This package enables you to add all combinations of SELECT, INSERT, UPDATE, and DELETE statements to one policy. You also can audit MERGE statements, by auditing the underlying actions of INSERT and UPDATE. To audit MERGE statements, configure fine-grained access on the INSERT and UPDATE statements. Only one record is generated for each policy for successful MERGE operations. To administer fine-grained audit policies, you must have the EXECUTE privilege on the DBMS_FGA package.

The audit policy is bound to the table for which you created it. This simplifies the management of audit policies because the policy only must be changed once in the database, not in each application. In addition, no matter how a user connects to the database—from an application, a Web interface, or through SQL*Plus or Oracle SQL Developer—Oracle Database records any actions that affect the policy.

If any rows returned from a query match the audit condition that you define, then Oracle Database inserts an audit entry into the fine-grained audit trail. This entry excludes all the information that is reported in the regular audit trail. In other words, only one row of audit information is inserted into the audit trail for every fine-grained audit policy that evaluates to true.

For detailed information about the syntax of the DBMS_FGA package, see Oracle Database PL/SQL Packages and Types Reference. See also Oracle Database Advanced Application Developer's Guide.


Note:

If you plan to use the DBMS_FGA package policy across different editions, then you can control the results of the policy: whether the results are uniform across all editions, or specific to the edition in which the policy is used. See "How Editions Affects the Results of a Global Application Context PL/SQL Package" for more information.

Creating a Fine-Grained Audit Policy

To create a fine-grained audit policy, use the DBMS_FGA.ADD_POLICY procedure. This procedure creates an audit policy using the supplied predicate as the audit condition. Oracle Database executes the policy predicate with the privileges of the user who created the policy. The maximum number of fine-grained policies on any table or view object is 256. Oracle Database stores the policy in the data dictionary table, but you can create the policy on any table or view that is not in the SYS schema.

After you create the fine-grained audit policy, it does not reside in any specific schema, although the definition for the policy is stored in the SYS.FGA$ data dictionary table.

You cannot modify a fine-grained audit policy after you have created it. If you need to modify the policy, drop it and then recreate it.

The syntax for the ADD_POLICY procedure is:

DBMS_FGA.ADD_POLICY(
   object_schema      VARCHAR2, 
   object_name        VARCHAR2, 
   policy_name        VARCHAR2, 
   audit_condition    VARCHAR2, 
   audit_column       VARCHAR2, 
   handler_schema     VARCHAR2, 
   handler_module     VARCHAR2, 
   enable             BOOLEAN, 
   statement_types    VARCHAR2,
   audit_trail        BINARY_INTEGER IN DEFAULT,
   audit_column_opts  BINARY_INTEGER IN DEFAULT);

In this specification:

See Oracle Database PL/SQL Packages and Types Reference for additional details about the ADD_POLICY syntax.

Example 9-21 shows how to audit statements INSERT, UPDATE, DELETE, and SELECT on table HR.EMPLOYEES. Note that this example omits the audit_column_opts parameter, because it is not a mandatory parameter.

At this point, if you query the DBA_AUDIT_POLICIES view, you will find the new policy listed:

SELECT POLICY_NAME FROM DBA_AUDIT_POLICIES;

POLICY_NAME
-------------------------------
CHK_HR_EMPLOYEES

Afterwards, any of the following SQL statements log an audit event record.

SELECT COUNT(*) FROM HR.EMPLOYEES WHERE COMMISSION_PCT = 20 AND SALARY > 4500;

SELECT SALARY FROM HR.EMPLOYEES WHERE DEPARTMENT_ID = 50;

DELETE FROM HR.EMPLOYEES WHERE SALARY > 1000000;

Auditing Specific Columns and Rows

You can fine-tune the audit behavior by targeting a specific column, referred to as a relevant column, to be audited if a condition is met. To accomplish this, you use the audit_column parameter to specify one or more sensitive columns. In addition, you can audit data in specific rows by using the audit_condition parameter to define a Boolean condition.

Example 9-21 performs an audit if anyone in Department 50 tries to access the salary and commission_pct columns.

audit_condition    => 'DEPARTMENT_ID = 50', 
audit_column       => 'SALARY,COMMISSION_PCT,'

As you can see, this feature is enormously beneficial. It not only enables you to pinpoint particularly important types of data to audit, but it provides increased protection for columns that contain sensitive data, such as Social Security numbers, salaries, patient diagnoses, and so on.

If the audit_column lists more than one column, you can use the audit_column_opts parameter to specify whether a statement is audited when the query references any column specified in the audit_column parameter or only when all columns are referenced. For example:

audit_column_opts   => DBMS_FGA.ANY_COLUMNS,

audit_column_opts   => DBMS_FGA.ALL_COLUMNS,

If you do not specify a relevant column, then auditing applies to all columns.

For more information about the audit_condition, audit_column, and audit_column_opts parameters in the DBMS_FGA.ADD_POLICY procedure, see Oracle Database PL/SQL Packages and Types Reference. See also the usage notes for the ADD_POLICY procedure in that section.

Tutorial: Adding an E-Mail Alert to a Fine-Grained Audit Policy

This section contains:

Step 1: Install and Configure the UTL_MAIL PL/SQL Package

  1. Log on as user SYS with the SYSDBA privilege.

    sqlplus sys as sysdba
    Enter password: password
    
  2. Install the UTL_MAIL package.

    @$ORACLE_HOME/rdbms/admin/utlmail.sql
    @$ORACLE_HOME/rdbms/admin/prvtmail.plb
    

    The UTL_MAIL package enables you to manage e-mail. See Oracle Database PL/SQL Packages and Types Reference for more information about UTL_MAIL.

    Be aware that currently, the UTL_MAIL PL/SQL package does not support SSL servers.

  3. Check the current value of the SMTP_OUT_SERVER initialization parameter, and make a note of this value so that you can restore it when you complete this tutorial.

    For example:

    SHOW PARAMETER SMTP_OUT_SERVER
    

    If the SMTP_OUT_SERVER parameter has already been set, then output similar to the following appears:

    NAME                    TYPE              VALUE
    ----------------------- ----------------- ----------------------------------
    SMTP_OUT_SERVER         string            some_imap_server.example.com
    
  4. Issue the following ALTER SYSTEM statement:

    ALTER SYSTEM SET SMTP_OUT_SERVER="imap_mail_server.example.com";
    

    Replace imap_mail_server with the name of your SMTP server, which you can find in the account settings in your e-mail tool. Enclose these settings in quotation marks. For example:

    ALTER SYSTEM SET SMTP_OUT_SERVER="my_imap_server.example.com"
    
  5. Connect as SYS using the SYSOPER privilege and then restart the database.

    CONNECT SYS/AS SYSOPER
    Enter password: password
    
    SHUTDOWN IMMEDIATE
    STARTUP
    
  6. Ensure that the SMTP_OUT_SERVER parameter setting is correct.

    CONNECT SYS/AS SYSDBA
    Enter password: password
    
    SHOW PARAMETER SMTP_OUT_SERVER
    

    Output similar to the following appears:

    NAME                    TYPE              VALUE
    ----------------------- ----------------- ----------------------------------
    SMTP_OUT_SERVER         string            my_imap_server.example.com
    

Step 2: Create User Accounts

  1. Ensure that you are connected as SYS using the SYSDBA privilege, and then create the sysadmin_fga account, who will create the fine-grained audit policy.

    For example:

    CONNECT SYS/AS SYSDBA
    Enter password: password
    
    GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password;
    GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga;
    GRANT CREATE PROCEDURE, DROP ANY PROCEDURE TO sysadmin_fga;
    GRANT EXECUTE ON UTL_TCP TO sysadmin_fga;
    GRANT EXECUTE ON UTL_SMTP TO sysadmin_fga;
    GRANT EXECUTE ON UTL_MAIL TO sysadmin_fga;
    GRANT EXECUTE ON DBMS_NETWORK_ACL_ADMIN TO sysadmin_fga;
    

    Replace password with a password that is secure. See "Minimum Requirements for Passwords" for more information.

    The UTL_TCP, UTL_SMTP, UTL_MAIL, and DBMS_NETWORK_ACL_ADMIN PL/SQL packages are used by the e-mail security alert that you create.

  2. Connect as user SYSTEM.

    CONNECT SYSTEM
    Enter password: password
    
  3. Ensure that the HR schema account is unlocked and has a password. If necessary, unlock HR and grant this user a password.

    SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';
    

    If the DBA_USERS view lists user HR as locked and expired, then enter the following statement to unlock the HR account and create a new password:

    ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;
    

    Enter a password that is secure. For greater security, do not give the HR account the same password from previous releases of Oracle Database. "Minimum Requirements for Passwords" for the minimum requirements for creating passwords.

  4. Create a user account for Susan Mavris, who is an HR representative, and then grant this user access to the HR.EMPLOYEES table.

    GRANT CREATE SESSION TO smavris IDENTIFIED BY password;
    GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO SMAVRIS; 
    

Step 3: Configure an Access Control List File for Network Services

Before you can use PL/SQL network utility packages such as UTL_MAIL, you must configure an access control list (ACL) file that enables fine-grained access to external network services. For detailed information about this topic, see "Managing Fine-Grained Access in PL/SQL Packages and Types".

To configure an access control list for the e-mail alert:

  1. Connect to SQL*Plus as user sysadmin_fga.

    CONNECT sysadmin_fga
    Enter password: password
    
  2. Create the following access control list and its privilege definitions.

    BEGIN
     DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
      acl          => 'email_server_permissions.xml', 
      description  => 'Enables network permissions for the e-mail server',
      principal    => 'SYSADMIN_FGA',
      is_grant     => TRUE, 
      privilege    => 'connect');
    END;
    /
    

    Ensure that you enter your exact user name for the principal setting, in upper-case letters. For this tutorial, enter SYSADMIN_FGA for the name of the principal.

  3. Assign the access control list to the outgoing SMTP network host for your e-mail server.

    BEGIN
     DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
      acl         => 'email_server_permissions.xml',
      host        => 'SMTP_OUT_SERVER_setting', 
      lower_port  => port); 
    END;
    /
    

    In this example:

    • SMTP_OUT_SERVER_setting: Enter the SMTP_OUT_SERVER setting that you set for the SMTP_OUT_SERVER parameter in "Step 1: Install and Configure the UTL_MAIL PL/SQL Package". This setting should match exactly the setting that your e-mail tool specifies for its outgoing server.

    • port: Enter the port number that your e-mail tool specifies for its outgoing server. Typically, this setting is 25. Enter this value for the lower_port setting. (Currently, the UTL_MAIL package does not support SSL. If your e-mail server is an SSL server, then enter 25 for the port number, even if the e-mail server uses a different port number.)

Step 4: Create the E-Mail Security Alert PL/SQL Procedure

As user sysadmin_fga, create the following procedure. (You can copy and paste this text by positioning the cursor at the start of CREATE OR REPLACE in the first line.)

1
2
3
4
5
6
7
8
9
10
11
12
CREATE OR REPLACE PROCEDURE email_alert (sch varchar2, tab varchar2, pol varchar2)
AS
msg varchar2(20000) := 'HR.EMPLOYEES table violation. The time is: ';
BEGIN
  msg := msg||TO_CHAR(SYSDATE, 'Day DD MON, YYYY HH24:MI:SS'); 
UTL_MAIL.SEND (
    sender      => 'youremail@example.com',
    recipients  => 'recipientemail@example.com',
    subject     => 'Table modification on HR.EMPLOYEES',
    message     => msg); 
END email_alert;
/

In this example:

  • Lines 1 and 2: In the CREATE PROCEDURE statement, you must include a signature that describes the schema name (sch), table name (tab), and the name of the audit procedure (pol) that you will define in audit policy in the next step.

  • Lines 9 and 10: Replace youremail@example.com with your e-mail address, and recipientemail@example.com with the e-mail address of the person you want to receive the notification.

Step 6: Test the Alert

  1. Connect to SQL*Plus as user smavris, check your salary, and give yourself a nice raise.

    CONNECT smavris
    Enter password: password
    
    SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris';
    
    SALARY
    -----------
    6500
    
    UPDATE HR.EMPLOYEES SET SALARY = 13000 WHERE LAST_NAME = 'Mavris';
    
  2. Now select from a column other than SALARY in the HR.EMPLOYEES table.

    SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE LAST_NAME = 'Raphaely';
    

    The following output should appear:

    FIRST_NAME           LAST_NAME
    -------------------- --------------------
    Den                  Raphaely
    

    By now, depending on the speed of you e-mail server, you (or your recipient) should have received an e-mail with the subject header Table modification on HR.EMPLOYEES notifying you of the tampering of the HR.EMPLOYEES table.

  3. As user sysadmin_fga, query the DBA_FGA_AUDIT_TRAIL data dictionary view, which contains the Susan Mavris's audited activities.

    CONNECT sysadmin_fga
    Enter password: password
    
    col dbuid format a10
    col lsqltext format a66
    col ntimestamp# format a15
    
    SELECT DBUID, LSQLTEXT, NTIMESTAMP# FROM SYS.FGA_LOG$ WHERE POLICYNAME='CHK_HR_EMP';
    

    Output similar to the following appears:

    DBUID      LSQLTEXT
    ---------- ------------------------------------------------------------------
    NTIMESTAMP#
    --------------------------------------------------------------------------
    SMAVRIS    SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris'
    23-JUN-09 03.48.59.111000 PM
    
    SMAVRIS    UPDATE HR.EMPLOYEES SET SALARY = 13000 WHERE LAST_NAME = 'Mavris'
    23-JUN-09 03.49.07.330000 PM
    

    The audit trail captures the two SQL statements that Susan Mavris ran that affected the SALARY column in the HR.EMPLOYEES table. The third statement she ran, in which she asked about Den Raphaely, was not recorded because it was not affected by the audit policy. This is because Oracle Database executes the audit function as an autonomous transaction, committing only the actions of the handler_module setting and not any user transaction. The function has no effect on any user SQL transaction.

Tutorial: Auditing Nondatabase Users

This section contains:

Step 1: Create the User Account and Ensure the User HR Is Active

  1. Log on as user SYS with the SYSDBA privilege.

    sqlplus SYS AS SYSDBA
    Enter password: password
    
  2. Create the sysadmin_fga account, who will create the fine-grained audit policy.

    GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password;
    GRANT SELECT ON OE.ORDERS TO sysadmin_fga;
    GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga;
    GRANT SELECT ON SYS.FGA_LOG$ TO sysadmin_fga;
    

    Replace password with a password that is secure. See "Minimum Requirements for Passwords" for more information.

  3. The sample user OE will also be used in this tutorial, so query the DBA_USERS data dictionary view to ensure that OE is not locked or expired.

    SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';
    

    If the DBA_USERS view lists user OE as locked and expired, log in as user SYSTEM and then enter the following statement to unlock the OE account and create a new password:

    ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;
    

    Enter a password that is secure. For greater security, do not give the OE account the same password from previous releases of Oracle Database. "Minimum Requirements for Passwords" for the minimum requirements for creating passwords.

Step 3: Test the Policy

  1. Connect as user OE and select from the OE.ORDERS table.

    CONNECT OE
    Enter password: password
    
    SELECT COUNT(*) FROM ORDERS;
    

    The following output appears:

      COUNT(*)
    ----------
           105
    
  2. Connect as user sysadmin_fga and then check if any audit records were generated.

    CONNECT sysadmin_fga
    Enter password: password
    
    SELECT DBUID, LSQLTEXT FROM SYS.FGA_LOG$ WHERE POLICYNAME='ORDERS_FGA_POL';
    

    The following output appears:

    no rows selected
    

    Because no nondatabase users were logged in to query the OE.ORDERS table, the audit trail is empty.

  3. Reconnect as user OE, set the client identifier to Robert, and then reselect from the OE.ORDERS table.

    CONNECT OE
    Enter password: password
    
    EXEC DBMS_SESSION.SET_IDENTIFIER('Robert');
    
    SELECT COUNT(*) FROM ORDERS;
    

    The following output should appear:

      COUNT(*)
    ----------
           105
    
  4. Reconnect as user sysadmin_fga and then check the audit trail again.

    CONNECT sysadmin_fga
    Enter password: password
    
    SELECT DBUID, LSQLTEXT FROM SYS.FGA_LOG$ WHERE POLICYNAME='ORDERS_FGA_POL';
    

    This time, because Robert has made his appearance and queried the OE.ORDERS table, the audit trail captures his actions:

    DBUID            LSQLTEXT
    ---------------- ----------------------------
    OE               SELECT COUNT(*) FROM ORDERS;
    

Step 4: Remove the Components for This Tutorial

  1. Connect to SQL*Plus as user SYSTEM, and then drop user sysadmin_fga (including the objects in the sysadmin_fga schema).

    CONNECT SYSTEM
    Enter password: password
    
    DROP USER sysadmin_fga CASCADE;
    
  2. If you want, lock and expire OE, unless other users want to use this account:

    ALTER USER OE PASSWORD EXPIRE ACCOUNT LOCK;
    

Auditing SYS Administrative Users

This section contains:

Auditing User SYS and Users Who Connect as SYSDBA and SYSOPER

You can fully audit sessions for users who connect as SYS, including all users connecting using the SYSDBA or SYSOPER privileges. This enables you to write the actions of administrative users to an operating system file, even if the AUDIT_TRAIL parameter is set to NONE, DB, or DB, EXTENDED. Writing the actions of administrator users to an operating system audit file is safer than writing to the SYS.AUD$ table, because administrative users can remove rows from this table that indicate their bad behavior.

To configure audit settings for SYSDBA and SYSOPER users:

  1. Set the AUDIT_SYS_OPERATIONS initialization parameter to TRUE.

    ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE;
    

    This setting records the top-level operations directly issued by users who have connected to the database using the SYSDBA or SYSOPER privilege. It writes the audit records to the operation system audit trail. The SQL text of every statement is written to the ACTION field in the operating system audit trail record.

  2. If you want to write system administrator activities to XML files, then set the AUDIT_TRAIL initialization parameter to either XML or XML, EXTENDED.

    For example:

    ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;
    

    In all operating systems, if you set AUDIT_TRAIL to either XML or XML,EXTENDED, then audit records are written as XML files in the directory specified by the AUDIT_FILE_DEST initialization parameter. By default, Oracle Database writes the audit records to operating system files.

    See Table 9-2, "AUDIT_TRAIL Initialization Parameter Settings" for more information about these settings. See also "Enabling or Disabling the Standard Audit Trail".

  3. Restart the database.

After you restart the database, Oracle Database audits all successful actions performed by SYSDBA and SYSOPER users, and writes these audit records to the operating system audit trail, and not to the SYS.AUD$ table.

In Windows, if you have set the AUDIT_TRAIL initialization parameter OS, then Oracle Database writes audit records as events to the Event Viewer log file.

If you do not specify the AUDIT_FILE_DEST initialization parameter, then the default location is $ORACLE_BASE/admin/$ORACLE_SID/adump in Linux and Solaris, and %ORACLE_BASE%\admin\%ORACLE_SID%\adump for Microsoft Windows. For other operating systems, refer to their audit trail documentation.

Oracle Database audits all SYS-issued SQL statements indiscriminately and regardless of the setting of the AUDIT_TRAIL initialization parameter.

Consider the following SYS session:

CONNECT SYS/AS SYSDBA;
Enter password: password

ALTER SYSTEM FLUSH SHARED_POOL;
UPDATE salary SET base=1000 WHERE name='laurel';

When SYS auditing is enabled, both the ALTER SYSTEM and UPDATE statements are displayed in the operating system audit file, similar to the following output. (Be aware that this format may change in different Oracle Database releases.)

Tue May  5 04:53:37 2009 -07:00
LENGTH : '159'
ACTION :[7] 'CONNECT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[9] '561542328'
 
Tue May  5 04:53:40 2009 -07:00
LENGTH : '183'
ACTION :[30] 'ALTER SYSTEM FLUSH SHARED_POOL'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[9] '561542328'
 
Tue May  5 04:53:49 2009 -07:00
LENGTH : '200'
ACTION :[47] 'UPDATE salary SET base=1000 WHERE name='laurel''
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[7] 'laurelh'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[9] '561542328'

The brackets indicate the length of the value. For example, PRIVILEGE is set to SYSDBA, which uses 6 characters. In addition, the values are in single quotes for SYS and mandatory audit records.

Because of the superuser privileges available to users who connect as SYSDBA, Oracle recommends that database administrators rarely use this connection and only when necessary. Database administrators can usually perform normal day-to-day maintenance activity. These database administrators are typical database users with the DBA role, or have been granted privileges that are the equivalent of a DBA role (for example, mydba or jr_dba) that your organization customizes.

Using Triggers to Write Audit Data to a Separate Table

You can use triggers to supplement the built-in auditing features of Oracle Database. The trigger that you create records user actions to a separate database table. When an activity fires the trigger, the trigger records the action in this table. Triggers are useful when you want to record customized information such as before-and-after changes to a table. For detailed information about creating triggers, see Oracle Database PL/SQL Language Reference.

You do not need to have auditing enabled for the trigger to work, nor does it matter what type of auditing you do have enabled. The trigger works outside of the database audit functionality.

Follow these guidelines if you want to create audit triggers:

Table 9-6 provides a comparison of trigger-based auditing and the built-in database auditing features.

Table 9-6 Comparison of Built-in Auditing and Trigger-Based Auditing

Audit FeatureDescription

DML and DDL auditing

Standard auditing options permit auditing of DML and DDL statements regarding all types of schema objects and structures. Comparatively, triggers permit auditing of DML statements entered against tables, and DDL auditing at SCHEMA or DATABASE level.

Centralized audit trail

All database audit information is recorded centrally and automatically using the auditing features of the database.

Declarative method

Auditing features enabled using the standard database features are easier to declare and maintain, and less prone to errors, when compared to auditing functions defined by triggers.

Auditing options can be audited

Any changes to existing auditing options can also be audited to guard against malicious database activity.

Session and execution time auditing

Using the database auditing features, records are generated once every time an audited statement is entered. With triggers, an audit record is generated each time a trigger-audited table is referenced.

Auditing of unsuccessful data access

Database auditing can be set to audit when unsuccessful data access occurs. However, unless autonomous transactions are used, any audit information generated by a trigger is rolled back if the triggering statement is rolled back. For more information about autonomous transactions, see Oracle Database Concepts.

Sessions can be audited

Connections, disconnections, and session activity (physical I/Os, logical I/Os, deadlocks, and so on) can be recorded using standard database auditing.


In Example 9-26, a trigger audits modifications to the emp_tab table for specific rows. The trigger writes the old and new values to the emp_audit_tab table, including the user who performed the update and the time the update took place.

To test this trigger, add a row to the emp_tab table, and then change the value the ename, job, or sal column in the emp_tab table. Then query the emp_audit_tab table to find the audit data.

Managing Audit Trail Records

This section contains:

Managing the Database Audit Trail

This section contains:

Database Audit Trail Contents

The database audit trail is a pair of tables, AUD$ (for standard auditing) and FGA_LOG$ (for fine-grained auditing), in the SYS schema of each Oracle Database data dictionary. It records both standard and fine-grained audit activities. Several data dictionary views can help you use the information in this table. "Finding Information About Audited Activities" lists all the auditing-related views.

The database audit trail record contains different types of information, depending on the events audited and the auditing options set. For example, if you have set the AUDIT_TRAIL initialization parameter to DB, EXTENDED or XML, EXTENDED, then the SQL_BIND and SQL_TEXT columns show any SQL bind variables used for a SQL statement and SQL text that triggered the audit, respectively. For full details about the contents of these views, refer to Oracle Database Reference. However, be aware that the format and columns of the DBA_AUDIT_TRAIL view may change across Oracle Database releases.


Note:

If the AUDIT_TRAIL initialization parameter is set to XML or XML, EXTENDED, then Oracle Database sends standard audit records to operating system files in XML format. Because XML is a standard document format, many utilities are available to parse and analyze XML data.

If the database destination for audit records becomes full or unavailable, and, therefore, unable to accept new records, then an audited action cannot complete. Instead, Oracle Database generates an error message and does not audit the action. You can control the size of the audit trail to make it more manageable. (In fact, Oracle strongly recommends that you do so.) See "Controlling the Size of the Database Audit Trail" for more information. See also "Keeping Audited Information Manageable".

The audit trail does not store information about any data values that might be involved in the audited statement. For example, old and new data values of updated rows are not stored when an UPDATE statement is audited. However, you can perform this specialized type of auditing by using fine-grained auditing methods.

You can use the Flashback Query feature to show the old and new values of the updated rows, subject to any auditing policy presently in force. The current policies are enforced even if the flashback is to an old query that was originally subject to a different policy. Current business access rules always apply.


See Also:


Controlling the Size of the Database Audit Trail

If the database audit trail is full and no more audit records can be inserted, then underlying statement cannot complete successfully until you purge the audit trail. Oracle Database issues errors to all users who issue statements that cause the audit. Therefore, you must control the growth and size of the audit trail.

When auditing is enabled and audit records are being generated, the audit trail increases according to two factors:

  • The number of audit options turned on

  • The frequency of execution of audited statements

To control the growth of the audit trail, you can use the following methods:

  • Enable and disable database auditing. If it is enabled, then audit records are generated and stored in the audit trail. If it is disabled, then audit records are not generated. (Remember that some activities are always audited.)

  • Be selective about the audit options that are turned on. If more selective auditing is performed, then useless or unnecessary audit information is not generated and stored in the audit trail. You can use fine-grained auditing to selectively audit only certain conditions.

  • Tightly control the ability to perform object auditing. You can accomplish this in the following ways:

    • A security administrator owns all objects and never grants the AUDIT ANY system privilege to any other user. Alternatively, all schema objects can belong to a schema for which the corresponding user does not have CREATE SESSION privilege.

    • All objects are contained in schemas that do not correspond to real database users (that is, the CREATE SESSION privilege is not granted to the corresponding user). The security administrator is the only user granted the AUDIT ANY system privilege.

    In both scenarios, a security administrator controls entirely object auditing.

The maximum size of the database audit trail tables (AUD$ and FGA_LOG$) is determined by the default storage parameters of the SYSTEM tablespace, in which it is stored by default. If you are concerned that a too-large database audit trail will affect the SYSTEM table performance, then consider moving the database audit trail tables to a different tablespace.


See Also:

Operating system-specific Oracle Database documentation for more information about managing the operating system audit trail when directing audit records to that location

Moving the Database Audit Trail to a Different Tablespace

By default, the SYSTEM tablespace stores the database audit trail SYS.AUD$ and SYS.FGA_LOG$ tables. You can change this default location to another tablespace, such as the SYSAUX tablespace or a user-created tablespace. You may want to move the database audit trail tables to a different tablespace if the SYSTEM tablespace is too busy. Another reason for moving these audit trail tables to a different tablespace is if you plan to purge them by using the DBMS_AUDIT_MGMT PL/SQL package procedures.

Be aware that moving the database audit trail tables to a different tablespace can take a long time, depending on the amount of audit data in the audit tables, so you may want to do this during a time when database activity is slow.

To move the database audit trail from SYSTEM to a different tablespace:

  1. Log in to SQL*Plus as an administrator who has the EXECUTE privilege on the DBMS_AUDIT_MGMT PL/SQL package.

    For more information about the DBMS_AUDIT_MGMT PL/SQL package, see Oracle Database PL/SQL Packages and Types Reference.

  2. Check the tablespace to which you want to move the database audit trail tables.

    You may need to optimize and allocate more space to this tablespace, including the SYSAUX auxiliary tablespace. For more information, see Oracle Database Performance Tuning Guide.

  3. Run the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION PL/SQL procedure to specify the name of the destination tablespace.

    For example:

    BEGIN
     DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
      AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, 
      AUDIT_TRAIL_LOCATION_VALUE  => 'AUD_AUX');
    END;
    

    In this example:

    • AUDIT_TRAIL_TYPE: Refers to the database audit trail type. Enter one of the following values:

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Standard audit trail table, AUD$.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail table, FGA_LOG$.

      • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trail tables.

    • AUDIT_TRAIL_LOCATION_VALUE: Specifies the destination tablespace. This example specifies a tablespace named AUD_AUX.

Managing the Operating System Audit Trail

This section contains:

If the Operating System Audit Trail Becomes Full

Be aware that an operating system audit trail or file system, including the Windows Event Log, can become full, and therefore, unable to accept new records, including audit records from Oracle Database. In this case, Oracle Database cancels and rolls back the operation being performed, including operations that normally are always audited. (See "Activities That Are Always Audited for All Platforms".) If the operating system audit trail becomes full, then set the AUDIT_TRAIL parameter to use database audit trail (such as DB or DB, EXTENDED). This prevents the audited actions from completing if their audit records cannot be stored. You should periodically archive and purge the operating system audit file to prevent these types of failures.

If you plan to use operating system auditing, then ensure that the operating system audit trail or the file system does not fill completely. Most operating systems provide administrators with sufficient information and warning to ensure this does not occur. If you configure auditing to use the database audit trail, you can prevent this potential loss of audit information. Oracle Database prevents audited events from occurring if the audit trail is unable to accept the database audit record for the statement.

Periodically archive and then purge the operating system audit trail. See "Archiving the Operating System Audit Trail" and "Purging Audit Trail Records"for more information.

Setting the Size of the Operating System Audit Trail

To control the size of the operating system audit trail, set the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property by using the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQL procedure. Remember that you must have the EXECUTE privilege for the DBMS_AUDIT_MGMT PL/SQL package before you can use it. When the operating system file meets the size limitation you set, Oracle Database stops adding records to the current file and then creates a new operating system file for the subsequent records. For more information about the DBMS_AUDIT_MGMT PL/SQL package, see Oracle Database PL/SQL Packages and Types Reference.

If you set both the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE and the DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE (described in "Setting the Age of the Operating System Audit Trail") properties, then Oracle Database performs the action based the property value limit that is met first.

For example:

BEGIN
  DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE            =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
   AUDIT_TRAIL_PROPERTY        =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
   AUDIT_TRAIL_PROPERTY_VALUE  =>  102400);
END;
/

In this example:

  • AUDIT_TRAIL_TYPE: Specifies the operating system audit trail. Enter one of the following values:

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Operating system audit trail files with the .aud extension. (This setting does not apply to Windows Event Log entries. Nor does it apply to syslog audit records, when the AUDIT_SYSLOG_LEVEL initialization parameter is set.)

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML audit trail files.

    • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Both operating system and XML audit trail files.

  • AUDIT_TRAIL_PROPERTY: Specifies the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property, which sets the maximum size. To find the status of the current property settings, query the PARAMETER_NAME and PARAMETER_VALUE columns of the DBA_AUDIT_MGMT_CONFIG_PARAMS data dictionary view.

  • AUDIT_TRAIL_PROPERTY_VALUE: Sets the maximum size to 102400 kilobytes, that is, 10 megabytes. The default setting is 10,000 kilobytes (approximately 10 megabytes). Do not exceed 2 gigabytes.

Clearing the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE Setting

To clear the maximum file size setting, use the DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY procedure.

For example:

BEGIN
  DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
   AUDIT_TRAIL_TYPE        =>  DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
   AUDIT_TRAIL_PROPERTY    =>  DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
   USE_DEFAULT_VALUES      =>  TRUE );
END;
/

In this example: