Введение

InfoSphere Guardium — это система мониторинга активности базы данных корпорации IBM. Она предоставляет функции аудита и безопасности с низким уровнем влияния на производительность для баз данных в масштабах всей организации. С ее помощью организации могут отслеживать все происходящее внутри базы данных на самом высоком уровне детализации с минимальной степенью вмешательства в работу системы и влияния на производительность.

Трансляция пользователей приложения — это процесс идентификации приложения, с помощью которого конечные пользователи осуществляют определенные транзакции с базой данных. Он подразумевает отслеживание активности конечного пользователя через прикладной уровень и вплоть до уровня базы данных. Поскольку создание соединения с базой данных является относительно дорогостоящей операцией, необходимость создания нового соединения с базой данных при каждом входе пользователя в систему оказывало бы значительное влияние на производительность. Для решения данной проблемы серверы приложений создают пул многократно используемых соединений, осуществляя их ротацию для транзакций приложения. При создании пула соединений для входа в систему базы данных используется одна учетная запись пользователя базы данных с высоким уровнем полномочий. В таком случае приложение принимает на себя функции контроля доступа к любым данным, запрашиваемым из базы данных с использованием пула соединений.

Результатом использования пула соединений является увеличение скорости работы приложения. К сожалению, еще одним следствием создания пула соединений является потеря информации о том, какие именно конечные пользователи приложения выполняли определенные транзакции с базой данных. Это порождает проблему. Определение конечных пользователей приложения имеет решающее значение для любой среды баз данных, предъявляющей строгие требования к аудиту. Например, в сфере здравоохранения понимание того, какие именно конечные пользователи получают доступ к электронной защищенной информации о состоянии здоровья пациентов (EPHI), может являться одним из обязательных для соблюдения требований Закона о преемственности и подотчетности медицинского страхования (HIPAA) в США. В финансовом секторе определение пользователей приложения улучшает возможности финансового контроля и учета, что может помочь в обеспечении соответствия требованиям Закона США о борьбе с корпоративным и бухгалтерским мошенничеством (закон Сарбейнса-Оксли) от 2002 г.

В этой статье описывается порядок использования пяти различных методов конфигурирования InfoSphere Guardium для решения указанной проблемы. Кроме того, статья поможет разобраться, какой из способов является оптимальным для конкретного приложения.

На наиболее общем уровне существует пять методов идентификации пользователей приложения в Guardium:

1. Встроенная трансляция пользователей приложения.
2. Определение переключений пользователей при помощи API Guardium Application Event.
3. Анализ шаблонов в хранимых процедурах.
4. Агенты S-TAP сервера приложений.
5. Интерфейсы API серверов баз данных и приложений.

В начало

Встроенная трансляция пользователей приложения

Guardium поддерживает различные коммерческие приложения. В их число входят Oracle E-Business, PeopleSoft, Siebel, SAP и Business Objects. Разработчики Guardium исследовали работу каждого из этих приложений и выявили шаблоны в SQL-запросах, выполняемых этими приложениями. Было установлено, что каждое приложение осуществляет обязательную идентификацию своих пользователей в SQL-операторах, выполняемых во время совершения транзакции. Путем выявления таких шаблонов в SQL-запросах Guardium может извлекать информацию о том, какой конечный пользователь приложения совершает транзакцию с базой данных.

Пример: Siebel

С целью демонстрации этих функциональных возможностей в данной статье приведено детальное изучение трансляции пользователей приложения Siebel CRM. При любом совершении транзакции в Siebel для затрагиваемых таблиц происходит обновление поля, указывающего на конечного пользователя. Продукт Guardium можно сконфигурировать для извлечения этой информации во время транзакции в Siebel.

Например, при обновлении значения дохода в Siebel транзакция SQL UPDATE записывается в Guardium примерно так:

UPDATE SIEBEL.S_REVIN 
  SET DB_LAST_UPD_SRC='User'.DB_LAST_UPD=current timestamp-current timezone, 
  LAST_UPD='2-11-04-19.49.43.000000',LAST_UPD_BY='8SIA-7ZPPT',
  MODIFICATION_NUM=0000000000000000,ACCNT_ID='1-4YR' 
  WHERE ROW_ID='UA1-1V1TV AND MODIFICATION_NUM=0000000000000000

На рисунке 2 показано, как данный SQL-код записывается в Guardium.

Продукт Guardium можно настроить для извлечения информации об идентификаторе (8SIA-7ZPPT) и имени пользователя (FBROOKS) для данного оператора. Это показано на рисунке 3:

Данный пример показывает способ, с помощью которого аудиторы и сотрудники, отвечающие за соблюдение соответствия нормам, могут с легкостью отследить, какой пользователь приложения совершил определенные транзакции с базой данных, при наличии соответствующей конфигурации Guardium.

Конфигурирование

Теперь, рассмотрев пример с Siebel, приведем описание процесса конфигурирования встроенной трансляции пользователей приложения. Конфигурации для Oracle E-Business, PeopleSoft, Siebel, SAP и Business Objects различны, но имеют некоторые общие моменты.

Первый шаг — конфигурирование процесса трансляции в консоли администрирования Guardium Administration Console, как показано на рисунке 4.

В панели Application User Translation (Трансляция пользователей приложения) указан ряд параметров для базы данных приложения. Если Guardium требует подключения к базе данных с целью импорта информации о соответствиях между идентификаторами и именами пользователей, необходимо также указать имя пользователя базы данных и ввести пароль (это касается Oracle E-Business и Siebel). Если имена пользователей указываются непосредственно в шаблонах SQL, необходимо указать только IP-адреса и номера портов приложения, например, для PeopleSoft и Business Objects.

После того как эти параметры будут введены в консоли администрирования Guardium, потребуется выполнить перезапуск механизма проверки Guardium с целью осуществления трансляции пользователей приложения, как показано на рисунке 6.

Это все, что потребовалось бы сделать для PeopleSoft и Business Objects. Для Oracle E-Business и Siebel дополнительно необходимо импортировать информацию о соответствиях между идентификаторами пользователей приложения и именами пользователей приложения. Для импорта этих соответствий необходимо запустить процесс импорта трансляции пользователей приложения, а затем запланировать выполнение импорта на регулярной основе. Средства управления этим процессом находятся в консоли администрирования, как показано на рисунке 7.

После того как встроенная трансляция пользователей приложения сконфигурирована и запущена, можно переходить к изучению стандартных отчетов Guardium для просмотра активности пользователей приложения. Например, для Oracle E-Business предоставлены отчеты EBS Processes Database Access (Доступ к базе данных процессов EBS) и EBS Application Access (Доступ к приложению EBS). Для корректного составления данных отчетов необходимо заполнение некоторых групп в Guardium. Для получения информации о таких группах обратитесь к Определению запросов для отчетов, показанному на рисунке 8.

Также возможно создание собственных отчетов с отображением данных о пользователях приложения. Для этого необходимо сформировать отчет и добавить поля App User Name (Имя пользователя приложения) из граф Access Period (Период доступа) и App User Name (Имя пользователя приложения). При просмотре отчетов убедитесь в том, что включены Aliases (Псевдонимы).

Некоторые замечания относительно SAP

В панели конфигурирования Application User Translation (Трансляция пользователей приложения) SAP имеет отдельную запись в списке Application Type List (Список типов приложений) — SAP Observed. Для осуществления трансляции пользователей приложения SAP нет необходимости в конфигурировании при помощи панели. Указанная запись присутствует в консоли администрирования исключительно по историческим причинам. Вместо этого для конфигурирования трансляции пользователей приложения для SAP необходимо заполнение групп SAP App Servers (Серверы приложения SAP) и SAP DB Servers (Серверы БД SAP) в Guardium, как показано на рисунке 9.

Сразу после заполнения IP-адресов сервера приложений и сервера баз данных необходимо перезапустить механизмы проверки для осуществления трансляции пользователей приложения.

Методы БД

Существует дополнительный не рассмотренный выше вариант для Siebel и SAP, представляющий собой трансляцию на основе БД, как показано на рисунке 10.

На самом деле никакой трансляции здесь не осуществляется. Guardium просто импортирует данные аудита, которые уже были извлечены приложением. Это более старый и более инвазивный метод, поэтому рекомендуемой конфигурацией является использование наблюдаемых методов. При необходимости использования методов БД вместо наблюдаемых требуется активация функций аудита SAP и Siebel. Для Siebel это означает, что для параметра Docking: Transaction Logging должно быть установлено значение TRUE (ИСТИНА). Для SAP для параметра rdisp/vb_delete_after_execution должно быть установлено значение 2. Дополнительно в случае SAP необходимо регулярно выполнять транзакцию rsm13002 с командой DELETE (УДАЛИТЬ) для очистки отчета.

В начало

API InfoSphere Guardium Application Event

Теперь, после рассмотрения встроенной трансляции пользователей приложений, мы рассмотрим API Guardium Application Event. В отличие от встроенной трансляции пользователей приложений, API Guardium Application Event будет работать с любым приложением при условии, что оно может быть сконфигурировано или модифицировано для выполнения SQL-операторов при переходе контроля над сеансом от одного пользователя приложения к другому.

Вызовы API Application Event – это простые пустые SQL-операторы, выполняемые до и после взятия пользователем приложения контроля над каким-либо соединением в пуле. Пустые вызовы сообщают Guardium о том, какой именно пользователь приложения в настоящий момент работает с базой данных. Такие вызовы не подразумевают каких-либо изменений в базе данных, но могут быть распознаны Guardium. Обычно такие пустые вызовы выполняются в специальных однострочных таблицах, таких как таблицы SYSDUMMY1 в DB2 для LUW или DUAL в ORACLE DB.

Для трансляции пользователей приложения вызов API Guardium AppEvent обычно принимает следующую форму:

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:user_name' FROM DUMMY_TABLE;
-- SQL Transactions related to the user named user_name
SELECT 'GuardAppEvent:Released'  FROM DUMMY_TABLE;

Эту концепцию легко продемонстрировать при помощи инструментальных средств командной строки базы данных. Рассмотрим выполнение следующего SQL-кода в интерфейсе командной строки DB2 LUW:

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:fbrooks' FROM SYSIBM.SYSDUMMY1;
SELECT count(*) FROM ITEMS;
SELECT 'GuardAppEvent:Released'  FROM SYSIBM.SYSDUMMY1;

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:kzuse' FROM SYSIBM.SYSDUMMY1;
SELECT count(*) FROM ITEMS; 
SELECT 'GuardAppEvent:Released'  FROM SYSIBM.SYSDUMMY1;

Как показано на рисунке 12, сеанс в Guardium отображает то, как пользователь fbrooks приписывается к первому оператору SELECT count(*). Также здесь показывается, как пользователь переключается на kzuse для второго оператора SELECT count(*).

Обычно для применения API Application Event требуется изменение приложения перед использованием. Заказчикам необходимо изменять код приложения для выполнения пустых команд SQL при любом переключении пользователей в пуле соединений во время сеанса. Однако некоторые приложения обладают достаточной гибкостью для того, чтобы позволить выполнять пустые вызовы SQL без изменений кода.

В начало

Идентификация пользователей приложения с помощью хранимых процедур

Идентификация пользователей приложения с помощью хранимых процедур похожа на идентификацию с использованием API Guardium Application Event, рассмотренную в предыдущем разделе в том отношении, что здесь для определения границ между пользователями в рамках одного сеанса работы с базой данных также используются SQL-операторы. В этом случае вместо пустых SQL-операторов используются хранимые процедуры. Если при смене пользователя приложения в пуле соединений приложение выполняет какую-либо хранимую процедуру ожидаемым способом, продукт Guardium можно сконфигурировать для извлечения этой информации и назначения атрибутов пользователю.

В качестве примера рассмотрите ситуацию, показанную на рисунке 13, когда приложение выполняет набор операторов в рамках одного сеанса работы с базой данных.

Вызов set_application_property с параметром user_name выполняется при каждом переключении пользователей приложения в пуле соединений. Продукт Guardium можно сконфигурировать для выявления такого вызова хранимой процедуры и использования второго параметра в качестве текущего имени пользователя приложения, как показано на рисунке 14.

Конфигурирование

Для того чтобы продукт Guardium идентифицировал пользователя при помощи описанного выше вызова хранимой процедуры, необходимо определить новую пользовательскую процедуру идентификации в консоли администрирования Guardium. Именем данной процедуры будет являться имя хранимой процедуры, вызываемой приложением при переключении пользователей, в данном случае set_application_property. Во избежание вызовов этой же процедуры с user_date в качестве первого параметра вы можете указать в качестве первого параметра user_name, создав для него значение условия. Наконец, требуется указать, что в качестве второго параметра в объекте Application Event (Событие приложения) будет использоваться поле Username (Имя пользователя). Затем можно добавить поле Application Event Username (Имя пользователя события приложения) в ваши отчеты для просмотра пользователей приложения, как показано на рисунке 15.

Данный способ идентификации пользователей приложения идеален для тех приложений, где часто используются хранимые процедуры или где границы между пользователями задаются при помощи вызова хранимых процедур. Также существуют приложения, которые недостаточно гибки для вызова пустых операторов выбора с целью использования API Guardium Application Event, но могут быть сконфигурированы для вызова соответствующих хранимых процедур. Для таких приложений данный метод также является оптимальным.

В начало

Агенты S-TAP сервера приложений

Бывают ситуации, когда изменение исходного кода приложения невозможно либо нежелательно, поэтому API Guardium Application Event использоваться не может. Приложение также может не использовать хранимые процедуры для определения границ между пользователями. В некоторых из этих случаев для идентификации пользователей приложения может использоваться способность агентов S-TAP Guardium осуществлять мониторинг трафика сети. При этом S-TAP используется для соотнесения конечных пользователей приложения с действиями в базе данных. Агент S-TAP устанавливается на хосте сервера приложений, а не на сервере базы данных. Затем агент конфигурируется для мониторинга входящего HTTP-трафика сервера приложения, а также для фильтрации имен пользователей и их соотнесения с действиями в базе данных с использованием идентификаторов сеансов сервера приложения. В Guardium этот подход называется идентификацией пользователей сервера приложений (Application Server User Identification) или S-TAP сервера приложений (Application Server S-TAP).

Данный подход имеет много преимуществ, так как он не требует изменения приложения или переконфигурирования сервера приложений. Поэтому такое решение является очень быстрым и простым. Недостатком данного способа является то, что он доступен не для всех корпоративных приложений. Возможной проблемой также является несовместимость механизмов аутентификации, которые шифруют или хешируют имена пользователей. S-TAP сервера приложений будет оптимальным вариантом для стандартных корпоративных приложений Java, использующих тип аутентификации Form Login (вход в систему с использованием формы).

Анализ приложения

Первым шагом конфигурирования S-TAP сервера приложений является анализ приложения, подлежащего аудиту.

Необходимо определить следующие три аспекта.

• HTTP-порт сервера приложений.
• Способ идентификации имени пользователя приложения в HTTP-трафике во время входа в систему.
• Способ определения идентификатора сеанса Java, сопоставляемого с именем пользователя.

При наличии большого спектра инструментальных средств анализа Web-трафика одним из самых простых будет использование плагина Firefox, называемого Live HTTP Headers. Его установка позволяет легко просматривать HTTP-трафик, передаваемый во время входа в систему по Интернету, как показано на рисунке 16.

В данной статье в качестве примера используется демонстрационное приложение Plants By Websphere. При входе в приложение под именем пользователя jon@doe.com. Вы увидите HTTP-трафик в окне Live HTTP headers, как показано на рисунке 17.

В приложении Plants By Websphere интересующий вас HTTP-вызов – это вызов Post к сервлету AccountServlet с параметром action=login. Вы можете видеть, что имя пользователя передается в содержимом вызова HTML POST. Фактическое имя пользователя имеет префикс userid= и постфикс &.

Идентификатор сеанса Java передается в cookie-файле вместе с вызовом, он имеет префикс JSESSIONID= и постфикс &.

Конфигурирование S-TAP сервера приложений

Для активации S-TAP сервера приложений необходимо сконфигурировать коллектор Guardium в соответствии с информацией, полученной из HTTP-потока, как показано на рисунке 18.

Конфигурирование осуществляется в консоли администрирования Guardium по пути Administration Console, Local Taps, S-TAP control. Здесь доступны все основные настройки конфигурации для S-TAP, как показано на рисунке 19. Для применения данного способа при конфигурировании агента S-TAP он должен быть установлен на хосте сервера приложений, а не на сервере баз данных.

На рисунке 19 показана конфигурация S-TAP сервера приложений на примере Plants By Websphere. Эти настройки соответствуют значениям, полученным из HTTP-трафика. Значение Ports (Порты) – это номер HTTP-порта сервера приложений, на котором работает приложение. Имя пользователя приложения передается Web-приложением с префиксом userid= и постфиксом &. Информация о доступе к базе данных передается с префиксом JSESSIONID= и постфиксом & в cookie-файле HTTP для идентификатора сеанса, который необходимо соотнести с пользователем приложения. Записи шаблона используются продуктом Guardium для проверки местоположения в HTTP-потоке.

После изменения параметров необходимо применить внесенные изменения. Затем произойдет перезапуск S-TAP и замена статуса на положительный.

После конфигурирования идентификации пользователей сервера приложений Guardium сохраняет имя пользователя приложения в поле Application User в объекте Access Period. Данное поле может быть добавлено в отчеты. На приведенном выше рисунке 20 представлен отчет, содержащий имя пользователя БД, которое относится к пользователю, связанному с источником данных JDBC (JDBC Datasource) и пользователем приложения (Application User), который представляет собой фактическое имя пользователя приложения, введенное во время входа в систему.

Выводы по S-TAP сервера приложений

S-TAP сервера приложений – это очень простой способ идентификации пользователей для приложений сервера приложений Java (Java Application Server) при отсутствии доступа к встроенному функционалу. Данный способ не требует проведения каких-либо изменений в существующих приложениях, что делает его очень привлекательным решением. Тем не менее следует учитывать несколько аспектов.

Для работы S-TAP сервера приложений имя пользователя должно передаваться прямым текстом в HTTP-потоке. Некоторые механизмы аутентификации, например, обычная аутентификация на основе HTTP, предусматривают хеширование или кодирование Base64 и потому не поддерживаются. При этом элементы Form Login передают имя пользователя прямым текстом.

Данный метод работает не со всеми приложениями. Это зависит от способа использования пула подключений. Например, метод требует, чтобы доступ к базе данных был синхронизирован с тем же процессом или потоком, который обрабатывает HTTP-запрос. Хорошим примером является приложение на основе сервлета, где сервлет обрабатывает HTTP-запросы и при выполнении этого процесса соединяется с пулом подключений для доступа к базе данных.

HTTPS-соединения также не поддерживаются. Обычно это не критично, так как S-TAP устанавливается на сервере приложений. В обычных корпоративных конфигурациях по протоколу HTTPS шифруется только трафик к Web-серверу, а для соединения между Web-сервером и сервером приложений используется стандартный протокол HTTP.

В начало

Интерфейсы API серверов баз данных и приложений

Guardium является не единственной системой аудита, которая сталкивается с проблемой распространения идентификации пользователей приложения с прикладного уровня вплоть до уровня базы данных. Перед многими собственными решениями баз данных для аудита стоит такая же проблема. В этих решениях проблема устраняется путем добавления в системы дополнительных API. С течением времени серверы приложений стали создаваться таким образом, чтобы можно было пользоваться данными API, и, следовательно, стал доступным аудит с минимальными усилиями по разработке приложений. Хорошая новость заключается в том, что продукт Guardium предусматривает возможность выявления использования таких API и соответствующего назначения пользователей приложений.

Примеры с DB2

Для иллюстрации данного процесса мы рассмотрим примеры с базой данных IBM DB2 LUW и сервером приложений WebSphere Application Server (WAS). Первый пример – это реализация в DB2 LUW стандартного API JDBC Connection.setClientInfo. Рассмотрим приложение, следующим образом использующее API setClientInfo:

Class.forName("com.ibm.db2.jcc.DB2Driver");
Properties props = new Properties();
props.setProperty("user", "guard");
props.setProperty("password", "password");
Connection  connection = DriverManager.getConnection("jdbc:db2://10.10.9.28:50001/orders"
, props);

connection.setClientInfo("ClientUser", "fbrooks");
execSelectOnItems(connection);

connection.setClientInfo("ClientUser", "kzuse");
execSelectOnItems(connection);

Этот пример является вымышленным. В реальном приложении имена пользователей вряд ли будут записаны непосредственно в программном коде. Вместо этого пользователь приложения будет вставляться в качестве переменной. Вероятно, пользователь будет определяться по идентификатору сеанса. Константы fbooks и kzuse использованы исключительно для демонстрации концепции. Для обработки информации базы данных метод execSelectOnItems выполняет простой оператор SELECT, который извлекает количество записей в таблице с именем ITEMS. Guardium захватывает трафик базы данных и назначает любой SQL-запрос, выполненный после вызова setClientInfo("ClientUser", "fbrooks"), пользователю fbrooks. Как показано на рисунке 21, конфигурирование не требуется.

Вторым примером является организация пула соединений DB2 с использованием доверенных контекстов. Доверенные контексты позволяют конфигурировать DB2 LUW для доверия паре IP-адрес/имя пользователя. Это позволяет при желании пропускать повторное проведение аутентификации и соединения при переключении имен пользователей базы данных. В отличие от API setClientInfo, переключение имени пользователя с использованием доверенных контекстов позволяет DB2 применять любые средства управления доступом, связанные с данным пользователем. Фактический пользователь DB2 сменяется. При использовании доверенных контекстов вы получаете и высокую производительность системы, и возможность использования всех механизмов контроля доступа, которые доступны для современных баз данных. Еще одним важным аспектом, связанным с доверенными контекстами, является то, что Guardium получает информацию о переключении пользователей. Для Guardium переключение выглядит как особый тип оператора подключения. В качестве иллюстрации этого переключения рассмотрите следующий код, который мог бы быть выполнен на сервере приложений.

Object[] objects = new Object[6];
Properties properties = new Properties();
byte[] cookie = new byte[1];
Connection con;
DB2ConnectionPoolDataSource ds1 = 
new DB2ConnectionPoolDataSource();	      
ds1.setServerName("10.10.9.28");
ds1.setPortNumber(50001);
ds1.setDatabaseName("orders");
ds1.setDriverType (4);
	 
objects = ds1.getDB2TrustedPooledConnection("guard", "password", properties); 
DB2PooledConnection pooledCon = (com.ibm.db2.jcc.DB2PooledConnection)objects[0];
cookie = (byte[])objects[1];
con = pooledCon.getDB2Connection(cookie, "fbrooks", null, null, null, null, properties);
execSelectItems(con);
con = pooledCon.getDB2Connection(cookie, "kzuse", null, null, null, null, properties);
execSelectItems(con);

Выполнение данного кода на сервере приложений будет выглядеть в Guardium так, как показано в примере на рисунке 22.

В поле DB User Name (Имя пользователя БД) указывается пользователь, который первоначально выполнил вход в систему с сервера приложений. Это доверенный пользователь для доверенного контекста. Поле пользователя приложения указывает на текущего пользователя, работающего в пуле соединений. Граница между пользователем базы данных и пользователем приложения начинает размываться, поскольку kzuse и fbrooks являются реальными пользователями базы данных с привилегиями уровня базы данных, но при этом они также являются и пользователями приложения. Подобные интерфейсы API существуют и для других баз данных, и Guardium должен иметь возможность поддерживать большинство из них.

В обоих приведенных выше примерах (с доверенными контекстами и с setClientInfo) речь идет о том, каким образом приложения могут получать непосредственный доступ к API. Большинство корпоративных приложений оставляют данные типы вызовов на откуп серверу приложений. WebSphere – один из таких серверов приложений, который может совершать вызовы. WebSphere с автоматическим использованием доверенных контекстов DB2 рассматривается в следующем разделе.

Пример с WebSphere

Вы можете сконфигурировать WebSphere 7 для использования доверенных контекстов DB2 в рамках конфигураций входа в систему ссылок на ресурсы приложения. При этом сервер WebSphere может быть сконфигурирован для автоматического использования доверенных контекстов, как показано на рисунке 23. Подробные инструкции по осуществлению такого конфигурирования приводятся в разделе ресурсов.

Вы также можете сконфигурировать WebSphere для использования плагинов (например, DataStoreHelper), которые будут вызывать либо интерфейсы API Guardium Application Event, либо API базы данных. Более подробная информация об этом приведена в статье на портале developerWorks Developing Special DataStoreHelper Plugins for WebSphere to insert Pre and Post SQL (Разработка специальных плагинов DataStoreHelper для WebSphere, которые должны вставляться перед SQL-кодом и после него), ссылка на которую приводится в разделе ресурсов. Сервер WebLogic также обладает подобным функционалом. Он вызывает процесс Credential Mapping (Отображение учетных записей). Ссылка на информацию о том, как сконфигурировать WebLogic для использования процесса Credential Mapping, также приводится в разделе ресурсов.

В начало

Заключение

Одной из ключевых проблем программного обеспечения для аудита баз данных является идентификация конечных пользователей приложений, работающих с базами данных. Данная проблема возникает в связи с тем, что для повышения производительности серверы приложений реализуют пулы подключений к базам данных.

Вы познакомились с пятью различными методами идентификации пользователей приложений в Guardium. Каждый из них имеет свои сильные и слабые стороны и может применяться, например, в следующих ситуациях.

• Для таких поддерживаемых приложений, как Siebel или SAP, лучшим выбором, несомненно, является встроенная трансляция пользователей приложений.
• Для таких поддерживаемых приложений, как Siebel или SAP, лучшим выбором, несомненно, является встроенная трансляция пользователей приложений.
• Для многих приложений, использующих вызовы хранимых процедур для управления собственными пользователями, одним из удачных решений является анализ шаблонов в хранимых процедурах.
• Если изменить исходный код приложения невозможно, а соответствующее приложение представляет собой стандартное корпоративное приложение Java (Java Enterprise Application), одним из быстрых и простых решений проблемы может быть использование S-TAP сервера приложений.
• Если сервер приложений и база данных поддерживают интерфейсы API для передачи информации о пользователях приложения, это также можно использовать.

В настоящей статье мы рассмотрели проблему идентификации пользователей приложений в программном обеспечении для аудита баз данных. Мы представили обзор доступных методов идентификации пользователей приложений в Guardium, а также продемонстрировали возможный порядок реализации этих методов. Мы также обозначили ситуации, предусматривающие возможность использования каждого из этих методов.

Ресурсы

• Оригинал статьи: InfoSphere Guardium application user translation
  
  
• Узнайте больше об InfoSphere Guardium в библиотеке IBM InfoSphere Guardium
  
  
• Получите дополнительные сведения об активации доверенных контекстов для баз данных DB2
  
  
• Усовершенствуйте поддержку доверенных контекстов DB2 с использованием Data Studio
  
  
• Узнайте о порядке конфигурирования решения Mashup Center для использования доверенного контекста DB2 через WebSphere
  
  
• Узнайте больше о разработке специальных плагинов DataStoreHelper для WebSphere с целью их вставки перед SQL-кодом и после него.
  
  
• Прочитайте о передаче идентификационной информации баз данных на сервер приложений WebSphere V6
  
  
• Узнайте больше об активации отображения учетных записей JDBC на сервере Weblogic для DB2 и Oracle
  
  
• Изучите способы использования блоков команд Cognos перед SQL-кодом и после него
  
  

Об авторах

Джон Холдмэн (John Haldeman) работает в команде Optim and Guardium Technology Ecosystem в лаборатории IBM в Торонто. Команда Technology Ecosystem предоставляет техническую поддержку деловым партнерам IBM на всех этапах процесса продаж: от демонстраций и проверок концепции до реализации и передовых практических методов.

Бенджамин Леонхарди (Benjamin Leonhardi) является разработчиком программного обеспечения в команде InfoSphere Warehouse and Netezza Technology Ecosystem в лаборатории IBM в Торонто. До этого он работал разработчиком программного обеспечения для InfoSphere Warehouse в Научно-исследовательской лаборатории IBM в Бёблингене (Германия). Бенджамин имеет опыт разработки в области анализа и извлечения данных, интеллектуального анализа текстов и разработки решений по отчетности.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Встроенная трансляция пользователей приложения
• API InfoSphere Guardium Application Event
• Идентификация пользователей приложения с помощью хранимых процедур
• Агенты S-TAP сервера приложений
• Интерфейсы API серверов баз данных и приложений
• Заключение
• Ресурсы
• Об авторах
• Комментарии