Securing Data

Securing Data Access

This section describes how to define the access policies for the data model. They are implemented in the form of model and entity privileges.
They are enforced when the user accesses the data through the graphical user interface, web services and API entry points.

Introduction to Security in Semarchy Convergence for MDM

There are two levels of security in Semarchy Convergence for MDM:

Both levels of security are role-based:

For more information about role creation and management, refer to the "Semarchy Convergence for MDM Administration Guide".

Model Privileges Grants

Model Privileges Grants define the access privileges for users via their roles.
A Model Privilege Grant is associated to a role and contains a set of Entity Privileges granted to this role. You can only define a single Privilege Grant for each role in a model.

Entity Privileges

An Entity Privilege defines the privilege of a role for an entity (or a subset of the entity records) and its attribute.

Entity-Level and Attribute-Level Privileges

An Entity Privileges includes privileges defined at:

Examples:

Privileges Types

The types of privilege are listed in the table below:

Privilege Type Entity-Level Attribute-Level Description
Denied Yes Yes Hides the entity or attribute to the user.
Read Yes Yes Allows the user to view the entity or attribute.
Read/Write Yes Yes Allows the user to view the entity or attribute. In addition, the user can edit the values in data entry workflows. Note that this privilege only allows modifying data. To create new records in a data entry workflow, the Creation privilege is needed.
Allow Export Yes N/A Allows the user to mass-export records from this entity in Excel format. Note that exported columns are filtered using the privileges granted on attributes. If a user can Export an entity, but is Denied certain attributes, these attributes will not appear in the export.
Allow Creation Yes N/A Allows the user to create new records and remove records for this entity in workflows.

Warning: If a user has Read-Only or Read/Write privileges on an attribute and this attribute is used in a display name, the entire display name becomes visible to the user, including those of the attributes for which he is denied. It is recommended to avoid using sensitive attributes as part of a display name.

Note: If a user has Read-Only or Read/Write privileges on one attribute of an entity, then he also has Read-Only privileges to see the built-in attributes managed by the platform (for example: publisher, update date, etc.).

Privilege Precedence

Privileges apply in order of precedence: Read/Write then Read-Only then Denied. As a consequence, a user always has the best privileges associated to his roles

For example: John has several roles given to him:

The resulting privilege for John is Read/Write and Creation on the Customer entity.

Important: Make sure to take into account all the roles of a user when reviewing his privileges. A given role may grant this user some privileges even if these are denied for his other roles.

Row-Level Filtering

Entity privileges support Row-Level Filtering, to apply privileges only to a subset of the records of the entity. The subsets are defined using SemQL filters.

To define different privileges for different subsets of records in the same entity, it is possible to create several entity privileges for the same entity. Each privilege will address a subset of the records, defined by a Filter.

Row-level security filters can use Model Variables to customize the data access privileges for the connected user’s session.

For example, the Privilege Grant for the GenericUser role contains:

Both these grants apply to the same employee entity and the same GenericUser role. The second one only applies to the filtered subset of records in this entity passing this filter. This subset corresponds to connected user’s employee record.

How are Privileges Applied?

The Semarchy Workbench Data Management user interface layout and actions are automatically modified depending on the user privileges:

The same rules applies when accessing data through Web Services

Setting up Model Privileges

Note: In this section, we assume that roles and users are already defined at the application server level, and that Roles are already defined in Semarchy Convergence for MDM by the administrator. For more information about role creation and management, refer to the "Semarchy Convergence for MDM Administration Guide".

To add a model privilege grant:

  1. Connect to an open model edition.
  2. In the Model Edition view, right-click the Model Privilege Grants node and select Add Model Privilege Grant.... The Create New Model Privilege Grant wizard opens.
  3. In the Create New Model Privilege Grant wizard, check the Auto Fill option and then enter the following values:
  4. Click Next.
  5. In the Entities Privileges Grants page, select the Entities for which you want grant privileges and click the Add >> button to add them to the Selected Entities.
  6. Click Next.
  7. In the next page, select the default privileges for the selected entities:
  8. Click Finish to close the wizard. The Model Privilege Grant editor opens.
  9. Press CTRL+S to save the editor.

In the Model Privilege Grant editor, you can refine the default privileges in the Entity Privileges table:

Important: Be cautious when checking the Grant full access to the model option in a privilege grant, as it overrides all privileges granted at the entity or attribute level.

Reviewing the Privileges

It is recommended to review the privileges of the users before releasing a model.

To test the security for a given user:

  1. Login to the Convergence for MDM Workbench using this user’s credentials.
  2. Connect to the Data Edition (optionally using an application).
  3. In the workbench toolbar, select the user name in the upper right corner and then select User Information.

The platform, entity-level and attribute-level privileges for the connected user, computed from his various roles, are listed in the user information window.

Defining Data Retention

This section describes how to define the retention policies for historical and lineage data.

Introduction to Data Retention

The MDM hub stores the lineage of the certified golden data, as well as the changes that led to this golden data.
The lineage traces the whole certification process from the golden data back to the sources. The history traces the source data changes pushed in the hub – through external loads – or performed into the hub – through workflows.

Preserving the lineage and history is a master data governance requirement. It is key in a regulatory compliance focus. However, keeping this information may also create a large volume of data in the hub storage.

To keep a reasonable volume of information, administrators will want to schedule Purges for this data. To make sure lineage and history are preserved according to the data governance and compliance requirements, model designers will want to define Data Retention Policy for the model.

Data Retention Policies

Data Retention Polices are defined with:

For example:

Data Purge

Depending on the retention policy that is defined for the model, data purges take place in the deployed hub.

The purges delete the following elements of the lineage and history:

Optionally, the job logs can also be deleted as part of the purge process.

Important: The purges only impact the history and lineage for all data editions. They do not delete golden and master data for the currently open and for previously closed data editions.

Purges are scheduled by the hub administrator. For more information, refer to the "Semarchy Convergence for MDM Administration Guide".

Note: Regardless of the frequency of the purges scheduled by the administrator, the data history retained is as defined by the model designer in the data retention policies.

Defining the Data Retention Policies

The model retention policy applies to all the entities with no specific retention policy.

To define the model data retention policy:

  1. Connect to an open model edition.
  2. In the Model Edition view, double-click the Retention Policies node. The Data Retention Policy editor opens.
  3. In the Data Retention Policy editor, set the Default Retention Policy for the model:
  4. Press CTRL+S to save the editor.

In addition to the model retention policy, you can also define in this editor the entity-specific retention policies.

To define an entity retention policy:

  1. In the Data Retention Policy editor, click the Add Entity Retention Policy. The Create New Entity Retention Policy wizard opens.
  2. In the Create New Entity Retention Policy wizard:
  3. Click Finish to close the wizard.
  4. Press CTRL+S to save the editor.

Note: You can only have one entity retention policy per entity of the model.

Warning: The retention policy has no effect unless the administrator of the hub schedules purge jobs for the data location. For more information, refer to the "Semarchy Convergence for MDM Administration Guide".