Applied Oracle Security: Developing Secure Database and Middleware Environments- P16 pdf

124 Part II: Oracle Database Vault 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). Let’s look at 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: dbvowner@aos> BEGIN dbms_macadm.create_realm( realm_name => 'Sales History' , description => 'Annual, quarterly, monthly, and weekly sales figures by product' , enabled => dbms_macutl.g_yes , audit_options => dbms_macutl.g_realm_audit_fail ); END; / PL/SQL procedure successfully completed. FIGURE 5-5 Sales History realm (all of one object owner) Chapter 5: Database Vault Fundamentals 125 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 discussed in Chapter 4. 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 => '%' ,object_type => '%' ); 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: system@aos> Attempt to query the sales data system@aos>select cust_id, amount_sold from sh.sales; select cust_id, amount_sold from sh.sales * ERROR at line 1: ORA-01031: insufficient privileges 126 Part II: Oracle Database Vault system@aos> Attempt to drop the sales data table system@aos>drop table sh.sales; drop table sh.sales * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: realm violation for drop table on SH.SALES ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 system@aos> Attempt to grant object privileges on the table to system@aos> another account, which will fail due to realm protections system@aos>grant select on sh.sales to scott; grant select on sh.sales to scott * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: realm violation for grant object privilege on SH.SALES ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 system@aos> Attempt to query the sales data using direct object system@aos> privileges granted to the account SCOTT. system@aos> This is authorized in the default behavior of a realm system@aos>connect scott Enter password: Connected. scott@aos>select cust_id, amount_sold from sh.sales; CUST_ID AMOUNT_SOLD 1258 23.75 1714 23.75 1842 23.75 Realm Audit Reporting The DBV owner account DBVOWNER can use the DBA web application to run audit reports on realm violations, as shown in Figure 5-6. 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. Furthermore, we’ve enforced this using a security administrator account (DBVOWNER) versus a database administrator, satisfying our separation of duty requirements. Finally we’ve prevented a database administrator from accidentally or maliciously destroying this financial data using a privilege such as DROP ANY TABLE. This aspect of DBV protection avoids the need for additional documentation during a compliance audit to describe the catastrophic event and elevates the integrity posture of any system. Chapter 5: Database Vault Fundamentals 127 Realm Components This is a good jumping off point to delve into the details of the components of a realm and some of the capabilities they provide. Earlier, we presented the creation of a logical realm name and its default auditing characteristics. We will call this the “realm header,” and you should note that the APIs used to maintain the realm header can also control the ability to enable and disable the realm, which may be required in situations where database installation, upgrade, or maintenance activities are required. TIP Use the disable and enable feature of a realm during installation, upgrade, or maintenance activities. Realm Objects Realm configuration can be defined at the schema level, as demonstrated in the SH example, so that all objects, no matter what type they are, will be protected. However, it is also possible to configure the realm to protect specific objects by object type or by object name. Given our SH example, it would be possible to protect only the tables in the SH schema as follows: dbvowner@aos> BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => '%' ,object_type => 'TABLE' ); END; / PL/SQL procedure successfully completed. FIGURE 5-6 DBV realm violation report 128 Part II: Oracle Database Vault It is also possible to configure the realm to protect only the SALES table in the SH schema, as follows: dbvowner@aos> BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SALES' ,object_type => 'TABLE' ); END; / The effect of this realm protection is immediate after the configuration step has been executed, in the same way that revoking an object privilege takes effect immediately. Any schema or a specific schema object can belong to multiple realms, so the OE.CUSTOMERS tables could be protected by both the Order Management realm and the Sales History realm. NOTE An object can be protected by more than one realm to support multiple application scenarios. The intent here is that an object such as OE.CUSTOMERS may be required for SELECT access by the database administrator of the Sales History realm, but we do not necessarily want to authorize this database administrator in the Order Management realm, which would provide the administrator access to more objects than requirements dictate. Managing Role Provisioning with Database Vault Realms In a special case, a database role is protected by a realm. To grant or revoke a role that is protected by a DBV realm, the session user must be authorized as the realm owner of the realm that is protecting the role. If you consider that a database administrator can grant or revoke any role in the database to any other user or role in the database, the need to incorporate protection of realms becomes clear. Suppose the application developer had defined a database role named SALES_SELECT_ROLE with SELECT privileges on the SH.SALES table and used this role as the only means to authorize access to view this data. A database administrator account could circumvent the Sales History realm controls if he were aware of the role and its privileges: system@aos> Display the object privileges defined for the role system@aos>SELECT grantee, privilege FROM dba_tab_privs WHERE owner = 'SH' AND table_name = 'SALES'; GRANTEE PRIVILEGE BI SELECT SALES_SELECT_ROLE SELECT system@aos> Display the system (ANY) privileges the account has system@aos> SELECT * FROM session_privs WHERE privilege LIKE '%ROLE%' Chapter 5: Database Vault Fundamentals 129 ORDER BY 1; PRIVILEGE ALTER ANY ROLE CREATE ROLE DROP ANY ROLE GRANT ANY ROLE system@aos> Attempt to query sales data, the realm control prevents system@aos>SELECT cust_id, amount_sold FROM sh.sales; SELECT cust_id, amount_sold FROM sh.sales * ERROR at line 1: ORA-01031: insufficient privileges system@aos> Grant the role to view the sales data since system@aos> as SYSTEM has the system privilege GRANT ANY ROLE system@aos> through the DBA role system@aos>GRANT sales_select_role TO system; Grant succeeded. system@aos> Set the role that allows us to view the sales data system@aos>SET ROLE SALES_SELECT_ROLE; Role set. system@aos> Attempt to query the sales data using the system@aos> direct object privileges provided by the role system@aos>SELECT cust_id, amount_sold FROM sh.sales; CUST_ID AMOUNT_SOLD 1258 23.75 1714 23.75 1842 23.75 With DBV, the security administrator can simply add the role as a realm object in the Sales History realm as follows: dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SALES_SELECT_ROLE' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. 130 Part II: Oracle Database Vault The next time a database administrator, such as SYSTEM, attempts to grant the role to himself or revoke the role from a valid grantee, DBV will prevent the action and audit the event: system@aos> Grant the role to view the sales data system@aos>GRANT sales_select_role TO system; system@aos>GRANT sales_select_role TO system * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: realm violation for grant role privilege on SALES_SELECT_ROLE. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 system@aos> Attempt to revoke the role from an existing grantee system@aos>REVOKE sales_select_role FROM sh; REVOKE sales_select_role FROM sh * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: realm violation for revoke role privilege on SALES_SELECT_ROLE. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 Realm Authorizations Realm authorizations define the accounts and roles that can use system ANY privileges on objects protected by a realm. Realm authorizations can be declared as either a realm participant or a realm owner. Both participants and owners can leverage system ANY privileges they have been granted on objects protected by the realm. The difference between a realm participant and a realm owner is that a realm owner can do the following but a participant cannot: Grant or revoke object privileges on objects protected by the realm Grant or revoke database roles that are protected in the realm DBV realm authorizations can be configured by accounts with the DV_ADMIN or DV_ OWNER roles, like our example DBVOWNER account. Note that realm authorizations do not grant system privileges or even object privileges when configured for a realm. Realm authorizations allow the use of system ANY privileges on objects that are protected by the realm. The underlying system ANY privileges still need to be granted to the account or role being authorized in the realm. In other words, a realm participant needs to be granted the SELECT ANY TABLE privilege explicitly to use a realm authorization, and a realm owner still needs to be granted the GRANT ANY OBJECT PRIVILEGE to use a realm authorization. NOTE Realm authorizations do not implicitly or explicitly grant privileges. They simply authorize the use of system ANY privileges. The ability to grant system ANY privileges and system privileges is limited once DBV is installed, using an out-of-the box realm called the Oracle Data Dictionary. The default owner of ■ ■ Chapter 5: Database Vault Fundamentals 131 this realm is the SYS account and is the only account capable of granting these privileges because DBV checks to see if the GRANT is performed by the owner of the Oracle Data Dictionary realm. Realms and Direct Object Privileges DBV will honor direct object privileges that are already granted (or are granted in the future) for any object protected by the realm. For example, since the account SCOTT had been granted the SELECT privilege on the SH.SALES table, the realm protections are not taken into consideration. The design intent with DBV in this regard was to honor existing application security models, where application developers had the foresight to grant specific object privileges as they were required using a least privilege design. Object-level privileges are verifiable through database dictionary views and extended through DBV privilege reports. Realms and the DBV Administrators For security reasons, the DBV roles DV_OWNER, DV_ADMIN, DV_SECANALYST, and DV_ ACCTMGR cannot be authorized in customer-defined realms. If this were allowed, the DBV security administrator, such as our example DBVOWNER, would be able to authorize himself in the Sales History realm, grant himself any realm-protected roles, and gain access to the sensitive financial data. The following example helps illustrate this DBV control: dbvowner@aos> DBV Security Administrator cannot authorize dbvowner@aos> themselves in a realm dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'DBVOWNER' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_owner ); END; / BEGIN * ERROR at line 1: ORA-01031: insufficient privileges ORA-06512: at "DVSYS.DBMS_MACUTL", line 10 ORA-06512: at "DVSYS.DBMS_MACUTL", line 367 ORA-06512: at "DVSYS.DBMS_MACADM", line 1728 ORA-06512: at line 2 Realm Authorizations and Object-owner Accounts Object-owner accounts, such as SH, are not authorized in a realm by default when the objects they own are protected by a realm. The object-owner accounts do have implicit direct object privileges and DDL privileges for objects they own in the normal Oracle Database security model. The DBV engine provides an implicit realm authorization for SELECT, DML, and EXECUTE, based on the direct object privilege rule, to the object-owner account, but DDL (ALTER, GRANT, AUDIT, and so on) statements are not implicitly authorized. This design allows for existing application code to operate for most environments but maintains a security posture around the structural integrity of the account’s objects. Object-owner accounts should have their passwords expired and locked by default. You want to maintain an audit attribution account model, using named administrators, as was discussed in Chapter 1. In this model, there is no 132 Part II: Oracle Database Vault expectation that the account would be used directly to manage the objects it owns. The following example shows this default behavior of application schemas being authorized for SELECT, but not being automatically authorized in the realm for DDL: sh@aos> Attempt to query the sales data as the object-owner SH sh@aos>SELECT cust_id, amount_sold FROM sh.sales; CUST_ID AMOUNT_SOLD 1258 23.75 1714 23.75 1842 23.75 sh@aos> Attempt to modify the SH.SALES table sh@aos>ALTER TABLE sh.sales ADD extra_column VARCHAR2(100); ALTER TABLE sh.sales ADD extra_column VARCHAR2 (100) * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: realm violation for alter table on SH.SALES ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 sh@aos> Attempt to grant the realm protected role sh@aos>GRANT sales_select_role TO system; GRANT sales_select_role TO system * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: realm violation for grant role privilege on SALES_SELECT_ROLE. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 To authorize DDL commands for the object-owner account SH in the Sales History realm to perform DDL, the following realm authorization must be configured: dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'SH' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_owner ); END; / PL/SQL procedure successfully completed. Named Accounts as Application DBAs for Realm Authorizations To manage the objects in an object-owner account such as SH, it is recommended that you use the application DBA pattern presented in Chapter 1. With this pattern, it would be more appropriate to create a named database account—such as a senior database administrator named MARY—to be the realm owner of the Sales History realm, and a realm participant—such as a Chapter 5: Database Vault Fundamentals 133 junior database administrator named ANTHONY. This forces audit attribution to a named individual (in other words, a real person) for any commands that are executed on objects protected by the realm, regardless of the outcome of those commands. The first step is to create the accounts. Recall from the DBV policy that is installed that the DBV Account Administrator, DBVACCTMGR, has been granted the only role, DV_ACCTMGR, authorized to use the CREATE USER privilege. use the example DBV Account Administrator to create the two new Application DBA accounts dbvacctmgr@aos>CREATE USER mary IDENTIFIED BY <password>; User created. dbvacctmgr@aos>CREATE USER anthony IDENTIFIED BY <password>; User created. The SYS account is the only account authorized to manage system ANY privileges, such as CREATE ANY TABLE, as well as powerful roles such as DBA that are protected by the default DBV configuration. This SYS account is the realm owner of the Oracle Data Dictionary realm. The SYS account can be used to grant the named accounts, MARY and ANTHONY, the underlying system ANY privileges required to manage the objects protected by the Sales History realm. The DBA role has been granted a number of system ANY privileges that help to demonstrate this approach concisely. dbvacctmgr@aos> grant these two new accounts the DBA role so they dbvacctmgr@aos> have the underlying system ANY privileges that allow dbvacctmgr@aos> them to manage objects protected in a realm dbvacctmgr@aos> connect / as sysdba Connected. sys@aos>GRANT dba TO mary; Grant succeeded. sys@aos>GRANT dba TO anthony; Grant succeeded. Finally, we use the example DBV security administrator, DBVOWNER, to authorize the accounts in the Sales History DBV realm as required: sys@aos>CONNECT dbvowner Enter password: Connected. dbvowner@aos> configure MARY as the realm owner dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'MARY' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_owner ); END; / PL/SQL procedure successfully completed. dbvowner@aos> configure ANTHONY as the realm participant dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( . II: Oracle Database Vault The next time a database administrator, such as SYSTEM, attempts to grant the role to himself or revoke the role from a valid grantee, DBV will prevent the action and. through database dictionary views and extended through DBV privilege reports. Realms and the DBV Administrators For security reasons, the DBV roles DV_OWNER, DV_ADMIN, DV_SECANALYST, and DV_ ACCTMGR. object privileges and DDL privileges for objects they own in the normal Oracle Database security model. The DBV engine provides an implicit realm authorization for SELECT, DML, and EXECUTE, based