Displaying sensitive data
Structural authorizations
When creating the permission concept, a naming convention is defined for PFCG roles. Every customer has his own preferences or specifications, which must be adhered to. According to our project experience, some naming conventions are particularly attractive. Naming conventions for PFCG roles can be very diverse. You will have noticed that even the roles provided by SAP do not correspond to a uniform naming convention. So there are roles whose names start with SAP_. There are also roles, such as for the SRM system, that start with the /SAPSRM/ namespace. In this tip we would like to give you some hints and criteria that you can use to help define a naming convention of PFCG roles.
To define table permissions in the PFCG transaction, it is not necessarily sufficient to specify the generic table display tools, such as the SE16 or SM30 transactions, in the role menu. The proposed values for these transactions are very general and only provide for the use of the S_TABU_DIS or S_TABU_CLI authorization objects. Explicit values must be entered depending on the tables that you have selected for permission. To explicitly grant access to the tables through the S_TABU_NAM authorization object, you can create a parameter transaction for each table access. For example, a parameter transaction allows you to call tables through the SE16 transaction without having to specify the table name in the selection screen because it is skipped. You can then maintain suggestion values for the parameter transaction you created.
Authorizations in SAP BW, HANA and BW/4HANA
The goal of an authorization concept is to provide each user with the appropriate authorizations in the system individually for their tasks according to a previously defined rule. For this purpose, an authorization concept must be defined as the foundation for efficient authorization assignment. In this way, each employee is given system access through the role-specific assignment of authorizations according to his or her tasks. On the one hand, this protects sensitive information and, on the other, prevents damage caused by incorrect use of data.
You should archive all document types at the same time intervals; This is especially true for the US_USER and US_PASS archive objects. It is customary to keep the supporting documents between 12 and 18 months, as this corresponds to the retention periods for the revision. For performance reasons, if you want to archive in shorter intervals, you should always archive all archive objects at the same time and store the PFCG and IDENTITY archive object classes in separate archives. In this case, it may be useful to download the archived revision documents back to a shadow database to make them available for faster review. You can use the following reports: RSUSR_LOAD_FROM_ARCH_PROF_AUTH / RSUSR_LOAD_FROM_ARCHIVE. You can also archive the table change logs with the BC_DBLOGS archive object.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
It may also be that you only use one sales organisation in your company and would therefore like to define the sales office.
You can customise the AIS cockpit to your needs.