Студопедия

КАТЕГОРИИ:

АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Практическая реализация механизмов добавочной защиты




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

 

 

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

Бороться с потерями производительности системы от введения средств добавочной защиты можно следующими путями:

≫ путем уменьшения списка правил разграничения доступа;

≫ путем уменьшением времени проверки одного запроса;

≫ сразу обоими методами.



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

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

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

Контроль за действиями пользователей

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

* список зарегистрированных в системе пользователей;

* список разрешенных к запуску процессов;

* список запрещенных событий в системе;

* список ключей реестра ОС. разрешенных для изменения;

* список устройств, к которым разрешен доступ пользователям, и т.д.

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

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










Последнее изменение этой страницы: 2018-04-12; просмотров: 446.

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