Governance refers to Data Governance in MDM.
What is Governance?
Governance describes the act of managing data access (i.e. who accesses certain data sets based on role, application, etc.).
| Governance... | |
|---|---|
| defines | where the Master Data is stored |
| provides | visibility to data between zones and adaptors |
| contains |
|
ACLs and ACL Chains
ACLs
An access control list, or ACL, is a list of permissions that controls data flow between zones and adaptors. The list includes:
...
If any of the above controls are omitted from an ACL, then ALL is assumed. (TODO - Add this later)
ACL Chains
ACLs are linked together to form ACL chains. They behave similar to network firewall chains but apply to an organizations data entities linked to YOUnite. When a data event occurs to a source entity, the changes change is transmitted to YOUnite and the appropriate ACL chains are consulted and data is propagated or restricted based on the ACLs in the ACL chains. Care must be taken to order the ACLs on a chain properly since the first ACL match is applied to a data event.
TODO Mark
ACLs are defined similarly to firewall rules where rules are put in on inbound and outbound chains for a given zone.
Care must be taken to order the ACLs on a chain properly since the first ACL match is applied to a data event.
Types of ACLs
There are three types of ACLs:
- Inbound ACLs
- Outbound ACLs
- Operational ACLs
Each zone has both an inbound and outbound ACL chain which are controlled by the zone data steward.
Operational ACLs control which zones can create or delete a federated data record for a specific domain version. Operational ACLs are controlled by the Data Governance Steward.
Outbound ACLs
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 Destination Zones:
- 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 → Destination Adaptor → Domain → DomainProperty → DR
Inbound ACLs
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.
ACLs Illustrated
I very simple example it illustrate this point:
...
- Need to include "allow" PUT and/or POST for them to take effect.
- The domain properties are a list of properties that should be restricted from flowing outbound
- The domain properties are ignored when "restrict" (e.g. restrict PUT or POST) is used since restrict is applied to the entire data event.
...
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.
...
- Permissions on outbound data
- Controls on what inbound data a zone or adaptor should receive
ACL and Governance Example
The image below represents an example of MDM domain-related permissions and operational, outbound, and inbound ACLs (traveling left to right). Additional text below the image describes the process in addition to the embedded in-image text.
- On the diagram's left side is a source zone’s single Source Adaptor (abcd-1234) that sends data changes (data records) in its domain(s) to the router.
- Note: A zone can have many adaptors.
- The data records sent from the source adaptor to the router have Operational ACL applied to them. Operational ACL limits which data operations are allowed from the source zone’s adaptor(s) and adaptor domain(s) and are defined by the zone's DGS.
- Next, the data records from the source zone’s domains/adaptors are linked to YOUnite Data Records to avoid data record duplication.
- Note: The data records published by the source adaptor could be updates, deletes, or new records.
- Outbound ACLs then get applied to the source adaptor’s data records. The Outbound ACLs are defined by the source zone’s ZDS and define what data the Zone can send out (i.e .restricting data, or elements of data, of certain domains from flowing out of certain adaptors in the zone to other zones). After Outbound ACLs are applied the data records are published to the YOUnite Data Hub and subscribing/desitnation zones and their adaptors (on the diagram's right side) are notified of the updated data.Any destination zone that has subscribed to data records from the source zone has Inbound
ACLs
...
ACLs can be thought of as a series of filters that get applied to a data operation.
...
- 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 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:
...
...
DELETE
...
Restrictions can be set on the following:
...
Outbound ACLs are applied from left to right in the following order:
Destination Zone → Source Adaptor → Domain → DomainProperty → DR
Example Outbound ACLs for GET
...
- 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.
...
The union of all instances of a specific domain property stored on adaptors inside the source zone (unless constrained to a subset of adaptors).
...
Inbound ACLs are applied from left to right in the following order:
Source Zone → Source Adaptor → Destination Adaptor → Domain → DomainProperty → DR
Operational ACLs
...
PROBABLY WANT TO REMOVE MOST OF THE FOLLOWING - Illustration is for devs but should be modified
ACL and Governance Example
The image below represents an example of MDM domain-related permissions and operational, outbound, and inbound ACLs (traveling left to right). Additional text below the image describes the process in addition to the embedded in-image text.
- On the diagram's left side is a source zone’s single Source Adaptor (abcd-1234) that sends data changes (data records) in its domain(s) to the router.
- Note: A zone can have many adaptors.
- The data records sent from the source adaptor to the router have Operational ACL applied to them. Operational ACL limits which data operations are allowed from the source zone’s adaptor(s) and adaptor domain(s) and are defined by the zone's DGS.
- Next, the data records from the source zone’s domains/adaptors are linked to YOUnite Data Records to avoid data record duplication.
- Note: The data records published by the source adaptor could be updates, deletes, or new records.
- Outbound ACLs then get applied to the source adaptor’s data records. The Outbound ACLs are defined by the source zone’s ZDS and define what data the Zone can send out (i.e .restricting data, or elements of data, of certain domains from flowing out of certain adaptors in the zone to other zones).
- After Outbound ACLs are applied the data records are published to the YOUnite Data Hub and subscribing/desitnation zones and their adaptors (on the diagram's right side) are notified of the updated data.
- Any destination zone that has subscribed to data records from the source zone has Inbound ACLs in place to define which data operations are allowed in the source zone and its adaptor(s). Inbound ACL is defined by the destination zone’s ZDS. Any data or operations that are configured to be ignored are filtered out. The Destination Adaptor (zyxw-9876) in the image above is shown receiving data records and/or operations it has subscribed to, as filtered by its zone’s Inbound ACL.