SQL Server Master Data Services provides a rich security model for authorizing discrete access to the Master Data Hub. I believe strongly that Master Data should be widely visible to the broadest possible audience. Unless your organization is subject to regulatory compliance which restricts one business unit from viewing customer information in another business unit, I advise that your hand picked Data Stewards be responsible for as much Master Data governance as is prudent, and certainly have access to everything.
Having said that, some organizations are “not there yet.” While they recognize the value of federating their customer master into a single hub, they have appointed some Data Stewards management responsibility for some of the attributes in the customer master, or even some of the customers. To accomplish this, we need to do more than grant access to the entire data model.
If you want to deliver member level access to a master data entity (i.e. row level security), you will need to do so by securing a Derived Hierarchy which includes the entity to be secured.
As an example, let’s say that you have a customer entity. The customer members are all accounts from several business units. Let’s say that you have one group of users who work for one of the business units and are responsible for managing only those business unit accounts.
If you have a domain based attribute on the customer account named “Business Unit” which refers to an entity named “Business Unit”, then you only need to create a Derived Hierarchy named “Customer Accounts By Business Unit” and include the Customer and Business Unit Entities.
Once this is done, you can grant access along any path within this hierarchy. For a given windows group, you may grant read access to the root of the hierarchy, then override this with an update permission to a particular business unit.