For example, if we log in as the EUS user JOE, we can see that his database session roles and privileges reflect being the Sales History application data administrator.. global_oid_tree1
Trang 1304 Part II: Oracle Database Vault
FIGURE 7-1 EUS global schema mapping
FIGURE 7-2 EUS Enterprise role and database global role
Trang 2Once this configuration is complete, we can immediately leverage externally defined users in the organization as our realm administrators A key point to this capability is that the membership
in the EUS enterprise role SH_DATA_ADMIN_ENTERPRISE, a directory groupOfUniqueNames
object, is also controlled externally and can be leveraged in more than just a single database in the organization For example, if we log in as the EUS user JOE, we can see that his database session roles and privileges reflect being the Sales History application data administrator
sam_sec_mgr@aos>CONNECT joe
Enter password:
Connected.
global_oid_tree1@aos>SELECT SYS_CONTEXT('USERENV','EXTERNAL_NAME')
FROM dual;
SYS_CONTEXT('USERENV','EXTERNAL_NAME')
-cn=joe,cn=users,dc=us,dc=oracle,dc=com
1 row selected.
global_oid_tree1@aos> show the session roles that include
global_oid_tree1@aos> the SH_DATA_ADMIN_0101 role
FIGURE 7-3 EUS-based application security administrators
Trang 3306 Part II: Oracle Database Vault
global_oid_tree1@aos>SELECT * FROM session_roles
ORDER BY 1;
ROLE
-BASE_DATA_ADMIN_0101
DV_PUBLIC
SH_DATA_ADMIN_0101
SH_DATA_ADMIN_GLOBAL
4 rows selected.
global_oid_tree1@aos> show the session privileges
global_oid_tree1@aos> that include privileges like AUDIT ANY (object) global_oid_tree1@aos>SELECT *
FROM session_privs
ORDER BY 1;
PRIVILEGE
-CREATE SESSION
DELETE ANY TABLE
EXECUTE ANY INDEXTYPE
EXECUTE ANY OPERATOR
EXECUTE ANY PROCEDURE
EXECUTE ANY TYPE
INSERT ANY TABLE
SELECT ANY SEQUENCE
SELECT ANY TABLE
UPDATE ANY TABLE
10 rows selected.
global_oid_tree1@aos> attempt to use the SELECT ANY privilege
global_oid_tree1@aos> on a table that is protected by the
global_oid_tree1@aos> Sales History realm
global_oid_tree1@aos> SELECT
cust_last_name
, cust_year_of_birth
, cust_marital_status
, cust_income_level
FROM sh.customers
WHERE cust_state_province = 'TX'
AND ROWNUM < 10
ORDER BY cust_last_name;
CUST_LAST_ CUST_YEAR_OF_BIRTH CUST_MARIT CUST_INCOME_LEVEL
- - - -Beiers 1982 single K: 250,000 - 299,999
Duval 1981 single H: 150,000 - 169,999
Greeley 1977 F: 110,000 - 129,999
Grover 1970 married D: 70,000 - 89,999
Hamilton 1961 single G: 130,000 - 149,999
Krider 1967 F: 110,000 - 129,999
Majors 1948 single G: 130,000 - 149,999
Rowley 1969 single H: 150,000 - 169,999
Stone 1978 single I: 170,000 - 189,999
9 rows selected.
Trang 4global_oid_tree1@aos> on a table that is protected by the
global_oid_tree1@aos> Order Entry realm
global_oid_tree1@aos>SELECT cust_last_name,
date_of_birth,
marital_status,
income_level
FROM oe.customers;
FROM oe.customers
*
ERROR at line 2:
ORA-01031: insufficient privileges
With Oracle technologies such as Oracle Identity Manager, which is covered in Chapter 9, we could configure self-service workflows that allow a directory user such as JOE to remove himself temporarily from the application data administrator responsibility The self-service workflow could allow JOE to delegate this function to another directory user OIM can be configured to update the
members of the SH_DATA_ADMIN_ENTERPRISE groupOfUniqueNames object with this information
so that delegation of realm administration can be achieved The use of the Oracle Virtual Directory (OVD) will even also allow us to extend the backend directory store for EUS users shown in this example to the Active Directory and Sun Java System Directory Server products Refer to the OVD home page on the Oracle Technology Network (OTN) at www.oracle.com/technology/products/id_ mgmt/ovds/index.html for more details on this type of integration
We can extend the EUS example we’ve just presented with user identity attributes in a DBV rule set that controls the DBV realm authorization for the SH_DATA_ADMIN_0101 role In Chapter 6 we introduced the user identity attributes that are exposed in the EUS session context’s SYS_LDAP_USER_DEFAULT namespace Consider the case where JOE is a permanent employee
and SALLY is a contractor This fact can be stored in the identity attribute employeeType that is part of the inetOrgPerson directory object as shown in Figure 7-4.
Business rules in the organization may dictate that contractors cannot delete financial data
in systems such as the Sales History application We can define a DBV rule set that leverages the
employeeType attribute and the type of SQL command issued as follows:
diego_dbvmgr@aos> create the rule to check for the DELETE
diego_dbvmgr@aos> commands and the employeeType attribute
diego_dbvmgr@aos> of PERMANENT, or DBA for non-EUS users
diego_dbvmgr@aos>BEGIN
dbms_macadm.create_rule(
rule_name => 'DELETE By Permanent Employee Only'
, rule_expr =>'(INSTR(DVSYS.DV_SQL_TEXT,''DELETE'') = 1 AND ' ||
'NVL(SYS_CONTEXT(''SYS_LDAP_USER_DEFAULT'',''EMPLOYEETYPE''),''DBA'')'
|| ' IN (''PERMANENT'',''DBA''))'
|| ' OR (INSTR(DVSYS.DV_SQL_TEXT,''DELETE'') = 0)'
);
END;
/
PL/SQL procedure successfully completed.
diego_dbvmgr@aos> create the rule set and add this rule
diego_dbvmgr@aos>BEGIN
dbms_macadm.create_rule_set(
rule_set_name =>'Sales History Data Administration Allowed',
Trang 5308 Part II: Oracle Database Vault
description =>'Authorizes data administration controls commands for the Sales History realm.',
enabled =>dbms_macutl.g_yes,
eval_options =>dbms_macutl.g_ruleset_eval_all,
audit_options =>dbms_macutl.g_ruleset_audit_fail,
fail_options =>dbms_macutl.g_ruleset_fail_show,
fail_message =>NULL,
fail_code =>NULL,
handler_options =>dbms_macutl.g_ruleset_handler_off, handler =>NULL);
END;
/
PL/SQL procedure successfully completed.
diego_dbvmgr@aos>BEGIN
dbms_macadm.add_rule_to_rule_set (
rule_set_name => 'Sales History Data Administration Allowed' , rule_name => 'DELETE By Permanent Employee Only'
);
END;
/
PL/SQL procedure successfully completed.
FIGURE 7-4 Identity attribute employeeType
Trang 6Next we would update the realm authorization created for the SH_DATA_ADMIN_0101 role
in Chapter 6 to use the new DBV rule set:
diego_dbvmgr@aos>BEGIN
dbms_macadm.update_realm_auth (
realm_name => 'Sales History'
, grantee => 'SH_DATA_ADMIN_0101'
, rule_set_name => 'Sales History Data Administration Allowed'
, auth_options => dbms_macutl.g_realm_auth_participant
);
END;
/
PL/SQL procedure successfully completed.
Finally, we can test this externally controlled realm authorization using JOE and SALLY as our test accounts for a permanent and contract employee, respectively:
diego_dbvmgr@aos>CONNECT joe
Enter password:
Connected.
global_oid_tree1@aos>SELECT
SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','UID') USERNAME
SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','EMPLOYEETYPE') EMPLOYEETYPE
FROM DUAL;
USERNAME EMPLOYEETYPE
-
-joe PERMANENT
global_oid_tree1@aos> JOE is a permanent employee and therefore
global_oid_tree1@aos> is authorized for DELETE commands
global_oid_tree1@aos>DELETE SH.COSTS WHERE ROWNUM < 2;
1 row deleted.
global_oid_tree1@aos> next test with SALLY, who is a contractor,
global_oid_tree1@aos> and attempt the same DELETE, which will not
global_oid_tree1@aos> be authorized according to our DBV Rule
global_oid_tree1@aos>CONNECT sally
Enter password:
Connected.
global_oid_tree1@aos>SELECT
SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','UID') USERNAME
SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','EMPLOYEETYPE') EMPLOYEETYPE
FROM DUAL;
USERNAME EMPLOYEETYPE
-
-sally CONTRACTOR
global_oid_tree1@aos>DELETE SH.COSTS WHERE ROWNUM < 2;
DELETE SH.COSTS WHERE ROWNUM < 2
*
ERROR at line 1:
ORA-01031: insufficient privileges
Trang 7310 Part II: Oracle Database Vault
Identify End User Access Accounts and Roles for DBV SARs
To identify end user access accounts, we can examine the query results for the query used to identify roles with direct object privileges for SELECT, DML, or EXECUTE on database objects in
an object-owner account The accounts that have been granted these roles are usually connection pool accounts used for end user access, and the roles themselves may even be used as global enterprise roles with the Oracle EUS technology Due to the sensitive nature of the data accessed
by these accounts and roles, you may want to consider the use of DBV SARs instead of traditional database roles This approach allows you to apply the multifactored, rule-based control of the enablement of the role (a privilege set on sensitive objects) using some of the techniques we demonstrated with the roles SALES_MANAGER_APP_ROLE and SALES_WEB_SERVICE_APP_ROLE
We queried the view DBA_TAB_PRIVS earlier in the chapter to show accounts and roles with direct object privileges on an object-owner account’s objects This is a first pass at the roles we need to consider as end user access accounts We can also identify global schema accounts for EUS and externally identified accounts (for Advanced Security option (ASO)/Public Key Infrastructure (PKI)) using the following query:
sys@aos>SELECT username, password
FROM dba_users
WHERE password IN
( 'GLOBAL' identified globally
, 'EXTERNAL' identified externally
) ;
USERNAME PASSWORD
-OPS$JEFFREY EXTERNAL
OPS$APPSERVER_1 EXTERNAL
GLOBAL_OID_TREE1 GLOBAL
GLOBAL_OID_TREE2 GLOBAL
4 rows selected.
We can identify which accounts may be used for proxy authentication, which is often used with JDBC connection pools and EUS together, using the following query:
sys@aos>SELECT proxy, client
FROM proxy_users
ORDER BY 1;
PROXY CLIENT
-OID_POOL_1 GLOBAL_OID_TREE1
OID_POOL_2 GLOBAL_OID_TREE2
2 rows selected.
Finally, we can query the existing SARs in a database if we want to convert the application security logic used to enable these roles into DBV rules as part of any overall effort to consolidate security policies:
sys@aos>SELECT *
FROM dba_application_roles
WHERE schema != 'DVSYS'
ORDER BY 1;
Trang 8ROLE SCHEMA PACKAGE
-
-CUSTOM_SECAPP_ROLE SECAPP ROLE_SECURITY
1 row selected.
Identifying DBV Command Rules from Conditions
To identify which commands in a database are candidates for DBV command rules, ask the following questions:
What are the most sensitive transactions in the database that could affect the
organization’s ability to meet compliance (or other) regulations?
Which accounts are authorized to establish connections to the database, and what commands can those accounts perform?
Under what conditions can each command be performed with respect to time, place, and methods (factors)?
If the database supports a financial system, sensitive transactions may mean transactions related to sales (revenues) and costs (expenses) If the database supports a human resources system, this may mean transactions involving employee Social Security numbers, salaries, and health benefits
DBV command rules can be applied to these sensitive transactions to ensure that you have the highest level of assurance that they are executed within the appropriate context The context refers to the category of factors outlined previously and can help validate whether a transaction was executed from the correct client (machines), software programs (such as PL/SQL code), business rules (such as two-person control), and within the appropriate timeframe(s)
One method for determining the most sensitive transactions is to consider the frequency of each transaction with respect to other transactions in the database In a typical financial system,
we would expect “create or update” sales and costs transactions to be executed much more frequently than a “create product category” transaction We can generate a detailed transaction
frequency report that includes the database user and object being accessed in SELECT, DML, and EXECUTE transactions using the audit trail we’ve captured This report not only provides an
indicator of the most frequently occurring transactions but can also serve as the initial content for
a Subject-Verb-Object-Conditions table we can use to develop a fine-grained security profile The following query on the captured audit trail demonstrates this type of transaction frequency report:
sys@aos> SELECT db_user subject, action_name verb,
object_schema || '.'|| object_name object, COUNT(*)
FROM aos_common_audit_trail
WHERE object_schema NOT IN
( 'SYS','SYSMAN','DVF','DVSYS','LBACSYS','WK_TEST')
AND ( action_name IN (
'SELECT'
,'UPDATE'
,'DELETE'
,'INSERT'
) OR action_name LIKE '%EXECUTE%')
AND object_type NOT LIKE '%PARTITION%'
■
■
■
Trang 9312 Part II: Oracle Database Vault
GROUP BY db_user , action_name ,
object_schema || '.'|| object_name
ORDER BY db_user , action_name ,
object_schema || '.'|| object_name
;
SUBJECT VERB OBJECT COUNT(*)
- -
-ALAN_ANALYST DELETE SH.COSTS 1
ANTHONY EXECUTE PROCEDURE SH.SALES_TRANSCTION 2
DEB_DATA_MGR DELETE SH.COSTS 1
JRUSSEL EXECUTE PROCEDURE SH.SALES_TRANSCTION 4
JRUSSEL INSERT SH.COSTS 1
JRUSSEL SELECT SH.CHANNELS 1
JRUSSEL SELECT SH.PRODUCTS 1
JRUSSEL SELECT SH.PROMOTIONS 1
MARY DELETE SH.COSTS 1
MARY DELETE SH.SALES 1
MARY EXECUTE PROCEDURE SH.SALES_TRANSCTION 2
MARY UPDATE SH.CUSTOMERS 1
OPS$APPSERVER_1 DELETE SH.SALES 1
OPS$APPSERVER_1 EXECUTE PROCEDURE SH.SALES_TRANSCTION 26
PTUCKER EXECUTE PROCEDURE SH.SALES_TRANSCTION 4
PTUCKER INSERT SH.COSTS 1
PTUCKER SELECT SH.CHANNELS 1
PTUCKER SELECT SH.PRODUCTS 1
PTUCKER SELECT SH.PROMOTIONS 1
20 rows selected.
With this initial Subject-Verb-Object-Conditions table in place, we can identify the most important transactions based on the following:
The frequency of the transactions
Interviews with application experts to identify transactions that are either critical to the integrity of the system or corporate assets such as a balance sheet
We can start the analysis to determine the conditions that bound each of these important transactions We can develop DBV command rules for the types of transactions we uncovered
in the query results once this final analysis of business conditions is completed
Limiting the Availability of Extremely Sensitive Transactions
To add a level of security to sensitive transactions, you can use a database feature called Oracle External Tables (OETs) OETs provide a way to limit the ability to execute sensitive transactions to
an externally controlled decision point, similar to the directory-based example we used for the realm authorizations earlier OETs are read-only database tables that are based on information stored in flat files in the operating system Using an approach based on OETs allows you to create
a file that is owned by an OS account (or OS role) other than the Oracle software owner account (oracle) The account needs only read access to the file The OS file will contain the information
■
■
Trang 10that can be used to authorize or deny sensitive transactions The OS file owner is the only account that can update the file
To implement this strategy, we use the root OS account to create a directory for the authorization file (/etc/dbv/external_authorize.conf) We will then configure the database to use the directory in the creation of the OET In addition, we will create a directory (/var/log/dbv) for the logs generated
by the OET
[root@node1 ~]# mkdir -p /etc/dbv
[root@node1 ~]# mkdir -p /var/log/dbv
Next we will set the permissions on these directories to allow Oracle to read the files that make up the OET and write to the supporting log file directory:
[root@node1 ~]# touch /etc/dbv/external_authorize.conf
[root@node1 ~]# chmod -R 750 /etc/dbv
[root@node1 ~]# chown -R root:dba /etc/dbv
[root@node1 ~]# chmod 750 /var/log/dbv
[root@node1 ~]# chown oracle:dba /var/log/dbv
The next step is to create the Oracle directories and an OET that will be based on the file We can use our operational DBA role to create the directories and the DBVEXT account that contains extended DBV security capabilities for the OET object and supporting code:
jean_oper_dba@aos> create the directories
jean_oper_dba@aos>CREATE OR REPLACE DIRECTORY dbv_dir
AS '/etc/dbv';
Directory created.
jean_oper_dba@aos>CREATE OR REPLACE DIRECTORY dbv_dir_log
AS '/var/log/dbv';
Directory created.
jean_oper_dba@aos> grant privileges to the DBVEXT user
jean_oper_dba@aos> to use the directories
jean_oper_dba@aos>GRANT READ ON DIRECTORY dbv_dir TO dbvext;
Grant succeeded.
jean_oper_dba@aos>GRANT READ, WRITE ON DIRECTORY dbv_dir_log TO dbvext;
Grant succeeded.
jean_oper_dba@aos> create an OET under the DBVEXT object-owner account
jean_oper_dba@aos>CONNECT dbvext
Enter password:
Connected.
dvf@aos> CREATE TABLE external_authorize (
username VARCHAR2(30)
, event VARCHAR2(30)
, owner VARCHAR2(30)
, object VARCHAR2(130)
, status NUMBER
)