 |
Порядок аттестации объектов
|
|
|
|
Регламентом стандарта предусмотрено, что сначала владелец ИС создает ее профиль защиты или задание по безопасности. Формализовать критерии выбора - что именно писать, профиль или задание по безопасности, довольно трудно. Если организация небольшая, то более эффективной будет разработка задания по безопасности. Если информационная система очень велика - возьмем для примера ведомство с огромным количеством филиалов, причем требования к подсистеме информационной безопасности примерно одинаковы для всех филиалов, но информационные системы в филиалах построены с некоторыми различиями, - то эффективнее разработать профиль защиты. Такой профиль описывает функции безопасности, которые должны обеспечиваться в ИС каждого филиала независимо от того, с помощью каких ОС, СУБД и прикладного ПО они построены. А для каждого филиала в данном случае необходимо написать отдельное задание по безопасности.
После разработки задания в соответствии со списком необходимых функций безопасности подбираются средства или системы защиты информации, реализующие данные функции. Выбранные системы должны быть сертифицированы по ГОСТ 15408 на соответствие разработанным заданиям по безопасности. В подсистеме защиты информации применяются выбранные средства или СЗИ в той конфигурации, в которой они описаны в задании по безопасности на ИС. И, наконец, подсистема информационной безопасности сертифицируется на соответствие заданию безопасности по ГОСТ 15408.
Учитывая все вышесказанное, нетрудно заметить, что для аттестации ИС недостаточно простой установки сертифицированной ОС (например, Windows XP) на всех компьютерах организации. Необходимо разработать профиль (как минимум - задание по безопасности) на автоматизированную систему с непротиворечивой моделью угроз, политик и предположений безопасности. После этого нужно подобрать такие сертифицированные по "Общим критериям" программные продукты, функции безопасности которых позволяют защититься от описанных угроз (и вот в числе этих продуктов уже может использоваться ОС Windows XP).
|
|
|
Сертификация Windows XP по "Общим критериям"
Как сообщалось, 22 января 2004 г. ОС Microsoft Windows XP прошла сертификацию. Сертификат № 844 подтверждает, что Windows XP Professional (Service Pack 1a) соответствует заданию по безопасности MS.Win_XP_SP1a.ЗБ. Но: внимание! В сертификате указано, что сертифицирована партия Windows XP из 300 штук. Заявитель - ФГУП "Предприятие по поставкам продукции Управления делами Президента Российской Федерации". Вывод: на рынке сейчас отсутствует сертифицированная ОС Windows XP.
Последствия для рынка
Для производителей СЗИ
Чтобы уяснить себе последствия перехода на сертификацию СЗИ по ГОСТ 15408-2000 для производителей СЗИ, необходимо вкратце описать некоторые стороны порядка сертификации по "старым" нормативам. Ранее существовали (и пока продолжают действовать) несколько РД Гостехкомиссии, которые определяли требования, например, для межсетевых экранов, для систем защиты информации от несанкционированного доступа, для антивирусов и т. д. Данные требования, однажды созданные, содержали небольшой и при этом статичный набор, который не изменялся со временем, несмотря на появление новых угроз, видов атак и даже функций безопасности самого продукта.
При этом два средства защиты, например, два межсетевых экрана, могли быть сертифицированы по одному документу и с формальной точки зрения обладали одинаковым функционалом. Однако на практике между ними могли быть значительные различия: например, один межсетевой экран управляется локально, не имеет горячего резервирования, не выполняет трансляцию адресов и т. д., а у второго все эти функции есть. В то же время с точки зрения сертификата данные межсетевые экраны одинаковы и могут использоваться для защиты конфиденциальной информации.
|
|
|
Теперь же, после принятия ОК, на каждый из таких межсетевых экранов можно создать собственный профиль для сертификации. Но технологически более слабый продукт не сможет быть сертифицирован по тому же профилю, что и функционально превосходящее его средство защиты. И хотя ясно, что на рынке ИБ существует конкуренция, после введения ОК конкурентные преимущества тех или иных продуктов будут уже формально зафиксированы в сертификате Гостехкомиссии России. Это очень и очень важный факт при выборе системы защиты информации, особенно для госструктур.
Кроме того, если будет введено постановление о взаимопризнании сертификатов, российский рынок СЗИ (но только тех, которые не предоставляют криптографических функций) становится открытым для конкуренции с зарубежными производителями и поставщиками.
Таким образом, можно прогнозировать, что наиболее востребованными станут услуги в области информационной безопасности, которые предоставляют российские специализированные интеграторы, и программные продукты, реализующие криптографические функции в соответствии с российскими стандартами (средства для создания виртуальных частных сетей, криптопровайдеры и т. д).
Для потребителей СЗИ
Очевидно, что более острая конкуренция между разработчиками СЗИ всегда на руку потребителям. Однако есть и еще один немаловажный положительный аспект, который будет интересен потребителям. Согласно ГОСТ, для каждой ИС должен создаваться свой профиль защиты (или задание по безопасности). Следуя профилю защиты, организация сможет подбирать такие СЗИ, которые наилучшим образом реализуют необходимые для ИС функции безопасности. Важно, что при таком подборе можно будет отбросить системы защиты, функционал которых излишне широк для применения в данной конкретной организации.
Например, если сеть организации находится внутри контролируемой зоны, то нет необходимости в применении таких СЗИ, которые шифруют трафик между рабочими станциями сети. Поэтому и затраты на информационную безопасность станут более обоснованными. Таким образом, будет соблюден принцип разумной достаточности, при котором в ИС применяются только те системы защиты, функций которых достаточно для обеспечения безопасности.
|
|
|
(15 вопрос) Рекомендации Х.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, то итоговый класс объединения совпадает с классом компонента с добровольным управлением доступом.
(16-18 вопросы) Дискреционная, Мандатная, Ролевая модель доступа.
4.1. Дискреционное управление доступом
Если пользователь создает файл, он является владельцем этого файла. Идентификатор этого пользователя размещается в заголовке файла. Владение может быть также предоставлено определенному человеку. Систе
|
|
|
