Changes between Version 17 and Version 18 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis
- Timestamp:
- Sep 19, 2006, 7:47:04 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/Rbac/OrbitRbacDesign/ThreatAnalysis
v17 v18 7 7 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 8 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 Admin strator 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.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 10 11 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.