1 / 13

FRIB Database Security

FRIB Database Security. Overview. Security Requirements Access Control Specification Access Control Realization Security Architecture Design Concerns Summary. Security Requirements. General Authentication and Authorization Role-based access control Delegation Structural

dory
Download Presentation

FRIB Database Security

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. FRIB Database Security

  2. Overview • Security Requirements • Access Control Specification • Access Control Realization • Security Architecture • Design Concerns • Summary V. Vuppala,Controls DB Meeting

  3. Security Requirements • General • Authentication and Authorization • Role-based access control • Delegation • Structural • Controlled access to components, their attributes and relationships • Area Managers are responsible for structural data • Behavioral or Operational • Controlled access to Operation of the Accelerator • Not managed by area managers • Operations Group responsible for Controls System (CS) • Experimental Group responsible for CS in Experimental Areas • Dynamic Access Control (Check-in/out Model) • Services • Controlled access to application functionality V. Vuppala,Controls DB Meeting

  4. Information Architecture • Application layer • Operator interfaces • High-level applications • Libraries • Service layer • Access to data • Programming Interface • Data layer • Managed data • Instrument data • No direct access V. Vuppala,Controls DB Meeting

  5. Example S2 S1 S3 Services 4. Done 3. Add Log Entry ‘YYY’ to L1 5. caput PS01 10 2. PV is PS01 6. Done 1. What is the PV for XXX? Application V. Vuppala,Controls DB Meeting

  6. Access Specification • Persons, Groups, Roles • Core • Grouping of Components Based on Areas • Areas Associated with Roles • Grouping of Components Based on Operations • Operational Groups Associated with Roles • Develop a Tool to Specify Authorizationand Delegation • Services • Each Application Has Its Own Authorization Data V. Vuppala,Controls DB Meeting

  7. Roles V. Vuppala,Controls DB Meeting

  8. Authorization: Core Structural V. Vuppala,Controls DB Meeting

  9. Authorization: Core Operational V. Vuppala,Controls DB Meeting

  10. Access Control: Realization S2 S1 S3 3. Add Log Entry ‘YYY’ to L1. [Token] 4. Done 5. caput PS01 10. [Token] 2. PV is PS01 1. What is the PV for XXX? [Token] 6. Done Auth Token Credentials V. Vuppala,Controls DB Meeting

  11. Concerns • Channel Access Does Not Support Tokens • Develop a Gateway? • Auth Service • Use Kerberos or Develop New Service • Single Point of Failure: Redundant Servers • Each Service Needs to Provide Security Configuration Tool • No Good Generic Way to Provide Service-Level Authorization • What About Dynamic Access Control? • Develop an Application for Reservation and Release (Check-in/out) V. Vuppala,Controls DB Meeting

  12. Architecture • Authentication/Authorization Service • Ticket Based System • Persons, Groups, Roles • Component Groupings for Core Security Specifications • Service-Level Access Control left to Services • Access Controls on IOCs • Tools • To Specify Core Authorizations • To Specify Service-Level Authorizations • To Reserve and Release Components V. Vuppala,Controls DB Meeting

  13. Summary • Security Must Be Integrated Into Design • Not Very Trivial • No Precedence • Work In Progress V. Vuppala,Controls DB Meeting

More Related