Databases Reference
In-Depth Information
the update privilege on
R
. Similar scenarios can be devised for the case of
database roles where
u
db
does not use all the privileges associated with a role
r
db
. If such a behavior can be found for all other users of that role, then respec-
tive privileges should be revoked from
r
db
. The access path model provides
a convenient framework to explore such correlations and establish profiles on
demand (though information needs to be collected over a time window) in
order to evaluate known security policies or to get better insights into the
exact user and access behavior.
5 Security Reconfiguration
We now detail and summarize some basic tasks to reconfigure the security
setting and mechanisms of a database system using the information obtained
from data and user profiling and access path correlations presented in the
previous sections. We assume that appropriate (coordinated) authentication
and auditing mechanisms are in place at the application and database layer.
The objective of the reconfiguration of security mechanisms is to con-
strain the behavior of database users and roles such they have exactly those
privileges necessary and sucient to perform their tasks. In other words, the
mechanisms should realize the principle of
least privilege
[11, 31]. The problem
with most security mechanisms in database systems in achieving this objec-
tive, however, is that they basically rely solely on the SQL
grant
statement,
which in general does not allow to specify fine-grained access policies. This
means, for example, that if a user is only allowed to insert tuples that have
some well-defined properties, this admissible behavior cannot be specified us-
ing the
grant
statement. In general, this leaves plenty of room for malicious
or accidental misuse of privileges by insiders.
Integrity Constraints.
As discussed in Section 3.2, semantic integrity con-
straints provide an effective mechanism to constrain attribute values and com-
binations thereof to admissible ones. Most static integrity constraints can be
implemented easily, e.g., through database triggers or
check
clauses in rela-
tion schemas. These mechanisms can be used to prevent inadmissible attribute
values a user tries to (maliciously) insert or modify. Recall that such mecha-
nisms also have the side-effect of helping maintaining the quality of the data,
an important prerequisite for evaluating the security of a database.
Unused Accounts and Roles.
The access path model provides a framework
to detect unused database accounts and roles. In particular unused accounts
are vulnerable to misuse and thus should be locked or simply deleted. Simi-
larly, unused roles should be deleted, because they likely implement obsolete
policies. The deletion of roles can also have implications on the re-design of
role-hierarchies.
Unused Privileges.
As indicated at the end of Section 4, unused privileges
can be detected once access sub-paths have been annotated with respective
