Unit 5 Database Security and Auditing

Elective-Database Administration – CSIT 7th Semester
Unit-5: Database Security and Auditing
Terminologies about Auditing:

Audit/auditing: process of examining and validating documents, data, processes,
procedures, systems
Audit log: document that contains all activities that are being audited ordered in a
chronological manner
Audit objectives: set of business rules, system controls, government regulations,

or security policies
Auditor: a person authorized to audit
Audit procedure: set of instructions for the auditing process
Audit report: a document that contains the audit findings
Audit trail: chronological record of document changes, data changes, system

activities, or operational events
Data audit: chronological record of data changes stored in log files or database
table object
Database auditing: chronological record of database activities
Internal auditing: examination of activities conducted by staff members of the

audited organization
External auditing: examination of activities conducted by freelancer or third party

auditor
Database, User, and Schema:

In Oracle, users and schemas are essentially the same thing. You can consider that
a user is the account you use to connect to a database, and a schema is the set of
objects (tables, views, etc.) that belong to that account.
You create users with the create user statement. This also "creates" the schema
(initially empty) - you cannot create a schema as such, it is tied to the user. Once
By Lec. Pratik Chand, Page 1

the user is created, an administrator can grant privileges to the user, which will
enable it to create tables, execute select queries, insert, and everything else.
For Example:
SCOTT is a schema that includes the EMP, DEPT and BONUS tables with
various grants, and other stuff.
SYS is a schema that includes tons of tables, views, grants, etc.
SYSTEM is a schema.....
Technically - A schema is the set of metadata (data dictionary) used by the

database, typically generated using DDL. A schema defines attributes of the
database, such as tables, columns, and properties. A database schema is a
description of the data in a database.
The database is the thing that contains all the users you've created, and their data
(and a bunch of predefined system users, tables, views, etc. that make the whole
thing work).
You can create a database with the create database statement, once you've
installed the Oracle software stack. But using dbca (database creation assistant) is
easier to get started.
Introduction to Auditing:
Auditing is the monitoring and recording of selected user database actions. It can
be based on individual actions, such as the type of SQL statement executed, or on
combinations of factors that can include user name, application, time, and so on.
Security policies can trigger auditing when specified elements in an Oracle
database are accessed or altered, including the contents within a specified object.
Auditing is always about accountability, and is frequently done to protect and

preserve privacy for the information stored in databases. Concern about privacy
policies and practices has been rising steadily with the ubiquitous use of databases
in businesses and on the Internet. Oracle Database provides a depth of auditing that
readily enables system administrators to implement enhanced protections, early
detection of suspicious activities, and finely-tuned security responses.

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 (discourage) users from inappropriate actions based on that
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 actions by an unauthorized user: For example, an
unauthorized user could change or delete data, or a user has more privileges
than expected, which can lead to reassessing user authorizations.
 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 do generate audit records, then you will
know the other security controls are not properly implemented.
 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/O operations are performed, or how many
concurrent users connect at peak times.
 Address auditing requirements for compliance: Regulations such as the
following have common auditing-related requirements:
o Health Insurance Portability and Accountability Act (HIPAA)
o International Convergence of Capital Measurement and Capital
Standards: a Revised Framework (Basel II)
o Japan Privacy Law
o European Union Directive on Privacy and Electronic Communications
Where Are Standard Audit Activities Recorded?

Oracle Database records audit activities in audit records. Audit records provide
information about the operation that was audited, the user performing the
operation, and the date and time of the operation. Audit records can be stored in
either a data dictionary table, called the database audit trail, or in operating system
files, called an operating system audit trail. Oracle Database also provides a set of
data dictionary views that you can use to track suspicious activities.
When you use standard auditing, Oracle Database writes the audit records to either
to DBA_AUDIT_TRAIL (the SYS.AUD$ table), the operating system audit trail, or to
the DBA_COMMON_AUDIT_TRAIL view, which combines standard and fine-grained audit
log records. In addition, the actions performed by administrators are recorded in
the syslog audit trail when the AUDIT_SYSLOG_LEVEL initialization parameter is set.
Types of audit:
Statement Auditing:
Enables you to audit SQL statements by type of statement, not by the specific
schema objects on which they operate. Typically broad, statement auditing audits
the use of several types of related actions for each option.
For example, AUDIT TABLE tracks several DDL (Data Definition Language)
statements regardless of the table on which they are issued. You can also set
statement auditing to audit selected users or every user in the database.
Privilege Auditing:
Enables you to audit the use of powerful system privileges that enable
corresponding actions, such as AUDIT CREATE TABLE. Privilege auditing is more
focused than statement auditing, which audits only a particular type of action. You
can set privilege auditing to audit a selected user or every user in the database.
Schema Object Auditing:

Enables you to audit specific statements on a particular schema object, such
as AUDIT SELECT ON employees. Schema object auditing is very focused, auditing only
a single specified type of statement (such as SELECT) on a specified schema
object. Schema object auditing always applies to all users of the database.
Fine-Grained Auditing (FGA):

Oracle Fine Grained Auditing (FGA) enables you to create policies that define
specific conditions that must be met in order for an audit to occur. It provides
granular auditing of queries, and INSERT, UPDATE, and DELETE operations.
Using FGA creates more meaningful and focused audit trails. Rather than
recording each and every access or update of a table, FGA allows you to set
parameters for audits to make them more efficient. For example, you might decide
to audit only under these circumstances:
o Tables accessed between 6 p.m. and 6 a.m. or only on Saturday and

Sunday.
o An IP address from outside the corporate network is used.
o A specific column has been selected or updated, perhaps with a specific
value
o Audit the data whose value>10,000
Importance of Data Security:

It is important to develop a security policy for every database. The security policy
establishes methods for protecting your database from accidental or malicious
destruction of data or damage to the database infrastructure.
Each database can have an administrator, referred to as the security administrator,

who is responsible for implementing and maintaining the database security policy
If the database system is small, the database administrator can have the
responsibilities of the security administrator. However, if the database system is
large, a designated person or group of people may have sole responsibility as
security administrator.
User Privilege and Roles:

Privileges and roles are used to control user access to data and the types of SQL
statements that can be executed.
Let‟s discuss the three types of privileges and roles:
System privilege:
A system-defined privilege usually granted only by administrators. These
privileges allow users to perform specific database operations.
Object privilege: A system-defined privilege that controls access to a specific

object.

Role: A collection of privileges and other roles. Some system-defined roles exist,
but most are created by administrators. Roles group together privileges and other
roles, which facilitates the granting of multiple privileges and roles to users.
Privileges and roles can be granted to other users by users who have been granted
the privilege to do so. The granting of roles and privileges starts at the
administrator level. At database creation, the administrative user SYS is created
and granted all system privileges and predefined Oracle Database roles. User SYS
can then grant privileges and roles to other users, and also grant those users the
right to grant specific privileges to others.
Authentication Methods:
Authentication means process of verifying the identity of someone (a user, device,
or an entity) who wants to access data, resources, or applications. Validating that
identity establishes a trust relationship for further interactions. Authentication also
enables accountability by making it possible to link access and actions to specific
identities. After authentication, authorization processes can allow or limit the
levels of access and action permitted to that entity.
Oracle allows a single database instance to use any or all methods. Oracle requires
special authentication procedures for database administrators, because they
perform special database operations. Oracle also encrypts passwords during
transmission to ensure the security of network authentication.
To validate the identity of database users and prevent unauthorized use of a

database user name, you can authenticate users by using any combination of the
methods described below:
 Authentication by the Operating System

 Authentication by the Network
 Authentication by Oracle Database
 Authentication of Database Administrators
 Multi-tier Authentication and Authorization

Authentication by the Operating System:
Some operating systems permit Oracle to use information they maintain to

authenticate users. This has the following benefits:
 Once authenticated by the operating system, users can connect to Oracle

more conveniently, without specifying a user name or password.
For example, an operating-system-authenticated user can invoke SQL*Plus
and skip the user name and password prompts by entering the following:
SQLPLUS /
 With control over user authentication centralized in the operating system,

Oracle need not store or manage user passwords, though it still maintains
user names in the database.
 Audit trails in the database and operating system can use the same user
names.
When an operating system is used to authenticate database users, managing

distributed database environments and database links requires special care.
Authentication by the Network
Authentication over a network is handled by the SSL protocol or by third-party

services as described below:
 Authentication Using SSL

 Authentication Using Third-Party Services
o Kerberos Authentication
o PKI-Based Authentication
o Authentication with RADIUS
o Directory-Based Services
Authentication Using SSL:

The Secure Socket Layer (SSL) protocol is an application layer protocol. It can be
used for user authentication to a database, and it is independent of global user
management in Oracle Internet Directory. That is, users can use SSL to
authenticate to the database even without a directory server in place.
Authentication Using Third-Party Services:

Authentication over a network makes use of third-party network authentication
services. Prominent examples include Kerberos, Public Key Infrastructure (PKI),
the Remote Authentication Dial-In User Service (RADIUS), and directory-based
services.
Kerberos Authentication: Kerberos is a trusted third-party authentication system

that relies on shared secrets. It presumes that the third party is secure, and provides
single sign-on capabilities, centralized password storage, database link
authentication, and enhanced PC security. It does this through a Kerberos
authentication server, or through Cybersafe Active Trust, a commercial Kerberos-
based authentication server.
PKI-Based Authentication: Authentication systems based on PKI issue digital

certificates to user clients, which use them to authenticate directly to servers in the
enterprise without directly involving an authentication server. Oracle provides a
PKI for using public keys and certificates, consisting of the following components:
 Authentication and secure session key management using SSL.

 Oracle Call Interface (OCI) and PL/SQL functions
These are used to sign user-specified data using a private key and certificate. The
verification of the signature on data is done by using a trusted certificate.
 Trusted certificates: These are used to identify third-party entities that are
trusted as signers of user certificates when an identity is being validated.
When the user certificate is being validated, the signer is checked by using
trust points or a trusted certificate chain of certificate authorities stored in
the validating system. If there are several levels of trusted certificates in this
chain, then a trusted certificate at a lower level is simply trusted without
needing to have all its higher-level certificates reverified.
 Oracle wallets: These are data structures that contain the private key of a
user, a user certificate, and the set of trust points of a user (trusted certificate
authorities).
 OracleAS Certificate Authority: This is a component of the Oracle
Identity Management infrastructure, which provides an integrated solution

for provisioning X.509 version 3 certificates for individuals, applications,

and servers that require certificates for PKI-based operations such as
authentication, SSL, S/MIME, and so on.
 Oracle Wallet Manager: This is a standalone Java application used to
manage and edit the security credentials in Oracle wallets. It performs the
following operations:
o Protects user keys
o Manages X.509 version 3 certificates on Oracle clients and servers
o Generates a public-private key pair and creates a certificate request for
submission to a certificate authority
o Installs a certificate for the entity
o Configures trusted certificates for the entity
o Creates wallets
o Opens a wallet to enable access to PKI-based services
Authentication with RADIUS: Oracle supports remote authentication of users

through the Remote Authentication Dial-In User Service (RADIUS), a standard
lightweight protocol used for user authentication, authorization, and accounting.
Directory-Based Services: Using a central directory can make authentication and

its administration extremely efficient. Directory-based services include the
following:
 Oracle Internet Directory, which uses the Lightweight Directory Access

Protocol (LDAP), enables information about users (called enterprise users)
to be stored and managed centrally. Although database users must be created
(with passwords) in each database that they need to access, enterprise user
information is accessible centrally in the Oracle Internet Directory. You can
also integrate this directory with Active Directory and iPlanet.
 Oracle Enterprise Security Manager, which provides centralized privilege
management to make administration easier and increase security levels.
Oracle Enterprise Security Manager lets you store and retrieve roles from
Oracle Internet Directory.

Authentication by Oracle Database:

Oracle Database can authenticate users attempting to connect to a database, by
using information stored in that database itself. To set up Oracle Database to use
database authentication, you must create each user with an associated password.
The user must provide this user name and password when attempting to establish a
connection. This process prevents unauthorized use of the database, because the
connection will be denied if the user provides an incorrect password. Oracle
Database stores user passwords in the data dictionary in an encrypted format to
prevent unauthorized alteration. Users can change their passwords at any time.
Database authentication includes the following features:
 Password Encryption While Connecting. This protection is always in force,

by default.
 Account Locking
 Password Lifetime and Expiration
 Password History
 Password Complexity Verification
Password Encryption While Connecting: Passwords are always automatically

and transparently encrypted during network (client/server and server/server)
connections, using AES (Advanced Encryption Standard) before sending them
across the network.
Account Locking: Oracle can lock a user's account after a specified number of
consecutive failed login attempts. You can configure the account to unlock
automatically after a specified time interval or to require database administrator
intervention to be unlocked.
Use the CREATE PROFILE statement to establish how many failed login attempts a
user can attempt before the account locks, and how long it remains locked before it
unlocks automatically.
The database administrator can also lock accounts manually, so that they cannot
unlock automatically but must be unlocked explicitly by the database
administrator.

Password Lifetime and Expiration: The database administrator can specify

a lifetime for passwords, after which they expire and must be changed before
account login is again permitted. A grace period can be established, during which
each attempt to login to the database account receives a warning message to
change the password. If it is not changed by the end of that period, then the
account is locked. No further logins to that account are allowed without assistance
by the database administrator.
The database administrator can also set the password state to expired, causing the
user account status to change to expired. The user or the database administrator
must then change the password before the user can log in to the database.
Password History: The password history option checks each newly specified
password to ensure that a password is not reused for a specified amount of time or
for a specified number of password changes. The database administrator can
configure the rules for password reuse with CREATE PROFILE statements.
Password Complexity Verification: Complexity verification checks that each

password is complex enough to provide reasonable protection against intruders
who try to break into the system by guessing passwords.
The sample Oracle password complexity verification routine (the PL/SQL

script UTLPWDMG.SQL, which sets the default profile parameters) checks that each
password meet the following requirements:
 Be a minimum of four characters in length

 Not equal the userid
 Include at least one alphabet character, one numeric character, and one
punctuation mark
 Not match any word on an internal list of simple words like welcome,
account, database, user, and so on
 Differ from the previous password by at least three characters

Authentication of Database Administrators:

Database administrators perform special operations (such as shutting down or
starting up a database) that should not be performed by normal database users.
Oracle provides for secure authentication of database administrator user names, for
which you can choose either operating system authentication or password files.
Following figure illustrates the choices you have for database administrator
authentication schemes. Different choices apply to administering your database
locally (on the machine where the database resides) and to administering many
different database machines from a single remote client.
Fig: Database Administrator Authentication Methods
Operating system authentication for a database administrator typically involves

establishing a group on the operating system, assigning DBA privileges to that
group, and then adding the names of persons who should have those privileges to
that group. On UNIX systems, the special group is called the dba group.
On Microsoft Windows systems, users who connect with the SYSDBA privilege can
take advantage of the Windows native authentication. If these users work with
Oracle Database using their domain accounts, then you must explicitly grant them
local administrative privileges and ORA_DBA membership.

The database uses password files to keep track of those database user names that
have been granted the SYSDBA and SYSOPER privileges. These privileges enable the
following operations and capabilities:
 SYSOPER lets database administrators perform STARTUP, SHUTDOWN,

ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP,
ARCHIVE LOG, and RECOVER. SYSOPER also includes the
RESTRICTED SESSION privilege.
 SYSDBA has all system privileges with ADMIN OPTION, including the
SYSOPER system privilege, and permits CREATE DATABASE and time-
based recovery.
Multitier Authentication and Authorization:

In a multitier environment, Oracle controls the security of middle-tier applications
by limiting their privileges, preserving client identities through all tiers, and
auditing actions taken on behalf of clients. In applications that use a heavy middle
tier, such as a transaction processing monitor, the identity of the clients connecting
to the middle tier must be preserved. One advantage of using a middle tier
is connection pooling, which allows multiple users to access a data server without
each of them needing a separate connection. In such environments, you need to be
able to set up and break down connections very quickly.
For these environments, Oracle database administrators can use the Oracle Call
Interface to create lightweight sessions, which allow database password
authentication for each user. This method preserves the identity of the real user
through the middle tier without the overhead of a separate database connection for
each user.
You can create lightweight sessions with or without passwords. However, if a

middle tier is outside or on a firewall, then security is better when each lightweight
session has its own password. For an internal application server, lightweight
sessions without passwords might be appropriate.

Fig: Multi-tire Authentication
LDAP = Lightweight Directory Access Protocol
Issues of administration and security in multitier environments are:
 Clients, Application Servers, and Database Servers

 Security Issues for Middle-Tier Applications
 Identity Issues in a Multitier Environment
 Restricted Privileges in a Multitier Environment
Clients, Application Servers, and Database Servers:
In a multitier environment, an application server provides data for clients and

serves as an interface from them to one or more database servers. The application
server can validate the credentials of a client, such as a web browser, and the
database server can audit operations performed by the application server. These
auditable operations include actions performed by the application server on behalf
of clients, such as requests that information be displayed on the client. A request to
connect to the database server is an example of an application server operation not
related to a specific client.
Authentication in a multitier environment is based on trust regions. Client

authentication is the domain of the application server. The application server itself
is authenticated by the database server. The following operations are performed:
 The client provides proof of authenticity to the application server, typically,

by using a password or an X.509 certificate.
 The application server authenticates the client and then authenticates itself to
the database server.
 The database server authenticates the application server, verifies that the
client exists, and verifies that the application server has the privilege to
connect for this client.
Security Issues for Middle-Tier Applications:
Security for middle-tier applications must address the following key issues:
 Accountability: The database server must be able to distinguish between the

actions of a client and the actions an application takes on behalf of a client.
It must be possible to audit both kinds of actions.
 Differentiation: The database server must be able to distinguish between a
client accessing the database directly and an application server acting either
for itself or on behalf of a browser client.
 Least privilege: Users and middle tiers should be given the fewest
privileges necessary to perform their actions, to minimize the danger of
inadvertent or malicious unauthorized activities.
Identity Issues in a Multitier Environment:
Multitier authentication maintains the identity of the client through all tiers of the
connection in order to maintain useful audit records. If the identity of the
originating client is lost, then specific accountability of that client is lost. It
becomes impossible to distinguish operations performed by the application server
on behalf of the client from those done by the application server by itself.
Restricted Privileges in a Multitier Environment:
Privileges in a multitier environment must be limited to those necessary to perform

the requested operation.

 Client Privileges: Client privileges must be as limited as possible in a

multitier environment. Operations are performed on behalf of the client by
the application server.
 Application Server Privileges: Application server privileges in a multitier
environment must also be limited, so that the application server cannot
perform unwanted or unneeded operations while performing a client
operation.
Database Authorization Methods:

A fundamental step in securing a database system is validating the identity of the
user who is accessing the database (authentication) and controlling what operations
they can perform (authorization). A strong authentication and authorization
strategy helps protect the users and their data from attackers.
Oracle provides a number of authentication and authorization mechanisms to meet

user requirements, from simple locally based password authentication to
centralized directory service integration to handle both authentication and
authorization. Administrators must keep user information up-to-date and secure for
the entire enterprise. This task becomes more difficult as the number of
applications, databases, and users increases. Each user might have or need multiple
accounts on different databases, making it harder to remember passwords. In
addition to user and account management problems, these conditions also produce
security problems. Any time a user leaves a company or changes jobs, that user's
privileges should be changed immediately in order to guard against their misuse.
However, large enterprises often have many user accounts distributed over
multiple databases, and an administrator may be unable to make timely changes.
Oracle Database provides different choices of authorization and authentication

methods such as:
Local Authentication and Local Authorization:

Oracle Database provides simple password authentication out of the box with
every database. This allows you to quickly create a database and provide access to
it, useful for some environments like development.

Authorization is also managed locally by having grants of privileges and roles

directly granted to the user schema in the database. With local password
authentication and local authorization, every new user for the database, every
person that leaves and changes in privileges and roles has to be managed by the
local DBA – including password resets. A typical method of authentication is using
the traditional password. When using database authentication for a user, the
administration of that user account including authentication is performed entirely
by Oracle Database. Users can also be authenticated externally by the operating
system. In this case, the user account is maintained by Oracle Database, but
password administration and user authentications are performed by an external
service. This external service can be the operating system or a network service,
such as Oracle Net.
Central Authentication and Local Authorization:

Oracle Database enables strong centralized authentication with Oracle
authentication adapters that support various third-party authentication services
such as Kerberos, Remote Authentication Dial-In User Service (RADIUS), and
SSL Authorization using Certificates. OS authentication can also be considered a
form of centralized authentication if the OS is configured in that manner.
 Kerberos is a trusted third-party authentication system that relies on shared

secrets. It presumes that the third party is secure, and provides single sign-on
capabilities, centralized password storage, database link authentication, and
enhanced PC security. It does this through a Kerberos authentication server.
Oracle supports both the original MIT Kerberos services as well as the
Kerberos service provided with Microsoft Active Directory.
 RADIUS is a client/server security protocol that is most widely known for
enabling remote authentication and access. Oracle Database uses this
standard in a client/server network environment to enable use of any
authentication method that supports the RADIUS protocol. RADIUS can be
used with a variety of authentication mechanisms, including token cards and
smart cards. Users frequently use the RADIUS service if they want to
implement multi-factor authentication for database users.
 SSL uses digital certificates that comply with the X.509v3 standard and a
public and private key pair.

 In OS authentication, the database relies on the OS to authenticate the user

to the user schema.
While authentication is centralized in these cases, authorization remains for the

most part locally managed in the Database. OS and RADIUS authentication allows
for some authorization via their service, most users manage the roles and privileges
locally in the database.
Central Authentication and Central Authorization:

Centralized management of users is a key part of IT security and the database is no
exception. Onboarding new users, assigning them to the correct resources with the
correct privileges, changing privileges and removing access when they leave is
more securely done centrally without having to manage every change within every
production database. DBAs could focus on application development or database
maintenance instead of the drudgery of fulfilling password reset requests. Oracle
Database provides two ways to get central authentication and central authorization:
 Centrally Managed Users (CMU): Starting in Oracle Database 18c, CMU

provides a simpler integration with Microsoft Active Directory to allow
centralized authentication and authorization of users. This direct integration
(without an intermediate directory service) enables organizations to use
Active Directory to centrally manage users and roles in multiple Oracle
databases with a single directory along with other Information Technology
services. Active Directory users can authenticate to the Oracle database by
using credentials that are stored in Active Directory. Active Directory can
also hold authorization information for database users through user
mappings to AD groups which then map to database schemas and global
roles. In fact, all the user authorizations (privileges and roles) can be granted
to the user through global roles which are granted to the user when they
authenticate to the database. CMU also integrates the database users with the
central Active Directory account policies for better security for parameters
like password lockout and expiration. Organizations can use Kerberos, PKI,
or password authentication with CMU with Active Directory.
 Enterprise User Security (EUS): is the legacy database integration with
Oracle directory services such as Oracle Internet Directory and Oracle
Unified Directory (OID and OUD). This powerful integration centrally
stores all the user and authorization mappings in the Oracle directory
service. This architecture is still available and will continue to be used by
users who must use the Oracle enterprise domain and current user database
link between trusted databases, complex enterprise roles, and having a single
place for auditing database access privileges and roles. The majority of
organizations do not have these complex requirements. Instead, they can use
centrally managed users (CMUs) with Active Directory.
Managing Users and Security:

Each Oracle database has a list of valid database users. To access a database, a user
must run a database application, and connect to the database instance using a valid
user name defined in the database.
When you create user accounts, you can specify limits to the user account. You can
also set limits on the amount of various system resources available to each user as
part of the security domain of that user. Oracle Database provides a set of database
views that you can query to find information such as resource and session
information.
Following are the components of Oracle database have to protect to manage users
and their security.
Profiles:
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 a wide range of
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, but for that purpose Database Resource Manager
is preferred.
Before creating profiles and setting the resource limits associated with them, you
should determine appropriate values for each resource limit. You can base these
values on the type of operations a typical user performs. For example, if one class
of user does not normally perform a high number of logical data block reads, then
set the LOGICAL_READS_PER_SESSION and

LOGICAL_READS_PER_CALL limits conservatively.
Usually, the best way to determine the appropriate resource limit values for a given
user profile is to gather historical information about each type of resource usage.
For example, the database or security administrator can use
the AUDIT SESSION clause to gather information about the limits
CONNECT_TIME, LOGICAL_READS_PER_SESSION, and
LOGICAL_READS_PER_CALL.
You can gather statistics for other limits using the Monitor feature of Oracle
Enterprise Manager (or SQL*Plus), specifically the Statistics monitor.
Managing Users:
When creating a user, you must provide a unique, unchangeable name for the user.
The name must be unique across all users within your tenancy. This name is the
user's login to the Console. You might want to use a name that's already in use by
your company's own identity system (for example, Active Directory, LDAP, etc.).
You must also provide the user with a description (although it can be an empty
string), which is a non-unique, changeable description for the user. This value
could be the user's full name, a nickname, or other descriptive information. Oracle
also assigns the user a unique ID called an Oracle Cloud ID (OCID).
After successfully creation of user admin can provide the different roles, privilege,
authority, to that user.
Some of the operations can perform to manage the user are:
 Provide Roles to the user

 Provide necessary privilege to user
 Add a user to a group
 Remove a user from a group
 Delete a user
 Block and Unblock a user
 Change a user's description

Managing Privilege:
A privilege is a right to execute a particular type of SQL statement or to access

another user's object. Some examples of privileges include the right to:
 Connect to the database (create a session)

 Create a table
 Select rows from another user's table
 Execute another user's stored procedure
You grant privileges to users so these users 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. A user can receive a privilege in two different ways:
 You can grant privileges to users explicitly. For example, you can explicitly
grant to user SCOTT the privilege to insert records into the employees table.
 You can also grant privileges to a role (a named group of privileges), and
then grant the role to one or more users. For example, you can grant the
privileges to select, insert, update, and delete records from
the employees table to the role named clerk, which in turn you can grant to
users scott and brian.
The major categories of privileges are:
 System Privileges
 Schema Object Privileges
 Table Privileges
 View Privileges
 Procedure Privileges
System privileges:
A system privilege is the right to perform a particular action, or to perform an
action on any schema objects of a particular type.

For example, the privileges to create tablespaces and to delete the rows of any table
in a database are system privileges.
Schema Object Privileges;

A schema object privilege is the 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.
Table Privileges
Schema object privileges for tables enable table security at the Data Manipulation
Language (DML) or Data Definition Language (DDL) level of operation,
DML Operations:
You can grant privileges to use the DELETE, INSERT, SELECT, and UPDATE DML
operations on a table or view. Grant these privileges only to users and roles that
need to query or manipulate data in a table.
You can restrict INSERT and UPDATE privileges for a table to specific columns of the
table. With selective INSERT, a privileged user can insert a row with values for the
selected columns. All other columns receive NULL or the default value of the
column. With selective UPDATE, a user can update only specific column values of a
row. Selective INSERT and UPDATE privileges are used to restrict user access to
sensitive data.
For example, if you do not want data entry users to alter the salary column of
the employees table, then selective INSERT or UPDATE privileges can be granted that
exclude the salary column. Alternatively, a view that excludes the salary column
could satisfy this need for additional security.

DDL Operations:
The ALTER, INDEX, and REFERENCES privileges allow DDL operations to be performed
on a table. Because these privileges allow other users to alter or create
dependencies on a table, you should grant privileges conservatively.
A user attempting to perform a DDL operation on a table may need additional

system or object privileges. For example, to create a trigger on a table, the user
requires both the ALTER TABLE object privilege for the table and
the CREATE TRIGGER system privilege.
View Privileges;
A view is a presentation of data selected from one or more tables (possibly
including other views). A view shows the structure of the underlying tables as well
as the selected data, and can be thought of as the result of a stored query. The view
contains no actual data but rather derives what it shows from the tables and views
on which it is based. A view can be queried, and the data it represents can be
changed. Data in a view can be updated or deleted, and new data inserted. These
operations directly alter the tables on which the view is based and are subject to the
integrity constraints and triggers of the base tables.
Procedure Privileges
EXECUTE is the only schema object privilege for procedures, including
standalone procedures and functions as well as packages. Grant this privilege only
to users who need to execute a procedure or to compile another procedure that calls
a desired procedure.
Managing Roles:
Managing and controlling privileges is made easier by using 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.

System or schema object privileges can be granted 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, a role X cannot be granted to role Y if
role Y has previously been granted to role X.
Database administrators often create roles for a database application. The DBA
grants a secure application role all privileges necessary to run the application. The
DBA then grants 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.
Predefined Roles:
The following roles are defined automatically for Oracle Database:
 CONNECT
 RESOURCE
 DBA
 EXP_FULL_DATABASE
 IMP_FULL_DATABASE
These roles are provided for backward compatibility to earlier versions of Oracle
Database and can be modified in the same manner as any other role in an Oracle
database.
Common Uses of Roles:

In general, you create a role to serve one of two purposes:
 To manage the privileges for a database application (Application Roles)

 To manage the privileges for a user group (User Roles)
Application Roles: You grant an application role all privileges necessary to run a
given database application. Then, you grant the secure application role to other
roles or to specific users. An application can have several different roles, with each
role assigned a different set of privileges that allow for more or less data access
while using the application.

User Roles: You create a user role for a group of database users with common
privilege requirements. You manage user privileges by granting secure application
roles and privileges to the user role and then granting the user role to appropriate
users.
Granting and Revoking Roles:

To provide selective availability of privileges, Oracle Database allows 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.
Who Can Grant and Revoke the roles?
Any user with the GRANT ANY ROLE system privilege can grant or revoke any
role except a global role to or from other users or roles of the database. You should
grant this system privilege conservatively because it is very powerful.
Any user granted a role with the ADMIN OPTION can grant or revoke that role to
or from other users or roles of the database. This option allows administrative
powers for roles on a selective basis.
You grant roles to (or revoke roles from) users or other roles by using either of the
following methods:
 Oracle Enterprise Manager 10g Database Control

 The SQL statements, GRANT and REVOKE
Privileges are granted to and revoked from roles using the same options. Roles can
also be granted to and revoked from users using the operating system that runs
Oracle, or through network services.
Security Domains of Roles and Users:

Each role and user has its own unique security domain. The security domain of a
role includes the privileges granted to the role plus those privileges granted to any
roles that are granted to the role.

The security domain of a user includes privileges on all schema objects in the
corresponding schema, the privileges granted to the user, and the privileges
of roles granted to the user that are currently enabled. (A role can be
simultaneously enabled for one user and disabled for another.) This domain also
includes the privileges and roles granted to the role PUBLIC.
Operating System and Roles:

In some environments, you can administer database security using the operating
system. The operating system can be used to manage the granting (and revoking)
of database roles and to manage their password authentication. This capability is
not available on all operating systems.
Roles in a Distributed Environment:

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

Oracle Database provides secure application roles, which are roles that can only be
enabled by authorized PL/SQL packages. This mechanism restricts the enabling of
such roles to the invoking application.
Security is strengthened when passwords are not embedded in application source

code or stored in a table. Instead, a secure application role can be created,
specifying which PL/SQL package is authorized to enable the role. Package
identity is used to determine whether privileges are sufficient to enable the roles.
Before enabling the role, the application can perform authentication and
customized authorization, such as checking whether the user has connected
through a proxy.

Data Encryption Techniques:

Encrypted data is data that has been disguised so that only an authorized recipient
can read it. You use encryption to protect data in a potentially unprotected
environment, such as data you have placed on backup media that is sent to an
offsite storage location.
When Should You Encrypt Data?

In most cases, you must encrypt sensitive data on your site to meet a regulatory
compliance.
For example, sensitive data such as credit card numbers, Social Security numbers,
or patient health information must be encrypted.
Historically, users have wanted to encrypt data to restrict data access from their
database administrators. However, this problem is more of an access control
problem, not an encryption problem. You can address this problem by using Oracle
Database Vault to control the access to your application data from database
administrators.
In most cases, you encrypt sensitive data, such as credit cards and Social Security
numbers, to prevent access when backup tapes or disk drives are lost or stolen. In
recent years, industry regulations such as the Payment Card Industry (PCI) Data
Security Standard and the Healthcare Insurance Portability and Accountability Act
(HIPAA) have become a driving factor behind increased usage of encryption for
protecting credit card and health care information, respectively.
Encrypting data includes the following components:
An algorithm to encrypt the data: Oracle Databases use the encryption algorithm
to encrypt and decrypt data. Oracle Database supports several industry-standard
encryption and hashing algorithms, including the Advanced Encryption Standard
(AES) encryption algorithm, which has been approved by the National Institute of
Standards and Technology (NIST).
A key to encrypt and decrypt data: When you encrypt data, Oracle Database
uses the key and plain text data as input into the encryption algorithm. Conversely,
when you decrypt data, the key is used as input into the algorithm to reverse the

process and retrieve the clear text data. Oracle Database uses a symmetric
encryption key to perform this task, in which the same key is used to both encrypt
and decrypt the data. The encryption key is stored in the data dictionary, but
encrypted with another master key.
You can encrypt individual table columns or an entire tablespace. Be careful that
you do not mix the two.
For example: suppose you encrypt a table column and then encrypt its surrounding
tablespace. This double encryption can cause performance problems. In addition,
column encryption has limitations in data type support, and only supports B-tree
indexes for equality searches. To check the current encrypted settings, you can
query the V$ENCRYPTED_TABLESPACES data dictionary view for tablespaces and
the DBA_ENCRYPTED_COLUMNS view for encrypted columns.
Transparent Data Encryption (TDE):

Transparent Data Encryption (TDE) is a data encryption technique used by oracle
database which enables you to encrypt individual table columns or an entire
tablespace.
When transparent encryption is applied, the protection is removed before data is

accessed. For example, when an authorized user copies a file from a file server,
this makes the encryption process “transparent” to end users, but also means data
exists in the clear any time it is moved or copied from the protected location.
When a user inserts data into an encrypted column, Transparent Data Encryption
automatically encrypts the data. When authorized users select the column, then the
data is automatically decrypted.
To encrypt data by using Transparent Data Encryption, you create the following
components:
 A keystore to stroe the master encryption key

 A Location for the keystore

A keystore to store the master encryption key:
The keystore is an operating system file that is located outside the database. The
database uses the keystore to store the Master Encryption Key.
To create the keystore, you can use the ADMINISTER KEY

MANAGEMENT SQL statement. The keystore is encrypted using a password as
the encryption key. You can create the password when you create the keystore.
Access of the contents (or master key) of the keystore is then restricted to only
those who know the password. After the keystore is created, you must open the
keystore using the password so that the database can access the master encryption
key.
You can use either software keystores or hardware keystores.
A software keystore is defined in a file that you create in a directory location. The
software keystore can be one of the following types:
 Password-based keystores: Password-based keystores are protected by

using a password that you create. You must open the keystore before the
keys can be retrieved or used.
 Auto-login keystores: Auto-login keystores are protected by a system-
generated password, and do not need to be explicitly opened by a security
administrator. Auto-login keystores are automatically opened when
accessed. Auto-login keystores can be used across different systems. If your
environment does not require the extra security provided by a keystore that
must be explicitly opened for use, then you can use an auto-login keystore.
 Auto-login local keystores: Auto-login local keystores are auto-login
keystores that are local to the system on which they are created. Auto-login
local keystores cannot be opened on any computer other than the one on
which they are created.
A hardware keystore is used with a hardware security module, which is a

physical device that is designed to provide secure storage for encryption keys

A location for the keystore:
You must specify the keystore location in the sqlnet.ora file.
When a user enters data, Oracle Database performs the following steps:
1. Retrieves the master key from the keystore.

2. Decrypts the encryption key using the master key.
3. Uses the encryption key to encrypt the data the user entered.
4. Stores the data in encrypted format in the database.
TDE Column Encryption:

Transparent Data Encryption (TDE) column encryption protects confidential data,
such as credit card and Social Security numbers, that is stored in table columns.
TDE column encryption uses the two-tiered key-based architecture to transparently

encrypt and decrypt sensitive table columns. The TDE master encryption key is
stored in an external security module, which can be an Oracle software keystore or
hardware keystore. This TDE master encryption key encrypts and decrypts the
TDE table key, which in turn encrypts and decrypts data in the table column.
Fig: TDE Column Encryption

As shown in figure above the TDE master encryption key is stored in an external
security module that is outside of the database and accessible only to a user who
was granted the appropriate privileges. For this external security module, Oracle
Database uses an Oracle software keystore or hardware security module (HSM)
keystore. Storing the TDE master encryption key in this way prevents its
unauthorized use.
When a table contains encrypted columns, TDE must use a single TDE table
key for all of encrypted columns. Each TDE table key is individually encrypted
with the TDE master encryption key. All of the TDE table keys are located
together in the colklc column of the ENC$ data dictionary table. No keys are
stored in plaintext.
Example 1: Encrypt an column with default encryption algorithm
CREATE TABLE employee (
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER,
salary NUMBER(6) ENCRYPT);
When you use ENCRYPT clause it encrypt the column with default encryption
algorithm i.e. AES192.
If you want to use a non-default algorithm, then use the ENCRYPT USING clause,
followed by one of the following algorithms enclosed in single quotation marks:
 3DES168
 AES128
 AES192 (default)
 AES256
Example 2: Encrypt a column sing non-default encryption algorithm
CREATE TABLE employee (
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER ENCRYPT NO SALT,
salary NUMBER(6) ENCRYPT USING '3DES168');
By default, TDE adds salt (random bits) to plaintext before encrypting it. Adding
salt makes it harder for attackers to steal data through a brute force attack.
However, if you plan to index the encrypted column, then you must use the NO
SALT parameter.
TDE Tablespace Encryption:
Transparent Data Encryption (TDE) tablespace encryption enables you to encrypt

an entire tablespace.
All of the objects that are created in the encrypted tablespace are automatically
encrypted. TDE tablespace encryption is useful if your tables contain sensitive data
in multiple columns, or if you want to protect the entire table and not just
individual columns. You do not need to perform a granular analysis of each table
column to determine the columns that need encryption.
Fig: TDE Tablespace Encryption

In addition, TDE tablespace encryption takes advantage of bulk encryption and

caching to provide enhanced performance. The actual performance impact on
applications can vary.
TDE tablespace encryption uses the two-tiered, key-based architecture to

transparently encrypt (and decrypt) tablespaces. The TDE master encryption key is
stored in an external security module (software or hardware keystore). This TDE
master encryption key is used to encrypt the TDE tablespace encryption key, which
in turn is used to encrypt and decrypt data in the tablespace.
TDE tablespace encryption also allows index range scans on data in encrypted
tablespaces. This is not possible with TDE column encryption.
Oracle Database implements the following features to TDE tablespace encryption:
 It uses a unified TDE master encryption key for both TDE column
encryption and TDE tablespace encryption.
 You can reset the unified TDE master encryption key. This provides
enhanced security and helps meet security and compliance requirements.
Example:
CREATE TABLESPACE tbstest;
CREATE TABLESPACE tbstest USING „AES192‟;
User-created tablespaces are encrypted by default.
By default, any new tablespaces created by using the SQL CREATE

TABLESPACE command are encrypted with the AES128 encryption algorithm.
You do not need to include the USING 'encrypt_algorithm' clause to use the
default encryption.
You can specify another supported algorithm by including the USING

'encrypt_algorithm' clause in the CREATE TABLESPACE command. Supported
algorithms are AES256, AES192, AES128, and 3DES168.

Benefits of TDE:
 As a security administrator, you can be sure that sensitive data is safe if the
storage media or data file is stolen or lost.
 Implementing Transparent Data Encryption helps you address security-
related regulatory compliance issues.
 Data from tables is transparently decrypted for the database user. You do not
need to create triggers or views to decrypt data.
 Database users do not need to be aware that the data they are accessing is
stored in encrypted form. Data is transparently decrypted for the database
users and does not require any action on their part.
 Applications need not be modified to handle encrypted data. Data encryption
and decryption is managed by the database.
Virtual Private Database (VPD):

Oracle Virtual Private Database (VPD) creates security policies to control database
access at the row and column level.
Essentially, Oracle Virtual Private Database adds a dynamic WHERE clause to a

SQL statement that is issued against the table, view, or synonym to which an
Oracle Virtual Private Database security policy was applied.
Oracle Virtual Private Database enforces security, to a fine level of granularity,

directly on database tables, views, or synonyms. Because you attach security
policies directly to these database objects, and the policies are automatically
applied whenever a user accesses data, there is no way to bypass security.
When a user directly or indirectly accesses a table, view, or synonym that is

protected with an Oracle Virtual Private Database policy, Oracle Database
dynamically modifies the SQL statement of the user. This modification creates
a WHERE condition (called a predicate) returned by a function implementing the
security policy. Oracle Database modifies the statement dynamically, transparently
to the user, using any condition that can be expressed in or returned by a function.
You can apply Oracle Virtual Private Database policies
to SELECT, INSERT, UPDATE, INDEX, and DELETE statements.

Example:
We have a table object student in c##pratik schema
Login to the c##pratik schema and apply select query on student object.
SQL> select* from student;
NAME ROLL
-------------------- ----------
ram 1
hari 2
gopal 3
lina 4
rajani 5
Let‟s apply policy on this schema object to hide the row whose roll is 3.
Login to database as sys user then perform the following task.
First create a function:
SQL> create or replace function filter_std(

st_schema in varchar2,
st_object in varchar2)
return varchar2
as
begin
return 'roll!=3';
end;
/
Add policy to the schema:
SQL> begin
dbms_rls.add_policy (
object_schema => 'c##pratik',
object_name => 'student',
policy_name => 'filter_student',
policy_function => 'filter_std'

);
end;
/
Now, login again to database as c##pratik schema and execute the select query.
SQL> select* from student;
NAME ROLL
-------------------- ----------
ram 1
hari 2
lina 4
rajani 5
Here the Oracle Virtual Private Database policy dynamically appends the
statement with a WHERE clause. This policy apply the following query to the
above table.
SQL> Select* from student where roll!=3;
End of Unit-5

Unit 5 Database Security and Auditing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 5 Database Security and Auditing

Uploaded by

Copyright:

Available Formats

Elective-Database Administration – CSIT 7th Semester

Unit-5: Database Security and Auditing

Terminologies about Auditing:

Audit objectives: set of business rules, system controls, government regulations,

Auditor: a person authorized to audit

Audit procedure: set of instructions for the auditing process

Audit report: a document that contains the audit findings

Audit trail: chronological record of document changes, data changes, system

Database auditing: chronological record of database activities

Internal auditing: examination of activities conducted by staff members of the

External auditing: examination of activities conducted by freelancer or third party

Database, User, and Schema:

By Lec. Pratik Chand, Page 1

SYS is a schema that includes tons of tables, views, grants, etc.

Technically - A schema is the set of metadata (data dictionary) used by the

Auditing is always about accountability, and is frequently done to protect and

By Lec. Pratik Chand, Page 2

Why Is Auditing Used?

 Enable accountability for actions: These include actions taken in a

Where Are Standard Audit Activities Recorded?

Schema Object Auditing:

Fine-Grained Auditing (FGA):

o Tables accessed between 6 p.m. and 6 a.m. or only on Saturday and

Importance of Data Security:

Each database can have an administrator, referred to as the security administrator,

User Privilege and Roles:

Let‟s discuss the three types of privileges and roles:

Object privilege: A system-defined privilege that controls access to a specific

By Lec. Pratik Chand, Page 5

To validate the identity of database users and prevent unauthorized use of a

 Authentication by the Operating System

By Lec. Pratik Chand, Page 6

Authentication by the Operating System:

Some operating systems permit Oracle to use information they maintain to

 Once authenticated by the operating system, users can connect to Oracle

 With control over user authentication centralized in the operating system,

When an operating system is used to authenticate database users, managing

Authentication by the Network

Authentication over a network is handled by the SSL protocol or by third-party

 Authentication Using SSL

Authentication Using SSL:

Authentication Using Third-Party Services:

Kerberos Authentication: Kerberos is a trusted third-party authentication system

PKI-Based Authentication: Authentication systems based on PKI issue digital

 Authentication and secure session key management using SSL.

By Lec. Pratik Chand, Page 8

for provisioning X.509 version 3 certificates for individuals, applications,

Authentication with RADIUS: Oracle supports remote authentication of users

Directory-Based Services: Using a central directory can make authentication and

 Oracle Internet Directory, which uses the Lightweight Directory Access

By Lec. Pratik Chand, Page 9

Authentication by Oracle Database:

Database authentication includes the following features:

 Password Encryption While Connecting. This protection is always in force,

Password Encryption While Connecting: Passwords are always automatically

By Lec. Pratik Chand, Page 10

Password Lifetime and Expiration: The database administrator can specify

Password Complexity Verification: Complexity verification checks that each

The sample Oracle password complexity verification routine (the PL/SQL

 Be a minimum of four characters in length

By Lec. Pratik Chand, Page 11

Authentication of Database Administrators:

Fig: Database Administrator Authentication Methods

Operating system authentication for a database administrator typically involves