Database Security with focus on Hyperion Database
University of Colorado at Colorado Springs
CS 691
Fadi Mohsen
Aug1, 2009
ABSTRACT
The security of databases has been changed because of the invention of web. Before web, databases were easy to protect using the basic access technique, but when the web systems came out, it became tough task. The attacks increased, also the type of attacks changed.For example, SQL injection is the most famous attack targeting the web-based database systems, and a lot of research has been done to stop it. The security in general is all about managing the relationships between three things, subjects, objects and access roles [2]. (i) Subjects are the active entities (such as processes) and objects are the passive entities (such as files), (iii) access roles define what subjects can do with the objects. Like the administrator (subject) can delete database table (object).
In this paper I will present a set of research methods proposed to protect the databases from being attacked, after that I will cover the security side in the Hyperion database.
- INTRODUCTION
First of all let me bring an important point which is, the efficiency of any proposed security related solution depends not just on the solution itself, but also on actually using it. In every database system there are a huge number of security options ready to be set, but most of database developers simply don’t use it, because of the time constraints or they don’t know about it. The database guy has nothing to do with security, and at the same time the security guy has no idea about database design.
Researchers adapted many approaches to secure the database system, but they did agree that the complexity of securing web-based database system came from the huge no of users accessing the web-application which is in charge of applying security, in the past the applications were run from the users’ desktop. These users were known to the application and their number was fixed orlimited. Web applications on the other hand are different completely, since these applications are run from the users’ browsers. The users of web applications can be casual users and their number is not limited. The browser does not directly connect to the database, but instead transfer a request to a web server [1]. So, the database can’t identify who is accessing it, since each time the super-user (web server) make the request and take back the results. So, there is a need to let the database knows who is requesting, so that role-based security can be implemented.
2 Researchers Approaches to Database Security
2.1 Fine-grained Access Control to Web Databases
It is a new method for protecting web-based databases; it utilizes the databases’ built-in access control mechanisms enhanced with Parameterized Views and adapts them to work with web applications. Their proposed access control mechanism is applicable for any existing databases and is capable to prevent many kinds of attacks, thus significantly decreases the web databases’ attack surface.Views are the basic block of securing relational database, since it presets to the user the only piece of the database that interests her. But again, since the database deals only with a strong user (web server user), traditional views kind of restricted and needs to be revived in order to best secure the web database. They come up with the parameterized view that is capable of transferring the user’ identity to the database, after that based on it the view will show relevant data. And that what they call fine-grained access control to the web databases. Actually, the concept of parameterized view is an old one, many researchers talked about it in 1990’s, but mainly in the context of object-oriented database. The results show that there is no performance degradation when the number of concurrent users grows. It also seems that with comparison to the traditional table-based application, the parameterized view-based web application does not require additional definition of indexesor query normalizations/optimizations [1].
2.2 MANDATORY SECURITY IN OBJECT-ORIENTED DATABASE SYSTEMS
They considered only the ORION object-oriented data model which was developed at MCC
[BANE871]. It describes how we can incorporate security to this model. They called this model
SORION. Then, they came out with a security policy based on it. Two issues were discussed, ployinstantiation and handling the inference problem. Finallythey described howmandatory security constraints, which are rules assigningsecurity levels to data, may be handled [2].
In general, multilevel secure database management system (MLS/DBMS) users subjected to different security levels access and share a database consisting of data at different sensitivity levels. An effective security policy for MIS/DBMS should ensure that the principle of least privileges security concept is met, which means a subject should be given only those privileges that it needs to in order to complete its task. The earliest of security policies, the Bell and LaPadula security model [BELL75], is stated below.
(i) Subjects are the active entities (such as processes) and
objects are the passive entities (such as files)
(ii) Subjects and objects are assigned security levels. The
set of security levels form a partially ordered lattice.(e.g.
Unclassified < Confidential c Secret < TopSecret).
(iii) simple security property: A subject has read access to
an object if the subject’s security level dominates the
security level of the object
(iv) *-property: A subject has write access to an object if
the subject’s security level is dominated by the security
level of the object.
As stated in [BANE87], all conceptual entities in ORION are modeled as objects. A class is a group of objects that has the same characteristics. A class could be a system-defined class, such as a class of integers or strings, or it could be a user-defined class suchas a class of documents or employees. The objects of a class are called its instances. Associated with each class is a set of instance variables that describe the state of the instances of the class. Object-ID, which uniquely identifies an object of the class is also an instance variable. For example, a class of employees could have Object-Id, social security number, name, salary and department as its instance variables [2].
So, the relationships between classes and objects should be reflected into the security policy. For example, if Ali is an employee, but at the same time he is a Director, then he would inherit the privileges from employee, and director classes. This terminology makes it easier to the security designers.
2.3 Role-Based Databases Security, Object Oriented & Separation of Duty
The combined the object-oriented and role-based concepts to apply separation of duty. Roles essentially partition database information into access contexts. Methods (O-O) associated with adatabase object, also partition the object interface to provide windowedaccess to object information. A set of privileges forms a Role, which can be assigned to a group of users. Thinking in Role-based protection makes the task of managing large number of users easy and trivial. So we have now, privileges and roles. The following are there definitions[4].
Definition I A privilege is a pair (z, m) where x represents (name, identifier, etc.) an object (data item, resource, etc.) and m is a non-empty list of access modaltries for object z.
Definition 2 A role is a named collection of privileges. It is a pair (rname, plist} where rname is the role name and plist is the privilege list.
There should some kind of mapping between roles and the information. Like, role1 related to the table1, file1, and printer 1. Etc. Now, when user has a role 1 then he will be able to access table1 data.
In the O-O paradigm, methods, the only means of access to object information, provide a windowing effect on this information. By authorizing different roles to execute different methods of an object, we effectively distribute the object interface across roles and hence the individuals authorized for the associated roles[4].
3 Hyperion Security Administration
In the previous section we covered some of the methods proposed by researchers to enforce security and access. In this section I will cover the security policies that are adopted in Hyperion database. I will first give an introduction to the Hyperion database technology, then I will cover the security side.
3.1 Hyperion Database
Hyperion Enterprise is a database that contains data that can be used to develop and print
reports [6]. The component Retrieve is an Excel interface that responsible for pulling numbers from the Hyperion database into the Excel. The scenario is as follows, if we have a company with different branches, then the accounting information is entered into the Hyperion
Database at the central location (the head) and then used by the branches (branch 1, branch 2, etc. ) to manage their accounts. Hyperion facilitates the process of viewing financial information with different formats. Figure 1 shows The EnterpriseDesktop which serves as main controller for all operations performed in the Hyperion Enterprisesystem. The eleven large icons in the lower three-fourths of the screen are Desktop icons [6].
Figure 1 Enterprise Desktop
Actual Hyperion Database data is seen in only the Data Entry and the Reports modules. The
Modules that are gray are used by the database administrators [6].
3.2 Security Components
Hyperion application security falls into two main categories, authentication and authorization. And each one of the previously mentioned consists of several components.
3.2.1 User Authentication
User authentication enables single sign-on functionality across Hyperion products by validating
The login information of each user to determine authenticated users. User authentication, along
with product-specific authorization, grants the user access to Hyperion products. Authorization
is granted through provisioning [5].
Single sign-on (SSO) is a session and user authentication process that permits a Hyperion
Product user to enter credentials only once at the beginning of a session to access multiple
Hyperion products. SSO, which is requested at session initiation, eliminates the need to log in
separately to each Hyperion product to which the user has access [5].
User Authentication consists of three components, Security API, Native directory, and User Directories. All of them used to support the SSO.
The Security Application Programming Interface (Security API) is the main interface to validate
users and interpret user access to Hyperion products. It is a Java API that enables Hyperion
products to authenticate users against user directories configured in Oracle's Hyperion® Shared
Services. It also allows integration with a security agents such as Netegrity SiteMinder, and
retrieval of users and groups based on names and identities. Each Hyperion application
implements the Security API to support user authentication [5].
Native directory (OpenLDAP), an open source Lightweight Directory Access Protocol (LDAP)-
enabled user directory, is bundled and configured with Shared Services.
Native Directory serves two functions:
-Used to maintain and manage the default Shared Services user accounts required by
Hyperion products
- Is the central storage for all Hyperion provisioning information because it stores the
relationships between users, groups, and roles.
User directories refer to any corporate user and identity management system compatible withShared Services. Hyperion products are supported on a large number of user directories. Theseinclude LDAP-enabled user directories, such as Sun Java System Directory Server (formerlySunONE Directory Server) and Microsoft Active Directory, Windows NT LAN Manager(NTLM); SAP Provider; and custom-built user directories that support LDAP version 3.In addition to Native Directory, which is automatically configured for your environment, one
or more user directories can be configured as the user information provider for Hyperion
products.User directories used with Hyperion products must contain an account for each user whoaccesses Hyperion products. These users may be assigned to groups to facilitate provisioning [5].
I will present two scenarios for the user authentication process, in the first one is signing on directly to the Hyperion products, the other on is signing on from external systems. Figure 2 shows the user authentication main components; we will use it to explain the first scenario.
Figure 2 User Authentication main components.
First scenario, user signs in directly to the Hyperion products.
Direct authentication connects Hyperion products to available user directories to verify the user
name and password (credentials) entered on the Login screen.
1. Using a browser, users access the Hyperion product login screen. They enter user names
and passwords. The Security API implemented on the Hyperion product queries the configured user directories (including Native Directory) to verify user credentials. A search order is used to
establish the search sequence. On finding a matching user account in a user directory, the
search is terminated and the user's information is returned to the Hyperion product.
Access to Hyperion product is denied if a user account is not found in any of the user
directories.
2. Using the retrieved user information, the Hyperion product queries Shared Services to
obtain provisioning details for the user. Provisioning details are stored in Native Directory.
On receiving provisioning information from Shared Services, the appropriate Hyperion product
is made available to the user. At this point, SSO is enabled for all Hyperion products for which
that user is provisioned. Access permissions within Hyperion products are determined by the
provisioning information.
Second scenario, user signs in to the Hyperion products from external systems.
Hyperion products can be configured to accept pre-authenticated users from external sources,
such as Netegrity SiteMinder and SAP Enterprise Portal, to enable SSO. In this scenario,
Hyperion products use the user information provided by a trusted external source to determine
access permissions of users.
SSO with SAP is supported by accepting an SAP logon ticket. In this scenario, users defined in
an SAP user directory can navigate between the SAP Portal and Hyperion products. If an SAP
provider is configured, users can also directly log on to Hyperion products using the user ID
and password stored in the SAP system. The SAP provider creates the SAP logon ticket to enableSSO with SAP systems.
Figure 3 Signing in from external systems.
1. Using a browser, users access the login screen of a web identity management solution (for
example, SiteMinder) or SAP Enterprise Portal. They enter user names and passwords,
which are validated against configured user directories to verify user authenticity. Hyperion
products are also configured to work with these user directories.
When users navigate to a Hyperion product, information about the authenticated user is
passed to Hyperion product, which accepts the information as valid.
If the user logged on to SAP Portal, an SAP logon ticket is passed to Hyperion product. The
Security API implemented on Hyperion product decrypts the SAP logon ticket using a
specified SAP certificate.
If the user logged on to a web identity management solution, a custom HYPLOGIN HTTP
header is passed to Hyperion product.
2. To verify user credentials, Hyperion product tries to locate the user in one of the user
directories based on the search order. If a matching user account is found, user information
is returned to Hyperion product.
3. Using the retrieved user information, Hyperion product queries Shared Services to obtain
provisioning details for the user.
On receiving user provisioning information from Shared Services, the Hyperion product is
made available to the user. SSO is then enabled for all Hyperion products for which that
user is provisioned.
3.2.2 Provisioning (Role-Based Authorization)
Hyperion application security determines user access to products using the concept of roles. A
role is a set of permissions that determines user access to product functions.
Each Hyperion product provides several default roles tailored to suit various business needs.
Predefined roles from each Hyperion application registered with Shared Services are available
from User Management Console. These roles are used for provisioning. You may also create
additional roles that aggregate the default roles to suit specific requirements. The process of
granting users and groups specific access permissions to Hyperion resources is called
provisioning.
Native Directory and configured user directories are sources for user and group information for
the provisioning (authorization) process. You can browse and provision users and groups from
all configured user directories from User Management Console. Provisioning data is stored in
Native Directory. You can also use application-specific aggregated roles created in Native
Directory in the provisioning process.
This illustration depicts a broad overview of the authorization process:
1. After a user is authenticated, Hyperion product queries the user directories to determine
the user's groups.
2. Hyperion product uses the group and user information to retrieve the user's provisioning
data from Shared Services. The product uses this data to determine resources that a user can
access.
Product-specific provisioning tasks, such as setting product-specific access control, are
completed from each product. This data is combined with provisioning data to determine
the product access for users.
Role-based provisioning of Hyperion products uses these concepts [5].
Roles
A role is a construct (similar to access control list) that defines the access permissions granted
to users and groups to perform functions on Hyperion resources. It is a combination of resource
or resource types (what users can access; for example, a report) and actions that users can performon the resource (for example, view and edit).