Заключение

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

Основу реализации метода составляет выполнение следующих действий средствами подсистемы разграничения прав доступа.

•Выделить для каждого пользователя (или группы пользователей) каталоги, из которых разрешен запуск программ. Это требует от администратора СЗИ проводить установку пользовательских программ только в такие каталоги.

•Запретить всем пользователям операции записи в эти каталоги.

•Запретить запуск программ из всех каталогов, куда пользователю (или группе пользователей) разрешена запись.

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

Литература

1.Гостехкомиссия России. Руководящий документ "Средства вычислительной техники, Защита от несанкционированного доступа к информации, Показатели защищенности от несанкционированного доступа к информации".. Москва, 1992.

2.Рихтер. Windows для профессионалов. М.: MS Пресс, 1999.

101

РЕШЕНИЕ СПЕЦИФИЧЕСКИХ ЗАДАЧ АУДИТА БАЗЫ ДАННЫХ

Г.Ю. Громов, Д.А. Дорохин, В.С. Черемухин

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

Вопросы, связанные с аудитом базы данных, в СУБД Oracle решены давно и вполне успешно. В СУБД Oracle существует стандартный, довольно громоздкий, но при этом обладающий большими возможностями механизм сбора информации аудита базы данных. На любом уровне детализации можно отследить события, происходящие в базе данных, вплоть до конкретных запросов, выполняемых определенным пользователем. Однако использование средств аудита, помимо естественно возникающих накладных расходов, связанных с дополнительной загрузкой базы данных, вызывает и ряд административных сложностей. Обязательно должна быть тщательным образом разработана и отлажена стратегия аудита базы данных, которая должна предусматривать своевременную очистку системной таблицы SYS.AUD$, размещенную в табличном пространстве SYSTEM. Если не уделить этому вопросу должного внимания, постоянное изменение размера системной таблицы SYS.AUD$ может привести к фрагментации табличного пространства SYSTEM, что просто недопустимо, так как избавиться от него можно только пересозданием базы данных. Наилучшим решением этой проблемы было бы перемещение системной таблицы SYS.AUD$ в другое табличное пространство, однако Oracle официально заявляет о непредсказуемых последствиях данного шага.

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

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

Вотличии от "классических" триггеров базы данных, срабатывающих в случае выполнения операций INSERT, UPDATE, DELETE, триггера событий срабатывают при возникновении как-либо системных событий, среди которых SERVERERROR, AFTER LOGON, BEFORE LOGOFF, AFTER/ BEFORE ALTER/CREATE/DROP, AFTER/ BEFORE GRANT/REVOKE и так далее. По сути, данный тип триггеров позволяет, помимо сбора информации аудита, выполнять набор необходимых действий, связанных

стем или иным системным событием. Триггера событий могут создаваться на двух уровнях – на уровне базы данных и на уровне конкретной схемы. Также только в триггерах событий доступен набор атрибутов этих событий, например, стек ошибок (ora_server_error) для события SERVERERROR или ip-адрес компьютера пользователя

(ora_client_ip_address) для события AFTER LOGON.

Вкачестве простейшего примера можно привести два триггера, выполняющих сбор информации аудита в созданную администратором базы данных таблицу. Таблица создается не в табличном пространстве SYSTEM, и помимо информации, которую можно собрать стандартными средствами (время начала и окончания работы с базой данных), в нее заносится информация о том, какая программа используется пользователем для работы, и ip-адрес компьютера, с которого он работает.

DROP TABLE adm_connections;

CREATE TABLE adm_connections

102

( s_id NUMBER ,

TABLESPACE tools;

CREATE OR REPLACE TRIGGER OnLogon AFTER LOGON ON DATABASE DECLARE

-- описываем служебную переменную pr VARCHAR2(64);

BEGIN

BEGIN

-- выбираем из представления v$session информацию о программе пользователя

SELECT program INTO pr FROM sys.v_$session t where audsid = sys_context('USERENV','SESSIONID');

EXCEPTION

WHEN NO_DATA_FOUND THEN NULL; END;

-- вставляем всю необходимую информацию в нашу таблицу

INSERT INTO adm_connections(s_id,user_name,host_ip,progr) VALUES (sys_context('USERENV','SESSIONID'), ora_login_user,

ora_client_ip_address, pr); END;

CREATE OR REPLACE TRIGGER OnLogoff BEFORE LOGOFF ON DATABASE BEGIN

-- обновляем нашу таблицу сведениями об окончании работы с базой данных данного пользователя

UPDATE adm_connections SET end_date = sysdate WHERE s_id = sys_context('USERENV','SESSIONID');

END;

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

CREATE OR REPLACE TRIGGER OnError AFTER SERVERERROR ON DATABASE

BEGIN

INSERT INTO adm_errors(user_name,host_ip, error_nom)

VALUES (ora_login_user, SYS_CONTEXT('USERENV','IP_ADDRESS'), SYS_CONTEXT('USERENV','CLIENT_INFO'), 'ORA- '||TO_CHAR(ora_server_error(1),'00000'));

END;

103

ПРОБЛЕМА ИНТЕГРАЦИИ ЛОКАЛЬНЫХ АВТОМАТИЗИРОВАННЫХ СИСТЕМ УПРАВЛЕНИЯ В ОБРАЗОВАТЕЛЬНОЙ СФЕРЕ ДЕЯТЕЛЬНОСТИ

Г.Ю. Громов, Д.А. Дорохин, В.В. Кириллов, В.С. Черемухин

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

Сегодня во многих российских вузах существуют разработанные и (или) приобретенные информационные системы и подсистемы оперативной обработки данных, реализованные на самой различной аппаратной и программной основе. Это и автономные файловые системы, и системы, использующие локальные или сетевые версии персональных систем управления базами данных (СУБД), и системы, построенные на серверах реляционных баз данных. Однако все они создавались для автоматизации деятельности сотрудников отдельных подразделений, и поэтому им трудно (а часто и невозможно) обмениваться данными, трудно выдать непредусмотренную справку, трудно "узнать", существуют ли в соседних системах данные, затребованные кем-либо из руководства вуза. Естественно, что такие данные часто противоречивы, и руководство университета не может получить полной и достоверной информации на многие актуальные вопросы [1].

Вотнесколькопримеровпротиворечивости:

•один и тот же сотрудник существует какое-то время под разными табельными номерами и оформлен в разных подразделениях;

•встречаются случаи назначения на стипендию неуспевающих студентов;

•не совпадают сведения о численности студентов и преподавателей, поступающие из подсистем отдела кадров, учебной части, деканатов, кафедр.

Непрерывно нарастающее число подобных противоречий в существующих

системах и явилось основным побудительным моментом необходимости их замены. Аналогичная проблема возникает и при разработке автоматизированных систем

управления (АСУ) министерства образования РФ или небольших автономных АСУ филиала университета, факультета, кафедры, секции, а также любого подразделения образовательного характера.

На разных уровнях управления эти локальные АСУ имеют неодинаковый характер и преследуют различные цели. Однако в них необходимо хранить частично пересекающуюся информацию (например, кафедры, факультеты и университет хранят в своих АСУ общие сведения об одних и тех же студентах и преподавателях). Как было отмечено выше, такое дублирование данных, как правило, приводит к появлению противоречивых сведений, не позволяющих получать достоверную информацию.

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

итерриториально разделенных систем затруднено из-за большого объема информации

иудаленного доступа (нереально объединение АСУ министерства с АСУ входящих в него образовательных учреждений).

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

Одним из решений этой задачи является выявление общих данных для различных уровней управления и интегрирование их (при исключении дублирования) в базах данных более высокого уровня. При этом частные данные размещаются (без дублирования) на более низких уровнях. Например, в университетской системе интегрируются сведения о бухгалтерской, хозяйственной, учебной деятельности

105

университета, санкционированную часть этой информации (сведения о сотрудниках, студентах, подразделениях и т.д.) могут использовать кафедры. В свою очередь АСУ университета может использовать информацию, предоставляемую кафедрами (списки трудов сотрудников, научные разработки, участие в конференциях, сведения о выпускниках, сведения о НИР, публикации и т.д.).

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

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

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

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

Литература

1.Васильев В.Н. Принципы создания интегрированной информационноаналитической системы управления вузом // Тезисы докладов Международной конференции "Интернет, Общество, Личность - ИОЛ-2000" Институт "Открытое общество", Санкт-Петербург, 2000.

2.Кириллов В.В., Громов Г.Ю. Применение CASE-технологии при создании интегрированной информационной системы университета // Доклад на Юбилейной научно-технической конференции профессорско-преподавательского состава, посвященная 100-летию университета 29-31 марта 2000 года, Санкт-Петербург, 2000.

3.Кириллов В.В., Громов Г.Ю. Штивельман Я.Е., Первый опыт проектирования несколькими вузами подсистемы "Учебный процесс" // Тезисы докладов Международной конференции "Интернет, Общество, Личность - ИОЛ-2000" Институт "Открытое общество", Санкт-Петербург, 2000.

4.Кириллов В.В., Громов Г.Ю., Черемухин В.С., Вотинцев А.А., Романенко В.А. Работа с одним репозиторием Oracle Designer территориально распределенных разработчиков // Тезисы докладов Международной научно-методической конференции "Телематика'2000", Санкт-Петербург, 2000.

106