1 / 16

Introduction to RBAC

Wojciech Sliwinski BE/CO for the RBAC team 25/04/2013. 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

dasan
Download Presentation

Introduction to RBAC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Wojciech Sliwinski BE/COfor the RBAC team 25/04/2013 Introduction to RBAC

  2. Purpose of RBAC • Motivation for RBAC • Machine Safety • Enormousenergy 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 W.Sliwinski - Introduction to RBAC

  3. 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 ControlsInfrastructure • Aims to enhance the overall Machine Safety • ProvidesAuthentication (A1) and Authorization (A2) services • Complements • Hardware Protection (BIS, PIS) • CNIC effort (access control into TechnicalNetwork) • MCS (Management of Critical Settings) W.Sliwinski - Introduction to RBAC

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

  5. RBAC architecture W.Sliwinski - Introduction to RBAC

  6. BE Control System A2 - RBAC Authorization A1 – RBAC Authentication 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 W.Sliwinski - Introduction to RBAC

  8. 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 collaborationwith CO and Equipmentgroups (LHC Controls Security Panel) defines policy for deployment of RBAC • Equipment groups • Prepare and maintain Access Rules • Following definedpolicy • Deploy Access Maps W.Sliwinski - Introduction to RBAC

  9. OrdinaryRoles • 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 Role’s lifetime W.Sliwinski - Introduction to RBAC

  10. TemporaryRoles • 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, rolewill not be given any more in a token Role’sexpiration time W.Sliwinski - Introduction to RBAC

  11. TemporaryRoles • Nameconvention 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. W.Sliwinski - Introduction to RBAC

  12. CriticalRoles • 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 onlyused by eqp. Experts and selectedOperators • MCS Roles already widely used for control of critical equipment • MoreoverRBAC provides: • Critical Roles management • Public & Private keys management for CriticalRoles • 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 W.Sliwinski - Introduction to RBAC

  13. 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 W.Sliwinski - Introduction to RBAC

  14. RolesSummary • Operator Role • Canalwaysaccessequipment but onlyfrom CCC • Expert Role • NON-OPERATIONALmode: accessfromanyLocation • OPERATIONAL mode: accessonlyfrom CCC • Piquet Role • Canalwaysaccessequipment, fromanyLocation • Role is normallyempty (not assigned) • EICassignsitonly for a duration of an intervention W.Sliwinski - Introduction to RBAC

  15. 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 ... W.Sliwinski - Introduction to RBAC

  16. Current Status • RBAC is deployed CERN-wisetogether 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) W.Sliwinski - Introduction to RBAC

More Related