На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

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

Система защиты должна осуществлять регистрацию основных событий при функционировании защищаемого объекта.
В рамках построения иерархической системы защиты, как следствие, может строиться иерархическая система аудита, содержащая следующие уровни иерархии.
Первый уровень иерархии аудита — регистрация событий уровней защи­ты, реализующих разграничительную политику доступа к ресурсам. В рамках данной функции аудита решаются следующие задачи:
* ведется аудит всех событий, связанных с действиями пользователей по доступу к ресурсам защищаемой системы (вход в систему, запрос и получение доступа к защищаемым ресурсам и т.д.);
« ведется аудит событий, связанных с действиями администратора бе­зопасности по созданию и переназначению прав доступа пользовате­лей к ресурсам защищаемой системы (создание и уничтожение субъек­тов и объектов доступа, действий по переназначению прав разграничения доступа и т.д.).
Второй уровень иерархии аудита — регистрация событий, относящихся к контролю корректности функционирования механизмов защиты, ре­ализующих разграничительную политику доступа к ресурсам. Данный контроль ведется механизмами уровневого контроля списков санкцио­нированных событий.
Принципиальным отличием в регистрации событий для рассмотренных уровней иерархии аудита является то, что на первом уровне иерархии фиксируются все события, связанные с доступом к защищаемым ресур­сам (ведутся журналы регистрации). Что касается второго уровня, то на нем регистрируются только ошибки (ведутся журналы ошибок) и факты некорректности срабатывания механизмов защиты, реализующих разгра­ничительную политику доступа к ресурсам, а также факты НСД.
Реализация иерархической модели аудита позволяет ввести в системе за­щиты различные схемы обработки журналов, в частности при удаленном управлении системой защиты - ее клиентской частью и с сервера безо­пасности. При этом регистрационная информация первого уровня аудита сохраняется в соответствующих файлах клиентской части системы защи­ты и могут быть переданы на сервер безопасности по запросу админист­ратора безопасности (затем соответствующим образом им обработаны с
применением фильтров, входящих в состав системы защиты).
302
Глава       Метод уровневого контроля списков санкционированных событий
Регистрационная информация второго уровня аудита в реальном времени выдается клиентской частью системы защиты на сервер безопасности и ото­бражается в специальном окне интерфейса сервера — в окне сервера оши­бок. Кроме того, на каждый тип ошибки администратор безопасности может задать реакцию, как на клиентской части системы защиты, так и
на сервере безопасности.
Таким образом, использование механизма уровневого контроля позволяет выделить два уровня аудита, для которых принципиально различаются ре­жимы обработки запросов (оперативная обработка и обработка в реаль­ном времени). Это, с одной стороны, позволяет существенно повысить
оперативность обработки критичных событий, обеспечивая реакцию на
критичные события в реальном масштабе времени. С другой стороны это позволяет существенно снизить нагрузку на трафик. И действительно, в реальном времени по сети на сервер безопасности передаются только данные второго уровня аудита, т.е. нагрузка на сетевой трафик подсис­темой аудита сводится к минимуму. При этом отметим, что в штатном режиме функционирования сетевой системы защиты именно интенсив­ность и объемы передачи данных аудита определяют дополнительную нагрузку, генерируемую системой защиты на сетевой ресурс.
Разработка и оптимизация механизма уровневого контроля, как механизма реального времени
Задача оптимизации механизма уровневого контроля в рамках вычислительной системы
Очевидно, что как любая синхронная процедура (синхронно — то есть по расписанию) рассматриваемый метод защиты информации потенциально может оказывать весьма существенное влияние на производительность за­щищаемого объекта. Особенно это может сказываться при жестких вре­менных ограничениях на время автоматической реакции на обнаруживае­мое несанкционированное событие (система реального времени).
Уже на основе описания метода можно предположить, что потребуется решать оптимизационные задачи с целью снижения влияния рассматри­ваемого подхода на производительность системы.
Так как исследования будут проводиться для систем реального времени (или реального масштаба времени — РМВ), прежде всего рассмотрим основные принципы построения и синтеза подобных систем в общем случае.
Теоретические основы обслуживания заявок в вычислительных системах в реальном времени (по расписаниям)
Общая модель системы реального времени (в общем виде)
Общая модель и условие обслуживания заявки в реальном времени
Рассмотрим модель системы реального времени в общем случае, то есть для распределенных вычислительных систем (ВС). Соответственно, в ча­стном случае, когда необходимо решать задачу в рамках сосредоточен­ной вычислительной системы (в рамках одного защищаемого компьюте­ра), соответствующие параметры, используемые в модели, могут быть опущены.
Так как основными требованиями к качеству построения и функциони­рования ВС реального времени является выполнение временных ограни­чений в обслуживании заявок, то распределенную ВС реального времени можно описать детерминированной моделью. Эта модель характеризуется не вероятностными, а граничными значениями параметров.
К временным параметрам обслуживании заявок относятся величины:
.....продолжительность занятия ресурса т-м абонентом,
т = \,...,М для информационного взаимодействия с ним; .... продолжительность передачи прав w-mv абоненту после ос­вобождения ресурса в системе; КНт).. коэффициент частоты занятия ресурса 1-й абонентом /= 1,...,^/относительно т-го (/ ф т).
Качество обслуживания заявок можно описать характеристиками:
.....продолжительность арбитража требования абонента (с
момента появления заявки до момента предоставления або­ненту права занять ресурс) или, соответственно, продолжи­тельность ожидания заявкой обслуживания;
.....продолжительность обслуживания заявки системой.
Для систем реального времени интерес представляют граничные (худшие для любой заявки) значения рассмотренных характеристик, которые со­ответственно обозначим: 7' , Тг„„ , КгИт), Тш , Тго , i,m = \...,М, i * m,
откуда получаем параметры обслуживания заявок в системе реального вре­мени: TV, , 7Л„ .
305
Часть V.   Контроль корректности функционирования механизмов защиты
С учетом сказанного получаем модель системы реального времени в об­щем виде:
Таким образом, обслуживание заявки в реальном масштабе времени кор­ректно, если для любого абонента системы m (m = выполняются условия (18.1). Если условие (18.1) хотя бы для одного абонента систе­мы не выполняется, то нельзя считать, что его заявки обслуживаются в реальном масштабе времени. В этом случае параметры обслуживания Та„ и Т0^ не могут быть ограничены сверху, и, следовательно, всегда най­дутся условия функционирования системы, при которых Тгат <Тат, Тго„, < Т0,„  или заявка будет обслужена не в реальном времени.
Понятие «цикл расписания»
Условие (18.1) выполняется только в том случае, если в системе реали­зуется дисциплина обслуживания заявок по расписаниям, т.к. любая иная
дисциплина обеспечивает выполнение данных условий с некоторой ве­роятностью (без учета эксплуатационных характеристик), что для рассмат­риваемого случая недопустимо.
Расписание будем характеризовать его циклом — повторяющейся очеред­ностью передачи прав на занятие ресурса. Цикл расписания будем зада­вать в круглых скобках. Например, цикл (1, 2, 3, 4) означает следующую циклическую последовательность передачи прав на занятие ресурса: пер­вому абоненту, затем второму, затем третьему, затем четвертому.
Приоритетное и бесприоритетное обслуживание в реальном времени
Особенностью обслуживания заявок в реальном времени будет то, что каждая заявка гарантированно должна быть обслужена за время Т№т. Исходя из этого, в данном случае приоритет заявки нельзя трактовать,
как преимущественное право одной заявки перед другой быть обслужен­ной (как, например, в случаях относительных и абсолютных приорите­тов). Все заявки должны быть обслужены. При этом приоритеты заявок здесь представляют собой отношение гарантированных продолжительно-стей их обслуживания: Т„я.
Будем говорить, что в системе реализована бесприоритетная дисциплина обслуживания требований общего ресурса реального времени, если для всех абонентов совпадают значения параметра Т„я. Соответственно, при-
оритетная дисциплина обслуживания требований общего ресурса реально­го времени имеет место, если хотя бы для двух любых абонентов не со­впадают значения параметра Тга^.
В качестве параметра приоритетности обслуживания заявок в реальном времени может быть введена количественная оценка — относительный уровень приоритетности реального времени (или относительный приори­тет реального времени) двух абонентов m и nf; m,m'=l,...,M.
Под относительным уровнем приоритетности реального времени (или от­носительным приоритетом реального времени) двух абонентов mum'; m,m'=l,...,M понимается отношение 8m~m> = Т^/Т^.
Соответственно, в системе реализована бесприоритетная дисциплина об­служивания требований ресурса, если для любых двух абонентов систе­мы т, т' выполняется: <5m_m. =1(/п*/и');если Sm_m. <1 приоритет m або­нента в <5m_m. выше, в противном случае — приоритет в Sm_m. ниже.
Способы задания приоритетного обслуживания
Системой (18.1) в общем случае определяются три способа задания при­оритетного обслуживания заявок в реальном времени для распределен­ных ВС и, соответственно, их комбинации:
1. Изменением параметров Кгцт) - именно этот параметр может изменяться при изменении цикла расписания (например, (1, 2, 3, 4) и (1, 2, 1, 3, 1, 4)).
2. Изменением параметров ТгпПт.
3. Изменением параметров ТгРт.
При этом очевидно, что выбор способов задания приоритетов абонентов определяется соотношением параметров Т9т и Тгпп. . При ТгРт»Тгпп^ целесообразно использовать способы 1 и 3 (это рассматриваемый нами далее случай сосредоточенной системы - в рамках одного компьютера), а при сопоставимости ТгРт и Тгпп^   - соответственно, способы 1 и 2.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика