FortiDB Version 3.2 Utilities User Guide
18
15-32000-81369-20081219
Chaining with Parameterized User-Defined Rules
Rule Chaining
SELECT username, osuser, terminal FROM v$session WHERE osuser =
'$osusername'
Multiple Source-Rule-Violation Behavior
When using the Rule Chaining feature with PUDRs, you might expect a target-
policy alert for each source-policy alert. However, unless there is a change in the
passed parameter, there will be only one PUDR alert--despite multiple source-
policy alerts.
For example, assume you have a session policy for your source rule, are passing
the terminal name to the target PUDR, and that the session policy is violated
twice. In this case, you will get two session-policy alerts because, due to different
timestamps, the session policy alerts are not the same. However, you will get only
one PUDR alert because the terminal name doesn't change.
DB Example
For example, when using a DB2 target database and passing
$objectowner
,
only one PUDR (target rule) alert will show up, regardless of how many times the
source rule gets violated. (A source-rule alert will appear for each violation.)
$objectowner
is replaced by the
creator
parameter which represents the
authorization ID of the user who pre-compiled the application
1
. This ID does not
change when a user executes multiple SQL queries thereby triggering multiple
source-rule alerts. Therefore, you can expect only one PUDR alert.
For example, assume:
a
You set up a source-rule User Policy that monitors user X.
b
You have a target-rule PUDR that expects
$objectowner
to be
passed; like this:
SELECT '$objectowner' FROM SYSIBM.SYSDUMMY1 AS
SYSDUMMY1
c
User X issues these two queries:
SELECT * from my.employee
SELECT * from x.table1
In this case, two source-rule alerts should show up but only one PUDR (target
rule) alert.
PUDR Alert Behavior with Multiple SELECT-List Objects in the Violating SQL State-
ment
FortiDB MA can detect, and alert on, only the first item in a multiple-object
SELECT list.
For example, assume you have created a user policy which gets violated by a
user's executing:
SELECT * FROM vje.test, vje.test1
1.
For more information, see
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r000
7595.htm