Проблема пользователей приложения
В предшествующей статье объяснялось, как настроить FGA, чтобы записать в таблицу FGA_LOG$ данные о пользователях базы данных, которые выполняли запросы. Этот подход работает хорошо в тех случаях, когда пользователь базы данных соответствует одному-единственному физическому пользователю. Однако в некоторых случаях, например, с веб-приложениями, сервер приложений соединяется с базой данных, используя неизменный пользовательский идентификатор, скажем, APPUSER. Пользователи приложения аутентифицируются приложением. Например, пользователь SCOTT соединяется с приложением, которое аутентифицирует его, а затем оно соединяется с базой данных, используя идентификатор пользователя APPUSER. Если средства FGA будут использоваться в такой среде, то они будут показывать пользователя APPUSER, а не SCOTT. Точно так же и другой пользователь приложения JANE, выбирающий данные, будет также регистрироваться как пользователь APPUSER, а не JANE. Поскольку зарегистрированное в журнале аудита имя пользователя не является именем фактического пользователя, цели аудита не будут достигнуты.
Первое решение, которое приходит на ум, состоит в том, чтобы создать пользователей приложений в базе данных, позволяя приложению соединяться с базой данных, используя те же идентификаторы пользователей и пароли. Скажем, в вышеприведенном примере пользователи SCOTT и JANE будут пользователями базы данных и не будет никакой потребности иметь пользователя по имени APPUSER. Этот подход прост и безопасен, поскольку пользователь аутентифицируется сервером базы данных, и имя пользователя остается тем же самым независимо от способа подключения.
При таком подходе, однако, все пользователи должны быть созданы в базе данных, что приведет к кошмару администрирования, особенно когда число пользователей достигнет нескольких тысяч, что является обычным в веб-приложениях. Кроме того, пользователи должны запоминать свои имена пользователей и пароли в различных местах; неудобство, которое полностью оправдает существование опции однократной регистрации (SSO, Single Sign-On). Хотя эта проблема может быть решена при использовании опции расширенной безопасности (ASO, Oracle Advanced Security Option), также известной как расширенная сетевая опция (ANO, Advanced Networking Option) наряду с использованием интернет-каталога Oracle (OID, Oracle Internet Directory), для большинства сайтов это решение не подходит.
В веб-приложениях в концепции пула соединений (connection pooling) также требуется использование одного универсального идентификатора пользователя. Как показано на следующем рисунке, сервер приложений создает несколько соединений с базой данных, используя пользователя APPUSER. Когда пользователю приложения, такому, как SCOTT, требуется обслуживание, относящееся к базе данных, приложение для выполнения запроса использует одно из этих соединений с базой данных. Эта модель может поддерживать много пользователей, используя только несколько соединений и, следовательно, находит поддержку у архитекторов веб-приложений. Но снова этот подход не позволяет FGA записать правильное имя пользователя.
Надписи на рисунке:
- Web Sessions – веб-сеансы;
- Connection Pool – пул соединений;
- Database Sessions – сеансы базы данных.
Аргументы в пользу универсальных идентификаторов пользователей приложений очень сильны. Таким образом, предпочтительнее не пытаться "избавиться" от этого требования, идеальное решение состоит в том, чтобы использовать в среде FGA идентификаторы пользователей приложений.
