Контроль за работой пользователей приложения с базой данных с применением Guardium и WebSphere Application Server

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

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

Свен Гершель, сертифицированный технический специалист по продажам Guardium, IBM

Фото автораСвен Гершель (Sven Herschel), ИТ-специалист с девятилетним опытом работы, архитектор программного обеспечения и инженер по техническим требованиям с солидной подготовкой в области баз данных, Web-разработки и цифровых сертификатов, пришел в IBM в качестве технического специалиста по работе с клиентами InfoSphere Guardium. Он отвечает за весь цикл предпродажной подготовки, начиная с первого контакта и заканчивая демонстрацией работы продукта на месте. Благодаря этой работе он из первых рук получает требования заказчиков по безопасности базы данных и соблюдению нормативов.



Марк Швинд, инженер-программист, IBM

Марк Швинд (Marc Schwind) пришел в IBM два года назад и является разработчиком программного обеспечения в группе WebSphere Business Process Choreographer исследовательской лаборатории IBM в Boeblingen, Германия. Он закончил факультет информационных технологий в Штудгарте.



13.03.2013

Обзор

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

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

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

Постановка задачи

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

Рисунок 1. Типичная топология приложения, в которой на уровне базы данных информация о пользователе приложения теряется
Схема типичной 3-уровневой архитектуры приложения с доступом технического пользователя к базе данных. На уровне базы данных информация о пользователе приложения теряется.

Почему это важно?

Ряд нормативных актов, таких как PCI-DSS и SOX, содержит требования по управлению данными и может требовать наличия возможностей контроля за базой данных, позволяющих увидеть, к каким данным, когда и кем осуществлялся доступ. Кроме того, внутренние правила могут требовать контроля за привилегированными пользователями с целью защиты данных от несанкционированного доступа и повышения прозрачности работы администраторов БД.

В рамках сценария PCI-DSS мониторинг фокусируется на любом доступе к информации о кредитных картах. Чтобы контролировать доступ к информации о кредитных картах через приложения, которые используют объединенные в пул соединения, необходимо определить реального пользователя приложения, стоящего за техническим пользователем, подключившимся к базе данных. Когда доступ к данным и управление пользователями разделены, как описано выше, эта задача становится особенно сложной.


Подход, предлагаемый в этой статье

Обзор

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

В то же время эта передаваемая мета-информация игнорируется системой управления базами данных (СУБД), так что это не влияет ни на СУБД (включая операции БД, ее систему разрешений и схему проверки подлинности и авторизации), ни на WebSphere Application Server (включая его средства объединения соединений в пул), и они будут работать так же эффективно, как прежде. Более того, в самом приложении никаких изменений не потребуется, потому что этот подход не меняет работы приложения.

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

Необходимые условия

Чтобы этот подход работал, должны быть выполнены следующие предварительные условия.

  1. Приложение должно использовать пул соединений WebSphere, настроенный внутри WAS и предоставляемый приложению посредством JNDI-имени. Это гарантирует, что DataStoreHelper можно будет добавить без влияния на приложения.
  2. Приложение использует систему безопасности приложений WebSphere, потому что код опирается на пользователя приложения, статически извлекаемого из API класса com.ibm.websphere.security.auth.WSSubject.

Реализация

При настройке DataSource для использования с приложением WebSphere Application Server позволяет указать вспомогательный класс хранилища данных.

Этот класс устраняет разрыв между кодом, зависящим от поставщика базы данных, и универсальным интерфейсом javax.sql.DataSource. Обычно нет необходимости указывать этот специальный класс, так как WebSphere Application Server предоставляет вспомогательные классы хранилища данных по умолчанию для наиболее популярных баз данных.

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

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

Листинг 1. Передача имени пользователя приложения, выполнившего транзакцию
public void doConnectionSetupPerTransaction(Subject subject, String user,
                                            Connection conn, boolean reauth,
                                            Object properties) throws SQLException {

    StringBuffer sql = new StringBuffer();
    sql.append("SELECT 'GuardAppEvent:Start','GuardAppEventUserName:");
    sql.append(WSSubject.getCallerPrincipal());
    sql.append("' FROM SYSIBM.SYSDUMMY1");
    Statement stmt = conn.createStatement();
    stmt.execute(sql.toString());
}

На первый взгляд может показаться странным, что имя принципала извлекается из потока посредством статического вызова WSSubject, когда уже передан субъект и даже имя пользователя. Но если приглядеться, то это субъект, используемый уровнем J2C (субъект технического пользователя) для проверки подлинности в базе данных.

В большинстве случаев переданный пользователь ― это null. Он устанавливается только в тех случаях, когда приложение использует проверку подлинности на основе компонента, предоставляя имя пользователя и пароль напрямую, так что это опять будет технический пользователь.

Реализовав doConnectionCleanup(Connection conn), можно также информировать систему Guardium всякий раз, когда соединение, связанное с текущим пользователем, освобождается. Единственное различие заключается в том, что фиктивный SQL-оператор передает сообщение GuardAppEvent:Released вместо GuardAppEvent:Start, как показано в листинге 2.

Листинг 2. Передача имени текущего пользователя приложения после освобождения соединения
public boolean doConnectionCleanup(Connection conn) throws SQLException {

StringBuffer sql = new StringBuffer();
sql.append("SELECT 'GuardAppEvent:Released','GuardAppEventUserName:");
sql.append(WSSubject.getCallerPrincipal());
sql.append("' FROM SYSIBM.SYSDUMMY1");

Statement stmt = conn.createStatement();
stmt.execute(sql.toString());
return super.doConnectionCleanup(conn); 
}

Настройка

  1. Скомпилировав и упаковав DataStoreHepler, поместите JAR в папку /lib установки WAS.
  2. Войдите в административную консоль WAS.
  3. На странице конфигурации DataSource выберите Specify a user defined data store helper (Указать определяемое пользователем вспомогательное хранилище данных), а затем укажите весь пакет и classname своего класса DataStoreHelper, как показано на рисунке 2.
    Рисунок 2. Указание специального класса DataSourceHelper
    Технический пользователь с диалоговым окном DataSource config для указания специального класса DataSourceHelper
  4. Сохраните настройки и перезапустите WebSphere Application Server. Настройка вспомогательного хранилища данных окончена, и он готов к применению.

Результат

Для целей этой статьи конфигурация была протестирована путем открытия двух окон браузера и входа в приложение двух разных пользователей с именами marc и sven. Само приложение было подключено к базе данных через технического пользователя, так как подключение приложения к БД с помощью владельца экземпляра в большинстве сценариев, как правило, не рекомендуется. Затем приложение запрашивает конфиденциальную таблицу. Как видно из рисунка 3, все запросы приходят из одного и того же сеанса связи с базой данных (3719) с использованием одного и того же технического пользователя.

Рисунок 3. Журнал событий GuardiumActivity с указанием внешнего пользователя, обращавшегося с запросами к базе данных
Технический пользователь с типичной топологией, в которой для связи с базой данных применяется технический пользователь

Обратите также внимание на то, что внешний пользователь / пользователь приложения четко отмечен в столбце Event User Name (Имя пользователя события) и указаны операторы, которые он выполнил в течение своего сеанса (приложения). Цель достигнута.

Возможные расширения

В данном случае метаданные, которые передаются в базу данных, относятся к СУБД DB2, так как фиктивный оператор select обращен к SYSIBM.SYSDUMMY1. Для других СУБД этот оператор нужно адаптировать к фиктивной таблице соответствующей СУБД. Примеры приведены ниже.

  1. DB2: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insert username]' FROM SYSIBM.SYSDUMMY1
  2. Oracle: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insert username]' FROM DUAL
  3. MS-SQL: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insert username]'
  4. PostgreSQL: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insert username]'

Альтернативные решения

Можно использовать следующие альтернативные решения этой задачи.

  • Ведение журнала событий приложения.
  • Повторная проверка подлинности / доверительные контексты.
  • Регистрация событий и их сопоставление по меткам времени.

Ведение журнала событий приложения

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

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

Во-вторых, предоставление мониторинга операций с базой данных специализированному решению непосредственно на сервере баз данных имеет то дополнительное преимущество, что эти решения на базе агента будут контролировать также и доступ в обход приложения, например, с консоли через учетные записи привилегированных пользователей или через мосты JDBC или ODBC. Большинство нормативных актов требует всеобъемлющего решения аудита, которое контролирует 100% всех обращений к базе данных.

Повторная проверка подлинности и доверительный контекст

Современные СУБД поддерживают механизмы для установления фактического владельца соединения с базой данных. В случае DB2 разработчик может выбирать между повторной процедурой проверки подлинности соединения, которая обычно гораздо эффективнее, чем открытие нового соединения, и использованием так называемых доверительных контекстов (trusted contexts), таких как способность СУБД доверить (предыдущему) владельцу соединения проверку подлинности другого пользователя и подменить этого другого пользователя.

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

Регистрация событий и их сопоставление по меткам времени

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

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

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

Эти метаданные игнорируется базой данных и не влияют на СУБД и на объединение соединений с базой данных в пул на сервере приложений. Тем не менее, они контролируются системами мониторинга операций с базой данных, такими как InfoSphere Guardium Database Activity Monitor.


Заключение

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


Загрузка

ОписаниеИмяРазмер
Исходный код примеров для этой статьиSampleGuardiumDataStoreHelper.zip10 КБ

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

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=861335
ArticleTitle=Контроль за работой пользователей приложения с базой данных с применением Guardium и WebSphere Application Server
publish-date=03132013