securing-data-with-data-access-controls-a032e51.md

Securing Data with Data Access Controls

Users with a space administrator role can create data access controls to allow modelers to apply row-level security to Data Builder and Business Builder objects. Once a data access control is applied to an object, any user viewing its data either directly or via an object using it as a source, will see only those records they are authorized to view, based on the specified criteria.

This topic contains the following sections:

• Permissions Entities
• Data Access Control Best Practices
• Applying Data Access Controls
• Data Access Control Example

Permissions Entities

Your criteria are defined in a table or view that lists SAP Datasphere user IDs (in the form required by your identity provider) and assigns them to one or more criteria. You can define the following types of criteria:

• Single Values - Each user can only see the records that match any of the single values she is authorized for in the permissions entity. See Create a "Single Values" Data Access Control.
• Operator and Values - Each user can only see the records that fulfill the operator-value pairs she is authorized for in the permissions entity, including support for complex AND and OR combinations. See Create an "Operator and Values" Data Access Control.
• Hierarchy - Each user can only see the records that match the hierarchy values she is authorized for in the permissions entity, along with any of their descendants. See Create a "Hierarchy" Data Access Control
• Hierarchy with Directory - Each user can only see the records that match the hierarchy values she is authorized for in the permissions entity, along with any of their descendants. See Create a "Hierarchy with Directory" Data Access Control.

You can create one or more data access controls that consume each permissions entity, and select one or more columns in each data access control to specify the criteria that it will enforce. You can apply a single data access control to multiple views. Each view protected in this way will filter the results available in its data preview to only those rows meeting the criteria for the current user.

Note:

Permissions entities must not, themselves, be protected by a data access control, or have any protected view among their sources.

Data Access Control Best Practices

We recommend that you develop clear policies for securing data, and that you:

• Focus in particular on securing transactional data and sensitive master data.

• Avoid applying multiple data access controls to a view if possible.

• Secure data as soon as possible once it is ingested into SAP Datasphere and then only use the protected view going forward, keeping the following factors in mind as you plan your modeling strategy for security and performance:

  • Encapsulating individual source tables in views and applying data access controls to them:

    • Improves performance by filtering records immediately, as fewer go forward for subsequent preparation.
    • Can impact performance when any view that combines multiple sources is run, by increasing the number of data access controls that must be applied.
    • Can impact performance by excluding the possibility of persisting subsequent views, since views cannot be persisted if any of their sources is protected by a data access control.

  • Doing initial processing and joining separate data sources before applying a single, more targeted data access control to the result:

    • Improves performance by applying only a single data access control to a combined view.
    • Improves performance by allowing the use of persistence at any stage during the preparation.
    • Can impact performance as more records will pass through each stage of the data preparation.

• When using Operator and Values data access controls, try to control the size of the permissions entity and, in particular, avoid having more than 5,000 permissions records for a single user:

  • Consider applying the filter against a different column that could simplify calculation.
  • You can use the * operator to provide access to all records.

Note:

The row-level security provided by the data access control can be circumvented while the view remains in its space. It is enforced only when the view is:

• Shared to another space, or
• Consumed outside the space in SAP Analytics Cloud.

Applying Data Access Controls

For information about:

• Applying a data access control to a view, see Apply a Data Access Control to a Graphical or SQL View ↗️.

  Note:

  For information about persisting data in a view that has a data access control applied to it, see Persisted Views and Data Access Control.

• Applying a data access control to an analytic model, see Apply a Data Access Control to an Analytic Model ↗️

  Note:

  For analytic models containing standard, reference date, or X variables, mapping a data access control to a dimension attribute is not supported.

• Using a data access control to create authorization scenarios in the business layer, see Authorization Scenario ↗️.

Note:

If you experience performance issues with a view protected by a data access control, we recommend enabling replication for source tables, particularly if any source contains more than 500,000 rows.

Data Access Control Example

This diagram shows a typical environment where a permissions entity is maintained by business users in one space and shared to a second space, where technical users create data access controls from it and apply them to views. These views are then shared to other spaces where they can be securely accessed by modelers and analysts:

In this environment:

• The Permissions space users are a select group of business users who:

  • Maintain the Permissions table, assigning users (which, in this case, are identified by their email address) to the appropriate country, department, and any other relevant criteria:

    User ID	Country	Department
    [email protected]	US	Sales
    [email protected]	FR	Sales

  • Share the Permissions table to the IT space to use as a data source for data access controls.

    Note:

    Tables and views shared to a space cannot be directly used as the permissions entity for a data access control. Modelers in the space receiving the shared object must encapsulate it in a view, which can then serve as the permissions entity for one or more data access controls.

• The IT space users are technical users who:

  • Use the shared Permissions table as the source for a Permissions view that they will use as a permissions entity in their space.

  • Create a Country data access control, which uses the Permissions view as its permissions entity.

  • Maintain a connection to a source system, from which they import the Sales table.

  • Create a Sales view for use by business analysts, to which they apply the Country data access control.

    Note:

    The row-level security provided by the Country data access control can still be circumvented while the view remains in the IT space.

  • Share the Sales view to the Sales space where it can be used securely.

• The Sales space users use the protected Sales view to do analytics on sales data:

  • Anne is a data modeler in the US sales department. She connects to SAP Datasphere and combines the Sales view with other data. Whenever she previews data, she can only see US data.
  • Jennifer is a business analyst in the French sales department. She connects to SAP Analytics Cloud, builds a story on the Sales view, and can only see French sales data.