Secure data from certain users via locking out specific dimensions

Description

To ensure information security, features enabling the locking out of specific dimensions can be used. This process involves applying restrictions to a specific dimension like department, not allowing users who are assigned to a specific department the ability to view data intersections outside of that.

Example Use Case

Scenario: A mid-market corporation utilizes planning software to develop an Annual Operating Plan in collaboration with various department heads. Within the corporation, specific sensitive data like financial earnings or human resources information should only be accessible to the manager of that specific department.

Solution: Implementing the feature of locking out specific dimensions, access to earnings can be restricted only to the finance department and the department manager for one specific department. This broad rule ensures that the user is unable to exploit any role assignment mistakes that may have been made by admins when the system was setup.

Considerations

The core benefit of using a dimension to set access rules is the broad nature of it. For example, if the user is not allowed to see anything outside of the dimension Product and member SKU123, that is very simple to enforce. It does not rely on any intricate security permissions, nor does it require the administrator to touch several sheets with custom rules.

This requires a tool that not only allows the dimensions to be used as a security mechanism, but also the children of the dimension, otherwise knowns as members. In the department example, Department is the name of the dimension with Marketing, Sales, Operations, IT and so on being members.

Questions to Ask a Vendor

• User Roles: Can we apply a specific role to a dimension, or just individual people? What about specific groupings in a dimension hierarchy? (Department / Sales (this is the group) / West, East, Marketing)
• Data Integrity: Does securing data through locking out specific dimensions create any problems access problems with the rest of the model?
• Exceptions to the Rule: If one of the department heads is allowed higher-level access, how do we manage that exception?