Implementing One Authoritative Source of Data Security ... · Design tips to keep in mind ChartField Security – Enabled by user level All ... • Security Records and Security Joins

Implementing One Authoritative

Source of Data Security –

PeopleSoft Financials 9.2

Trimaan Dang

June 23, 2015

ChartField Security with

Query and nVision Security

Contents

• Issue and business requirements

• Proposed solution

− Chartfield Security

− Query Security

− nVision Security

• Use case

• Conclusion

• Questions

© Deloitte LLP and affiliated entities | Implementing One Authoritative Source of Data Security – PeopleSoft Financials 9.2 – ChartField Security with Query and

nVision Security 2

Typical business requirements and

implementation issues

What’s the need?

• Secure fields not able to secure in

the past

• Ensure confidential data accessible

only by authorized users

• Ensure data available for users

without an extra layer of effort

What’s the problem?

• Different methods of accessing data

• Wide-open access to data, by

default

• Securing data through one means

does not automatically secure data

through other means

• Gap exists that needs to be

mitigated


nVision Security 3

Proposed solution

• One overall security method

• Other methods of accessing data

default to the same level of access

provided under overall approach

• Same outcome from a data

perspective, no matter which access

route is selected

• Terminology Used:

− Chartfield Security: As intended

within PS

− Query and nVision Security: Deeper

dive while including data restriction

ChartField security

Query security

nVision security


nVision Security 4

ChartField Security


nVision Security 5

Overview of ChartField Security

• Secures those on-screen pages where ChartFields with monetary amounts and

sensitive data are displayed

− ChartFields available: Account, Alta count, DeptID, Operating Unit, Fund

Code, Project ID etc.

• Allows access for an end-user according to their “need to know” level

− Option to choose method and ChartFields via which Security can

be implemented

• Can choose up to two ChartFields to be secured

• Can be implemented via either the user ID, role, or permission list

• Access is provided through building rules that are specific to the organization

− Rules can be built for multiple products or combinations of products

− Multiple products can be chosen, such as: General Ledger, Expenses,

Payables, Asset Management etc.


nVision Security 6

Chartfield Security

Advantages of using

ChartField Security

• Transactions for only Authorized

ChartFields:

− Once active, end users only see

transactions for authorized Chartfields

− Users restricted to select or enter only

those authorized ChartField values

• Key to seeing authorized values in

the Prompt Tables is to have the

Security Rules “built” into the

underlying security table.

• Works in conjunction with Business Unit

and Ledger Security

• Super users can also be defined

• Security Values “built” for the end-user can

be viewed from the Assign Rule to

User/Role/Permission List page


nVision Security 7

Chartfield Security

How does ChartField Security work?

Secure ChartField options page

Once an option is selected here, ChartField

Security is active!

Options: Deny or Grant Access

Designed such that transactions containing one or more

than one line with secured ChartFields are not accessible


nVision Security 8

Chartfield Security

How to configure ChartField Security

Decide security options

• Should partial access be provided? Which ChartFields should be secured? Which method is the most appropriate?

Define the Rules

• How will ChartField Security be administered? Through Tree Nodes, Values, Ranges, or Wildcards?

Associate Rules with the ChartField security method chosen:

• Users, Roles or Permission Lists

Build Rules’ values in respective security table

Enable ChartField security on the secure ChartField options page

1

2

3

4

5 © Deloitte LLP and affiliated entities | Implementing One Authoritative Source of Data Security – PeopleSoft Financials 9.2 – ChartField Security with Query and

nVision Security 9

Chartfield Security

1. Partial access – Deny access

or grant access

Example

Grant access

• End-user is able to view the journal entry as long as he/she has access to one secured ChartField

• Seamless transition

Deny access

• End-user is unable to view the journal entry and gets the error message of Contacting the Security Administrator

• Only able to see the journal entry if access to all secured ChartFields provided

Pros vs. cons

• Depends on the needs of the organization!

• Grant Access: Ease of use exists since user frustration is minimized

• Deny Access: Can create user frustration especially if the error messages are constant and proper maintenance of ChartField Security does not exist

DR/CR Account Department Amount

DR Asset 1001 $100

CR Liability 1002 $100


nVision Security 10

Chartfield Security

2. Define rules

• Can create multiple combinations within the same rule of a tree node, value, wildcard etc.


nVision Security 11

Chartfield Security

3. Associate rules with ChartField

Security method

• Can associate more than just the products chosen at the Overall level here.

• Caveat is that all the products selected here in the Rule Definition must also be selected

in the Secure ChartField Options page


nVision Security 12

Chartfield Security

Implementation vs. Maintenance


nVision Security 13

Initial setup

• Secure ChartField options

• Define security rules

Post initial setup

• Copying existing rule assignment

• Assigning rules to method selected

Chartfield Security

ChartField Security –

Design tips to keep in mind

ChartField Security – All

or nothing

Enabled by user level –

Initial one-time effort in

setting up all users for

org

Once product enabled

on overall level, rules

and associations to

users/roles/permission

lists must be made

Using tree nodes based

on secured ChartField

tree allows initial set-up

and maintenance

process to become much

faster


nVision Security 14

Chartfield Security

Query Security


nVision Security 15

Overview of queries

• Front-end PIA Queries.

− Tool that can be used to generate flexible extracts of information needed

• Multiple navigations to access.

− Query Manager: Modify and run existing queries. Ability to create queries

− Query Viewer: Run queries on this page. Read only version

• How to configure Query Security through permission lists

• Outcome: wide-open access to all data in underlying tables.

− Gap exists since ability to access more data here than under ChartField Security.

Secure access to Query Viewer or Query Manager navigation

Setup Query Profiles that allow ability to run/create queries

Provide access to tables through Query Access Groups


nVision Security 16

Query Security

Align Query Security with

ChartField Security

Delivered process

• End-users have access to all the data in a table that is being queried upon

• Data returned in queries is not automatically restricted when ChartField Security is

enabled and active.

2 Options

• Security Records and Security Joins within the Query

Security records

• Query security records – equivalent of component search records

• When a query security record is enabled on a record, PeopleSoft runs a “security check”

based on the query security record before returning data in the results

• The Query Security Record is first looked towards for which values are authorized before

data is returned in the Query

Security joins within the query

• Delivered queries or custom queries created can be joined with the underlying Query

Security table within the query itself


nVision Security 17

Query Security

Comparison of the 2 options

Keep in mind

• How is Query Access being designed overall: What’s the need?

• Is access going to be wide-spread? How many users will be provided access?

• Is data needed to be secured? What’s the model being used – need to know vs. transparency for entire

organization?

• How is access being provided?

− Through the delivered Query Viewer page or a custom page?

− Through delivered Query Trees or Custom Query Trees?

Via security records Via security joins

Needs to be applied to every record that can be

queried upon

Needs to be applied to every Query that contains

the secured ChartFields

May cause issues with delivered processes that

rely on queries upon which query security records

have been applied.

Dependency: Is access to delivered Query Viewer

to be provided? If so, might be unrealistic to

change every single delivered queries

Dependency: How many delivered processes rely

on delivered queries

If access to Queries is to be restricted, then can be

a viable option


nVision Security 18

Query Security

Implementation vs. Maintenance

Initial setup

• Revolves around getting Query Security up and running

Post initial setup

• Revolves around making sure that queries can be run on records

• Revolves around ensuring that data restrictions are complied with


nVision Security 19

Query Security

nVision Security


nVision Security 20

Overview of nVision Security

• Overview of PS/nVision

− Tool for creating reports in Excel

− Reports are created when a Report Layout is selected

− The Report Layout defines the information that needs to be retrieved along with the

specified formatting

− Drill down features can also be used within nVision Reports to expose further

information to make the report more useful

− Reports can be run from either PIA or the client version

• How to configure nVision Security

• Outcome: wide-open access to all data in the Ledger

− Gap exists since ability to access more data here than under ChartField Security.

Restrict access to the nVision pages through permission lists

Restrict access to the nVision actions allowed through permission lists


nVision Security 21

nVision Security

Delivered process: nVision ledger

based security

• Inactive unless a Reporting View is enabled

• Secured Reporting View – Join between the Ledger Authorization Table and the

Ledger Table

• Secured Ledger Reporting View “sits” on top of the Ledger Template

• Once a Secured Ledger Reporting View has been identified, PeopleSoft

defaults to the dynamic Ledger Reporting View to ensure that only authorized

values for the user are returned

− Authorized values are determined when a “match” happens between the

Ledger Authorization Table and the Ledger itself

− Secured Reporting View is a dynamic SQL view that is called upon when an

nVision Report request is generated


nVision Security 22

nVision Security

Delivered process: nVision ledger

based security (cont’d)

Ledger Template

Ledger B

Ledger A

Ledger C

Business Unit

and Ledger

match

Delivered Ledger

Authorization Table

• User ID field

• Business Unit field

• Ledger field

Ledger

Table

Delivered

Ledger

Reporting View

• SQL

Statement

Generated


nVision Security 23

nVision Security

Proposed solution –

Infrastructure needed

Customize Ledger Authorization

Table

• Secured ChartField needs to be added

• Needs to be able to hold repeating

values of secured ChartFields for the

same user ID and business unit but for

the number of different ledgers

Customize Secured Ledger

Reporting View

• SQL addition needs to happen. Addition

needs to match the secured ChartField

value held in the Authorization Table

and the Ledger Table

• SQL change needs to happen.

Customized view needs to point to

Custom Ledger Authorization Table


nVision Security 24

nVision Security

Overall benefits

Streamlined access

Configuration with

minimum customization

Confidentiality and

availability maintained

Relatively straightforward

maintenance


nVision Security 25

ChartField security

Query security

nVision security

Use case


nVision Security 26

ChartField Security

Asset Management

Billing Commitment

Control

Contracts Cost

Management Expenses

General Ledger

Grants Management

Inventory

Order Management

Payables Project Costing

Purchasing Receivables Service

Procurement

eProcurement Treasury

Secure ChartField Options page Products Enabled

© Deloitte LLP and affiliated entities | Implementing One Authoritative Source of Data Security – PeopleSoft Financials 9.2 –

ChartField Security with Query and nVision Security 27

Chartfield Security

Query Security

• 2 Permission Lists Created to Hold the Query Profiles

− Run Queries and Create Queries

• Query Access Groups assigned to other Permission lists that provided access

to navigations.

− Delivered Query Access Groups utilized mostly

• Access to delivered Query Viewer page was restricted.

− A custom Query Viewer page was created that only displayed those custom

queries that were created for the organization.

• Alignment with ChartField Security by using Security Joins within the

Query itself


nVision Security 28

Query Security

nVision Security

• Need was to ensure that data available from nVision should match data

displayed on the on-screen pages

• Delivered process does not allow for

− An additional ChartField such as Department to be included in the Reporting

View or

− Values held in the ChartField Security tables to be “translated” into the

nVision Ledger Authorization Table

• Once changes to ChartField Security are made, the Secured Reporting View

and the Ledger Authorization Table are not updated automatically


nVision Security 29

nVision Security

Customization


nVision Security 30

Ledger Template Ledger B

Ledger A

Ledger C

Business Unit

and Ledger

match

Delivered Ledger

Authorization Table

• User ID field

• Business Unit field

• Ledger field

Ledger

Table

Delivered

Ledger

Reporting View

• SQL

Statement

Generated

Addition of Dept

ID field

Should be able to hold

repeating values

Dept ID Field

MUST match

SQL addition

“AND L.DEPTID

= A.DEPTID”

nVision Security

Solution eventually designed:

Loading the data

• Method needed for values to be “translated” from ChartField Security underlying table of

SEC_DEPT_USER into the custom Ledger Authorization Table

• Process used for initially loading the values will be the same process used for maintaining

the Custom Ledger Authorization Table in the future also

• Process eventually designed was an Application Engine program to map values from the

ChartField Security underlying table into the custom Ledger Authorization Table

• Values currently held in the custom Ledger Authorization Table are deleted

• Changes are reflected as follows

SEC_DEPT_USER

• User ID

• Dept ID

Custom LED_AUTH_TBL

• User ID

• Dept ID

• Business Unit

• Ledger

Extended

for 9

Ledgers


nVision Security 31

nVision Security

Solution eventually designed:

Maintenance perspective

• How is the Application Engine triggered?

• Few Options existed

• Simplest option was chosen

− Separate page

• Points to consider

− Everytime changes to ChartField Security are made, must come to this page and

trigger the App Engine program to “map” values between the two tables

− Access to the custom page must be provided through appropriate permission lists


nVision Security 32

nVision Security

To sum it all up

• ChartField Security can be used as a base for ensuring that data accessible

from all points of access is consistent

• ChartField Security only governs on-page access.

• Query and nVision Security are by default wide-open.

− Do not automatically comply with ChartField Security

• Query and nVision Security needs to be configured

• Above all, the organization’s needs must be considered. Security strategy

around all of this must “fit” with the broader picture


nVision Security 33

Questions? Trimaan Dang, Macc, CPA,CA Candidate

Consultant

Enterprise Risk Services

Deloitte

[email protected]

519-650-7702


nVision Security 34

mailto:[email protected]

www.deloitte.ca Deloitte, one of Canada's leading professional services firms, provides audit, tax, consulting, and financial advisory services. Deloitte LLP, an

Ontario limited liability partnership, is the Canadian member firm of Deloitte Touche Tohmatsu Limited.

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms,

each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of

Deloitte Touche Tohmatsu Limited and its member firms.

© Deloitte LLP and affiliated entities.

Documents

Implementing One Authoritative Source of Data Security ... · Design tips to keep in mind ChartField Security – Enabled by user level All ... • Security Records and Security Joins