Changes between Version 11 and Version 12 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

Timestamp:

Sep 12, 2006, 3:53:41 PM (18 years ago)

Author:

hedinger

Comment:

—

Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

@@ -5 +5 @@
 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.
 
-In fact, access control has to center on projects.  Resources like data files belong to projects not users.  Roles would be role types expressed in the context of a given project.  Controlling access might involve not granting access to a user that once was a member of a project, and in fact ran the experiment that created the data file in question, but no longer is a member.  Controlling access also would be a way to limit or cease work on a project if need be.  
-
-It is assumed that all members of a given project can see all of that project's scripts, programs and data, but not all scripts, programs and data belonging to each member of the project.
-
-The privileges of users and of projects has made more explicit on the ORBIT system.  One complication is that scripts and programs are often shared across projects.  Such shared resources couild be considered objects common to ORBIT, but some might want to restrict the projects with which they are shared.
-
-One rationale for using dynamic instead of static separation of duty is to not impose overburdensome restrictions on the roles allowed for a few users on a small project.  There are many small ORBIT projects.  A given user might be an Adminstrator 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.
+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 Adminstrator 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.
 
 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.