Global Security Policies

Global Security Policies allow you to define security restrictions that apply to all/some users over all/several views that verify certain conditions.

Global policies are easier to manage than view restrictions (Row Restrictions and Column Privileges) because when the same security policy applies to several views, you can define it once instead of having to assign it to multiple views.

Global policies are often used together with “Tags”, which are labels that you can assign to views and their columns. For instance, you can define a global policy so only the users with a certain role can query the views that have the tag “secret”. You can also define a global policy that masks all the columns that have the tag “confidential”.

Note

This feature is only available with the subscription bundle Enterprise Plus. To find out the bundle you have, open the About dialog of the Design Studio or the Administration Tool. See more about this in the section Denodo Platform - Subscription Bundles.

Note

Currently, the tags of Virtual DataPort are not related to the tags of Data Catalog.

Tags Management

Tags in Virtual DataPort are labels that you assign to views and their columns. They can be used to:

  • Define global security policies that apply to multiple views and columns.

  • It is another way of organizing and browsing the views for the users of Design Studio and the Administration Tool (not for other tools).

To manage the tags, click Tags on the left panel of the Administration Tool or Design Studio. Expand the tags to see the elements that are tagged with them. From this panel, you can create, edit and remove tags, and assign tags to views and their columns.

Tags management: Tags explorer

Tags management: Tags explorer

To create a tag click the menu File > New > Tag. Enter the name of the tag and its description.

Tags management: Create tags

Tags management: Create tags

To modify a tag, locate it on the Tags tree and open it. In this dialog you can do this:

  • Rename the tag and change its description.

  • Assign tags to views. To do this, click the Tagged views tab, click the tree to display the list of views and drag the view to the panel Tagged views.

  • Assign tags to columns. To do this, click Tagged Columns. In Design Studio, drag a view and in the popup, select the columns to tag. In the Administration Tool, drag the column.

  • To remove a tag from a view or a column, go to Tagged views or Tagged Columns and use the contextual menu.

Tags management: Tag assignation (Web Design Studio)

Tags management: Tag assignation (Web Design Studio)

Removing Tags

To remove a tag open the tag and click Drop. Consider this:

  • The global security policies that use this tag will be removed as well. The user must have the required privileges to remove these global security policies.

  • The tag will be unassigned from the views that have this tag assigned.

Privileges Required to Manage and Assign/Unassign Tags

Administrators are not affected by the following restrictions; they can create, modify and delete any tag and assign it to any view, use it in a global policy, etc.

  • You need the role manage_tags to create tags, change their description and remove them. If the tag is assigned to a view or a global policy, you also need certain privileges over said element (see below).

  • The privileges required to assign and unassign a tag to a view or to a column of a view are:

    1. The user is an administrator of the database of the view.

    2. Or, the user has the role assign_tags and the privilege “METADATA” over the view.

    These rules apply even if the user is the owner of the view. That is, the owner of the view may be able to create and modify a view but may not be allowed to modify the tags of said view.

  • When removing a tag that is used in a global policy, the global policy is deleted as well so you need the necessary privileges to do that as well.

Global Security Policy

A global security policy represents a definition of privileges over views from a general vision. With this type of element, you are allowed to create restrictions on views working with abstract concepts, instead of with individual views or fields. You can specify to who the global security policy applies based on what user is executing a query or based on her roles. Also, you can refine the who specifying conditions based on attributes of the user’s session. Then, you define to what elements does the policy applies to using tags. Finally, you specify the applied restrictions which are also expressed with tags (including the optional conditions when required).

Examples

Example #1

We have a view with the addresses of customers and we do not want users with role “developers” to see these columns. We can add tags to that view for specifying the semantic.

Global security policies: View with assigned tags (example 1)

View with assigned tags

Tags added to view “address”:

  • View tagged as “locations”.

  • Fields “address”, “district” and “city_id” tagged as “location”.

  • Field “postal_code” tagged as “zip_code”.

  • Field “phone” tagged as “phone_number”.

Now, we create a Global Security Policy indicating that users with the role “developers”, accessing to views tagged with “locations” must mask fields tagged with tags “location”, “zip_code” or “phone_number”.

Global security policies: Developers masking policy example

Developers masking policy example

Since now, when users with “developers” role access to views tagged with “locations” will see data masked for fields tagged with “location”, “zip_code” or “phone_number”.

Global security policies: User with developers role (example 1)

User with developers role

Example #2

We want to apply a new restriction to users with “developers” role. They must see only rows from locations which are at certain zones. For example, we only want them to see rows from California and Florida. We need to tag the column which has that information and create a Global Security Policy with required restriction.

Global security policies: View with assigned tags (example 2)

View with assigned tags

We modified tags added to view “address” with:

  • Field “district” also tagged with “zone”.

Now, we create a Global Security Policy named “developers_filter_data” indicating that users with “developers” role, accessing to views tagged with “locations” must only see rows that fulfill the condition that “zone” is California or Florida.

Global security policies: Developers filter rows policy example

Developers filter rows policy example

Note

Condition is expressed using tags.

Since now, when users with “developers” role access to views tagged with “locations” will see only rows that fulfill the condition. Also, data from fields tagged with “location”, “zip_code” or “phone_number” are masked due to the Global Security Policy created at first example.

Global security policies: User with developers role (example 2)

User with developers role

Note

More than one Global Security Policy are applied.

Example #3

We have a view with information about payments. We do not want that users with role “developers” can executed this view. We can add a tag to the view and then create a Global Security Policy denying the execution to desired roles.

Global security policies: View with assigned tags (example 3)

View with assigned tags

Tags added to view “payment”:

  • View tagged as “confidential”.

Now, we create a Global Security Policy named “developers_deny_views” indicating that users with “developers” role are not allowed to execute views tagged with “confidential”.

Global security policies: Developers denying policy example

Developers denying policy example

Since now, users with “developers” role do not have access to views tagged with “confidential”.

Global security policies: User with developers role (example 3)

User with developers role

Example #4

Now, we want to modify previous Global Security Policy developers_deny_views for denying the execution for users with role developers based on some session attributes. We want to deny when they access to the view with a client different than the Virtual DataPort Administration Tool and from a client IP different than 127.0.0.*.

We have to add the following session attributes conditions:

Global security policies: User with developers role and session attributes (example 4)

User with developers role and session attributes

The Global Security Policy will be triggered for users with developers role connects from an accessInterface different than VDP-AdminTool and from a clientIp not like 127.0.0.% (note the % for the like operator syntax).

The access to the view, for example, is available when the user connects with the Virtual DataPort Administration Tool from any IP. Also, it is available when the user connects with Web Design Studio from a IP like 127.0.0.1.

Global security policies: User with developers role and session attributes connecting from 127.0.0.1 (example 4)

User with developers role and session attributes connecting from 127.0.0.1

But the view is not accessible when the users with developers role connect with Web Design Studio from a IP different than 127.0.0.%.

Global security policies: User with developers role and session attributes connecting from an IP not like 127.0.0.% (example 4)

User with developers role and session attributes connecting from an IP not like 127.0.0.%

Note that Global Security Policy is enabled when both session attributes do not satisfy the conditions.

Global Security Policies Management

To create a global security policy, click the menu Administration > Semantics and governance > Global security policies.

In this dialog, you can enable or disable all the policies at once.

Global security policies: Global security policies management

Global security policies

Creating a Global Security Policy

Click New to create a Global Security Policy and provide the following information:

Global security policies: Creating global security policies

Creating a Global Security Policy

  • Name. Name of the new Policy.

  • Description. A description of the Global Security Policy.

  • Enabled. Indicates if the Global Security Policy will be used on execution. This is useful to disable temporarily a policy.

  • Audience. Indicates to who the Global Security Policy applies to. The options are:

    • All. The policy applies to all the users. Generated restrictions are combined as an AND with the restrictions from the current user and her roles.

    • Any role in list. It applies to every user which has at least one of the selected roles. Generated restrictions are combined as an AND with the restrictions from the roles which triggered the Global Security Policy.

    • All roles in list. It applies to every user which has all the selected roles. Generated restrictions are combined as an AND with the restrictions from the roles which triggered the Global Security Policy.

    • Roles not in list. It applies to every user that has roles which are not present at the selected ones. Generated restrictions are combined as an AND with the restrictions from the roles which triggered the Global Security Policy.

    • User not in list. It applies to every user which is not at the selected list. Generated restrictions are combined as an AND with the restrictions from the current user.

    • Any user in list. It applies to every user which is at the selected list. Generated restrictions are combined as an AND with the restrictions from the current user.

    • Attributes of the user’s session. If the Global Security Policy depends on them, then the specified conditions will be checked. The Global Security Policy applies if these conditions are also verified.

      • Apply the policy to the audience that satisfies any of these conditions. It applies to every user when her current session satisfies at least one of the specified attribute conditions.

      • Apply the policy to the audience that satisfies all these conditions. It applies to every user when her current session satisfies all the specified attribute conditions.

      • Apply the policy to the audience that fails to meet all these conditions. It applies to every user when her current session does not satisfy any of the specified attribute conditions.

  • Elements. Indicates to what elements the Global Security Policy applies to. Note that elements are referenced using tags, not individually. The options are:

    • All views. It applies to every view.

    • Views tagged with any. It applies to every view tagged with at least one tag from the list.

    • Views tagged with all. It applies to every view tagged with all tags from the list.

    • Views not tagged with. It applies to every view not tagged with at least one tag from the list.

    • Columns tagged with any. It applies to every view with some column tagged with at least one tag from the list.

    • Columns tagged with all. It applies to every view with some column tagged with all tags from the list.

    • Columns not tagged with. It applies to every view with some column not tagged with at least one tag from the list.

      Finally, the affected elements can be restricted to a list of databases.

  • Restrictions. This is the applied restriction when the Global Security Policy is triggered. The options are:

    • Deny execution. A privileges error accessing the view will be thrown.

    • Mask columns tagged with any of these tags. Fields from the view tagged with at least one tag from the list will be masked. The condition is optional (tags can be used).

    • Mask columns tagged with all of these tags. Fields from the view tagged with all tags from the list will be masked. The condition is optional (tags can be used).

    • Only show rows that fulfill condition. Returned rows will be filtered using a condition. The condition is mandatory (tags can be used).

    • Custom view policy. A custom view policy is executed. The section Custom Policies of the Developer Guide explains what they are and how to develop them.

    • Deny execution if (any tag). A privileges error accessing the view if there is some column with at least a tag from the list.

    • Deny execution if (all tag). A privileges error accessing the view if there is some column with every tag from the list.

    • Only show rows that fulfill condition if (any tag). Returned rows will be filtered using a condition if there is some column with at least a tag from the list. The condition is mandatory (tags can be used).

    • Only show rows that fulfill condition if (all tags). Returned rows will be filtered using a condition if there is some column with every tag from the list. The condition is mandatory (tags can be used).

    • Condition. These are the conditions applied when the restriction is executed. The user will see the rows or data that fulfill them. They are expressed using tags, except in the case of using a subselect. In such case, the subselect is processed as a normal query.

Operators for session attributes conditions:

You can specify use the following operators:

  • = an equals operation is done between the specified value and the attribute value from the user session.

  • contains condition is satisfied if the specified value is contained on the attribute value from the user session. In case of the session attribute has more than one value (a list), the condition is satisfied if the specified value is contained at least by one of the session attribute values.

  • in condition is satisfied if the specified value is equals to the attribute value from the user session. In case of the session attribute has more than one value (a list), the condition is satisfied if the specified value is equals to at least one of the session attribute values.

  • like condition is satisfied if the specified pattern value matches with the attribute value from the user session. In case of the session attribute has more than one value (a list), the condition is satisfied if the specified pattern value matches with at least one of the session attribute values.

Combination with restrictions by user or role

Restrictions generated by Global Security Policies will be combined with restrictions defined at Row Restrictions, depending on the type of audience which triggered the Global Security Policy.

By type of audience:

  • All: restrictions from the Global Security Policy will be concatenated as an AND with the restrictions defined to the user and her roles.

  • By role: restrictions from the Global Security Policy will be concatenated as an AND with the restrictions defined to the role which triggered the Global Security Policy.

  • By user: restrictions from the Global Security Policy will be concatenated as an AND with the restrictions defined to the user which triggered the Global Security Policy.

If the user or role has a masking restriction defined at Row Restrictions, that masking expression is used for the affected fields.

For example, let us say you have this:

  • A view “employees” with a column that has the tag “region”.

  • A role “developers” with a row restriction that in the view “employees”, replaces the values of the column “salary” with “-1”.

  • A Global Security Policy that applies to any of these roles: “marketing” and “developers” (i.e. “Audience = Any role in list”) and only returns the rows tagged by “region” with the value “USA”.

When a user with the role “developers” connects to Virtual DataPort, this policy is triggered and this will happen: So, the role developers for current execution will have these restrictions:

  • Masking the column salary (due to the Row Restrictions).

  • Filtering the columns tagged as region with the value USA (due to the Global Security Policy)

Notes about Masking

As tagged fields could have any Virtual DataPort type, we allow to configure a different masking per general type. Also, we have a set of built-in masking expressions for being selected depending on the type. For more information about built-in custom masking expressions you could refer to Row Restrictions.

When there are more than one masking restriction defined on a field, Virtual DataPort will use the expression from one of them, and the conditions (if exist) will be concatenated as an AND. Nevertheless, it is not recommended to use different maskings definitions for avoid unexpected results or ambiguities.

Remember that Global Security Policies reference views or fields by tags. So, in case of defining a Custom masking expression, you can use tags creating the expression. Virtual DataPort will use a field from the view tagged with the used tags on the expression. Note that, if there are not fields tagged with the used tag, then an execution error will occur.

For example, we have next view returning employees information. One column is the social security number.

Global security policies: Data from view with social security number

View with social security number

We want to use a specific masking for that column allowing only to see first three numbers, therefore, we have to define a custom masking expression with our format.

First of all, we create a tag named “ssn” and we assign this tag to the field social_security_number.

Global security policies: View with social security number

View with social security number definition

Then, we create a Global Security Policy which mask columns tagged with “ssn”. As this data has text type, we have to edit the masking for that data type. We must select Custom and use our expression.

Note that we must use the tag “ssn” on the definition. On execution time, Virtual DataPort will use a field from the accessed view tagged with that tag for creating a valid executable expression on the running query.

Global security policies: Custom masking expression policy definition

Custom masking expression definition

Global security policies: Custom masking expression definition

Custom masking expression definition

Now, when a user executes a query accessing a view which triggers our Global Security Policy, the fields tagged with “ssn” will be masked using the custom expression.

Global security policies: Custom masking expression evaluation

View with social security number masked

Privileges

Only administrator users or local administrators can create, edit or drop a Global Security Policy.

Local administrators, can only manage and see Global Security Policies restricted to databases administered by them.