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 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.

Creating a Global Security Policy¶

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

• 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.

    Note

    The attributes accessInterface, clientIp, intermediateClientIp and userAgent can be overriden by a client application, so they should only be used for security configurations only on controlled environments.

    • 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.

    Variables added by the Resource Manager can also be used as attributes of the user session.

• 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. This means that elements from databases not specified on the list (if defined) are not affected by the Global Security Policy.

• 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)

For example, let us have the following views:

• A database named base_views containing the views customer and payment.

  The view customer has a field email with the tag sensitive.

  The view payment has a field amount with the tag amounts.

• A database named final_views containing the view customer_payments created on top of the previous ones.

We want to restrict the visibility for columns masked with these tags sensitive and amounts to roles different than finance and sales.

So, we select as Audience the option Roles not in list adding finance and sales as values. Also, we define a masking for columns tagged with email and amounts tags.

By this way, the masking restriction will be generated for the roles the user has which are not finance or sales.

We have the user denodo_user with the role marketing. That user and its role have the following privileges. For simplifying, we only show the EXECUTE privilege.

Privileges for user denodo_user and role marketing¶

Role/User	Database	Execute
denodo_user	base_views	Yes
denodo_user	final_views	Yes
marketing	base_views	Yes
marketing	final_views	Yes

This user connects to Virtual DataPort and executes the view final_views. The created Global Security Policy applies, generates the restrictions but the data is unmasked.

Why? The policy was applied and the restrictions were generated, but the Global Security Policies generate the restrictions to the audiences which triggers the policy.

In this case, the audience is Roles not in list and it specifies finance and sales as roles. So, the restrictions are generated to the roles which are not in that list. In the example, to the role marketing.

Let see the following table showing the restrictions after the policy application.

Restrictions generated on the views customer_payments, customer and payment for the user denodo_user executing the view customer_payments.¶

Role/User	View	Execute	Restriction
denodo_user	customer_payments	Yes	No
denodo_user	customer	Yes	No
denodo_user	payment	Yes	No
marketing	customer_payments	Yes	No
marketing	customer	Yes	Mask email field
marketing	payment	Yes	Mask payment field

This table shows that user denodo_user has enough privileges to see the data because the user has EXECUTE privilege directly granted to the user and no restriction applies to this audience. For this reason, the denodo_user is allowed to see the data without restriction.

We must modify the privileges in order to get this Global Security Policy work as expected. We remove the EXECUTE privilege to the user.

Privileges for user denodo_user and role marketing removing EXECUTE from user¶

Role/User	Database	Execute
denodo_user	base_views	No
denodo_user	final_views	No
marketing	base_views	Yes
marketing	final_views	Yes

After that, when denodo_user executes the view, the policy applies again and there are not any role or direct privileges granting EXECUTE on the views. For this reason, now the data is masked.

Restrictions generated on the views customer_payments, customer and payment for the user denodo_user executing the view customer_payments after removing EXECUTE from user.¶

Role/User	View	Execute	Restriction
denodo_user	customer_payments	No	No
denodo_user	customer	No	No
denodo_user	payment	No	No
marketing	customer_payments	Yes	No
marketing	customer	Yes	Mask email field
marketing	payment	Yes	Mask payment field

Specifying a list of databases

When a query is executed, Virtual DataPort checks all views present on the query tree for applying the Global Security Policies created on the system. By default, views from every database are checked. This behavior is configurable selecting a list of databases at the policy definition. In such case, the Global Security Policy is only applicable to the views present on the selected databases.

For example, let us have the following views:

• A database named base_views containing the views customer and payment.

  The view customer has a field email with the tag sensitive.

  The view payment has a field amount with the tag amounts.

• A database named final_views containing the view customer_payments created on top of the previous ones.

We want to restrict the visibility for columns masked with these tags sensitive and amounts to the role marketing. We create a Global Security Policy, affecting to marketing role and we mask columns tagged with email and amounts.

Finally, we select to apply the policy only to final_views database.

With this policy, when a user from marketing executes the final customer_payments view, the returned results are not masked.

This is because the Global Security Policy is defined for applying only to views from final_views database. As the views with the tagged columns are at database base_views, the policy does not affect to them and the results are returned without restrictions.

Now, we edit the policy adding the database base_views to the list of databases. Then, execute again with the user from marketing. With this change, the Global Security Policy applies also to view from base_views database, so the policy generates the restrictions over the tagged columns, and the returned results are masked.

Notes about audience

When a role used by a Global Security Policy is removed, the Global Security Policy will be placed as invalid and will not be evaluated.

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.

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.

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.

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.

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.