Changes between Version 17 and Version 18 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis


Ignore:
Timestamp:
Sep 19, 2006, 7:47:04 PM (18 years ago)
Author:
hedinger
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

    v17 v18  
    77Because 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.
    88
    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 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.
     9One 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.
    1010
    1111Adopting 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.