Changes between Version 19 and Version 20 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis
- Timestamp:
- Sep 20, 2006, 3:07:35 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/Rbac/OrbitRbacDesign/ThreatAnalysis
v19 v20 1 1 [[TOC(Internal/Rbac, Internal/Rbac/OrbitRbacLevels, Internal/Rbac/OrbitRbacDesign, Internal/Rbac/OrbitRbacDesign/ThreatAnalysis, Internal/Rbac/OrbitRbacDesign/AuditingTools, Internal/Rbac/OrbitRbacDesign/ConsistencyChecking, Internal/Rbac/OrbitRbacDesign/NistRbacSoftware, Internal/Rbac/OrbitRbacDesign/SolarisRbac, Internal/Rbac/OrbitRbacDesign/OasisRbac, Internal/Rbac/OrbitRbacDesign/xoRbac, Internal/Rbac/OrbitRbacDesign/DesignByWiki, Internal/Rbac/OrbitRbacDesign/OpenIssues, Internal/Rbac/LdapResources, Internal/Rbac/RbacResources)]] 2 2 ==== ORBIT Design Goals and Threats ==== 3 The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has sufficient access to each and every ORBIT resource that he or she needs to perform each phase of an experiment without giving each user root privileges. Each identifiable task of each phase of each type of experiment could be a role, and a user need only have certain privileges when acting in a given role.3 The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has sufficient access to each and every ORBIT resource that he or she needs to perform each phase of an experiment without giving each user root privileges. The privileges needed to execute each identifiable task of each phase of each type of ORBIT experiment have been considered, and a set of roles defined to cover each of these situations using the principle of least privilege [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]]. 4 4 5 A longer term goal is to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders and using RBAC's administrative functions. Once a project was defined and a Project Leader assigned to it, that Project Leader would be able to add ORBIT users and add project members and assign them roles within the project as he or she sees fit. 5 A longer term goal, also considered in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]] is use RBAC's administrative functions to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders. Once a project was defined and a Project Leader assigned to it, that Project Leader would be able to add ORBIT users and add project members and assign them roles within the project as he or she saw fit. 6 7 It is expected that over the next few years there could be a thousand or more ORBIT users with many hundreds of ORBIT projects. Many of these projects will have just a few members. Some may have many members. The membership of a project may well change over its lifetime. Some members might be removed from a project intentionally, and, when that happens, access to the projects resources should no longer be granted to that former member. 8 9 Implementing dynamic instead of static separation of duty will not impose overburdensome restrictions on the roles allowed for the few users on a small project. A given member might be an Administrator on one project and just a User on two others. Dynamic separation of duty allows a user to act in two conflicting roles on a single project at two different times. 10 11 The use of dynamic separation of duty may diminish the care and checking needed when assigning roles, but it also strengthens the requirement to log accesses and to check those logs regularly. Project administrators should check for project-level issues and system administrators for cross-project issues. 6 12 7 13 Because ORBIT is designed to be operated as a service available to the research community, no one experiment should affect a future one, and each project must be protected from other projects. 8 14 9 One rationale for using dynamic instead of static separation of duty is to not impose overburdensome restrictions on the roles allowed for the few users on a small project. There are many small ORBIT projects. A given user might be an Administrator on one project and just a User on two others. Dynamic separation of duty allows a user to act in two conflicting roles on a single project at two different times. 10 11 Adopting dynamic separation of duty implies the use possible less but perhaps more care assigning roles, but it also gives rise to the need log accesses to resources of concern and to check those logs as regularly as required by the cause of the concern. 15 Nothing should affect the integrity of experimental results nor any project member's ability to properly interpret those results. 12 16 13 17 List of possible threats … … 17 21 * intentional or unintentional modification or deletion of a user's or a project's scripts or own components or data results by nonproject members. 18 22 * unauthorized access to ORBIT system code, esp., device driver source or controller scripts. 19 20 Nothing should affect the integrity of experimental results nor any project member's ability to properly interpret those results.21 23 22 24 Who (what role on the project) is allowed to change data, i.e., remove outliers, otherwise filter data, or delete data sets? … … 30 32 Are there any requirements related to version control? Is it safe to assume that each project will keep track of it? 31 33 32 Although it does not seem likely with the current ORBIT resources, it is possible that access to some resources (instruments)might be limited to protect them from overuse or damage or just to keep the in calibration.34 Although it does not seem likely with the current ORBIT resources, it is possible that access to some resources, e.g., special instruments, might be limited to protect them from overuse or damage or just to keep the in calibration. 33 35 34 36 Are there any other threats that might require the use of RBAC with ORBIT?
