494 Part IV: Applied Security for Oracle APEX and Oracle Business IntelligenceNote that the new row in the audit trail was issued by the database user ANONYMOUS, which typically means i
Trang 1494 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,
Trang 2return 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;
Trang 3496 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
Trang 4Securing Access to
Oracle BI
497
Trang 5498 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
■
■
■
■
■
■
■
■
T
Trang 6The 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
Trang 7500 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
■
■
■
Trang 8Inferring 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
■
■
■
■
Trang 9502 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
Trang 10To 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