114 Part II: Oracle Database Vault executed by the SYS account or enabling OS authentication, changing the database dump destinations. A complete list of security sensitive database initialization parameters that are protected follows: ■ 07_DICTIONARY_ACCESSIBILITY ■ _dynamic_rls_policies ■ _system_trig_enabled ■ audit_file_dest ■ audit_sys_operations ■ audit_syslog_level ■ audit_trail ■ background_core_dump ■ background_dump_dest ■ background_dump_dest ■ control_files ■ core_dump_dest ■ core_dump_dest ■ db_create_file_dest ■ db_create_online_log_dest_1 ■ db_create_online_log_dest_2 ■ db_create_online_log_dest_3 ■ db_create_online_log_dest_4 ■ db_create_online_log_dest_5 ■ db_recovery_file_dest ■ job_queue_processes ■ max_dump_file_size ■ optimizer_secure_view_merging ■ os_roles ■ plsql_debug ■ recyclebin ■ remote_os_roles ■ shadow_core_dump ■ sql92_security ■ user_dump_dest ■ user_dump_dest ■ utl_file_dir Another control that is installed by DBV is the restriction that a database superuser account cannot modify the DBV policy using the DBMS_MACADM PL/SQL package or even grant the account the roles DV_OWNER or DV_ADMIN to use this package. system@aos> attempt to use the DBV administration package system@aos> using SYSTEM, the default Oracle DBA system@aos> to remove the DBV Realm for the database itself system@aos>BEGIN dvsys.dbms_macadm.delete_realm_cascade('Oracle Data Dictionary'); END; / dvsys.dbms_macadm.delete_realm_cascade('Oracle Data Dictionary'); * ERROR at line 2: ORA-06550: line 2, column 8: PLS-00904: insufficient privilege to access object DVSYS.DBMS_MACADM ORA-06550: line 2, column 2: PL/SQL: Statement ignored system@aos> attempt to grant the DBV owner role to SYSTEM which system@aos> would offer control over the DBV policy configuration system@aos>GRANT dv_owner TO system; GRANT dv_owner TO system * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant role privilege on DV_OWNER. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 With this triad of database administrators (security, account, and DBA) and the separation of duty that is created with the DBV installation, an enterprise can immediately operate with checks and balances to help meet whatever compliance regulations are required. Chapter 4: Database Vault Introduction 115 Default Audit Policy The Oracle DBV installation includes a comprehensive database audit policy designed to audit commands and activity related to DBV’s DVSYS and DVF accounts and the OLS product account LBACSYS. This policy ensures that any changes (or attempts to change) to the configuration data for these two products is captured. Any subversive commands such as NOAUDIT, REVOKE, and RENAME against these object-owning accounts are also capture by this audit policy. The installation also includes a comprehensive audit policy for the database as a whole that audits the following categories of database activity: Session login and logoff Privilege management, such as GRANT and REVOKE commands Database Account Management, such as CREATE, ALTER, and DROP USER commands Audit Policy, such as AUDIT and NOAUDIT commands Structural Changes, such as tablespace management and object management with command syntax such as CREATE <object>, ALTER <object>, and DROP <object> Use of privileged commands including o ADMINISTER DATABASE TRIGGER o ALTER SESSION o ALTER SYSTEM o BECOME USER o Flashback o FORCE ANY TRANSACTION o Restricted database sessions o Use of system *ANY privileges o Table truncation This audit policy was developed from research conducted by leading government and commercial authorities on computer security that continuously publish up-to-date recommendations on this subject. The protection of the DBV and OLS configuration was then added to this policy to audit these security-relevant features by default. Default Security-relevant DBV Factors The DBV installation creates a number of DBV factors that an enterprise may find useful for developing custom DBV rule sets to control DBV command rules, DBV realm authorizations, and DBV secure application roles. The installed factors can be categorized as follows: Database and instance information Database client network protocol Database client language Enterprise user information Session authentication information ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 116 Part II: Oracle Database Vault Summary: Database Vault Is Differentiating Security In our efforts to create a richer summary section, we thought it would be good to place the summary in a discussion context. As with some security capabilities in the past, people will often believe that they have created a security approach that is equal to DBV but that is implemented through some other clever set of (database) technologies. Also similar to historical truth, they are misguided, and it’s important to understand this so that you, too, don’t try to build your own database vault. To some degree, this is a buy-versus-build discussion. In the next few paragraphs, we’ll tell you why DBV is not only unique in what it does, but unique in how it does it. You cannot build an equivalent database vault—even if you could, the costs in doing so would far outweigh the costs of purchasing DBV from Oracle. One of the early ideas for creating a DBV used triggers. DML triggers, and in particular DDL triggers, can be set to fire for a large number of commands. Conceptually, this is similar to the concept of command rules. The big difference, however, is that DBV is protected from nefarious or unwitting actions even by administrators. Triggers were not designed or intended to be used as security mechanisms. Changing trigger code, disabling a trigger, and dropping a trigger can be performed by any user with the ALTER ANY TRIGGER or ALTER ANY TABLE system privilege. Although DBV “uses DBV to secure DBV,” the security starts before you get to the database tables and PL/SQL code. The security starts in the database kernel, as the DBV exists as a code linked into the Oracle binaries. The importance of binary execution is that, unlike triggers that are implemented in PL/SQL, you are unlikely to see the source code or be able to modify it. The code that is linked into the Oracle binaries supports the numerous commands you will find in the “Oracle SQL Language Reference” and has undergone countless hours of regression testing with each database release. This gives you higher assurance that it has not been tampered with. As you saw when reviewing the installation of DBV, the core DBV controls are in a protected schema. Even SYS is unable to tamper with DBV. The other differentiators for DBV come with its approach to implementation. The declarative framework is at its core. The invaluable security validation and verification capabilities are possible through the use of the framework. This has been an absolute necessity for getting the security implemented and approved for operational production systems in very secure environments. Transparency has also enabled DBV to succeed. In Chapter 1, you learned about the importance of transparency, and DBV has enabled this by tapping into the DB kernel. The result is that you can almost always enable DBV for an application and get things working in a more secure manner than ever before. Simply add your objects of interest to a realm, add the right users as realm participants or realm administrators, and you are on the right track. This is simple to do and definitely increases your security with very little or no effort. Perhaps the most impressive statement about DBV is that it addresses security by taking an innovative approach to governing who gets access to what, where, when, and how. Conditional security can be based on factors chained together in reusable rule sets and allows you to create a myriad of realistic and useful security controls. The factors are based on things you know or can validate. They allow you to ensure that security is happening the way it’s supposed to be happening. The ability to use multiple factors significantly increases the security of your access decisions. The adaptive nature of the framework and the rules not only allow extensibility to your security, but they allow it to grow and shrink based on values that can be determined at runtime. In the next two chapters, you will see several examples of how to apply DBV to applications. You’ll not only see how to get it set up and working, but you’ll learn how to blend design patterns. This will not only give you a jump start on using the technology, but it will also help you solidify DBV concepts and your understanding of when and how to use it. CHAPTER 5 Database Vault Fundamentals 117 118 Part II: Oracle Database Vault his chapter presents a collection of examples that demonstrate the fundamentals behind how DBV components are configured using the DBMS_MACADM API. The examples are built around the Sales History (SH) object-owner account included with Oracle Database’s sample schemas. These examples cover the following component configurations and demonstrate how these components’ configurations impact sessions trying to access objects owned by the SH accounts: Realms Provide boundaries around the use of system ANY privileges that administrators typically have been granted. Realms examples demonstrate how you can meet your organization’s compliance and consolidation requirements. Command rules Protect the use of more than 100 commands in the “Oracle SQL Reference Guide.” Command rules allow you to implement security policies based on the business rules maintained by your organization. Rule sets Serve as the library rules for your security policy engine. We examine the impact of rule evaluation semantics, auditing and how custom event handler mechanisms can be enabled in response to DBV enforcement events. Factors Fundamental security policy attributes you define that form the building blocks for DBV rule expressions and result in a multifactored security policy. Example of factors linked into policies for Oracle Label Security (OLS) and Oracle Virtual Private Database (VPD) are also presented. Secure application roles Allow you to control the enablement of the more sensitive privilege sets using business or application rules defined by your organization. Realms A realm is a new security layer that provides containment and eliminates inadvertent access based on system ANY privileges. System ANY privileges are required for many application and administration scenarios. These privileges are heavily used in operating a database, but the privileges have no boundaries and therefore must be restricted. The security gap exists between the database objects controlled by object privileges and the system controlled by system ANY privileges. Realms were designed as a security mechanism that establishes boundaries around a set of objects that limit the use of system ANY privileges to authorized realm users or roles. Therefore, any attempt to access a realm protected object by an unauthorized user with system ANY privileges will be blocked and raise a realm violation. Access based on object-level privileges are not considered inadvertent and therefore are not enforced by the realm. Object- level privileges are explicit permissions on individual objects that can be verified through database dictionary views. Realms are a simple and critical security measure that address many of the issues we face today regarding compliance and separation of duties for different job responsibilities. They also serve as an affective defensive measure for cyber security by limiting the extent to which system privileges can be exploited by an attacker. Therefore, realms not only provide another layer of security, but they add another level of defense. DBAs who are responsible for the health and well-being of production databases should consider the serious nature of realm violations, either legitimate or not. For example, an application needing additional accesses is legitimate and a malicious attempt to access data within the database is not. ■ ■ ■ ■ ■ T Chapter 5: Database Vault Fundamentals 119 In Chapter 4, we suggested that realms could be used to protect the security mechanisms that are protecting your application. We know many customers have leveraged the existing database security technologies and other database mechanisms, such as triggers, views, and PL/SQL, to implement application security within the database. Perhaps you have read David Knox’s Effective Oracle 10g Database Security by Design that serves as one of the best foundations for implementing good security practices in an Oracle database. Security threats and challenges continue to surface every day and require that you update our security design and implementation on an ongoing basis. Therefore, simply maintaining an existing security approach can lure you into a false sense of security, which effectively decreases your security posture and increases your risk over time. TIP Realm access = DB ANY privilege + Realm authorization. Applying realms to existing security approaches increases your security posture and reduces your risk if you perform these simple steps: 1. Protect the data tables by adding them to a realm. 2. Protect security relevant objects by adding them to a realm. This includes PL/SQL procedures for VPD, PL/SQL procedures that perform trusted transactions, and application database roles. Also consider the intent of any realm violation you encounter. A realm violation will occur if A new login session is created or an existing one is highjacked; Key privileges are available or new privileges are gained; Attempted access of a realm-protected object is determined to be unauthorized. Without DBV, the attempted access cannot be easily detected or blocked. Realms allow application access paths and profiles to be contained and controlled. It also allows for a system administrator or administrators to be better governed using both a context-based and a data content security model. Realms allow you to govern security by the data semantics themselves. Database administrators should consider the use of realms in production systems to update their database security to meet today’s security challenges. A good example of a need for security is personally identifiable information (PII). Within DBV realms, you can establish boundaries and controls over PII at a either the database schema level or an object level. Likewise, you can segment data as financials, personal health information, Sarbanes Oxley Act (SOX), and so forth across database schemas, so that your realm covers many objects over several database schemas. With realms for consolidation of IT resources and data, you can meet security for compliance and insider threat concerns, along with data integration for consolidation objectives. Security should not be the primary excuse for not consolidating data into a fewer common databases. Consolidation will clearly add more value to the processing of data that is usually transacted and queried together. Consolidation will reduce operations and maintenance costs associated with multiple systems and offers these primary benefits: Increased data availability with a reduction in the labor, power, and storage requirements to increase this availability ■ ■ ■ ■ 120 Part II: Oracle Database Vault Enhanced and centralized enterprise security that accounts for regulatory compliance controls Universal access to data across the enterprise, without inefficient data movement Reduced inconsistencies due to fewer instances of data duplication Simplification of the security management of your Oracle database and applications as centralized policies are not coded into each application. To demonstrate how we meet these objectives for consolidation, consider the sample schemas that are available with Oracle Database. The samples include the following schemas (a partial list): Human Resources (HR) Order Entry (OE) Sales History (SH) In many enterprises, this type of data is kept in separate databases and on separate servers. This data as shown Figure 5-1. ■ ■ ■ ■ ■ ■ FIGURE 5-1 Preconsolidation databases Chapter 5: Database Vault Fundamentals 121 When viewed this way, it is easy to see the costs associated with maintaining these databases with respect to the power consumption, hardware costs, labor costs, software license costs, and recurring maintenance fees. With consolidation efforts in an enterprise, you can reduce the costs by hosting the databases on a shared server platform with a smaller number of administrators, as shown in Figure 5-2. The challenge in this consolidated database architecture then becomes how to keep database administrators of the Human Resources (HR) data from accessing or manipulating the Sales History (SH) data, or vice versa. To demonstrate, log into the database using the SYSTEM account, a well-known Oracle database account. The SYSTEM account has been granted the powerful DBA role and that role is granted many ANY privileges for TABLE objects: system@aos> Display the system (ANY) privileges the account has system@aos>select privilege name from session_privs where privilege like '%TABLE%' or privilege like '%GRANT%' order by 1; NAME ALTER ANY TABLE ALTER TABLESPACE BACKUP ANY TABLE COMMENT ANY TABLE CREATE ANY TABLE CREATE TABLE CREATE TABLESPACE DELETE ANY TABLE DROP ANY TABLE DROP TABLESPACE FLASHBACK ANY TABLE GRANT ANY ROLE GRANT ANY PRIVILEGE FIGURE 5-2 Consolidated databases 122 Part II: Oracle Database Vault GRANT ANY OBJECT PRIVILEGE INSERT ANY TABLE LOCK ANY TABLE MANAGE TABLESPACE SELECT ANY TABLE UNDER ANY TABLE UNLIMITED TABLESPACE UPDATE ANY TABLE 18 rows selected. system@aos> Attempt to query the sales data using system@aos> the SELECT ANY TABLE privilege system@aos>select cust_id, amount_sold from sh.sales; CUST_ID AMOUNT_SOLD 1258 23.75 1714 23.75 1842 23.75 system@aos> Grant object privileges on the table system@aos> to another account system@aos>grant select on sh.sales to scott; Grant succeeded. system@aos> Attempt to query the sales data using direct object system@aos> privileges granted to the account SCOTT 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 As you can see, the SYSTEM account has privileges not only to read or write the Sales History data using privileges such as SELECT ANY TABLE and UPDATE ANY TABLE, but the account can modify the structures in which the data is stored using a privilege such as ALTER ANY TABLE. The same types of system ANY privileges are usually granted to named database administrator accounts, providing the same unbounded access to application data. We must introduce a DBV realm around the SH and HR schemas to enforce the separation of duty and mitigate compliance concerns over unprotected access to PII or the integrity of financial numbers used in an audit. Realm Protection Patterns A DBV realm can be defined as a boundary around all the objects in a database schema, a subset of objects in a database schema, or a collection of objects in multiple schemas. These example usages are shown in Figure 5-3. Chapter 5: Database Vault Fundamentals 123 In Figure 5-3, a realm may be defined for objects in several schemas to support the concept of an order management application. The application may use a privileged account to access sensitive customer purchasing information and PII information for employees. In Figure 5-4, you can see a realm was created for a subset of the HR schema, where tables such as EMPLOYEES and EMP_DETAILS_VIEW can contain PII information and tables such as JOBS and JOB_HISTORY can include personal information such as an employee’s salary. In Figure 5-5, an entire Sales History schema is protected and may contain sensitive information used for SOX compliance and auditing. FIGURE 5-3 Order Management realm (subset of object owner’s objects) FIGURE 5-4 Human Resources realm (multiple objects, multiple object owners) . categories of database activity: Session login and logoff Privilege management, such as GRANT and REVOKE commands Database Account Management, such as CREATE, ALTER, and DROP USER commands Audit. for developing custom DBV rule sets to control DBV command rules, DBV realm authorizations, and DBV secure application roles. The installed factors can be categorized as follows: Database and. expressions and result in a multifactored security policy. Example of factors linked into policies for Oracle Label Security (OLS) and Oracle Virtual Private Database (VPD) are also presented. Secure