Role Based Access Control

Consumer Groups

Consumer Groups are logical groupings of users who need access to the data in production and, in some approved instances, non-production data on data layers. These groups are unique to the type of users and the specific business area.

Each consumer group will have an accountable owner/approver responsible for identifying the data objects users need access to and managing the consumer groups for their business area. The relevant consumer group owner should maintain and review their consumer group periodically, according to the defined review schedule, to ensure access is accurate. For example, the product owner for finance data will own and manage use cases specific to their data, while the product owner from different divisino will own division specific use cases.

Users may have bindings to multiple consumer groups and data groups if they have a valid business justification for accessing the data.

The proposed naming convention below is provided for guidance and to ensure consistency across the project.

Naming guidance:     

<BUSINESS GROUP>_<ENV>_<USE-CASE>_CG
e.g. BG_PRD_FINANCE_CG

where

• BUSINESS GROUP is business your products belong to i.e. the business project for which you require this consumer groups.
• ENV is the enviornment for which the consumer group is valid i.e. dev, test, prd. Please note that the environment is required if you are creating AD groups as those will reside in common pool. If you are creating on GCP or AWS itself, then mentioning environment is not required as those will already be environment specific.
• Use-Case is the use case for which the consumer groups is required. It could be for particular use-case, division, product class etc.

Data Groups

Data groups control access to data assets on the Cloud. Consumer groups become members of data groups to grant users access to the data asset. Data group is implemented as combination of Google Resource Group and Azure AD group and are created per Business Team requirements and/or data products has binding to each data object/table. Each data group will be unique to identified data object through use case i.e. Single or combination of data objects.

Use case defines consumer group binding to data group and then specific data object.

Naming guidance

<BUSINESS GROUP>_<USE-CASE>_<Subject Area>_<Data Layer>_DG
e.g. BG_FINANCE_PSA_ACCESS_DG

where

• BUSINESS GROUP is business your products belong to i.e. the business project for which you require this data groups.
• Use Case is the usecase for which you require this data group
• Subject Area is a data class that contains set of data tables that are accessed together i.e. combination of data tables that you foresee should be accessed in a bunch.
• Data Layer in data lake defines the hops through which the data goes in a workflow. It could be staging, access layer or datamart layer

After Consumer owner/delegate/business area define, their engineers add those tables into the git repo and raise pull request for the platform team to review and approve. During the release, Platform team will run the pipeline which will provision access to these tables for relevant Consumer Group. Data group design should be defined considering different data objects for each stream and product, business requirements, governance guidelines and controls.

*Relevant business area(approver) will identify and manage their consumer group.

A simple explanation of how access to business data is provided to a user using Consumer and Data Groups.

• Each consumer group should be unique to user’s business area and level of access.
• Each data group should be unique to each data object/table.
• Different access scenarios across all teams or different business teams may need multiple data group combinations or multiple data group and consumer group bindings.
• Unique consumer group and data group provides segregation of access and data security from accidental access or unauthorized access to protected data in the platform.

New consumer groups and data groups will be identified and created when new users and access scenarios are requested for data access provisioning. User access request to access any data objects on the platform can only be approved by Consumer group owner. Each Consumer owner can define consumer group based on data objects mapping and decide how user can access their business area specific data.