Идентификатор клиента
В СУБД Oracle9i введено понятие идентификатора клиента (client identifier), который является значением, устанавливаемым в качестве атрибута сеанса. Все, что находится в этом атрибуте, в нашей ситуации мы можем использовать для представления имени фактического пользователя, такого, как JANE. И даже если имя пользователя базы данных зарегистрировано как APPUSER или что-то подобное, идентификатор клиента может иметь значение JANE.
Вы можете установить значение идентификатора клиента для сеанса с помощью поставляемой корпорацией Oracle пакетной процедуры dbms_session.set_identifier. Следующий оператор устанавливает в сеансе идентификатор SCOTT:
EXECUTE DBMS_SESSION.SET_IDENTIFIER ('SCOTT')
После установки этот идентификатор виден для данного сеанса в представлении V$SESSION: SELECT CLIENT_IDENTIFIER FROM V$SESSION WHERE AUDSID = USERENV('SESSIONID');
Здесь будет показано значение SCOTT, которое и было установлено ранее. Итак, какова важность этого значения? В дополнение к тому, что эта информация находится в представлении V$SESSION, она также обнаруживается в среде FGA в таблице FGA_LOG$ и, впоследствии, в представлении DBA_FGA_AUDIT_TRAIL в столбце CLIENT_ID, как показано ниже:
SELECT DB_USER, CLIENT_ID FROM DBA_FGA_AUDIT_TRAIL;
И даже если столбец DB_USER показывает пользователя базы данных, в журнале аудита FGA может быть найден реальный пользователь приложения, если его имя установлено в идентификаторе клиента. Это очень важно для понимания и применения во время аудита пользователей приложения.
Идентификатор клиента также находится в журнале обычного аудита, а не только в журнале детального аудита. Итак, во всех типах аудита, от обычного до расширенного детального, это значение обеспечивает недостающую связь для представления фактического пользователя. В случае обычного аудита идентификатор клиента, если он установлен в сеансе, записывается в таблицу AUD$ в столбец CLIENTID. Это значение находится в зависимых представлениях, таких, как DBA_AUDIT_TRAIL, в столбце CLIENT_ID.
Проблема: как установить это значение должным образом. Помните, в веб-приложениях пул соединений сеансы базы данных обслуживают много пользовательских сеансов, а значит, установка идентификатора только один раз в начале сеанса не поможет. Вместо этого приложение должно устанавливать идентификатор клиента перед каждым обращением к базе данных, чтобы средства FGA могли видеть фактический идентификатор пользователя приложения. Когда сеанс базы данных повторно используется другим потоком приложения, в идентификатор клиента вводится идентификатор данного пользователя, что позволяет "опознать" его в журнале аудита FGA.
Другой подход состоит в том, чтобы создать "куку" (cookie) и использовать это значение для установки идентификатора клиента. Этот способ более безопасен, поскольку "кука" может содержать другую аутентификационную информацию, которая не доступна в обычном сеансе. Значение в идентификаторе в этом случае может быть должным образом декодировано для получения реального имени пользователя, но аутентификационная информация добавляет к значению идентификатора клиента компонент целостности данных.
