Databases Reference
In-Depth Information
access profiles. As the content of an access profile clearly depends on the time
window for which information has been collected, care has to be taken to
ensure that the suspected unused privilege is not used only on rare occasions.
In this case, it is likely that this privilege should then be associated with a
separate role and not with a role for which the privilege has been determined
as inactive during the time window. The revocation of unused or obsolete
privileges and roles from users and roles clearly helps a lot in achieving the
goal of least privilege.
Discovery and Re-design of Database Roles.
Database roles help in
administering privileges associated with complex tasks [24, 45], i.e., activi-
ties by different types of application users. Assume that for a set of mission-
critical relations data and user access profiles have been determined. Respec-
tive access paths in the access path model can now be analyzed to determine
whether there are similarities among accesses to the relations by these differ-
ent database users. If no roles (or only some default role) have been associated
with these users in the context of respective accesses, database roles (and role
hierarchies) can be introduced to better capture similar privileges used by
these accounts and to ease the management of privileges.
There has recently been a great interest in mining roles from permission
assignments (see, e.g., [52, 58]). Such approaches can be extended to include
more fine-grained access information, such as those represented by access pro-
files. The design and evaluation of roles and role hierarchies as well as a
security analysis focusing just on roles [35] is a topic on its own that can
effectively be integrated in our security re-engineering approach.
Derivation of Database Views.
One of the most effective mechanisms to
achieve the principle of least privilege is to have database views, and to give
database users privileges on these views rather than the underlying relations.
The derivation of such views is not an easy task and requires a careful analysis
of access profiles. Assume a database user
u
db
who has been granted select,
insert, and update privileges on a relation
R
. The access profile for
u
db
might
show that the user only selects certain types of tuples and the tuples she mod-
ifies have similar characteristics. The description of these tuples, represented
in the user profile for
u
db
, then can be used to derive a view
V
that contains
only tuples the user typically operates on. The privileges
u
db
has on
R
are
then revoked, and the user is assigned respective privileges on the view
V
.
More complex views can be derived as well for SQL select statements that
refer to more than one relation.
The idea of view derivation from access profiles is relatively unexplored
as it is a non-trivial task to precisely describe the data (based on user pro-
files) that are necessary and sucient for the user to perform her legitimate
tasks. A practical problem might be that an access profile does not cover a
large enough time window, and the view derived from the profile then would
prevent the user from performing tasks she only does on rare occasions. Note
that most of today's DBMSs address the view update problem by providing
