🎓 Lesson 13
D5
Role-Based Access Control (RBAC) Design for Multi-Shift Operations
RBAC is a way to give people in a mine only the digital permissions they need for their specific job and shift—no more, no less.
🎯 Learning Objectives
- ✓ Design an RBAC schema for a three-shift mining operation with overlapping maintenance windows
- ✓ Analyze permission conflicts across supervisory, operator, and technician roles using role hierarchy and constraint rules
- ✓ Apply separation-of-duty (SoD) constraints to prevent unauthorized blast initiation or PLC parameter changes
- ✓ Explain how RBAC integrates with IEC 62443-3-3 security levels and ISA/IEC 62443-2-4 zone-based access policies
📖 Why This Matters
In modern automated mines, a single misconfigured access right—like granting a day-shift technician write access to blast timing logic during night shift—can cause catastrophic safety failures, regulatory penalties, or production downtime. RBAC isn’t just about IT security; it’s a critical engineering control that ensures blast initiation, conveyor speed overrides, and ventilation override commands are physically and logically gated by *who*, *when*, and *where*—making it foundational to functional safety in integrated mine automation systems.
📘 Core Principles
RBAC operates on four foundational elements: Users (e.g., Blaster, Shift Supervisor), Roles (e.g., 'NightShift_BlastOperator'), Permissions (e.g., 'execute_blast_sequence_v2'), and Sessions (time-bound, location-aware role activations). Unlike discretionary access control (DAC), RBAC enforces policy at the system level—not per file or device—but across OT platforms (e.g., Siemens Desigo CC, ABB Ability™ MineOptimize). Advanced implementations incorporate constraints: static (e.g., SoD: no user may hold both 'BlastInitiate' and 'BlastCancel' roles), dynamic (e.g., role activation only when GPS-tagged within blast exclusion zone), and temporal (e.g., 'Maintenance_Tech' role expires 15 minutes after shift end). In multi-shift environments, RBAC must synchronize with MES/SCADA shift calendars and support role inheritance hierarchies (e.g., 'Senior_BlastEngineer' inherits all permissions of 'BlastOperator' plus audit-log review rights).
📐 Role Conflict Index (RCI)
The Role Conflict Index quantifies permission overlap risk between concurrently active roles—critical for identifying SoD violations before shift handover. It measures pairwise permission intersection relative to total unique permissions across roles.
Role Conflict Index (RCI)
RCI = |P_i ∩ P_j| / |P_i ∪ P_j|Quantifies permission overlap between two concurrently active roles to identify separation-of-duty violations.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| P_i | Permission set for role i | dimensionless set | Collection of discrete permissions assigned to role i (e.g., ['read_blast_log', 'initiate_blast'] |
| P_j | Permission set for role j | dimensionless set | Collection of discrete permissions assigned to role j |
Typical Ranges:
Acceptable operational overlap: 0.0 – 0.20
High-risk overlap requiring redesign: > 0.25
💡 Worked Example
Problem: During shift change, 'DayShift_Operator' (permissions: P1, P2, P3, P4) and 'NightShift_MaintenanceTech' (permissions: P3, P4, P5, P6) are simultaneously active. Calculate RCI.
1.
Step 1: Identify intersecting permissions: {P3, P4} → count = 2
2.
Step 2: Compute union of all permissions: {P1, P2, P3, P4, P5, P6} → count = 6
3.
Step 3: Apply RCI = |P_i ∩ P_j| / |P_i ∪ P_j| = 2 / 6 = 0.333
Answer:
The result is 0.333, which exceeds the safe threshold of 0.20—indicating unacceptable permission overlap requiring role redesign or temporal deconfliction.
🏗️ Real-World Application
At Newmont’s Boddington Gold Mine (Western Australia), RBAC was redesigned following a near-miss incident where a maintenance technician inadvertently modified conveyor interlock logic during active ore haulage. The updated framework enforced: (1) time-bound role activation synced to SAP EAM shift schedules, (2) geofencing via UWB beacons restricting 'PLC_Parameter_Edit' to authorized maintenance bays, and (3) mandatory dual-role approval (Supervisor + Technician) for any blast-related configuration change—validated against IEC 62443-3-3 SL2 requirements. Post-implementation, unauthorized access attempts dropped by 97% and audit compliance rose from 68% to 100% across quarterly NIST SP 800-53 assessments.
🔧 Interactive Calculator
🔧 Open Mine Automation Cybersecurity Framework Calculator📋 Case Connection
📋 Autonomous Haulage System (AHS) Cybersecurity Upgrade – Iron Ore Mine, Pilbara
Legacy CAN bus interfaces exposed to lateral movement; lack of secure firmware update mechanism
📋 Blasting Control System Zero Trust Pilot – Limestone Mine, Indiana
Single-factor authentication for blast engineers; no session timeout or command replay protection