USER MANUALS

Limit Indirect Access to Views Shared with Other Development Teams

In multi-layered virtual models with several development teams, defining restrictions at intermediate layers may be unavoidable: different layers may be managed by different teams with different security concerns and the owners of the views in a given layer may need to ensure that the data of their views is not inadequately exposed by views in the higher layers.

In this scenario, it is easy to lose control of which data is accessible from the final users. So you could be interested in changing the behavior of the security model to avoid that giving access on a view is also transferring the ability to grant privileges to other users over that data. There are two alternative ways to do this:

  1. Using Global Security Policies.

  2. Or using the Indirect Access privilege (see the section below).

Limit Indirect Access to Shared Views Using Global Security Policies

The Denodo Enterprise Plus subscription bundle includes tag-based security policies that allows to easily define an allowlist of selected users or roles that can have indirect access to these views, and therefore restrict the visibility for any user or role that is not included in the list. Visit section “Allow indirect access to a restricted list of roles” of the article Best Practices in Designing Fine-Grained Privileged in Multi-layered Virtual Models to see an example of this approach.

Limit Indirect Access to Shared Views Using the Indirect Access Privilege

Denodo includes an alternative way to limit this access that does not require using Global Security Policies. It includes a new INDIRECT_ACCESS privilege that can be granted to roles on specific views.

Let’s illustrate this feature using the example from the first section.

You could grant INDIRECT_ACCESS privilege on EMPLOYEE view to HR role, so:

  • Users from HR could execute queries using the EMPLOYEE view.

  • Users from HR could create new views using the employee information.

  • Users from HR could grant EXECUTE privilege on a derived view(which uses the employee information) to the SALES department.

  • Users from SALES could execute the derived view but all data from EMPLOYEE view will be restricted to them until INDIRECT_ACCESS is granted to SALES.

Note

Keep the following considerations in mind when implementing this security model:

  • This feature is disabled by default at server level (previous behavior is the default one).

  • Once the feature is enabled at server level, it must be enabled for a specific view.

  • Once the feature is enabled for a specific view, the INDIRECT_ACCESS privilege can be granted to roles in order to define which users will retrieve the data of the specific view executing other views which query data from this view somehow.

Let’s see how to implement this step by step:

  1. First, this feature must be enabled at server level in Administration > Server Configuration > Privileges and check the option Allow Indirect access by default.

../../../../_images/indirect_access_server_configuration.png

  1. Roles that include these privileges could be configured for a specific view or procedure clicking the tab privileges in the detail pane of view/procedure and check the option Restrict indirect access. You could select the roles that will have this privilege.

../../../../_images/indirect_access_view_privileges.png

Another option to configure the privilege is going to the Administration > Role Management option, select a role and click on the button Assign Privileges. Click on the edit button of advanced privileges column for the database and then click on the button of the column indirect access for the element that is going to be changed. This column show a check for the elements that have configured the grant indirect_access.

../../../../_images/indirect_access_roles.png
Add feedback