Database Administration

Unit 4: Profiles, Resources, and Auditing (4 Hrs.)

Profiles And Resources:

• Overview of User Profiles,
• Profile Resource Parameters,
• Create Profile Command,
• Manage Passwords with Profiles,
• Control Resource Usage with Profiles,
• Maintain Profiles
In Oracle Database, User profiles are mechanisms or tools used to control various aspects of user
behavior and access privileges within the database.

These profiles allow database administrators to enforce security policies, manage resource usage,
and customize user sessions. Some common features and settings controlled by user profiles
include:

•Password policies: Enforcing password complexity rules, expiration periods, and locking
mechanisms to enhance security.

•Resource limits: Setting constraints on CPU usage, memory consumption, and other system
resources to prevent abuse or excessive usage by users.

Database administrators can ensure that users adhere to security policies, optimize resource
utilization, and maintain the integrity and availability of the database system by defining and
assigning appropriate user profiles .
In Oracle Database, Non-CDB profiles doesn't begin with C## where as in CDB profiles
name requires following naming convention.

•The name of a common profile must begin with characters that are a case-insensitive
match to the prefix specified by the COMMON_USER_PREFIX initialization parameter. By
default, the prefix is C##.

•The name of a local profile must not begin with characters that are a case-insensitive
match to the prefix specified by the COMMON_USER_PREFIX initialization parameter.
Regardless of the value of COMMON_USER_PREFIX, the name of a local profile can never begin with
C## or c##.
Resource parameters are assign to profile to limit access on database resources by users which are assigned with that
profile.

Types of Resource Parameters:

1. CPU_PER_SESSION : CPU Time limit for a session which is specified in hundredth of second.
2. CPU_PER_CALL : CPU time limit for call like execute, fetch or parse query.
3. CONNECT_TIME : Time specified in minutes for elapsed time for a session.
4. IDLE_TIME : Time a user can stay in database without any activity.
5. SESSIONS_PER_USER : Determines how many concurrent connection can be open;
6. LOGICAL_READS_PER_SESSION : Specify the permitted number of data blocks read in a session,
including blocks read from memory and disk.
7. PRIVATE_SGA : The amount of private space a session can allocate in the shared pool
of the system global area (SGA)
This limit applies only if you are using shared server architecture. The private space for a session in the SGA
includes private SQL and PL/SQL areas, but not shared SQL and PL/SQL areas.
8. LOGICAL_READS_PER_CALL : Specify the permitted number of data blocks read for a call to process a
SQL statement (a parse, execute, or fetch).

9. COMPOSIT LIMIT : Specify the total resource cost for a session, expressed in service units.
Oracle Database calculates the total service units as a weighted sum of
CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.
All the password parameters except FAILED_LOGIN_ATTEMPTS and PASSWORD_REUSE_MAX—are interpreted in number of
days. The maximum value is 24855 days. For FAILED_LOGIN_ATTEMPTS and PASSWORD_REUSE_MAX, you must specify an
integer.
Password parameters are assign to profile to limit access on database by users which are assigned with that profile based on
password parameters clauses as below

Types of Password Parameters:

1. PASSWORD_LOCK_TIME : Number of days a password will be locked Default value is a day.
2. PASSWORD_GRACE_TIME : Days after grace period started. Warning is given with a login. Default
value is 7 days
3. INACTIVE_ACCOUNT_TIME : Time specified in days for inactivity of account before being locked.
Default value is 15 days.
4. PASSWORD_LIFE_TIME : Days a password can be used for authentication. Default value is 180 days
, if PASSWORD_GRACE_TIME not specified.
5. PASSWORD_VERIFY_FUNCTION : A PL/SQL password complexity verification script as an argument
to CREATE PROFILE by specifying PASSWORD_VERIFY_FUNCTION.
6. PASSWORD_REUSE_MAX : Number of other passwords that must be used before one can be reused.
7. PASSWORD_ REUSE _TIME : Number of days during which a password cannot be reused.
8. FAILED_LOGIN_ATTEMPTS : The number of consecutive failed attempts to log in to the user account
before the account is locked. Default value is 10 times.
In Oracle database, User profiles can be associated with
password parameters or resource parameters or both.

Resource parameters are assign to profile to limit access on

database resources by users which are assigned with that profile.

Example
SQL> create profile bmcpdb_profile limit
SESSIONS_PER_USER UNLIMITED
PASSWORD_REUSE_MAX 10
CPU_PER_SESSION UNLIMITED
PASSWORD_REUSE_TIME 40
PRIVATE_SGA 15K
PASSWORD_LOCK_TIME 1/24
FAILED_LOGIN_ATTEMPTS 5;

SQL> ALTER USER sushant PROFILE bmcpdb_profile;

Unit 4: Auditing (4 Hrs.)

Database Auditing:
• Overview of Database Security,
• Overview of Database Auditing,
• Security Compliance,
• Standard Auditing,
• Unified Audit Trail,
• Separation of Audit Responsibilities with The AUDIT_ADMIN And
AUDIT_VIEWER Roles,
• Configure the Audit Trail,
• Specify Audit Options.
 What is
database Security? Why?
Database security refers to controls and measures along with the range of tools, designed to establish and preserve
database confidentiality, integrity and availability. Confidentiality is the element that's compromised in most data breaches.
Database security, in general involves user authentication, access control, monitoring and encryptions. Some of the aspect
taken into consideration while ensuring database security as follows

 Database Authentication ( Authentication by database, Authentication by OS)

 Database Access Methods like (Oracle data vault, Virtual Private Database (VPD), Oracle Label Security (OLS))

 Encryptions (Network Encryption, Transparent Data Encryption eg individual tablespace or table columns (AES)

algorithms with built-in key management is used. )

 Data access monitoring. ( Database Auditing by configuring unified audit policy or fine-grained auditing or Oracle

database real application security)

 Oracle Data Redaction ( Full/Partial/Random data redaction. We use DBMS_REDACT Package)

 User Accounts (Privileges, Roles, User Profiles)

Security Compliance is maintained in Oracle database.

 The ora_stig_profile user profile is designed for Security Technical Implementation Guide
compliance.
 The ora_stig_profile user profile addresses STIG requirements such as the need for a password
complexity function, maximum failed login attempts, reuse time, and other requirements. The definition
for this profile is as follows:
CREATE PROFILE ora_stig_profile
password_life_time 60
password_grace_time 5
password_reuse_time 365
password_reuse_max 10
failed_login_attempts 3
password_lock_time unlimited
inactive_account_time 35
idle_time 15
password_verify_function ora12c_stig_verify_function;
What is Auditing?
An audit , in oracle database, is a process of investigation or review of various aspects of database activity, along with
monitoring of an accounts by system to ensure security, consistency, reliability and integrity of data in database. It is
done to ascertain activities within database by both database users and application user (Non-database) users.
Users who are recognized in the database using the CLIENT_IDENTIFIER attribute are non-database users.

Image: https://www.oreilly.com/library/view/oracle-plsql-for/0596005873/ch05s06s04.html
Why is Auditing?
Database auditing is generally used to:
 Provide proof of monitoring internal controls to auditors

 Provide reports on changes to the database environment to auditors

 Act as a deterrent to unauthorized activity

 Assist with investigations of data breaches or other suspicious activity

 Detect when an attempt is made to bypass a security control

Auditing can be used to accomplish one important aspect that is database confidentiality, integrity and
availability along with security.

 Enable accountability for actions

 Actions taken in a particular schema, table, or row, or affecting specific content.

 Investigate suspicious activity

 If a user is deleting data from tables, then a security administrator can audit all connections to the
database and all successful and unsuccessful deletions of rows from all tables in the database

 Notify an auditor of an unauthorized activity.

 If a user is deleting data from tables, then a security administrator can audit all connections to the
database and all successful and unsuccessful deletions of rows from all tables in the database.
 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.

 Discover glitches 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.

 Compliance issues.
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
 Standard Auditing
• Standard auditing provides the ability to audit based on user, privileges, schemas objects, and statements. For
example, it can be based on a specific type of SQL statement (create, alter, update, delete,…).

• You can track the issuance of a specific SQL statement in user sessions or of all SQL statements authorized by a
particular system privilege. Auditing operations on SQL statements apply only to subsequent sessions, not to
current sessions.

• Track operations on a specific schema object. Auditing operations on schema objects apply to current sessions as
well as to subsequent sessions.

• To audit issuances of a SQL statement, you must have the AUDIT SYSTEM system privilege. However, the AUDIT
SYSTEM system privilege is not required when you use the IN SESSION CURRENT clause

• By setting the initialization parameter AUDIT_TRAIL to a value, we can collect auditing results. Oracle Database
does not generate audit records until you enable auditing.

• To audit operations on a schema object, the object you choose for auditing must be in your own schema or you
must have AUDIT ANY system privilege. In addition, if the object you choose for auditing is a directory object,
even if you created it, then you must have AUDIT ANY system privilege.
 Standard Auditing
• When you are connected to a multitenant container database (CDB), you must have
the privileges, either granted locally in the current container or granted commonly.

• To specify the CONTAINER clause, you must be connected to a multitenant container

database (CDB). To specify CONTAINER = CURRENT, the current container must be a
pluggable database (PDB). To specify CONTAINER = ALL, the current container must be
the root.
 Standard Auditing
AUDIT statement in a CDB, the database performs auditing as
follows:

• If you issue the AUDIT statement when the current container is

a PDB, then the database performs auditing in that PDB. If you
specify the auditing_by_clause, then user must be a local user
in the PDB or a common user. If you specify the
audit_schema_object_clause, then the object must be a local
object in the PDB.

• If you issue the AUDIT statement when the current container is

the root, then the database performs auditing across the entire
CDB, that is, in the root and all PDBs. If you specify the
auditing_by_clause, then user must be a common user. If you
omit the auditing_by_clause, then all common users are
audited. If you specify the audit_schema_object_clause, then
the object must be a local object in the root or a common
object.
 Unified Audit Trail
• The Unified Audit Trail is a feature introduced in Oracle Database consolidates audit records from various sources into a
single, unified view. It provides a centralized location for auditing activities across the database, making it easier to
manage and analyze audit data.
• Unified auditing enables you to capture audit records from the following sources:
• Audit records (including SYS audit records) from unified audit policies and AUDIT settings
• Fine-grained audit records from the DBMS_FGA PL/SQL package
• Oracle Database Real Application Security audit records
• Oracle Recovery Manager audit records
• Oracle Database Vault audit records
• Oracle Label Security audit records
• Oracle Data Mining records
• Oracle Data Pump
• Oracle SQL*Loader Direct Load
The unified audit trail, which resides in a read-only table in the AUDSYS schema in the SYSAUX tablespace, makes this
information available in a uniform format in the UNIFIED_AUDIT_TRAIL data dictionary view, and is available in both
single-instance and Oracle Database Real Application Clusters environments. In addition to the user SYS, users who have
been granted the AUDIT_ADMIN and AUDIT_VIEWER roles can query these views. If your users only need to query the
views but not create audit policies, then grant them the AUDIT_VIEWER role.

When the database is writeable, audit records are written to the unified audit trail. If the database is not writable, then
audit records are written to new format operating system files in the $ORACLE_BASE/audit/$ORACLE_SID
directory.
Unified Audit Trail
The Unified Audit Trail Key concepts

1. Centralized Audit Repository: The Unified Audit Trail stores audit records from different sources, including
database-level, operating system-level, and Oracle Database Vault audit data, in a single repository.
2. Consistent Format: Audit records in the Unified Audit Trail are stored in a consistent format, making it
easier to query and analyze the data. The audit records contain information such as the user performing the
action, the SQL statement executed, the timestamp of the action, and other relevant details.
3. Enhanced Security: The Unified Audit Trail provides enhanced security features, such as the ability to
encrypt audit records and protect them from unauthorized access.
4. Fine-Grained Auditing: With the Unified Audit Trail, you can enable fine-grained auditing for specific
database objects, operations, or users. This allows you to capture detailed audit information tailored to
your specific auditing requirements.
Unified Audit Trail
The Unified Audit Trail Key concepts

5. Performance: The Unified Audit Trail is designed for improved performance compared to traditional audit
trails. It uses optimized storage structures and indexing mechanisms to efficiently handle large volumes of
audit data.
6. Integration with Enterprise Manager: Oracle Enterprise Manager provides a graphical interface for
managing and monitoring the Unified Audit Trail. You can use Enterprise Manager to configure audit
settings, view audit reports, and perform other audit-related tasks.
7. Compliance and Reporting: The Unified Audit Trail helps organizations meet regulatory compliance
requirements by providing comprehensive audit data for reporting and analysis purposes. It simplifies the
process of auditing database activities and demonstrating compliance to auditors.
 Audit Roles
(AUDIT_ADMIN and AUDIT_VIEWER)
Separation of audit responsibilities
1.AUDIT_ADMIN Role:
1. Users assigned the AUDIT_ADMIN role have the privilege to configure and manage audit settings
within the database.
2. Responsibilities of users with AUDIT_ADMIN role may include:
1. Enabling and disabling auditing for specific actions or objects.
2. Managing audit policies and settings.
3. Viewing and managing audit trails and audit data.
3. Users with AUDIT_ADMIN role have full control over auditing functionalities and can make changes to
audit configurations as needed.
 Audit Roles
(AUDIT_ADMIN and AUDIT_VIEWER)
Separation of audit responsibilities
2. AUDIT_VIEWER Role:
1. Users assigned the AUDIT_VIEWER role have read-only access to audit information within the database.
2. Responsibilities of users with AUDIT_VIEWER role may include:
1. Viewing audit logs and audit trails.
2. Monitoring audit data for compliance and security purposes.
3. Users with AUDIT_VIEWER role can review audit information but cannot make changes to audit settings or
policies.
By separating responsibilities between AUDIT_ADMIN and AUDIT_VIEWER roles, organizations can enforce a principle of
least privilege, ensuring that users only have access to the audit functionalities they need to perform their job duties. This
separation enhances security and helps in compliance with regulatory requirements.
SQL>GRANT AUDIT_ADMIN TO username; SQL>GRANT AUDIT_VIEWER TO username;
 Audit Roles
(AUDIT_ADMIN and AUDIT_VIEWER)
Separation of audit responsibilities
Feature AUDIT_ADMIN AUDIT_VIEWER
Can configure and manage audit
Configuration Cannot configure audit settings
settings

Can define audit policies and Cannot define or modify audit

Audit Policies
enable/disable auditing policies

Can view and manage audit trails Can only view audit trails and audit
Audit Trails
and audit data data

Can enable/disable auditing, define

Actions Can only view audit data and trails
policies, and manage trails

Can make changes to audit settings Cannot make changes to audit

Changes
and policies settings or policies

Responsible for managing audit Responsible for monitoring audit

Responsibilities
configurations data and compliance
 Unified Audit Trail
Is Unified Audit Trail enable?

To check Logon into database server and connect to PDB or CDB Root.

Conn sys as sysdba;

Enter password:
Conn shushat@pdb1 as SYSDBA;
Enter password:

SQL > SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
Configuring Auditing
• Enable auditing is done by setting audit_trail parameter value. E.g
SQL> alter system set audit_trail=db scope=spfile; OR
SQL> alter system set audit_trail='db_extended' scope=spfile; OR
SQL> alter system set audit_trail=‘db’,’extended' scope=spfile;

SQL>shutdown or shutdown immediate;

SQL>startup

• The audit_trail is either database table (data directory) or Operating system files. If parameter is set
to DB or DB_EXTENDED then the audit trail is maintained in the AUD$ system table where as If you
set the parameter to OS, XML, or XML_EXTENDED, then the audit trail is maintained by the operating
system.

• Enable auditing on objects like table, index

SQL> audit all on <schema>.<table> bmc.student by access; OR
SQL> audit all on <schema>.<table> bmc.student by session; OR
SQL> Select max(marks) from bmc.student;
SQL> update student set mark=200 where marks= 190;
SQL> select timestamp,username,action_name, ses_actions from dba_audit_trail;
What to audit Examples

• Enable auditing is done by setting audit_trail parameter value. E.g

SQL> audit create table by user; Audit succeeded.
SQL> audit create table;
Audit succeeded.
To audit all statements:
SQL> audit all;
Audit succeeded. To audit a set of statements:
SQL> audit create table, create procedure; Audit succeeded.
Or, use statement groups as a shorthand – for example, rather than specify:
SQL> audit alter user; Audit succeeded.
SQL> audit drop user; Audit succeeded.
SQL> audit create user; Audit succeeded.
Audit Configurations and Options
When specifying audit options in Oracle Database, you can configure various parameters to define what
actions are audited and under what circumstances. Here are some common audit options and how to specify
them:

1. **Actions to Audit**:
- Specify the actions you want to audit, such as SELECT, INSERT, UPDATE, DELETE, EXECUTE, or schema-level
operations.
AUDIT SELECT TABLE, INSERT TABLE, UPDATE TABLE, DELETE TABLE BY <user>;

2. **Auditing Conditions**:
- Specify when to audit, such as whether the action was successful, unsuccessful, or both.
AUDIT SELECT TABLE BY <user> WHENEVER SUCCESSFUL;

3. **Audit Object Privileges**:

- Audit when object privileges are granted or revoked.
AUDIT GRANT, REVOKE ON <object> BY <user>;

4. **Audit System Privileges**:

- Audit when system privileges are granted or revoked.
AUDIT GRANT, REVOKE ANY PRIVILEGE BY <user>;
5. Audit Database Links:
Audit Configurations and Options
- Audit database link usage.
AUDIT DATABASE LINK BY <user>;

6. Audit Session Events:

- Audit session-related events, such as logon, logoff, and failed logon attempts.
- AUDIT SESSION, LOGOFF BY <user>; These are just some examples of audit
options that you can specify in Oracle
7. Fine-Grained Auditing (FGA) Database. Adjust the audit settings based
- Specify conditions for auditing based on specific column values or other on your security and compliance
criteria. requirements. Use the `AUDIT` statement
-DBMS_FGA.ADD_POLICY('HR', 'EMPLOYEES', 'salary > 10000', 'SELECT'); to enable auditing for specific actions,
objects, or privileges, and the `NOAUDIT`
8. Audit DDL : statement to disable auditing when it is no
- Audit data definition language (DDL) statements, such as CREATE, ALTER, and longer needed.
DROP operations.
AUDIT CREATE TABLE, ALTER TABLE, DROP TABLE BY <user>;

9. Audit by Object:
- Specify auditing for specific database objects.
AUDIT SELECT, INSERT, UPDATE, DELETE ON <object> BY <user>;