Действия общего характера предпринимаемые руководством организации это

К
административному
уровню информационной безопасности
относятся действия общего характера,
предпринимаемые руководством организации.

Главная
цель мер административного
уровня
— сформировать программу работ в области
информационной безопасности и обеспечить
ее выполнение, выделяя необходимые
ресурсы и контролируя состояние дел.

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

Политика
безопасности
строится на основе анализа
рисков,
которые признаются реальными для
информационной системы организации.
Когда риски проанализированы и стратегия
защиты определена, составляется программа
обеспечения информационной безопасности.
Под эту программу выделяются ресурсы,
назначаются ответственные, определяется
порядок контроля выполнения программы
и т.п.

Термин
«политика
безопасности»
является не совсем точным переводом
английского словосочетания «security
policy», однако в данном случае калька
лучше отражает смысл этого понятия, чем
лингвистически более верные «правила
безопасности». Мы будем иметь в виду не
отдельные правила или их наборы (такого
рода решения выносятся на процедурный
уровень, речь о котором впереди), а
стратегию организации в области
информационной безопасности. Для
выработки стратегии и проведения ее в
жизнь нужны, несомненно, политические
решения, принимаемые на самом высоком
уровне.

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

Такая
трактовка, конечно, гораздо шире, чем
набор правил
разграничения доступа
(именно это означал термин «security policy»
в «Оранжевой книге» и в построенных на
ее основе нормативных документах других
стран).

ИС
организации и связанные с ней интересы
субъектов — это сложная система, для
рассмотрения которой необходимо
применять объектно-ориентированный
подход и понятие уровня детализации.
Целесообразно выделить, по крайней
мере, три таких уровня, что мы уже делали
в примере и сделаем еще раз далее.

Чтобы
рассматривать ИС предметно, с использованием
актуальных данных, следует составить
карту
информационной системы.
Эта карта,
разумеется, должна быть изготовлена в
объектно-ориентированном стиле, с
возможностью варьировать не только
уровень
детализации,
но и видимые грани объектов. Техническим
средством составления, сопровождения
и визуализации подобных карт
может служить свободно распространяемый
каркас какой-либо системы управления.

Политика
безопасности

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

• решение
  сформировать или пересмотреть комплексную
  программу обеспечения информационной
  безопасности, назначение ответственных
  за продвижение программы;

• формулировка
  целей, которые преследует организация
  в области информационной безопасности,
  определение общих направлений в
  достижении этих целей;

• обеспечение
  базы для соблюдения законов и правил;

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

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

На
верхний уровень выносится управление
защитными ресурсами и координация
использования этих ресурсов, выделение
специального персонала для защиты
критически важных систем и взаимодействие
с другими организациями, обеспечивающими
или контролирующими режим безопасности.

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

В
политике должны быть определены
обязанности должностных лиц по выработке
программы безопасности и проведению
ее в жизнь. В этом смысле политика
безопасности
является основой подотчетности персонала.

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

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

Британский
стандарт BS 7799:1995 рекомендует включать
в документ, характеризующий политику
безопасности организации, следующие
разделы:

• вводный,
  подтверждающий озабоченность высшего
  руководства проблемами информационной
  безопасности;

• организационный,
  содержащий описание подразделений,
  комиссий, групп и т.д., отвечающих за
  работы в области информационной
  безопасности;

• классификационный,
  описывающий имеющиеся в организации
  материальные и информационные ресурсы
  и необходимый уровень их защиты;

• штатный,
  характеризующий меры безопасности,
  применяемые к персоналу (описание
  должностей с точки зрения информационной
  безопасности, организация обучения и
  переподготовки персонала, порядок
  реагирования на нарушения режима
  безопасности и т.п.);

• раздел,
  освещающий вопросы физической
  защиты;

• управляющий
  раздел, описывающий подход к управлению
  компьютерами и компьютерными сетями;

• раздел,
  описывающий правила
  разграничения
  доступа к производственной информации;

• раздел,
  характеризующий порядок
  разработки
  и сопровождения систем;

• раздел,
  описывающий меры, направленные на
  обеспечение непрерывной
  работы
  организации;

• юридический
  раздел, подтверждающий соответствие
  политики безопасности действующему
  законодательству.

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

Политика
среднего уровня должна для каждого
аспекта освещать следующие темы:

Описание
аспекта. Например, если рассмотреть
применение пользователями неофициального
программного обеспечения, последнее
можно определить как ПО, которое не было
одобрено и/или закуплено на уровне
организации.

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

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

Роли
и обязанности. В «политический» документ
необходимо включить информацию о
должностных лицах, ответственных за
реализацию политики безопасности.
Например, если для использования
неофициального программного обеспечения
сотрудникам требуется разрешение
руководства, должно быть известно, у
кого и как его можно получить. Если
неофициальное программное обеспечение
использовать нельзя, следует знать, кто
следит за выполнением данного правила.

Законопослушность.
Политика должна содержать общее описание
запрещенных действий и наказаний за
них.

Точки
контакта. Должно быть известно, куда
следует обращаться за разъяснениями,
помощью и дополнительной информацией.
Обычно «точкой контакта» служит
определенное должностное лицо, а не
конкретный человек, занимающий в данный
момент данный пост.

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

• кто
  имеет право доступа к объектам,
  поддерживаемым сервисом?

• при
  каких условиях можно читать и
  модифицировать данные?

• как
  организован удаленный доступ к сервису?

При
формулировке целей политики нижнего
уровня можно исходить из соображений
целостности, доступности и конфиденциальности,
но нельзя на этом останавливаться. Ее
цели должны быть более конкретными.
Например, если речь идет о системе
расчета заработной платы, можно поставить
цель, чтобы только сотрудникам отдела
кадров и бухгалтерии позволялось вводить
и модифицировать информацию. В более
общем случае цели должны связывать
между собой объекты сервиса и действия
с ними.

Из
целей выводятся правила безопасности,
описывающие, кто, что и при каких условиях
может делать. Чем подробнее правила,
чем более формально они изложены, тем
проще поддержать их выполнение
программно-техническими средствами. С
другой стороны, слишком жесткие правила
могут мешать работе пользователей,
вероятно, их придется часто пересматривать.
Руководству предстоит найти разумный
компромисс, когда за приемлемую цену
будет обеспечен приемлемый уровень
безопасности, а сотрудники не окажутся
чрезмерно связаны. Обычно наиболее
формально задаются права доступа к
объектам ввиду особой важности данного
вопроса.

Программа
безопасности

После
того, как сформулирована политика
безопасности,
можно приступать к составлению программы
ее реализации и собственно к реализации.

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

Программу
верхнего уровня возглавляет лицо,
отвечающее за информационную безопасность
организации. У этой программы следующие
главные цели:

• управление
  рисками (оценка
  рисков,
  выбор эффективных средств защиты);

• координация
  деятельности в области информационной
  безопасности, пополнение и распределение
  ресурсов;

• стратегическое
  планирование;

• контроль
  деятельности в области информационной
  безопасности.

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

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

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

Цель
программы нижнего уровня — обеспечить
надежную и экономичную защиту конкретного
сервиса или группы однородных сервисов.
На этом уровне решается, какие следует
использовать механизмы защиты; закупаются
и устанавливаются технические средства;
выполняется повседневное администрирование;
отслеживается состояние слабых мест и
т.п. Обычно за программу нижнего уровня
отвечают администраторы сервисов.

Синхронизация
программы безопасности с жизненным
циклом систем

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

В
жизненном
цикле
информационного сервиса можно выделить
следующие этапы:

Инициация.
На данном этапе выявляется необходимость
в приобретении нового сервиса,
документируется его предполагаемое
назначение.

Закупка.
На данном этапе составляются спецификации,
прорабатываются варианты приобретения,
выполняется собственно закупка.

Установка.
Сервис устанавливается, конфигурируется,
тестируется и вводится в эксплуатацию.

Эксплуатация.
На данном этапе сервис не только работает
и администрируется, но и подвергается
модификациям.

Выведение
из эксплуатации.
Происходит переход на новый сервис.

Рассмотрим
действия, выполняемые на каждом из
этапов, более подробно.

На
этапе инициации
оформляется понимание того, что необходимо
приобрести новый или значительно
модернизировать существующий сервис;
определяется, какими характеристиками
и какой функциональностью он должен
обладать; оцениваются финансовые и иные
ограничения.

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

• какого
  рода информация предназначается для
  обслуживания новым сервисом?

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

• каковы
  угрозы, по отношению к которым сервис
  и информация будут наиболее уязвимы?

• есть
  ли какие-либо особенности нового сервиса
  (например, территориальная распределенность
  компонентов), требующие принятия
  специальных процедурных мер?

• каковы
  характеристики персонала, имеющие
  отношение к безопасности (квалификация,
  благонадежность)?

• каковы
  законодательные положения и внутренние
  правила, которым должен соответствовать
  новый сервис?

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

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

Когда
продукт закуплен, его необходимо
установить.
Несмотря на кажущуюся простоту, установка
является очень ответственным делом.
Во-первых, новый продукт следует
сконфигурировать. Как правило, коммерческие
продукты поставляются с отключенными
средствами безопасности; их необходимо
включить и должным образом настроить.
Для большой организации, где много
пользователей и данных, начальная
настройка может стать весьма трудоемким
и ответственным делом.

Во-вторых,
новый сервис нуждается в процедурных
регуляторах. Следует позаботиться о
чистоте и охране помещения, о документах,
регламентирующих использование сервиса,
о подготовке планов на случай экстренных
ситуаций, об организации обучения
пользователей и т.п.

После
принятия перечисленных мер необходимо
провести тестирование. Его полнота и
комплексность могут служить гарантией
безопасности эксплуатации
в штатном режиме.

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

Для
борьбы с эффектом медленных изменений
приходится прибегать к периодическим
проверкам безопасности сервиса.
Разумеется, после значительных модификаций
подобные проверки являются обязательными.

При
выведении
из эксплуатации
затрагиваются аппаратно-программные
компоненты сервиса и обрабатываемые
им данные. Аппаратура продается,
утилизируется или выбрасывается. Только
в специфических случаях необходимо
заботиться о физическом разрушении
аппаратных компонентов, хранящих
конфиденциальную информацию. Программы,
вероятно, просто стираются, если иное
не предусмотрено лицензионным соглашением.

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

Лекция
7 Процедурный уровень информационной
безопасности

Основные
классы мер процедурного уровня

Мы
приступаем к рассмотрению мер безопасности,
которые ориентированы на людей, а не на
технические средства. Именно люди
формируют режим информационной
безопасности, и они же оказываются
главной угрозой, поэтому «человеческий
фактор» заслуживает особого внимания.

В
российских компаниях накоплен богатый
опыт регламентирования и реализации
процедурных (организационных) мер,
однако дело в том, что они пришли из
«докомпьютерного» прошлого, поэтому
требуют переоценки.

Следует
осознать ту степень зависимости от
компьютерной обработки данных, в которую
попало современное общество. Без всякого
преувеличения можно сказать, что
необходима информационная гражданская
оборона. Спокойно, без нагнетания
страстей, нужно разъяснять обществу не
только преимущества, но и опасности,
связанные с использованием информационных
технологий. Акцент следует делать не
на военной или криминальной стороне
дела, а на гражданских аспектах, связанных
с поддержанием нормального функционирования
аппаратного и программного обеспечения,
то есть концентрироваться на вопросах
доступности и целостности данных.

На
процедурном
уровне
можно выделить следующие классы мер:

• управление
  персоналом;

• физическая
  защита;

• поддержание
  работоспособности;

• реагирование
  на нарушения режима безопасности;

• планирование
  восстановительных работ.

Управление
персоналом

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

• разделение
  обязанностей;

• минимизация
  привилегий.

Принцип
разделения
обязанностей
предписывает как распределять роли и
ответственность, чтобы один человек не
мог нарушить критически важный для
организации процесс. Например, нежелательна
ситуация, когда крупные платежи от имени
организации выполняет один человек.
Надежнее поручить одному сотруднику
оформление заявок на подобные платежи,
а другому — заверять эти заявки. Другой
пример — процедурные ограничения действий
суперпользователя. Можно искусственно
«расщепить» пароль суперпользователя,
сообщив первую его часть одному
сотруднику, а вторую — другому. Тогда
критически важные действия по
администрированию ИС они смогут выполнить
только вдвоем, что снижает вероятность
ошибок и злоупотреблений.

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

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

Когда
кандидат определен, он, вероятно, должен
пройти обучение;
по крайней мере, его следует подробно
ознакомить со служебными обязанностями,
а также с нормами и процедурами
информационной безопасности. Желательно,
чтобы меры безопасности были им усвоены
до вступления в должность и до заведения
его системного счета с входным именем,
паролем и привилегиями.

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

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

К
управлению сотрудниками примыкает
администрирование лиц, работающих по
контракту (например, специалистов
фирмы-поставщика, помогающих запустить
новую систему). В соответствии с принципом
минимизации
привилегий,
им нужно выделить ровно столько прав,
сколько необходимо, и изъять эти права
сразу по окончании контракта. Проблема,
однако, состоит в том, что на начальном
этапе внедрения «внешние» сотрудники
будут администрировать «местных», а не
наоборот. Здесь на первый план выходит
квалификация персонала организации,
его способность быстро обучаться,
а также оперативное проведение учебных
курсов. Важны и принципы выбора деловых
партнеров.

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

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

Физическая
защита

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

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

Мы
кратко рассмотрим следующие направления
физической
защиты:

• физическое
  управление доступом;

• противопожарные
  меры;

• защита
  поддерживающей инфраструктуры;

• защита
  от перехвата данных;

• защита
  мобильных систем.

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

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

Во-вторых,
производится декомпозиция контролируемой
территории, выделяются (под)объекты и
связи (проходы) между ними. При такой,
более глубокой детализации следует
выделить среди подобъектов наиболее
критичные с точки зрения безопасности
и обеспечить им повышенное внимание.
Декомпозиция должна быть семантически
оправданной, обеспечивающей разграничение
разнородных сущностей, таких как
оборудование разных владельцев или
персонал, работающий с данными разной
степени критичности. Важно сделать так,
чтобы посетители, по возможности, не
имели непосредственного доступа к
компьютерам или, в крайнем случае,
позаботиться о том, чтобы от окон и
дверей не просматривались экраны
мониторов и принтеры. Необходимо, чтобы
посетителей по внешнему виду можно было
отличить от сотрудников. Если отличие
состоит в том, что посетителям выдаются
идентификационные карточки, а сотрудники
ходят «без опознавательных знаков»,
злоумышленнику достаточно снять
карточку, чтобы его считали «своим».
Очевидно, соответствующие карточки
нужно выдавать всем.

Средства
физического управления доступом известны
давно. Это охрана, двери с замками,
перегородки, телекамеры, датчики движения
и многое другое. Для выбора оптимального
(по критерию стоимость/эффективность)
средства целесообразно провести анализ
рисков (к этому мы еще вернемся). Кроме
того, есть смысл периодически отслеживать
появление технических новинок в данной
области, стараясь максимально
автоматизировать физическую
защиту.

Более
подробно данная тема рассмотрена в
статье В. Барсукова «Физическая защита
информационных систем» (Jet Info, 1997, 1).

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

К
поддерживающей инфраструктуре можно
отнести системы электро-, водо- и
теплоснабжения, кондиционеры и средства
коммуникаций. В принципе, к ним применимы
те же требования целостности и доступности,
что и к информационным системам. Для
обеспечения целостности нужно защищать
оборудование от краж и повреждений. Для
поддержания доступности следует выбирать
оборудование с максимальным временем
наработки на отказ, дублировать
ответственные узлы и всегда иметь под
рукой запчасти.

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

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

Желающим
подробнее ознакомиться с вопросом мы
рекомендуем прочитать статью В. Барсукова
«Блокирование технологических каналов
утечки информации» (Jet Info, 1998, 5-6).

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

Вообще
говоря, при выборе средств физической
защиты
следует производить анализ рисков. Так,
принимая решение о закупке источника
бесперебойного питания, необходимо
учесть качество электропитания в здании,
занимаемом организацией (впрочем, почти
наверняка оно окажется плохим), характер
и длительность сбоев электропитания,
стоимость доступных источников и
возможные потери от аварий (поломка
техники, приостановка работы организации
и т.п.) (см. также статью В.Барсукова
«Защита компьютерных систем от силовых
деструктивных воздействий» в Jet Info,
2000, 2). В то же время, во многих случаях
решения очевидны. Меры противопожарной
безопасности обязательны для всех
организаций. Стоимость реализации
многих мер (например, установка обычного
замка на дверь серверной комнаты) либо
мала, либо хоть и заметна, но все же явно
меньше, чем возможный ущерб. В частности,
имеет смысл регулярно копировать большие
базы данных.

Поддержание
работоспособности

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

Недооценка
факторов безопасности в повседневной
работе — ахиллесова пята многих
организаций. Дорогие средства безопасности
теряют смысл, если они плохо документированы,
конфликтуют с другим программным
обеспечением, а пароль системного
администратора не менялся с момента
установки.

Можно
выделить следующие направления
повседневной деятельности:

• поддержка
  пользователей;

• поддержка
  программного обеспечения;

• конфигурационное
  управление;

• резервное
  копирование;

• управление
  носителями;

• документирование;

• регламентные
  работы.

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

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

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

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

Лучший
способ уменьшить количество ошибок в
рутинной работе — максимально
автоматизировать ее. Правы те «ленивые»
программисты и системные администраторы,
которые, окинув взглядом море однообразных
задач, говорят: «Я ни за что не буду
делать этого; я напишу программу, которая
сделает все за меня». Автоматизация и
безопасность зависят друг от друга;
тот, кто заботится в первую очередь об
облегчении своей задачи, на самом деле
оптимальным образом формирует режим
информационной безопасности.

Резервное
копирование необходимо для восстановления
программ и данных после аварий. И здесь
целесообразно автоматизировать работу,
как минимум, сформировав компьютерное
расписание создания полных и инкрементальных
копий, а как максимум — воспользовавшись
соответствующими программными продуктами
(см., например, Jet Info, 2000, 12). Нужно также
наладить размещение копий в безопасном
месте, защищенном от несанкционированного
доступа, пожаров, протечек, то есть от
всего, что может привести к краже или
повреждению носителей. Целесообразно
иметь несколько экземпляров резервных
копий и часть из них хранить вне территории
организации, защищаясь таким образом
от крупных аварий и аналогичных
инцидентов.

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

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

Документирование
— неотъемлемая часть информационной
безопасности. В виде документов
оформляется почти все — от политики
безопасности до журнала учета носителей.
Важно, чтобы документация была актуальной,
отражала именно текущее состояние дел,
причем в непротиворечивом виде.

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

Регламентные
работы — очень серьезная угроза
безопасности. Сотрудник, осуществляющий
регламентные работы, получает
исключительный доступ к системе, и на
практике очень трудно проконтролировать,
какие именно действия он совершает.
Здесь на первый план выходит степень
доверия к тем, кто выполняет работу.

Реагирование
на нарушения режима безопасности

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

Реакция
на нарушения режима безопасности
преследует три главные цели:

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

• выявление
  нарушителя;

• предупреждение
  повторных нарушений.

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

Важность
быстрой и скоординированной реакции
можно продемонстрировать на следующем
примере. Пусть локальная сеть предприятия
состоит из двух сегментов, администрируемых
разными людьми. Далее, пусть в один из
сегментов был внесен вирус. Почти
наверняка через несколько минут (или,
в крайнем случае, несколько десятков
минут) вирус распространится и на другой
сегмент. Значит, меры нужно принять
немедленно. «Вычищать» вирус необходимо
одновременно в обоих сегментах; в
противном случае сегмент, восстановленный
первым, заразится от другого, а затем
вирус вернется и во второй сегмент.

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

Чтобы
найти нарушителя, нужно заранее выяснить
контактные координаты поставщика
сетевых услуг и договориться с ним о
самой возможности и порядке выполнения
соответствующих действий. Более подробно
данная тема рассматривается в статье
Н. Браунли и Э. Гатмэна «Как реагировать
на нарушения информационной безопасности
(RFC 2350, BCP 21)» (Jet Info, 2000, 5).

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

Необходимо
отслеживать появление новых уязвимых
мест и как можно быстрее ликвидировать
ассоциированные с ними окна опасности.
Кто-то в организации должен курировать
этот процесс, принимать краткосрочные
меры и корректировать программу
безопасности для принятия долгосрочных
мер.

Планирование
восстановительных работ

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

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

Процесс
планирования
восстановительных работ
можно разделить на следующие этапы:

• выявление
  критически важных функций организации,
  установление приоритетов;

• идентификация
  ресурсов, необходимых для выполнения
  критически важных функций;

• определение
  перечня возможных аварий;

• разработка
  стратегии восстановительных работ;

• подготовка
  к реализации выбранной стратегии;

• проверка
  стратегии.

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

Идентифицируя
ресурсы, необходимые для выполнения
критически важных функций, следует
помнить, что многие из них имеют
некомпьютерный характер. На данном
этапе желательно подключать к работе
специалистов разного профиля, способных
в совокупности охватить все аспекты
проблемы. Критичные ресурсы обычно
относятся к одной из следующих категорий:

• персонал;

• информационная
  инфраструктура;

• физическая
  инфраструктура.

Составляя
списки ответственных специалистов,
следует учитывать, что некоторые из них
могут непосредственно пострадать от
аварии (например, от пожара), кто-то может
находиться в состоянии стресса, часть
сотрудников, возможно, будет лишена
возможности попасть на работу (например,
в случае массовых беспорядков). Желательно
иметь некоторый резерв специалистов
или заранее определить каналы, по которым
можно на время привлечь дополнительный
персонал.

Информационная
инфраструктура включает в себя следующие
элементы:

• компьютеры;

• программы
  и данные;

• информационные
  сервисы внешних организаций;

• документацию.

Нужно
подготовиться к тому, что на «запасном
аэродроме», куда организация будет
эвакуирована после аварии, аппаратная
платформа может отличаться от исходной.
Соответственно, следует продумать меры
поддержания совместимости по программам
и данным.

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

Документация
важна хотя бы потому, что не вся информация,
с которой работает организация,
представлена в электронном виде. Скорее
всего, план восстановительных работ
напечатан на бумаге.

К
физической инфраструктуре относятся
здания, инженерные коммуникации, средства
связи, оргтехника и многое другое.
Компьютерная техника не может работать
в плохих условиях, без стабильного
электропитания и т.п.

Анализируя
критичные ресурсы, целесообразно учесть
временной профиль их использования.
Большинство ресурсов требуются постоянно,
но в некоторых нужда может возникать
только в определенные периоды (например,
в конце месяца или года при составлении
отчета).

При
определении перечня возможных аварий
нужно попытаться разработать их сценарии.
Как будут развиваться события? Каковы
могут оказаться масштабы бедствия? Что
произойдет с критичными ресурсами?
Например, смогут ли сотрудники попасть
на работу? Будут ли выведены из строя
компьютеры? Возможны ли случаи саботажа?
Будет ли работать связь? Пострадает ли
здание организации? Можно ли будет найти
и прочитать необходимые бумаги?

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

Стратегия
должна предусматривать не только работу
по временной схеме, но и возвращение к
нормальному функционированию.

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

Избыточность
обеспечивается также мерами резервного
копирования, хранением копий в нескольких
местах, представлением информации в
разных видах (на бумаге и в файлах) и
т.д.

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

Проверка
стратегии производится путем анализа
подготовленного плана, принятых и
намеченных мер.

Основные понятия

К административному уровню информационной безопасности относятся действия общего характера, предпринимаемые руководством организации.

Главная цель мер административного уровня — сформировать программу работ в области информационной безопасности и обеспечить ее выполнение, выделяя необходимые ресурсы и контролируя состояние дел.

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

Политика безопасности строится на основе анализа рисков, которые признаются реальными для информационной системы организации. Когда риски проанализированы и стратегия защиты определена, составляется программа обеспечения информационной безопасности. Под эту программу выделяются ресурсы, назначаются ответственные, определяется порядок контроля выполнения программы и т.п.

Термин «политика безопасности» является не совсем точным переводом английского словосочетания «security policy«, однако в данном случае калька лучше отражает смысл этого понятия, чем лингвистически более верные «правила безопасности». Мы будем иметь в виду не отдельные правила или их наборы (такого рода решения выносятся на процедурный уровень, речь о котором впереди), а стратегию организации в области информационной безопасности. Для выработки стратегии и проведения ее в жизнь нужны, несомненно, политические решения, принимаемые на самом высоком уровне.

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

Такая трактовка, конечно, гораздо шире, чем набор правил разграничения доступа (именно это означал термин «security policy» в «Оранжевой книге» и в построенных на ее основе нормативных документах других стран).

ИС организации и связанные с ней интересы субъектов — это сложная система, для рассмотрения которой необходимо применять объектно-ориентированный подход и понятие уровня детализации. Целесообразно выделить, по крайней мере, три таких уровня, что мы уже делали в примере и сделаем еще раз далее.

Чтобы рассматривать ИС предметно, с использованием актуальных данных, следует составить карту информационной системы. Эта карта, разумеется, должна быть изготовлена в объектно-ориентированном стиле, с возможностью варьировать не только уровень детализации, но и видимые грани объектов. Техническим средством составления, сопровождения и визуализации подобных карт может служить свободно распространяемый каркас какой-либо системы управления.

Политика безопасности

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

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

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

На верхний уровень выносится управление защитными ресурсами и координация использования этих ресурсов, выделение специального персонала для защиты критически важных систем и взаимодействие с другими организациями, обеспечивающими или контролирующими режим безопасности.

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

В политике должны быть определены обязанности должностных лиц по выработке программы безопасности и проведению ее в жизнь. В этом смысле политика безопасности является основой подотчетности персонала.

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

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

Британский стандарт BS 7799:1995 рекомендует включать в документ, характеризующий политику безопасности организации, следующие разделы:

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

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

Политика среднего уровня должна для каждого аспекта освещать следующие темы:

Описание аспекта. Например, если рассмотреть применение пользователями неофициального программного обеспечения, последнее можно определить как ПО, которое не было одобрено и/или закуплено на уровне организации.

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

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

Роли и обязанности. В «политический» документ необходимо включить информацию о должностных лицах, ответственных за реализацию политики безопасности. Например, если для использования неофициального программного обеспечения сотрудникам требуется разрешение руководства, должно быть известно, у кого и как его можно получить. Если неофициальное программное обеспечение использовать нельзя, следует знать, кто следит за выполнением данного правила.

Законопослушность. Политика должна содержать общее описание запрещенных действий и наказаний за них.

Точки контакта. Должно быть известно, куда следует обращаться за разъяснениями, помощью и дополнительной информацией. Обычно «точкой контакта» служит определенное должностное лицо, а не конкретный человек, занимающий в данный момент данный пост.

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

• кто имеет право доступа к объектам, поддерживаемым сервисом?
• при каких условиях можно читать и модифицировать данные?
• как организован удаленный доступ к сервису?

При формулировке целей политики нижнего уровня можно исходить из соображений целостности, доступности и конфиденциальности, но нельзя на этом останавливаться. Ее цели должны быть более конкретными. Например, если речь идет о системе расчета заработной платы, можно поставить цель, чтобы только сотрудникам отдела кадров и бухгалтерии позволялось вводить и модифицировать информацию. В более общем случае цели должны связывать между собой объекты сервиса и действия с ними.

Из целей выводятся правила безопасности, описывающие, кто, что и при каких условиях может делать. Чем подробнее правила, чем более формально они изложены, тем проще поддержать их выполнение программно-техническими средствами. С другой стороны, слишком жесткие правила могут мешать работе пользователей, вероятно, их придется часто пересматривать. Руководству предстоит найти разумный компромисс, когда за приемлемую цену будет обеспечен приемлемый уровень безопасности, а сотрудники не окажутся чрезмерно связаны. Обычно наиболее формально задаются права доступа к объектам ввиду особой важности данного вопроса.

В.А. Галатенко
АО «Инфосистемы Джет», тел.: 972-11-82

---

Критерии оценки надежных компьютерных
систем

Основные понятия
Основные элементы политики безопасности

Классы безопасности

Интерпретация «Критериев» для сетевых
конфигураций

Интерпретация
Новые сервисы безопасности и защитные
механизмы
Оценка надежности сетевой конфигурации
на основе оценки компонентов

Гармонизированные критерии безопасности
информационных технологий

Основные понятия
Функциональность
Гарантированность эффективности

Формальные модели безопасности

Информационная безопасность — основы
практического подхода

Заключение

Литература

---

Изложение следует начать с пояснения понятия информационной безопасности.

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

Таким образом, правильный с методологической точки зрения подход к проблемам информационной безопасности начинается с выявления субъектов и интересов субъектов, связанных с использованием информационных систем. Из этого довольно очевидного положения можно вывести два важных следствия:

1. Трактовка проблем, связанных с информационной безопасностью, для разных
   категорий субъектов может существенно различаться. Для иллюстрации достаточно
   сопоставить режимные военные организации и коммерческие структуры. В данной
   работе информационная безопасность рассматривается с точки зрения наиболее
   массовой- коммерческой категории пользователей.
2. Информационная безопасность не сводится исключительно к защите информации.
   Субъект информационных отношений может пострадать (понести убытки) не только
   от несанкционированного доступа, но и от поломки системы, вызвавшей перерыв
   в обслуживании клиентов. Более того, для многих открытых организаций (например,
   учебных) собственно защита информации стоит по важности отнюдь не на первом
   месте.

На практике важнейшими являются три аспекта информационной безопасности:

• доступность (возможность за разумное время получить требуемую
  информационную услугу);
• целостность (актуальность и непротиворечивость информации, ее
  защищенность от разрушения и несанкционированного изменения);
• конфиденциальность (защита от несанкционированного прочтения).

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

Формирование режима информационной безопасности- проблема комплексная. Меры по ее решению можно подразделить на четыре уровня:

• законодательный (законы, нормативные акты, стандарты и т.п.);
• административный (действия общего характера, предпринимаемые руководством
  организации);
• процедурный (конкретные меры безопасности, имеющие дело с людьми);
• программно-технический (конкретные технические меры).

При формировании режима информационной безопасности следует учитывать современное состояние информационных технологий. Почти все организации ждут от информационных систем, в первую очередь, полезной функциональности. Компьютерные системы покупаются не ради защиты данных, а, наоборот, защита данных строится ради экономически выгодного использования компьютерных систем. Для получения полезной функциональности естественно обратиться к наиболее современным решениям в области информационных технологий. Значит, говоря о защите, следует иметь в виду прежде всего современные аппаратные и программные платформы. Важно учитывать следующие характеристики подобных систем:

• глобальную связанность;
• разнородность корпоративных информационных систем;
• распространение технологии клиент/сервер.

Одним из следствий глобальной связанности является меньшая эффективность мер физической защиты, общее усложнение проблем, связанных с защитой от несанкционированного доступа, необходимость привлечения для их решения новых программно-технических средств, например межсетевых экранов (firewalls).

Разнородность аппаратных и программных платформ требует от изготовителей средств защиты соблюдения определенной технологической дисциплины. Важны не только чисто защитные характеристики, но и возможность встраивания в современные корпоративные информационные системы. Если, например, продукт, предназначенный для криптографической защиты, способен функционировать исключительно на платформе Intel/DOS, то его практическая применимость вызывает серьезные сомнения.

Следствия использования технологии клиент/сервер для информационной безопасности, коротко говоря, состоят в том, что:

• каждый сервис имеет свою трактовку главных аспектов информационной
  безопасности (доступности, целостности, конфиденциальности);
• каждый сервис имеет свою трактовку понятий субъекта и объекта;
• каждый сервис имеет специфические угрозы;
• каждый сервис нужно по-своему администрировать;
• средства безопасности в каждый сервис нужно встраивать по-особому;
• операционная система — просто группа сервисов, она перестает быть главной
  с точки зрения защиты.

Полезно мысленно применить сформулированные положения к двум употребительным сервисам — СУБД и электронной почте. Трактовка понятия целостности для СУБД будет подробно рассматриваться во второй части данной публикации; в общих чертах она общеизвестна. В то же время для электронной почты желательно обеспечить целостность как каждого из пересылаемых писем (неизменность содержимого, а также отправителя и списка получателей), так и всего потока сообщений (защиту от кражи, дублирования и переупорядочивания сообщений). Ясно, что такая трактовка целостности не применима к СУБД.

Далее, и для СУБД, и для электронной почты имеет место такая угроза конфиденциальности, как получение информации путем логического вывода. Но если в случае СУБД логические выводы строятся, в основном, на агрегировании информации, то для электронной почты важнейшим источником выводов служит анализ трафика.

Дальнейшее изложение будет строиться следующим образом. Сначала мы рассмотрим основы классического подхода к информационной безопасности. Имеются в виду «Критерии оценки надежных компьютерных систем» («Оранжевая книга»), Интерпретация «Критериев» для сетевых конфигураций (документ, очень важный с методологической точки зрения, входящий в так называемую «Радужную серию») и Гармонизированные критерии Европейских стран (здесь мы также сосредоточимся на концептуально важных положениях). Затем мы перейдем к рассмотрению практических аспектов защиты современных информационных систем.

Вторая часть публикации будет посвящена исключительно вопросам обеспечения информационной безопасности систем управления базами данных.

Критерии оценки надежных компьютерных систем

Основные понятия

В «Оранжевой книге» [1] надежная система определяется как «система, использующая достаточные аппаратные и программные средства, чтобы обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа».

Степень доверия, или надежность систем, оценивается по двум основным критериям: Политика безопасности -набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь имеет право оперировать с определенными наборами данных. Чем надежнее система, тем строже и многообразнее должна быть политика безопасности. В зависимости от сформулированной политики можно выбирать конкретные механизмы, обеспечивающие безопасность системы. Политика безопасности — это активный компонент защиты, включающий в себя анализ возможных угроз и выбор мер противодействия. Гарантированность — мера доверия, которая может быть оказана архитектуре и реализации системы. Гарантированность может проистекать как из тестирования, так и из проверки (формальной или нет) общего замысла и исполнения системы в целом и ее компонентов. Гарантированность показывает, насколько корректны механизмы, отвечающие за проведение в жизнь политики безопасности. Гарантированность можно считать пассивным компонентом защиты, надзирающим за самими защитниками.

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

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

Вообще говоря, компоненты вне вычислительной базы могут не быть надежными, однако это не должно влиять на безопасность системы в целом. В результате, для оценки надежности компьютерной системы достаточно рассмотреть только ее вычислительную базу, которая, как можно надеяться, достаточно компактна.

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

От монитора обращений требуется выполнение трех свойств: Изолированность. Монитор должен быть защищен от отслеживания своей работы; Полнота. Монитор должен вызываться при каждом обращении, не должно быть способов его обхода; Верифицируемость. Монитор должен быть компактным, чтобы его можно было проанализировать и протестировать, будучи уверенным в полноте тестирования.

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

Границу надежной вычислительной базы называют периметром безопасности. Как уже указывалось, от компонентов, лежащих вне периметра безопасности, вообще говоря, не требуется надежности. С развитием распределенных систем понятию «периметр безопасности» все чаще придают другой смысл, имея в виду границу владений определенной организации. То, что внутри владений, считается надежным, а то, что вне, — нет. Связь между внутренним и внешним мирами осуществляют посредством шлюзовой системы (межсетевого экрана, firewall), которая, по идее, способна противостоять потенциально ненадежному или даже враждебному окружению.

Основные элементы политики безопасности

Согласно «Оранжевой книге», политика безопасности должна включать в себя по крайней мере следующие элементы:

• произвольное управление доступом;
• безопасность повторного использования объектов;
• метки безопасности;
• принудительное управление доступом.

Ниже следует подробное рассмотрение перечисленных элементов.

Произвольное управление доступом

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

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

Очевидно, прямолинейное представление подобной матрицы невозможно (поскольку она очень велика), да и не нужно (поскольку она разрежена, то есть большинство клеток в ней пусты). В операционных системах более компактное представление матрицы доступа основывается или на структурировании совокупности субъектов (владелец/группа/прочие в ОС UNIX), или на механизме списков управления доступом, то есть на представлении матрицы по столбцам, когда для каждого объекта перечисляются субъекты вместе с их правами доступа. За счет использования метасимволов можно компактно описывать группы субъектов, удерживая тем самым размеры списков управления доступом в разумных рамках.

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

Безопасность повторного использования объектов

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

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

Современные интеллектуальные периферийные устройства усложняют обеспечение безопасности повторного использования объектов. Действительно, принтер может буферизовать несколько страниц документа, которые останутся в памяти даже после окончанию печати. Необходимо предпринять специальные меры, чтобы «вытолкнуть» их оттуда.

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

Метки безопасности

Для реализации принудительного управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка субъекта описывает его благонадежность, метка объекта — степень закрытости содержащейся в нем информации.

Согласно «Оранжевой книге», метки безопасности состоят из двух частей: уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:

• совершенно секретно;
• секретно;
• конфиденциально;
• несекретно.

Категории образуют неупорядоченный набор. Их назначение — описать предметную область, к которой относятся данные. В военной области каждая категория может соответствовать, например, определенному виду вооружений. Механизм категорий позволяет разделить информацию «по отсекам», что способствует лучшей защищенности. В следующем пункте мы подробно рассмотрим правила принудительного управления доступом, здесь же отметим, что субъект не может получить доступ к «чужим» категориям, даже если его уровень благонадежности — «совершенно секретно». Специалист по танкам не узнает тактико-технические данные самолетов.

Главная проблема, которую необходимо решать в связи с метками, — это обеспечение их целостности. Во-первых, не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши. Во-вторых, при любых операциях с данными метки должны оставаться правильными. В особенности это относится к экспорту и импорту данных. Например, печатный документ должен открываться заголовком, содержащим текстовое и/или графическое представление метки безопасности. Аналогично, при передаче файла по каналу связи должна передаваться и ассоциированная с ним метка, причем в таком виде, чтобы удаленная система могла ее протрактовать, несмотря на возможные различия в уровнях секретности и наборе категорий.

Метки безопасности, ассоциируемые с субъектами, более подвижны, чем метки объектов. Субъект может в течение сеанса работы с системой изменять свою метку, естественно, не выходя за предопределенные для него рамки. Иными словами, он может сознательно занижать свой уровень благонадежности, чтобы уменьшить вероятность непреднамеренной ошибки. Вообще, принцип минимизации привилегий — весьма разумное средство защиты.

Принудительное управление доступом

Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта.

Субъект может читать информацию из объекта, если уровень секретности субъекта не ниже, чем у объекта, а все категории, перечисленные в метке безопасности объекта, присутствуют в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Смысл сформулированного правила понятен — читать можно только то, что положено.

Субъект может записывать информацию в объект, если метка безопасности объекта доминирует над меткой субъекта. В частности, «конфиденциальный» субъект может писать в секретные файлы, но не может — в несекретные (разумеется, должны также выполняться ограничения на набор категорий). На первый взгляд, подобное ограничение может показаться странным, однако оно вполне разумно. Ни при каких операциях уровень секретности информации не должен понижаться, хотя обратный процесс вполне возможен. Посторонний человек может случайно узнать секретные сведения и сообщить их куда следует, однако лицо, допущенное к работе с секретными документами, не имеет права раскрывать их содержание простому смертному.

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

Принудительное управление доступом реализовано во многих вариантах операционных систем и СУБД, отличающихся повышенными мерами безопасности. В частности, такие варианты существуют для SunOS и СУБД Ingres. Независимо от практического использования принципы принудительного управления являются удобным методологическим базисом для начальной классификации информации и распределения прав доступа. Удобнее мыслить в терминах уровней секретности и категорий, чем заполнять неструктурированную матрицу доступа.

Классы безопасности

«Критерии…» Министерства обороны США открыли путь к ранжированию информационных систем по степени надежности. В «Оранжевой книге» определяется четыре уровня безопасности (надежности) — D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он пуст, и ситуация едва ли когда-нибудь изменится. По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности — C1, C2, B1, B2, B3, A1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, мы, следуя [2], будем выписывать лишь то новое, что присуще данному классу, группируя требования в согласии с предшествующим изложением.

Итак, ниже следуют критерии оценки надежных компьютерных систем.

Требования к политике безопасности

Требования к политике безопасности, проводимой системой, подразделяются в соответствии с основными направлениями политики, предусматриваемыми «Оранжевой книгой».

Произвольное управление доступом:

Класс C1 — надежная вычислительная база должна управлять доступом именованных пользователей к именованным объектам. Механизм управления (права для владельца/группы/прочих, списки управления доступом) должен позволять специфицировать разделение файлов между индивидами и/или группами.

Класс C2 — в дополнение к C1, права доступа должны гранулироваться с точностью до пользователя. Механизм управления должен ограничивать распространение прав доступа — только авторизованный пользователь, например владелец объекта, может предоставлять права доступа другим пользователям. Все объекты должны подвергаться контролю доступа.

Класс B3 — в дополнение к C2, обязательно должны использоваться списки управления доступом с указанием разрешенных режимов. Должна быть возможность явного указания пользователей или их групп, доступ которых к объекту запрещен.

(Примечание. Поскольку классы B1 и B2 не упоминаются, требования к ним в плане добровольного управления доступом те же, что и для C2. Аналогично, требования к классу A1 те же, что и для B3.)

Повторное использование объектов:

Класс C2 — при выделении хранимого объекта из пула ресурсов надежной вычислительной базы необходимо ликвидировать все следы предыдущих использований.

Метки безопасности:

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

Класс B2 — в дополнение к B1, помечаться должны все ресурсы системы, например ПЗУ, прямо или косвенно доступные субъектам.

Целостность меток безопасности:

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

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

Принудительное управление доступом:

Класс B1 — надежная вычислительная база должна обеспечить проведение в жизнь принудительного управления доступом всех субъектов ко всем хранимым объектам. Субъектам и объектам должны быть присвоены метки безопасности, являющиеся комбинацией упорядоченных уровней секретности, а также категорий. Метки являются основой принудительного управления доступом. Надежная вычислительная база должна поддерживать по крайней мере два уровня секретности.

Субъект может читать объект, если его (субъекта) метка безопасности доминирует над меткой безопасности объекта, то есть уровень секретности субъекта не меньше уровня секретности объекта и все категории объекта входят в метку безопасности субъекта.

Субъект может писать в объект, если метка безопасности объекта доминирует над меткой субъекта.

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

Класс B2 — в дополнение к B1, все ресурсы системы (в том числе ПЗУ, устройства ввода/вывода) должны иметь метки безопасности и служить объектами принудительного управления доступом.

Требования к подотчетности

Идентификация и аутентификация:

Класс C1 — пользователи должны идентифицировать себя, прежде чем выполнять какие-либо иные действия, контролируемые надежной вычислительной базой. Для аутентификации должен использоваться какой-либо защитный механизм, например пароли. Аутентификационная информация должна быть защищена от несанкционированного доступа.

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

Класс B1 — в дополнение к C2, надежная вычислительная база должна поддерживать метки безопасности пользователей.

Предоставление надежного пути:

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

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

Аудит:

Класс C2 — надежная вычислительная база должна создавать, поддерживать и защищать журнал регистрационной информации, относящейся к доступу к объектам, контролируемым базой. Должна быть возможность регистрации следующих событий:

• использование механизма идентификации и аутентификации;
• внесение объектов в адресное пространство пользователя, например открытие
  файла, запуск программы;
• удаление объектов;
• действия системных операторов, системных администраторов, администраторов
  безопасности;
• другие события, затрагивающие информационную безопасность.

Каждая регистрационная запись должна включать следующие поля:

• дата и время события;
• идентификатор пользователя;
• тип события;
• результат действия (успех или неудача).

Для событий идентификации/аутентификации регистрируется также идентификатор устройства, например терминала. Для действий с объектами регистрируются имена объектов.

Системный администратор может выбирать набор регистрируемых событий для каждого пользователя.

Класс B1 — в дополнение к C2, должны регистрироваться операции выдачи на печать и ассоциированные внешние представления меток безопасности. При операциях с объектами, помимо имен, регистрируются их метки безопасности. Набор регистрируемых событий может различаться в зависимости от уровня секретности объектов.

Класс B2 — в дополнение к B1, должна быть возможность регистрировать события, связанные с организацией тайных каналов с памятью.

Класс B3 — в дополнение к B2, должна быть возможность регистрации появления или накопления событий, несущих угрозу политике безопасности системы. Администратор безопасности должен немедленно извещаться о попытках нарушения политики безопасности, а система, в случае продолжения попыток, должна пресекать их наименее болезненным способом.

Требования к гарантированности

Операционная гарантированность:

Архитектура системы:

Класс C1 — надежная вычислительная база должна поддерживать область для собственного выполнения, защищенную от внешних воздействий, в частности от изменения команд и/или данных, и от попыток слежения за ходом работы. Ресурсы, контролируемые базой, могут составлять определенное подмножество всех субъектов и объектов системы.

Класс C2 — в дополнение к C1, надежная вычислительная база должна изолировать защищаемые ресурсы в той мере, как это диктуется требованиями контроля доступа и подотчетности.

Класс B1 — в дополнение к C2, надежная вычислительная база должна обеспечивать взаимную изоляцию процессов путем разделения их адресных пространств.

Класс B2 — в дополнение к B1, надежная вычислительная база должна быть внутренне структурирована на хорошо определенные, относительно независимые модули. Надежная вычислительная база должна эффективно использовать имеющееся оборудование для отделения элементов, критически важных с точки зрения защиты, от прочих компонентов системы. Модули базы должны проектироваться с учетом принципа минимизации привилегий. Для защиты логически раздельных хранимых объектов должны использоваться аппаратные средства, например сегментация. Должен быть полностью определен пользовательский интерфейс к надежной вычислительной базе и все элементы базы.

Класс B3 — в дополнение к B2, надежная вычислительная база должна быть спроектирована и структурирована таким образом, чтобы использовать полный и концептуально простой защитный механизм с точно определенной семантикой. Этот механизм должен играть центральную роль во внутренней структуризации надежной вычислительной базы и всей системы. База должна активно использовать разделение по уровням, абстракцию и инкапсуляцию данных. Значительные инженерные усилия должны быть направлены на уменьшение сложности надежной вычислительной базы и на вынесение из нее модулей, не являющихся критически важными с точки зрения защиты.

Целостность системы:

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

Анализ тайных каналов передачи информации:

Класс B2 — системный архитектор должен тщательно проанализировать возможности по организации тайных каналов с памятью и оценить максимальную пропускную способность каждого выявленного канала.

Класс B3 — в дополнение к B2, аналогичная процедура должна быть проделана для временных каналов.

Класс A1 — в дополнение к B3, для анализа должны использоваться формальные методы.

Надежное администрирование:

Класс B2 — система должна поддерживать разделение функций оператора и администратора.

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

Надежное восстановление:

Класс B3 — должны существовать процедуры и/или механизмы, позволяющие произвести восстановление после сбоя или иного нарушения работы без ослабления защиты.

Технологическая гарантированность:

Тестирование:

Класс C1 — защитные механизмы должны быть протестированы на предмет соответствия их поведения системной документации. Тестирование должно подтвердить, что у неавторизованного пользователя нет очевидных способов обойти или разрушить средства защиты надежной вычислительной базы.

Класс C2 — в дополнение к C1, тестирование должно подтвердить отсутствие очевидных недостатков в механизмах изоляции ресурсов и защиты регистрационной информации.

Класс B1 — в дополнение к C2, группа специалистов, полностью понимающих конкретную реализацию надежной вычислительной базы, должна подвергнуть описание архитектуры, исходные и объектные коды тщательному анализу и тестированию. Цель должна состоять в выявлении всех дефектов архитектуры и реализации, позволяющих субъекту без должной авторизации читать, изменять, удалять информацию или приводить базу в состояние, когда она перестает обслуживать запросы других субъектов. Все выявленные недостатки должны быть исправлены или нейтрализованы, после чего база подвергается повторному тестированию, чтобы убедиться в отсутствии прежних или приобретении новых недостатков.

Класс B2 — в дополнение к B1, должна быть продемонстрирована относительная устойчивость надежной вычислительной базы к попыткам проникновения.

Класс B3 — в дополнение к B2, должна быть продемонстрирована устойчивость надежной вычислительной базы к попыткам проникновения.

Не должно быть выявлено архитектурных недостатков. Допускается выявление лишь небольшого числа исправимых недостатков реализации. Должна существовать обоснованная уверенность, что немногие недостатки остались невыявленными.

Класс A1 — в дополнение к B3, тестирование должно продемонстрировать, что реализация надежной вычислительной базы соответствует формальным спецификациям верхнего уровня.

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

Верификация спецификаций архитектуры:

Класс B1 — должна существовать неформальная или формальная модель политики безопасности, поддерживаемой надежной вычислительной базой. Модель должна соответствовать основным посылкам политики безопасности на протяжении всего жизненного цикла системы.

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

Класс B3 — в дополнение к B2, должны быть приведены убедительные аргументы соответствия между спецификациями и моделью.

Класс A1 — в дополнение к B3, помимо описательных должны быть представлены формальные спецификации верхнего уровня, относящиеся к аппаратным и/или микропрограммным элементам, составляющим интерфейс надежной вычислительной базы. Комбинация формальных и неформальных методов должна подтвердить соответствие между спецификациями и моделью. Должны использоваться современные методы формальной спецификации и верификации систем, доступные Национальному центру компьютерной безопасности США. Ручное или иное отображение формальных спецификаций на исходные тексты должно подтвердить корректность реализации надежной вычислительной базы.

Конфигурационное управление:

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

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

Надежное распространение:

Класс A1 — должна поддерживаться целостность соответствия между эталонными данными, описывающими текущую версию вычислительной базы, и эталонной копией текстов этой версии. Должны существовать процедуры, подтверждающие соответствие между поставляемыми клиентам аппаратными и программными компонентами и эталонной копией.

Требования к документации

Руководство пользователя по средствам безопасности:

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

Руководство администратора по средствам безопасности:

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

Класс C2 — в дополнение к C1, должны описываться процедуры обработки регистрационной информации и управления файлами с такой информацией, а также структура записей для каждого типа регистрируемых событий.

Класс B1 — в дополнение к C2, руководство должно описывать функции оператора и администратора, затрагивающие безопасность, в том числе действия по изменению характеристик пользователей. Должны быть представлены рекомендации по согласованному и эффективному использованию средств безопасности, их взаимодействию друг с другом, по безопасной генерации новых версий надежной вычислительной базы.

Класс B2 — в дополнение к B1, должны быть указаны модули надежной вычислительной базы, содержащие механизмы проверки обращений. Должна быть описана процедура безопасной генерации новой версии базы после внесения изменений в исходные тексты.

Класс B3 — в дополнение к B2, должна быть описана процедура, обеспечивающая безопасность начального запуска системы и возобновления ее работы после сбоя.

Тестовая документация:

Класс C1 — разработчик системы должен представить экспертному совету документ, содержащий план тестов, процедуры прогона тестов и результаты тестов.

Класс B2 — в дополнение к C1, тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации.

Класс A1 — в дополнение к B2, должно быть описано соответствие между формальными спецификациями верхнего уровня и исходными текстами.

Описание архитектуры:

Класс C1 — должны быть описаны подход к безопасности, используемый производителем, и применение этого подхода при реализации надежной вычислительной базы. Если база состоит из нескольких модулей, должен быть описан интерфейс между ними.

Класс B1 — в дополнение к C1, должно быть представлено неформальное или формальное описание модели политики безопасности, проводимой в жизнь надежной вычислительной базой. Необходимо наличие аргументов в пользу достаточности избранной модели для реализации политики безопасности. Должны быть описаны защитные механизмы базы и их место в модели.

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

Класс B3 — в дополнение к B2, должно быть неформально продемонстрировано соответствие между описательными спецификациями верхнего уровня и реализацией надежной вычислительной базы.

Класс A1 — в дополнение к B3, должно быть неформально продемонстрировано соответствие между формальными спецификациями верхнего уровня и реализацией надежной вычислительной базы.

Таковы, согласно «Оранжевой книге», требования к классам безопасности информационных систем.

Интерпретация «Критериев» для сетевых конфигураций

В 1987 году Национальный центр компьютерной безопасности США выпустил в свет интерпретацию «Оранжевой книги» для сетевых конфигураций [3]. Данный документ состоит из двух частей. Первая содержит собственно интерпретацию, во второй рассматриваются сервисы безопасности, специфичные или особенно важные для сетевых конфигураций.

Интерпретация

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

Не существует прямой зависимости между вычислительными базами компонентов, рассматриваемых как изолированные системы, и фрагментами сетевой вычислительной базы. Более того, нет прямой зависимости и между уровнями безопасности отдельных компонентов и уровнем безопасности всей сетевой конфигурации. Например, в результате объединения двух систем класса B1, обладающих несовместимыми правилами кодирования меток безопасности, получается сеть, не удовлетворяющая требованию обеспечения целостности меток. В качестве противоположного примера рассмотрим объединение двух компонентов, один из которых сам не обеспечивает протоколирование действий пользователя, но передает необходимую информацию другому компоненту, который и ведет протокол. В таком случае сеть в целом, несмотря на слабость компонента, удовлетворяет требованию подотчетности.

Чтобы понять суть положений, вошедших в первую часть, рассмотрим интерпретацию требований к классу безопасности C2. Первое требование к этому классу — поддержка произвольного управления доступом. Интерпретация предусматривает различные варианты распределения сетевой надежной вычислительной базы по компонентам и, соответственно, различные варианты распределения механизмов управления доступом. В частности, некоторые компоненты, закрытые от прямого доступа пользователей (например, коммутаторы пакетов, оперирующие на третьем уровне семиуровневой модели OSI) могут вообще не содержать подобных механизмов.

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

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

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

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

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

Регистрационная информация в сетевом случае может включать в себя записи новых видов, например: сведения об установлении и разрыве соединений, о потенциальном нарушении целостности данных (ввиду неправильной маршрутизации датаграмм в том числе), об изменениях в конфигурации сети. «Адресное пространство пользователей» становится распределенным, а в число регистрируемых событий попадают действия с удаленными объектами (открытие, переименование и т.п.).

При ведении регистрационного журнала могут использоваться локальные или глобальные синхронизированные часы.

Регистрационные журналы разных компонентов сети должны быть согласованы между собой; должны предоставляться средства для комплексного анализа совокупности регистрационных журналов с целью глобального отслеживания деятельности пользователей.

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

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

Интерпретация отличается от самих «Критериев» учетом динамичности сетевых конфигураций. Предусматривается наличие средств проверки подлинности и корректности функционирования компонентов перед их включением в сеть, наличие протокола взаимной проверки компонентами живучести и корректности функционирования друг друга, доступность средств оповещения администратора о неполадках в сети. Сетевая конфигурация должна быть устойчива к отказам отдельных компонентов или коммуникационных путей.

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

В качестве еще одного отличительного момента Интерпретации отметим повышенное внимание к целостности информации вообще и меток безопасности в частности (мы переходим к рассмотрению некоторых аспектов принудительного управления доступом, характерного для уровня безопасности B). Для контроля целостности меток и для их защиты от нелегального изменения в Интерпретации рекомендуется широкое использование криптографических методов. Далее, чтобы принудительное управление доступом в распределенной конфигурации имело смысл, совокупность уровней секретности и категорий должна поддерживаться централизованно. В этом одно из принципиальных отличий от произвольного управления доступом.

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

Новые сервисы безопасности и защитные механизмы

Рассматриваемый документ создавался примерно в то же время, что и рекомендации X.800. Естественно, что две рабочие группы обменивались информацией, поэтому во многих отношениях их подходы схожи. Имеются, однако, и важные различия. Интерпретация не замыкается на эталонной семиуровневой модели, ее цель — оценка безопасности всей распределенной конфигурации, а не только чисто сетевых аспектов. Рекомендации X.800 в основном имеют дело с функциональностью (с сервисами безопасности) и в меньшей степени с защитными механизмами. В части 2 Интерпретации анализируется еще одна важнейшая характеристика — гарантированность.

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

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

Новым по сравнению с рекомендациями X.800 является рассмотрение вопросов доступности. Сетевой сервис перестает быть доступным, когда пропускная способность коммуникационных каналов падает ниже минимально допустимого уровня или сервис не в состоянии обслуживать запросы. Удаленный ресурс может стать недоступным и вследствие нарушения равноправия в обслуживании пользователей. Надежная система должна быть в состоянии обнаруживать ситуации недоступности, уметь возвращаться к нормальной работе и противостоять атакам на доступность.

Для обеспечения непрерывности функционирования могут применяться следующие защитные меры:

• внесение в конфигурацию той или иной формы избыточности (резервное
  оборудование, запасные каналы связи и т.п.);
• наличие средств реконфигурирования для изоляции и/или замены узлов
  или коммуникационных каналов, отказавших или подвергшихся атаке на доступность;
• рассредоточенность сетевого управления, отсутствие единой точки отказа;
• наличие средств нейтрализации отказов (обнаружение отказавших компонентов,
  оценка последствий, восстановление после отказов);
• выделение подсетей и изоляция групп пользователей друг от друга.

Многие из этих мер реализованы в современных кластерных конфигурациях серверов баз данных.

С точки зрения оценки надежности систем, критерии части 2 дополняют «Оранжевую книгу». Каждый сервис безопасности рассматривается независимо и может получить одну из трех положительных оценок. Таким образом, общая оценка сетевой конфигурации выглядит примерно так: класс безопасности C2, сервис_1 — удовлетворительно, сервис_2 — хорошо и т.д. Заказчик, зная свои потребности, в состоянии принять решение о пригодности той или иной конфигурации.

Оценка надежности сетевой конфигурации на основе оценки компонентов

В части 1 Интерпретации излагается подход к оценке надежности сетевой конфигурации как единого целого. В то же время имеет право на существование и другой подход, когда сеть составляется из предварительно проверенных компонентов, а общая оценка по определенным правилам выводится из их «рейтинга». Подобная точка зрения является предметом рассмотрения приложений к Интерпретации, где анализируются три главных вопроса:

Как следует структурировать сеть, чтобы оценка компонентов помогала получить общую оценку?

Какие критерии следует применять к компонентам?

Как получать общую оценку?

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

· произвольное управление доступом;

· принудительное управление доступом;

· идентификация и аутентификация;

· протоколирование и аудит.

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

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

Истинность этого утверждения непосредственно следует из определения монитора обращений.

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

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

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

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

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

Гармонизированные критерии безопасности информационных технологий

Следуя по пути интеграции, европейские страны приняли согласованные критерии оценки безопасности информационных технологий (Information Technology Security Evaluation Criteria, ITSEC) [4]. Наше изложение основывается на версии 1.2 этих Критериев, опубликованной в июне 1991 года от имени соответствующих органов четырех стран — Франции, Германии, Нидерландов и Великобритании.

Принципиально важной чертой Европейских Критериев является отсутствие априорных требований к условиям, в которых должна работать информационная система. (Напомним, что в «Критериях» Министерства обороны США очевидна привязка к условиям правительственной системы, обрабатывающей секретную информацию.) Так называемый спонсор, то есть организация, запрашивающая сертификационные услуги, формулирует цель оценки, то есть описывает условия, в которых должна работать система, возможные угрозы ее безопасности и предоставляемые ею защитные функции. Задача органа сертификации — оценить, насколько полно достигаются поставленные цели, то есть насколько корректны и эффективны архитектура и реализация механизмов безопасности в описанных спонсором условиях. Таким образом, в терминологии «Оранжевой книги» Европейские Критерии относятся к гарантированности безопасной работы системы. Требования к политике безопасности и к наличию защитных механизмов не являются составной частью Критериев. Впрочем, чтобы облегчить формулировку цели оценки, Критерии содержат в качестве приложения описание десяти примерных классов функциональности, типичных для правительственных и коммерческих систем.

Основные понятия

Европейские Критерии рассматривают следующие составляющие информационной безопасности:

• конфиденциальность, то есть защиту от несанкционированного получения
  информации;
• целостность, то есть защиту от несанкционированного изменения информации;
• доступность, то есть защиту от несанкционированного удержания информации
  и ресурсов.

В Критериях проводится различие между системами и продуктами. Система — это конкретная аппаратно-программная конфигурация, построенная с вполне определенными целями и функционирующая в известном окружении. Продукт — это аппаратно-программный «пакет», который можно купить и по своему усмотрению встроить в ту или иную систему. Таким образом, с точки зрения информационной безопасности основное отличие между системой и продуктом состоит в том, что система имеет конкретное окружение, которое можно определить и изучить сколь угодно детально, а продукт должен быть рассчитан на использование в различных условиях. Угрозы безопасности системы носят вполне конкретный и реальный характер. Относительно угроз продукту можно лишь строить предположения. Разработчик может специфицировать условия, пригодные для функционирования продукта; дело покупателя обеспечить выполнение этих условий.

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

Каждая система и/или продукт предъявляет свои требования к обеспечению конфиденциальности, целостности и доступности. Чтобы удовлетворить эти требования, необходимо предоставить соответствующий набор функций (сервисов) безопасности, таких как идентификация и аутентификация, управление доступом или восстановление после сбоев.

Сервисы безопасности реализуются посредством конкретных механизмов. Например, для реализации функции идентификации и аутентификации можно использовать такой механизм, как сервер аутентификации Kerberos.

Чтобы объект оценки можно было признать надежным, необходима определенная степень уверенности в наборе функций и механизмов безопасности. Степень уверенности мы будем называть гарантированностью. Гарантированность может быть большей или меньшей в зависимости от тщательности проведения оценки.

Гарантированность затрагивает два аспекта — эффективность и корректность средств безопасности. При проверке эффективности анализируется соответствие между целями, сформулированными для объекта оценки, и имеющимся набором функций безопасности. Точнее говоря, рассматриваются вопросы адекватности функциональности, взаимной согласованности функций, простоты их использования, а также возможные последствия эксплуатации известных слабых мест защиты. Кроме того, в понятие эффективности входит способность механизмов защиты противостоять прямым атакам (мощность механизма). Определяется три градации мощности — базовая, средняя и высокая.

Под корректностью понимается правильность реализации функций и механизмов безопасности. В Критериях определяется семь возможных уровней гарантированности корректности — от E0 до E6 (в порядке возрастания). Уровень E0 обозначает отсутствие гарантированности (аналог уровня D «Оранжевой книги»). При проверке корректности анализируется весь жизненный цикл объекта оценки — от проектирования до эксплуатации и сопровождения.

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

Функциональность

В Европейских Критериях средства, имеющие отношение к информационной безопасности, рассматриваются на трех уровнях детализации. Наиболее абстрактный взгляд касается лишь целей безопасности. На этом уровне мы получаем ответ на вопрос, зачем нужны функции безопасности. Второй уровень содержит спецификации функций безопасности. Мы узнаем, какая функциональность на самом деле обеспечивается. Наконец, на третьем уровне содержится информация о механизмах безопасности. Мы видим, как реализуется декларированная функциональность.

Спецификации функций безопасности — важнейшая часть описания объекта оценки. Критерии рекомендуют выделить в этих спецификациях разделы со следующими заголовками:

• идентификация и аутентификация;
• управление доступом;
• подотчетность;
• аудит;
• повторное использование объектов;
• точность информации;
• надежность обслуживания;
• обмен данными.

Большинство из перечисленных тем мы рассматривали при анализе «Оранжевой книги». Здесь мы остановимся лишь на моментах, специфичных для Европейских Критериев.

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

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

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

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

К области обмена данными относятся функции, обеспечивающие коммуникационную безопасность, то есть безопасность данных, передаваемых по каналам связи. Здесь Европейские Критерии предлагают следующие подзаголовки:

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

Набор функций безопасности может специфицироваться с использованием ссылок на заранее определенные классы функциональности. В Европейских Критериях таких классов десять. Пять из них (F-C1, F-C2, F-B1, F-B2, F-B3) соответствуют классам безопасности «Оранжевой книги».

Класс F-IN предназначается для объектов оценки с высокими потребностями по обеспечению целостности данных и программ, что типично для систем управления базами данных. При описании класса F-IN вводится понятие роли, выдвигается требование по предоставлению доступа к определенным объектам только с помощью предопределенных процессов. Должны различаться следующие виды доступа: чтение, запись, добавление, удаление, переименование (для всех объектов), выполнение, удаление, переименование (для выполняемых объектов), создание и удаление объектов.

Класс F-AV характеризуется повышенными требованиями к доступности. Это существенно, например, для систем управления технологическими процессами. В разделе «Надежность обслуживания» описания этого класса специфицируется, что объект оценки должен восстанавливаться после отказа отдельного аппаратного компонента таким образом, чтобы все критически важные функции оставались постоянно доступными. То же должно быть верно для вставки отремонтированного компонента, причем после этого объект оценки возвращается в состояние, устойчивое к одиночным отказам. Независимо от уровня загрузки должно гарантироваться время реакции на определенные события и отсутствие тупиков.

Класс F-DI характеризуется повышенными требованиями к целостности передаваемых данных. Перед началом общения стороны должны быть в состоянии проверить подлинность друг друга. При получении данных должна предоставляться возможность проверки подлинности источника. При обмене данными должны предоставляться средства контроля ошибок и их исправления. В частности, должны обнаруживаться все повреждения или намеренные искажения адресной и пользовательской информации. Знание алгоритма обнаружения искажений не должно давать возможность производить нелегальную модификацию. Должны обнаруживаться и трактоваться как ошибки попытки воспроизведения ранее переданных сообщений.

Класс F-DC характеризуется повышенными требованиями к конфиденциальности передаваемой информации. Перед поступлением данных в каналы связи должно автоматически выполняться шифрование с использованием сертифицированных средств. На приемном конце также автоматически производится расшифровка. Ключи шифрования должны быть защищены от несанкционированного доступа.

Класс F-DX характеризуется повышенными требованиями и к целостности, и к конфиденциальности информации. Его можно рассматривать как объединение классов F-DI и F-DC с дополнительными возможностями шифрования, действующими из конца в конец, и с защитой от анализа трафика по определенным каналам. Должен быть ограничен доступ к ранее переданной информации, которая в принципе может способствовать нелегальной расшифровке.

Гарантированность эффективности

Для получения гарантий эффективности средств безопасности рассматриваются следующие вопросы:

• соответствие набора функций безопасности провозглашенным целям, то
  есть их пригодность для противодействия угрозам, перечисленным в описании
  объекта оценки;
• взаимная согласованность различных функций и механизмов безопасности;
• способность механизмов безопасности противостоять прямым атакам;
• возможность практического использования слабостей в архитектуре объекта
  оценки, то есть наличие способов отключения, обхода, повреждения и обмана
  функций безопасности;
• возможность небезопасного конфигурирования или использования объекта
  оценки при условии, что администраторы и/или пользователи имеют основание
  считать ситуацию безопасной;
• возможность практического использования слабостей в функционировании
  объекта оценки.

Важнейшей частью проверки эффективности является анализ слабых мест в защите объекта оценки. Цель анализа — найти все возможности отключения, обхода, повреждения, обмана средств защиты. Оценивается также способность всех критически важных защитных механизмов противостоять прямым атакам — мощность механизмов. Защищенность системы или продукта не может быть выше мощности самого слабого из критически важных механизмов, поэтому в Критериях имеется в виду минимальная гарантированная мощность. Для нее определены три уровня — базовый, средний и высокий.

Согласно Критериям, мощность можно считать базовой, если механизм способен противостоять отдельным случайным атакам.

Мощность можно считать средней, если механизм способен противостоять злоумышленникам с ограниченными ресурсами и возможностями.

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

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

Эффективность защиты признается неудовлетворительной, если выявляются слабые места, допускающие практическое использование, и эти слабости не исправляются до окончания процесса оценки. В таком случае объекту присваивается уровень гарантированности E0.

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

Формальные модели безопасности

Теоретическим базисом работ в области информационной безопасности являются формальные модели, предоставляющие принципиальную возможность построения систем с доказуемой безопасностью. В работе [5] рассматривается более десяти подобных моделей. Мы остановимся на одной из них, предложенной Дионом. Причина нашего выбора состоит в том, что модель Диона является весьма представительной, трактующей как вопросы конфиденциальности, так и вопросы целостности информации.

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

• абсолютная метка конфиденциальности (ACL) присваивается субъекту
  во время создания и остается постоянной во все время его существования.
  Обычно в качестве ACL используется метка пользователя-инициатора процесса;
• метка конфиденциальности чтения (RCL) — максимальный (в смысле
  отношения доминирования меток) уровень конфиденциальности, с которого субъекту
  разрешено читать информацию;
• метка конфиденциальности записи (WCL) — минимальный уровень
  конфиденциальности, на который субъекту разрешено записывать информацию;
• абсолютная метка целостности (AIL);
• метка целостности чтения (RIL) — минимальный уровень целостности, с
  которого субъекту разрешено читать информацию;
• метка целостности записи (WIL) — максимальный уровень целостности,
  на который субъекту разрешено записывать информацию.

Для каждого субъекта s должны выполняться следующие соотношения:

WCL(s) <= ACL(s) <= RCL(s)
RIL(s) <= AIL(s) <= WIL(s)

(запись L1 <= L2 обозначает доминирование метки L2 над L1).

Будем говорить, что метка безопасности L2 строго доминирует над меткой L1 (обозначается L1 < L2), если уровень безопасности L2 строго больше, чем у L1, а набор категорий L1 является собственным подмножеством набора L2.

Субъект, для которого хотя бы одно из записанных выше четырех неравенств является строгим, называется надежным (в противном случае — ненадежным).

Под объектом в модели Диона понимается любой элемент, способный хранить данные. С каждым объектом ассоциируются по три метки конфиденциальности и целостности:

• абсолютная метка конфиденциальности (ACL) присваивается объекту
  во время создания и остается постоянной на все время его существования.
  Характеризует конфиденциальность данных, хранящихся в объекте;
• метка конфиденциальности чтения из объекта (RCL) — максимальный
  уровень конфиденциальности, на который могут мигрировать данные, хранящиеся
  в объекте;
• метка конфиденциальности записи в объект (WCL) — минимальный
  уровень конфиденциальности, с которого данные могут записываться в объект;
• абсолютная метка целостности (AIL);
• метка целостности чтения из объекта (RIL) — минимальный уровень
  целостности, на который могут мигрировать данные, хранящиеся в объекте;
• метка целостности записи в объект (WIL) — максимальный уровень
  целостности, с которого данные могут записываться в объект.

Для каждого объекта o должны выполняться следующие соотношения:

WCL(o) <= ACL(o) <= RCL(o)
RIL(o) <= AIL(o) <= WIL(o)

Модель Диона предусматривает возможность передачи информации путем организации однонаправленных каналов между объектами. Субъект s может организовать канал передачи информации из объекта o1 в объект o2, если выполняются следующие соотношения:

ACL(o1) <= RCL(s)
RIL(s) <= AIL(o1)
WCL(s) <= ACL(o2)
AIL(o2) <= WIL(s)

(субъект должен иметь право на чтение из объекта o1 и на запись в объект o2)

RCL(o2) <= RCL(o1)
RIL(o1) <= RIL(o2)
WCL(o2) <= WCL(o1)
WIL(o1) <= WIL(o2)

(эти соотношения гарантируют, что ограничения на метки чтения/записи не могут быть нарушены при посредничестве «третьих» объектов)

ACL(s) <= RCL(o1)
RIL(o1) <= AIL(s)
WCL(o2) <= ACL(s)
AIL(s) <= WIL(o2)

(субъекты не должны нарушать ограничения на метки чтения/записи).

Модель Диона обобщает более известные модели безопасности (Bell-LaPadula и Biba). В частности, из приведенных аксиом следует, что ненадежные субъекты (WCL(s) = ACL(s) = RCL(s)) не могут переместить информацию в объект с меньшим уровнем конфиденциальности и/или более высоким уровнем целостности (см. также п. 2.2.4).

Информационная безопасность — основы практического подхода

Стандарты и рекомендации, рассмотренные выше, образуют понятийный базис, на котором строятся все работы по обеспечению информационной безопасности. В то же время эти документы ориентированы в первую очередь на производителей и «оценщиков» систем и в гораздо меньшей степени — на потребителей (пользователей).

Стандарты и рекомендации статичны, причем статичны, по крайней мере, в двух аспектах. Во-первых, они не учитывают постоянной перестройки защищаемых систем и их окружения. Во-вторых, они не содержат практических рекомендаций по формированию режима безопасности. Информационную безопасность нельзя купить, ее приходится каждодневно поддерживать, взаимодействуя при этом не только и не столько с компьютерами, сколько с людьми.

Таким образом, стандарты и рекомендации не дают ответов на два главных, с практической точки зрения, вопроса:

как приобретать (комплектовать) информационную систему масштаба предприятия, чтобы ее можно было сделать безопасной?

как практически сформировать режим безопасности и поддерживать его в условиях постоянно меняющегося окружения и структуры самой системы?

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

Во введении отмечался комплексный характер проблемы обеспечения безопасности, необходимость сочетания законодательных, организационных и программно-технических мер. К сожалению, законодательная база отстает от потребностей практики. Имеющиеся в России законы и указы [6, 7] носят в основном запретительный характер. В то же время следует учитывать, что в нашей стране доминирует зарубежное аппаратно-программное обеспечение. В условиях ограничений на импорт [7] и отсутствия межгосударственных соглашений о взаимном признании сертификатов потребители, желающие быть абсолютно законопослушными, оказываются по существу в безвыходном положении — у них нет возможности заказать (и получить) современную систему «под ключ» и с сертификатом безопасности.

Следующим после законодательного можно назвать управленческий уровень. Руководство каждой организации должно осознать необходимость поддержания режима безопасности и выделения на эти цели значительных ресурсов. Главное, что должен сделать управленческий уровень, — это выработать политику безопасности, которая задает общее направление работам в данной области. Важный момент при выработке политики безопасности — анализ угроз и выбор адекватных мер противодействия.

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

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

• идентификация и аутентификация;
• управление доступом;
• протоколирование и аудит;
• криптография;
• экранирование.

Важнейшим моментом практического подхода к информационной безопасности является применение идеологии клиент/сервер.

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

Как правило, заказчик хочет получить определенный набор сервисов. Назовем их основными. Например, если заказчиком является банк, то в качестве основных сервисов могут выступать банковская система, система автоматизации офиса, бухгалтерская система самого банка и т.п.

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

И основные, и вспомогательные сервисы, как правило, могут быть подвергнуты декомпозиции. Так, банковская система состоит из ряда аппаратно-программных подсистем (валютный опердень, рабочее место операциониста и т.п.). Каждую из таких подсистем можно рассматривать как относительно самостоятельный сервис. Сервисы, декомпозиция которых нецелесообразна, мы будем называть атомарными.

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

В защите нуждаются все сервисы (в том числе вспомогательные) и коммуникационные пути между ними. В то же время, возможно, не все запланированные атомарные сервисы обладают полным набором механизмов безопасности. Интерпретация «Оранжевой книги» для сетевых конфигураций подсказывает правила, по которым следует объединять сервисы. Идея их проста — нужно формировать составные сервисы, обладающие полным набором механизмов безопасности и, с внешней точки зрения, представляющие собой единое целое (нет информационных потоков, идущих к незащищенным компонентам). Приведенное ранее Утверждение 1 гарантирует, что совокупность подобных составных сервисов, соединенных защищенными коммуникационными путями, является надежной системой. Подчеркнем, что здесь важна полнота функциональности каждого компонента, и это является теоретическим обоснованием предлагаемой нами методологии анализа безопасности информационных систем.

Вполне возможно, что из сервисов, выбранных на первом этапе, не удается составить надежной конфигурации. Наиболее распространенной причиной тому, вероятно, может оказаться отсутствие механизмов безопасности в операционных системах класса MS-DOS. В таком случае необходимо привлечение дополнительных сервисов, которые мы будем называть экранирующими. Экранирующие сервисы могут не обладать полезной функциональностью; они нужны лишь для формирования защищенных составных сервисов. Примеры экранирующих сервисов — сервер аутентификации Kerberos и межсетевые экраны (firewalls), защищающие сети организаций от враждебного окружения.

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

Выбор подхода клиент/сервер как основы структурирования информационных систем при рассмотрении программно-технических мер безопасности целесообразен еще и потому, что для каждого сервиса основные цели (конфиденциальность, целостность, доступность) трактуются по-своему. Целостность, с точки зрения системы управления базами данных и с точки зрения почтового сервера, — вещи принципиально разные. Бессмысленно говорить о безопасности локальной или иной сети вообще, если сеть включает в себя разнородные компоненты. Следует анализировать защищенность сервисов, функционирующих в сети. Часто для разных сервисов и защиту строят по-разному. Например, обычно межсетевые экраны свободно пропускают через себя почтовый трафик (почта — относительно безобидный сервис), но контролируют попытки доступа к другим, более мощным или более уязвимым сервисам.

Заключение

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

Литература

1. Department of Defense Trusted Computer System Evaliation Criteria.
   — DoD 5200.28-STD, 1993.
2. Russel D., Gangemi G.T. Sr. Computer Security Basics. — O»Reilly &
   Associates, Inc., 1992.
3. National Computer Security Center. Trusted Network Interpretation.
   — NCSC-TG-005, 1987.
4. Information Technology Security Evaluation Criteria (ITSEC). Harmonised
   Criteria of France — Germany — the Netherlands — the United Kingdom. —
   Department of Trade and Industry, London, 1991.
5. Castano S., Fugini M., Martella G., Samarati P. Database Security.
   — Addison-Wesley, 1995.
6. Федеральный Закон «Об информации, информатизации и защите информации».
   — «Российская газета», 22 февраля, 1995.
7. Президент Российской Федерации. Указ от 3 апреля 1995 г. номер 334
   «О мерах по соблюдению законности в области разработки, производства, реализации
   и эксплуатации шифровальных средств, а также предоставления услуг в области
   шифрования информации».

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

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

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

На практике важнейшими являются три аспекта информационной безопасности:

доступность (возможность за разумное время получить требуемую информационную услугу);

целостность (актуальность и непротиворечивость информации, ее защищенность от разрушения и несанкционированного изменения);

конфиденциальность (защита от несанкционированного прочтения).

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

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

аппаратные средства — компьютеры и их составные части (процессоры, мониторы, терминалы, периферийные устройства — дисководы, принтеры, контроллеры, кабели, линии связи и т.д.);

программное обеспечение — приобретенные программы, исходные, объектные, загрузочные модули; операционные системы и системные программы (компиляторы, компоновщики и др.), утилиты, диагностические программы и т.д.;

данные — хранимые временно и постоянно, на магнитных носителях, печатные, архивы, системные журналы и т.д.;

персонал — обслуживающий персонал и пользователи.

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

аварийные ситуации из-за стихийных бедствий и отключений электропитания;

отказы и сбои аппаратуры;

ошибки в программном обеспечении;

ошибки в работе персонала;

помехи в линиях связи из-за воздействий внешней среды.

Преднамеренные воздействия — это целенаправленные действия нарушителя. В качестве нарушителя могут выступать служащий, посетитель, конкурент, наемник. Действия нарушителя могут быть обусловлены разными мотивами:

недовольством служащего своей карьерой;

взяткой;

любопытством;

конкурентной борьбой;

стремлением самоутвердиться любой ценой.

Можно составить гипотетическую модель потенциального нарушителя:

квалификация нарушителя на уровне разработчика данной системы;

нарушителем может быть как постороннее лицо, так и законный пользователь системы;

нарушителю известна информация о принципах работы системы;

нарушитель выбирает наиболее слабое звено в защите.

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

Проведем классификацию каналов НСД, по которым можно осуществить хищение, изменение или уничтожение информации:

Через человека:

хищение носителей информации;

чтение информации с экрана или клавиатуры;

чтение информации из распечатки.

Через программу:

перехват паролей;

дешифровка зашифрованной информации;

копирование информации с носителя.

Через аппаратуру:

подключение специально разработанных аппаратных средств, обеспечивающих доступ к информации;

перехват побочных электромагнитных излучений от аппаратуры, линий связи, сетей электропитания и т.д.

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

Обеспечение информационной безопасности

Формирование режима информационной безопасности — проблема комплексная. Меры по ее решению можно подразделить на пять уровней:

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

Единая совокупность всех этих мер, направленных на противодействие угрозам безопасности с целью сведения к минимуму возможности ущерба, образуют систему защиты.

Надежная система защиты должна соответствовать следующим принципам:

Стоимость средств защиты должна быть меньше, чем размеры возможного ущерба.

Каждый пользователь должен иметь минимальный набор привилегий, необходимый для работы.

Защита тем более эффективна, чем проще пользователю с ней работать.

Возможность отключения в экстренных случаях.

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

Под защитой должна находиться вся система обработки информации.

Разработчики системы защиты, не должны быть в числе тех, кого эта система будет контролировать.

Система защиты должна предоставлять доказательства корректности своей работы.

Лица, занимающиеся обеспечением информационной безопасности, должны нести личную ответственность.

Объекты защиты целесообразно разделять на группы так, чтобы нарушение защиты в одной из групп не влияло на безопасность других.

Надежная система защиты должна быть полностью протестирована и согласована.

Защита становится более эффективной и гибкой, если она допускает изменение своих параметров со стороны администратора.

Система защиты должна разрабатываться, исходя из предположения, что пользователи будут совершать серьезные ошибки и, вообще, имеют наихудшие намерения.

Наиболее важные и критические решения должны приниматься человеком.

Существование механизмов защиты должно быть по возможности скрыто от пользователей, работа которых находится под контролем.

Аппаратно-программные средства защиты информации

Несмотря на то, что современные ОС для персональных компьютеров, такие, как Windows 2000, Windows XP и Windows NT, имеют собственные подсистемы защиты, актуальность создания дополнительных средств защиты сохраняется. Дело в том, что большинство систем не способны защитить данные, находящиеся за их пределами, например при сетевом информационном обмене.

Аппаратно-программные средства защиты информации можно разбить на пять групп:

Системы идентификации (распознавания) и аутентификации (проверки подлинности) пользователей.

Системы шифрования дисковых данных.

Системы шифрования данных, передаваемых по сетям.

Системы аутентификации электронных данных.

Средства управления криптографическими ключами.

1. Системы идентификации и аутентификации пользователей

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

При построении этих систем возникает проблема выбора информации, на основе которой осуществляются процедуры идентификации и аутентификации пользователя. Можно выделить следующие типы:

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

физиологические параметры человека (отпечатки пальцев, рисунок радужной оболочки глаза и т.п.) или особенности поведения (особенности работы на клавиатуре и т.п.).

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

2. Системы шифрования дисковых данных

Чтобы сделать информацию бесполезной для противника, используется совокупность методов преобразования данных, называемая криптографией [от греч.kryptos — скрытый и grapho — пишу].

Системы шифрования могут осуществлять криптографические преобразования данных на уровне файлов или на уровне дисков. К программам первого типа можно отнести архиваторы типа ARJ и RAR, которые позволяют использовать криптографические методы для защиты архивных файлов. Примером систем второго типа может служить программа шифрования Diskreet, входящая в состав популярного программного пакета Norton Utilities, Best Crypt.

Другим классификационным признаком систем шифрования дисковых данных является способ их функционирования. По способу функционирования системы шифрования дисковых данных делят на два класса:

системы «прозрачного» шифрования;

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

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

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

Большинство систем, предлагающих установить пароль на документ, не шифрует информацию, а только обеспечивает запрос пароля при доступе к документу. К таким системам относится MS Office, 1C и многие другие.

3. Системы шифрования данных, передаваемых по сетям

Различают два основных способа шифрования: канальное шифрование и оконечное (абонентское) шифрование.

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

шифрование служебных данных осложняет механизм маршрутизации сетевых пакетов и требует расшифрования данных в устройствах промежуточной коммуникации (шлюзах, ретрансляторах и т.п.);

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

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

4. Системы аутентификации электронных данных

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

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

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

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

5. Средства управления криптографическими ключами

Безопасность любой криптосистемы определяется используемыми криптографическими ключами. В случае ненадежного управления ключами злоумышленник может завладеть ключевой информацией и получить полный доступ ко всей информации в системе или сети.

Различают следующие виды функций управления ключами: генерация, хранение, и распределение ключей.

Способы генерации ключей для симметричных и асимметричных криптосистем различны. Для генерации ключей симметричных криптосистем используются аппаратные и программные средства генерации случайных чисел. Генерация ключей для асимметричных криптосистем более сложна, так как ключи должны обладать определенными математическими свойствами. Подробнее на этом вопросе остановимся при изучении симметричных и асимметричных криптосистем.

Функция хранения предполагает организацию безопасного хранения, учета и удаления ключевой информации. Для обеспечения безопасного хранения ключей применяют их шифрование с помощью других ключей. Такой подход приводит к концепции иерархии ключей. В иерархию ключей обычно входит главный ключ (т.е. мастер-ключ), ключ шифрования ключей и ключ шифрования данных. Следует отметить, что генерация и хранение мастер-ключа является критическим вопросом криптозащиты.

Распределение — самый ответственный процесс в управлении ключами. Этот процесс должен гарантировать скрытность распределяемых ключей, а также быть оперативным и точным. Между пользователями сети ключи распределяют двумя способами:

с помощью прямого обмена сеансовыми ключами;

используя один или несколько центров распределения ключей.