Understanding Rulebook Logic
Rulebooks are a collection of rules that determine what type of access is considered a risk. They can contain both SEN and SoD rules. To determine risks, rules use business functions and their related permissions to identify potentially risky access.
Rulebook Definitions
-
Rules: The possible combinations of transactions and permissions that compose a business risk. Sensitive access rules are made up of one business function. SoD rules have two or more business functions.
-
Business functions: Collections of access that provide the ability to perform activities associated with part of a potentially risky action. Each business function contains permissions represented through transaction codes and authorization objects that define access.
-
Transaction codes: Transaction codes used when executing a task. Transaction codes, or TCodes, are the first authority check performed as part of an analysis and are used to group the related authorization objects associated with the access in a business function.
-
Authorization objects: Objects containing authorization fields and values that represent data and activities. These are used to grant and check authorizations down to the most granular level. Authorization objects are grouped together and can be edited in the TCode.
You can view your rulebook information down to the authorization values in the Rulebook Dashboard.
The following logic examples demonstrate how these objects work together to create rules that identify risks.
TCode Logic
TCode logic is used to determine if all, or just one, of the transaction codes are required for a user or role to access the business function.
To view the TCode and object logic of a business function, select the Info icon next to the business function name.
For example, if a business function has 2 TCodes and their related authorizations, and the TCode logic is set to OR, then the user or role will have access to that business function if they have the first or the second TCode.
If the logic is set to AND, then the user or role will need both transaction codes to have access to the business function.
Authorization Object Logic
Object logic is used to determine if all, or just one, of the authorization objects are required for a user or role to have access to the transaction code.
If the logic is AND, all authorization objects are required.
If the logic is OR, then only one of the authorization objects is required.
The example above shows the TCode SE38 and its authorization objects. There are 2 different objects.
If the object logic is set to OR, the user or role will have access to TCode SE38 if they have the object S_PROGRAM or S_DEVELOP. If the logic is set to AND they will need both authorization objects.
Field and Value Logic
There is also field and value logic, which is used to determine the field and value criteria for a user or role to have access to the authorization object.
Logic is set for the fields and the values as follows:
-
Within the Same Field Value - A user can have any of the values. The example above shows an OR between ACTVT 01 and 02 for auth object F_BKPR_KOA.
-
Between Different Field Values - A user needs to have access to a value from each of the fields. The example above shows an OR for ACTVT 01 and 02 and an AND between fields ACTVT and KOART for auth object F_BKPF_KOA.
-
For this user to be considered as having access to auth object F_BKPF_KOA, they need KOART K AND (ACTVT 01 OR ACTVT 02).
Documentation Feedback
Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.