Трансляция пользователей приложений с помощью продукта InfoSphere Guardium

Пять методов идентификации конечных пользователей приложений, связанных с операциями с базой данных.

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

Джон Холдмэн, разработчик программного обеспечения, IBM

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



Бенджамин Леонхарди, разработчик программного обеспечения, IBM

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



30.11.2012

Введение

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

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

Рисунок 1. Доступ к базе данных с использованием пула соединений
Diagram Showing Three Application Users: fbrooks, kzuse, and aturing Being Consolidated Into a Single Database User: APPS Via a Connection Pool

Результатом использования пула соединений является увеличение скорости работы приложения. К сожалению, еще одним следствием создания пула соединений является потеря информации о том, какие именно конечные пользователи приложения выполняли определенные транзакции с базой данных. Это порождает проблему. Определение конечных пользователей приложения имеет решающее значение для любой среды баз данных, предъявляющей строгие требования к аудиту. Например, в сфере здравоохранения понимание того, какие именно конечные пользователи получают доступ к электронной защищенной информации о состоянии здоровья пациентов (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.

Рисунок 2. SQL-оператор UPDATE, выполняемый приложением Siebel CRM при обновлении значений дохода
Guardium screen with SQL ID, timestamp, session ID, server IP, source program, db user name, and full SQL

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

Рисунок 3. Извлечение продуктом Guardium идентификатора пользователя из оператора Update и сопоставление данного идентификатора с именем пользователя
Guardium Extracting the User ID from the Update Statement

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

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

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

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

Рисунок 4. Меню Application User Translation (Трансляция пользователей приложения) в консоли администрирования
Screen shot of Administration Console with application user translation highlighted

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

Рисунок 5. Пример конфигураций для Siebel, Business Objects, Oracle E-Business и PeopleSoft
Figure 5 shows the example configurations for Siebel, Business Objects, Oracle E-Business, and PeopleSoft

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

Рисунок 6. Конфигурация механизма проверки в Guardium
The Inspection Engine Control in Guardium. This is Where the Inspection Engines Would be Restarted

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

Рисунок 7. Диалоговое окно конфигурирования импорта соответствий
Configuration Dialog for Mapping import

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

Рисунок 8. Определение запроса для отчета EBS Application Access (Доступ к приложению EBS)
Query Definition for the EBS Application Access Report. For this Report to Run Correctly, Two Groups must be Populated: EBS App Servers and EBS DB Servers

Также возможно создание собственных отчетов с отображением данных о пользователях приложения. Для этого необходимо сформировать отчет и добавить поля 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.

Рисунок 9. Две группы для заполнения с целью конфигурирования трансляции пользователей приложения SAP
The Two Groups to Populate in Order to Configure SAP Application User Translation

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

Методы БД

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

Рисунок 10. Выбор трансляции пользователей приложения БД в консоли администрирования для Siebel и SAP
DB Application User Translation can be selected In the Administration Console for Siebel and SAP

На самом деле никакой трансляции здесь не осуществляется. 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;
Рисунок 11. Выполнение API Guardium Application Event из командной строки DB2 в Linux
Figure 11 shows how the Guardium Application Event API from the DB2 Command Line in Linux is excecuted

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

Рисунок 12. Отнесение оператора SELECT count(*) к пользователю приложения
Attributing a SELECT count(*) Statement to the Application User fbrooks Using the Guardium Application Event API, and Then Switching the Application User to kzuse

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


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

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

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

Рисунок 13. Сеанс работы с базой данных Oracle с границами между пользователями приложения, определяемыми при помощи вызова хранимой процедуры set_application_property
Figure 13 shows an example of an Oracle database session displayed in Guardium. User boundaries are defined using a call to the set_application_property stored procedure

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

Рисунок 14. Выходные данные Guardium при конфигурировании продукта для идентификации хранимой процедуры в качестве границы между пользователями приложения
Guardium populating an application user field after having identified a call to set_application_property as a switch in a user

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

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

Рисунок 15. Окно конфигурирования хранимых процедур Guardium
Figure 15 shows the parameters required to configure Guardium in this case. Identifying set_application_property as the stored procedure, and adding a condition that the first parameter must be 'user_name'. The position of the actual username is also specified

Данный способ идентификации пользователей приложения идеален для тех приложений, где часто используются хранимые процедуры или где границы между пользователями задаются при помощи вызова хранимых процедур. Также существуют приложения, которые недостаточно гибки для вызова пустых операторов выбора с целью использования 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.

Рисунок 16. Экран входа в систему для приложения Plants by Websphere
Login Screen for the Plants By Websphere Application

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

Рисунок 17. HTTP-трафик для входа в систему
HTTP traffic for Login

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

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

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

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

Рисунок 18. Консоль администрирования Guardium
The Guardium Administration Console

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

Рисунок 19. Конфигурация S-TAP сервера приложений
S-TAP configuration for Application Server S-TAP

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

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

Рисунок 20. Отчет S-TAP сервера приложений
Application Server S-TAP Report

После конфигурирования идентификации пользователей сервера приложений 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, конфигурирование не требуется.

Рисунок 21. Отображение вызова setClientInfo в Guardium
The setClientInfo calls in DB2 translate to SET CLIENT USERID calls in Guardium

Вторым примером является организация пула соединений 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.

Рисунок 22. Отображение переключения пользователей с использованием доверенных контекстов в Guardium
Trusted Context look like special CONNECT statements to Guardium. Guardium picks this up and identifies the application user (which is also the database user at this point)

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

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

Пример с WebSphere

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

Рисунок 23. Ссылка на ресурс источника данных, сконфигурированная для использования доверенных контекстов в WebSphere
Figure 23 shows an example of how a data source resource reference that is configured to use trusted contexts in WebSphere

Вы также можете сконфигурировать 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, а также продемонстрировали возможный порядок реализации этих методов. Мы также обозначили ситуации, предусматривающие возможность использования каждого из этих методов.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=848012
ArticleTitle=Трансляция пользователей приложений с помощью продукта InfoSphere Guardium
publish-date=11302012