реклама
ЭКСПЕРТИЗА САЙТОВ НА СЛИВ ИНФОРМАЦИИ

ВОССТАНОВЛЕНИЕ ИНФОРМАЦИИ С РАЗЛИЧНЫХ НАКОПИТЕЛЕЙ В КИЕВЕ
уход за растениями - озеленение - фитодизайн
реклама

proxy  статьи  библиотека  softice  free_юр.консультация  hard  iptv
рекламодателям  фирмы/add  расшифровка штрих-кодов  links/add

http://kiev-security.org.ua

Содержание

103. Интеграция механизмов защиты ВС

7.6.6.  Интеграция  механизмов  защиты  ВС  Интеграция  различных
механизмов   защиты   ВС  может  быть  достигнута  при  следующих
условиях:  -  применение одного и того же механизма для различных
функций  защиты;  -  использование  единой  концепции  построения
информационной   базы   управления   защитой;   -   использование
унифицированных  управляющих  функций защиты (управления ключами,
управления  проверкой  и  т.д.); - формирование единых протоколов
взаимодействия  пользователей  и  механизмов защиты и компонентов
самого  механизма; - использование единой стратегии защиты ВС. Из
сказанного  выше  можно  сделать  вывод о том, что информационная
база  управления  защиты  SMIB  должна содержать следующие четыре
сегмента:  -  таблицу  параметров  защиты  пользователя  USER;  -
таблицу  защиты  передачи  сообщений  UST;  -  таблицу управления
расширенным  доступом  ЕАС;  -  таблицу  регтстрации LOG. Таблицы
USER,  EAC  и  LOG  - постоянные сегменты базы управления защитой
SMIB, которые хранятся во внешней памяти сетевых станций и узлов,
в  то  время  как  таблица  UST  - временный сегмент, создаваемый
только  в  том  случае,  если в данном узле присутствуют активные
пользователи ВС. Эти сегменты входят в базу данных распределенной
сети,  но  их  топологическая  организация до сих пор не писана в
литратуре.   Сегенты   USER,EAC   и   LOG  формируются  на  этапе
инсталляции  процедур  защиты  ВС. Их параметры инициализируются,
обновляются или удаляются в результате возникновения тех или иных
событий   в   ВС.  Параметры  сегента  USER  создаются  в  момент
регистрации   каждого   нового   легального   пользователя  сети,
обновляются при необходимости самим пользователем и уничтожаются,
когда  пользователь  отказывается  от  услуг данной ВС. Параметры
сегмента  ЕАС  создаются,  обновляются и удаляются при выполнении
команд   в   соответствии  со  стратеией  управления  расширенным
доступом.  Сегмент  LOG  инициализируется одновременно с открытым
ключом   менеджера  защиты  и  обновляется,  как  это  описано  в
предыдущем   разделе;   параметры  данного  сегмента  никогда  не
удаляются.  Сегмент  UST  используется  в динамическом режиме при
создании  новых  входов для каждого нового активного пользователя
ВС,  для  каждого  нового соединения. Первая часть входа содержит
параметры,  скопированные  из  сегмента USER. Остальные параметры
определяются   для   каждого   нового  соединения  в  момент  его
инициализации.  Все  описанные  действия  должны  быть поддержаны
специальным сетевым протоколом защиты, который содержит команды с
соответствующими  параметрами  защиты.  Первая попытка определить
некоторые  из этих команд была сделана в работе /BRAN87/, где они
были  названы  примитивамизащиты,  несмотря  на  их  ограниченные
возможности    и    ограниченную    область   применения.   Идеи,
рассмотренные  в  этой  работе, заслуживают внимания и могут быть
применены  к  широкому  кругу механизмов защиты сети и управления
защитой.  Формальное  описание  этих  примитивов  может оказаться
необходимым и полезным для: реализации интегрированного механизма
сетевой  защиты;  верификации  сетевых  функций;  оценки  функций
защиты; разборки согласующихся, совместимых между собой функций и
механизмов;   переноса  функций  на  различные  уровни  протокола
взаимодействия  открытых систем; проверки эффективности и полноты
интегрированного  механизма сетевой защиты. В заключение отметим,
что  мы использовали здесь список функций сетевой защиты из разд.
1.3. Для реализации каждой функции предложены некоторые механизмы
и  структуры  в  составе  информационной  базы управления защитой
SMIB.   Интеграция   отдельных   механизмов   достигается   путем
использования   компонентов   единой   базы  управления  защитой.
Дальнейшие   исследования   следует  проводить,  начав  с  оценки
описанных  механизмов  и  выбрав  наиболее  подходящие для данной
сети. Затем необходимо выявить общие функции управления защитой и
формально описать соответствующие механизмы и функции защиты. Эта
информация  послужит  основой  разработки  протоколов  защиты ВС.
Затем  должна  быть  выполнена  некоторая  формальная верификация
отдельных  механизмов  и  функций  защиты сети. Все перечисленные
этапы составляют теоретическую основу проектирования, реализации,
тестирования  и применения на практике конкретных сетевых средств
защиты,  которые должны предоставить пользователям ВС защищенные,
надежные и эффективные механизмы реализации сетевых операций.

Содержание

HOME


Если у вас есть сайт или домашняя страничка - поддержите пожайлуста наш ресурс, поставьте себе кнопочку, скопировав этот код:

<a href="http://kiev-security.org.ua" title="Самый большой объем в сети онлайн инф-ции по безопасности на rus" target="_blank"><img src="http://kiev-security.org.ua/88x31.gif" width="88" height="31" border="0" alt="security,безопасность,библиотека"></a>

Идея проекта(C)Anton Morozov, Kiev, Ukraine, 1999-2020, security2001@mail.ru