SAP Business Intelligence WhitePaper

SAP Business Intelligence White Paper v1.0.doc

of 32 © 2009 KPMG LLP, a U.S. limited liability partnership and a member firm of the KPMG network of independent member firms affiliated with KPMG International, a Swiss

cooperative. All rights reserved. KPMG and the KPMG logo are registered trademarks of KPMG International, a Swiss cooperative. For internal use only.

ABCD

SAP Business Intelligence (BI)

SAP Business Intelligence Overview of Authorizations & Controls

Author: Jared D. Krueger [email protected]

March 11, 2009

Version 1.0




ABCD Table of Contents

1. Overview .................................................................................................................................................................... 3 2. BI Security Overview .............................................................................................................................................. 4 3. BI Benefits ................................................................................................................................................................. 5 4. BI Authorizations Overview .................................................................................................................................. 6 5. BI Building Blocks ................................................................................................................................................... 7

InfoArea .................................................................................................................................................................. 7 InfoProvider ........................................................................................................................................................... 7 DataSources .......................................................................................................................................................... 7 InfoSources ............................................................................................................................................................ 7 ODS Objects .......................................................................................................................................................... 7 InfoCubes ............................................................................................................................................................... 8 Subobject ............................................................................................................................................................... 8 InfoSet ..................................................................................................................................................................... 8 Component Types ................................................................................................................................................ 8 Component Type Activities ............................................................................................................................... 8

6. Data Extraction ......................................................................................................................................................... 8 7. BI Authorization Objects & Security ................................................................................................................... 9

S_RS_COMP ........................................................................................................................................................ 10 S_RS_COMP1 ...................................................................................................................................................... 12 S_RS_FOLD ......................................................................................................................................................... 13 S_RS_ADMWB .................................................................................................................................................... 13 S_RS_IOBJ ........................................................................................................................................................... 16 S_RS_ISOUR ....................................................................................................................................................... 17 S_RS_ISRCM ....................................................................................................................................................... 18 S_RS_IOMAD ....................................................................................................................................................... 19 S_RS_ICUBE ........................................................................................................................................................ 20 S_RS_ODSO ........................................................................................................................................................ 21 S_RS_HIER .......................................................................................................................................................... 22 S_RS_TOOLS ...................................................................................................................................................... 23 S_RS_MPRO ........................................................................................................................................................ 23 S_RS_ISET ........................................................................................................................................................... 24 S_RFC.................................................................................................................................................................... 24

8. Reporting Security Strategy ............................................................................................................................... 24 1 Securing by InfoCube .............................................................................................................................. 24 2 Securing by Query .................................................................................................................................... 25 3 Securing at the InfoObject Level .......................................................................................................... 25

9. BI Audit Program Guide - Suggested Controls ............................................................................................ 26 10. Version History .................................................................................................................................................... 31 11. Sources: ................................................................................................................................................................. 32




ABCD

1. Overview

The purpose of this document is to discuss different aspects of SAP Business Intelligence (BI), functionality, security, and building blocks that make it one of the leading reporting applications on the market. SAP Business Intelligence (BI) is a reporting system used to consolidate and view a company’s financial and operational data. It is primarily used to retrieve and report on data from SAP systems, but can also be used to report on data which is part of non-SAP systems. BI uses the Netweaver SAP Enterprise Portal, this means that it uses the standard backend GUI for administration and development, however uses a web-based GUI for end-users utilizing Internet Explorer, and MS Excel to generate reports.

SAP BI integrates data from across a company(s), and then transforms it into practical, timely information to drive sound decision-making, targeted action, and solid business results.

Key areas BI supports:

• Data warehousing – Data warehouse management; business modeling; and extraction, transformation, and loading enable you to build data warehouses, model information architecture according to business structure, and manage data from multiple sources.

• Business intelligence – Online analytical processing, data mining, and alerts provide a foundation for accessing and presenting data, searching for patterns, and identifying exceptions.

• Business planning – A BI planning framework with secure workflow capabilities supports Microsoft Excel or Web-based planning and budgeting based on consolidated corporate data for bottom-up or top-down planning.

• Business insights – Query design, reporting and analysis, and Web application design allow you to create analysis reports, support decisions at every level, and present business intelligence applications on the Web.

• Measurement and management – Business-content management, metadata management, and collaborative business intelligence monitor progress, provide reporting templates, ensure consistent data, and help decision-makers work together.

• Open hub services – Open hub services features enable the delivery of high-quality, audited enterprise information through Web services to applications. Bulk data exchange, change data capture (CDC), and modeling features streamline deployment and enable cost-effective operations.

• Information broadcasting – Information broadcasting features support the distribution of mass information to large audiences in a personalized and secure manner. You can broadcast information as an offline document or live report through personalized e-mail or the Internet, according to a schedule or based on key events.

• Accelerated business intelligence – Based on compressions, parallel in-memory processing, and search technologies, the SAP NetWeaver BW Accelerator functionality improves the performance of queries, reduces administration tasks, and shortens batch processes. Developed as an appliance on Intel processors, the accelerator provides consistently fast response times, even as data volumes, number of users, and analytics increase.

When looking at BI there are 3 major areas:

1. Administrative/Security: This is the area responsible for maintaining the application for user access, developing roles, access to queries, system connections, authorization objects, info providers, info objects, info systems and source systems. This area should be restricted to Basis and Security personnel.

2. Development – This area is responsible for designing queries using info-cubes. Since SAP BI is used for reporting purposes, the primary development is building reports and queries. Primarily this area should be locked down in production so any new development of queries must take place in development environment.




ABCD

3. Front-end – This area is where the user logs into BI and executes queries & reports. Multiple roles may have been designed to limit which users have access to specified queries.

How are reports generated?

Analyzing reports in BI is the main function performed using this application. Custom and standard reports are generated using the BEx Analyzer. The Business Explorer Analyzer (BEx Analyzer) is the analysis and reporting tool of the Business Explorer that is embedded in Microsoft Excel. This enables accurate near real-time reporting based on data stored in the BI warehouse. These reports are generated by extracting master data and transactional data from the SAP production system (source system) and loading it into the warehouse for reporting purposes only. You can call up the BEx Query Designer in the BEx Analyzer, in order to define queries. Subsequently, you can analyze the selected InfoProvider data by navigation to the query created in the Query Designer and create different query views of the data. You can add the different query views for a query or for different queries to a work book and save them there. You can save the workbook in your favorites or in your role on the BW Server. You can also save the workbook locally on your computer. Beyond that, you can precalculate the workbook and distribute it by e-mail to recipients or you can export it to the Enterprise Portal and make it accessible to other employees in the company. The BEx Analyzer offers convenient functions for evaluating and presenting InfoProvider data interactively. In the BEx Analyzer, you can add queries to workbooks, navigate within them and refresh the data. You can also process the queries further in Microsoft Excel or display them in the Web browser in a default view. SAP BI is not about creating and updating data, it is about converting data into knowledge. Below is a diagram of the SAP BI Data Warehousing and Business Explorer Suite which provides an accurate breakdown of the BI structure and where all pieces of the application reside.

2. BI Security Overview




ABCD When securing BI Data you determine what data users can view and access. You are used to transaction codes serving as your first line of defense in R/3. In BI, transaction codes are fewer and are not used as the primary means of controlling what data a user can access.

• BI security is focused on: InfoAreas, InfoProviders (InfoCubes, ODS, objects), and Queries • Transaction RRMX Launches the BEx Analyzer, which is used to execute queries (reports) for end-users, security

can be designed so that when an end-user logs in, they can only view specified queries based on their access. • Transaction RSA1 Launches the Administrator Workbench, which is used by SAP BI administrators, access to this

transaction should be highly restricted to only authorized users, developers should never have this access since reporting output could be altered.

*For further information on security see Section 7

3. BI Benefits

• Increased business visibility and performance to make faster decisions. • Integrate, standardize and synchronize data across business workstreams • Centralized reporting mechanism • Reporting with no risk to master data changes • SAP Business Warehouse is ships with "Business Content". It comes with ready-made extraction routines, meta-

data, InfoCubes, information models, reports and channels that guarantee analysis and reporting capabilities out of the box.

• It closes the loop as it provide a seamless links to planning and execution applications that allow you to act instantly on the insight you gain to improve the performance of your business processes.

• It openness ensure that SAP BW is ideal for SAP R/3Æ and other SAP solutions but not limited to them. You can combine it easily with practically any internal or external data source, including existing data marts, with third-party reporting and analysis tools, or planning and execution applications.

• The flexibility of SAP BW is that it is a ready-to-go solution but easy to adapt. You can modify or add data sources, meta-data, InfoCubes and reports as and when you need to.

Further example of the benefits of SAP can be seen from the diagram below. This diagram details how you can combine data to report on planning and actual costs to help determine P&L of sales vs. operational overhead costs. You can use the reporting mechanisms to plan your strategic growth and long-term financial planning by analyzing real-time data.




ABCD

4. BI Authorizations Overview

• BI Authorizations

BI has two authorization object classes:

1 Business Information Warehouse Reporting – Object class used for field level security in reporting

• No authorization objects are delivered in this object class

• Authorization objects for field level security in reporting are created as needed

2 Business Information Warehouse – authorization object class which is used to secure BI objects for administration

• Authorization objects are delivered to protect all major administration and planning functions in SAP BI




ABCD 5. BI Building Blocks

SAP’s BI information model is based on the core building block of InfoObjects which are used to describe business processes and information requirements. They provide basis for setting up complex information models in multiple languages, currencies, units of measure, hierarchy, etc. The key elements in the SAP’s BI information model are:

• InfoArea

• DataSources

• InfoSources

• ODS Objects

• InfoCubes • InfoProviders • MultiProviders

• Subobject

• InfoSet

InfoArea

InfoAreas are logical groups of InfoProviders. You may have only one InforArea or you may have an InfoArea for each application area, such as sales, financials, HR, and so on.

InfoProvider

This is the category of objects that can provide data to a query, such as InfoCubes and ODS objects. The InfoCube or ODS object holds the summarized data that the user can analyze. Query results are based on the data in the InfoCube or ODS object.

DataSources

DataSources are flat data structures containing data that logically belongs together. They are responsible for extracting and staging data from various source systems.

InfoSources

InfoSources are the group of InfoObjects that belong together from a business point of view. It contains the transactional data obtained from the transactions in online transactional processes (OLTP) and master data such as addresses of customers and organizations, which remain unchanged for longer time period.

ODS Objects

An ODS object is a dataset which is formed as a result of merging data from one or more info sources. In it information is stored in the form of flat, transparent database tables that are used for preparing reports and quality assurance purposes.




ABCD

InfoCubes

InfoCubes are multidimensional data storage containers for reporting and analysis of data, they hold the actual data used for reporting. They consist of keys figures and characteristics of which latter is organized as dimensions facilitating users to analyze data from various business perspectives such as geographical area or types of sales channel. Reports are generated from pulling data defined by the InfoCube key figures which are mapped to warehouse data.

If you have an InfoArea for each application area, then you may have only on InfoProvider in that InfoArea or you could have several InfoProviders. For example, in an InfoArea for FI could be an InfoCube for accounts receivable data and another for accounts payable data.

Subobject

This is part of an InfoSet that can be selected to be edited “by user” as a security function.

InfoSet

An InfoSet gives you a view of a dataset that you report on using the InfoSet Query. The InfoSet determines which tables or fields within a table an InfoSet Query refers to. When running a query you can restrict users from viewing certain fields within an InfoSet.

Component Types Component Type Activities

• REP: Entire query

• STR: Structure

• CKF: Calculated key figure

• RKF: Restricted key figure

• VAR: Variables

• 01 Create

• 02 Change

• 03 Display

• 06 Delete

6. Data Extraction

So where does the data for BI reports come from? Simple, they are generated using data stored in a data warehouse/repository. This is populated using data extraction programs that read data from extract structures and send it, in the required format, to the Business Information Warehouse.

To use data from other non-SAP applications, extraction programs can be implemented with the help of third party providers. These then collect the requested data and send it in the required transfer format using BAPIs to the SAP Business Information Warehouse.

The below image highlights how InfoSource’s which were discussed above have data extracted and populated into InfoCubes:




ABCD

7. BI Authorization Objects & Security

Authorization Objects in BI:

• Objects used for REPORTING users

• S_RS_COMP

• S_RS_COMP1

• S_RS_FOLD

• Objects used by ADMINISTRATION users

• S_RS_ADMWB

• S_RS_IOBJ

• S_RS_ISOUR

• S_RS_ISRCM

• S_RS_IOMAD

•

• Objects used by both REPORTING & ADMINISTRATION users

• S_RS_ICUBE




ABCD • S_RS_ODSO

• S_RS_HIER

• Other objects

• S_RS_TOOLS

• S_RS_MPRO

• S_RS_ISET

• S_RFC

Reporting Security Authorization Objects

BI does not have many transactions so it is important to understand how to enforce security at the object level. As mentioned earlier, transaction RRMX launches the BEx Analyzer which is used for reporting purposes. So restricting by transaction code alone is not sufficient to limit reporting capabilities. Security must be taken one step further at the object level. Below are the authorization objects that you will find in the BI system and what they are used to control user access.

S_RS_COMP

Overview

Authorizations for using different components for the query definition. You can secure based on query name schema or InfoCube name (Important for reporting). Using this authorization object, you can restrict the components that you work with in the Business Explorer query definition. For example, it restricts if someone can create queries, change queries, or execute queries. You can restrict query creation, change, and execution by the InfoArea and InfoCube. If your company has one InfoCube for sales information and another for financial data, you can restrict a user to only those queries written for the sales InfoCube or the financial InfoCube.

You could also use S_RS_COMP if you want to protect by query name. For example, you have an InfoCube for sales data. Every sales manager needs access to this InfoCube. However, sales managers in different lines of business are not allowed to execute the same query.

Defined fields The object contains four fields:

• InfoArea: Determines which InfoAreas a given user is allowed to process.

• InfoProvider: Determines which InfoProviders a given user is allowed to process.

• Component type: Determines which components a given user is allowed to process.

o Calculated key figure (Type = CKF)

o Restricted key figure (Type = RKF)




ABCD o Template structure (Type = STR)

o Query (Type = REP)

o Variable.....(Type = VAR)

o Query View.....(Type = QVW)

• Name (ID) of a reporting component: Determines which components (according to name) a given user is allowed process.

• Activity: Determines whether the user is allowed to

o Create (Activity =01)

o Change (Activity =02)

o Display (Activity =03 ) or

o Delete (Activity =06) a component.

o The activities 16 'Execute', and 22 'Save for reuse' are not currently checked by the query definition.

With query view, only the activities 01 'Create', 02

'Change', or 06 'Delete' are currently checked.

Example #1

With InfoArea 0001 in InfoProvider 0002, user A is allowed to create, change and delete the queries that start with A1 and A6. The user can change the structures (templates) and calculated key figures already defined in this InfoProvider.

Relevant authorization for user A:

InfoArea: '0001'

InfoProvider: '0002'

Component type: 'REP'

Component: 'A1*','A6*'

Activity: '01','02','06'

InfoArea: '*'

InfoProvider: '0002'

Component type: 'STR', 'CKF'

Component: '*'




ABCD Activity: '02'

Example #2

Your company decides that each power user can create queries only for their application area. You are using a naming convention for each area. S_RS_COMP can be used to enforce this policy (for example, in accounts receivables all queries must start with “AR”). This can also enforce users to only create queries for “their” InfoCubes

S_RS_COMP1

Overview

With this authorization object, you can restrict query component authorization with regards to the owner. This authorization object is checked in conjunction with the authorization object S_RS_COMP.

This can be used to limit, by the query owner, which queries a user can see.

Authorization object S_RS_COMP1 secures the list of queries seen by the user via the BEx Analyzer or Web-based reporting and can limit the list of queries by the query owner. For example, you are a manager for a local sales team. You can only run queries created by the power user for your geographic region. S_RS_COMP1 limits both what queries you can see in the BEx Analyzer tool, what queries you can display, and what queries you can execute. The Owner field in S_RS_COMP1 works in conjunction with the fields in S_RS_COMP. If the special value $USER is entered as an authorization value for the Owner field, then a user can only change their queries and cannot change any other queries. The $USER will also limit the queries the user can see and display in the analyzer tool.

Authorization objects S_RS_COMP and S_RS_COMP1 are evaluated together. A user must have access to both objects. The actions you can take related to a query in S_RS_COMP are complemented by the owner field in S_RS_COMP1.

Defined Fields

The object contains four fields:

• Name (ID) of a reporting component: determines which components (according to name) are allowed to be edited by the user

• Type of reporting component: determines which component types are allowed to be edited by the user

o Calculated key figure (Type = CKF)

o Restricted key figure (Type = RKF)

o Structure (Type = STR)

o Query (Type = REP)




ABCD o Variable (Type = VAR)

o Query View (Type = QVW): Authorizations for S_RS_COMP1 are not

o Currently checked for query views.

• Reporting component owner: determines whose components are allowed to be edited by the user

• Activity: determines whether the user

o is allowed to change a component (Activity = 02)

o is allowed to display a component (Activity = 03)

o is allowed to delete a component (Activity = 06)

Example #1

Power users create queries for various application areas. If a user chooses to open up a new query while in the BEx Analyzer, only the queries created by their power users should appear in the query list.

S_RS_FOLD

Overview

With this authorization object, you can deactivate the general view of the 'InfoArea' folder. Then only the favorites and roles appear in the BEx open dialog for queries. The view of the InfoAreas is hidden.

You only need to use this object it if you do not want users to see the InfoAreas listing of queries. The object has one field - Hide .Folder. Push button. If this field is set to X (True), then the InfoAreas button will not appear in the BEx Analyzer Open → Queries dialog box

When a user brings up the BEx Analyzer or uses the Query Designer for Web-based reporting, there are four categories from which they may choose existing queries: History, Favorites, Roles, and InfoAreas. Authorization object S_RS_FOLD will allow you to disable the InfoAreas category

Defined Fields

The object contains a field:

• SUP_FOLDER: Hide the file view if the field is set to 'True' ('X'). If both 'True' and 'False' is selected ('All Values'), the value 'False' is valid, meaning that the 'InfoAreas' file is not hidden.

Example #1

The reporting user should only be able to see their “Favorites” folder and their assigned roles in the BEx Analyzer. They cannot look at the other InfoAreas to which they have not been granted access.

S_RS_ADMWB




ABCD

Overview

Using this authorization object you can limit the work done with certain objects in the Administrator Workbench. It protects working with individual objects of the Administrator Workbench such as sources system, InfoObjects, monitoring, application components, InfoAreas, settings, metadata, InfoPackages, and InfoPackage groups.

This object is used throughout transaction code RSA1. It covers many administrative tasks. It includes dealing with source systems, InfoObjects, InfoPackages, master data, and transaction data.

Authorization object S_RS_ADMWB is the most critical authorization object in administration protection. When you do anything in transaction code RSA1, object S_RS_ADMWB is the first object checked. There are two fields in this object: Activity and Administrator Workbench Object. Each of the two fields can have a variety of values. The possible values for the Administrator Workbench field are:

• SourceSys: Working with a source system

• InfoObject:Creating, maintaining InfoObjects

• Monitor: monitoring data brought over from the source systems

• Workbench: Checked as you execute transaction code RSA1

• InfoArea:Creating and maintaining InfoAreas

• ApplComp: Limiting which application components you can access

• InfoPackage: Creating and scheduling InfoPackages for data extraction

• Metadata: Replication and management of the metadata repository

Defined Fields

The object contains two fields:

• Administrator Workbench object: Here you enter the name of the object of the Administrator Workbench that a user is allowed to edit. The following objects are possible:

o SourceSys Source system

o InfoObject InfoObject

o Monitor Monitor

o ApplComp Application component

o InfoArea InfoArea

o Workbench Administrator Workbench

o Settings Settings

o MetaData Meta data




ABCD o InfoPackag InfoPackage and InfoPackage group

o RA_Setting Reporting Agent setting

o RA_Package Reporting Agent package

o DOC_META Meta data documents

o DOC_MAST Master data documents

o DOC_HIER Hierarchy documents

o DOC_TRAN Transaction data documents

o DOC_ADMIN Document storage administration

• Activity: determines whether you are allowed to display or maintain a sub-object

o Display source system (activity = 03)

o Display InfoObject (activity = 03)

o Display Monitor (activity = 03)

o Display Reporting Agent setting (activity=03)

o Display Reporting Agent package (activity=03)

o Display meta data documents (activity=03)

o Display master data documents (activity=03)

o Display hierarchy documents (activity=03)

o Display transaction data documents (activity=03)

o Maintain source system (activity = 23)

o Maintain application component (activity = 23)

o Maintain InfoArea (activity = 23)

o Maintain InfoObject (activity = 23)

o Maintain settings (activity = 23)

o Maintain InfoPackage (group) (activity = 23)

o Maintain Reporting Agent package (activity=23)

o Maintain Reporting Agent setting (activity=23)

o Maintain meta data documents (activity=23)




ABCD o Display meta data documents (activity=03)

o Maintain master data documents (activity=23)

o Display master data documents (activity=03)

o Maintain hierarchy documents (activity=23)

o Display hierarchy documents (activity=03)

o Maintain transaction data documents (activity=23)

o Display transaction data documents (activity=03)

o Administer document storage (activity=23)

o Execute Administrator Workbench (activity = 16)

o Update Metadata (activity = 66)

Example #1

This object is used in transaction code RSA1 and covers numerous administrative tasks. It includes dealing with source systems, InfoObjects, InfoPackages, master data, and transaction data.

S_RS_IOBJ

Overview

Authorizations for working with individual InfoObjects and their sub-objects. This authorization object is only checked if the user is NOT authorized to maintain or display InfoObjects. Working with the InfoObject catalog can be restricted with this authorization object.

If someone needs to update InfoObjects, but they do not need other administration functions granted in S_RS_ADMWB, then you can give them S_RS_IOBJ in lieu of S_RS_ADMWB. It will provide access to InfoObjects only.

Defined Fields

The object includes three fields:

• InfoArea: Here you can specify the key for the InfoArea for which a user can edit the InfoObject catalog.

• InfoObject catalog: Here you can specify the key for the InfoObject catalog that a user can edit.

• Activity: Determines whether you can display or maintain an InfoObject catalog.

o Display InfoObject Catalog (Activity = 03)

o Maintain InfoObject Catalog (Activity = 23)

This authorization object is only checked if the user has neither general maintenance authorization nor display authorization for InfoObjects (Authorization Object: S_RS_ADMWB InfoObject, Activity: Maintain/Display).




ABCD

S_RS_ISOUR

Overview

You can use this authorization object to restrict the handling of InfoSources with flexible updating and their sub-objects.

Defined Fields The authorization object contains four fields:

• Application component: Enter the application component key here for which a user is allowed to edit InfoSources.

• InfoSource: Enter the InfoSources with flexible updating the user is allowed to edit here.

• Subobject for InfoSource: You use the sub-object to specify the part of the InfoSource that the user is allowed to edit. The following sub-objects exist:

o Definition Definition

o CommStruc Communication structure

o TrnsfrRule Transfer rules

o Data Data

o InfoPackag InfoPackage

o MetaData Metadata

• Activity: Determines whether you are allowed to displaymaintain, request or update a sub-object:

o Display InfoSource definition (Activity = 03)

o Display InfoSource communication structure (Activity = 03)

o Display InfoSource transfer rules (Activity = 03)

o Display InfoSource data (Activity = 03)

o Maintain InfoSource definition (Activity = 23)

o Maintain InfoSource communication structure ,(Activity = 23)

o Maintain InfoSource transfer rules (Activity = 23)

o Maintain InfoSource InfoPackage (Activity = 23)

o Maintain InfoSource Data (Aktivität = 23)




ABCD o Request InfoSource data (Activity = 49)

The display and maintenance of the InfoSource data is checked in the PSA tree and in the Monitor.

Example #1

If you want to allow a user to maintain, but not request, the master data for all InfoSources delivered with the application component CO-PA, assign him or her the following authorizations:

• Application component: CO-PA

• InfoSource: 0*

• Subobject: *

• Activity: 23

Example #2

You have an administrator who defines what data needs to be extracted from what source systems. This object protects access to the source systems and managing the transfer rules.

S_RS_ISRCM

Overview

With this authorization object you can restrict handling of InfoSources with direct updating (for master data) or with their sub-objects.

Defined Fields


• Application components: Here you enter the application component key for which a user is allowed to edit master data InfoSources.

• InfoSource: A user is allowed to edit the master data InfoSources you specify here.

• Subobject for the InfoSource: You can use the sub-object to specify the part of the InfoSource the user is allowed to edit. The following sub-objects are available:

o TrnsfrRule Transfer rules

o Data Data

o InfoPackag InfoPackage

o MetaData Metadata

• Activity: Determines whether you are allowed to display, maintain, request or update a sub-object:




ABCD o Display InfoSource transfer rules (Activity = 03)

o Display InfoSource data (Activity = 03)

o Maintain InfoSource transfer rules (Activity = 23)

o Maintain InfoSource InfoPackage (Activity = 23)

o Maintain InfoSource data (Activity = 23)

o Request InfoSource data (Activity = 49)

Display and maintenance of InfoSource data is checked in the PSA tree and in the Monitor.

Example #1

If you want to allow a user to maintain, but not request, the master data for all InfoSources delivered with the application component CO-PA, assign him or her the following authorizations:


• InfoSource: 0*

• Subobject: *

• Activity: 23

Example #2

You have an administrator who defines what data needs to be extracted from what source systems. This object protects access to the source systems and managing the transfer rules.

S_RS_IOMAD

Overview

With this authorization object you can restrict the editing of master data in the Administrator Workbench.

Defined Fields

The authorization object contains four fields:

• Application component: You enter here the key of the application component, which a user is allowed to edit.

• InfoArea: You enter here the key of the InfoArea, that the user is allowed to edit. With the question whether master data for an InfoObject of a particular InfoArea is allowed to be edited, a check is carried out to see to which InfoObject catalog the InfoObject is assigned. An InfoArea, which the user is allowed to edit, must be assigned to this InfoObject catalog.

• InfoObjects, which are not assigned to an InfoObject catalog and thus are assigned to an InfoArea, can be found under




ABCD Nodes not assigned.

• InfoObject : You enter here the key of the InfoObject, which the user is allowed to edit.

• Activity : determines whether master data may be maintained, deleted, or displayed.

o Display master data (activity = 03)

o Maintain master data (activity = 23)

o Delete master data (activity = 06)

Using activity 23 (maintain master data) you can authorize the user to maintain master data manually and to delete single records. The activity 06 (delete master data) authorizes the user to carry out mass deletion of master data for an InfoObject. You get to this function in the Administrator Workbench via InfoObject tree -> your InfoObject -> Context menu (right mouse button) -> Delete master data. Only those master data values that have not been used are deleted.

Example #1

If a user is to be allowed to maintain the master data of all InfoObjects delivered with the application component CO-PA, then assign this person the following authorizations:


• InfoArea: <DUMMY>

• InfoObject: 0*

S_RS_ICUBE

Overview

Using this authorization object you can restrict working with InfoCubes or their sub-objects.

Defined Fields


• InfoArea: You enter the key of the InfoArea, for which a user is allowed to edit InfoCubes.

• InfoCube: The InfoCubes that you enter here can be edited by a user.

• Subobject for InfoCube: Using the sub-object you specify the part of the InfoCube that the user is to edit. The following sub-objects exist:


o UpdateRule Update rules

o Aggregate Aggregate

o Data Data




ABCD o ExportISrc Export DataSource

• Activity: Determines whether you are allowed to display, maintain or delete sub-objects

o Display InfoCube definition (Activity = 03)

o Display InfoCube update rules (Activity = 03)

o Maintain InfoCube data (Manage Cube) (Activity = 03)

o Display InfoCube aggregate (Activity = 03)

o Delete InfoCube data (Activity =06 )

o Maintain InfoCube definition (Activity = 23)

o Maintain InfoCube update rules (Activity = 23)

o Maintain InfoCube aggregate (Activity = 23)

o Maintain InfoCube export DataSource (Activity = 23)

o Update InfoCube aggregate (Activity = 66)

Example #1

Your SAP BI administrator creates InfoCubes. You have a regional manager who needs access to the data in one of the InfoCubes. The regional manager will need access to S_RS_ICUBE and the respective InfoCube that holds the data.

S_RS_ODSO

Overview

Using this authorization object you can restrict working ODS objects and their sub-objects

Defined Fields

The object includes four fields:

• InfoArea: Here you specify the key for the InfoArea, for which a user is allowed to edit the MultiProvider

• MultiProvider: The MultiProviders that you specify here are allowed to be edited by a user.

• Subobject for the Multiprovider: With this sub-object you specify the part of the MutliProvider that the user is allowed to edit. There are the following sub-objects:


o ExportDS Export-DataSource




ABCD • Activity: determines whether you are allowed to display, delete, maintain, or update a sub-object.

o Display MultiProvider definition (Activity = 03)

o Maintain MultiProvider definition (Activity = 23)

o Maintain MultiProvider Export-DataSource (Activity = 23)

Example #1

Same as S_RS_ICUBE except for ODS objects

S_RS_HIER

Overview

Authorizations for working with hierarchies, who can create hierarchies and run queries that use hierarchies. Using this authorization object you can restrict the working with hierarchies in the Administrator Workbench.

Defined Fields


• InfoObject: You enter the key of the InfoObject here, for which a user is allowed to edit hierarchies.

• Hierarchy name: Enter the name of the hierarchies that a user is allowed to edit.

• Hierarchy version: Enter to which version of the hierarchy the authorization refers here.

• Activity: Determines whether the user is allowed to

o Display (activity = 03) or

o Maintain (Activity = 23) a hierarchy

o or if he or she is allowed to display data along the hierarchy (activity = 71).

Example #1

If you want a user to maintain all hierarchies for the InfoObject 0COSTCENTER, assign him or her the following authorizations:

• InfoObject: 0COSTCENTER

• Hierarchy Name: *

• Activity: 23

Example #2




ABCD Manager needs to access data by cost centers. The regional manager for the “Southwest” needs access to all cost centers in the Southwest. Cost centers are set up in a hierarchy. Within the “Southwest” hierarchy are cost centers for each region in that area. The BI administrator must have S_RS_HIER to execute queries that use hierarchies.

S_RS_TOOLS

Overview

You use the authorization object to limit your user group for individual Business Explorer tools. At the moment the authorization object only has an effect if you activate it with a source code modification (see note 332738 in OSS / SAPNet). This is the minimal authorization profile needed for a user to execute transaction RRMX and run the BEx queries.

S_RS_MPRO

Overview

With this authorization object you can restrict working with MultiProviders or their sub-objects.

Defined Fields

The object includes four fields:

• InfoArea: Here you specify the key for the InfoArea, for which a user is allowed to edit the MultiProvider

• MultiProvider: The MultiProviders that you specify here are allowed to be edited by a user.

• Subobject for the Multiprovider: With this sub-object you specify the part of the MutliProvider that the user is allowed to edit. There are the following sub-objects:


o ExportDS Export-DataSource

• Activity: determines whether you are allowed to display, delete, maintain, or update a sub-object.

o Display MultiProvider definition (Activity = 03)

o Maintain MultiProvider definition (Activity = 23)

o Maintain MultiProvider Export-DataSource (Activity = 23)

Example:




ABCD

S_RS_ISET

Overview

You can restrict working with InfoSets with this authorization object.

Defined Fields


• InfoArea: Enter the key of the InfoArea for which a user may edit Infosets here.

• InfoSet: Enter the name of the InfoSet here.

• Activity: Define if you may display, delete, or maintain the InfoSet.

o Display the InfoSet object definition (Activity = 03)

o Maintain the InfoSet object definition (create, delete, change) (Activity = 23)

• Subobject for InfoSet: With the sub-object you specify the part of the InfoSet that is edited by the user. There are the following sub-objects:

o Definition: Definition

o Data: Data

S_RFC

Overview

You use the authorization object to perform RFC (remote function call) for the BEx Analyzer or BEx Browser only.

8. Reporting Security Strategy

In R/3, security is focused around detailed information in purchasing groups, company codes, cost centers, plants, or business areas. These are key fields that may be an integral part of a security strategy. It may be important for users to view more results in BI than they can see in R/3. If a user executes a query and only receives results from company code 1000, then they can only make business decisions based on that one company code. In order to discover important trends, they may need to see data from all company codes.

Before implementing security, the level of security needs to be in line with the goals of the business.

Any role for a reporting user must have the S_RS_COMP and S_RS_COMP1 authorization objects, as well as the authorization objects related to the InfoProvider on which the query is based. This would also be for the following: S_RS_ICUBE for an InfoCube or S_RS_MPRO for a MultiProvider.

1 Securing by InfoCube




ABCD This option is for securing reporting users by dividing them into groups. Optimal if the authorizations only need to be checked at the InfoCube level. Roles can be created that allow you to run queries from specified InfoCubes.

2 Securing by Query

This option would be to use the InfoCube in conjunction with the query name. Strict naming conventions should be in place so that security does not have to be updated when queries are created.

3 Securing at the InfoObject Level

If securing users by InfoCube or Queries is not sufficient, it is optional to secure down to the InfoObject level. This security method is if you want two users to execute the same query, but to get different results based on their assigned division, cost center, or some other InfoObject. This option is the closest parallel to the field-level security that is traditional to R/3.

3A Steps to Implement InfoObject Security

1 Define the InfoObject as authorization relevant.

• This setting can be selected in the InfoObject definition on the Business Explorer tab. The business needs to drive which InfoObjects should be relevant for security.

2 Creating a customer reporting authorization object

• Since there are no reporting authorization objects provided for InfoObjects, you will have to create your own reporting authorization object for any InfoObject you decide to secure. This is done using transaction RSSM. When creating a reporting authorization object, you select which fields to put in the authorization object from a list of authorization relevant InfoObjects (see #1).

• Business ExplorerAuthorizationsReporting Authorization Objects

3 Add a variable to the query.

• The reason the variable is required is sometimes unclear. If we want a query to only provide results based on the division, then the query itself needs the ability to filter specific division values. Before you can secure on division, the query must be able to restrict data by division. This is done using a variable.

4 Link the reporting authorization object to an InfoProvider

• This is a very critical step. This will impact people currently executing queries for the InfoProvider that is now related to the reporting authorization object that was just created. This linkage forces the reporting authorization object to be checked when ANY query tied to the InfoProvider is executed.

3B Creating Authorizations in Role Maintenance

1 Transaction code PFCG, specify roles to be changed.

2 Authorizations TabChange authorization dataEnter authorization objects manually

3 Enter the appropriate field values for the authorization objects that were added. Generate




ABCD

9. BI Audit Program Guide - Suggested Controls

Activity Control Risk Testing

Secure BW Reporting Users

Access to modify sensitive BW Reporting is restricted

Users can maintain queries and generate inaccurate results

Identify queries that should have restricted access. Access to the following authorization objects and values allows a user to maintain queries Execute SUIM for the following objects: S_RS_COMP1 Activity: 2 (change) Name (ID) of a reporting component: “query name” or ‘*’ for all queries S_RS_COMP Activity: 2 (change) Name (ID) of a reporting component: “query name”




ABCD Activity Control Risk Testing

Secure BW Administration Users

Control Objective: Controls should be in place to ensure that BW Administration Users have appropriate access.

Unauthorized changes to objects may result in inaccurate queries

Test 1: Execute SUIM for the following: Transaction: RSA1 Authorization object: S_RS_ADMWB Activity 23, 06 (maintain all objects) Guidance: This list should contain a very low number of users, only system administrators Test 2: Execute SUIM for the following: Transaction: RSA1 Authorization object: S_RS_IOBJ Activity 23, 06 (displays a list of users who can maintain info objects only, however you must exclude users identified in the list above) Guidance: This list should be relatively low, only users who manage their own info objects

Secure User BWREMOTE

Access to User BWREMOTE is correct to receive data from an OLTP system

BW connections may change and generate inaccurate reporting

Execute SUIM and determine which uses have Profile: S_BI-WHM_RFC Guidance: List should be low and restricted to system administrators

Secure User BWALEREMOTE

Access to User BWREMOTE is correct to connect and send to the BW system

BW connections may change and generate inaccurate reporting

Execute SUIM and determine which uses have Profile: S_BI-WX_RFC Guidance: List should be low and restricted to system administrators





Secure BW developers

BW developers have appropriate access in the Production system.

BW Developers may generate roles and authorizations bypassing the transport process

Execute SUIM and determine which uses have access to transaction: PFCG S_USER_GRP Activity: 02 S_USER_PRO Activity: 02 Guidance: No users should have access to change roles in Production.

BW Hierarchies & Authorization Objects

BW authorization objects are configured and controlled correctly

BW authorization objects may not be checked when users execute transaction codes.

Execute SUIM and determine which uses have access to Transaction RSSM Info Object S_RS_HIER Activity: 23 (maintain) Guidance: No users should have access to change heirarchy or maintain authorization objects in Production. Access should only be allowed in Development

Info Object Maintenance

Only authorized users have access to mark objects as relevant for authorization (InfoObject Maintenance)

BW authorization objects may not be checked when users execute transaction codes.

Execute SUIM and determine which uses have access to Transaction RSD1 Info Object S_RS_HIER Activity: 23 (maintain)

Guidance: List should be low and restricted to system administrators or security





BW Workbooks Only authorized users have access to

maintain tables

Unauthorized changes to SAP tables may lead to inaccurate data

Step1: Execute SUIM and determine which uses have access to Transaction LISTCUBE Step2: Execute SUIM and determine which uses have access to Transaction: SE16 or SM31 Auth Object: S_TABU_DIS Activity: 02 Guidance: No user should have access to maintain tables in production

BW Access

Only authorized users have the ability to maintain users and user access

Unauthorized user access may result in inaccurate system data

Execute SUIM and determine which uses have access to Transaction: SU01 Auth Object: S_USER_GRP Activity 01,02,06 (create,change,delete) Guidance: Should be restricted to security administrators

Transport Organizer

Only authorized users can transport development objects

Unauthorized changes may be transported to production

Execute SUIM and determine which uses have access to Transactions: SE01, STMS Authorization Object: S_TRANSPRT Activities: 1,2, 43, 60 Guidance: Should be restricted to basis admins who are responsible for performing transports





Configuration Access to configure the IMG is

restricted Unauthorized changes to the system configuration IMG could occur and provide inaccurate data

Execute SUIM and determine which uses have access to Transaction: SPRO Auth Object: S_IMG_ACTV Activity: 02 Authorization: ACT Auth Object: S_PROJECT Activity 01 or 02 Guidance: Access should be restricted to display only in Production. This goes together with the system change settings control below. If system change is incorrect, unauthorized changes could occur in SPRO.

System Connections

Only authorized users have ability to maintain system connections is restricted based on business need:

System reporting may be inaccurate if system connections to host SAP data system is incorrect

Execute SUIM and determine which uses have access to Transaction SM59 Auth Object: S_ADMI_FCD Activity value NADM Guidance: Should be restricted to system administrators.

Programs The ability to run system programs is restricted

Unauthorized use of executing or changing programs may impact system credibility, data integrity and system performance

Execute SUIM and determine which uses have access to Transaction SE38 Auth Object: S_DEVELOP Activity 01 or 02 And Auth Object: S_PROGRAM User Action: SUBMIT Guidance: Access should be restricted to system administrators or a limited number of users. Best if no users have access in Production.





System Change Option

Global system change option is appropriately configured.

Incorrect system global settings may allow unauthorized changes in the production environment that will impact data integrity

Execute SUIM and determine which uses have access to Transaction SE06. Auth Object: S_TRANSPRT Activities: 01, 02 And review access for: Transaction: SCC4 Auth Object S_TABU_DIS Activity: 02 Guidance: Access should be restricted to system administrators only and should have an audit log attached to determine when the system is opened and changed.

SAP ALL No users should have access to SAP_ALL Profile

User will have no restrictions and may cause data integrity issues

Execute SUIM and determine which uses have access to Profile: SAP_ALL Guidance: No users under any circumstances should have access to SAP_ALL if they are a dialogue user ID. Determine if client made a copy of SAP_ALL and is using similar access under another role or profile.

10. Version History

Version # Date Version History Author 1.0 3/11/2009 First Version for Publication Jared D. Krueger




ABCD

____________________________________________________________________________________________________________________

11. Sources:

1 SAP Training Class TBI40 Data Modeling and Security

2 SAP Business Intelligence Security by Gary Morris

3 http://help.sap.com

4 http://sap.ittoolbox.com

5 http://www.sapsecurityonline.com

http://sap.ittoolbox.com/�

SAP Business Intelligence WhitePaper

Documents

Transcript of SAP Business Intelligence WhitePaper