We can use DBV rule set event functions and application context within the rule expressions used in DBV rule sets to provide this information.. The first thing we need to do is update ou
Trang 1However, an operational DBA can use EXPLAIN PLAN without being authorized in the realm
to determine whether query or storage optimization techniques need to be applied to resolve performance issues
an operational DBA cannot query
the realm protected data and
analyze with AUTOTRACE ON
jean_oper_dba@aos>SET AUTOTRACE ON
jean_oper_dba@aos>SELECT COUNT(*)
FROM app_object_owner.customers
WHERE state_province = 'VA' ;
2 3 FROM app_object_owner.customers
*
ERROR at line 2:
ORA-01031: insufficient privileges
jean_oper_dba@aos>EXPLAIN PLAN FOR
SELECT COUNT(*)
FROM app_object_owner.customers
WHERE state_province = 'VA'
/
Explained.
query the EXPLAIN PLAN data to
retrieve the diagnostic information
SELECT plan_table_output
FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-Plan hash value: 296924608
-| Id -| Operation -| Name -| Rows -| Bytes -| Cost (%CPU) -| Time -|
-| 0 -| SELECT STATEMENT -| -| 1 -| 11 -| 898 (1) -| 00:00:11 -|
| 1 | SORT AGGREGATE | | 1 | 11 | | |
|* 2 | TABLE ACCESS FULL| CUSTOMERS | 383 | 4213 | 898 (1)| 00:00:11 |
-Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter("STATE_PROVINCE"='VA')
14 rows selected.
Advanced Monitoring and Alerting
with a DBV Database
In this section, we present some exciting new features that are available in the latest version of the OEM GC product These features offer centralized monitoring, audit reporting, and alerting for all DBV-enabled databases in your enterprise They also enable the macro-level auditing type view
Trang 2of the enterprise security posture that was first introduced in Chapter 2 We conclude the section with a simple example of how you can extend the DBV Rule Set component to integrate your existing monitoring and alerting systems with context-sensitive information regarding DBV policy violations that occur
Monitoring and Alerting on DBV with OEM GC
Another useful feature added to OEM GC 10.2.0.5 is the ability to monitor and alert on DBV policy changes, DBV configuration issues, and DBV policy violations in the target databases it monitors The product defines several metrics in these categories that are collected on an ongoing basis, as shown in Figure 7-8
When an alert is generated from one of these metrics, it is displayed on the target DBV database’s home page in OEM GC providing a real-time, comprehensive view of what may have occurred This home page display is depicted in Figure 7-9
For each alert that is presented, the administrators of the systems can choose to acknowledge the alert and add comments related to the research and resolution of the issue When the alert has been fully resolved, the primary administrator or compliance officer can choose to clear the alert The alert tracking capability is shown in Figure 7-10
OEM GC allows you to log into each DBV-enabled database to view summary statistics, charts, and target-specific alerts for the database, as depicted in Figure 7-11
The target-centric interface also allows you to generate reports using a variety of filter controls
to investigate the offending account, SQL commands, and time frame that caused a policy violation as you investigate an alert This reporting interface is shown in Figure 7-12
FIGURE 7-8 DBV metric collection parameters in OEM GC
Trang 3FIGURE 7-9 Alerts for a DBV database in OEM GC
FIGURE 7-10 Responding to DBV alerts in OEM GC
Trang 4FIGURE 7-11 Database-specific DBV statistics in OEM GC
FIGURE 7-12 Fine-grained reporting on DBV policy violations in OEM GC
The monitoring and alerting of DBV policy changes, DBV configuration issues, and DBV policy violations in OEM GC provide real-time visibility into potential security issues in your databases The ability to document the process of responding to these issues provides added value to your compliance reporting needs as OEM GC keeps track of the historical nature of this process
Trang 5Extending the DBV Rule Set Custom Event Handler
Chapter 5 presented a simple example of how you can develop custom PL/SQL handler routines that handle the event that a rule set returns false (or true!) when used as part of a DBV command
rule The DBV command rule allowed only UPDATE commands on the SH.SALES table when
they came from the PL/SQL package procedure SH.SALES_TRANSACTION In this example,
we wrote a message to the table SH.ALERTS indicating that an event had occurred An alerting mechanism also needs to have detailed information on the actual security-relevant event that occurred We can use DBV rule set event functions and application context within the rule expressions used in DBV rule sets to provide this information The rule will write the details of the security-relevant event based on the data returned from the DBV rule set event functions to an application context namespace as part of the initial evaluation of the rule We can subsequently read this information from the application context in the rule set’s custom event handler procedure The first thing we need to do is update our rule definition to pass the DBV rule set event function values into the function we use to authorize the command:
diego_dbvmgr@aos> update the conditional rule that states
diego_dbvmgr@aos> we are using the trusted application code
diego_dbvmgr@aos> to pass the event functions, save them in
diego_dbvmgr@aos> context so they are accessible from the
diego_dbvmgr@aos> custom event handler
diego_dbvmgr@aos>BEGIN
dbms_macadm.update_rule(
rule_name => 'Called From Sales Transaction Package'
, rule_expr =>
'sh.sales_rules.update_allowed(
DVSYS.DV_SYSEVENT'
|| ',DVSYS.DV_LOGIN_USER'
|| ',DVSYS.DV_INSTANCE_NUM'
|| ',DVSYS.DV_DATABASE_NAME'
|| ',DVSYS.DV_DICT_OBJ_TYPE'
|| ',DVSYS.DV_DICT_OBJ_OWNER'
|| ',DVSYS.DV_DICT_OBJ_NAME'
|| ',DVSYS.DV_SQL_TEXT) > 0'
);
END;
/
PL/SQL procedure successfully completed.
The PL/SQL package DBVEXT.DBMS_MAC_EXTENSION that is part of the example source code provided with this book includes a procedure that can write this information to an application context with the namespace SQL_EVENT The procedure has the following signature:
PROCEDURE set_event_context(
command IN VARCHAR2
, session_user IN VARCHAR2
, instance_num IN NUMBER
, database_name IN VARCHAR2
, obj_type IN VARCHAR2
, obj_owner IN VARCHAR2
, obj_name IN VARCHAR2
, sql_text IN VARCHAR2
Trang 6DBVEXT must grant execute on this package to the SH for the object-owner account to use the SET_EVENT_CONTEXT procedure that is defined in the package:
diego_dbvmgr@aos>CONNECT dbvext
Enter password:
Connected.
dbvext@aos>GRANT EXECUTE ON dbvext.dbms_mac_extension TO sh;
Grant succeeded.
The next step is to update the function we use to authorize the command, SH.SALES_RULES UPDATE_ALLOWED, to have these new parameters passed to it We will use our Application Maintenance Administrator account from Chapter 6 for this task
dbvext@aos>CONNECT mark_maint_mgr
Enter password:
Connected.
mark_maint_mgr@aos> create a rules package procedure
mark_maint_mgr@aos> that accepts the event state and
mark_maint_mgr@aos> execute rule-specific decisions in one expression
mark_maint_mgr@aos>CREATE OR REPLACE PACKAGE sh.sales_rules AS
FUNCTION update_allowed(
command IN VARCHAR2
, session_user IN VARCHAR2
, instance_num IN NUMBER
, database_name IN VARCHAR2
, obj_type IN VARCHAR2
, obj_owner IN VARCHAR2
, obj_name IN VARCHAR2
, sql_text IN VARCHAR2
) RETURN NUMBER;
END;
/
Package created.
mark_maint_mgr@aos> create a rules package body
mark_maint_mgr@aos> that uses the DBVEXT procedure
mark_maint_mgr@aos> to save the event state to
mark_maint_mgr@aos> the application context SQL_EVENT
mark_maint_mgr@aos>CREATE OR REPLACE PACKAGE BODY sh.sales_rules AS
FUNCTION update_allowed(
command IN VARCHAR2
, session_user IN VARCHAR2
, instance_num IN NUMBER
, database_name IN VARCHAR2
, obj_type IN VARCHAR2
, obj_owner IN VARCHAR2
, obj_name IN VARCHAR2
, sql_text IN VARCHAR2
) RETURN NUMBER IS
BEGIN
Trang 7dbvext.dbms_mac_extension.set_event_context(
command => command
, session_user => session_user
, instance_num => instance_num
, database_name => database_name
, obj_type => obj_type
, obj_owner => obj_owner
, obj_name => obj_name
ensure we have first 4K only , sql_text => SUBSTR(sql_text,1,4000)
);
put the original business rules here
RETURN INSTR(UPPER(DBMS_UTILITY.FORMAT_CALL_STACK),
'PACKAGE BODY SH.SALES_TRANSCTION');
EXCEPTION
WHEN OTHERS THEN
ITS A GOOD IDEA TO GIVEN ERROR
CODE FOR ANY EXCEPTION THAT OCCURS
RETURN -1 * ABS(SQLCODE);
END;
END;
/
Package body created.
The next step is to update our rule set’s custom event handler to read the event details from application context and process them In this example, we will keep it simple and just write them
to the SH.ALERTS table:
mark_maint_mgr@aos>CREATE OR REPLACE PACKAGE BODY sh.sales_alerts AS
PROCEDURE sales_update_alert(
ruleset_name IN VARCHAR2
, ruleset_result IN VARCHAR2) IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO sh.alerts (msg ) VALUES
('Alert for Rule Set:' || ruleset_name);
INSERT INTO sh.alerts (msg ) VALUES
('result is ' || ruleset_result);
INSERT INTO sh.alerts (msg ) VALUES
('event is ' || sys_context('SQL_EVENT','COMMAND'));
INSERT INTO sh.alerts (msg ) VALUES
('user is ' || sys_context('SQL_EVENT','USER'));
INSERT INTO sh.alerts (msg ) VALUES
('instance is ' ||
sys_context('SQL_EVENT','INSTANCE'));
INSERT INTO sh.alerts (msg ) VALUES
('database is ' ||
sys_context('SQL_EVENT','DATABASE'));
INSERT INTO sh.alerts (msg ) VALUES
('object type is ' ||
sys_context('SQL_EVENT','OBJECT_TYPE'));
Trang 8('owner is ' || sys_context('SQL_EVENT','OWNER'));
INSERT INTO sh.alerts (msg ) VALUES
('object name is ' ||
sys_context('SQL_EVENT','OBJECT_NAME'));
INSERT INTO sh.alerts (msg ) VALUES
('SQL text is "' ||
sys_context('SQL_EVENT','SQL_TEXT') || '"');
COMMIT;
END;
END;
/
Package body created.
The final preparation step is to make sure we revalidate our DBV rule sets as follows:
mark_maint_mgr@aos>CONNECT diego_dbvmgr
Enter password:
Connected.
diego_dbvmgr@aos> verify the DBV Rule Sets are valid!
diego_dbvmgr@aos> exec dbms_macadm.sync_rules;
PL/SQL procedure successfully completed.
We are now ready to test our solution using the realm’s Application Data Administrator from Chapter 6 as the trouble-maker!
diego_dbvmgr@aos>CONNECT deb_data_mgr
Enter password:
Connected.
deb_data_mgr@aos> force the Command Rule violation
deb_data_mgr@aos> UPDATE sh.sales
SET amount_sold = 200
WHERE cust_id = 305;
2 3 UPDATE sh.sales
*
ERROR at line 1:
ORA-01031: insufficient privileges
deb_data_mgr@aos> view the alert table
deb_data_mgr@aos>SELECT msg
FROM sh.alerts
ORDER BY msgdate;
MSG
-Alert for Rule Set:Using Financials Application
result is FALSE
event is UPDATE
user is DEB_DATA_MGR
SQL text is "UPDATE SH.SALES
SET AMOUNT_SOLD = 200
WHERE CUST_ID = 305"
database is ENSG.US.ORACLE.COM
object type is TABLE
Trang 9object name is SALES
instance is 1
10 rows selected.
We could perform just about any integration with this handler mechanism when we consider the use of the standard Oracle PL/SQL packages such as UTL_TCP, UTL_HTTP, and UTL_SMTP or features such as external stored procedures and Java stored procedures
DBV realm authorizations are binary (allow/disallow) control unless coupled with a DBV rule set We can use the same approach of passing the DBV rule set event function values to
a function to provide a fine-grained control of realm authorizations that are based on these values In other words, we can define an application-specific function for use in a DBV realm authorization’s rule set rules as follows:
FUNCTION authorize_in_app_realm(
command IN VARCHAR2
, session_user IN VARCHAR2
, instance_num IN NUMBER
, database_name IN VARCHAR2
, obj_type IN VARCHAR2
, obj_owner IN VARCHAR2
, obj_name IN VARCHAR2
, sql_text IN VARCHAR2
) RETURN NUMBER;
This allows us to build case-like statements or table-driven controls in this function that handle command-specific, owner-specific, object-specific, or exception criteria in existing applications once we protect data with a realm
Summary
In this chapter, we presented techniques for developing DBV policies that can be applied to existing Oracle database applications DBV policies can be transparently applied to all SQL commands submitted to the database, regardless of the technology used to build the application This represents an opportunity for you to increase the security posture of your applications without rewriting code The following might prompt you to add DBV protections to your
applications:
Your organization is striving to meet compliance regulations such as separation of duties
or information privacy in the applications
Your organization is undergoing a database consolidation effort and security must be applied to achieve separation of control and to reduce the risk of insider threats or external attacks
The primary technique used in this chapter to identify the candidate DBV policy involves enabling core database auditing for all transactions and then exercising the applications to develop a transaction profile Once the transaction profile has been created, we demonstrate how you can query it to uncover the candidate DBV policy We augmented the queries on the transaction profile with additional queries on security-relevant database configuration views to refine the candidate DBV policy
■
■
Trang 10The transaction profile includes object-owner account names and object names that form the basis of DBV realm protections You can validate the list of sensitive objects by examining existing audit policies and row-level security policies Roles associated with a database account are listed
as database clients, and the use of system ANY privileges provides insight into which database roles should be authorized in a DBV realm and which database roles should protected by a DBV realm
We included a technique to help you map existing database roles to the Application Administrator roles pattern we recommended in Chapter 6 You can even integrate these Application Administrator roles with an external resource such as OID using the Oracle EUS technology
The transaction profile can be used to develop the candidate Subject-Verb-Object-Conditions table that we recommended in Chapter 6 This table serves as the basis for candidate DBV command rules and DBV rule sets Queries presented to develop this table gave you insight into the most sensitive transactions in your database We’ve included an example of how to externalize the authorization of these sensitive transactions with a mechanism that was controlled outside of the database
We concluded the analysis techniques with queries on both the transaction profile and the security-relevant database configuration views to identify DBV factors based on identity management, operational context, time, and external events Inspecting documentation from existing applications can assist in augmenting analysis, but we recommend that you review your candidate DBV policy with the technical experts of the applications and databases involved These experts have the greatest knowledge about how a system works and what the impact(s) might be if you add layers of security to an existing application or a database
We have also demonstrated how the Oracle Real Application Testing feature can be used
to validate that your applications continue operating normally under DBV policy control using real-world transactions and workloads The use of the newly released OEM GC DBV policy provisioning capabilities will reduce the time and risk in deploying the new DBV policy to test and production environments
Your applications and database may be using any number of existing database features and administration tools, such as Oracle Text, Oracle Spatial, RMAN, and TDE We included tips and techniques to ensure that these database features and the new Oracle DBV policy controls work together
Finally, we encourage you to consider the newly released monitoring and alerting features
in the OEM GC product for DBV policy changes, DBV configuration issues, and DBV policy violations These features are critical to tracking and reporting on security-relevant issues that could impact your ability to meet compliance regulations and protect against attacks