564 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence shared connection pool. Once the database knows who is running the query, it should be a simple matter of enabling database auditing. As you know, caching exists to speed performance, and it does this by eliminating redundant work. In our examples, this means redundant queries. The consequence is that when the caching feature of Oracle BI is enabled, it is possible that queries will sometimes be satisfied without even accessing the database. In such cases, there is nothing to audit in the database, because the database has done no work. This leaves three options. First, realize the limitation and understand that database auditing will work only when queries are actually sent to the database. This is not a bad option, however, an audit record of the first query (meaning the query that generated the cache entry) will exist, so it’s not as if data can be viewed without your knowledge—you simply won’t know everyone who looked at it. Second, turn off caching and force all queries to the database. This will ensure auditing for all access by all users all the time but negates any performance enhancements to the application as well as the benefits of allowing the database to do other work instead of returning these (redundant) queries. Third, combine the auditing that the BI server does with the auditing that the database does. This option, depicted in the following illustration, is discussed in the next two sections. Usage Tracking The usage tracking feature of the Oracle BI enables you to capture information about your environment that can be used for a variety of purposes: Tracking actual performance data Often performance data is conveyed through vague references to dashboards being slow. Usage tracking provides actual facts on how long queries take, where the time is being spent (database or BI server), and cache hit information. Not only can this provide useful performance information, but it can help you figure out what queries need to be tuned. ■ Chapter 14: Securing Oracle BI Content and Data 565 Tracking who is doing what from a security perspective Usage tracking will record every logical SQL statement issued by a user. This is the logical SQL issued against the BI server and not the physical SQL sent to the database. The only place to find the physical SQL is in the BI server query logs or in the database audit logs. Tracking who is doing what from a content perspective Usage tracking records which subject areas and dashboard pages are being queried. You can see the most commonly used subject areas and dashboards. This can be useful in figuring out where development resources should be focused. Usage tracking is documented in the Server Administration Guide of the Oracle BI Documentation Library (www.oracle.com/technology/documentation/bi_ee.html). The content captured in usage tracking is very well documented. The following steps represent a few additional notes on configuring usage tracking: 1. Create the usage tracking table. The SAACCT.*.sql script (use the one appropriate for your database) is located in the OracleBI_HOME/server/schema directory. This directory also contains scripts for setting up Oracle Delivers and Oracle BI Marketing. 2. Create a time dimension. The scripts for this are located in the OracleBI_HOME/server/ Sample/usagetracking/SQL_Server_Time directory. Note that scripts are included for multiple databases in this directory and not just SQL Server. This will create and populate two tables: One table includes date information that extends from year down to the day. The other table is a dimension that includes all minutes in a 24-hour period. 3. Merge the usage tracking repository with your production repository. The usage tracking RPD can be found in the OracleBI_HOME/server/Sample/usagetracking directory. 4. Merge the usage tracking web catalog with your production web catalog. The usage tracking web catalog is found in the same location as the usage tracking RPD. 5. Configure the BI server to use usage tracking. This configuration change is done in the NQSConfig.ini file. An example of how to configure this is included in the comments of your default configuration file. NOTE Two important points about using usage tracking: First, this information is useful as a security tool. As such, read and write access to this information should be restricted to those with a need to know. Second, the usage tracking table will grow quite rapidly. You will need to monitor this and steps will need to be taken to manage the size of this table (such as partitions, archiving). Database Auditing The Oracle database has very robust auditing capabilities. When used properly, organizations have gleaned tremendous information about who is getting access to what, from where, when, and how. This section provides some basic insight into how Oracle database auditing can be used in conjunction with Oracle BI. Three basic steps are involved: 1. Verify that database auditing is enabled. Validating that the database is set up to audit is as simple as checking the value for the AUDIT_TRAIL parameter. The appendix of this book covers the details on how to check whether auditing is enabled and how to enable ■ ■ 566 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence it. The examples provided on the Web have the AUDIT_TRAIL set to DB_EXTENDED so that the physical SQL statements are captured. 2. Start auditing. Auditing can be done in various ways, and two possibilities work well for Oracle BI. You could audit all select statements on a specific table, or you could audit all queries issued by a specific user (the shared connection pool user in this case). 3. Convey the end user’s identity to the database, as described earlier in this chapter. NOTE Database auditing is transparent to Oracle BI as well as to any application. The database will audit any SQL statement that the BI server sends to the database that matches the audit criteria. It’s worth mentioning again that if the BI server is caching, not every user query will be sent to the database. If the BI server cache can satisfy the user query, it will do so without bothering the database. To get a complete picture of what the end user is accessing, you should enable both usage tracking and database auditing, as discussed next. Combining Usage Tracking and Database Auditing Usage tracking and database auditing are by default two completely independent features. You can enable one or both of them and they act independently of one another. However, as mentioned, to get a complete view of what a user is doing, you can use both features simultaneously and combine the output. The easiest way to combine this data is to expose the database audit trail via Oracle BI. The database audit trail can be modeled in the BI server metadata just like any source. This can then be combined with the usage tracking metadata. Combining data sources with Oracle BI can be done in a number of different ways. You could combine the two data sources in the business model layer of the BI server metadata. This would allow the BI server to present these two data sources as a single subject area. This technique requires a clear means of joining the data from the two different sources. Another way to combine multiple data sources is to merge the data at the answers request or dashboard level. Using this method, data from two or more sources could be displayed together on one dashboard page. Dashboard prompts can be used to link the information from the different sources. In the examples provided on the Web, usage tracking and the database audit trail were modeled as two separate subject areas. The information was then merged on the dashboard by including reports from both subject areas, filtered by the same prompt. Figure 14-20 shows usage tracking and database audit information for user BIPRODUCT1. Usage tracking and the database audit trail were modeled separately and combined at the dashboard layer for two reasons. First, this satisfies the requirement of being able to analyze both usage tracking and database audit information at the same time. To make this work, the column being filtered by the dashboard prompt must be named the same in each subject area. In this example, the dashboard prompt is filtering the column User Name. In the BI server metadata, the column User Name maps to the physical column LOGON in the usage tracking schema and CLIENT_ID in the database audit trail. The second reason for modeling this as two subject areas is that modeling these two data sources as a single subject area could prove challenging for the following reasons: Not every logical SQL statement logged in usage tracking will generate a physical SQL statement captured in the database audit trail. ■ Chapter 14: Securing Oracle BI Content and Data 567 One logical SQL statement logged in usage tracking may generate multiple physical SQL statements in the database audit trail (multi-pass SQL, query fragmentation, or aggregate navigation). Usage tracking records access to the logical table accessed in the subject area and the database audit trail records access to physical tables in the database. To join these, it would be necessary to capture the relationship between logical tables in subject areas and physical tables in the database. In conclusion, to get a complete audit record, you need to use a combination of Oracle BI Usage Tracking and the Oracle Database Auditing. Usage tracking records what is accessed at the logical level and database auditing captures what is accessed at the database level. BI Features with Security Implications A number of features of Oracle BI should be examined from a security perspective. Using these features does not imply a security risk. It is important that you understand exactly what each feature does and what it means from a security perspective. Managing access to features is done via the web using the Manage Privileges screen on the Administration page. The first section of this screen allows you to control access to major applications within the suite. Just as you would with any other system, you turn off access to anything that is not explicitly required. Most features are fairly self-explanatory. Features requiring special attention are covered here. Default Privileges As is the case with any product, you should carefully examine the default security setup upon installation. In both the BI server and the presentation server, there are a number of things granted to Everyone. As mentioned, these permissions should be carefully analyzed to see if everyone really ■ ■ FIGURE 14-20 Usage tracking and database audit information combined on a single dashboard 568 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence needs that functionality. As we go through the following sections, we will discuss many of these features in detail. Here are a few changes that you should consider making immediately: Revoke access to products from Everyone and grant access only when needed. By default, everyone has access to Oracle Answers, Oracle Delivers, Oracle BI Publisher, and Oracle Disconnected Analytics. Revoke access to the Advanced tab in Oracle Answers. Revoke the ability to issue direct database requests. You can also make a configuration change at the BI server to help with appropriately setting default privileges. You can control the default privileges set on presentation catalogs in the RPD. This is done by setting the configuration option titled DEFAULT_PRIVILEGES. This parameter can be set to NONE or READ. By default, it is set to READ. When in this mode, each new presentation catalog is readable by everyone by default. To change this behavior, set the value to NONE. Act as Proxy Oracle BI can let users run a request on behalf of someone else. This feature is designed primary for two reasons. First, it allows and end user to delegate functionality to someone else. For example, a manager might be going on vacation and wants someone else to be able to run her reports while she is gone. The second possible use is for developer or administrators to test running reports using someone else’s permissions. To keep things clear in this section, we will refer to the user running reports for someone else as the “proxy user.” We will refer to the impersonated user as the “target user” (this is the same notation used in the documentation). In this section, three topics are covered: The actual permissions that the proxy user gets when running reports for someone else The steps required to set up and maintain this feature The impact on usage tracking, database logs, and database security A Proxy User’s Permissions When a proxy user requests that things are “run as” the target user, the proxy user gets one of two possible sets of privileges: full or restricted. This is called the proxy level. With restricted proxy level, the proxy user gets read access to everything the target user can see but does not get the privileges of the proxy user. Let’s assume that a manager has granted restricted proxy permissions to a subordinate. The employee can now see all the reports and data that the manager can see. However, the employee will still maintain his normal privileges. So if the manager had access to Oracle Dashboards and Oracle Delivers and the employee had access only to Oracle Dashboards, the employee will still be able to run only Oracle Dashboards. On the other hand, if the manager had granted full proxy permissions, the employee would get all of the manager’s permissions and privileges. If a proxy level is not specified, it is set to restricted by default. Enabling Act as Proxy Functionality Several steps are required to set up this functionality. First, you need to set up the database infrastructure to support it. Oracle BI does not contain the facilities for storing the allowed proxy users and the associated proxy levels. This must be stored and maintained in a database table ■ ■ ■ ■ ■ ■ Chapter 14: Securing Oracle BI Content and Data 569 external to Oracle BI. The table must contain three columns: PROXYID, TARGETID, and PROXYLEVEL. Note that since this table dictates the proxy arrangement—that is, which user can assume privileges of which other user—you need to ensure tight security controls on this table. Next you need to modify the BI server. Two session variables must be set: PROXY and PROXYLEVEL. When you create these variables, you will get a notification that these variables have special purposes. This is exactly what they were designed for. Both of these variables are considered security-sensitive by default, meaning their values cannot be modified from the Web even if you forget to mark the Security Sensitive checkbox. Here is a sample initialization block for PROXY: SELECT targetid FROM bi_proxy.Proxies WHERE 'VALUEOF(NQ_SESSION.RUNAS)'=targetid AND ':USER'=proxyId Here is a sample initialization block for PROXYLEVEL: SELECT proxylevel FROM bi_proxy.Proxies WHERE 'VALUEOF(NQ_SESSION.RUNAS)'=targetid AND ':USER'=proxyId Notice the use of the session variable RUNAS. This will get defined and populated by the presentation server when the user initiates the Run As process from the settings menu on the Web. Lastly, you need to modify the presentation server. To do this, you first create an XML file in the $OracleBI_HOME\web\msgdb\customMessages folder. You can call the file anything you want. This file defines what will show up in the Run As screen for the given user, and it needs to contain the following information: <?xml version="1.0" encoding="utf-8" ?> <WebMessageTables xmlns:sawm="com.siebel.analytics.web.messageSystem"> <WebMessageTable system="SecurityTemplates" table="Messages"> <WebMessage name="LogonParamSQLTemplate"> <XML> <logonParam name="RUNAS"> <getValues>EXECUTE PHYSICAL CONNECTION POOL “Security Information".bi_security_select select targetid from bi_proxy.proxies where proxyid='@{USERID}' </getValues> <verifyValue> EXECUTE PHYSICAL CONNECTION POOL “Security Information".bi_security_select select targetid from bi_proxy.proxies where proxyid='@{USERID}' and targetid='@{VALUE}' </verifyValue> <getDelegateUsers>EXECUTE PHYSICAL CONNECTION POOL “Security Information".bi_security_select select proxyid, PROXYLEVEL from bi_proxy.proxies where targetid='@{USERID}' </getDelegateUsers> </logonParam> 570 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence </XML> </WebMessage> </WebMessageTable> </WebMessageTables> Notice a couple of interesting things in this file. First is the name of the web message: LogonParamSQLTemplate. This will be referenced in the instanceconfig.xml file shortly. Second, notice that the session variable title RUNAS is defined and will be populated with the targetid value that the user selects. Next, modify the instanceconfig.xml file so that this custom web message will be loaded. Add the following lines: <LogonParam> <TemplateMessageName>LogonParamSQLTemplate</TemplateMessageName> <MaxValues>100</MaxValues> </LogonParam> MaxValues refers to the maximum number of users that will be shown in the drop-down list. The final step is to make sure that you enable the Web privilege that allows a user or group of users to use the Act as Proxy functionality. By default, no one is allowed this privilege. As you can see from Figures 14-21 and 14-22, once the Web privilege is enabled, you will get a new option on the settings menu and a list of Act As users will be populated from the database table you created. The examples shown in this section are included on the Downloads page at www. OraclePressBooks.com. See the section in the appendix titled “Internal Authentication with Act As Proxy Enabled” for information on using this example. Act as Proxy Impact on Security To help you understand the implications of using this feature, let’s use some of the techniques developed in Chapter 13 to explore what happens when a user acts as another user. First, you inspect the USER and GROUP session variables and notice that they actually change to the target user and the target user’s groups. This is easily accomplished using the Utilities Dashboard in the examples included on the Web. This has a major impact on all things security related. In addition, all session variables are repopulated as though the target user had logged onto the system. This means all business model filters will now be applied as if the target user were actually logged onto the system. Recall that we set the Client Identifier in the connection pool DB session to convey that the end user’s identity to the database will send the target ID only to the database. The database will then apply VPD policies for the target ID, and all audit trails will reference only the target user. This is a good thing, because all security policies, both BI server–enforced and database-enforced, are being applied to the target user. It is worth noting that, from the database’s perspective, FIGURE 14-21 Act As Proxy functionality enabled Chapter 14: Securing Oracle BI Content and Data 571 everything was done by the target user. It does not know that a proxy user is actually issuing queries on behalf of the target user. In contrast, the BI server does record the fact that the Act As Proxy functionality is being used. If you take a look at the usage tracking, you will notice that the proxy user value is saved in the USER_NAME physical column and the target user value is saved in the RUNAS_USER_NAME physical column. This is very useful because it shows the true picture of what happened: the proxy user ran the query acting as the target user. Figure 14-23 shows both the proxy user and the target user recorded in the usage tracking logs after running the examples found at www .OraclePressBooks.com. The presentation layer column User Name corresponds to the physical column USER_NAME, and the presentation layer column Impersonated User corresponds to the physical column RUNAS_USER_NAME. Direct Database Requests The basic architecture of Oracle BI is designed to push all requests through the BI server and leverage the metadata defined there. However, it is possible to make direct database requests. This is a feature that is disabled by default and should be evaluated very carefully before being enabled. Direct database requests allow the user to enter a physical SQL statement via the Web. This statement is then sent directly to the database for execution. FIGURE 14-22 The user biadmin running reports as the user biproduct1 FIGURE 14-23 Proxy and target user shown in usage tracking 572 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Before we discuss the steps required to enable or disable direct database requests, it is worth examining the impact of doing so. Forcing the query through the BI server does a number of things: Joins the tables as defined in the metadata Groups and aggregates the data as defined in the metadata Applies appropriate row- and column-level security as defined in the metadata Allowing the user to issue direct database requests lets the user bypass all security and business rules that have been defined in the BI server metadata. Three major components must be enabled before a direct database request can be issued: The database definition in the BI server metadata must allow direct database requests. The presentation server privilege Edit Direct Database Requests must be enabled. The presentation server privilege Execute Direct Database Requests must be enabled. You can configure a database to allow direct database requests in the BI server metadata in two ways: You can check the Allow Direct Database Requests By Default checkbox, as shown in Figure 14-24, to enable direct database requests for all users against that database. Or you can enable direct database requests in the BI server metadata for a specific group. As shown in Figure 14-25, you do this in the Query Limits tab of the Group Permissions dialog box in the Administrator tool. For each group and database, you can specify whether direct database requests are ignored or allowed. ■ ■ ■ ■ ■ ■ FIGURE 14-24 Enabling direct database requests for all users Chapter 14: Securing Oracle BI Content and Data 573 After direct database requests are enabled in the RPD, two presentation server permissions must be enabled: a permission allowing users to edit or create direct database requests and a permission allowing users to execute answers requests based on direct database requests. These permissions are located under the Answers section on the Manage Privileges web page, as shown in Figure 14-26. At the beginning of this section, the reasons for avoiding direct database requests were presented. At some time, you may need to use this feature, and the ability to separate the privileges associated with editing and executing direct database requests is very useful. As shown in Figure 14-26, Presentation Server Administrators are the only users allowed to create or edit a FIGURE 14-25 Enabling direct database requests by group FIGURE 14-26 Enabling direct database requests in the presentation server . IV: Applied Security for Oracle APEX and Oracle Business Intelligence shared connection pool. Once the database knows who is running the query, it should be a simple matter of enabling database. the database. In such cases, there is nothing to audit in the database, because the database has done no work. This leaves three options. First, realize the limitation and understand that database. really ■ ■ FIGURE 14-20 Usage tracking and database audit information combined on a single dashboard 568 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence needs that