GRC TABLES

  Let's dive into some of the tables available for SAP GRC.

GRACFUNC - Function

GRACFUNCT - Function Description Translations

GRACFUNCACT - Function Action Relationship

GRACFUNCPRM - Function Action Permission relationship

GRACSODRISKFUNC - SOD Risk Function Relationship

GRACRULESET - Rule Set

GRACRULESETT - Rule Set Description

GRACORGRULE - Organization Rules

GRACACTRULE - SOD Action Rule Detail

GRACSODRISKT - SOD Risk Description

GRACSODRISK - SOD Risk

GRACSODRISKOWN - SOD Risk Owner

GRACMITROLE - Role mitigating control assignment

GRACMITUSER - User mitigating control assignment

GRACCRPROFILE - Critical Profile Rule

GRACCRROLE - Critical Role Rule

GRACBPROC - Business Process

GRACBPROT - Business Process Description

GRACMGRISKD - Risk Analysis Management Sum data for Batch Risk Analysis.

HRP5320 - Defined mitigation controls

GRACUSERPRMVL - User Permission Violation Table

GRACFFLOG - Details related to Firefighter ID Log On Information

GRACFFREPMAPP - FFLOG and Repository Mapping for Firefighters

GRACACTUSAGE - Action Usage

GRACAUDITLOG - Security Audit Log table

GRACSYSTEMLOG - System Security Log table

GRACCHANGELOG - Data Change Log table

GRACREASONCOD - Master table for Reason Codes

GRACREASONSYS - Reason Code and System assignments

GRACFFCTRL - Maintain assignment of FF ID or Role to Controllers

GRACFFOBJECT - Maintain SPM Firefighter ID and Role details

GRACFFUSER - Maintain SPM Firefighter Assignment to FF ID/Roles

GRACROLE - Role

GRACROLEAPPRVR - Role Approver

GRACROLESTATUS - Role Status Table

GRACROLETYPE - Role Type Table

GRACMTH - GRC Methodology

GRACMTHT - GRC ERM Methodology Text

GRACREQ - Request Header

GRACREQPROVITEM - Line Items Associated with Request

GRACREQUSER - User Associated with Request

GRACEUPCONFIG - End User Personalization Fields

GRFNMWCNPATH - MSMP Path

GRFNMWCNROUTE - MSMP Route Mapping

GRFNMWCNSDEF - MSMP Stage Definition

GRFNMWRTAPPR - Current approver of Access Request (GRFNMWRTSTAPPR only during runtime)

SWWUSERWI - Task ID assigned to users

HRUS_D2 - Delegation table

Security Fiori important Tables , T-codes and Queries

  Important T-codes:

/UI2/FLPD_CUST - Launchpad Designer (can add/remove catalogue/group/Tile/TM  -Browser view)

/UI2/FLPCM_CUST - FLP content manager (ADD/Remove Tiles from catalogue) (maintain catalogue present in role)  (SAP GUI view)

/UI2/FLPCAT -Fiori catalogue maintenance

/UI2/FLPCA- Launchpad content aggregator (roles vs catalogue)

SCTS_HTA - Transport HANA Studio role changes (add security package and execute)

Important Tables :

USOBHASH - Table Service name(Field: Object name) vs HASH value(Field: Name)

AGR_BUFFI - Catalogue vs Role, Group vs Role , Hash Value Vs Role

HANADB SQL Queries -

1) To get details of error GUID code

call sys.get_insufficient_privilege_error_details('GUID' , ? )

2) AGR_USERS -

select grantee, role_name from granted_roles;

select * from granted_roles;

select * from granted_roles where role_name like '%SECURITY_Y%'

select grantee, role_name from granted_roles where  grantee in ('Gitesh') and role_name <> 'PUBLIC';

3)USR02

Select * from users;

4)To find Roles having access to Root package/particular package-

Select Grantee from Granted_privileges where OBJECT_NAME= '.REPO_PACKAGE_ROOT'

Project plan for conversion from ECC to S4Hana

 Let's dive deeper into each phase of the ECC to SAP S/4HANA migration project plan:

Phase 1: Planning (Weeks 1-4)

- Define project scope, goals, and timeline

- Identify stakeholders and their roles

- Develop a detailed project schedule

- Establish a budget and resource plan

- Define project governance and decision-making processes

Phase 2: Assessment and Preparation (Weeks 5-12)

- Analyze current ECC system landscape and identify:

    - Customization and integration points

    - Data quality and cleansing requirements

    - Business process and workflow changes

- Develop a data migration strategy

- Set up a test environment for S/4HANA

- Install and configure S/4HANA sandbox system

Phase 3: System Setup and Configuration (Weeks 13-20)

- Install and configure S/4HANA production system

- Set up organizational structures and master data

- Configure business processes and workflows

- Integrate with other systems (e.g., CRM, SCM)

- Develop customizations (if necessary)

Phase 4: Data Migration (Weeks 21-28)

- Migrate data from ECC to S/4HANA using:

    - SAP Data Migration Cockpit

    - SAP LT Replication Server

    - Other tools and methods

- Validate data quality and integrity

- Perform data reconciliation

Phase 5: Testing and Quality Assurance (Weeks 29-36)

- Develop test cases and scenarios

- Perform:

    - Unit testing

    - Integration testing

    - System testing

    - User acceptance testing (UAT)

- Identify and fix defects

Phase 6: Deployment and Go-Live (Weeks 37-40)

- Finalize deployment preparations

- Execute go-live activities

- Provide post-go-live support

Phase 7: Hypercare and Optimization (Weeks 41-52)

- Provide hypercare support

- Monitor system performance

- Identify optimization opportunities

- Implement post-go-live enhancements

Additionally, consider the following best practices:

- Engage stakeholders and end-users throughout the project

- Develop a comprehensive training plan

- Establish a change management process

- Monitor and report on project progress

- Identify and mitigate risks

SAP Security Interview Questions and Answers

 
Fiori and HANA DB

1. What is different type of deployment model? - Hub vs Embedded
HUB:
Developers can make changes to the UI without worrying about the back-end development authorizations.
A single point of access is provided to multiple back-end systems; 
it supports the composition and routing of multiple back-end systems, as well.
Because there’s no direct access to the back-end data, you can benefit from enhanced security.
The lifecycle of UI applications can be decoupled from the back-end.
Production scenarios with medium to high loads are supported.

The only disadvantage of this kind of deployment is that it needs an additional server for SAP Gateway.

Embedded:
The advantages of using an embedded deployment include the following:
No additional system for SAP Gateway is required.
Direct access is provided to the business data and business logic.
Only one remote call to the SAP system is necessary.

Disadvantages of using this deployment option include the following:
Production use is only suitable for low-load production systems  not for medium to high loads.
SAP Gateway must be configured on every system when multiple SAP Business Suite systems are used.
Components can only be upgraded during system maintenance;

2.       Types of Tile/Apps in Fiori? 
Transactional(Tcode based) vs Analytic(provide business insight using complex algo(Sales            order fulfillment)) vs Navigation (itself an app navigated to/from another app)

3.       What is Tile, groups and catalogue (Technical and business) ?
Tile is container that represents an app on Fiori launchpad, so its used to display and launch App
A catalog is a set of Tiles / Applications you want to make available for one role.
Technical catalog act as a repository of tiles and target mappings. 
Business catalog contain references to the tiles and target mappings defined in technical      Catalogs.
A Group is a subset of Applications from one or more catalogs

4.       T-code to activate services in Fiori? /N/IWFND/MAINT_SERVICE 

5.    What is Target Mapping? 
you map a navigation target to the combination of a semantic object and an action, also         known as an intent.

 6.   A semantic object represents a business entity such as a customer, a sales order, or a             product, supplier. Using semantic objects, you can bundle applications that reflect a specific         scenario.
   
7       Mandatory Basic services to load Fiori Launchpad? 
Page Builder, Interop, Easy Access Menu and User Menu 

8.     What is OData services? front end and backend name? - IWSG (front) & IWSV(back)
 OData is a resource-based web protocol for querying and updating data.

9.      What are diff type of role in HANA? -
Design time(Repository) and Run time(Catalog role)

10.  Diff type of HANA privileges?

11.   What is diff BW on HANA and Bw4HANA?

12.   Why has SAP provided Spaces and Pages concept over Group and Catalogue?

13.   What is the main advantage of using Spaces and Pages in Fiori? 

BI Security -
1.       What is different level of access in hierarchy type characteristics?
2.       Table for analysis auth?
3.       What is Colon (:) and Hash (#) in AA?
4.       Diff Auth object to execute query in BW? -  S_RS_COMP, S_RA_COMP1, A_RS_FOLD
5.       Auth Object to Restrict Query access? S_RS_AUTH
6.       step by step BI security? - https://blogs.sap.com/2009/02/26/step-by-step-sap-bi-security

ECC Security-
1.       What is diff between su24 and su25?
2.       Steps of su25?
3.       Custom T-code creation process?
4.       Auth objects used for table access.
5.       Monthly activities to perform in system
6.       Difference between S_PROGRAM and S_DEVELOP
7.       Critical Auth object in security? S_ADMIN_FCD (Spool admin), S_DATASET (OS file)
S_DEVELOP (Debug access), S_USER_GRP, S_USER_AUTH, S_USER_PRO
8.       Background job auth objects? S_BTCH_ADM, S_BTCH_NAM, S_BTCH_JOB
9.       how to delete a role?
10.   Difference between Data/Enabler role vs Task Role?
11.   Imp tables for derived, composite and single roles?
12.   What happen if we transport role along with user assignment? If user exist/not exist in receiver
13.   What is difference between composite role and business Role
14.   What are the audit activities u know
15.   How to find user email id in ECC
16.   What are diff types of licenses SAP Grant
17.   What is diff between user group in address and group tab in SU01?
18.   What is diff in SUIM for searching T-code in Transaction and Auth object using S_Tcode?
19.   What is the use of personalization tab
20.   What is diff between role and profile
21.   What are different colour code in PFCG
22.   diff modes of PFCG? - when they used
23.   Diff type of Org fields in SAP
24.   t-code to create custom T-code? - SE93
25.   T-code to Transport? and how transport works in SAP? Data Files and Co-files
26.   Type of Transport request? - Custom, Workbench, TOC

GRC
1.       Critical action vs critical permission
2.       What is risk? And its type
3.       Diff stages of MSMP? And how it flows
4.       Where to keep the notification mgs? Se61
5.       What are fields present in end user personalization?
6.       What are diff types of GRC Sync jobs
7.       Max number of functions for a risk in GRC?5
8.       How to make/process for custom risk in GRC?
9.       What is diff between centralize and decentralize FFID
10.   Advantage and disadvantage of types of FFID
11.   How to make sure if user is not login with FFID in plugin system
12.   What is Remediation and Mitigation
13.   How to set the mitigation controller/ID? assign to Risk
14.   What are FFowner, FF controller, FFusers
15.   What are diff FF Parameter
16.   What is diff between FF id based and Role based
17. SOD Examples

VA01-creation of sale order vs VF01 - approving sales order
PA30- HR master data vs PA03 - Payroll Control Record
FB60- posting vendor invoice vs FK02 (Vendor master data)

Miscellaneous-
http://basisandsecurity.blogspot.com/2015/07/sap-security-interview-questions-and.html
Will Add further on this-

BW 7.4 To BW/4HANA Security Auth Conversion Steps In Details (Remote Conversion)

1.    Objective

With SAP BW/4HANA, SAP has re-architected its solution for modern data warehousing processes that the ever-increasing digitization of the world demands. Re-architecting a solution that has been growing over the past 20 years and has, at points, evolved into different data structures and architectures means that we also have to decide on one data structure and architecture as we move forward. This is the only way that we can prepare the solution for increased simplicity and faster innovation cycles.

The purpose of this document is to explain the end-to-end Authorization conversion process with which you can transition from your existing SAP Business Warehouse to the next-generation data warehouse solution: SAP BW/4HANA.

2.    Description

SAP provides three paths for the conversion from SAP BW to SAP BW/4HANA, the so-called “In-place Conversion”, “Remote Conversion”, and “Shell Conversion”.

The Remote Conversion approach enables you to move whole data flow or transfer only selected data flows including the data from SAP BW 7.3 with any DB to a new installation of SAP BW/4HANA. You are able decide whether you want to build a clean system, leave old and unused objects behind, and reduce unnecessary layers of your data warehouse. If applicable, the Remote Conversion process includes a Unicode conversion. Carve-out scenarios are also supported.

The Remote Conversion is available for SAP BW 7.3 and later releases. Among other ad- vantages, this approach only includes objects that will remain relevant going forward and saves you the effort of converting your database. It thus represents the chance to build a clean system, leave old and unused objects behind while migrating to SAP BW/4HANA system.

      The simplification of object types in SAP BW/4HANA has an impact on authorization objects. When converting a SAP BW system to a SAP BW/4HANA, authorizations for object types that are not available in SAP BW/4HANA (like Info Cubes) must be replaced by authorizations for corresponding object types (like ADSO).  

3.    Transfer Cockpit (RSB4HCONV)

The Authorization Transfer Tool uses the existing roles in your system. It will create copies of these roles while preserving original ones. Conversion rules for authorization objects are then applied on top of these role copies. After the conversion of objects using the Scope Transfer Tool, both original and created roles will be assigned to the users. After confirmation of authorization object conversion and a successful system conversion to SAP BW/4HANA, you can then remove original roles manually.

Any required actions on the authorization objects can be carried out only after the transfer of their corresponding SAP BW objects is done in the system via the BW/4HANA transfer toolbox. (especially for object types adjust and replace). The transfer of the SAP BW object must be done usi7ng the Scope Transfer Tool. The transfer runs will provide the information required to adjust or replace the authorization objects in the selected roles:

·       Mapping of new names and types of converted Info Providers, transformations, etc.

·       Names of additional Info Providers created (e.g., Composite Provider for Datastore objects (advanced) with navigational attributes)

4.    System Landscape   

 

Sender system Name	BW 7.4
Receiver system Name	BW4HANA
Target OS version	SLES 15 Sp01
Hana DB version (Target DB)	HANA 2.0 SP05 Rev 53
Source System Application	NETWEAVER 7.4
Target System Application	BW/4HANA 2.0 SP08

 

5.    Prerequisite

5.1.   Understanding Sender System

User Master data details to be exported in excel to replicate in Target Sandbox from Sender system like user address data, user role mapping sheet, list of analysis authorizations

To execute the object conversion process using the BW/4HANA transfer toolbox (transaction RSB4HTRF), SAP recommend adding few authorization objects and values as in reference note 2383530.This SAP template role will be required in all BW systems in the landscape as the BW/4HANA conversion needs to be executed.

Master Role will contain all DMIS related Authorization that is requires in Sender system environment for running BW4HANA Cockpit Once implemented, please assign only to project team members responsible for the conversion of the BW objects.

The SAP template role details in present in note 2280336. For our project we have created custom role below 

5.2.   SAP BW/4HANA Conversion Cockpit Execution Users

SAP BW/4HANA Conversion Cockpit Execution user access required for the SAP BW/4HANA Conversion Cockpit. This is a composite role for execution expert users with complete project administration authorizations. It contains the authorizations required in source environment by project Team members 

5.3.   Communication RFC User

The SAP BW/4HANA Conversion Cockpit does not come with fixed destinations or usernames. An RFC destination from the original SAP BW system and target SAP BW/4HANA system needs to be created using process tree step “Define RFC Destination”. Users in RFC destinations need to have the require authorizations in sender and target as specified in the Excel

5.4.   SAPOSS Connection User

SAP BW needs to open SAP connection to connect to SAP for that creation of SAPOSS User id and Role as per suggestion given by SAP in sender. Refer link http://wiki.scn.sap.com/wiki/x/EQlSGQ for details Auth required.

5.5.   Delta Authorizations required in BW4 Environment

Several Delta Authorizations created as part of migration activity in Target environment that is required by developer to work for the scope collection and remediation task. These are created based on the requirement from BW and BPC project admin Team.

5.6.1       BW4HANA Modeler Role

The BW/4HANA Modeler connects source systems, model’s data flows, performs data transfer processes, and schedules process chains. This takes place in the development system.

The BW/4HANA Modeler role has the following authorizations:

•         Create/change/delete data flows, Info Objects, Info Providers (Datastore object, Composite Provider, Open ODS view), transformations, data transfer processes and process chains in the BW Modeling tools and on the back end

•         Administration of Info Providers

•         Execute data transfer processes

•         Schedule process chains

•         Transport objects on existing transport requests

5.6.2       ABAP Developer role

The role is required to use the BW Modeling Tools. Role that contains all authorizations to display and browse ABAP development objects. it is mainly used by BW and BPC folks for Remediation purpose in the Target Environment. This role can only be assigned to folks involving in Remediation.

5.6.3       BW/BPC Delta Auth Role

There are several Authorizations which are not present in Modeler either in BW support maintenance and those are required as part of migration for Scope collection, Migration and Remediation Purpose of BW/BPC Developer. Those all authorizations are collected in BW delta role and BPC Delta Role which will finally merge in Modeler role for BW and BPC respectively

6.    Preparing Transfers of Standard Authorizations

            6.1 Conversion Rules of Authorization Objects

Conversion from SAP BW to SAP BW/4HANA also requires conversion of authorization objects, SAP have defined four types of actions that need to be applied for respective authorization objects impacted by the conversion process using the BW/4HANA transfer toolbox and the migration to BW/4HANA:

·       Assume – Nothing to do. Authorizations will continue to work after conversion

·       Adjust – Check and adapt values of authorization objects

·       Replace – Change authorization object and adapt its values

·       Obsolete – Not needed/supported authorization object that should be remove

SAP NOTE 2468657 shows the authorizations objects used in SAP BW and not available in SAP BW/4HANA. The SAP BW/4HANA Transfer Cockpit provides an Authorization Transfer Tool to automate the transfer of existing security roles

            6.2 Copy Principle

The Authorization Transfer Tool uses already existing roles in your system. It will create copies of these roles while preserving original ones. Conversion rules for authorization objects are then applied on top of these role copies. After the conversion of objects using the Scope Transfer Tool, both original and created roles will be assigned to the users. After confirmation of authorization object conversion and a successful system conversion to SAP BW/4HANA, you can remove original roles.

              

7.    HANA DB Privileges

When a user accesses the SAP HANA database using a client interface (for example, ODBC, JDBC, or HTTP), his or her ability to perform database operations on database objects is determined by the privileges that he or she has been granted.

All the privileges granted to a user, either directly or indirectly through roles, are combined. This means that whenever a user tries to access an object, the system performs an authorization check on the user, the user's roles, and directly granted privileges. It is not possible to explicitly deny privileges. This means that the system does not need to check all the user's privileges. As soon as all requested privileges have been found, the system skips further checks and grants access. Several privilege types are used in SAP HANA (system, object, analytic, package, and application)

8.    Realization

 

8.1  Transport Analysis Auth And Roles

Transport the user master data from Sender system – Sender systems new target sandbox BW/4HANA along with user assignment.

8.2  Validating Analysis Authorizations and Roles

Check and confirm if all Auth Relevant Characteristics and roles exist in Target Environment also make sure all AA is activated in Target system.

8.3  Standard Transfer Auth

Execute program RS_B4HTAU_CREATE_RUN for creation of run Id and execution of Standard Transfer Authorizations using SE38

8.4  Run Id

Create a Run ID (Reciever_RUNID1) run id is a name for bunch of roles we need to convert at a same time

8.5  Suffix settings

Perform the initial setting for user assignment and the suffix to be used for newly created roles. Here we have used BW4 as suffix for new roles

8.6  Original Roles

Select and upload original roles (SAP BW Roles) that needs to be converted. Below are the roles       

8.7  Execute the Initial run

For each role, a new mapping name is created, and the role is scanned for authorization objects with defined “assume” or “obsolete” rules.

8.8  BW Object Migration

Wait for the BW team for completion of the BW/4HANA object migration before starting Delta Execution

8.9  Execute Delta Run

After the successful transfer of objects using the Scope Transfer Tool, the transfer of standard authorizations must be completed using a delta run.

The system will retrieve the details of related scope transfer runs and scan the original roles for authorization objects with defined “adjust” or “replace” rules. Authorization objects with “replace” rule are checked for conflicts. Then the roles copies are adjusted according to the defined rules.

8.10                Generate Target Roles

The system will generate the new roles and offers the possibility assign them to the same users as the corresponding original roles. the newly created roles with Suffix B4H in Target BW/4HANA system.

8.11                Review the prepared mapped roles and authorizations

Review and compare the roles which are newly created vs the once present in sender BW system. Also check and confirm the necessary actions have been taken on objects in SAP Note 2468657

Once the complete system is converted to SAP BW/4HANA, you should delete the original roles (they are inconsistent anyway, since they contain obsolete authorization objects).

8.12                 Enhancement 

Adjust the newly created BW objects (Info Providers) in Analysis Authorization manually in converted security BW4Hana support roles.

Once the complete system is converted to SAP BW/4HANA, you should delete the original roles (they are inconsistent anyway, since they contain obsolete authorization objects).

9.    Finalization

All the SECURITY activities for Remote Conversion have been captured in this document.

10. References

SAP BW4HANA 2.0 Conversion Guide and Experience

https://help.sap.com/doc/999ae5f8c578402dab1fea94fa4599f9/2.0/en-US/SAP_BW4HANA_20_Conversion_Guide.pdf

 

 Please Comment for feedback :)