Securing Data | ||
---|---|---|
Previous | ||
Deployment |
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.
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 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.
An Entity Privilege defines the privilege of a role for an entity (or a subset of the entity records) and its attribute.
An Entity Privileges includes privileges defined at:
Examples:
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.).
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.
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:
employeeName=:V_USERNAME
.
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.
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
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:
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.
It is recommended to review the privileges of the users before releasing a model.
To test the security for a given user:
The platform, entity-level and attribute-level privileges for the connected user, computed from his various roles, are listed in the user information window.
This section describes how to define the retention policies for historical and lineage data.
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 Polices are defined with:
For example:
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.
The model retention policy applies to all the entities with no specific retention policy.
To define the model data retention policy:
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:
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".
Previous | Top | |
Deployment |