Introduction:
Data Access Controls in SAP Datasphere help manage the access rights of users. They make sure your information stays safe and correct. As more data is made and passed around, it is of highest importance to have strong rules to keep sensitive info safe from people who shouldn't see it. In this blog, we will talk about why these controls matter, how they help, and why they are vital for keeping your data secure.
To explore a diverse range of scenarios, a rather "lite version" of the data model described in the SAP blog titled "SAP Datasphere Analytic Model Series – Data Model Introduction" is used. The dataset mentioned and shared in the SAP blog is filed here. It allows to test and analyze the effectiveness of different scenarios within different contexts. Let's check out the scenarios and gain insights into the diverse outcomes they produced.
Data Model:
As mentioned above the following files were imported in order to have sample data and a sample view.
Having successfully imported the tables, a view has been created in SAP Datasphere with these tables to explore diverse data access scenarios. Please be aware that this view is primarily for testing data access scenarios and may not be implemented in the most optimal form from business perspective.
View 1: Main View created in SAP Datasphere including some of the tables from the article
Let's walk through the scenarios and observe how SAP Datasphere responds.
Scenario 1:
Table 1 Users_Salesorg: Username and sales organization
DAC 1: Permission Entity is Users_salesorg and Identifier Column is the username
Once we add this DAC into our Main View (see first View 1), the user is only allowed to see the data specific to the permitted sales organizations. The following table shows the results of which data is allowed to be accessed and as we can see, only the according sales organizations are depicted.
Result 1: Main View result table after adding DAC 1 as access right rule.
As stated earlier, the preceding example served as a foundational starting point. Moving forward, we will delve into more detailed scenarios.
Scenario 2:
In this scenario, we assume that the user has access to two different sales organizations and to product category 3.
Table 2: Username, sales organization and product category
And the result is as expected, the user can only see the data related to sales organization 463 and 949 and product category 3. Any other data is not accessible.
Result 2: Main View result table after adding the above mentioned Table 2 as Access Right rule.
Scenario 3:
In the following Scenario I tested if there is a possibility to add user roles into SAP Datasphere since user roles are an essential aspect of any system or platform that involves multiple users.
Instead of individually assigning permissions to each user, administrators can assign roles that includes a set of predefined permissions. This simplifies the process of granting or revoking access, as administrators only need to manage roles rather than individual user permissions. Consequently, the corresponding access rights are automatically extended to all users assigned to the same user roles.
To efficiently handle user roles, I have created a user role table. Within this table, I've added user roles UR1 and UR2, along with the sales organization and product category.
Table 3: User Role, Sales Organization and Product Category
Table 4: User and User Role
To merge the user role table with the user table I joined them within a view.
View 2: User roles and user list joined
The result table shows the correct values that are accessible for me with user role UR1. This shows that user roles in SAP Datasphere are possible and easy to maintain.
Result 3: User Role result table after adding the above mentioned view as access right rule.
Scenario 4:
Continuing our exploration, I conducted an assessment of the interaction between two DACs when both are applied to the same view. Will the system prioritize the first DAC, or will the most recent DAC override the earlier one? Hence, two DACs are concurrently integrated within a single view, providing insights into how they influence each other.
In Table 5, you can observe the initial table where I've implemented a restriction, allowing the user access only to sales organization 949. I have embedded this table in one DAC and labeled it as "SalesOrg DAC".
Table 5: Username and Sales Organization
For the second DAC, I've used the User Role DAC mentioned earlier, which I've labeled as "User Role DAC."
View 3: User Role View used as second access right restriction
First, I added "SalesOrg DAC" in the Main View, and then I added the "UserRole DAC." When I checked the data as in Result 4, there was no data showing. I tried the reverse order too, starting with the "UserRole DAC" and then adding the "SalesOrg DAC," but still, there was no data as shown in Result 5. This confirms that data access is working correctly according to the expected process since one DAC should not override the other.
Result 4: No data available
Result 5: No data available
Scenario 5:
In this scenario I want to test what happens if I use wildcards such as "*", " ", "null". By implementing wildcards for data access, we will test whether users are able to see and access all data within the system. This approach helps evaluate the effectiveness of the data access controls and identify any potential gaps or vulnerabilities in the security measures.
However, it is important to note that granting unrestricted access to all data may not be suitable or recommended in most scenarios. It is generally advisable to define specific filters and restrictions based on user roles, organizational requirements, and data sensitivity to ensure proper data governance and security.
Let's see what happens if we put the data access table with the wildcard on top of the previous view.
Table 6: Wildcard table with username, Sales Organization and Product Category
As shown in Result 6, none of the aforementioned wildcards are functioning with the wildcard DAC. Using wildcards can sometimes lead to unintended or inaccurate results, and they might not provide the precision required for specific queries. The fact that wildcards are not working in SAP Datasphere can be considered advantageous. This limitation encourages users to adopt more precise and controlled search methods, promoting accurate and reliable results in their data analysis processes.
Result 6: Invalid number: SQL Error
Conclusion
The exploration of data access controls within SAP Datasphere has highlighted the critical role they play in ensuring the security, integrity, and controlled access to sensitive data. Through a series of scenarios involving different access scenarios and data models, we have gained valuable insights into the capabilities of these controls.
Overall, the scenarios showcased the effectiveness and flexibility of data access controls in SAP Datasphere. By leveraging these controls, organizations can ensure data security, adhere to compliance regulations, and facilitate efficient collaboration among users with varying levels of access.
- SAP Managed Tags:
