Databases Reference
In-Depth Information
so-called
instead-of triggers
that can execute some SQL modification state-
ments on base relations whenever a modification statement is issued against
a view. Thus, views can even be used in the context of SQL data modification
statements.
Stored Procedures.
A major limitation of discretionary access control mod-
els in relational databases is that SQL
grant
statements for assigning priv-
ileges to users and roles are often too coarse-grained. Some of these limita-
tions can be circumvented by view privileges instead of privileges on base
relations, as outlined above. However, oftentimes granting access to some re-
lations (and views) depends on
context information
that cannot easily be
specified in a view definition. Such context information might include con-
current database user sessions, time information, and the origin of database
requests (e.g., application hosts). There has been some substantial work on
more expressive access control models that take such context information into
account and therefore provide more dynamic access control mechanisms (see,
e.g., [10, 16, 17, 27, 28]).
As indicated in Section 3.1, stored procedures provide a powerful means to
collect context information (e.g., for auditing purposes) when the procedures
are called from application programs instead of plain SQL data modification
statements. In the same way, stored procedures can be used to gather context
information about its current execution, and one can use this information
to make fine-grained access control decisions. For example, when a stored
procedure is supposed to perform an update issued by an application, SQL
queries in the procedure's body then can query data dictionary relations or
call other (remote) procedures, and subsequently make a decision on whether
or not the update operation is admissible. Clearly, using stored procedures
might require modifications to some application code in that procedures are
called instead of plain SQL DML statements. In general, stored procedures
seem to be an effective means that help in dealing with misuse prevention,
rather than just misuse detection (as done by analyzing audit trails after the
fact).
The choice of an appropriate security re-design strategy for a particluar
vulnerability discovered in analyzing access paths depends on several factors.
First and foremost, there is the issue of database performance. Integrity con-
straints, triggers, stored procedures and even auditing occur some overhead
in verifying conditions or executing additional code. Here again it is impor-
tant to balance the ecient and reliable performance of the database and it
applications with the various security requirements. As the access path model
allows to gradually detect and analyze vulnerabilities, driven by specific secu-
rity foci, re-designed security mechanisms can be gradually implemented and
evaluated for performance. In general, the aspect of performance impact se-
curity mechanisms have on a database is rarely discussed in related work but
leaves an interesting area for further investigation and re-design strategies.
