Unit 5 Database Security and Auditing
Unit 5 Database Security and Auditing
Audit log: document that contains all activities that are being audited ordered in a
chronological manner
Data audit: chronological record of data changes stored in log files or database
table object
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
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.
SYSTEM is a schema.....
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.
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.
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:
System privilege:
A system-defined privilege usually granted only by administrators. These
privileges allow users to perform specific database operations.
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.
SQLPLUS /
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
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.
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.
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.
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:
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.
Security for middle-tier applications must address the following key issues:
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.
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.
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
By Lec. Pratik Chand, Page 19
Elective-Database Administration – CSIT 7th Semester
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.
Managing Privilege:
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
The keystore is an operating system file that is located outside the database. The
database uses the keystore to store the Master Encryption Key.
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.
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:
When a user enters data, Oracle Database performs the following steps:
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.
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER,
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
first_name VARCHAR2(128),
By Lec. Pratik Chand, Page 31
Elective-Database Administration – CSIT 7th Semester
last_name VARCHAR2(128),
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.
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.
TDE tablespace encryption also allows index range scans on data in encrypted
tablespaces. This is not possible with TDE column 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:
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.
Example:
Login to the c##pratik schema and apply select query on student object.
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.
SQL> begin
dbms_rls.add_policy (
object_schema => 'c##pratik',
object_name => 'student',
policy_name => 'filter_student',
By Lec. Pratik Chand, Page 35
Elective-Database Administration – CSIT 7th Semester
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.
End of Unit-5