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, the roles or session attributes. Then, you define to what elements does the policy applies to using tags and, finally, the applied restrictions which are also expressed using 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

Conditions are 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

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.

    • Any role in list. It applies to every user which has at least one of the selected roles.

    • All roles in list. It applies to every user which has all the selected roles.

    • Roles not in list. It applies to every user that has roles which are not present at the selected ones.

    • User not in list. It applies to every user which is not at the selected list.

    • Any user in list. It applies to every user which is at the selected list.

    • All session attribute in list. It applies to every user when her current session has all the specified attributes.

    • Any session attribute in list. It applies to every user when her current session has at least one of the specified attributes.

    • Session attribute not in list. It applies to every user when her current session does not have any of the specified attributes.

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

Combination with restrictions by user or role

Restrictions generated will be combined with the user or roles restrictions depending on the type of audience which triggered the Global Security Policy. By type of audience:

  • All and Session Attributes: will be combined with the restrictions assigned to the user and her roles.

  • By role: will be combined with the restrictions assigned to the roles that triggered the Global Security Policy.

  • By user: will be combined with the restrictions assigned to the user that triggered 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.

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.