"Оранжевая книга" Министерства обороны США и Руководящие документы Гостеккомиссии при Президенте РФ создавались в расчете на централизованные конфигурации, основу которых составляют большие машины. Распределенная организация современных информационных систем требует внесения существенных изменений и дополнений как в политику безопасности, так и в способы проведения ее в жизнь. Для противодействия новым угрозам безопасности нужны и новые функции и механизмы защиты. Продолжая начатое в предыдущих номерах журнала [1,2] изложение по основам информационной безопасности остановимся сегодня на особенностях безопасной работы с компьютерными сетями. Основополагающим документом в области защиты распределенных систем стали Рекомендации Х.800 [3]. В данном разделе мы рассмотрим эту работу, а также интерпретацию "Критериев" Министерства обороны США для сетевых конфигураций [4].
Рекомендации X.800
Рекомендации Х.800 - документ довольно обширный, поэтому сосредоточим внимание только на специфических сетевых функциях или сервисах безопасности и на необходимых для их реализации защитных механизмах. Одновременно имеет смысл познакомится с основными понятиями данной области информационной безопасности.
Чтобы почувствовать специфику распределенных систем, достаточно рассмотреть такое стандартное средство защиты, как подотчетность. Помимо других целей, записи в регистрационном журнале могут служить доказательством того, что определенный пользователь совершил то или иное действие (точнее, действие было совершено от его имени). В результате пользователь не может отказаться от содеянного и в некоторых случаях несет за это наказание. В распределенных системах действие порой совершается на нескольких компьютерах, и, вообще говоря, не исключено, что их регистрационные журналы противоречат друг другу. Так бывает, когда злоумышленнику удается подделать сетевой адрес и имя другого пользователя - значит, нужны иные средства обеспечения "неотказуемости" (невозможности отказаться) от совершенных действий.
Функции безопасности
Перечислим функции безопасности, характерные для распределенных систем, и роли, которые они могут играть.
Аутентификация. Данная функция обеспечивает аутентификацию партнеров по общению и аутентификацию источника данных.
Аутентификация партнеров по общению используется при установлении соединения или иногда периодически во время сеанса. Она служит для предотвращения таких угроз, как маскарад и повтор предыдущего сеанса связи.
Аутентификация источника данных - это подтверждение подлинности источника отдельной порции данных. Функция не обеспечивает защиты против повторной передачи данных.
Управление доступом. Управление доступом обеспечивает защиту от несанкционированного использования ресурсов, доступных по сети.
Конфиденциальность данных. Данная функция обеспечивает защиту от несанкционированного получения информации. Различают следующие виды конфиденциальности:
- конфиденциальность данных при общении с установлением соединения (в этом и следующем случаях защищаются вся пользовательская информация);
- конфиденциальность данных при общении без установления соединения;
- конфиденциальность отдельных полей данных (избирательная конфиденциальность);
- конфиденциальность трафика (защита информации, которую можно получить, анализируя трафик).
Целостность данных. Данная функция подразделяется на подвиды в зависимости от того, какой тип общения используют партнеры - с установлением соединения или без такового, защищаются ли все данные или только отдельные поля, обеспечивается ли восстановление в случае нарушения целостности.
Неотказуемость. Данная функция невозможности отказаться от совершенных действий обеспечивает два вида услуг:
- неотказуемость с подтверждением подлинности источника данных;
- неотказуемость с подтверждением доставки.
Побочным продуктом неотказуемости является аутентификация источника данных.
В таблице 1 указаны уровни эталонной семиуровневой модели OSI, на которых могут быть реализованы функции безопасности. Отметим, что прикладные процессы в принципе могут взять на себя поддержку всех защитных сервисов.
Таблица 1.
Распределение функций безопасности по уровням эталонной семиуровневой модели OSI.- Функции безопасности
- Уровень
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- Аутентификация
- -
- -
- +
- +
- -
- -
- +
- Управление доступом
- -
- -
- +
- +
- -
- -
- +
- Конфиденциальность соединения
- +
- +
- +
- +
- -
- +
- +
- Конфиденциальность вне соединений
- -
- +
- +
- +
- -
- +
- +
- Избирательная конфиденциальность
- -
- -
- -
- -
- -
- +
- +
- Конфиденциальность трафика
- +
- -
- +
- -
- -
- -
- +
- Целостность с восстановлением
- -
- -
- -
- +
- -
- -
- +
- Целосность без восстановления
- -
- -
- +
- +
- -
- -
- +
- Избирательная целостность
- -
- -
- -
- -
- -
- -
- +
- Целостность вне соединения
- -
- -
- +
- +
- -
- -
- +
- Неотказуемость
- -
- -
- -
- -
- -
- -
- +
Механизмы безопасности
Для реализации функций безопасности могут использоваться следующие механизмы и их комбинации.
Шифрование. Шифрование подразделяется на симметричное с секретным ключом, когда знание ключа шифрования влечет знание ключа расшифровки, и асимметричное с открытым ключом, когда знание ключа шифрования не позволяет узнать ключ расшифровки.
Различают также обратимое и необратимое шифрование. Последнее может использоваться для вычисления криптографических контрольных сумм (хэш-функций, дайджестов, имитовставок).
Электронная подпись. Механизм электронной подписи включает в себя две процедуры:
- выработку подписи;
- проверку подписанной порции данных.
Процедура выработки подписи использует информацию, известную только лицу, визирующему порцию данных. Процедура проверки подписи является общедоступной, она не должна позволять найти секретный ключ подписывающего.
Механизмы управления доступом. При принятии решений о предоставлении запрашиваемого типа доступа могут использоваться следующие виды и источники информации:
- Базы данных управления доступом. В такой базе, поддерживаемой централизованно, или на оконечных системах могут храниться списки управления доступом или структуры аналогичного назначения.
- Пароли или иная аутентификационная информация.
- Токены, билеты или иные удостоверения, предъявление которых свидетельствует о наличии прав доступа.
- Метки безопасности, ассоциированные с субъектами и объектами доступа.
- Время запрашиваемого доступа.
- Маршрут запрашиваемого доступа.
- Длительность запрашиваемого доступа.
Механизмы управления доступом могут располагаться у любой из общающихся сторон или в промежуточной точке. В промежуточных точках целесообразно проверять права доступа к коммуникационным ресурсам. Очевидно, что требования механизма, расположенного на приемном конце, должны быть известны заранее, до начала общения.
Механизмы контроля целостности данных. Различают два аспекта целостности: целостность отдельного сообщения, или поля информации, и целостность потока сообщений, или полей информации. Вообще говоря, контроль двух видов целостности осуществляется различными механизмами, хотя контролировать целостность потока, не проверяя отдельные сообщения, едва ли имеет смысл.
Процедура контроля целостности отдельного сообщения, или поля, включает в себя два процесса: один на передающей стороне, другой - на приемной. На передающей стороне к сообщению добавляется избыточная информация, которая является функцией от сообщения (та или иная разновидность контрольной суммы). На приемной стороне независимо генерируется контрольная сумма полученного сообщения с последующим сравнением результатов. Данный механизм сам по себе не защищает от дублирования сообщений.
Для проверки целостности потока сообщений: защиты от кражи, переупорядочивания, дублирования и вставки сообщений - используются порядковые номера, временные штампы, криптографическое связывание, при котором результат шифрования очередного сообщения зависит от предыдущего, или иные аналогичные приемы.
При общении в режиме без установления соединения использование временных штампов может обеспечить ограниченную форму защиты от дублирования сообщений.
Механизмы аутентификации. Аутентификация может достигаться за счет использования паролей, личных карточек или иных устройств аналогичного назначения, криптографических методов - когда демонстрируется знание секретного ключа, устройств измерения и анализа биометрических характеристик.
Аутентификация бывает односторонней, когда клиент обычно доказывает свою подлинность серверу, и двусторонней, или взаимной. Пример односторонней аутентификации - процедура входа пользователя в систему.
Для защиты от дублирования аутентификационной информации могут использоваться временные штампы и синхронизация часов в узлах сети.
Механизмы дополнения трафика. Механизмы дополнения трафика эффективны, разумеется, только в сочетании со средствами обеспечения конфиденциальности, поскольку в противном случае злоумышленнику будет очевиден фиктивный характер дополнительных сообщений.
Механизмы управления маршрутизацией. Маршруты могут выбираться статически или динамически. Оконечная система, зафиксировав неоднократные атаки на определенном маршруте, может отказаться от его использования. На выбор маршрута способна повлиять метка безопасности, ассоциированная с передаваемыми данными.
Механизмы нотаризации. Механизм нотаризации служит для заверения таких коммуникационных характеристик, как целостность, время, личности отправителя и получателей. Заверение обеспечивается надежной третьей стороной, которая обладает достаточной информацией, чтобы ее подтверждению можно было доверять. Обычно нотаризация опирается на механизм электронной подписи.
В таблице 2 сведены функции и механизмы безопасности, а также показано, какие отдельные механизмы или их комбинации с другими могут использоваться для реализации той или иной функции.
Таблица 2.
Взаимосвязь функций и механизмов безопасности.- Механизмы/Функции безопасности
- Шифрование подписи
- Электронный трафик
- Управление доступом
- Целостность
- Аутентификация
- Дополнение
- Управление маршрутизацией
- Нотаризация
- Аутентификация партнеров
- +
- +
- -
- -
- +
- -
- -
- -
- Аутентификация источника
- +
- +
- -
- -
- -
- -
- -
- -
- Управление доступом
- -
- -
- +
- -
- -
- -
- -
- -
- Конфиденциальность
- +
- -
- -
- -
- -
- -
- +
- -
- Избирательная конфиденциальность
- +
- -
- -
- -
- -
- -
- -
- -
- Конфиденциальность трафика
- +
- -
- -
- -
- -
- +
- +
- -
- Целостность соединения
- +
- -
- -
- +
- -
- -
- -
- -
- Целосность вне соединения
- +
- +
- -
- +
- -
- -
- -
- -
- Неотказуемость
- -
- +
- -
- +
- -
- -
- -
- +
Администрирование средств безопасности
Администрирование средств безопасности включает в себя распространение информации, необходимой для работы функций и механизмов безопасности, а также сбор и анализ информации об их функционировании. Примерами могут служить распространение криптографических ключей, установка значений параметров защиты, ведение регистрационного журнала и т.п.
Концептуальной основой администрирования является информационная база управления безопасностью. Эта база может не существовать как единое, распределенное хранилище, но каждая из оконечных систем должна располагать информацией, необходимой для проведения в жизнь избранной политики безопасности.
Усилия администратора средств безопасности должны распределяться по трем направлениям:
- администрирование системы в целом;
- администрирование функций безопасности;
- администрирование механизмов безопасности.
Среди действий, относящихся к системе в целом, отметим поддержание актуальности политики безопасности, взаимодействие с другими административными службами, реагирование на происходящие события, аудит и безопасное восстановление.
Администрирование функций безопасности включает в себя определение защищаемых объектов, выработку правил подбора механизмов безопасности (при наличии альтернатив), комбинирование механизмов для реализации функции безопасности, взаимодействие с другими администраторами для обеспечения согласованной работы.
Обязанности администратора механизмов безопасности определяются перечнем задействованных механизмов. Типичный список имеет следующий вид:
- Управление ключами (генерация и распределение). Вероятно, многие аспекты управления ключами, например их доставка, выходят за пределы среды OSI.
- Управление шифрованием: установка и синхронизация криптографических параметров. К управлению шифрованием можно отнести и администрирование механизмов электронной подписи. Управление целостностью, если оно обеспечивается криптографическими средствами, также тяготеет к данному направлению.
- Администрирование управления доступом (распределение информации, необходимой для управления - пароли, списки доступа и т. п.).
- Управление аутентификацией (распределение информации, необходимой для аутентификации - паролей, ключей и т. п.).
- Управление дополнением трафика (выработка и поддержание правил, задающих характеристики дополняющих сообщений - частоту отправки, размер и т. п.). Характеристики могут варьироваться по заданному закону в зависимости от даты и времени.
- Управление маршрутизацией (выделение надежных путей).
- Управление нотаризацией (распространение информации о нотариальных службах, администрирование этих служб).
Мы видим, что администрирование средств безопасности в распределенной среде имеет много особенностей по сравнению с централизованными системами.
Интерпретация "Оранжевой книги" для сетевых конфигураций
В 1987 году Национальный центр компьютерной безопасности США выпустил в свет интерпретацию "Оранжевой книги" для сетевых конфигураций [4]. Данный документ состоит из двух частей. Первая содержит собственно интерпретацию, во второй рассматриваются сервисы безопасности, специфичные или особенно важные для сетевых конфигураций.
Интерпретация
В первой части вводится минимум новых понятий. Важнейшее из них - сетевая надежная вычислительная база, распределенный аналог надежной вычислительной базы изолированных систем. Сетевая надежная вычислительная база формируется из всех частей всех компонентов сети, обеспечивающих информационную безопасность. Надежная сетевая система должна обеспечивать такое распределение защитных механизмов, чтобы общая политика безопасности проводилась в жизнь несмотря на уязвимость коммуникационных путей и параллельную, асинхронную работу компонентов.
Не существует прямой зависимости между вычислительными базами компонентов, рассматриваемых как изолированные системы, и фрагментами сетевой вычислительной базы. Более того, нет прямой зависимости и между уровнями безопасности отдельных компонентов и уровнем безопасности всей сетевой конфигурации. Например, в результате объединения двух систем класса B1, обладающих несовместимыми правилами кодирования меток безопасности, получается сеть, не удовлетворяющая требованию обеспечения целостности меток. В качестве противоположного примера рассмотрим объединение двух компонентов, один из которых не обеспечивает сам протоколирование действий пользователя, но передает необходимую информацию другому компоненту, который и ведет протокол. В таком случае сеть в целом, несмотря на слабость компонента, удовлетворяет требованию подотчетности.
Чтобы понять суть положений, вошедших в первую часть, рассмотрим интерпретацию требований к классу безопасности С2. Первое требование - это поддержка добровольного управления доступом. "Интерпретация" предусматривает различные варианты распределения сетевой надежной вычислительной базы по компонентам и, соответственно, различные варианты распределения механизмов управления доступом. В частности, некоторые компоненты, закрытые от прямого доступа пользователей (например, коммутаторы пакетов, оперирующие на третьем уровне семиуровневой модели OSI), могут вообще не содержать подобных механизмов.
Пользователь осуществляет доступ к удаленному ресурсу посредством суррогатного процесса, выполняющегося на удаленной системе от его имени. Данный процесс подвергается стандартным локальным процедурам контроля доступа. "Интерпретация" предусматривает различные способы ассоциирования идентификатора пользователя с суррогатным процессом. Может существовать единая идентификационная база данных, доступная каждому компоненту; могут быть реализованы лишь локальные базы, и тогда суррогатный процесс выполняется от имени незарегистрированного пользователя или по некоторым правилам получает идентификатор кого-либо из локальных пользователей.
Идентификация групп пользователей может строиться на основе сетевых адресов хостов или подсетей. В то же время регистрационный журнал должен содержать достаточно информации для ассоциирования действий с конкретным пользователем. Сетевой адрес может являться частью глобального идентификатора пользователя.
В принципе возможен централизованный контроль доступа, когда решения принимает специальный сервер авторизации. Возможен и смешанный вариант, когда сервер авторизации разрешает соединение двух хостов, а дальше в дело вступают локальные механизмы хоста, содержащего объект доступа.
Аналогично, идентификация и аутентификация пользователей может производиться как централизованно (соответствующим сервером), так и локально - той системой, с которой пользователь непосредственно взаимодействует. Возможна передача идентификационной и аутентификационной информации между хостами, чтобы избавить пользователя от многократной аутентификации. При передаче аутентификационная информация должна быть защищена не слабее, чем на каждом из компонентов сетевой конфигурации.
В идентификации и аутентификации могут нуждаться не только пользователи, но и компоненты сети, такие как хосты.
Регистрационная информация в сетевом случае может включать в себя записи новых видов, например, сведения об установлении и разрыве соединений, о потенциальном нарушении целостности данных, например, в ввиду неправильной маршрутизации датаграмм, об изменениях в конфигурации сети. "Адресное пространство пользователей" становится распределенным, а в число регистрируемых событий попадают действия с удаленными объектами (открытие, переименование и т.п.).
При ведении регистрационного журнала могут использоваться локальные или глобальные синхронизированные часы.
Регистрационные журналы разных компонентов сети должны быть согласованы между собой; должны предоставляться средства для комплексного анализа совокупности регистрационных журналов с целью глобального отслеживания деятельности пользователей.
Возможно выделение в сети одного или нескольких серверов протоколирования и аудита, обслуживающих другие компоненты, которые не имеют ресурсов или по иным причинам не желают вести протоколирование самостоятельно.
Переходя к рассмотрению вопросов гарантированности, отметим, что каждая часть сетевой надежной вычислительной базы, расположенная на отдельном компоненте, должна поддерживать отдельную область для собственного выполнения, защищенную от внешних воздействий.
"Интерпретация" отличается от самих "Критериев" учетом динамичности сетевых конфигураций. Предусматривается наличие средств проверки подлинности и корректности функционирования компонентов перед их включением в сеть, наличие протокола взаимной проверки компонентами живучести и корректности функционирования друг друга, доступность средств оповещения администратора о неполадках в сети. Сетевая конфигурация должна быть устойчива к отказам отдельных компонентов или коммуникационных путей.
Динамичность, согласно "Интерпретации", должна найти отражение в Руководстве администратора по средствам безопасности. Помимо прочих, это Руководство обязано освещать такие темы, как аппаратное конфигурирование сети, учет последствий подключения новых компонентов или отключения старых.
В качестве еще одного отличительного момента "Интерпретации" отметим повышенное внимание к целостности информации вообще и меток безопасности в частности. Здесь уже речь идет о некоторых аспектах принудительного управления доступом, характерного для уровня безопасности "В". Для контроля целостности меток и для их защиты от нелегального изменения в "Интерпретации" рекомендуется широкое использование криптографических методов. Далее, чтобы принудительное управление доступом в распределенной конфигурации имело смысл, совокупность уровней секретности и категорий должна поддерживаться централизованно. В этом одно из принципиальных отличий от добровольного управления доступом.
В целом следует отметить довольно очевидный характер первой части "Интерпретации", что, впрочем, является прямым следствием выбранного методологического подхода. Описание существенно новых сервисов и механизмов вынесено во вторую часть документа. Если первая часть посвящена в основном управлению доступом к информации, то во второй нашли отражение все основные аспекты безопасности: конфиденциальность, целостность и доступность.
Новые сервисы безопасности и защитные механизмы
Рассматриваемый документ создавался примерно в то же время, что и Рекомендации Х.800. Естественно, что две рабочие группы обменивались информацией, поэтому во многих отношениях их подходы схожи. Имеются, однако, и важные различия. "Интерпретация" не замыкается на эталонной семиуровневой модели, ее цель - оценка безопасности всей распределенной конфигурации, а не только чисто сетевых аспектов. Рекомендации Х.800 в основном имеют дело с функциональностью (с сервисами безопасности) и в меньшей степени - с защитными механизмами. В части 2 "Интерпретации" анализируется еще одна важнейшая характеристика - гарантированность.
Основой функционирования сетей вообще и коммуникационной безопасности в частности являются сетевые протоколы. Многие защитные механизмы встраиваются в протоколы. От протоколов зависит защита системы от тупиков и иных обстоятельств, способных повлиять на доступность сервисов, а также наличие средств обнаружения ситуаций недоступности. Протоколы влияют и на возможность поддержания целостности данных.
Среди защитных механизмов в сетевых конфигурациях на первом месте стоит криптография, помогающая поддерживать как конфиденциальность, так и целостность. Следствием использования криптографических методов является необходимость реализации механизмов управления ключами.
Для поддержания целостности (в аспектах, относящихся к коммуникациям) используются аутентификация, контроль целостности полей и механизмы обеспечения неотказуемости. Этот сервис подробно рассматривался в связи с Рекомендациями Х.800.
Новым, по сравнению с Х.800, является подход к вопросу доступности. Сетевой сервис перестает быть доступным, когда пропускная способность коммуникационных каналов падает ниже минимально допустимого уровня или сервис не в состоянии обслуживать запросы. Удаленный ресурс может стать недоступным и вследствие нарушения равноправия в обслуживании пользователей. Надежная система должна быть в состоянии обнаруживать ситуации недоступности, уметь возвращаться к нормальной работе и противостоять атакам на доступность.
Для обеспечения непрерывности функционирования могут применяться следующие защитные меры:
- Внесение в конфигурацию той или иной формы избыточности (резервное оборудование, запасные каналы связи и т.п.).
- Наличие средств реконфигурирования для изоляции и/или замены узлов или коммуникационных каналов, отказавших или подвергшихся атаке на доступность.
- Рассредоточенность сетевого управления, отсутствие единой точки отказа.
- Наличие средств нейтрализации отказов (обнаружение отказавших компонентов, оценка последствий, восстановление после отказов).
- Выделение подсетей и изоляция групп пользователей друг от друга.
С точки зрения оценки надежности систем, критерии части 2 дополняют "Оранжевую книгу". Каждый сервис безопасности рассматривается независимо и может получить одну из трех положительных оценок. Таким образом, общая оценка сетевой конфигурации выглядит примерно так: класс безопасности С2, сервис_1 - удовлетворительно, сервис_2 - хорошо и т.д. Заказчик, зная свои потребности, в состоянии принять решение о пригодности той или иной конфигурации.
Оценка надежностн сетевой конфигурации на основе оценки компонентов
В части 1 "Интерпретации" излагается подход к оценке надежности сетевой конфигурации как единого целого. В то же время имеет право на существование и другой взгляд, когда сеть составляется из предварительно проверенных компонентов, а общая оценка по определенным правилам выводится из их "рейтинга". Подобная точка зрения является предметом рассмотрения приложений к "Интерпретации", где анализируются три главных вопроса:
- Как следует структурировать сеть, чтобы оценка компонентов помогала получить общую оценку?
- Какие критерии следует применять к компонентам?
- Как получать общую оценку?
Предварительным условием надежности сетевой конфигурации является наличие единой политики безопасности, с которой должны быть согласованы поведение каждого компонента и характер связей между ними. В "Интерпретации" рассматриваются следующие аспекты политики безопасности:
- добровольное управление доступом;
- принудительное управление доступом;
- идентификация и аутентификация;
- протоколирование и аудит.
Одним из важнейших в "Оранжевой книге" является понятие монитора обращений, а применительно к структурированию сетевой конфигурации можно сформулировать следующее утверждение, дающее достаточное условие корректности фрагментирования монитора обращений.
Утверждение 1. Пусть каждый субъект, в качестве которого выступает процесс, действующий от имени какого-либо пользователя, заключен внутри одного компонента и может осуществлять непосредственный доступ к объектам только в пределах этого компонента. Пусть, далее, каждый компонент содержит свой монитор обращений, отслеживающий все локальные попытки доступа и все мониторы проводят в жизнь согласованную политику безопасности. Пусть, наконец, коммуникационные каналы, связывающие компоненты, сохраняют конфиденциальность и целостность передаваемой информации. Тогда совокупность всех мониторов образует единый монитор обращений для всей сетевой конфигурации.
Истинность этого утверждения непосредственно следует из определения монитора обращений.
Отметим разумность структурирования на компоненты, содержащие собственные мониторы обращений. Обычно каждый такой компонент предоставляет законченный набор услуг, а значит, его выделение естественно и целесообразно не только с точки зрения безопасности, но и с функциональной точки зрения.
Таким образом, сетевые конфигурации рекомендуется структурировать на компоненты, предоставляющие определенные виды сервиса и отслеживающие обращения к своим объектам, и на коммуникационные каналы, защищенные надежными сетевыми сервисами, использующими, как правило, криптографические механизмы.
Оценка компонентов производится по обычным критериям "Оранжевой книги" с одной важной оговоркой, а именно: каждый компонент, вообще говоря, не обязан поддерживать все перечисленные выше аспекты политики безопасности. В таком случае к нему нужно применять соответствующее подмножество критериев. Компоненты, поддерживающие лишь часть аспектов политики безопасности, должны обладать программными и/или протокольными интерфейсами, чтобы получить недостающие им сервисы от других компонентов (предоставляющих такую возможность).
При оценке сетевой конфигурации принимается во внимание тип компонентов и присвоенный им класс безопасности. Комбинируя четыре аспекта политики безопасности, каждый из которых может независимо поддерживаться или не поддерживаться, получим 15 типов компонентов и их комбинаций (случай, когда не поддерживается ни один аспект, не рассматривается). Как правило, условия корректности комбинаций и итоговый класс безопасности очевидным образом следуют из обычных критериев. Так, при объединении двух компонентов, поддерживающих добровольное управление доступом, необходимо, чтобы был определен протокол передачи идентификационной информации, на которой основываются решения о предоставлении запрашиваемого вида доступа. Политика безопасности каждого компонента и их объединения должна быть согласована с общей политикой. Итоговый класс безопасности объединения равен минимальному из классов, присвоенных компонентам.
При объединении компонента с добровольным управлением доступом и компонента, поддерживающего идентификацию и аутентификацию, должны сохраниться возможности обоих компонентов и, кроме того, для классов С2 и выше необходимо наличие интерфейса к компонентам протоколирования и аудита. Если компонент идентификации отнесен к классу безопасности С2, то итоговый класс объединения совпадает с классом компонента с добровольным управлением доступом.
В. Галатенко Vladimir.Galatenko@jet.msk.su
АО "Инфосистемы Джет"
-
Литература
[1] В. Галатенко. Информационная безопасность, "Открытые системы", # 4, 1995.
[2] В. Галатенко. Информационная безопасность, "Открытые системы", # 5, 1995.
[3] Security Architecture for Open Systems lnterconnection for CCITT Applications. Recommendation X.800. - CCITT, Geneva, 1991.
[4] National Computer Security Center. Trusted Network Interpretation. - NCSC-TG-005, 1987.
(c) АО "Инфосистемы Джет",1995
