Introduction
For new implementations, the Oracle Enterprise Performance Management (EPM) suite of products brings a new regimen of security terminology, often times making auditors cringe. Historically, Financial Management, and its predecessor Hyperion Enterprise, have been fully administered by finance or accounting managers thus totally eliminating any possibility of change management or control. In recent versions of Oracle Hyperion Financial Management (HFM), organizations are able to draw clear lines of separation between application administrative functionality and systems administration functionality.
This article is not intended to help establish a process for defining policy but should provide some guidelines for establishing a security plan in other organizations.
The Oracle® Enterprise Performance Management System User and Role Security Guide provides general descriptions for roles in the EPM suite of products which do not always translate to functionality. I will attempt to clarify what some of these roles grant from a practical perspective ina future article.
General Good Practices
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
The following remarks are recommended good practices I have observed. Maybe these are common sense to you, but; if there was such a thing, then everyone would have it.
- Good Practice 1: Change the password for the default ADMIN account. During implementations, the default ADMIN account often is overused by developers and administrators. In a hurry, developers will resort to using ADMIN in order to just “get the job done.”
- Good Practice 2: If you created an administrator group, remove everyone that doesn’t belong.
- Good Practice 3: USE GROUPS. With the exception of the ADMIN account, de-provision any administrator and provisioning manager roles from individuals.
Segregation of Duties
Administrators should have access to the functionality they need to accomplish their daily job. Segregation of duties is a key concept of internal controls and is often difficult and costly to implement. The concept is hardly new to finance and account departments as pairing roles, such as depositing cash and reconciling bank statements or approving time cards and having custody of pay checks, has been a playground for auditors for decades.
The primary objective of segregating job duties is to remove the possibility of a conflict of interest or fraud. The following table depicts recommended segregation of duties in a production environment.
| Task |
Security Admin |
Systems Admin |
Application Admin |
| Migrate artifacts (reports, rules, application artifacts, dimensions) to production |
|
X |
|
| Provision users and groups |
X |
|
|
| Manage group membership |
X |
|
|
| Modify Essbase application and database properties |
|
X |
|
| Maintain servers |
|
X |
|
| Access servers desktop |
|
X |
|
| Maintain data |
|
|
X |
| Perform consolidations |
|
|
X |
| Modify dimensions in an emergency* |
|
X |
|
| Modify business rules in an emergency* |
|
X |
|
| Modify Reporting and Analysis documents in an emergency* |
|
X |
|
| Review system logs |
|
X |
|
| Manage data workflow through Financial Data Quality Management |
|
|
X |
| Journal Management** |
|
|
X |
* Emergency changes to production should only be executed when a managed development workflow process is not practical in a given situation.
** An application administrator should not be granted authority to both submit and approve journals.
The above SOD matrix restricts the business administrators from performing application modifications and security changes in the Production environment while enabling them to perform design and build activities in the Development environment.
