SAP Business Intelligence Whitepaper

SAP Business Intelligence White Paper v1.0.
doc
ABCD
SAP Business Intelligence (BI)
SAP Business Intelligence Overview of Authorizations & Controls
Author: Jared D. Krueger

jdkrueger@kpmg.com
March 11, 2009
Version 1.0
Page 1 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.
SAP Business Intelligence White Paper v1.0.doc
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
Page 2 of 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.
Page 3 of 32
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
Page 4 of 32
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.
Page 5 of 32
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
Page 6 of 32
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.
Page 7 of 32
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 • 01 Create
• STR: Structure • 02 Change
• CKF: Calculated key figure • 03 Display
• RKF: Restricted key figure • 06 Delete
• VAR: Variables
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:
Page 8 of 32
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
Page 9 of 32
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)
Page 10 of 32
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: '*'
Page 11 of 32
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
• 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)
Page 12 of 32
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
Page 13 of 32
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
Page 14 of 32
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)
Page 15 of 32
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).
Page 16 of 32
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)
Page 17 of 32
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:
Page 18 of 32
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
Page 19 of 32
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
Page 20 of 32
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
Page 21 of 32
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
Page 22 of 32
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:
Page 23 of 32
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
Page 24 of 32
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 ExplorerAuthorizationsReporting 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 TabChange authorization dataEnter authorization objects manually
3 Enter the appropriate field values for the authorization objects that were added. Generate
Page 25 of 32
ABCD
9. BI Audit Program Guide - Suggested Controls
Activity Control Risk Testing
Secure BW Access to modify sensitive BW Users can maintain queries Identify queries that should
Reporting Reporting is restricted and generate inaccurate have restricted access.
Users results 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”
Page 26 of 32
ABCD
Secure BW Control Objective: Controls should Unauthorized changes to Test 1:

Administration be in place to ensure that BW objects may result in Execute SUIM for the
Users Administration Users have appropriate inaccurate queries following:
access.
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 Access to User BWREMOTE is BW connections may Execute SUIM and determine
BWREMOTE correct to receive data from an OLTP change and generate which uses have Profile:
system inaccurate reporting S_BI-WHM_RFC
Guidance: List should be low

and restricted to system
administrators
Secure User Access to User BWREMOTE is BW connections may Execute SUIM and determine
BWALEREMOT correct to connect and send to the BW change and generate which uses have Profile:
E system inaccurate reporting S_BI-WX_RFC

administrators
Page 27 of 32
ABCD
Secure BW BW developers have appropriate BW Developers may Execute SUIM and determine
developers access in the Production system. generate roles and which uses have access to
authorizations bypassing transaction: PFCG
the transport process
S_USER_GRP
Activity: 02
S_USER_PRO
Activity: 02
Guidance: No users should

have access to change roles in
Production.
BW Hierarchies BW authorization objects are BW authorization objects Execute SUIM and determine
& Authorization configured and controlled correctly may not be checked when which uses have access to
Objects users execute transaction Transaction RSSM
codes. 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 Only authorized users have access to BW authorization objects Execute SUIM and determine
Maintenance mark objects as relevant for may not be checked when which uses have access to
authorization (InfoObject users execute transaction Transaction RSD1
Maintenance)
codes. Info Object S_RS_HIER
Activity: 23 (maintain)

administrators or security
Page 28 of 32
ABCD
BW Workbooks Only authorized users have access to Unauthorized changes to Step1:

maintain tables SAP tables may lead to Execute SUIM and determine
inaccurate data 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
Only authorized users have the ability Unauthorized user access Execute SUIM and determine
BW Access to maintain users and user access may result in inaccurate which uses have access to
system data Transaction: SU01
Auth Object: S_USER_GRP
Activity 01,02,06
(create,change,delete)
Guidance: Should be restricted

to security administrators
Transport Only authorized users can transport Unauthorized changes may Execute SUIM and determine
Organizer development objects be transported to production which uses have access to
Transactions: SE01, STMS
Authorization Object:
S_TRANSPRT
Activities: 1,2, 43, 60

to basis admins who are
responsible for performing
transports
Page 29 of 32
ABCD
Configuration Access to configure the IMG is Unauthorized changes to Execute SUIM and determine
restricted the system configuration which uses have access to
IMG could occur and Transaction: SPRO
provide inaccurate data 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 Only authorized users have ability to System reporting may be Execute SUIM and determine
Connections maintain system connections is inaccurate if system which uses have access to
restricted based on business need: connections to host SAP Transaction SM59
data system is incorrect Auth Object: S_ADMI_FCD
Activity value NADM

to system administrators.
Programs The ability to run system programs is Unauthorized use of Execute SUIM and determine
restricted executing or changing which uses have access to
programs may impact Transaction SE38
system credibility, data Auth Object: S_DEVELOP
integrity and system Activity 01 or 02
performance And
Auth Object: S_PROGRAM
User Action: SUBMIT

restricted to system
administrators or a limited
number of users. Best if no
users have access in
Production.
Page 30 of 32
ABCD
System Change Global system change option is Incorrect system global Execute SUIM and determine
Option appropriately configured. settings may allow which uses have access to
unauthorized changes in the Transaction SE06.
production environment that Auth Object: S_TRANSPRT
will impact data integrity Activities: 01, 02
And review access for:
Transaction: SCC4
Auth Object S_TABU_DIS
Activity: 02

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 User will have no Execute SUIM and determine
SAP_ALL Profile restrictions and may cause which uses have access to
data integrity issues 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
Page 31 of 32
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
Page 32 of 32

SAP Business Intelligence Whitepaper

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Business Intelligence Whitepaper

Uploaded by

Copyright:

Available Formats

SAP Business Intelligence White Paper v1.0.

SAP Business Intelligence (BI)

SAP Business Intelligence Overview of Authorizations & Controls

Author: Jared D. Krueger

Key areas BI supports:

When looking at BI there are 3 major areas:

How are reports generated?

*For further information on security see Section 7

• Increased business visibility and performance to make faster decisions.

Component Types Component Type Activities

7. BI Authorization Objects & Security

Reporting Security Authorization Objects

• 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)

o Query (Type = REP)

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

• 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.

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

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

Relevant authorization for user A:

Component type: 'REP'

Component type: 'STR', 'CKF'

The object contains four fields:

o Calculated key figure (Type = CKF)

o Restricted key figure (Type = RKF)

o Structure (Type = STR)

o Query (Type = REP)

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

o Currently checked for query views.

• 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)

The object contains a field:

• 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

The object contains two fields:

o SourceSys Source system

o ApplComp Application component

o Workbench Administrator Workbench

o MetaData Meta data

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

o Display source system (activity = 03)

o Display InfoObject (activity = 03)