Changes between Version 21 and Version 22 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

Timestamp:

Sep 20, 2006, 3:25:10 PM (18 years ago)

Author:

hedinger

Comment:

—

Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

@@ -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)]]
 ==== ORBIT Design Goals and Threats ====
-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]].
+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 was defined to cover each of these situations consistent with the principle of least privilege [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]].
 
-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 to his or her project and assign them roles within that project as he or she saw fit.
+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 is defined and a project leader assigned to it, that project leader would be able to add ORBIT users and add project members to his or her project and assign them roles within that project as he or she saw fit.
 
-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.
+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 project's resources should no longer be granted to that former member, despite any user-level access privileges granted by the operating system.
 
 Implementing dynamic instead of static separation of duty should eliminate the possiblity of overburdensome restrictions on the roles allowed for the few members of a small project and on users that are members of more than one 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 at two different times.
 
-The use of dynamic separation of duty may diminish the care and eliminate any formal checking for conflicts needed when assigning roles, but it also strengthens the requirement to log accesses and to check those logs regularly.  Project administrators would check for project-level issues and system administrators for cross-project issues.
+The use of dynamic separation of duty should diminish the care that needs to be taken when assigning roles and it should also eliminate any formal checking for conflicts after role assignments, but it also strengthens the requirement to log accesses and to check those logs regularly.  Project administrators would check for project-level issues and system administrators for cross-project issues.
 
 Because ORBIT is designed to be operated as a service available to the research community each project must be protected from other projects.  Experimental scripts, data and results must be private to the project.