Databases Reference
In-Depth Information
Of course, such information cannot be obtained from the relations but requires
auditing techniques introduced in Section 3.1.
Assume a relation
R
for which access properties is to be determined.
First, a suitable time-granularity is chosen for the auditing approach, such
as just one hour or a whole week. Next, audit mechanisms are designed and
enabled that record access information about SQL insert, update, delete, and
select statements against
R
. If only the frequency of such statements over a
period of time is of interest, then normal auditing based on the SQL
audit
command is sucient, and no database triggers are employed. However, if
more fine grained information about the data modification statements is of
interest, triggers have to be employed to record for each such SQL statement
what tuples have been inserted, deleted, or modified, the latter also recording
the old and new values of updated tuples.
Gathering fine-grained information about SQL select statements is much
harder to deal with. To our knowledge, there is no DBMS that provides mech-
anisms to record how many and what tuples have been retrieved by a select
statement, but only the plain, text-based SQL query plus some additional in-
formation such as access time and user account. Thus, excessive and possibly
anomalous reads against a database are hard to capture as part of a misuse
detection strategy. The only viable solution to this problem is to embed some
extra code in application programs (e.g., at the client side) and stored proce-
dures (at the database side) that make use of cursors to retrieve and process
individual result tuples from an SQL select query.
In the following, we denote the access profile for a relation
R
for a time
interval [
t
i
,t
j
]by
AccessP rof
(
R, t
i
,t
j
). The profile manages information (as
measure/value pairs) about the frequencies of all insert, delete, and update
statements, including information about individual tuples, and the frequency
of select statements against
R
. Note that for each individual statement, all
standard audit information as outlined in Section 3.1 is recorded as well. Fig-
ure 2 illustrates the structure and content of a relation used to manage infor-
mation about accesses to some relation
R
(
A
1
,A
2
,A
3
). Note that in the ideal
case, respective profiles and audit trails are not managed in the production
database but in another database that allows to analyze and evaluate au-
dit and profile information without interfering with the production database.
Oracle's Audit-vault product is a good example of such an approach [2].
∈R
timestamp user operation new tuple old tuple
09-01-07 09:12:14 scott insert
(3,8,12)
-
09-01-07 09:12:15 scott insert
(4,9,7)
-
09-01-07 09:13:01 smith update
(3,8,12)
(3,8,13)
09-01-07 09:13:02 jones delete
-
(4,9,7)
...
...
...
...
...
Fig. 2.
Snapshot of the basic information recorded for a data access profile for a
given database relation, including old and new values of modified tuples.
