At the SAPinsider 2020 virtual conference experience, one of our product demo attendees asked how Appsian works with SAP GRC Access Control. We get this question a lot as SAP security and system professionals explore adding attribute-based access controls (ABAC) to the native SAP role-based access controls (RBAC) to streamline and strengthen access policy management and enforcement. Sometimes there is confusion about whether ABAC is enhancing or replacing their RBAC. Let’s take a quick look at how Appsian’s ABAC works with and enhances SAP GRC Access Control.
What is SAP GRC Access Control
Organizations use SAP Governance, Risk, and Compliance (SAP GRC) to manage regulations and compliance and remove any risk in managing critical operations. One of the SAP GRC modules that helps organizations meet data security and authorization standards is SAP GRC Access Control. This module ensures that the right access is given to the right people with RBAC. It uses templates and workflow-driven access requests and approvals to streamline the process of managing and validating user access and provisioning. Without SAP GRC, for comparison, a person is creating all the roles from scratch and assigning privileges to them.
Appsian Enhances SAP GRC with Attribute-Based Access Controls
Appsian combines the SAP GRC role-based access controls with an attribute-based access control solution that delivers an ABAC + RBAC hybrid approach. This enhanced approach enables granular control and visibility that delivers a wide range of business benefits and lets you deploy data-centric security policies that leverage the context of access to reduce risk.
Appsian overcomes the limitations of traditional RBAC, allowing you to fully align SAP security policies with the objectives of your business and streamline audits and compliance.
As you can see in this illustration, ABAC begins the moment users start to access data and transactions. Where RBAC assigns access based specific roles, ABAC considers the context of access (who, what, where, when, and how) before allowing access to transactions or data. Customers can set up additional rules that allow conditional access, for example, masking specific data fields or limiting the number of transactions after a particular time of day) or entirely denying access based on factors such as an unknown IP address.
Real-Time Analytics for SAP Security & Risk Management
With Appsian360, our real-time analytics and reporting tool, Appsian can enhance the SAP GRC reporting capabilities with direct, real-time visibility into transaction usage, violations, and compliance risk. Additionally, customers can:
- Monitor transaction usage, master data changes, and SoD violations
- View actual SoD violations with user, data, and transaction correlation
- Segment reports by user/data attributes
- Drill down into end-user usage events
Appsian360 provides analytical reports to drill down into end-user usage events to capture business risks and anomalies, and usage events that tie back to compliance risks.
The ABAC + RBAC Hybrid Approach to SAP GRC Access Control
By combining data-centric security capabilities with attribute-based policies, Appsian extends and enhances the existing SAP GRC internal access controls and improves the reporting and auditing capabilities.
Contact us today and schedule a demo to see how Appsian can help you enforce access controls beyond the standard RBAC model of SAP.
Secure, compliant, and efficient business processes are critical to enterprise operations. In SAP, Segregation of Duties (SoD) is a key principle in making this possible.
What happens when an SoD exception is necessary?
Often times a user will need to be granted roles and privileges that pose a conflict of interest. It could be that an employee is part of a small department, or that a security clearance precludes others from involvement. Whatever the reason, this user needs the ability to handle multiple steps in a business process – and an exception is made.
Here’s where things can get tricky. Once an SoD exception is made, your standard preventive controls are no longer effective. This is one of the major shortfalls of SAP’s static, role-based access controls.
Shifting from a preventive approach to a detective approach…
… you must now gather access logs, filter out false-positives, and finally, send to the appropriate control owner to review and sign-off. Besides the additional overhead of manual reviews and approvals, detective controls create room for human error and increase the dwell time before red flags are caught.
So why are current SAP SoD Controls limited?
Without the logic ability to decipher potential violations from actual violations, preventive controls are a non-starter. Your (preventive) SAP access controls determine authorizations based on two things: 1.) a user’s role and 2.) the role’s associated permissions (think transactions.) While this works in the vast majority of cases, enforcing SoD requires controls with more granularity.
Let’s take a look at what an actual SoD violation entails
The whole objective of SoD is to avoid conflicts of interest in your business processes. Although, conflicting transactions do not necessarily pose a conflict of interest, unless the subject is the same.
For example, a user performs the transactions to create and approve multiple purchase orders. Looking at the transactions themselves, this activity has the potential for violations. Looking deeper into the PO details, you may see that the user never created and approved the same PO – therefore no violation was made.
SAP can show you 1.) the user and role, and 2.) the transactions performed, but is missing the 3rd component: the field-level values in the PO itself. This lack of visibility into attributes beyond roles and permissions is what makes preventive controls a non-starter and clutters SoD audit logs with false-positives when exceptions have been made.
The Solution? Enforcing SoD Policy with Attribute-Based Access Controls
Attribute-Based Access Controls (ABAC) enable the use of “attributes” in authorization decisions. These attributes can be anything from user details such as role, department, nationality, or even a user’s security clearance level. Additionally, access context such as IP address, location, time, device and transaction history can be considered. And most importantly for SoD, data attributes can now be used in authorization logic. This means that field-level values within SAP can be used to determine whether to block or allow a transaction, and these details can further be used in reporting activities.
In the Purchase Order example above, data attributes can be used to identify whether a user performed the first transaction and make the correlation that performing the second transaction would result in a violation.
Combining SAP’s role-based access controls (RBAC) with an attribute-based access control (ABAC) solution enables granular control and visibility that delivers a wide range of business benefits.
Newfound Flexibility in SoD Exception Scenarios – RBAC + ABAC Hybrid Approach
The RBAC + ABAC hybrid approach opens the possibility to apply preventive controls in SoD exception scenarios. By doing so, you can offer users the flexibility an exception provides while still preventing any actual violations from happening.
Together, this hybrid approach (RBAC + ABAC) enables a dynamic SoD model that prevents violations while still allowing the flexibility of conflicting roles to be assigned (when necessary) and reinforces role-based policy to mitigate over-provisioning.
RBAC + ABAC Hybrid Approach Using Appsian
Appsian adds an additional authorization layer to SAP GRC Access Control that correlates user, data and transaction attributes, along with identified SoD conflicts, to block conflicting transactions at runtime.
Contact Us to learn more about how a hybrid access control approach can strengthen Segregation of Duties (SoD) at your organization.