Wojciech Sliwinski BE/CO for the RBAC team 25/04/2013.
-
Upload
karin-wilson -
Category
Documents
-
view
220 -
download
1
Transcript of Wojciech Sliwinski BE/CO for the RBAC team 25/04/2013.
W.Sliwinski - Introduction to RBAC
Purpose of RBAC
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/2013 2
W.Sliwinski - Introduction to RBAC
Scope of RBAC
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/2013 3
W.Sliwinski - Introduction to RBAC 625/04/2013
A1 – RBAC Authentication
A2 - RBAC Authorization
BE Control System
W.Sliwinski - Introduction to RBAC 7
RBAC Modes
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/2013
W.Sliwinski - Introduction to RBAC
Sharing of responsibility
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 Maps25/04/2013 8
Ordinary Roles 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/2013 W.Sliwinski - Introduction to RBAC 9
Role’s lifetime
Temporary Roles 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/2013 W.Sliwinski - Introduction to RBAC 10
Role’s expiration
time
Temporary Roles
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/2013 W.Sliwinski - Introduction to RBAC 11
Critical Roles
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/2013 W.Sliwinski - Introduction to RBAC 12
Critical Roles
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/2013 W.Sliwinski - Introduction to RBAC 13
Roles Summary
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/2013 W.Sliwinski - Introduction to RBAC 14
Virtual Devices in CCDB
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/2013 W.Sliwinski - Introduction to RBAC 15
W.Sliwinski - Introduction to RBAC 16
Current Status
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/2013