1 / 83

A Framework for Secure and Interoperable Cloud Computing with RBAC, MAC, and DAC

A Framework for Secure and Interoperable Cloud Computing with RBAC, MAC, and DAC. Mohammed S. Baihan Major Advisor: Dr. Steven A. Demurjian Associate Advisors: Dr. Reda Ammar, Dr. Swapna Gokhale , Dr. Thomas Agresta. Introduction and Motivation.

seaton
Download Presentation

A Framework for Secure and Interoperable Cloud Computing with RBAC, MAC, and DAC

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. A Framework for Secure and Interoperable Cloud Computing with RBAC, MAC, and DAC Mohammed S. Baihan Major Advisor: Dr. Steven A. Demurjian Associate Advisors: • Dr. Reda Ammar, Dr. SwapnaGokhale, Dr. Thomas Agresta

  2. Introduction and Motivation • Organizations migrate their systems and applications to the cloud: availability, flexibility, scalability and cost-effective • Cloud changes systems development: from software-based to API-based • Enhance and add new functionalities: utilizing API, organizations may open their systems to outsider developers, without exposing the actual underlying implementation

  3. Introduction and Motivation • The Healthcare Domain has rich applications that spans a multiple systems (in cloud) via their APIs • Developers must work with multiple systems that : • Have cloud services, programming services (traditional), or web services, and • employ different security policies (RBAC, MAC, DAC) • Makes Development • Difficult • Prone to Errors when Changing

  4. Main Research Objectives & Questions • Unify different service types using one common service type so that Apps can be easily built • How to unify different service types? • How each system provides its services? • How Apps can discover the unified services? • Support Multiple Access Control Models • Role-Based, Mandatory, and Discretionary • Control the access to the unified services • How to unify different security policies? • How to define a new global security policy against the unified services? • How each system provides its security policy? • Enable systems to publish services and security policies • Enable applications to discover and utilize unified services in a secure manner

  5. Big Picture Repository Client n Desktop/ Web/Mobile App Client 1 Desktop/ Web/Mobile App API API Integration Layer • Integration Layer Clients Registry RBAC/MAC/DAC Interceptors Global Services Systems Registry Security Policy Mapping Global Security Policy • Integration Layer • Integration Layer API/ Web/ Cloud services System 1 System m API/ Web/ Cloud services Security Policy Security Policy

  6. Research Contributions • Architectural Blueprints for Supporting FSICC • A collection of blueprints for the design and development of Integration Framework servers that integrate systems with Apps • Integrated RBAC, MAC, and DAC Model for FSICC • Model enterprise Apps, client Apps, systems, etc. • Model RBAC, MAC, DAC Permissions, permissions mapping • Security Mapping/Enforcement Algorithms + SSEP • Combining security policies (RBAC, MAC or DAC) from different systems into global security policy • Generation of security enforcement code • Dynamic Enforcement via Intercepting Process • Programmatic mechanisms to intercept service calls from client Apps for performing security checks • RBAC, MAC, and DAC Interceptors

  7. Remainder of Presentation • Background • Security Requirements and Cloud Computing Capabilities for FSICC • Unified Cloud Computing Access Control Model • Architectural Blueprints • Global Security Policy Generation & Dynamic Enforcement • SOA-based security engineering process SSEP • Research Accomplishments • Future Work • Publications

  8. Background: Cloud Computing • NIST Definition of Cloud Computing: Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud Service Registry Find Publish Bind Cloud Service Model • Cloud Services for HIT systems: • Meaningful Use Stage 3 requires HIT systems to have cloud services to access, modify, and exchange health-related data Cloud Service Supplier Cloud Service Consumer

  9. Background: Access Control Models • Role-Based Access Control (RBAC) • User is associated with a role, and permissions are authorized to roles • NIST RBAC Standard (2004) • Mandatory Access Control (MAC) • Security administrator assigns sensitivity levels to objects and users to control who can see what • Sensitivity levels: Top Secret (TS), Secret (S), Confidential (C), Unclassified (U) • Discretionary Access Control (DAC) • User may pass privileges (e.g. roles) to delegate both authority and permissions to another user • Access to objects based on user’s identity

  10. Background: Access Control Models • Access Control & Cloud Services: • Traditionally, RBAC, DAC, and MAC define permissions over objects of a system • However, for cloud services, they need to be modified so that permissions can be defined against cloud services • Then it is possible to: • specify which role can access which cloud service • define a classification of each cloud service, and • delegate a cloud service from one user to another

  11. Background: FHIR & HAPI FHIR • Fast Health Interoperable Resources (FHIR): • A health integration standard developed by HL7 • Structured around the concept of Resources • FHIR Resources (93+) can hold health information to be exchanged between a HIT system to another via RESTful API that utilize XML and JSON formats • Example: the Patient FHIR resource in JSON:

  12. Background: FHIR & HAPI FHIR • HL7 API FHIR (HAPI FHIR): • Popular FHIR reference implementation • Open-source Java-based library • HAPI-FHIR server architecture:

  13. Background: Healthcare Scenario • Two mHealth client apps: • CTConcussion Tracker (CT2): allows the user (e.g., parent, school nurse) to manage concussion incidents of students • ShareMyHealth(SMH): enables patients to manage and share their fitness data across multiple systems • Two HIT systems: • OpenEMR: open source Electronic Health Record (EHR) system that can be utilized by any health/medical organization around the world • MyGoogle: a middle layer between the ShareMyHealth app and two HIT systems: OpenEMR; and Google Fit (a system for sharing and managing patient fitness data)

  14. Background: CT2 UI, Services, and Roles

  15. Background: SMHUI, Services, and Roles

  16. Background: CT2 & SMHUI, Services, and Roles CT2 Roles

  17. OpenEMR and MyGoogleServices, and Roles

  18. Security Requirements for FSICC • Numerous and Varied Access Control Models • FSICC must support a wide range of access control such as: RBAC, MAC, DAC, ABAC, UCON: as each system may utilize any access control model • Control Access to Cloud Services Using RBAC • The unified cloud services expect high number of consumers • Need to be controlled based on roles (efficient management) • Control Access to Cloud Services Using MAC • Some services may access sensitive information such as patient data • Such services can be further restricted using MAC (CLS for each service) • Support Delegation of Cloud Services Using DAC • Services consumers need to pass/revoke permissions to other consumers • Need to enable permissions delegation via DAC

  19. Cloud Computing Capabilities for FSICC • Local service registration and mapping to global services • For systems to register local services where mapped to a global set • Map cloud/programmatic/web services into equivalent global services • Supported by Registration and Services Mapping & Global Security Policy components • Local security policies registration to yield global security policy • For systems to register their local security policy to generate a global security policy (green arrows) • Includes: defined roles, permissions authorized to each role, classifications for each service, allowable delegations, etc. • Supported by Security Policy Mapping & Global Security Policy components • Global registration, authentication, authorization, service discovery • Consumers (new or existing Apps) can: • Register, be authenticated and authorized to services (Global Authorization and Authentication component) • Discover global services (Global Cloud Services component) • Existing Apps: link its API to the global services (via an integration layer)

  20. Requirements and Capabilities for FSICC • FSICC Capabilities: • Local service registration and mapping to global services • For systems to register local services where mapped to a global set (blue arrows) • Map cloud/programmatic/web services into equivalent global services (cloud) • Supported by Registration and Services Mapping component

  21. Requirements and Capabilities for FSICC • FSICC Capabilities: • Local security policies registration to yield global security policy • For systems to register their local security policy to generate a global security policy (green arrows) • Includes: defined roles, permissions authorized to each role, classifications for each service, allowable delegations, etc. • Supported by Security Policy Mapping component • Global security policy is realized within the Global Security Policy component

  22. Requirements and Capabilities for FSICC • FSICC Capabilities: • Global registration, authentication, authorization, and service discovery • Enable consumers (new or existing apps) to register and discover global services, & be authenticated and authorized to services • Supported by Global Authorization and Authentication component for consumers’ ID, and associated roles/clearance • Global Cloud Services componentsupports the services discovery • Existing apps that has API must link its API via integration layer to the global services

  23. Contribution B. Integrated RBAC, MAC, and DAC Model Unified Cloud Computing Access Control (UCCAC) that: • Models schemas • Models enterprise application, client applications, systems, and global resources • Models RBAC, MAC, DAC permissions • Models permissions mapping • Models security interceptors

  24. EnterpriseApplication Definitions Depiction Defn. 4: operation(s) Defn. 1: Element(s) Ek= <EID, EName, ECLS > E1 Defn. 2: Schema(s) SCi= <SCID, SCName, SCE, SCCLS > [R, I, U, D] Defn. 3: Schema Instance(s): SCI1 SCI2 SCI3 [R, I, U, D] E2 [R, I, U, D] Ek • Abbreviations: • Read (R) • Insert (I) • Update (U) • Delete (D) • Classification (CLS) (Defn. 10)

  25. Roles and Users Definitions Depiction Definition 14: User u= <uID,uName, uCLR> Definition 12: Role Permission rp= < rpID, pID, rID> Definition 13: RPSr= <rp1, rp2 , … , rpn> Definition 11: Permission p= < pID, pSC, pO> Definition 8: Role r= <rID,rName> Definition 9: Set of Roles R={r1,r2,…,rj} rj= <rIDj,rNamej> Definition 15: Set of Users U = {u1,u2,…,uj} uj= <uIDj,uNamej, uCLRj> Definition 16: User Role Assignment ura= <uIDj, rIDj> • Abbreviations: • User (u), Set of users (U) • Role (r), Set of roles (R) • User Role Assignment (URA) • User Role Assignment Set (URAS) • Role Permission Set (RPS) • Clearance (CLR) (Defn. 10) Definition 17: User Role Assignment Set uras= {<uID1,rIDj>,<uID2,rID1>,…,<uID3,rIDj>}

  26. Delegation & Services Definitions Depiction αSignature= < αMT, αURI , αIV> Web/ Cloud Definition 27: Service αi= < αID, αName , αSignature , αType > Definition 26: Delegation Set DSS/C= <d1, d2, … , dn> where di= <ou, du, dr/ drp> αSignature= < αMN, αRT , αP> αType= read, write, (read/ write) Program • Abbreviations: • Method Type (MT) Uniform Resource Identifier (URI) • Input Variable (IV) Method Name (MN) • Return Type (RT) Parameters (P) • Delegation (d) Original user (ou) (Defn. 20) • Delegated user (du) (Defn. 23) Delegated role (dr) (Defn. 18) • Delegated role permission (drp) (Defn. 22) 26

  27. Systems and Clients Definitions Depiction Defn. 28: System(s) Si = <SID, SName , SAPI , SSC, SR , SRPS , SU , SURAS , SDS > Defn. 7: Set of Systems S1 OpenEMR, MyGoogle S2 Definition 5: Enterprise Application EA= <EAID, EAName , EACS , EASS , EASCS > Si Defn. 2: Schema(s) SCI1 SCI2 SCI3 Defn. 29: Client(s) Ci = <CID, CName , CAPI , CSC, CR , CRPS , CU , CURAS , CDS > Defn. 6: Set of Clients C1 CT2, SMH, C2 • Abbreviations: • Client set (CS) • System set (SS) • Schema set (SCS) 27 Ci

  28. Global Resources/Mapping Definitions Depiction Defn. 35: Global Resource(s) (G) Gi= <GID, GName , GAPI , GR , GRPS , GU , GURAS , GDS > Definition 36: FSICC = <G, R, U, URAS, RRPS> G1 FSICC Defn. 30: Global Service(s) βi= <βID, βName , βSIG , βCLS > G2 Gi Defn. 39/40: CSAGAM(s) CSAGAMi= < CiAPI/SiAPI, GiAPI> Defn. 41/42: CSRGRM(s) CSRGRMi= < CiR/SiR, GiR> Defn. 43/44: CSUGUM(s) CSUGUMi= < CiU/SiU, GiU> G1API C1API /S1API G1R G1U C1R /S1R C1U /S1U G2API C2API /S2API G2R G2U C2R /S2R C2U /S2U GiAPI CiAPI/SiAPI GiR GiU CiR/SiR CiU/SiU • Abbreviations: • Client/System Roles to Global Roles Mapping (CSRGRM) • Client/System Users to Global Users Mapping (CSUGUM) • Client/System API to Global API Mapping (CSAGAM)

  29. RBAC Interceptor Definitions Depiction • Programmatic RBAC, MAC, and DAC interceptors: • Represent the implementation of the UCCACM for the FSICC • Utilized to intercept any request to access FSICC’s global services User-Role Enforcement Check (Definition 50): This checks if a user is authorized to the role it is attempting to use. Role-Service Enforcement Check (Definition 51): This checks if a role authorized to access the service that is attempting to execute. RBAC Interceptor (Definition 52): This interceptor checks if a user with a role is authorized to access a requested service.

  30. MAC Interceptor Definitions Depiction • MAC properties (Definition 53): These are the standard MAC properties for objects that we are applying to services • SS (Simple Security): a user can invoke a read service, if CLR >= CLS • SI (Simple Integrity): a user can invoke a write service, if CLR >= CLS • L* (Liberal): a user can invoke a write service, if CLR <= CLS • S* Write (Strict): a user can invoke a write service, if CLR = CLS • S* Read (Strict): a user can invoke a read service, if CLR = CLS User Assigned MAC Properties (Definition 54): Each user is assigned a read and write property which must be checked in order to invoke the service. MAC Enforcement Check (Definition 55): This checks if a user’s clearance and read/write properties allows the invocation of a CRUD service (Defns. 53 and 54). MAC Interceptor (Definition 56): This interceptor checks if a user with a clearance is authorized to access a requested service which constrained by the user's read and write properties.

  31. DAC Interceptor Definitions Depiction Delegated User- Delegated Role Enforcement Check (Definition 57): This checks if a delegated user is authorized to be delegated roll that is a tempting to be utilized. Delegated User- Delegated Role Permission Enforcement Check (Definition 58): This checks if a delegated user can utilize the permissionos of a delegated role permission. Delegated User- Delegated Clearance Enforcement Check (Definition 59): This checks if a delegated user is authorized to the claimed delegated clearance. DAC Interceptor (Definition 60): This interceptor checks to see if a delegated user is authorized to the delegated role and/or authorized to the delegated clearance.

  32. Defining Global Services and Roles Global Services Global Roles

  33. Mapping Roles for CT2, SMH, OEMR, & MyGoogle

  34. Mapping Services for CT2, SMH, OEMR, & MyGoogle

  35. Contribution A. Architectural Blueprints for FSICC • Intent: • Different architecture options for mHealth, web, or desktop apps to interact with multiple HIT systems via FSICC by adopting FHIR • Considered issues(App components): • Application overall architecture (one-tier, two-tier, three-tier) • User interface (the presentation layer); user request processing (the business layer); and the repository (the data layer) • Involved technologies • Programmatic API, repository API, RESTful API, cloud services, etc. • Source code availability • Source code of the app, API, server, or database • Allowable access to HIT • What parts are accessible (RESTful API, programmatic API, repository API, cloud services, etc).

  36. Contribution A. Architectural Blueprints for FSICC • Blueprints for the three architectures: • Integration steps and processes • Three main blueprints: • Basic Architecture Blueprint • Alternative Architecture Blueprint • Radical Architecture Blueprint • All share a common HIT FHIR Blueprint • HIT FHIR Blueprint • Define HIT system’s data items: • Identify each data item in the repository • For each data item: find a similar item name of a FHIR Resource (if not try datatype), and the selection description • Group multiple related data items into a distinct data entity • Design an HIT.FHIR server: • Use HAPI FHIR to create a controller class that controls all requests to all FHIR Resources • Use HAPI FHIR to create a class and CRUD methods for each identified FHIR Resource

  37. Contribution A. Architectural Blueprints for FSICC • Application Integration Options: App Repository App RESTful API Calls to RESTful API OpenEMR OpenMRS PHR Main App Components

  38. Option 1: Basic Architecture • a FHIR server that works directly with the App repository and FHIR servers for OpenEMR, OpenMRS, and PHR App Repository App RESTful API Calls to RESTful API APP.FHIR OpenEMR OpenMRS PHR PHR.FHIR OpenEMR.FHIR OpenMRS.FHIR API API API

  39. Option 1: Basic Architecture Blueprint • Define App’s data items: • Identify each data item in the App • For each data item: find a similar item name of a FHIR Resource (if not try datatype), and the selection description • Group multiple related data items into a distinct data entity • Design App.FHIR server for App Repository: • Use HAPI FHIR to create a controller class that controls all requests to all FHIR Resources • Use HAPI FHIR to create a class and CRUD methods for each identified FHIR Resource • Design the additional services: • App.FHIR.LOAD: occurs upon startup to initialize the App repository with information from HITs • App.FHIR.STORE: occurs when app closes to update HIT repository with data from App repository • Employ the HIT FHIR Blueprint

  40. Option 2: Alternative Architectural • a FHIR server that works directly with the App RESTful API and FHIR servers for OpenEMR, OpenMRS, and PHR App Repository App RESTful API Calls to RESTful API App. FHIR OpenEMR OpenMRS PHR OpenEMR.FHIR OpenMRS.FHIR PHR.FHIR API API API

  41. Option 2: Alternative Architecture Blueprint • Define App’s data items: (identical to step 1 in Basic blueprint) • Design App.FHIR server for App RESTful API: • Similar to step 2 in Basic blueprint but in front of the RESTful API • Design the additional services: • App.FHIR.LOAD: occurs when the Read method of any FHIR class is called to App repository • App.FHIR.STORE: occurs after the Create method of any FHIR class is called to update the HIT repository with data from App repository • Employ the HIT FHIR Blueprint

  42. Option 3: Radical Architecture • Option 3: Radical Architecture • removes the repository and has FHIR servers for the App API, OpenEMR, OpenMRS, and PHR App RESTful API Calls to RESTful API App. FHIR OpenEMR OpenMRS PHR OpenEMR.FHIR OpenMRS.FHIR PHR.FHIR API API API

  43. Option 3: Radical Architectural Blueprint • Define App’s data items: (identical to step 1 in Basic blueprint) • Redesign the App RESTful API to implement App.FHIR server: • Similar to step 2 in Basic blueprint but integrated with the RESTful API • Employ the HIT FHIR Blueprint

  44. Contri C/D. Dynamic Policy Enforcement via Intercepting Process • Programmatic RBAC, MAC, and DAC interceptors: • Represent the implementation of the UCCAC model for the FSICC • Utilized to intercept any request to access FSICC’s global services • Approach: • Mapping processes that enable clients to utilize systems services in a secure way • Implementation of HAPI FHIR APIs and its server interceptor • Algorithms for: RBAC interceptor, MAC interceptor, and DAC interceptor • Access scenarios • First– Briefly Review Relevant Interceptor Definitions

  45. Global Security Policy Generation & Dynamic Enforcement(Contributions C/D) Global Security Policy Generation & Utilization

  46. Integration Architecture of FSICC(EAHIT) SMH mHealth app CT2mHealth app Repository RESTful API ObservationResource ObservationResource UserResource PatientResource ConditionResource EncounterResource PatientResource LOAD LOAD FHIR Controller STORE FHIR Controller STORE SMH FHIR Server CT2 FHIR Server Clients Registry FSICC FHIR Server RBAC/MAC/DAC Interceptors FHIR Controller EncounterResource UserResource ObservationResource PatientResource ConditionResource Global Policy Systems Registry OpenEMR FHIR Server MyGoogle FHIR Server FHIR Controller FHIR Controller ObservationResource ObservationResource ConditionResource EncounterResource PatientResource UserResource PatientResource API API OpenEMR MyGoogle

  47. Algorithms for Global RBAC Generation

  48. Algorithms for Global RBAC Generation

  49. Algorithms for Global RBAC Generation

  50. Algorithms for Global MAC and DAC Generation

More Related