Governance refers to Data Governance in MDM and it:
- describes the act of managing data access (i.e. who accesses certain data sets based on role, application, etc.)
- defines where the Master Data is stored
- provides visibility to data between zones and adaptors
- has policies that get applied by the Data Governance Steward (DGS), as regards to the data taxonomy of the tenant (Note that the DGS does not control the content (data) in MDM)
- has data content managed by the Zone Data Steward, who is designated by the DGS to:
Governance: InboundAclEntries and OutboundAclEntries
As mentioned above, governance provides visibility to data between zones and adaptors. This is typically managed by the ZDS, implemented with Access Control Lists (ACLs). ACLs are a key component of YOUnite. ACLs are different from permissions in that they control access to data. Permissions control who can manage zones, users, groups, permissions. and roles.
ACLs control both:
- Permissions on outbound data
- Controls on what inbound data a zone or adaptor should receive
ACLs can be thought of as a series of filters that get applied to a data operation.
For example, if an update (PUT or PATCH) operation is performed on data under YOUnite control, ACLs would control:
- What zones and adaptors would have visibility to the change (outbound ACLs)
- Which zones and adaptors receive (or reject) the change (inbound ACLs) e.g. a zone may be granted ACLs to a change but the ZDS for the zone may choose not to accept it.
Outbound Access Control Lists (ACLs)
Outbound ACLs provide data record visibility between zones and adaptors. ACLs are a key component of MDM and are part of what is often referred to as the router.
Outbound ACLs can be thought of as permissions on out-bound data. By default, all ACLs are open. Outbound ACLs are the restrictions a Source Zone sets on a Destination Zone's:
- access to source data (GET) inside the Source Zone
- data operations (PUT, POST and DELETE) inside of the Source Zone
| Operation | Description |
|---|---|
| PUT | When the source zone restricts the changes that occur inside the source zone from flowing outbound to destination zones. |
| POST | When the source zone restricts new data that is created on adaptors in the source zone from flowing outbound to destination zones. |
DELETE | When the source zone restricts "deletes" that occur inside the source zone from flowing outbound to destination zones. |
| GET | What destination zones are restricted from using the source zone's data when assembling data. |
Restrictions can be set on the following:
| Entity | Description |
|---|---|
| Destination Zone | he destination zone |
| Adaptor | A Source Zone's adaptor(s) |
| DR | The union of all data for a specific DR stored on the adaptors (unless constrained to an adaptor) inside the Source Zone |
| Domain | The union of all data stored on adaptors (unless constrained to a subset of adaptors) inside the Source Zone that maps to a given Data Domain |
| DomainProperty | The union of all instances of a specific domain property stored on adaptors inside of the Source zone (unless constrained to a subset of adaptors) |
Outbound ACLs are applied from left to right in the following order:
Destination Zone → Source Adaptor → Domain → DomainProperty → DR
Example Outbound ACLs for GET
These example ACLs are combined to create the effective outbound governance for a zone. DR-XXX represents a specific data record:
| ACLs | Description |
|---|---|
| ZoneX | Restrict all outbound data to ZoneX |
| ZoneX, AdaptorA | This would be useless since ZoneX is already restricted. |
| ZoneX, DR-123 | Again, no need to restrict a specific data record from going to ZoneX since ZoneX is already restricted. |
| ZoneY, DR-123 | OK |
| ZoneY, DR-456 | OK |
| AdaptorB, Students.feeWaiver | Restrict the Students.feeWaiver property stored on AdaptorB from going outbound. |
| Students.ssn | Do not send Student.ssn out from source zone. |
After applying all of the above, the end result is:
- ZoneX gets nothing
- Zone Y is restricted from seeing the two DRs listed above
- Student.feeWaiver on AdaptorB is not shared with any other zone
- Student.ssn is never shared with another zone (for all adaptors in the outbound zone)
Out-bound data permission is controlled at various levels. See an example of the data access, below.
| Source of Data | Destination | Priority |
|---|---|---|
| Zone[1] | Zone[2] | 1 |
| Zone[1].Adaptor[x] | Zone[2] | 2 |
| Zone[1].DR[i] | Zone[2] | 3 |
| Zone[1].DR[i].DRproperty[X] | Zone[2] | 4 |
| Zone[1].Adaptor[x].DRproperty[X] | Zone[2] | 5 |
- At the highest prioirty level (Priority 1), Zone[1] can shut off all outbound data record changes to Zone[2]. At the lowest priority level (Prioirty 5), Zone[1] can shut off sharing a single attribute on a single adaptor (that it owns) to Zone[2].
- Sharing precedence is based on the priority e.g. If Zone[1] has turned off access to Zone[2] (Priority 1), then all other sharing actions are null.
- Permissions for each element are based on REST operations GET, PATCH, POST and DELETE. An additional operation is added for PUSH, where a zone allows another zone to receive real-time changes. However, it may be determined that GET will include PUSH.
Inbound ACLs
By default, all ACLs are open. Inbound ACLs are restrictions a Destination Zone sets on Incoming data requests (GET) and operations (DELETE, PUT, POST) from Source Zones.
| Operation | Description |
|---|---|
| PUT | When the destination zone restricts changes that occur in source zones/adaptors from flowing into the destination zone. |
| POST | When the destination zone restricts new data that is created in source zones from flowing into the destination zone. |
| DELETE | When the destination zone restricts deletes that occur in source zone/adaptors from flowing into the destination zone. |
| GET | What source zone/adaptors are restricted (ignored) by the destination zone when assembling data. |
| Entity | Description |
|---|---|
| Source Zone | The source zone of data flowing into the destination zone. |
| Source Adaptor | The source zone's adaptor(s). |
| Destination Adaptor | The destination zone's adaptor(s). |
| Domain | The union of all data stored on adaptors (unless constrained to a subset of adaptors) inside the zource zone that maps to a given data domain. |
| DomainProperty | The union of all instances of a specific domain property stored on adaptors inside the source zone (unless constrained to a subset of adaptors). |
| DR | The union of all data for a specific DRs stored on the adaptors (unless constrained to an adaptor) inside the source zone. |
Inbound ACLs are applied from left to right in the following order:
Source Zone → Source Adaptor → Destination Adaptor → Domain → DomainProperty → DR
Operational ACLs
Operation ACLs are not part of zone data governance but should be mentioned briefly here. By default, the DGS has permission to modify ACLs to data records (DRs) to zone users and adaptors to create new DRs. Operational ACLs control operations to the underlying DRs are granted by the DGS to Zone Users and Adaptors; typically the ZDSs.