|
access
control
Any security regime
must have a system of controls that limit access to the organization's
resources. In computer contexts, it is natural to focus on
the limitations for/within information systems. Physical controls
are a critical part of organizational security too. (And physical
controls are critical for information security -- e.g., limiting
physical access to the rooms where critical computer hardware
is located.)
Access controls
are predicated on a system of identification
and authentication -- that is, "Who are you?"
and "Can you prove it?" In an information
system, human identity is usually linked to a unique "user-ID"
(unique to the particular information system anyway). The
task of proving that you are you -- the lawful user-ID holder
and not an imposter -- is accomplished with some combination
of passwords, token cards, and biometric identifiers that
are linked to the user-ID.
(Physical access
is predicated on authenticators too, such as an ID badge.
In a small organization, with limited security needs, it may
be enough just that everyone knows everyone else -- the most
basic of biometric authentications.)
Once identity is
assured in an information system, the access control mechanisms
have the task of enforcing limits associated with that identity.
Absent access controls, anyone whose identity passed muster
would be able to do anything. That might be adequate for a
personal computer with a single user; it's almost never sufficient
for a computer system that is shared.
Formally,
access control sets the relationships between "subjects"
(such as human users who want to do things) and "objects"
(files, databases, applications programs, devices like printers).
The relationship need not be between human subjects and cyber
objects -- sometimes the subject is a computer program that
wants to do something and needs other programs or resources
to accomplish the task.
Even more abstractly,
one can think of an access control system as a two-dimensional
matrix with subjects forming one dimension and objects the
other. In each cell of the matrix is a permission specification
relating a particular subject to a particular object -- e.g.,
the ability of user GWBush to read a particular file or use
printer Oval_Office_01.
With lots of subjects
and lots of objects this quickly becomes a very large matrix
indeed. An alternative is to store an "access control
list" (ACL) with each subject or object. A subject ACL
would list what that subject could do (to various objects);
an object ACL would list what could be done to it (by various
subjects).
It is more typical
to store ACLs with objects (system resources), in which case
the ACL lists individual users or user groups (subjects) and
their privileges. User groups would be populated with lists
of user-IDs for persons with common information needs -- "programmers,"
"senior management, " etc.
Another way to
view the access control task is in terms of "roles"
and "rules." Users or user groups are assigned roles
(or user groups can just be defined as roles themselves).
A set of rules can then be applied to the roles to set the
precise terms of access.
Obviously, access
control is only as good as the software, hardware and liveware
(humans) that enforce it. It also depends on the quality of
the categorization of subjects and objects.
See also:
Last modified:
10-May-2005
[RC]
|
