1. Wojciech Sliwinski BE/CO for the RBAC team 25/04/2013

2.  Motivation for RBAC  Machine Safety ▪ Enormous energy stored in the LHC magnets and beams ▪ Potential machine damage is a serious concern ▪ Prevent from invoking machine protection systems  Machine Performance ▪ Do not mess with a fine tuned system ▪ Access denied during certain machine states  Commissioning feedback ▪ Hardware and software commissioning ▪ Debugging 25/04/20132W.Sliwinski - Introduction to RBAC

3.  RBAC infrastructure provided by CO  Does not prevent hackers from doing damage  Protects against human mistakes ▪ A well meaning person from doing wrong thing at the wrong time ▪ An ignorant person from doing anything at anytime  Original scope: LHC machine  Can be deployed anywhere in the Controls Infrastructure  Aims to enhance the overall Machine Safety  Provides Authentication (A1) and Authorization (A2) services  Complements ▪ Hardware Protection (BIS, PIS) ▪ CNIC effort (access control into Technical Network) ▪ MCS (Management of Critical Settings) 25/04/20133W.Sliwinski - Introduction to RBAC

4. 25/04/20134 P. Charrue: RBAC Review ABMB - 02/04/2007 W.Sliwinski - Introduction to RBAC

5. 25/04/20135W.Sliwinski - Introduction to RBAC

6. 25/04/20136 A1 – RBAC Authentication A2 - RBAC Authorization BE Control System W.Sliwinski - Introduction to RBAC

7.  RBAC has 3 modes  NO-CHECK ▪ As it says, no checks are made  LENIENT ▪ A token is needed ONLY if a property is protected in an access map  STRICT ▪ A token is MANDATORY ▪ All SET properties have to be protected 25/04/20137W.Sliwinski - Introduction to RBAC

8.  CO  Provides the RBAC tool and the infrastructure (CMW, FESA,...)  Support for OP and Equipment groups  Proposes general recommendations ▪ Naming and usage of Roles ▪ Preparation of Access Rules  OP  OP in collaboration with CO and Equipment groups (LHC Controls Security Panel) defines policy for deployment of RBAC  Equipment groups  Prepare and maintain Access Rules ▪ Following defined policy  Deploy Access Maps 25/04/20138W.Sliwinski - Introduction to RBAC

9.  Ordinary Roles  Can be assigned to any user  Optionally specify role’s lifetime ▪ Token lifetime bound by role’s lifetime (relative) ▪ Role’s lifetime is global for all assigned users 25/04/2013W.Sliwinski - Introduction to RBAC9 Role’s lifetime

10.  Temporary Roles (e.g. Piquet Roles)  Assign (e.g. EIC on shift) certain role for duration of intervention  Specify absolute expiration time (short period)  Expiration time registered in CCDB  Token’s lifetime bound by role’s expiration time (absolute)  After expiration, role will not be given any more in a token 25/04/2013W.Sliwinski - Introduction to RBAC10 Role’s expiration time

11.  Name convention for Piquet Roles  XX-LHC-Piquet (e.g. BT-LHC-Piquet, PO-LHC-Piquet)  NO users in these ROLES except when needed  Requested by OP & PO groups  Hardware interventions during operations  Roles for temporary staff, contractors, etc. 25/04/2013W.Sliwinski - Introduction to RBAC11

12.  Critical Roles (MCS Roles)  Short lifetime roles with elevated level of access rights  Give access to critical equipment (e.g. BLMs, Kickers, Coll.)  Should be only used by eqp. Experts and selected Operators  MCS Roles already widely used for control of critical equipment  Moreover RBAC provides: ▪ Critical Roles management ▪ Public & Private keys management for Critical Roles ▪ Service for signing the equipment settings  Issues when using Critical Roles  Short role’s lifetime (10 min) bounds the whole token’s lifetime  Not acceptable by users who need valid token for long time ▪ Users have to re-login frequently 25/04/2013W.Sliwinski - Introduction to RBAC12

13.  Proposed improvements (Java Client & A1 Server)  User always requests Master & Application tokens  Master token’s lifetime is fixed (8h), it represents user’s session  Critical Roles not included in a token after initial login ▪ Critical Role has to be requested explicitly (RolePicker) ▪ Only one Critical Role can be present in a token  Master token’s creation time and role’s lifetime used to verify if a certain Critical Role can be obtained at a given moment ▪ Protection of Critical Roles against malicious and/or accidental use  Requested by OP group 25/04/2013W.Sliwinski - Introduction to RBAC13

14.  Operator Role  Can always access equipment but only from CCC  Expert Role  NON-OPERATIONAL mode: access from any Location  OPERATIONAL mode: access only from CCC  Piquet Role  Can always access equipment, from any Location  Role is normally empty (not assigned)  EIC assigns it only for a duration of an intervention 25/04/2013W.Sliwinski - Introduction to RBAC14

15.  Virtual Devices  Convenient way to model non-hardware quantities  Represent non-hardware info using class/device/property model  CCDB – master source of all Device related data  New support for Virtual Devices (DM section)  Extension to CCDB data model  Population via CCDB Data Editor forms  Generic db view for external clients (e.g. import into LSA db)  Possible to define RBAC rules (needed for MCS)  Use cases  SIS (Software Interlock System) Interlock Thresholds  Requires RBAC MCS Role and access rule  Import of virtual devices into LSA db  SIS Interlocks protected by MCS (part of LSA)  Any virtual MCS setting in LSA, DIAMON properties, etc..  More to come... 25/04/2013W.Sliwinski - Introduction to RBAC15

16.  RBAC is deployed CERN-wise together with CMW & FESA  All major applications have a token  RBAC mode is STRICT for LHC  RBAC mode is LENIENT for the injectors  CO diagnostic and monitoring tool (DIAMON) uses RBAC on the GUI level to protect specific actions (e.g reboot, wreboot, repair) 25/04/201316W.Sliwinski - Introduction to RBAC