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

574 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence 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 ■ ■ ■ ■ ■ ■ 576 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence 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. This page intentionally left blank APPENDIX Using the Oracle BI Examples 579 580 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence 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 Group Name Group Type Description Administrators Group BI Server Administrators Presentation Server Administrators Web group Web Catalog Administrator SH Users Group and web group Sales History BI User Product Managers Group Sales History product managers; business model filters applied to members of this group XMLP_ADMIN Group Required BI Publisher group XMLP_DEVELOPER Group Required BI Publisher 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. Username Group Membership Description 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 binoshuser User does not have access to the SH subject area TABLE A-2 Users and Their Roles in the Examples 582 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence 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 ■ ■ ■ ■ ■ ■ ■ . Users and Their Roles in the Examples 582 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Database Auditing A dashboard in the examples focuses on BI usage tracking and. 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. security plan for your Oracle BI implementation. This page intentionally left blank APPENDIX Using the Oracle BI Examples 579 580 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence