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

494 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Note that the new row in the audit trail was issued by the database user ANONYMOUS, which typically means it’s coming from APEX using the Embedded PL/SQL Gateway. Also note that APEX sets CLIENT_ID to the APEX User and APEX Session ID number that is captured in the audit trail. You might wonder why I included SCN (System Change Number) as a column in this example. My goal was to hint at a powerful concept that is a bit beyond the scope of this chapter, and that is to combine FGA with the Oracle database Flashback feature and, new in 11g, Flashback Data Archive. Flashback is designed to retain historical data for short periods—say, a week or less—which provides DBAs many more options for data recovery. Flashback is also a great compliment to FGA in that it allows you to put your session back in time. Since the audit trail provides both the SCN and the query, we could put our session back to that time and run the same query to see exactly what data was displayed in a security breach. Flashback Data Archive extends this concept as it is designed to retain data for much longer periods, measured in months or years. The following code is a quick example of how the code is used for this scenario: exec DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER(6009443); select * from employees where 1 = 1; FGA Example 3 One parameter of DBMS_FGA.ADD_POLICY we haven’t explored yet is HANDLER_MODULE. While this parameter is not directly related to APEX, the functionality it provides is significant enough to deserve an example. HANDLER_MODULE is designed to be able to send alerts when an audit event occurs. Without the ability to send alerts, a security administrator needs to review the audit logs on a regular basis to detect suspicious events. HANDLER_MODULE allows you to define a PL/SQL procedure that is called every time an audit event occurs. The PL/SQL procedure must conform to the following signature: procedure_name( object_schema in VARCHAR2, object_name in VARCHAR2, policy_name in VARCHAR2); Our example procedure will use the database package UTL_MAIL. In 11g, this package is not installed by default. Installation instructions for this package are detailed in the “Oracle Database PL/SQL Packages and Types Reference.” You will also need to set the initialization parameter SMTP_OUT_SERVER and grant execute on UTL_MAIL to SEC_ADMIN. The following procedure is an example handler module that collects as much information as possible about the session that triggered the audit event and e-mails that information to one or more security administrators.: create or replace procedure fga_notify ( schema_name in varchar2, table_name in varchar2, policy_name in varchar2) as l_msg varchar2(32767); the t_row function accepts name / value pairs and returns them as an HTML table row with 2 cells function t_row( p_label in varchar2, p_data in varchar2) Chapter 12: Secure Coding Practices in APEX 495 return varchar2 is begin return '<tr><td style="text-align:right;">'||p_label||'</td>'|| ' <td style="font-weight:bold;">'||p_data||'</td></tr>'||utl_tcp. crlf; end t_row; begin l_msg := '<html><head><style type="text/css">body{font-family:helvetica}</ style></head><body>'|| '<table style="border:0px;">'|| t_row('Schema',schema_name)|| t_row('Table',table_name)|| t_row('Policy',policy_name)|| t_row('User',user)|| t_row('Client Info',sys_context('userenv', 'client_info'))|| t_row('Client Identifier',sys_context('userenv', 'client_identifier'))|| t_row('IP Address',sys_context('userenv', 'ip_address'))|| t_row('Auth Type',sys_context('userenv', 'authentication_type'))|| t_row('Session ID',sys_context('userenv', 'sessionid'))|| t_row('DB Name',sys_context('userenv', 'db_name'))|| t_row('Host',sys_context('userenv', 'host'))|| t_row('OS User',sys_context('userenv', 'os_user'))|| t_row('External Name',sys_context('userenv', ' external_name'))|| t_row('Current SQL', '<pre> '||sys_context('userenv', 'current_ sql')||'</pre>')|| '</table></body></html>'; utl_mail.send( SENDER => 'sec_admin@mycompany.com', RECIPIENTS => 'security_admin@mycompany.com,dba@mycompany.com', SUBJECT => 'Policy Violation', MESSAGE => l_msg, MIME_TYPE => 'text/html', PRIORITY => 1); end fga_notify; / To demonstrate the use of this procedure we will use the Audit Function defined in the first example. Note that the last parameter is new. begin dbms_fga.add_policy (object_schema => 'SEC_USER', object_name => 'EMPLOYEES', policy_name => 'IS_FROM_APEX_POLICY', audit_condition => 'SEC_ADMIN.IS_APEX_SESSION_ONE = 0', audit_column => null, statement_types => 'INSERT,UPDATE,DELETE,SELECT', enable => true, handler_module => SEC_ADMIN.FGA_NOTIFY); end; / 496 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Now let’s issue a query from SQL*Plus to trigger an audit event: SQL> select * from employees; This solution notifies administrators within seconds of an attempted data breach, enabling them to take proactive measures to prevent further data loss. Since it does not require any schema or code changes, this solution is an excellent addition to any system dealing with sensitive data. Summary APEX encourages secure coding practices by providing developers with the right tools and examples. As with any security-focused solution, there is no magic button labeled “Secure My Code.” Security is developed through knowledge and awareness. The goal of this chapter is to raise your level of awareness and to provide examples to steer developers in the right direction. It is a developer’s responsibility to apply these techniques in their day-to-day development and, more important, to open a dialogue with their colleagues to help raise everyone’s level of awareness. CHAPTER 13 Securing Access to Oracle BI 497 498 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence his part of the book will focus on securing Oracle Business Intelligence (Oracle BI) Enterprise Edition. This process can easily be divided into two topics: securing access to Oracle BI and securing the data and content surfaced by Oracle BI. This chapter focuses primarily on the first topic, including external authentication methods, capturing user ID and group membership information, and single sign-on (SSO) integration. Some prerequisite topics are also covered, as well as a discussion on securing communication between components in an Oracle BI system. The next chapter will focus on securing of Oracle BI content (dashboards, ad hoc requests, and reports) as well as row- and column-level security. To finish off the section, the topic of auditing will be discussed. The official name of the Oracle product is Oracle Business Intelligence Suite Enterprise Edition Plus. The “Plus” refers to the Hyperion BI components that were added to the suite after Oracle acquired Hyperion. This book does not discuss the Hyperion components of the suite. Instead, it focuses on the following components (hereafter referred to as Oracle BI): Oracle BI Server Oracle BI Interactive Dashboards Oracle BI Answers Oracle BI Delivers Oracle BI Publisher Several examples of each of these components are provided in this text. All examples can be downloaded from the Downloads page at www.OraclePressBooks.com. In this chapter, several authentication schemes are discussed. An Oracle BI repository is provided for each authentication method covered. The Oracle BI metadata, contained in a file with a .rpd extension, is often referred to as the RPD. The data model in each RPD is identical and is designed to run off the Sales History (SH) sample schema provided with the Oracle Database. A collection of reports and dashboards are also provided. The definitions of the reports and dashboards are stored in a web catalog. The sample web catalog provided with this book consists of three dashboards: The SH dashboard illustrates how data can be protected. The Utilities dashboard offers some tools for accessing variables and testing security settings. The Audit dashboard is a combination of the database auditing discussed in Chapter 14 and the usage tracking reports provided with Oracle BI. See the appendix for instructions on setting up and running these examples. These examples were all developed on Oracle BI Enterprise Edition 10.1.3.4. Oracle Virtual Directory (OVD) and Oracle Access Manager (OAM) were used as the Lightweight Directory Access Protocol (LDAP)and SSO systems, version 10.1.4. The Oracle Database-specific examples—Virtual Private Database (VPD), DBMS_LDAP, and auditing—were all tested on both Oracle 10g R2 and 11g R1. ■ ■ ■ ■ ■ ■ ■ ■ T Chapter 13: Securing Access to Oracle BI 499 The Challenge in Securing BI The whole point of a BI system is to give people better access to information—and get the right information to the right people at the right time. BI systems often bring together data from separate systems. The data might be stored in a different fashion for speed of retrieval. Changes to the data might include demoralization, aggregation, and cleansing processes. These factors provide some interesting challenges to the BI administrator in terms of security. In fact, often the desires of the information consumers seem to be at odds with the mandates of the people charged with protecting the data. However, with an effective BI tool, you can provide easier access to data while still maintaining the necessary security for that data. To look at some of these challenges, consider an example of a school district and some of the challenges such an organization might face while deploying a BI system. Why a school district? First, it’s something a little different from the typical example of protecting credit card information or financial information. Second, I’ve worked with a number of school districts and have seen the interesting security challenges that they encounter as they try to create data warehouses, longitudinal data systems (systems that track students across multiple schools over multiple years), and “No Child Left Behind” reporting systems. Third, if you are reading this, you have likely been to school and have a basic familiarity with the concepts discussed. Finally, the same issues challenging school districts in securing a BI system can be applied to a number of other industries. System Users One of the first interesting challenges you’ll encounter when securing a BI system concerns the types of users. Again, a goal of a BI system is to give more people access to the information they need. The people seeing the data are no longer just the people who key in the data. In fact, there are many more information consumers than producers. Let’s look at our school district example. A school district has a number of information consumers: superintendents, school board members, local government, state school boards and governments, the federal government, administrators, research departments, principals, teachers, guidance counselors, parents, students, and tax-paying citizens. This list includes an incredibly diverse set of users: from public users to internal users, from very technical users to nontechnical users, and from highly privileged users to restricted users. The research department, for example, will often have access to large amounts of data, and potentially sensitive data, often combining demographic information with performance. Students or parents might be accessing the same data warehouse or BI system, but their information will normally be limited to their own data at the detail level (the student’s own standardized test results, for example) and all data at the aggregate level (how a child’s school performs compared to other schools in the district). Each type of user must be carefully evaluated, and significant care must be taken to make sure they are given access only to the type of data they should see. Security in the Warehouse vs. the Transactional System Another security challenge lies in the fundamental difference between a BI system and the transactional systems that feed the warehouse of the BI system. Security in transactional systems is often determined by the business process that the transactional system was designed to address. 500 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence For example, if you have a grade entry system, it’s fairly easy to define security requirements. Here’s a simple list of requirements to start with: Only teachers can enter grades. Teachers can enter grades for their students only. Grades can be entered only at certain times. Obviously, some special cases would need to be addressed, but by and large the requirements are fairly straightforward. When you consider grades in the context of a data warehouse, things get much more complicated. Many different types of users are now going after the same information, and different users will have different security requirements. Students want to see details of their grades and possibly class averages. Teachers may look across years. Principals may compare different teachers of the same subject. Research analysts may be investigating whether the lottery-sponsored scholarship program has impacted grade inflation across the state. Also, grade entry is always done at the detail level (this student got this particular grade on this particular exam on this date); however, grade analysis can be done at multiple levels. What started as a simple security problem of entering grades has become exponentially more complex when we start looking at the data for reporting purposes. As you can tell from these examples, one of the keys to implementing robust security successfully within in a BI system is flexibility. For a transactional system, the security requirements are often easily defined and fairly static; you know exactly who can do what to the data and that normally doesn’t change. In a BI system, this just isn’t true. Lots of different groups will all be trying to access the same information, and each group will need to have its own security policy in place. In addition, you’ll typically see things change significantly over time. Special projects, new requirements, and changing environments will necessitate changes in the user population and what type of access they need. One last difference between transactional system and BI systems is that transactional systems require read-write permissions and BI systems are generally read-only. At first, this seems like a simple case of selecting the proper user profile, as we discussed in Chapter 1. In reality, putting a read-only policy in place for users of a BI system is only the first step. The question is more about what data users can see than it is about read-write versus read-only access. Ensuring that users see only data they are supposed to see is the focus of this chapter and the next. Consolidated Data Creates More Interesting Problems One of the main reasons for implementing a data warehouse is that it allows you to bring together data from multiple systems. This creates a number of interesting security requirements. Each system from which data was pulled will have its own set of security requirements. When you gather all of the data together, these requirements may be different. At the very least, you will need to reconcile the security requirements from each system. Let’s revisit the grades example again. While performing grade entry, teachers probably look only at a small data set. They probably see a student’s name and grade for a particular test. However, once the data is consolidated in a data warehouse, different sets of data are combined to yield interesting, but sensitive information. For example, consolidating data from the free lunch program with grade data may provide interesting information for the research department, but this data probably shouldn’t be available to the general public. Similarly, providing demographic information together with grade data makes the data more sensitive, because you can now do grade analysis by race, gender, or socioeconomic status (politically charged data, to say the least). ■ ■ ■ Chapter 13: Securing Access to Oracle BI 501 Inferring Information from Lack of Data Let’s continue the example a bit further. School districts often publish information about how students perform, broken out by various demographic indicators at the aggregate level. For example, information might be published on what percentage of students from each race achieved a “Proficient” score on a statewide assessment. That’s all well and good, unless a particular racial group is a very small part of the student population. At this point, aggregate data starts to become personal data. Because of this, I’ve worked with several school districts that have security requirements that data should not be shown if the population size is below a certain amount. This is another example of security requirements that are quite unique to BI systems. Inheriting Security from Packaged Applications We discussed the fact that the BI system often has different security requirements from the transactional system. However, that doesn’t mean you have to start from scratch in defining security requirements for a BI system. Often, the transactional system has a good set of roles or groups that can be reused in the BI system. The ability to leverage these roles and the already defined membership in these roles can help you jump start the process of setting up BI security. In addition, if you want to provide users the ability to navigate from the BI system back to the transactional system, it is important that you have their security context properly set up in the BI system. A good example of this can be seen in the Oracle BI Applications, which are prebuilt data warehouses and BI systems designed to be placed on top of major transactional systems (Siebel, PeopleSoft, Oracle, and SAP). With these applications, you can leverage the security model and roles defined in transactional systems. To start with, these BI applications have security groups that map to the roles (PeopleSoft) or responsibilities (Siebel and Oracle) of the source transactional system. They also leverage transactional system information such as Operating Unit Organization or Inventory Organization to provide data-level security. This allows the BI applications to limit the rows returned in queries based on the organization of which the user is a member. This gives you a great starting place in defining the security model for your BI system. What Needs To Be Secured Securing a BI system can involve several tasks: Securing access to the BI system itself Securing the data presented via the BI system Securing access to content created with the BI system Securing functionality of the BI system Securing the BI system includes both authentication and authorization. You can authenticate with Oracle BI using externalizing authentication so that you can leverage existing security infrastructure. The SSO server can authenticate the user and provide a coarse level of authorization (for example, this person’s credentials check out and he or she is allowed to access the BI system). We also discuss group membership within Oracle BI for few different reasons. First, with security administration externalized, this topic requires some special attention. Second, it is a critical prerequisite to setting up SSO. Finally, it sets the stage for Chapter 14 and all the other steps required in securing a BI system. Securing data and content and establishing privileges are all based on group membership. ■ ■ ■ ■ 502 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence As mentioned, BI systems often bring together an organization’s most important data and present it in an analytically friendly way. This data consolidation is great for people who are supposed to have access to the data, but if the data is not properly secured, people can exploit data they shouldn’t be allowed to access. We look at ways to provide both coarse- and fine- grained data protection. Coarse permissions are fairly easy to define (“only group A should have access to a certain type of data”), so we focus most of our attention on the fine-grained securing of data, including both row- and column-level security. We will consider two methods of providing row-level security and will compare and contrast these methods. Next, we look at how web catalog content can be protected. We focus on the mechanisms in Oracle BI used to organize and secure all BI content (dashboards, reports, ad hoc requests, and alerts). Protection means controlling who has access to the definitions of these objects and who can manipulate these definitions. NOTE In order for a user to run a report successfully, that user must have access both to the definition of the report and the data presented in the report. Finally, we look at the privileges that need to be granted to different users of the system. We focus on privileges that require specific care. Oracle BI offers some advanced features that should be granted only after careful consideration. Users should have access to these features only if they have been trained in how to use them. Some of these features allow users to impact data and functionality for other users. It is important that you know exactly what you are allowing users to do when you give them access to a specific feature. Mechanics of Accessing Data with Oracle BI Before getting into the details of how to secure Oracle BI, let’s review the mechanics of accessing data using Oracle BI, including a review of Oracle BI’s architecture, primarily from a security perspective. Architecture Your understanding of the BI server is critical to understanding the information presented in this chapter and the following one. For example, when we talk about authenticating with Oracle BI, we’re referring to the BI server, which you must be logged into. In Chapter 14, when we focus on data security, this again centers on the BI server. Let’s start with what happens when a user tries to access Oracle BI. We’ll examine the interaction from end-to-end. First, the user’s browser communicates with the web tier of Oracle BI, a plug-in that is deployed to Internet Information Services (IIS) or a J2EE container. This plug-in handles communication with the Oracle BI presentation server in the middle tier. The presentation server, in turn, talks to the Oracle BI server, another middle-tier component, which handles all communication with the underlying databases. This architecture is depicted in the following illustration. Chapter 13: Securing Access to Oracle BI 503 To help you understand the authentication process, let’s first examine this process for simple, out-of-the-box, internal authentication. When attempting to access Oracle BI, users will be presented with a login screen. Credentials are captured, passed to the presentation server, and sent to the BI server for validation. With internal authentication, the usernames and passwords are stored in the BI server metadata (the RPD file). So, in this case, the BI server actually validates the credentials and performs the authentication. After the user is authenticated, a session must be established. Setting up the session properly includes populating a variety of session variables. These session variables are at the core of securing Oracle BI and will be discussed in greater detail later in this section. Once the user is authenticated and a session is established, the Oracle BI server will issue queries to the database on behalf of the end user. NOTE This is just a brief introduction to one way of performing authentication with Oracle BI. We will discuss the details of other methods of performing authentication in the next section. While reviewing the architecture of Oracle BI, you’ll find it worthwhile to examine the mechanics of running a report and retrieving data. Let’s take a simple ad hoc request. In the Answers component of Oracle BI, you would create a query: deciding what fields to include, filters to be applied, and functions to be evaluated. The presentation server evaluates this request and then creates a logical SQL statement that is sent to the BI server. The BI server analyzes the . Protocol (LDAP )and SSO systems, version 10.1.4. The Oracle Database- specific examples—Virtual Private Database (VPD), DBMS_LDAP, and auditing—were all tested on both Oracle 10g R2 and 11g R1. ■ ■ ■ ■ ■ ■ ■ ■ T Chapter. following components (hereafter referred to as Oracle BI): Oracle BI Server Oracle BI Interactive Dashboards Oracle BI Answers Oracle BI Delivers Oracle BI Publisher Several examples of each of. access to Oracle BI and securing the data and content surfaced by Oracle BI. This chapter focuses primarily on the first topic, including external authentication methods, capturing user ID and group