| « SOX Compliance - How to Select controls for SOX Testing | Basics of Function Modules in SAP ABAP » |
Security Strategy in BW Vs SAP R/3 ECC
Security Strategy in BW Vs SAP R/3 ECC
SAP BW turns data stored in SAP R/3 into more reportable knowledge. SAP BW is not about creating or updating data, but it is about turning the data into information for decision making. As with SAP R/3 where security is controlled via authorizations, in SAP BW implementation as well, security is a key aspect of BW model implementation. SAP BW Security is not focused on transaction codes or actions that can be executed by users, but is more focused on the data itself. To put this in a structure, SAP BW security focuses on the key areas within BW which are:
- Info Areas
- Info Provides including BW Infocubes
- BW Queries
It is clear on the above that SAP BW Security is focused on what data can be accessed by the user, The main use of BW is to analyze information and summarize this information in an Infocube. This data is not updated by the end user. The data to be analyzed is accessed by the user in the InfoProvider by using a reporting tool such as BEx Analyzer. InfoProviders in BW are a classification of objects that can provide data to a BW query such as Infocubles or ODS objects. The Infocube contains data the summarized data that can then be analyzed by the user. Results of the query are based on the data in the InfoCube / ODS Object. BW Transaction code RRMX is one of the key transaction codes to analyze data.
So how does a company differentiate between its security strategy for SAP BW as against tackling security within SAP R/3. In ECC 6.0 security is detailed around company codes, document types, sales organizations, purchasing organizations, plants, business areas and so on. Authorization restrictions are relevant at the transaction code level as well as at authorization object level to prevent users from creating, changing, or viewing data with the ACTVT field.
However, one has to take a different approach for BW security as compared to R/3. To take an example, in BW it is key to look at lets say which company codes can a user access. A BW query can provide a restrictive view if the user has access to only a select set of company
codes. The user may only be able to make decisions for that particular company code only. When a user executes a query, and they have access to only one company code 1000, the query will return data for that company code only. This may be valid in a scenario, where there are
multiple company codes per geography and data across each should not be shared. It is important that the security strategy be planned at the onset of the BW implementation. This has a major impact on how BW report, queries will work in the future and how these may be secured. Even in BW, report and queries can be secured at the company code level, purchasing organisation level etc, but a thorough consideration must be given as to how this will fit in with the overall security strategy for the company in their system landscape.
Related Posts on SAP BW
BW Certification Exam Questions
SAP BW Application Consultant
SAP BW Reporting Agent Configuration
Feedback awaiting moderation
This post has 4 feedbacks awaiting moderation...