Контексты приложений
Использование идентификатора клиента имеет свои преимущества, но также и представляет серьезную угрозу безопасности: эта установка предполагает, что пользователь установит в идентификаторе значение реального идентификатора пользователя, но этого нельзя гарантировать. Злонамеренный пользователь может соединиться с базой данных и установить значение другого идентификатора пользователя, что серьезно подрывает достоверность журнала аудита. В веб-приложениях использование "куков" для хранения идентификаторов клиентов делает эту задачу трудной, если не невозможной; но в обычных приложениях использование только клиентских идентификаторов не обеспечивает удовлетворительной защиты. Нам требуется более безопасное средство фиксации пользователей приложения в журнале аудита.
Предложим решение: контексты приложений (application contexts). Контексты приложений похожи на атрибуты сеанса: после установки к ним можно обращаться в сеансе в любое время. В другом сеансе может быть установлено другое значение, но эти значения не будут видны в других сеансах. Контекст имеет атрибуты, подобные столбцам таблицы; но, в отличие от таблиц, контексты – не объекты сегментов, и атрибуты могут быть определены во время выполнения, а не во время проектирования.
Контекст приложения может быть создан следующим SQL-оператором:
create context my_app_ctx using set_my_app_ctx;
Обратите внимание на предложение using set_my_app_ctx, указывающее, что атрибутами внутри контекста можно манипулировать только с помощью процедуры с именем set_my_app_ctx, определяемой следующим образом: create or replace procedure set_my_app_ctx ( p_app_user in varchar2 := USER ) is begin dbms_session.set_context('MY_APP_CTX','APP_USERID', p_app_user); end;
Эта процедура просто устанавливает в атрибуте APP_USERID значение, передаваемое в ее входном параметре, вызывая для этой установки процедуру dbms_session.set_context. Что случится, если пользователь непосредственно вызовет процедуру dbms_session.set_context? SQL> exec dbms_session.set_context('MY_APP_CTX','APP_USERID', 'JUNE') BEGIN dbms_session.set_context('MY_APP_CTX','APP_USERID', 'JUNE'); END; * ERROR at line 1: ORA-01031: insufficient privileges ORA-06512: at "SYS.DBMS_SESSION", line 78 ORA-06512: at line 1
Обратите внимание на ошибку ORA-01031:insufficient privileges (недостаточные привилегии), которая в данное время немного вводит в заблуждение. Пользователь не имеет привилегии выполнения процедуры SYS.DBMS_SESSION, установка атрибута контекста вызовом этой процедуры запрещена, поэтому возникает ошибка. Однако когда пользователь для установки атрибута вызовет доверенную процедуру: SQL> execute set_my_app_ctx ('AAAA') PL/SQL procedure successfully completed.
…она выполнится успешно. Атрибуты контекста могут устанавливаться только с помощью этой процедуры, поэтому она и называется соответствующим образом – доверенная процедура (trusted procedure). Это важное свойство контекста приложения, и оно может использоваться в FGA.
Атрибут контекста, если установлен (в приведенном выше коде), может быть извлечен вызовом функции SYS_CONTEXT:
select sys_context('MY_APP_CTX','APP_USERID') from dual;
Этот оператор возвращает значение атрибута. Если контекст может быть установлен безопасным способом, его можно использовать для установки идентификатора клиента.
Исходя из наших знаний, возможное решение может выглядеть следующим образом:
- приложение выполняет процедуру, которая автоматически устанавливает правильное значение в контексте приложения. В вышеупомянутом примере атрибут контекста использовался для установки идентификатора пользователя, но можно также использовать и другой атрибут, такой, как роль пользователя. В контексте вы можете определять более одного атрибута. Атрибут может использоваться как включаемая роль. В доверенную процедуру можно включить все типы проверок безопасности, обеспечивая защиту и аутентичность. Если эти проверки безопасности будут неудачными, требуемая роль не будет включена. Так, даже если пользователь может успешно соединиться с базой данных, используя учетную запись APPUSER, он будет не в состоянии манипулировать данными, так как соответствующая роль не будет включена. Обратите внимание: роли должны быть ролями, аутентифицируемыми процедурой, а не обычными. Такие роли создаются оператором CREATE ROLE <имя_роли> USING <имя_процедуры>; и пользователь включает роль, вызывая <имя_процедуры>, а не оператором SET ROLE;
- эта процедура также устанавливает идентификатор клиента, так что нет никакой потребности предоставлять привилегии выполнения пакета dbms_session всем пользователям (public), они не нужны даже данному пользователю. Поскольку пользователи не имеют привилегий вызова процедур пакета dbms_session, они не могут непосредственно устанавливать идентификаторы клиентов – те будут устанавливаться и переноситься в журнал детального аудита автоматически.
Этот метод может быть в дальнейшем усовершенствован за счет использования определяемых пользователем записей аудита, в которых в идентификаторах клиентов могут устанавливаться значения, извлекаемые из контекста приложения. Мы обсудим данный метод в третьей (и последней) части этой серии статей.
