Applied Oracle Security: Developing Secure Database and Middleware Environments- P27 pps

234 Part II: Oracle Database Vault END; / PL/SQL procedure successfully completed. These additional identities for the Client_IP and Session_User factors could also be incorporated into the Connection_Type DBV identity map presented in Chapter 5 to establish new connection classifications of INTERNAL_WEB and EXTERNAL_WEB. Read-only Application Users and Read-write Application Users Read-only application users are typically found in reporting systems or in a privilege set that is assigned to a “partner” application for a consolidated database with integrated object-owner accounts. For example, we may define an HR read-only role for access to the objects in the HR schema and grant this HR read-only role to the SH schema or a SH-related read-write role. Read-write application users are typically found in transactional database systems as they require INSERT, UPDATE, and DELETE commands against objects an application’s object-owner account. The users might also have access to execute PL/SQL procedures that are required to participate in the transactional nature of the system, especially in packaged applications for human resources or finance. The first things to consider before we create the end user access roles are the object access behaviors (the Verb-Object tables discussed earlier) the actors invoke in the use cases we defined for our system. In our notional use case, we’ve defined SELECT (read) on several objects such as Products, Channels, and Promotions in the SH schema as well as INSERT (write) on the object Product Cost. We also know that additional use cases in our system, such as the internal and external web services, will query Sales History objects. It becomes evident as we examine the Subject-Verb-Object-Condition tables we create that each use case will exhibit the need for read-only and read-write role pattern from Chapter 1. The difference among the use cases is the objects that are read from or written to. It is perfectly acceptable to define the read-only or read-write roles required for each use case at the start—in other words, a role for each Subject-Verb-Object-Condition table—but we must iterate through each role definition to see where the roles for the use case are the same and can therefore be combined into common roles. We must be careful not to combine them with reckless abandon, as we want to stick with the least privilege principals and avoid exposing sensitive objects to use cases that would lead to compliance issues or policy violation issues. For example, we want to avoid exposing read access to things like the company’s balance sheet numbers (compliance) or Social Security numbers of employees (PII) to roles used in a use case such as a Partner Web Service Sales History Query. Once we’ve defined the distinct set of read-only and read-write roles we will need, we can establish a basic approach for defining these roles based on the nature of the objects involved. The next topic to consider is how frequently objects are created or destroyed within object-owner accounts over the lifetime of the application(s). We also need to consider whether object-owner accounts are created and destroyed frequently, as this scenario can be found in many applications. If the objects within object-owner accounts are static in nature, the use of a direct object privilege model can be leveraged for the application (read-only and read-write) roles. If object-owner accounts will be dynamic or have dynamically created objects, a system privilege model has to be employed for the application (read-only and read-write) roles. We are left with a decision to create a finite set of roles for our use cases (or those that we are forced to use) and privilege sets that are based on either direct object privileges or system ANY privileges. The decision is really based on the static or dynamic nature of the objects being protected. Chapter 6: Applied Database Vault for Custom Applications 235 Database Administrator “Database administrator” is an overloaded term that typically refers to a person who uses a highly privileged database administration account, such as the SYS account with the SYSDBA privilege, the SYSTEM account, or a named account with the DBA role. These administrators can often cut across all application object-owner accounts and security controls to get the job done. What’s needed is a methodology to categorize these administrators so that a separation of duty can be achieved. A usable breakout of responsibilities that achieves this separation of duty among various database administrators is presented and demonstrates how DBV enables this separation. Application Administrator or Developer The application administrator or developer should be granted a limited set of system ANY privileges that would allow him or her to maintain object types and roles that are protected by a DBV realm and are authorized within the appropriate realm. DBV realms are set up to provide separation and areas of responsibility. Different areas of responsibility can be set up when more than one person does the same job but each has responsibilities for different types of data (such as sales or human resources data). TIP Define the areas of responsibility for determining realm authorizations. The administrator would have the system ANY privileges SELECT ANY, INSERT ANY, UPDATE ANY, DELETE ANY, CREATE ANY, ALTER ANY, DROP ANY, EXECUTE ANY (where applicable), and AUDIT ANY (where applicable) on the following object types to read, write, execute, audit, and modify the objects owned by separate object-owner accounts that are protected in the realm: CLUSTER CONTEXT DIMENSION INDEX INDEXTYPE MATERIALIZED VIEW OPERATOR OUTLINE PROCEDURE SEQUENCE SYNONYM TABLE TRIGGER TYPE VIEW ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 236 Part II: Oracle Database Vault The administrator would also have the following privileges for managing the roles protected by a realm and privileges and objects that are protected by a realm: GRANT ANY OBJECT PRIVILEGE To grant SELECT, UPDATE, and other direct object privileges on realm protected objects GRANT ANY ROLE To grant roles protected by the realm to accounts or other roles This full-featured application database administrator concept is already provided within the DBV product in the DV_REALM_OWNER role and can be used to implement this type of account. You may be concerned about the GRANT privileges, but remember that DBV includes the out-of- the-box realm Oracle Data Dictionary that protects against improper use of the privileges for Oracle COTS roles in the same way the functional application realm would enable the proper use of the privilege among different application realms. At this point, is this full-featured administrator role sufficient? It is sufficient to manage all aspects of the realm, but when viewed another way, it is not sufficient or at least not tolerable. It does not provide for the possibility that some organizations cannot tolerate a highly privileged database administrator within a given application, especially if that application contains sensitive data, where the application administrator could disable auditing of the realm objects while he or she “fixes” the application. We can create a model for the application administrator role that further breaks this user profile into separate application administrator profiles with distinct and sufficient responsibilities by grouping privilege (sets) granted to the role to perform a specific job. TIP Break down privilege sets into administrator profiles that define a job. This method still provides the possibility of combining profiles while maintaining separation of duties. Here’s a look at the profile breakout: Application security administrator This administrator is an application realm owner and can create roles, grant realm-protected roles, or grant realm-protected objects to other accounts or roles. The administrator can also control the audit configuration for the objects protected by the realm. We will demonstrate how to extend this profile to apply OLS policy objects protected by the realm. Application maintenance administrator This administrator’s privileges are limited to performing in the DDL category of commands on the application realm’s objects. The administrator is a participant in the application realm but the privileges do not allow for querying or manipulating data protected by the realm, controlling audit configuration for the objects protected in the realm, or granting of realm-protected roles or object privileges to realm-protected objects to other accounts or roles. Application data manager (data steward) This administrator is a participant in the application realm and the privileges granted are limited to performing queries (read) and DML, or write, commands on the objects protected by the realm. Very simply put, only SELECT, INSERT, UPDATE, DELETE, and EXECUTE commands are allowed. In certain cases, it may be possible to use the privilege set provided by this profile for read-write end user access profile if we couple it with the Subject-Verb-Object-Condition paradigm presented earlier. ■ ■ ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 237 Application data analyst A read-only end user profile whose scope is all objects within a realm. This type of profile is useful for accounts that need direct access to the database outside of an application (such as a web interface) and may use tools such as SQL*Plus or SQL Developer to perform ad hoc queries on the application data. Again, the Subject- Verb-Object-Condition paradigm presented earlier may apply here. Operational database administrator The operational DBA addresses the concern that an organization too often provides the SYS password to the IT staff members that ensure database integrity, reliability, and performance. This administrator has a wide range of system privileges for SELECT, DDL, DML, and system control commands to perform generic database administration related to storage, database jobs, Oracle COTS group account object maintenance (such as Oracle Spatial or Oracle Text), or performance tuning. The role we create will be granted a subset of the privileges granted to the default Oracle DBA role in the Oracle DBV. The fundamental differences between the operational DBA role and the default DBA role is removal of the following: o Account management privileges o Administer database-level triggers privileges, and these would be installed on an as- needed basis for applications o Oracle Data Change Notification (DCN) and Oracle Flashback privileges to prevent snooping of application realm–protected data The operational DBA is not authorized in any application (functional) DBV realms and therefore cannot perform commands that should be executed by the application administrator. However, the operational DBA is authorized as an owner in the Oracle Data Dictionary realm provided with the DBV installation so that named administrator accounts can be established to manage the objects and roles in this “application realm” The DBV policy limits security configuration for this operational DBA role to audit configuration and privilege management (GRANTs, ROLEs) within the Oracle Data Dictionary realm. The operational DBA can grant system privileges, restricted to realm owners of the Oracle Data Dictionary realm. The security controls in place for DBV prevent this role (or the DBA role) from modifying the DBV configuration or row-level security controls such as Oracle VPD or Oracle OLS. Account administrator This administrator provides separation of duty/controls the ability to create new database accounts or alter existing accounts (especially changing passwords) and database (password) profiles. Many forms of privilege escalation attacks involve creating a new privilege account or modifying the existing privileged accounts. By removing this capability from the operational DBA or SYSDBA, as DBV does out of the box, we reduced the possibility of this form of attack. The DBV product installs a role named DV_ACCTMGR, a DBV account management realm, along with a collection DBV command rules to model this separation-of-duty concept. DBV administrators and analysts The DBV product includes the roles DV_OWNER and DV_ADMIN and the DBV realm that allow for a named account to manage the DBV policy and authorizations within the overall policy. The responsibility is initially provided to the named account that is granted the DV_OWNER role at the time of the option’s installation. This account can create additional DBV administrators, so the use of named ■ ■ ■ ■ ■ ■ ■ 238 Part II: Oracle Database Vault accounts versus a group account is the direction we recommend for this administration function. DBV also includes a role named DV_SECANALYST that can query (SELECT) from the DBV configuration tables and the DBV audit trail stored in the table DVSYS. AUDIT_TRAIL$. In a compliance-regulated environment, or during an internal IT security review, you may need to set up named accounts and grant this read-only role to the account. Figure 6-4 depicts the administrator model along with the types of actions each administrator can perform. This separation of duty model in the database administrator area may seem overly strict to the typical database administrator. The intent is to demonstrate that a very fine-grained privileged model for administration is possible. The level at which it is broken out can be tailored to any environment based on the unique requirements that exist. The flexibility of DBV, in particular the rules-based approach that is central to the product, would not prevent you from assigning FIGURE 6-4 Administrators and duties Chapter 6: Applied Database Vault for Custom Applications 239 multiple administrative duties to a single named account or a new profile that combines application data administrator and application analyst, for example. Instead, the product lets you limit the use of privileges with some externally controlled factor or second person using rules you define and in the business context you desire. Now that we have outlined the content and rules for our model, let’s implement it! Example Implementation of Secure Schemas with DBV The approach employed to achieve this separation of duties should strive to leverage roles whenever possible as this provides a solution that is the easiest to manage from the perspective of granting system and object privileges. The process presented here includes the code to create these roles and demonstrate how named accounts can be created to leverage these roles within the flow of the overall process. We apply DBV policy as we proceed to help clarify its role in helping control the responsibilities of various actors. Create Operational Database Administrator Role and Accounts Recall that our operational DBA is responsible for general database administration tasks such as storage management, job maintenance, performance tuning, and general COTS group account object maintenance related to the Oracle feature set. The implementation of a role for this type of administrator is somewhat lengthy so is included as the script create_oper_dba.sql in the scripts that accompany this book. These scripts can be found on www.OraclePressBooks.com on the Downloads page. We can create this operation DBA role and accounts that require it as follows: sys@aos> create the role and grants sys@aos>@create_oper_dba.sql script. Role created. Grant succeeded. … Grant succeeded. sys@aos> authorize the role in the Oracle Data Dictionary realm sys@aos>CONNECT dbvowner Enter password: Connected. dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Oracle Data Dictionary' , grantee => 'OPER_DBA_0101' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_owner ); END; / PL/SQL procedure successfully completed. dbvowner@aos> add the role to the Oracle Data Dictionary realm dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Oracle Data Dictionary' ,object_owner => 'SYS' ,object_name => 'OPER_DBA_0101' ,object_type => 'ROLE' ); END; / 240 Part II: Oracle Database Vault PL/SQL procedure successfully completed. dbvowner@aos> create a new named account who will serve as the Operational DBA dbvowner@aos>CONNECT dbvacctmgr Enter password: Connected. dbvacctmgr@aos>CREATE USER jean_oper_dba IDENTIFIED BY <password>; User created. dbvacctmgr@aos> expire the password for dbvacctmgr@aos> the account so they are forced to dbvacctmgr@aos> change it to something they can control at next login dbvacctmgr@aos>ALTER USER jean_oper_dba PASSWORD EXPIRE; User altered. dbvacctmgr@aos> grant the Operational DBA role to new named account dbvacctmgr@aos>CONNECT / AS SYSDBA Connected. sys@aos>GRANT oper_dba_0101 TO jean_oper_dba Grant succeeded. sys@aos>CONNECT jean_oper_dba Enter password: ERROR: ORA-28001: the password has expired Changing password for jean_oper_dba New password: Retype new password: Password changed Connected. jean_oper_dba@aos> the account can manage roles as well as system jean_oper_dba@aos> privileges that are protected by jean_oper_dba@aos> the Oracle Data Dictionary jean_oper_dba@aos>GRANT RESOURCE, CREATE SESSION TO scott; Grant succeeded. jean_oper_dba@aos> the account can grant object privileges in Oracle jean_oper_dba@aos> COTS account that are protected by the Oracle Data jean_oper_dba@aos> Dictionary realm. jean_oper_dba@aos> CTX_DDL is an object owned by CTXSYS, jean_oper_dba@aos> the Oracle Text feature group account jean_oper_dba@aos>GRANT EXECUTE ON CTX_DDL TO scott; Grant succeeded. jean_oper_dba@aos> the account can manage Oracle COTS account objects jean_oper_dba@aos> that are protected by the Oracle Data Dictionary jean_oper_dba@aos>ALTER PACKAGE CTXSYS.CTX_DDL COMPILE BODY; Package body altered. jean_oper_dba@aos> the account can perform system level auditing jean_oper_dba@aos>AUDIT CREATE TABLE BY ACCESS; Audit succeeded. jean_oper_dba@aos> the account is still subject to jean_oper_dba@aos> application realm protections for SELECT jean_oper_dba@aos>SELECT * FROM sh.costs WHERE ROWNUM < 6; SELECT * FROM sh.costs WHERE ROWNUM < 6; * ERROR at line 1: Chapter 6: Applied Database Vault for Custom Applications 241 ORA-01031: insufficient privileges jean_oper_dba@aos> the account is still subject jean_oper_dba@aos> to application realm protections for GRANTs jean_oper_dba@aos>GRANT SELECT ON sh.costs TO oper_dba_0101; GRANT SELECT ON sh.costs TO oper_dba_0101 * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant object privilege on SH.COSTS ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 jean_oper_dba@aos> the account is still subject jean_oper_dba@aos> to application realm protections for AUDITs jean_oper_dba@aos>AUDIT INSERT ON sh.costs BY ACCESS; AUDIT INSERT ON sh.costs BY ACCESS * ERROR at line 1: ORA-01031: insufficient privileges jean_oper_dba@aos> tests for privilege escalation jean_oper_dba@aos>GRANT ADMINISTER DATABASE TRIGGER TO oper_dba_0101; Grant succeeded. jean_oper_dba@aos>GRANT ADMINISTER DATABASE TRIGGER TO jean_oper_dba; Grant succeeded. We don’t want the operational DBAs granting themselves privileges we are trying to protect them from using! At the same time, we want them to be able to grant system privileges or roles protected in the Oracle Data Dictionary realm as part of their normal job responsibilities. Sounds like a rule would be in order here—a DBV rule to be precise. The expression that would check for roles being part of the grantee list could be quite complex, if you consider that nested roles could exist. With this complexity, we might not have much luck with this as a simple DBV rule set expression. We will need to create a PL/SQL function to hide the complexity of the logic and need to determine under which object-owner account the PL/SQL should be created. Centralizing PL/SQL Routines for DBV Rules We want to centralize the PL/SQL routines that we use for DBV rules for the same reasons we centralized PL/SQL code used for DBV factors. We can implement common PL/SQL routines to be used in DBV rule sets in the DBVEXT schema in the same way we did for DBV factors. We’ve taken the liberty of creating a function named GRANT_OR_REVOKE_TO_SELF in the PL/SQL package DBVEXT.DBMS_MAC_EXTENSION. This function is used to indicate whether a grant occurs for the current user or roles they have been granted. This logic can be used to control the realm authorizations we are defining. We added to this package the SQL event context logic and call stack logic that were used in the DBV rule sets examples of Chapter 5. Protecting Against Privilege Escalation: “NO GRANTS TO THYSELF” We can now revisit the issue where jean_oper_dba was able to GRANT the ADMINISTER DATABASE TRIGGER privilege to the OPER_DBA_0101 role and her own account. Let’s revoke the privilege and modify our DBV policy to prevent this in the future: jean_oper_dba@aos>revoke administer database trigger FROM oper_dba_0101; Revoke succeeded. 242 Part II: Oracle Database Vault jean_oper_dba@aos> revoke administer database trigger FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos>CONNECT dbvowner Enter password: Connected. dbvowner@aos> create the rule that checks dbvowner@aos> for grants to one's account or roles dbvowner@aos>BEGIN dbms_macadm.create_rule( rule_name => 'Authorized Grant or Revoke' , rule_expr => 'dbvext.dbms_mac_extension.grant_or_revoke_to_self = 0' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> create a general rule set dbvowner@aos> for operation DBA command authorizations dbvowner@aos>BEGIN dbms_macadm.create_rule_set( rule_set_name =>'Authorized Operational DBA Command', description => 'Checks to verify the command is authorized for an Operational DBA', 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. dbvowner@aos> add the rule to the rule set dbvowner@aos>BEGIN dbms_macadm.add_rule_to_rule_set( rule_set_name => 'Authorized Operational DBA Command' , rule_name => 'Authorized Grant or Revoke' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> modify the realm authorization to be rules-based dbvowner@aos>BEGIN dbms_macadm.update_realm_auth( realm_name =>'Oracle Data Dictionary' , grantee => 'OPER_DBA_0101' , rule_set_name => 'Authorized Operational DBA Command' , auth_options => dbms_macutl.g_realm_auth_owner ); Chapter 6: Applied Database Vault for Custom Applications 243 END; / PL/SQL procedure successfully completed. dbvowner@aos>CONNECT jean_oper_dba Enter password: Connected. jean_oper_dba@aos> tests for privilege escalation jean_oper_dba@aos>grant administer database trigger to oper_dba_0101; grant administer database trigger to oper_dba_0101 * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant system privilege on ADMINISTER DATABASE TRIGGER. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 jean_oper_dba@aos>grant administer database trigger to jean_oper_dba; grant administer database trigger to jean_oper_dba * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant system privilege on ADMINISTER DATABASE TRIGGER. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 This is much better. We now have a named account with operational DBA privileges that can perform many of the database functions that SYS AS SYSDBA could perform with audit attribution to a named user. We have taken some precautions to prevent privilege escalation for this type of account using standard DBV capabilities and a simple PL/SQL function. Create (Group) Application Accounts With DBV installed, creating application accounts and protecting them with a realm is quite simple, as you saw in Chapter 5. We need to present the end-to-end process starting with the creation of an object-owner account for the Sales History application. We will do this with DBV already installed so you can understand the process within this context. dbvacctmgr@aos> create the Sales History dbvacctmgr@aos> realm's object-owner account, SH dbvacctmgr@aos>CREATE USER sh IDENTIFIED BY oracle DEFAULT TABLESPACE SYSAUX; User created. dbvacctmgr@aos> ensure we establish quotas on object-owner dbvacctmgr@aos> accounts whenever possible dbvacctmgr@aos>ALTER USER sh QUOTA 500M ON SYSAUX User created. dbvacctmgr@aos>CONNECT jean_oper_dba Enter password: Connected. jean_oper_dba@aos> grant the DBV role jean_oper_dba@aos> target for object-owner accounts jean_oper_dba@aos>GRANT dv_realm_resource TO sh; Grant succeeded. . 6: Applied Database Vault for Custom Applications 235 Database Administrator Database administrator” is an overloaded term that typically refers to a person who uses a highly privileged database. reliability, and performance. This administrator has a wide range of system privileges for SELECT, DDL, DML, and system control commands to perform generic database administration related to storage, database. privileges o Administer database- level triggers privileges, and these would be installed on an as- needed basis for applications o Oracle Data Change Notification (DCN) and Oracle Flashback privileges