Applied Oracle Security: Developing Secure Database and Middleware Environments- P60 potx

The only place to find the physical SQL is in the BI server query logs or in the database audit logs.. Figure 14-20 shows usage tracking and database audit information for user BIPRODUC

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

■

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

■

■

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

■

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

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

■

■

■

■

■

■

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>

</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

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

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

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