224 Part II: Oracle Database Vault As you can see, factors can play a significant role in application logic codified in your PL/SQL programs and can be integrated into row-level security mechanisms such as Oracle VPD, Oracle OLS, Oracle FGA, and database views. The implementation of factors as PL/SQL opens up these possibilities and just about any PL/SQL-based database feature such as database triggers or database jobs. Identify DBV Realms and Realm Objects Based on Objects The next step in the process of designing the DBV security policy is to examine the objects in our security profile to determine where we may have sensitive information that needs to be protected. We can identify the following objects: Product Costs Products Sales Organization Sales Management Package User Credentials Social Security Number Salary Commission System Security Package Products Channels Promotions Audit Trail Audit Notifications Next, we can ask ourselves whether we can categorize the information by the following criteria: Application and access requirements Content type This high-level usage analysis can be done using the information in Table 6-3, with requirements documents such as use case scenarios or UML sequence diagrams providing input into the analysis. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 225 Table 6-3 provides an interesting analysis in that we can clearly see a set of content type or application categories that will provide a nice break-out for our DBV realms. Namely, we want to investigate whether we need to provide DBV realms for the following: Sales Human Resources Database Yes, database! That seems odd, but the database itself is an application in that it operates in the same manner as custom applications that are loaded into it—tables, indexes, views, and programs are all found. As discussed in Chapter 5, Oracle DBV creates a handful of realms for the Enterprise Edition itself so the concept that the database itself should be protected is built into the product. ■ ■ ■ Object Content Type Application Type Access Requirement Product Costs Sales (SOX compliance) Sales Management Read, Write Products Sales Sales Management Read, Write (Read in this use case) Channels Sales Sales Management Read, Write (Read in this use case) Promotions Sales Sales Management Read, Write (Read in this use case) Sales Management Package Sales Sales Management Read, Write Sales Organization Identity Management Human Resources Read User Credentials Identity Management Human Resources Read Social Security Number Identity Management (PII compliance) Human Resources Prevent Read Salary Identity Management (privacy) Human Resources Prevent Read Commission Identity Management (privacy) Human Resources Prevent Read System Security Package Identity Management Human Resources Read Audit Trail System Database Write Audit Notifications System Database Read, Write TABLE 6-3 Information for High-level Usage Analysis 226 Part II: Oracle Database Vault We want to consider auditing and auditing notification as a generic application requirement in many customer applications. The Oracle database provides auditing components and features to enable notifications, so we can leverage these capabilities (versus building them) and simply ensure they are properly protected. Our next step is to determine which database object-owner accounts and objects will be created (or exist) to support the application itself. The use case we are examining is related to Sales Management, so there will certainly be a schema with database objects in it to support this use case. This research will typically be conducted with the assistance of a system or application database administrator, but for this book, we will look at the sample schemas. We see the Sales History (SH) schema has tables such as COSTS, SALES, PRODUCTS, PROMOTIONS, CHANNELS, and CUSTOMERS. So in simply examining one use case, “Add Monthly Product Costs,” we have uncovered new areas of concern related to security and compliance. If the COSTS information is of concern for SOX compliance, we can only assume the SALES information should be treated with the same level of concern. In addition, if we examine the CUSTOMERS table, we can see that privacy related information is being maintained in the organization’s databases and includes customer address, phone number, e-mail address, gender, marital status, and income data! If we examine the candidate realm Human Resources, we have to consider how identity management is handled at the enterprise and application levels. If a corporation is leveraging Oracle technologies such as EUS, it can integrate database authentication with LDAP-based directories, so our concern (at the database level) is more about protecting objects such as database roles used for EUS enterprise roles. We also need to consider that an enterprise may delegate the authentication against directories (or even database tables) to the application tier logic, leaving the database interactions to be based on a shared pool account using a design pattern named “application proxy.” For the purposes of this chapter, we will not discuss all the available authentication mechanisms in use across the industry. For this chapter, we will consider the Human Resources realm to comprise tables in the HR schema, as we can associate database accounts to employee-related records in this schema’s tables quite easily to resolve organizational affiliation, such as whether the logged in user works for a Sales Department. We want to address DBV security policy from the perspective of multiple object-owner accounts taking part in the example use case and leave it at that. When we examine the HR schema, we find tables such as EMPLOYEES and DEPARTMENTS that would be used in read operations for the example use case. In the case of the EMPLOYEES table, we have potential PII and privacy concerns, and our security profile even goes so far as to dictate requirements for column-level controls on data related to Social Security numbers, salary, and commission data that might be found in this table. Configure Standard Object-level Auditing for Realm-protected Objects At this point, we’ve uncovered a handful of security-relevant tables based on compliance and privacy criteria. In particular, the SH tables SALES and COSTS and the HR table EMPLOYEES fall into this category. For compliance and privacy concerns, or for mission-critical tables in general, we absolutely want to form a database auditing policy, even for database accounts that are allowed to access or manipulate the data stored in these tables. DBV will allow for the auditing of violations to the realm security policy, but we want to leverage normal/core RDBMS auditing to ensure that a database administrator can provide information sufficient to pass a compliance audit, which will need to include successful transactions as well as unsuccessful transactions. It is recommended that the following audit policy be applied to each sensitive table: Chapter 6: Applied Database Vault for Custom Applications 227 AUDIT SELECT ON <TABLE> BY ACCESS WHENEVER NOT SUCCESSFUL AUDIT INSERT ON <TABLE> BY ACCESS AUDIT DELETE ON <TABLE> BY ACCESS AUDIT UPDATE ON <TABLE> BY ACCESS AUDIT ALTER ON <TABLE> BY ACCESS AUDIT AUDIT ON <TABLE> BY ACCESS AUDIT COMMENT ON <TABLE> BY ACCESS AUDIT GRANT ON <TABLE> BY ACCESS AUDIT INDEX ON <TABLE> BY ACCESS AUDIT RENAME ON <TABLE> BY ACCESS This policy provides audit attribution for all write transactions to the sensitive tables as well as any security-relevant operations on the table such as GRANT, REVOKE, AUDIT, and NOAUDIT. Unsuccessful read attempts (SELECT) are captured and offer visibility to potential insider threats. Note that in the policy we do not recommend that you audit all successful SELECT commands against the sensitive table unless your regulations absolutely require each access to be audited. The reason for this omission is that for a heavily loaded system, with a large number of read transactions or a large number of users, the amount of audit data can become quite large. The amount of audit data does not really provide a lot of value unless compliance regulations or audits would need to know about each read transaction. It is important to consider applying this same table-based audit policy to database views as well. Many packaged database applications leverage PL/SQL stored procedures (packages, procedures, and functions), and you can ensure proper auditing of these program units using a policy similar to the following: AUDIT EXECUTE ON <PROCEDURE> BY ACCESS WHENEVER NOT SUCCESSFUL AUDIT RENAME ON <PROCEDURE> BY ACCESS AUDIT GRANT ON <PROCEDURE> BY ACCESS AUDIT AUDIT ON <PROCEDURE> BY ACCESS We have a situation with auditing successful EXECUTE operations similar to that with SELECTs on tables. We audit the successful EXECUTE operations only if compliance regulations dictate that this be done and the volume of audit data generated does not become unmanageable. Configure RLS on Realm-protected Objects As discussed in Chapter 5, Oracle DBV is geared to authorize commands against database objects, or statement-level security (SLS), versus an implementation for row-level security (RLS). As we have done with auditing, we need to examine the security-relevant tables based on compliance and privacy criteria to determine whether any RLS policies are required. Some environments demand absolute requirements for label-based controls, but in many environments, it’s up to the database administrators and developers how RLS requirements are defined, designed, and implemented. RLS is the best place to put the data security, because it keeps the security as close to the data as possible. In many cases, RLS requirements are implemented within the application tier and often require additional DBV security. DBV would protect the security-relevant data and packages on which the application relies to enforce the data security from the application. Not adding security is analogous to locking the front door of your house with a dead bolt and leaving your side gate open with the back door unlocked. In addition, if another application comes along that requires access to the same set of tables, you have to copy the existing source code and possibly retool the existing application. Whenever possible, use the advanced RLS features of Oracle Database to implement the security policy within the database. 228 Part II: Oracle Database Vault This analysis for RLS can be based on the conditions from our security profile. As we discussed in the section related to identifying DBV factors, our example security profile presents RLS examples based on the security profile conditions around the concept of “Weekly Maintenance Window” and “Product Ownership/Responsibility.” If we dig a little deeper into the conditions and the compliance-driven requirements these conditions impose, we see that controls are required on the visibility of end user Social Security numbers and salary information to the application. Oracle VPD’s fine-grained access control for security-relevant column masking meets these compliance- based requirements. NOTE Refer to David Knox’s Effective Oracle Database 10g Security By Design (McGraw-Hill, 2009) for a comparison between Oracle VPD and Oracle OLS. Oracle OLS is a more intuitive and declarative model to work with initially, while Oracle VPD has the flexibility to create and support more complex PL/SQL function policies that implement row-level security. Identify Accounts, Roles, and DBV Realm Authorizations from Use Case Actors If we look at our security profile syntax, we’ve defined what must be protected (the object), the commands or privileges we need to control (the verb), and how they need be protected (the conditions, based on compliance, application, and business rules), but we haven’t spent time describing who (the subject). To define the subject-level aspects of our security profile, we need to consider the entire set of use cases that make up our system and not just the Sales Management– related use case. If we consider the overall notional software architecture, we find actors such as sales data administrators, database administrators, batch program accounts, internal web service consumers, external (partner) web service consumers, and more subtlety accounts that will own objects and code. In Chapter 1, we introduced the concept of “schema profiles” that include object owner accounts user access accounts. The user access accounts included user profiles with read-only users, read-write users, application administrators/developers, and database administrators. We need to examine the actors in our use cases and classify them according to the profiles presented in Chapter 1. Next, we’ll create database roles and accounts for these actor classifications so we can associate a real database identity to each actor. Once this is done, we can authorize the appropriate role or account in the DBV realms we have identified. To help clarify the process, we will first look at the details of each profile’s relationship to DBV roles and concepts. We then present a detailed implementation example that demonstrates how the profiles might be constructed in DBV-enabled database. Secure Schemas Under DBV We first want to examine the actors in our notional software architecture to determine how they can be categorized using the profiles presented in the first chapter and understand how DBV may shape the form of those profiles in implementation. As we examine the profiles in more detail, you will discover that DBV helps enable the development of either a coarse-grained and fine-grained separation of duty model for some of the object owner and user access profiles. A fine-grained separation of duty model might be warranted in a system that contains highly Chapter 6: Applied Database Vault for Custom Applications 229 sensitive information or when compliance regulations are enforced. Let’s examine each profile in more detail to help clarify the approach to constructing these profiles as roles and accounts. Object-Owner Accounts In this section, we introduce two types of object-owner accounts: commercial-off-the-shelf (COTS) accounts that may be required by a software product and database application and system accounts that may used in batch (database) processing jobs. We will examine how these two types of object-owner accounts have common privilege models and how you can protect these accounts from being used in a manner in which they were not intended to be used. Group COTS or Application Account As discussed in Chapter 1, group accounts are installed with vendor commercial off-the-shelf (COTS) products that are rarely accessed by privileged database administrators to perform software maintenance: MDSYS for a spatial or SH account is an example in our use case. As discussed in Chapter 1, the SYS account falls into the category of a group account that is shared by many database administrators through access to an OS account’s credentials. Typically, the non-SYS account would be locked with the password expired and controlled by the account administrator as described next. The application account is typically granted a limited set of system privileges that enable the creation and maintenance of tables, views, and PL/SQL objects in its own schema. Note that DBV includes the role DV_REALM_ RESOURCE that can be leveraged to create application accounts. The role includes all the system privileges you’d find in the normal RESOURCE role with the addition of the CREATE VIEW and CREATE SYNONYM privileges. This role includes the following system privileges: CREATE CLUSTER CREATE INDEXTYPE CREATE OPERATOR CREATE PROCEDURE CREATE SEQUENCE CREATE SYNONYM CREATE TABLE CREATE TRIGGER CREATE TYPE CREATE VIEW CREATE SESSION System Accounts Oracle products and your own applications will leverage accounts that would never really be accessed by a database administrator if you are using the named user account pattern to maintain audit attribution to real end users. For example, Oracle Enterprise Manager (EM) uses the SYSMAN and DBSNMP accounts for statistics collection and runs this collection processing through a database job. Your own applications may have similar accounts that run on a scheduled basis as part of batch processing. This processing might leverage Oracle Secure External Passwords to interact with the database to load or extract database records. These accounts may own data tables, views, PL/SQL programs, and other objects that would be accessed ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 230 Part II: Oracle Database Vault by this account only under normal circumstances. It is a good idea to protect these objects with a DBV realm, in the same way objects owned by the SYSMAN and DBSNMP accounts are protected by the Oracle Enterprise Manager realm. These system accounts are typically associated with batch programs or database jobs, so the actual database access path is limited to the database servers running the database jobs or crontab processes. Batch programs might also be run from a set of servers that are physically located near the database servers (for example, the same racks), such as a finite set of external application servers. This is a great opportunity to leverage DBV factors as the building blocks for the DBV rule sets that control the realm authorizations or even the DBV CONNECT command rule for these system accounts. This approach can ensure that system accounts are used only under the appropriate conditions. To help illustrate this concept, consider the fact that the SH account’s objects are protected by the Sales History realm. We might create a SH_BATCH account for batch processing on PL/SQL objects owned by the SH account. We can then authorize SH_BATCH as a participant of this realm. You can use DBV factors and DBV rules to control the conditions that allow SH_BATCH to be authorized in this realm so that the authorization is valid only when issued from the database server (defined by the IP Address 192.168.0.251): create the batch account dbvacctmgr@aos>CREATE USER sh_batch IDENTIFIED BY <password>; User created. grant the appropriate system privileges to the batch account CONNECT / AS SYSDBA Connected. sys@aos>GRANT CREATE SESSION TO sh_batch; Grant succeeded. sys@aos>GRANT EXECUTE ANY PROCEDURE TO sh_batch; Grant succeeded. create the DBV Rule Set that uses DBV Factors to authorize the account in the realm under the conditions we want. CONNECT dbvowner Enter password: Connected. create a rule that we can use to limit realm authorizations to sessions running on the database server dbvowner@aos>BEGIN dbms_macadm.create_rule( rule_name => 'Is Client Connection From Database Server' , rule_expr => 'NVL(DVF.F$Client_IP,''0'') IN (''0'',''192.168.0.251'')' ); END; / PL/SQL procedure successfully completed. create the rule set to associate the rule to dbvowner@aos>BEGIN dbms_macadm.create_rule_set( rule_set_name =>'Sales History Batch Allowed', description => 'Checks to authorize batch commands for the Sales History realm.', Chapter 6: Applied Database Vault for Custom Applications 231 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. associate the rule to the rule set dbvowner@aos>BEGIN dbms_macadm.add_rule_to_rule_set ( rule_set_name => 'Sales History Batch Allowed' , rule_name => 'Is Client Connection From Database Server' ); END; / PL/SQL procedure successfully completed. define the realm authorization for this batch account that uses this rule set dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name => 'Sales History' , grantee => 'SH_BATCH' , rule_set_name => 'Sales History Batch Allowed' , auth_options => dbms_macutl.g_realm_auth_participant ); END; / PL/SQL procedure successfully completed. In this example, we have established these types of rules to ensure that system accounts, such as SH_BATCH, do not issue accounts from database client, such as an application server that hosts a web application. We expect database sessions for enterprise users to be established from these application servers and for them to issue a SELECT or DML command, but anything else, such as a SH_BATCH session, is an anomaly. Our goal to confine these privileged system accounts to known access paths helps reduce the attack surface of an exploit such as a password-cracking algorithm. User Access Accounts In this section, we examine categories for the User Access Accounts that were introduced in Chapter 1. User Access Accounts, which are used by many database applications, can be categorized as follows: System Access Accounts Enable a real end-user (person) to access database applications without requiring a real database account for each end-user. Read-only or Read-write Application Users that are dedicated database accounts for each real end-user (person). ■ ■ 232 Part II: Oracle Database Vault Database Administrator The person(s) whose job duties require him or her to connect to the database to maintain the database structure, database security, or the database applications that reside in a database. This section discusses how to identify these types of accounts within the use-case analysis paradigm we’ve discussed so far and how the Database Administrator type of account can be broken into a fine-grained separation of duty model. The section serves to lay the groundwork for the detailed separation of duty model example presented in the next section. System Access Account Oracle technologies such as proxy authentication and EUS require a real database account to serve as an intermediary between the database and a directory. These accounts are also not typically “directly” logged into but rather are used as part of a connection pool in application servers. The system access accounts are typically granted the privilege sets on objects they do not own and they are a form of the Read-only Application User or Read-write Application User profiles we will discuss next. Similar to the batch-program variety of system accounts, there are access path factors or other conditions that would define the “normal use” of these system accounts. The situation is reverse here, so we allowed database connections and authorized realm activity from the application servers hosting our web applications and disallowed the account usage from the database servers and backend infrastructure. Our notional database application environment has internal and external web service consumers. Suppose we are using EUS and the same directory server for authentication of employees and partners to these services; we can and should map the different base user trees to different global schemas (the system access account) since the privilege sets for the consumers may be different. Figure 6-2 depicts the mapping defined in the Oracle Enterprise Security Manager (ESM) for internal users to the global schema GLOBAL_INTERNAL. Figure 6-3 depicts the mapping defined in the ESM for external users to the global schema GLOBAL_EXTERNAL. ■ FIGURE 6-2 Enterprise Security Manager map for internal users Chapter 6: Applied Database Vault for Custom Applications 233 If the application servers that host the web services for the two different sets of users are different, we can then leverage this fact as a DBV factor to fine-tune the authorizations of SQL commands issued by these two global schemas. Suppose the application servers that serve (internal) employees have IP addresses of 192.168.0.100 and 192.168.0.101. The application servers that serve external partners have IP addresses of 192.168.0.50 and 192.168.0.101.51. We can create DBV rules to be used in authorizations for these system access accounts as follows: create a rule to authorize commands for an internal global system access account BEGIN dbms_macadm.create_rule( rule_name => 'Is Internal Web Service' , rule_expr => 'NVL(DVF.F$Client_IP,''0'') IN ' || '(''192.168.0.100'',''192.168.0.101'')' || ' AND DVF.F$Session_User = ''GLOBAL_INTERNAL''' ); END; / PL/SQL procedure successfully completed. create a rule to authorize commands for an external global system access account BEGIN dbms_macadm.create_rule( rule_name => 'Is External Web Service' , rule_expr => 'NVL(DVF.F$Client_IP,''0'') IN ' || '(''192.168.0.50'',''192.168.0.51'')' || ' AND DVF.F$Session_User = ''GLOBAL_EXTERNAL''' ); FIGURE 6-3 Enterprise Security Manager map for external users . as Oracle VPD, Oracle OLS, Oracle FGA, and database views. The implementation of factors as PL/SQL opens up these possibilities and just about any PL/SQL-based database feature such as database. David Knox’s Effective Oracle Database 10g Security By Design (McGraw-Hill, 2009) for a comparison between Oracle VPD and Oracle OLS. Oracle OLS is a more intuitive and declarative model to. and possibly retool the existing application. Whenever possible, use the advanced RLS features of Oracle Database to implement the security policy within the database. 228 Part II: Oracle Database