Definitions

Definition 1

Access granularity designates the scale or precision level(s) at which access control is supported by a system.

A system that supports finer grained access controls may provide more configurational flexibility but may require higher maintenance costs, unless it provides efficient mechanisms to simplify and automate access management. Conversely, a system that supports coarser grained access controls may provide less configurational flexibility but may require lower maintenance costs.

Finer access granularity allows for more accurate configuration of access policies such as toxic rights combinations.

A system may simultaneously support multiple access granularity levels. When loosely speaking about the granularity of a system, the intention is often to get a sense of the flexibility provided by a system and thus the smallest level is generally implied.

Examples

• a file server may support file-level ACLs as its smallest access granularity.

• a relational database management system may support database-level, table-level, row-level and field-level access granularities.

• a business application may implement complex policy-based access control mechanisms that resolve in a matrix of record and operation access granularity levels where both record and operation accesses are required to gain access.

Related Terms

• Access

• Authorization

• Coarse-Grained Access Controls

• Fine-grained Access Controls

• Information Asset

• Information Asset Granularity

Quotes

Degree of Granularity – Typically, more simplistic structures such as ACLs or IBAC may be adequate when coarse access decisions are needed, such as the ability to gain access to an enterprise based on membership in an organization. On the other hand, implementing fine-grained controls may be more suitable for granting access to information, where many factors may have to be considered to implement formal release policies established for each information object requested. Here an ABAC or PBAC structure may be more suitable.

Access granularity defines the storage unit to control data access – e.g., at the tuple, tables or databases levels.

6.1.3 The degree to which an access control system supports the concept of least privilege

In addition to an access control mechanism’s reference mediation function, there are two other basic functions: a function to create subjects and associate these subjects with their users, and a function to associate a subject with a subset of attributes that are assigned to its user. Regardless of its implementation and the type of attributes that are deployed, reference mediation of an access control system constrains the subject and user’s requests to the capabilities that are associated with a subject’s attributes. Although a number of access control mechanisms associate a subject with each and every user attribute, in order for an access control mechanism to support the principle of least privilege, constraints must be placed on the attributes that are associated with a subject to further reduce the permissible capabilities. The organization specific least- privilege policy is described by specifying the rules composed by the basic access control elements: subjects, operations, and objects. The access control systems provide various specifying methods, which achieve different degrees of granularity, flexibility, and scope, and different groupings of the controlled resources for the least-privilege policies.

4.2.7 Granularity

A practical problem with all current flavors of access control system is granularity. As the operating system works with files, this will usually be the smallest object with which its access control mechanisms can deal. So it will be application-level mechanisms that, for example, ensure that a bank customer at a cash machine can see his or her own balance but not anybody else’s.

But it goes deeper than that. Many applications are built using database tools that give rise to some problems that are much the same whether running DB2 on MVS or Oracle on Unix. All the application data is bundled together in one file, and the operating system must either grant or deny a user access to the lot. So, if you developed your branch accounting system under a database product, then you’ll probably have to manage one access mechanism at the operating system level and another at the database or application level. Many real problems result. For example, the administration of the operating system and the database system may be performed by different departments, which do not talk to each other; and often user pressure drives IT departments to put in crude hacks that make the various access control systems seem to work as one, but that open up serious holes.

Another granularity problem is single sign-on. Despite the best efforts of computer managers, most large companies accumulate systems of many different architectures, so users get more and more logons to different systems; consequently, the cost of administering them escalates. Many organizations want to give each employee a single logon to all the machines on the network. A crude solution is to endow their PCs with a menu of hosts to which a logon is allowed, and hide the necessary userids and passwords in scripts. More sophisticated solutions may involve a single security server through which all logons must pass, or a smartcard to do multiple authentication protocols for different systems. Such solutions are hard to engineer properly. Whichever route one takes, the security of the best system can easily be reduced to that of the worst.

An operation represents a unit of control that can be referenced by an individual role that is subject to regulatory constraints within the RBAC framework. It is important to note the difference between a simple mode of access and an operation. An operation can be used to capture security-relevant details or constraints that cannot be determined by a simple mode of access[2]. These details can be in terms of both method and granularity of access.

Bibliography

• Anderson, 2001

• Farroha and Farroha, 2012

• Ferraiolo, 1995

• https://open-measure.atlassian.net/wiki/spaces/BIB/pages/67633515

• Sasaoka and Medeiros, 2006

See Also