CHAPTER 5

REALM COMPONENTS AND PROTECTION PATTERNS

CHAPTER CONTRIBUTOR: Mr. Y.Rajesh Babu

5.1 INTRODUCTION TO REALM COMPONENTS

• A realm is a new security layer that provides containment and eliminates inadvertent
access based on system ANY privileges.
• System ANY privileges are required for many application and administration
scenarios.
• These privileges are heavily used in operating a database, but the privileges have no
boundaries and therefore must be restricted.
• The security gap exists between the database objects controlled by object privileges
and the system controlled by system ANY privileges.
• Realms were designed as a security mechanism that establishes boundaries around a
set of objects that limit the use of system ANY privileges to authorized realm users or
roles.
• Therefore, any attempt to access a realm protected object by an unauthorized user
with system ANY privileges will be blocked and raise a realm violation.
• Access based on object-level privileges are not considered inadvertent and therefore
are not enforced by the realm. Object level privileges are explicit permissions on
individual objects that can be verified through database dictionary views.
• Realms are a simple and critical security measure that address many of the issues we
face today regarding compliance and separation of duties for different job
responsibilities.
• They also serve as an affective defensive measure for cyber security by limiting the
extent to which system privileges can be exploited by an attacker.
• We know many customers have leveraged the existing database security technologies
and other database mechanisms, such as triggers, views, and PL/SQL, to implement
application security within the database.
• Therefore, simply maintaining an existing security approach can lure you into a false
sense of security, which effectively decreases your security posture and increases your
risk over time.
• Realm access = DB ANY privilege + Realm authorization.
• Applying realms to existing security approaches increases your security posture and
reduces your risk if you perform these simple steps:
1. Protect the data tables by adding them to a realm.
2. Protect security relevant objects by adding them to a realm.
• This includes PL/SQL procedures for VPD, PL/SQL procedures that perform trusted
transactions, and application database roles.
• Also consider the intent of any realm violation you encounter.
• A realm violation will occur if
• A new login session is created or an existing one is highjacked;
• Key privileges are available or new privileges are gained;
• Attempted access of a realm-protected object is determined to be unauthorized.
• Also consider the intent of any realm violation you encounter.
• A realm violation will occur if
• A new login session is created or an existing one is highjacked;
• Key privileges are available or new privileges are gained;
• Attempted access of a realm-protected object is determined to be unauthorized.
• A good example of a need for security is personally identifiable information (PII).
• Within DBV realms, you can establish boundaries and controls over PII at a either the
database schema level or an object level.
• Likewise, you can segment data as financials, personal health information, Sarbanes
Oxley Act (SOX), and so forth across database schemas, so that your realm covers
many objects over several database schemas.
• With realms for consolidation of IT resources and data, you can meet security for
compliance and insider threat concerns, along with data integration for consolidation
objectives.
• Security should not be the primary excuse for not consolidating data into a fewer
common databases.
• Consolidation will clearly add more value to the processing of data that is usually
transacted and queried together.
• Consolidation will reduce operations and maintenance costs associated with multiple
systems and offers these primary benefits:
• Increased data availability with a reduction in the labor, power, and storage
requirements to increase this availability.
2. Enhanced and centralized enterprise security that accounts for regulatory
compliance controls.
3. Universal access to data across the enterprise, without inefficient data movement
4.Reduced inconsistencies due to fewer instances of data duplication
• Simplification of the security management of your Oracle database and applications
as centralized policies are not coded into each application.
• To demonstrate how we meet these objectives for consolidation, consider the sample
schemas that are available with Oracle Database.
• The samples include the following schemas (a partial list):
• Human Resources (HR)
• Order Entry (OE)
• Sales History (SH)
• In many enterprises, this type of data is kept in separate databases and on separate
servers.
• This data as shown in the below figure
5.2 TYPES OF REALMS
Preconsolidation databases:

Consolidated databases:

• When viewed this way, it is easy to see the costs associated with maintaining these
databases with respect to the power consumption, hardware costs, labor costs,
software license costs, and recurring maintenance fees.
• With consolidation efforts in an enterprise, you can reduce the costs by hosting the
databases on a shared server platform with a smaller number of administrators.
• The challenge in this consolidated database architecture then becomes how to keep
database administrators of the Human Resources (HR) data from accessing or
manipulating the Sales History (SH) data, or vice versa.
• To demonstrate, log into the database using the SYSTEM account, a well-known
Oracle database account.
• The SYSTEM account has been granted the powerful DBA role and that role is
granted many ANY privileges for TABLE objects:
• As you can see, the SYSTEM account has privileges not only to read or write the
Sales History data using privileges such as SELECT ANY TABLE and UPDATE
ANY TABLE, but the account can modify the structures in which the data is stored
using a privilege such as ALTER ANY TABLE.
• The same types of system ANY privileges are usually granted to named database
administrator accounts, providing the same unbounded access to application data.
• We must introduce a DBV realm around the SH and HR schemas to enforce the
separation of duty and mitigate compliance concerns over unprotected access to PII or
the integrity of financial numbers used in an audit.
5.3 REALM PROTECTION PATTERNS:
• A DBV realm can be defined as a boundary around all the objects in a database
schema, a subset of objects in a database schema, or a collection of objects in multiple
schemas.
• In Figure Order Management realm (subset of object owner’s objects), a realm may
be defined for objects in several schemas to support the concept of an order
management application.
• The application may use a privileged account to access sensitive customer purchasing
information and PII information for employees.

Order Management realm (subset of object owner’s objects):

5.4 PROCESS IN REALM

• In Figure Human Resources realm (multiple objects, multiple object owners),
you can see a realm was created for a subset of the HR schema, where tables such as
EMPLOYEES and EMP_DETAILS_VIEW can contain PII information and tables such
as JOBS and JOB_HISTORY can include personal information such as an employee’s
salary.
 5.5 HUMAN RESOURCES REALM (MULTIPLE OBJECTS, MULTIPLE OBJECT
OWNERS)

FIG 1. HUMAN RESOURCES REALM INTER-REALTIONSHIP

5.6 CREATING YOUR FIRST REALM:

• You can protect and audit access to sensitive financial data in a configuration with a
few steps.
• The protection offers compliance-focused safeguards against insider threats and
elevates the integrity posture of the data to avoid accidental or malicious destruction
of the data.
• An example shows how the protection is implemented by the security administrator
and not the standard database administrator, demonstrating how DBV satisfies
separation of duty requirements.
• The first step in naming a realm allows you to identify data boundaries, irrespective of
ownership or control, as in the case of the Order Management realm.
• Realms are also verifiable from audit and compliance perspectives, because you can
define the DBV auditing behavior for any commands executed against objects
protected by the realm when you define the realm.
• Realm auditing can be configured for the realm so that audit records are generated if a
command is disallowed by the realm’s controls (called a realm violation).
• A simple example creating a realm for the Sales History (SH) schema to remove
access to the Sales History data from an account such as SYSTEM and roles such as
DBA.
• First, we log into the database using the DBV owner account named DBVOWNER
and create the realm:
• The DBVOWNER account was specified as the DBV owner during DBV installation
and is the initial account that can administer the DBV configuration.
• DBV realm configuration can be performed using the DVA web application or the
DVSYS.DBMS_MACADM administration package .
• The PL/SQL package DVSYS.DBMS_MACUTL contains constants and utility
functions that are used by DBV.
• The constants are beneficial when using the DVSYS. DBMS_MACADM package for
administration because they avoid the need for you to remember character or numeric
values for DBV component configuration procedures.
• In this example, we have simply created the realm and configured its default auditing
behavior, which is to audit when a realm authorization fails. We have not identified
the actual objects in the SH schema that will be protected by the realm, but this can be
done with one command:

5.7 Accessing Realm-Protected Objects:

• Once a schema or set of objects is protected by a realm, only the object owning
account can issue SELECT, Data Manipulation Language (DML), and EXECUTE
statements on the objects.
• The object owning account is not, however, allowed to execute Data Definition
Language (DDL) statements on the protected objects by default.
• Accounts and roles that have direct object privileges on a realm-protected object can
also access the objects protected in a realm for which they have object privileges,
shown in the GRANT SELECT ON sh.sales TO scott example.
• For system ANY privilege usage, realms must have owners and participants
established using a realm authorization.
• One of the most beneficial aspects of realms is that you get security enforcement
immediately without needing to perform additional procedures.
• Another way to look at this is that realms ensure that the ANY privileges are
immediately controlled.
• A realm immediately locks out users who were accessing the objects via the system
ANY privileges—even sessions operating with the SYSDBA privilege can no longer
access the objects protected in a realm.
• The DBV security administrator, such as DBVOWNER, must authorize an account
or a role in a realm before the account or role can use system ANY privileges against
the objects protected in a realm.
• At this point, we have defined the logical realm, its auditing characteristics, and the
objects that are to be protected in the SH object-owner account.
• We have not defined any explicit realm authorizations for the Sales History realm.
• What this means is that any database administrator will be prevented from accessing
or manipulating objects in the realm.
• We can demonstrate this by attempting to read the SH.SALES table again with the
SYSTEM account:
•
5.8 Realm Protection Patterns:

• A DBV realm can be defined as a boundary around all the objects in a database
schema, a subset of objects in a database schema, or a collection of objects in multiple
schemas.
• In Figure Order Management realm (subset of object owner’s objects), a realm may
be defined for objects in several schemas to support the concept of an order
management application.
• The application may use a privileged account to access sensitive customer purchasing
information and PII information for employees.

Creating Your First Realm:

• You can protect and audit access to sensitive financial data in a configuration with a
few steps.

• The protection offers compliance-focused safeguards against insider threats and

elevates the integrity posture of the data to avoid accidental or malicious destruction
of the data.

• An example shows how the protection is implemented by the security administrator

and not the standard database administrator, demonstrating how DBV satisfies
separation of duty requirements.

• The first step in naming a realm allows you to identify data boundaries, irrespective of
ownership or control, as in the case of the Order Management realm.
 • Realms are also verifiable from audit and compliance perspectives, because you can
define the DBV auditing behavior for any commands executed against objects
protected by the realm when you define the realm.
• Realm auditing can be configured for the realm so that audit records are generated if a
command is disallowed by the realm’s controls (called a realm violation).
• A simple example creating a realm for the Sales History (SH) schema to remove
access to the Sales History data from an account such as SYSTEM and roles such as
DBA.
• First, we log into the database using the DBV owner account named DBVOWNER
and create the realm:

-- Create a new realm named 'Sales History'

CREATE REALM Sales_History;

-- Grant the SH user access to the Sales_History realm

GRANT ALL ON Sales_History TO SH;

-- Create a global table named 'g' in the Sales_History realm

CREATE TABLE g (
id INT,
name VARCHAR(255),
price DECIMAL(10,2)
);

-- Insert some data into the g table

INSERT INTO g VALUES (1, 'Widget A', 12.99);
INSERT INTO g VALUES (2, 'Widget B', 9.99);
INSERT INTO g VALUES (3, 'Widget C', 15.99);

-- Select all data from the g table

SELECT * FROM g;

• The DBVOWNER account was specified as the DBV owner during DBV installation
and is the initial account that can administer the DBV configuration.
• DBV realm configuration can be performed using the DVA web application or the
DVSYS.DBMS_MACADM administration package .
• The PL/SQL package DVSYS.DBMS_MACUTL contains constants and utility
functions that are used by DBV.
• The constants are beneficial when using the DVSYS. DBMS_MACADM package for
administration because they avoid the need for you to remember character or numeric
values for DBV component configuration procedures.
In this example, we have simply created the realm and configured its default auditing
behavior, which is to audit when a realm authorization fails. We have not identified
the actual objects in the SH schema that will be protected by the realm, but this can be
done with one command
dbvowner@aos> BEGIN
dbms_macadm.add_object_to_realm ( realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => 'g'
,object_type => 'g'
);
END;
PL/SQL procedure successfully completed.

Accessing Realm-Protected Objects:

• Once a schema or set of objects is protected by a realm, only the object owning
account can issue SELECT, Data Manipulation Language (DML), and EXECUTE
statements on the objects.
• The object owning account is not, however, allowed to execute Data Definition
Language (DDL) statements on the protected objects by default.
• Accounts and roles that have direct object privileges on a realm-protected object can
also access the objects protected in a realm for which they have object privileges,
shown in the GRANT SELECT ON sh.sales TO scott example.
• For system ANY privilege usage, realms must have owners and participants
established using a realm authorization.
• One of the most beneficial aspects of realms is that you get security enforcement
immediately without needing to perform additional procedures.
• Another way to look at this is that realms ensure that the ANY privileges are
immediately controlled.
• A realm immediately locks out users who were accessing the objects via the system
ANY privileges—even sessions operating with the SYSDBA privilege can no longer
access the objects protected in a realm.
• The DBV security administrator, such as DBVOWNER, must authorize an account
or a role in a realm before the account or role can use system ANY privileges against
the objects protected in a realm.
• At this point, we have defined the logical realm, its auditing characteristics, and the
objects that are to be protected in the SH object-owner account.
• We have not defined any explicit realm authorizations for the Sales History realm.
• What this means is that any database administrator will be prevented from accessing
or manipulating objects in the realm.
• We can demonstrate this by attempting to read the SH.SALES table again with the
SYSTEM account:
Realm Audit Reporting:

• The DBV owner account DBVOWNER can use the DBA web application to run audit
reports on realm violations, as shown in the figure DBV realm violation report .
• The report demonstrates the failed attempts to query and even drop the objects
protected in the Sales History realm by the SYSTEM user.
• This realm example demonstrates how simple it is to protect sensitive financial data
using just two configuration steps with the DBV administration capabilities.
• With respect to compliance regulations, such as SOX, or an insider threat, you can see
how easily we’ve addressed access controls for privileged users to view financial data
and audited attempts to access the data.

DBV realm violation report:

SELF ASSESSMENT QUESTIONS
1. Can you identify the different components of a Realm?
2. Can you describe the purpose of each Realm component?
3. Can you explain how Realm components work together to provide data security?
4. Can you identify the different types of Realm protection patterns?
5. Can you describe the purpose of each Realm protection pattern?
6. Can you explain how Realm protection patterns can be used to protect data from
unauthorized access?
7. Can you identify the different types of Realm access control mechanisms?
8. Can you describe how Realm access control mechanisms can be used to control access
to data?
9. Can you explain how Realm access control mechanisms can be used to enforce data
security policies?
10. Can you identify the different types of Realm audit mechanisms?
11. Can you describe how Realm audit mechanisms can be used to track data access?
12. Can you explain how Realm audit mechanisms can be used to identify and investigate
data breaches?
13. Role-Based Access Control (RBAC): Can you explain how Role-Based Access Control
(RBAC) works? Can you identify the different types of RBAC roles? Can you explain how
RBAC roles can be used to control access to data?
14. Attribute-Based Access Control (ABAC): Can you explain how Attribute-Based Access
Control (ABAC) works? Can you identify the different types of ABAC attributes? Can you
explain how ABAC attributes can be used to control access to data?
15. Mandatory Access Control (MAC): Can you explain how Mandatory Access Control
(MAC) works? Can you identify the different types of MAC security labels? Can you
explain how MAC security labels can be used to control access to data?
16. Discretionary Access Control (DAC): Can you explain how Discretionary Access Control
(DAC) works? Can you identify the different types of DAC access control lists (ACLs)?
Can you explain how DAC ACLs can be used to control access to data?
17. Can you describe the different types of Realm threats?
18. Can you explain how Realm threats can be mitigated?
 19. Can you identify the different types of Realm vulnerabilities?
20. Can you explain how Realm vulnerabilities can be exploited?
21. Can you describe the different types of Realm attacks?
22. Can you explain how Realm attacks can be prevented and detected?

TERMINAL QUESTIONS
1. What is a realm?
Ans: A realm is a logical grouping of users, resources, and permissions within an
organization. It is a way to organize and manage access to data and resources in a secure
and manageable way.

realm in terminal - Opens in a new window

www.hoyolab.com
realm in terminal

2. What are the different components of a realm?

The different components of a realm are:

3. Users: The users of the realm are the people who are authorized to access the resources
in the realm.
4. Resources: The resources of the realm are the data and applications that are available to
users in the realm.
5. Permissions: The permissions of the realm are the rules that define what users are
allowed to do with the resources in the realm.
6. What are the different types of realm protection patterns?
7. The different types of realm protection patterns are:

8. Role-Based Access Control (RBAC): RBAC is a security model that assigns permissions to
users based on their roles in an organization.
9. Attribute-Based Access Control (ABAC): ABAC is a security model that assigns
permissions to users based on their attributes, such as their job title, department, or
security clearance.
10. Mandatory Access Control (MAC): MAC is a security model that assigns permissions to
users based on a security policy that is enforced by the system.
11. Discretionary Access Control (DAC): DAC is a security model that assigns permissions to
users by the owner of the resource.
12. What are the different types of realm access control mechanisms?
13. The different types of realm access control mechanisms are:

14. Access Control Lists (ACLs): ACLs are a list of permissions that specify who is allowed to
do what with a resource.
15. Roles: Roles are a way to group users together and assign them permissions.
16. Attributes: Attributes are a way to associate metadata with users and resources.
17. What are the different types of realm audit mechanisms?
18. The different types of realm audit mechanisms are:

19. Access logs: Access logs are records of who accessed what resources, when they
accessed them, and what they did with them.
20. Event logs: Event logs are records of events that occur in the realm, such as user logins,
resource creations, and permission changes.
21. Audit trails: Audit trails are a combination of access logs and event logs that provide a
complete record of activity in the realm.