Студопедия КАТЕГОРИИ: АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Практическая реализация механизмов добавочной защиты
Механизм управления доступом к ресурсам (диспетчер доступа) должен выполняться в виде системного драйвера и функционально располагаться между приложением и ядром ОС. Это вызвано следующим. На уровне приложения невозможно осуществить разграничительную политику доступа в принципе. Реализация диспетчера на уровне ядра, во-первых, практически невозможна для коммерческих систем, а во-вторых, может быть связана с нарушением лицензионных соглашений разработчика. Любой запрос на доступ к ресурсам от приложения к ядру перехватывается диспетчером доступа и анализируется в соответствии с заданными правами доступа к объектам от субъектов. В случае противоречия запрашиваемого доступа разграничительной политике, он отвергается диспетчером, в противном случае доступ к ресурсу разрешается — транслируется в ядро ОС. При наличии в системе встроенного диспетчера доступа механизм добавочной защиты должен располагаться перед ним и первым анализировать запрос. Т.е. обработка запроса на доступ к ресурсам в этом случае должна осуществляться по схеме, приведенной на рис. 1.
Особенностью реализации механизма управления доступом (диспетчера доступа) к ресурсам добавочной защиты является то, что он полностью должен быть развязан с соответствующим механизмом встроенной защиты. В противном случае настройки механизма добавочной защиты могут быть изменены средствами настройки встроенного механизма защиты. Остается единственный способ хранения прав доступа к ресурсам матрицы доступа. Этот способ предусматривает хранение прав доступа в файле (либо в реестре), доступ к которому также соответствующим образом разграничивается. Реализация данного подхода позволяет строить диспетчер доступа с едиными принципами построения для различных типов файловых систем и для различных видов ресурсов. Принципиальным отличием хранения матрицы доступа в файле является то, что на производительности системы сказывается величина таблицы прав разграничения доступа, анализируемой при каждом доступе к ресурсам. Бороться с потерями производительности системы от введения средств добавочной защиты можно следующими путями: ≫ путем уменьшения списка правил разграничения доступа; ≫ путем уменьшением времени проверки одного запроса; ≫ сразу обоими методами. Метод уровневого контроля списков санкционированных событий В качестве возможного способа противодействия ошибкам и закладкам в системном и прикладном ПО, а также контроля (мониторинга) корректности функционирования механизмов, реализующих разграничительную политику доступа к ресурсам защищаемого объекта, рассмотрим метод уровневого контроля списков санкционированных событий (МУКССС). Контроль корректности должен реализовывать как контроль функционирования самой системы зашиты, так и контроль за действиями пользователей. Контроль за действиями пользователей В общем случае получение пользователем доступа к ресурсу можно представить набором некоторых событий. Например, какой пользователь обращается к ресурсу, какой процесс запущен пользователем, к какому ресурсу обращается пользователь и т.д. Таким образом, доступ пользователя к ресурсу представляет собой некоторую последовательность действий, каждое из которых может быть охарактеризовано соответствующим списком санкционированных (разрешенных), либо несанкционированных (запрещенных) событий. Такими списками могут быть: * список зарегистрированных в системе пользователей; * список разрешенных к запуску процессов; * список запрещенных событий в системе; * список ключей реестра ОС. разрешенных для изменения; * список устройств, к которым разрешен доступ пользователям, и т.д. Таким образом, контролируя текущие события системы в соответствии со списками разрешенных событий (списками санкционированных событий), можно контролировать корректность работы пользователя в системе. При этом в случае выполнения пользователем несанкционированных действий будет вырабатываться соответствующая реакция системы защиты: завершение несанкционированного процесса, завершение сеанса несанкционированного пользователя в системе и т.п. Отличительной особенностью рассматриваемого подхода является то, что в принципе неважно, каким образом злоумышленник пытается осуществить несанкционированный доступ к информации, т.к. фиксируются не конкретные описания, а косвенные признаки атаки — несанкционированные для системы события. Принципиально важным является то, что рассматриваемый подход позволяет противодействовать скрытым угрозам, а также использованию злоумышленником ошибок и закладок в системном, функциональном и прикладном программном обеспечении без необходимости выявления последних. |
||
Последнее изменение этой страницы: 2018-04-12; просмотров: 446. stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда... |