User Role Access and Resource Controls

1️⃣ Overview

The Data Warehouse (DWH) enforces role-based access control (RBAC) and Multi-Factor Authentication (MFA) to secure access across:

  • SQL Server databases
  • Storage accounts (via Azure Storage Explorer or SAS tokens)
  • myBMT application (with dedicated application login & role-based access)
  • APIs (with access key validation)

All users must authenticate using MFA when accessing database resources and storage accounts.

Access Governance and Security

  • Group-Based Role Assignments:
    • Users are granted access only to the necessary resources.
  • Regular Access Reviews:
    • Periodic audits to ensure correct role assignments.
    • Revocation of access when users change roles or leave.
  • Authentication & Security Controls:
    • myBMT-based authentication for application and API access.
    • RBAC enforcement across storage and database layers.
    • Audit logs track access and modification activity.

2️⃣ User Access and Membership Groups

Volumes – Users and Type

  • 21 registered users in myBMT with login access to the pipeline process.
  • Access to DWH databases and the get.myview function is managed via membership groups:
    • DWH Dev Admins (2 members)
    • DWH Dev Users (4 members)
    • DWH Prd Admins (4 members) + DWH Dev Admins
    • DWH Prd Users (8 members) + DWH Dev Users

3️⃣ SQL Server Access Control

SQL Server permissions are structured using role groups mapped to schemas, ensuring that users and applications have controlled and appropriate access.

Database-Level Permissions

User / Role GroupAssigned Role(s)Permissions
bmt-dwh-sql-biread_ifs, memb_cdm, read_hbs, read_mvwRead access to key schemas (ifs, cdm, hbs, mvw).
bmt-dwh-sql-dvdb_owner, db_datareader, db_datawriterFull database access, including write operations.
bmt-dwh-sql-mydb_datareaderRead access to my schema.
bmt-dwh-sql-stgdb_datareaderRead access to staging schemas.
dbodb_ownerFull database ownership.
DWH Dev Adminsdb_ownerFull control over Development databases.
DWH Dev Usersmemb_cdm, exec_ifsRead and execution permissions on cdm and ifs schemas.
DWH Prod Adminsdb_ownerFull control over Production databases.
Example for Staging Database

Schema-Level Access Control

  • Read Access (db_datareader roles) is granted for Development (dv), staging, and myBMT app.
  • Schema based Read Access (read_ifs) is granted to key schemas.
  • Write Access (db_datawriter) is limited to Development (dv) and Data Engineering roles.
  • Execution Privileges (exec_ifs) allow controlled execution of procedures in the IFS schema.
  • Full Ownership (db_owner) is granted to Administrators and Production Admins only.

The user bmt-dwh-sql-bi is used to emulate the actions of users arriving via group based MFA


4️⃣ myBMT Application Access & Role-Based Permissions

Dedicated Application Login

The myBMT application operates using a dedicated application login, ensuring:

  • Centralised access control for application-based interactions.
  • Consistent role-based permissions, reducing the risk of unauthorised modifications.
  • Seamless API and database access, aligning with security best practices.

User Groups & Access Levels

myBMT enforces access through role-based user groups, ensuring controlled interactions based on responsibility levels:

myBMT RolePermissions
AdminFull system control, including database and storage settings.
DeveloperFull access to all items and data, but no system controls.
DE&A (Data Engineers & Analysts)View all items, can perform actions only on assigned items.
ManagerView assigned items, can perform actions only on assigned items.
ClientView assigned items only, no modification rights.

5️⃣ Resource Access Controls

User access is strictly governed across the following core resources:

Storage Containers

  • Development (Dev) and Production (Prd) storage accounts.
  • Access Managed via: RBAC, container-level permissions.

SQL Servers

  • Staging and Global SQL Servers (both Dev and Prd).
  • Access Controlled By:
    • Membership group assignments.
    • Restricted read/write access based on user role.
    • Query execution limitations for non-developer roles.

myBMT Application

  • Login-based user access controls pipeline processes.
  • Special Privileges:
    • myBMT itself has Dev Admin access to Storage and SQL resources.
    • Users within myBMT adhere to DWH membership roles.

API Access

  • Access is paired with an access key, validated against registered myBMT users.
  • Ensures only authenticated and authorised API users can interact with DWH resources.
  • API access enforces User validation via myBMT.

Power BI Workspaces

  • Access to Power BI reports and datasets is controlled via role-based workspaces.
  • Workspaces align with SQL Server role groups to ensure consistent security across platforms.
  • Row-level security (RLS) and workspace permissions further restrict data access as necessary.

6️⃣ SQL Server Access Control & Data Segmentation

SQL Server permissions are structured using role groups mapped to schemas, enforcing principle of least privilege.

General Data Access

  • A majority of data is delivered via a batch process from the IFS ERP system.
  • It is assumed that this data has been validated for general report consumption.
  • General security access rules apply to this data, and it is further constrained by Power BI report writer controls (workspaces and row-level security).
  • The function get.myView provides a single governed access method for all data within SQL Server, ensuring uniform security and controlled data retrieval.

Restricted Data Access

  • Data identified as ‘restricted’ (e.g., financial and people-related data) is subject to stricter access controls, including:
    • Separate Storage Accounts
    • Dedicated SQL Server Databases
    • Schema Role-Based Access Control (RBAC)

Only authorised users with appropriate use-case and schema-level permissions can access restricted data.


7️⃣ Multi-Factor Authentication (MFA) Enforcement

Required for all users accessing:

  • SQL Server databases
  • Storage accounts (via Azure Storage Explorer)

MFA is enforced through Azure AD Conditional Access Policies, ensuring:

  • All interactive sign-ins require MFA verification.
  • MFA validates user identity before granting access.
  • Users must re-authenticate periodically.

8️⃣ Azure Storage Account Access

Access via Azure Storage Explorer

Users access storage containers using Azure Storage Explorer with RBAC permissions:

  • Storage Blob Reader permissions are assigned via Azure Portal to approved user groups.
  • Only read access is provided through this method to prevent unintended modifications.

Access via SAS Tokens

For write (POST) actions, access is granted via SAS (Shared Access Signature) tokens:

  • SAS tokens are time-limited and role-specific.
  • They are issued only to approved users or applications needing temporary access.
  • SAS tokens expire and are refreshed at least every 6 months to enhance security.
  • Expiration policies and token rotation are enforced to prevent misuse.
  • sp=racwl: Permissions ReadAddCreateWrite, and List (Delete actions are not allowed)

9️⃣ Log & Monitoring Strategy

Logging Assumptions

  • SQL Server & Storage Account log actions automatically within their own environments.
  • myBMT maintains an internal login record for tracking user authentication.

Data Access Logging

SystemLog DestinationDetails Logged
myBMT ApplicationInternal Login RecordTracks authentication and user sessions.
get.myview Functionlog.trans_mylog (SQL)Logs access attempts for audit and reporting.
myBMT Container View (action=shower)WordPress mylogLogs access attempts to front-end views.

Reporting on Usage

  • The log.trans_mylog table forms the foundation for Report Usage Analysis in Power BI.
  • Reports track access frequency, failed attempts, and resource interaction trends.

🔟 Policy for Revoking Expired Users

  • Users will be revoked from myBMT upon notification of access changes.
  • Users are reviewed for inactivity and revoked after 3 months of inactivity.
  • SQL Server users are applied via role groups, meaning:
    • Group IT must be notified if a user requires withdrawal from a role group.
    • The same role groups are applied to Power BI Workspaces, ensuring consistent access management across systems.

Leave a Comment