Relationship between users and roles in databases

Relation Between Users And Roles In Databases

Discuss, in your own words using 250 words or more, the relationship between users and roles in databases. Explain why we use roles rather than simply assigning rights and privileges to each individual user.

Refer to the chapter one of attached document and answer it.

If you want more information. Refer below videos
https://www.youtube.com/watch?v=IDxXUBNBxPA

https://www.youtube.com/watch?v=eOSVTdw7Qbg

McGraw-Hill Education books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. To contact a representative, please visit the Contact Us pages at www.mhprofessional.com.

Security Oracle Database 12c: A Technical Primer Copyright © 2014 by McGraw-Hill Education (Publisher). All rights reserved. Printed in the United States of America. Except as permitted under the Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of Publisher, with the exception that the program listings may be entered, stored, and executed in a computer system, but they may not be reproduced for publication.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. All other trademarks are the property of their respective owners, and McGraw-Hill Education makes no claim of ownership by the mention of products that contain these marks.

Screen displays of copyrighted Oracle software programs have been reproduced herein with the permission of Oracle Corporation and/or its affiliates.

ISBN 978-0-07-182617-4 MHID 0-07-182617-3

Sponsoring Editor Proofreader Paul Carlstroem Paul Tyler

Editorial Supervisor Production Supervisor Patty Mon Jean Bodeaux

Acquisitions Coordinator Art Director, Cover Amanda Russell Jeff Weeks

Copy Editor Margaret Berson

Information has been obtained by Publisher from sources believed to be reliable. However, because of the possibility of human or mechanical error by our sources, Publisher, or others, Publisher does not guarantee to the accuracy, adequacy, or completeness of any information included in this work and is not responsible for any errors or omissions or the results obtained from the use of such information.

Oracle Corporation does not make any representations or warranties as to the accuracy, adequacy, or completeness of any information contained in this Work, and is not responsible for any errors or omissions.

About the Authors Michelle Malcher IOUG Board of Directors President and DBA Team Lead, DRW Holdings

Michelle is an Oracle ACE Director and the DBA Team Lead at DRW Holdings in Chicago, with several years’ experience in database development, design, and administration. She has expertise in security, performance tuning, data modeling, and database architecture of very large database environments. When she is not securing her own company’s databases, she writes articles and gives presentations on security and compliance topics as well as other database administrative areas such as RAC, ASM, and recovery. She is also a contributing author for multiple books including the IOUG Best Practices Tip Booklet. She has been very involved in the IOUG, and is currently serving as president on the Board of Directors. Paul Needham Senior Director of Product Management for Database Security, Oracle

Paul is responsible for the development of Oracle Database security features and products spanning Oracle Advanced Security, Oracle Database Vault, Oracle Audit Vault and Database Firewall, and Oracle Label Security. Joining Oracle Consulting in 1991, Paul worked closely with customers to help identify their security needs and challenges, and build innovative solutions. In 1998, he joined the Oracle Database Security product management team, and has since then introduced many new database security features and products. Prior to Oracle, Paul was responsible for various government projects at BDM International, a multinational information technology company, and was an intern at the National Security Agency studying database security. Paul graduated from Purdue University with a Bachelor of Science degree in computer science. Scott Rotondo Consulting Member of Technical Staff for Database Security, Oracle

Scott is a software architect for the Oracle Database Security development group. With 25 years of experience in the computer industry, Scott has held senior technical and management positions in operating system and database development, primarily focused on security features. From 2008 through 2010, Scott served as president of the Trusted Computing Group, an industry consortium and standards body dedicated to enhancing system security using mass-produced, standardized security hardware.

iv

Foreword In the first half of the 1990s, few if any databases were connected to the Internet,

certainly not the Internet as we know it today. The primary consumers of our security technologies back then were government and defense organizations concerned about data classification and multilevel security. Compliance regulations were few and far between. There was no such thing as the Payment Card Industry Data Security Standards (PCI- DSS), and HIPAA was just beginning to take shape. If a DBA wanted to steal a large amount of information (back then, a few megabytes was a “large” amount), they would need to carry out a disk drive larger than a few construction bricks and almost as heavy.

Outside of Oracle’s multilevel security solutions, the set of database security features used in our larger customer base consisted of discretionary access controls and database roles. Threats to data from insiders, organized crime, hackers, and SQL injection were not even a consideration. The primary security requirement was enforcing the principle of need-to-know using privileges, roles, and views.

When I joined Oracle in 1993, the user base of any database was necessarily limited—it was the day of client-server computing and, given the machines that databases ran on, databases were rather small; the number of users who had access to that database was small. For most customers database security was barely a consideration. SQL injection was considered acceptable in some applications. In fact, I remember demonstrating the use of SQL injection in Oracle Forms to show how easy it was to modify a query. Of course, due to the client-server nature of most applications, this was not a big deal as the application user was connected to the database using their own personal credentials and not the One-Big-Application User Model used by applications today.

Today, the world is a much different place. A DBA can walk out of work with terabytes of information easily—in a form factor smaller than a mobile phone and weighing even less. Privileged accounts and SQL injection are by some accounts the number one method of accessing sensitive information. Privacy and compliance requirements permeate nearly every industry worldwide. The Sarbanes-Oxley Act, the EU Data Protection Directive, China’s Guide for Personal Information Protection, and Japan’s APPI are just a few of the many regulations that customers must deal with on a regular basis. Today, the three-tier software architecture is the standard and the user base that has some level of access to application data is huge, typically measuring in the thousands, if not more. Securing your data and infrastructure can no longer be an afterthought, unless you want to appear on the front page of the news for having your users’ personal information stolen. Security is something that must be considered as important as high availability and scalability. When designing new applications, security must be considered from the very beginning and through every stage of the lifecycle development process.

That is where Securing Oracle Database 12c: A Technical Primer comes in. The three authors have dozens of years of experience between them and more importantly— dozens of years of Oracle Database security experience.

v

They begin with the basics—how to control access for your authorized users. This includes the concepts of enforcing “least privilege,” for example, making it harder for your trusted DBA or someone with unauthorized access to physically or figuratively walk out with terabytes of sensitive information. Each user in your database, each application schema, should have the smallest set of grants and privileges necessary to accomplish the job—and here we see how to accomplish that and learn why it is paramount.

After having discussed access control fully, they discuss how to secure data in the event of theft; how to secure data even if all access control is subverted. They introduce the concept of data encryption and discuss how to implement it at multiple levels.

Next, they return to access controls, getting into more sophisticated approaches such as column- and row-level access controls. This takes us beyond simple table and system privileges. They then move to a related security feature: auditing. Here we discover the auditing capabilities of the database and how to use them proactively, rather than as an after-the-fact diagnostic tool.

SQL injection is next. SQL injection is perhaps the most ubiquitous attack approach to databases. SQL injection exploits flaws in developed application code—not in the database itself. Given that there is a lot more application code out there floating around than database code, and given that much of that application code was written without thinking about SQL injection issues, there are many vulnerable applications. A quick search on the Internet for “SQL injection” will return millions of hits, many to news articles describing the latest company attacked, breaching sensitive customer data as a result. This book describes how database and security professionals can add a layer of defense between the application and database in order to reduce the ability of an outsider to launch a successful SQL injection attack.

Lastly, the authors look at implementing compliance. In 1993, if a company had 10 or even 100 Oracle databases running, that was considered “a lot.” Twenty years later, having thousands, or even tens of thousands, of Oracle databases running is commonplace. The need to ensure that all of these databases have the current patch and have been rolled out using a secure configuration is paramount. Doing that assurance check can be cumbersome, if not impossible, unless you have the right approach and tools, of course; that is what this section is all about. You’ll see how to verify and validate your system configuration compliance so that your database environment is set up in a secure, validated fashion.

If you are interested in security—specifically, securing an Oracle database—this is the book for you. While the title references Oracle Database 12c, most all of the content is applicable to Oracle Database 9i and above. Thomas Kyte http://asktom.oracle.com/

vi

Acknowledgments The authors wish to thank the following individuals who provided invaluable

assistance during the preparation and review of this manuscript: Troy Kitch, Melody Liu, Vikram Pesati, and James Spooner.

vii

Introduction The problem of securing important information has unfortunately become a

familiar one to organizations everywhere. A constant stream of news reports tells of successful attacks that gain access to sensitive data and the legal, economic, and reputational damage that results. Even though the vast majority of sensitive data is stored in relational databases, very little of the information security effort in most organizations is devoted to making those databases secure.

While there are many technologies and products available to improve the security of a database in various ways, what is needed is a brief but comprehensive overview that describes the major threats and appropriate techniques to address them. Attackers can be expected to exploit any available weakness including incorrect configuration of security controls in the database, unpatched operating system vulnerabilities, or compromised user accounts. More indirect methods such as SQL injection or intercepting data on the network are also possible. Truly securing a database system requires consideration of any opening an attacker might use.

Each chapter in this book covers a single threat area, but they are all related. There is no single solution that prevents all methods of attack, and each security mechanism reinforces the others. Defense-in-depth is the only way to effectively combat both threats that are known today and those that will be discovered tomorrow.

We begin with security features available within the database itself.

• Chapter 1: Controlling Data Access and Restricting Privileged Users describes the fundamental notions of authenticating users and controlling the data that they can access. It covers best practices for determining the access that each user requires and limiting the powers of highly privileged users.

• Chapter 2: Preventing Direct Access to Data explains the use of encryption to prevent attacks that attempt to gain access to data directly, bypassing the access controls described in the previous chapter.

• Chapter 3: Advanced Access Control covers more sophisticated access control mechanisms that allow for more precise control. These mechanisms include Virtual Private Database, Oracle Label Security, and Real Application Security.

• Chapter 4: Auditing Database Activity describes the techniques for maintaining an effective audit trail, which is a vital defense-in-depth technique to detect misuse by privileged users and unexpected violations of the security policies implemented in the previous chapters.

We then broaden the discussion to include external components that improve the security of the database and the data it stores.

• Chapter 5: Controlling SQL Input explains the use of a specialized database firewall to monitor the SQL statements going to the database. This helps to protect the database against SQL injection attacks launched by Web users.

viii

• Chapter 6: Masking Sensitive Data covers the use of data masking to remove sensitive information from data that is used for test or development purposes. It also describes the use of Data Redaction to dynamically mask the results of queries on production databases.

• Chapter 7: Validating Configuration Compliance describes the need to evaluate the database configuration against accepted standards and the tools available for performing the evaluation to ensure continued compliance.

Throughout the book, we highlight new features found in Oracle Database 12c. However, the majority of the solutions described in this book are applicable to earlier Oracle Database releases as well.

1

CHAPTER 1

Controlling Data Access and Restricting Privileged Users

The most fundamental step in securing a database system is determining who should be

able to access which data. This chapter describes the management of user accounts and

the mechanisms for determining the access that each user has. It continues with a

discussion of the types of privileged access that a user may have and available tools for

removing any additional access they do not need.

User Management All access to the database is through users, whether these are administrative users,

application accounts, or regular users. As the users have direct connection to the

database, it is important that they are properly authenticated and have appropriate roles,

and that their accounts cannot easily be compromised. It is also important to ensure that

there are proper resource constraints on their usage, or else the rest of the database may

be indirectly affected.

The CREATE USER statement is used to create a database user and its associated

schema. In the following example, the user is identified by a password, and the account

follows the policy specified by org_profile.

CREATE USER jsmith IDENTIFIED BY NoOne!Knows PROFILE org_profile

DEFAULT TABLESPACE data_ts TEMPORARY TABLESPACE temp_ts;

A profile specifies a named set of resource limits and password parameters that

restricts excessive consumption of system resources and enforces constraints on the

passwords. The password-specific parameters provide password management including

account locking, password aging, password history, and password complexity

verification. The password verification function is perhaps the most important control to

ensure that users pick complex passwords, making it difficult for intruders to guess them.

The FAILED_LOGIN_ATTEMPTS parameter limits brute-force password-guessing attacks

by locking the account after a specified number of incorrect logins.

2

CREATE PROFILE org_profile LIMIT

FAILED_LOGIN_ATTEMPTS 6 -- attempts allowed before locking

PASSWORD_LIFE_TIME 180 -- max life-time for the password

PASSWORD_VERIFY_FUNCTION ora12c_verify_function; -- Password complexity

check

The dictionary views DBA_USERS and DBA_PROFILES describe the users and

profiles, respectively. The privilege to create users must be limited to the DBA or the

security administrator. Each user should have an assigned tablespace; otherwise, any

objects they create would go into the SYSTEM tablespace, thus creating contention

between the data dictionary objects and the user objects.

Oracle Multitenant Database Users Oracle Multitenant, an Oracle Database 12c option, includes both common and local

users. A common user is created in the container database and has the same user name

and password in all of the pluggable databases that are part of the container database. The

common user can have privileges that are granted at the container level, and other

privileges that are granted in each pluggable database. The privileges can be different in

each of the pluggable databases, but the user doesn’t need to be created in each pluggable

database.

To create a common user for the container database and all of the pluggable

databases, log in to the container database as SYSTEM and create a user with

CONTAINER=ALL. Note that all common user names begin with the prefix C##.

SQLPLUS> CONNECT SYSTEM@root

Enter password: **********

Connected.

SQLPLUS> CREATE USER C##DB_ADMIN

IDENTIFIED BY IronMan4

CONTAINER = ALL;

A local user, on the other hand, is created in the pluggable database, and does not

have access to the container. This is good for the administrator who manages a pluggable

database but does not manage the overall system. To create a local user, connect to the

3

pluggable database as SYSTEM, create the user, and grant the needed roles and privileges

as before, but specify CONTAINER=CURRENT instead of CONTAINER=ALL.

SQLPLUS> CONNECT SYSTEM@pdb1

Enter password: *********

Connected.

SQLPLUS> CREATE USER pdb1_admin

IDENTIFIED BY SpiderMan3

CONTAINER = CURRENT;

Storing Passwords Users are expected to provide the password when they connect to the database, but

applications, middle-tier systems, and batch jobs cannot depend on a human to type the

password. Earlier, a common way to provide passwords was to embed user names and

passwords in the code or in scripts. This increased the attack surface and people had to

make sure that their scripts were not exposed to anyone else. Also, if passwords were

ever changed, changes to the scripts were required. Now you can store password

credentials by using a client-side Oracle wallet. This reduces risks because the passwords

are no longer exposed on command-line history, and password management policies are

more easily enforced without changing application code whenever user names or

passwords change.

To configure password storage using an Oracle wallet, set the

WALLET_LOCATION parameter in the sqlnet.ora file. The applications can then connect to

the database without providing login credentials, as follows:

CONNECT /@hr_db.example.com

Authentication Methods Users need to be authenticated before being allowed to connect to the database. Oracle

supports different means of authentication including passwords stored locally within the

database or in directories. Users can also be authenticated by the operating system, using

the IDENTIFIED EXTERNALLY clause when creating the user, or by various third-party

authentication services, including Kerberos, SSL/TLS, and RADIUS. Passwords are only

4

used for one-way authentication of the user to the database, while Kerberos and PKI

support mutual authentication, ensuring that the user is indeed connecting to the proper

database.

Oracle clients and servers communicating over SSL/TLS must have a wallet

containing an X.509 certificate, a private key, and a list of trusted certificates. An

administrator sets up this configuration using Oracle Wallet Manager to create the wallet

to store the PKI credentials and Oracle Net Manager to configure sqlnet.ora and

listener.ora for SSL authentication. The following example shows how to create a user

with the PKI certificate:

SQL> CREATE USER jsmith IDENTIFIED EXTERNALLY AS

'cn=jsmith,OU=HR,O=oracle,c=US';

Users can authenticate to the database using Kerberos in environments that

support that service. This capability is configured by setting the required parameters in

the Oracle Database server and client sqlnet.ora files using Oracle Net Manager. The

following example shows how to create an externally authenticated user that corresponds

to the Kerberos user:

SQL> CREATE USER jsmith IDENTIFIED EXTERNALLY AS 'jsmith@example.com';

You can now connect to an Oracle Database server without using a user name or

password as follows:

$ sqlplus /@hr_db.example.com;

Centralized User Management In an enterprise with a number of users accessing a number of databases, it is difficult to

manage unique accounts for each user in every database. Oracle Enterprise User Security

(EUS) enables centralized management of users and roles across multiple databases in

Oracle Internet Directory, which integrates with other directories such as Microsoft

Active Directory. Such users are called enterprise users, and they can be assigned

enterprise roles that determine access privileges across multiple databases. An enterprise

role consists of one or more global roles that grant database privileges to specific

databases.

5

EUS allows users and administrators to be authenticated by Oracle Internet

Directory using a password, Kerberos, or SSL. Upon connecting, the database refers to

the directory for user authentication, authorization (roles) information, and schema

mapping. Enterprise users can have their own schema, or they can share a global schema

in the databases they access. Here is an example of an enterprise user with an exclusive

schema, jsmith.

CREATE USER jsmith IDENTIFIED GLOBALLY AS 'CN=jsmith,OU=HR,O=oracle,C=US';

Users with Administrative Privileges Certain users can connect with special administrative privileges, such as SYSDBA and

SYSOPER, to allow maintenance operations even when the database is not open. These

users can authenticate using a network-based authentication service such as Oracle

Internet Directory or based on membership of the connecting user in a particular

operating system group.

If a user must connect with administrative privilege using a password for

authentication, the password is stored outside the database in a password file, which is

administered using the orapwd command. User management functions such as locking

an account after multiple failed login attempts are not available for users in the password

file, although each failed attempt will cause an exponentially increasing delay to limit

password guessing when the database is running.

Proxy Authentication and Authorization Sometimes administrators need to connect to an application schema to perform

maintenance. Sharing the application schema password among several administrators

would provide no accountability. Instead, proxy authentication allows the administrators

to authenticate with their own credentials first and then proxy to the application schema.

In such cases, the audit records show the actual user who performed the maintenance

activities. This form of proxy authentication is supported in Oracle Call Interface (OCI),

JDBC, and on the SQL*PLUS command line. Here is an example where the user

app_dba is allowed to connect to the database and act as hrapp.

ALTER USER hrapp GRANT CONNECT THROUGH app_dba;

6

Now the user app_dba can connect using his own password and assume the identity of

the hrapp user by proxy as follows:

CONNECT app_dba[hrapp]

Enter password:

Basic Access Control Every object in the database, such as a table, view, or procedure, is contained within a

schema. A schema is a user in the Oracle Database that owns objects. The schema user

generally has full access to the objects contained within that schema. Access by other

users is determined by object privileges, which allow a user to perform a particular

operation on one specific object. Some typical operations for objects are SELECT,

INSERT, UPDATE, DELETE, ALTER, and EXECUTE.

The schema user that owns an object has the ability to grant object privileges to

other users. In addition, if an object privilege is granted with GRANT OPTION, the

recipient of the grant also gains the ability to grant the same privilege to others. The

ability to propagate grants in this way is powerful and should be used sparingly.

Here is an example of creating a user with just a few privileges: to create a session

and connect to the database, to select from the DEPARTMENTS table, to execute the

ADD_DEPARTMENT procedure, and full permissions to read and change data on the

ADVENTURES table:

SQL> CREATE USER jsmith IDENTIFIED BY "Raider5!";

SQL> GRANT CREATE SESSION TO jsmith;

SQL> GRANT SELECT ON hr.departments TO jsmith;

SQL> GRANT EXECUTE ON hr.add_department TO jsmith;

SQL> GRANT SELECT, INSERT, UPDATE, DELETE ON hr.adventures TO jsmith;

The dictionary table DBA_TAB_PRIVS shows the object privileges that have been

granted. This gives detail about the object including the schema owner and which

privileges were granted. This table can be used for reporting privileges and managing the

level of permissions.

7

SQL> SELECT GRANTEE, OWNER, TABLE_NAME, PRIVILEGE

FROM DBA_TAB_PRIVS

WHERE GRANTEE='JSMITH';

GRANTEE OWNER TABLE_NAME PRIVILEGE

-------- ------ ------------ ----------

JSMITH HR DEPARTMENTS SELECT

JSMITH HR ADVENTURES SELECT

JSMITH HR ADVENTURES INSERT

JSMITH HR ADVENTURES DELETE

JSMITH HR ADVENTURES UPDATE

JSMITH HR ADD_DEPARTMENT EXECUTE

When privileges are no longer needed on an object, they should be revoked.

SQL> REVOKE DELETE ON hr.adventures FROM jsmith;

System Privileges and Roles Object privileges allow for very fine control over the data that a user can access, but

sometimes an administrator may require access to many objects. System privileges allow

access to all objects of a particular type; for example, SELECT ANY TABLE allows a user

to select from any table in any schema, and EXECUTE ANY PROCEDURE allows

execution of any PL/SQL procedure or function. Other system privileges apply to

operations that do not involve a specific object, such as the ability to create objects, users,

and roles; to change session and system parameters; and to export and import the

database. As you can see, these are privileges for the administrator who can perform

operations that have an impact across multiple schemas and objects.

Another convenient feature for managing privileges is the ability to group

multiple object and system privileges into a role. Roles are especially useful when there

is a need to grant a consistent set of privileges to several users. The roles are easier to

manage than individual privileges and can be matched up with an application or a job

function. Roles can be granted to other roles, allowing a large role like the DBA role for

the database administrator to be built up out of smaller components. Like the GRANT

option for object privileges, a system privilege or role can be granted with ADMIN

OPTION, which allows the recipient to grant the role or privilege to others.

8

The dictionary tables listed in the following table show the roles and privileges

granted to each user or role. For example, selecting from these tables shows that the DBA

role is extremely powerful, with more than 200 system privileges including CREATE and

ALTER SESSION; CREATE and ALTER ANY TABLE; SELECT, INSERT, UPDATE, and

DELETE ANY TABLE; EXPORT and IMPORT FULL DATABASE; DROP and CREATE

TABLESPACE; EXECUTE ANY PROCEDURE, and over a dozen roles.

Dictionary Table Contents

DBA_TAB_PRIVS Object privilege grants to roles or users

DBA_SYS_PRIVS System privilege grants to roles or users

DBA_ROLE_PRIVS Role grants to users or other roles

DBA_ROLES All defined roles

Least Privilege and Separation of Duty The principle of least privilege denotes the idea that each user of the system should be

granted only the minimum set of privileges needed to accomplish their intended tasks or

functions. When granting privileges to a user or role, it is preferable to grant specific

object privileges that are needed rather than broad system privileges that allow access to

all objects in the database. Similarly, it is better to create roles that each contain a few

privileges designed to be used for a particular function instead of very powerful roles like

the built-in DBA role. Granting several of these smaller roles to a user allows for a close

match to the tasks that the user needs to perform without granting extra privileges that are

not required.

Closely related to the principle of least privilege is the concept of separation of

duty. This is the notion that privileges should be divided among several users instead of a

single powerful individual. Dividing administrative privileges in this way improves

accountability and makes trusted administrators less likely to abuse their privileges.

To support the principles of least privilege and separation of duty, Oracle

Database has long included a SYSOPER administrative privilege, which allows an

administrator to perform certain tasks like starting and stopping the database without

9

having the full range of powers conferred by the SYSDBA privilege. Oracle Database 12c

adds additional administrative privileges called SYSBACKUP, SYSDG, and SYSKM, to

enable database backups, Data Guard administration, and key management, respectively.

With these targeted privileges, one or more administrators can perform all of the normal

operations to manage a database without needing the all-powerful SYSDBA privilege.

Controlling Privileged Users System privileges and powerful roles give significant control of the database, including

the ability to view all data and make changes to the data. Some administrative users need

these powerful privileges for maintenance, tuning, and backups, but they don’t need

access to all of the data. Even though the administrative users are trusted, it is important

to secure company data assets and personal information even from these privileged

accounts in order to prevent unauthorized use by insiders or attackers.

Oracle Database Vault provides several kinds of operational controls within the

database including realms, which enforce limits on access to specified objects such as

tables and views. After creating a Database Vault realm, objects are added to the realm

and database users can be designated as realm participants. This provides access only to

the realm participants, and excludes other users, even if they have powerful system

privileges like SELECT ANY TABLE that would otherwise allow them to access the

objects in the realm.

The following illustration shows an example of two realms, protecting database

schemas containing human resources (HR) and finance (FIN) data. Once enabled, the

realms prevent privileged administrative users or other application owners from using

their elevated privileges to access data. The privileged application owner HR is prevented

from accessing data inside the FIN realm, and even an administrator with the DBA role is

unable to access data in the HR and FIN realms.

10

In addition to regular realms, Oracle Database 12c adds the ability to create

mandatory realms. A regular realm will block the use of system privileges such as

SELECT ANY TABLE if the user is not a realm participant, but it doesn’t block the

schema owner or other users who gain access to the data using object privileges.

Mandatory realms prevent access by anyone who is not a realm participant. One popular

use for a mandatory realm is to continue to protect sensitive data during patching and

upgrades, when an administrator needs to make changes to the application schema but

should not have access to the data tables in that schema.

When Oracle Database Vault is configured, a couple of additional users are

created. The first of these is the Database Vault owner, who can create and manage

realms to control access to sensitive data. The second user is the Database Vault account

manager, who has the responsibility for creating users in the database. While a single user

could perform both functions, the ability to divide these duties among multiple users

allows for separation of duty as described earlier. Furthermore, there is a DVOWNER role

that can be granted to other users to delegate the ability to manage Database Vault

realms. This role should be granted to administrators who are responsible for the security

configuration of the database, rather than the general database administrator.

The following illustration shows the use of the Database Configuration Assistant

for enabling Oracle Database Vault. Management of Database Vault requires the use of

these specialized users and roles. The SYSDBA administrative privilege cannot be used for

realm or user management when Database Vault is enabled.