1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
# Role-Based Access Control (RBAC)
Assigns permissions to roles, which are collections of permissions related to specific job functions.
This style of access control aligns with how humans organize themselves within
organizations by assigning job functions to roles. This model is simple and
aligns well with how humans operate within their job function.
This model also helps to align security objectives with higher level
organizational policy (.e.g. ethics, privacy, administration). This type of
model requires centralized control and enforcement.
> The act of granting membership and specifying transactions for a role is loosely
> analogous to the process of clearing users (granting membership) and the
> labeling (associate operation sensitivities) of objects ... - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
> A role can be thought of as a set of transactions that a user or set of users
> can perform within the context of an organization. - Role-Based Access Controls by Ferraiolo, Kuhn Et el.
Roles are group oriented and they provide a means of naming and describing
many-to-many relationships between individuals and rights.
1. For each subject, the active role is the one that the subject is currently using:
```
AR(s: subject) = { the active role for subject s}.
```
2. Each subject may be authorized to perform one or more roles:
```
RA(s: subject) = { authorized roles for subject s }.
```
3. Each role may be authorized to perform one or more transactions:
```
TA(r: role) = { transactions authorized for role r}.
```
4. Subjets may execute transactions. The predicate `exec(s,t)` is true if
subject `s` can execute transaction `t` at the current time, otherwise it is
false:
```
exec(s :subject, t: tran) = true iff subject `s` can execute transaction `t`
```
Three basic rules are required:
1. Role assignment: A subject can execute a transaction only if the subject has
selected or been assigned a role
2. Role authorization: A subject's active role must be authorized for the
subject
3. Transaction authorization: A subject can execute a transaction only if the
transaction is authorized for the subject's active role
Another user of RBAC is to support integrity. One aspect of integrity is a
requirement that data and processes be modified only in authorized ways by
authorized users.
The problem of determining whether data have been modified only in authorized
ways can be as complex as the transaction that did the modification. For this
reason, the practical approach is for transactions to be certified and
trusted. If transactions must be trusted then _access control can be incorporated
directly into each transaction_.
RBAC makes a decision based on the subject's association with a role. RBAC does
not easily support multi-factor decisions. RBAC role assignments tend to be
based upon more static organizational positions, presenting challenges in
certain RBAC architectures where dynamic access control decisions are required
(.e.g. `CI_JOB_TOKEN`). Trying to implement these kidns of access control
decisoins would require the creation of numerous roles that are ad hoc and
limited in membership, leading to what is often termed "role explosion".
ABAC avoids the need for explicit authorizations to be directly assigned to
individual subjects prior to a request to perform an operation on the object.
> ABAC: An access control method where subject requests to perform operations on
> objets are granted or denied based on assigned attributes of the subject,
> assigned attributes of the object, environment conditions, and a set of
> policies that are specified in terms of those attributes and conditions.
* Attributes: characteristics of the subject, object, or environment conditions.
* Subject: is a human or or non-person entity (NPE) that issues access requests
to perform operations on objects.
* Object: a system resource for which access is managed by the ABAC system
* Operation: is the execution of a function at the request of a subject upon an
object. (e.g. read, write, edit, delete, copy, execute and modify)
* Policy: is the representation of rules or relationships that makes it possible
to determine if a requested access should be allowed.
* Environment conditions: operational or situational context in which the access
request occurs.
## See also
* [Role-Based Access Controls](https://csrc.nist.gov/files/pubs/conference/1992/10/13/rolebased-access-controls/final/docs/ferraiolo-kuhn-92.pdf)
|
