Applied Oracle Security: Developing Secure Database and Middleware Environments- P61 ppt

In summary, the ability to execute a direct database request must first be enabled at the database level inside the RPD.. Then, at the presentation server, users must be granted permissi

direct database request, and member of the SH Users group are the only users allowed to execute the request This allows the members of SH Users to run direct database requests without granting them permission to create these types of requests This segregation of duties allows for a very controlled use of the privilege

An example of a direct database request is included in the dashboards found on the Downloads page at www.OraclePressBooks.com The Channel Managers tab of the SH dashboard has two requests that are based on direct database requests Figure 14-27 shows one of these requests This tab was designed to show data with VPD policies being enforced As you saw earlier in the chapter, an important step is conveying the end user’s identity to the database In this example, to verify that the database was aware of the true end user, I wanted the BI Server to issue the query

select syscontext(‘USERENV’,’CLIENT_IDENTIFIER’) from dual.

In summary, the ability to execute a direct database request must first be enabled at the database level inside the RPD Then, at the presentation server, users must be granted permission

to edit or execute direct database requests These permissions should be enabled with great care, because you are opening additional access to your backend data sources

Advanced Tab

When you decide to give users access to Oracle Answers, you should evaluate several features within Answers, including the ability to set system-wide formats for columns The general user should not have the ability to do this, because it would affect the look and feel of all reports By default, only Presentation Server Administrators are granted this permission

Another Answers feature that you should evaluate is ability to use the Advanced tab By default, this tab is available to any user that has access to Answers This should be changed Only Presentation Server Administrators and advanced developers should have access to this tab One reason for turning off access to the Advanced tab for general ad hoc query users is that they probably don’t need it and it might confuse them Another reason is because you can perform operations that the general user should not be allowed to do

FIGURE 14-27 An example of a direct database request

Chapter 14: Securing Oracle BI Content and Data 575

The Advanced tab contains the following capabilities:

Directly edit the XML definition of a report

Directly edit the logical SQL of the report

Bypass the presentation server cache

Bypass the BI server cache The BI server cache can be bypassed by including the

statement set variable DISABLE_CACHE_HIT=1; in the Prefix box on the Advanced tab.

Turn on logging This is also very useful for developers and administrators and is

discussed in the “Testing the VPD Example” section

Set session variables values

Session variable values can be set using the set variable command in the Prefix box on the

Advanced tab Session variables are often used as security measures We used them in this chapter to create business model filters and limit data returned to users The ability to override the values of these session variables could possibly provide a means of overriding these security settings To prevent the end user from changing the value of a session variable, it must be marked

as security sensitive during the definition of the session variable

Direct Access to the BI Server

The BI server presents itself as a database It is not a database, however, because it does not actually store any data, and it is not possible to perform transactions against it You can, however, query it like a database JDBC and ODBC drivers are provided with Oracle BI and can be used to query the BI server directly

Just as it is common to restrict direct access to your database and force general user interaction with the database through an application layer, you may consider restricting direct access to the

BI server You can restrict direct access to the BI server by restricting network access to the BI server listening port (default value of 9703) using standard firewall techniques The components that require direct BI server access are the presentation server, the scheduler service, BI Publisher, and Hyperion Provider Services (if you want to use SmartView against the BI server)

To understand why you might want to limit direct access to the BI server, consider how a user might attempt to access the BI server directly First, JDBC and ODBC drivers are shipped with the

BI server, so any Java- and ODBC-based application such as Access or Excel could communicate with the BI server In addition, the BI Administration tool makes direct access to the BI server and can manipulate the metadata It is not uncommon for organizations to lock down direct access to the BI server to prohibit access to the BI server via the Administration tool This is actually more of

a configuration management restriction to prevent developers from making non-tested metadata manipulations to production servers

Lastly, a command-line interface to the BI Server, nqCmd.exe, can be thought of as SQL*Plus for the BI server It is most commonly used for running scripts to manage BI server cache or for managing aggregates defined by the Aggregate Persistence Wizard Just as you might limit who has access to SQL*Plus in your organization, you should consider limiting access to nqCmd.exe

We have focused on restricting direct access to the BI server Most users will communicate with the BI server via some type of application layer: the presentation server, BI Publisher, or some custom application One important thing to remember is that even if people do gain direct access

to the BI server, all security rules still apply and usage tracking will still be enforced Strong authentication and authorization policies are going to be your best means of protecting access

■

■

■

■

■

■

to data Preventing direct access to the BI server just adds one more layer of defense against unauthorized data access

Web Services Access

Oracle BI includes a complete set of Web Services that include the ability to create a session, query the catalog, check permissions, modify the catalog, run reports, and schedule iBots The ability to use the Web Services is controlled with a privilege called SOAP

The ability to make web services calls to Oracle BI is controlled with this privilege If you are not planning on using Web Services, you might be tempted to turn this feature off However, many other features also use these Web Services, including the BI Office plug-in, BI Publisher (when using Answers as a data source), and the Oracle Business Indicators iPhone application Turning off the ability to use Web Services will prevent you from using these applications

CAUTION

Turning off access to Oracle BI Web Services will impact other

components of Oracle BI, including the Oracle BI Office plug-in,

Oracle BI Publisher, and the Oracle Business Indicators iPhone

application.

Summary

Let’s summarize what you’ve learned so far with a scenario: Assume we are logging into Oracle

BI In Chapter 13, we covered all of the details of what happens during the login process So now

we have logged onto Oracle BI and are assigned to appropriate RPD groups and web catalog groups Now we have access to a collection of dashboards, reports, iBots, and BI Publisher reports All these components require the appropriate permissions for both the report definition and the data that will be presented through the report

Our ability to access the report definition is determined by web catalog security We may have been granted access to objects directly, or one of the groups of which we are a member might have been granted access to a folder of web catalog content We may also have been granted any of the following permissions: Change/Delete, Full Control, No Access, or Read Assuming we have the appropriate access to the report definition, the next step is to ensure that we have access to the data that will be presented through the report Security for the data can be applied at the BI server or at the database At the BI server, coarse access to the data is controlled at the subject area level Based on our RPD group membership, we will have read access to certain subject areas At a more granular level, row- or column-level security may have been applied The BI server implements row-level security via a feature called Business Model Filters Column-level security is very easy to implement and several tools are provided to help make sure reports run correctly when column-level security is applied

For security to be applied at the database level, the database must know who we are For performance and ease of maintenance reasons, Oracle BI uses connection pools when connecting

to the database Connection scripts in the connection pool definition make it possible to convey the end user’s identity to the database For the Oracle database, the easiest way to do this is to set

a client identifier in the connection script For databases using Database Vault, factors should be set as part of this connection script In either case, once the database knows our identity, database security and auditing can be leveraged

Chapter 14: Securing Oracle BI Content and Data 577

This chapter covered a variety of Oracle BI features that require some considerations from a security perspective One such feature is the sharable cache of Oracle BI We explored the ability

to make the cache aware of database security policies We also recognized that if queries are being satisfied by cache, they will not get logged by database auditing procedures Other topics included running reports as another user, executing direct database requests, and accessing web services in Oracle BI

A successful implementation of Oracle BI should make it much easier for users to access data sources and, hopefully, increase the number and type of users with access to organizational information The notion of providing enterprise-level, self-service BI can be your impetus to reevaluate existing security policies The design and implementation stages of Oracle BI are the easiest times to implement new security policies Chapters 13 and 14 identified several areas worthy of your attention and provided you with the necessary skills to put together an effective security plan for your Oracle BI implementation

Using the Oracle BI

Examples

579

set of Oracle BI examples are provided with this book to help you set up various security configurations and to reinforce concepts discussed in Chapters 13 and 14 These examples are available on the Downloads page at www.OraclePressBooks com Specifically, these examples help with the concepts of variables, dynamic group membership, various authentication schemes, business model filters, Virtual Private Database (VPD) integration, and database auditing They consist of a web catalog (with several dashboards and reports) and several RPDs The web catalog works with each of the provided RPDs Each RPD focuses on a different method of authentication or security feature This appendix gives an overview of each example provided, notes on how to set up each

example, and notes on interesting features that should be observed in each example

In each example, I tried to minimize the amount of work necessary to maintain users and groups User-group information is needed for authorization purposes, usage tracking, and SA System The concept in every example is to have one place where you manage users and groups and then find a way that authorization, usage tracking, and SA System can all use that information For example, when you’re setting up database authentication, all users, groups, and user-to-group memberships are created in the database using database users and roles Then, views based on the database dictionary are used for authorization, usage tracking, and SA System This allows the information to be managed in one place and to be instantly available for use in several areas

Users and Groups

Table A-1 lists the groups that are used in the examples Depending on the RPD, these groups are implemented in different fashions (internal RPD groups, rows in a database tables, database groups, or LDAP groups)

Several more XMLP_* groups should also be used, in whichever authentication mode you choose XMLP_ADMIN and XMLP_DEVELOPER were the only BI Publisher groups used in the examples Refer to the BI Publisher documentation for a detailed list of the rest of the XMLP_* groups

Table A-2 shows the users included in these examples The password for each user is the same as the username The Administrator account is the standard RPD Administrator account that

A

Presentation Server

Administrators

business model filters applied to members of this group

TABLE A-1 The BI Groups Used in the Examples

Appendix: Using the Oracle BI Examples 581

is created with any new repository It is always defined internal to Oracle BI All other users are defined in the place most appropriate for the authentication method that the RPD supports

Database Preparations

These examples were tested on both Oracle 10g and Oracle 11g databases To run the scripts in

this example, you will need a database with the sample schemas installed All the examples are built on the SH (sales history) schema Several database scripts are provided to set up additional tables used in the examples

Administrator Administrators, Presentation

Server Administrators, XMLP_

ADMIN

The internal Administrator account

biadmin Administrators, Presentation

Server Administrators, XMLP_

ADMIN

The administrator for Oracle BI (BI Server, Presentation Server, BI Publisher, Delivers)

biwebadmin Presentation Server

Administrator

Full administrative privileges on the Presentation Server only

bishuser SH Users, XMLP_DEVELOPER Normal user allowed to use the SH

subject area; user can also developer new reports in BI Publisher

biproduct1 SH Users, Product Managers Business model filters limit user to game

consoles; restrictions driven by rows in PRODUCT_MANAGERS table

biproduct2 SH Users, Product Managers Business model filters limit user to

portable and desktop PCs; restrictions driven by rows in PRODUCT_

MANAGERS table bichannel1 SH Users VPD policies restrict user to Tele Sales

channel; restrictions driven by rows in CHANNEL_MANAGERS table

bichannel2 SH Users VPD policies restrict user to Internet

channel; restrictions driven by rows in CHANNEL_MANAGERS table

bichannel3 SH Users VPD policies restrict user to Internet

channel; restrictions driven by rows in CHANNEL_MANAGERS table

subject area

TABLE A-2 Users and Their Roles in the Examples

Database Auditing

A dashboard in the examples focuses on BI usage tracking and database auditing To use database auditing, you must ensure that this feature is enabled in the database In particular, to see the SQL that is being executed, the database must be in extended auditing mode You can check the status

of your database by executing the following query:

SELECT name,value FROM v$parameter

WHERE name LIKE 'audit%'

If your database is not in extended auditing mode (DB_EXTENDED), issue this command:

alter system set audit_trail='DB_EXTENDED' scope=spfile;

You must restart the database for this to take effect These commands to enable auditing were not included in the example install scripts because they require a database restart Finally, you must specify exactly what is going to be audited See the section “Useful Scripts” later in this appendix

to see how to do this

Database Scripts

Four setup scripts should be run for any example you want to use For specific RPDs, you may need to run additional scripts These are explained in the section “RPD-Specific Scripts.” Finally, some scripts are provided to help test and enable various features

Setup Scripts

Run the following scripts in this order:

1_install_script.sql This script must be run as sys or another user that has permission

to grant privileges on dbms_crypto The users that Oracle BI will use to connect to the Oracle database are set up here Tables that express user-to-group assignments for usage tracking and SA System are also set up here When using internal authentication, user-to-group assignments must be maintained in two places: the RPD (for authentication and authorization) and a set of tables (for usage tracking and SA System) These tables are also used for table-based authentication

2_usage_tracking_sa_system.sql This script sets up the required infrastructure for usage

tracking and the SA System subject area

3_load_date.sql This loads the date table used by usage tracking If you have a date

dimension in your data warehouse, you could use it instead

4_load_time.sql This loads the time table used by usage tracking, which includes a row

for every minute in a day

RPD-Specific Scripts

Following are the RPD-specific scripts:

database_account_roles.sql This should be run before using aos_database.rpd It

creates database users and roles that will be used for Oracle BI authentication and

■

■

■

■

■

Appendix: Using the Oracle BI Examples 583

authorization purposes It also creates the necessary views so that usage tracking and

SA System can pull user-to-group assignment information from the database dictionary

ldap_setup_oid.sql This should be run before using aos_ldap.rpd Several things must

also happen before attempting to use this script First, you should populate your LDAP with the users and groups described in Table A-2 You should create one extra group

in your LDAP called BIUsers and put all the Oracle BI end users in this group Finally, you must modify this script so that it has the correct LDAP connection information and base DN information If you are using Oracle Internet Directory as your LDAP, this script should be close to what you need

ldap_setup_ad.sql This is the same as the ldap_setup_oid.sql script, but it includes

minor changes for Active Directory You will need to make the same changes here as listed for the OID script

act_as_proxy.sql This should be run before using aos_internal_proxy.rpd This creates

the table that holds the proxy permissions necessary for this example

Useful Scripts

Following are some other useful scripts:

vpd_setup.sql This creates a VPD policy on SH.SALES You should be aware of a few

things when enabling this policy After it is enabled, the only users that will be allowed to query the SH.SALES table will be users listed in the BI_TABLES.CHANNEL_MANAGERS table If any other user queries SH.SALES, no rows will be returned As discussed in Chapter 14, a well-designed VPD policy should handle all types of users and should make sure they see the appropriate information This policy is quite simple and was designed to illustrate the ability to use VPD with Oracle BI’s caching infrastructure in a secure way This script also contains the code necessary to disable and drop the policy

vpd_tester.sql Some useful SQL statements to test that the VPD policy is set up correctly audit_tester.sql Some useful SQL statements to test that auditing is working properly.

Oracle BI Setup

Before beginning the process of setting up any of the provided examples, you should perform the following steps Of particular importance is the information in the section “BI Publisher Super User.” Skipping this step makes it easy to lock yourself completely out of BI Publisher Scheduler configuration could actually be done anytime during the process However, whenever you set

up an authentication scheme, I recommend that you test all components—it’s just nice to have Delivers completely set up before beginning

Credential Store

In Chapter 13, you read how the presentation server uses a credential store to store encrypted passwords Three sets of credentials need to go into this credential store Each set is identified

by an alias:

admin The credentials for the Scheduler service

■

■

■

■

■

■

■