Grouping Subjects and Objects

Reducing what must be said involves two aspects: grouping objects and grouping subjects. The resource categories represent one way of grouping objects. Another mechanism is naming. For example, all of a user’s private objects may bear the user’s own name within their identifiers. In that case, a single rule that states that a user may have all types of access to all of that user’s own private objects may take the place of thousands or even millions of separate statements of access permission. Still another way that objects are grouped is by their types; in this case, administrators can categorize all volumes of magnetic tape or all CICS transactions. Still other methods of grouping objects are by device, directory, and library.

When subject groupings match categories, many permissions may be subsumed in a single rule that grants groups all or selected types of access to resources of specific categories. For various administrative purposes, however, groups may not represent categories; rather, they must represent organizational departments or other groupings (e.g., projects) that are not categories. Although subject grouping runs counter to the assignment-of-privilege standard, identity-based access control redresses the balance.

Whenever there are groups of subjects or objects, efficiency requires a way to make exceptions. For example, 10 individuals may have access to 10 resources. Without aggregation, an administrator must make 10 times 10 (or 100) statements to tell the system about each person’s rights to access each object. With groups, only 21 statements are needed: one to identify each member of the group of subjects, one to identify each member of the group of objects, and one to specify the subjects’ right of access to the objects. Suppose, however, that one subject lacks one right that the others have. If exceptions cannot be specified, either the subject or the object must be excluded from a group and nine more statements must be made. If an overriding exception can be made, it is all that must be added to the other 21 statements. Although exceptions complicate processing, only the computer need be aware of this complication.

Additional grouping mechanisms may be superimposed on the subject and object groupings. For example, sets of privileges may be associated with individuals who are grouped by being identified as, for example, auditors, security administrators, operators, or data base administrators.

Administrator Interfaces

To remain ignorant of irrelevant distinctions, administrators must have a coherent and consistent interface. What the interface is consistent with depends on the administrative context. If administrators deal with multiple subsystems, a single product can provide administrators with a single interface that hides the multiplicity of subsystems for which they supply administrative data. On the other hand, if administrators deal with single subsystems, the subsystem itself or a subsystem-specific product can provide administrators with an interface that makes administrative and other functions available to them.

The administrative burden can be kept within tolerable bounds if each administrator is responsible for only a reasonable number of individuals and functions. Functional distribution might focus on subsystems or types of resources (e.g., media or programs). When functional distribution is inadequate, decentralization is vital. With decentralized administration, each administrator may be responsible for one or more departments of an organization. In sum, effective control of access is the implementation of the policy’s rules and implications to ensure that, within cost/benefit constraints, the principles of separation of duties and least privilege are upheld.

IMPLEMENTING CONTROLS

Every time a request for access to type of protected resource occurs in a job or session, an access control decision must be made. That decision must implement management’s wishes, as recorded by administrators. The program that makes the decisions has been called a reference monitor because the job or session is said to refer to a protected resource and the decision is seen as a monitoring of the references.

Although the reference monitor is defined by its function rather than by its embodiment, it is convenient to think of it as a single program. For each type of object, there is a program, called a resource manager, that must be involved in every access to each object of that type. The resource manager uses the reference monitor as an arbiter of whether to grant or deny each set of requests for access to any object of a type that it protects.

In a data base management system (DBMS) that is responding to a request for a single field, the DBMS’s view-management routines act as a reference monitor. More conventional is the case of binding to a view, whereby the DBMS typically uses an external, multipurpose reference monitor to decide whether to grant or deny the job or session access to use the view.