МЕНЮ | Информация |
---|
|
Механизмы безопасности
Данный труд, называемый чаще всего по цвету обложки "Оранжевой книгой", был впервые опубликован в августе 1983 года. "Оранжевая книга" поясняет понятие безопасной системы, которая "управляет, посредством соответствующих средств, доступом к информации, так что только должным образом авторизованные лица или процессы, действующие от их имени, получают право читать, писать, создавать и удалять информацию". Очевидно, что абсолютно безопасных систем не существует, что это абстракция. Любую систему можно "взломать", если располагать достаточно большими материальными и временными ресурсами. Есть смысл оценивать лишь степень доверия, которое разумно оказать той или иной системе.
Надежность системы
В "Оранжевой книге" надежная система определяется как "система, использующая достаточные аппаратные и программные средства, чтобы обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа". Степень доверия, или надежность систем, оценивается по двум основным критериям:
Политика безопасности Это набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь имеет право оперировать с определенными наборами данных. Чем надежнее система, тем строже и многообразнее должна быть политика безопасности. В зависимости от сформулированной политики можно выбирать конкретные механизмы, обеспечивающие безопасность системы. Политика безопасности — это активный компонент защиты, включающий в себя анализ возможных угроз и выбор мер противодействия.
Основными элементами политики безопасности являются
Гарантированность
Это мера доверия, которая может быть оказана архитектуре и реализации системы. Гарантированность показывает, насколько корректны механизмы, отвечающие за проведение в жизнь политики безопасности. Гарантированность можно считать пассивным компонентом защиты, надзирающим за самими защитниками. Важным средством обеспечения безопасности является механизм подотчетности (протоколирования). Надежная система должна фиксировать все события, касающиеся безопасности. Ведение протоколов должно дополняться аудитом, то есть анализом регистрационной информации. Концепция надежной вычислительной базы является центральной при оценке степени гарантированности, с которой систему можно считать надежной. Надежная вычислительная база — это совокупность защитных механизмов системы (включая аппаратное и программное обеспечение), отвечающих за проведение в жизнь политики безопасности.
Классы безопасности
В "Оранжевой книге" определяется четыре уровня безопасности (надежности) — D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он содержит две подсистемы управления доступом для ПК. По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности — C1, C2, B1, B2, B3, A1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям.
3. Интерпретация "Оранжевой книги" для сетевых конфигураций Вводится новое понятие — сетевая надежная вычислительная база, распределенный аналог надежной вычислительной базы изолированных систем. Сетевая надежная вычислительная база формируется из всех частей всех компонентов сети, обеспечивающих информационную безопасность. Надежная сетевая система должна обеспечивать такое распределение защитных механизмов, чтобы общая политика безопасности проводилась в жизнь несмотря на уязвимость коммуникационных путей и на параллельную, асинхронную работу компонентов. Интерпретация предусматривает различные варианты распределения сетевой надежной вычислительной базы по компонентам и, соответственно, различные варианты распределения механизмов управления доступом. В частности, некоторые компоненты, закрытые от прямого доступа пользователей (например, коммутаторы пакетов, оперирующие на третьем уровне семиуровневой модели OSI), могут вообще не содержать подобных механизмов. Идентификация групп пользователей может строиться на основе сетевых адресов хостов или (под)сетей. В то же время регистрационный журнал должен содержать достаточно информации для ассоциирования действий с конкретным пользователем. Сетевой адрес может являться частью глобального идентификатора пользователя. В принципе возможен централизованный контроль доступа, когда решения принимает специальный сервер авторизации. Возможен и смешанный вариант, когда сервер авторизации разрешает соединение двух хостов, а дальше в дело вступают локальные механизмы хоста, содержащего объект доступа. Аналогично, идентификация и аутентификация пользователей может производиться как централизованно (соответствующим сервером), так и локально — той системой, с которой пользователь непосредственно взаимодействует. Возможна передача идентификационной и аутентификационной информации между хостами (чтобы избавить пользователя от многократной аутентификации). При передаче аутентификационная информация должна быть защищена не слабее, чем на каждом из компонентов сетевой конфигурации. В качестве еще одного отличительного момента Интерпретации нужно отметить повышенное внимание к целостности информации вообще и меток безопасности в частности. Для контроля целостности меток и для их защиты от нелегального изменения в Интерпретации рекомендуется широкое использование криптографических методов. Далее, чтобы принудительное управление доступом в распределенной конфигурации имело смысл, совокупность уровней секретности и категорий должна поддерживаться централизованно. В этом одно из принципиальных отличий от произвольного управления доступом. Новым по сравнению с Оранжевой книгой является рассмотрение вопросов доступности. Сетевой сервис перестает быть доступным, когда пропускная способность коммуникационных каналов падает ниже минимально допустимого уровня или сервис не в состоянии обслуживать запросы. Удаленный ресурс может стать недоступным и вследствие нарушения равноправия в обслуживании пользователей. Надежная система должна быть в состоянии обнаруживать ситуации недоступности, уметь возвращаться к нормальной работе и противостоять атакам на доступность.
4. Гармонизированные критерии Европейских стран Европейские страны приняли согласованные критерии оценки безопасности информационных технологий (Information Technology Security Evaluation Criteria, ITSEC). опубликованные в июне 1991 года от имени соответствующих органов четырех стран — Франции, Германии, Нидерландов и Великобритании. Принципиально важной чертой Европейских Критериев является отсутствие априорных требований к условиям, в которых должна работать информационная система. Так называемый спонсор, то есть организация, запрашивающая сертификационные услуги, формулирует цель оценки, то есть описывает условия, в которых должна работать система, возможные угрозы ее безопасности и предоставляемые ею защитные функции. Задача органа сертификации — оценить, насколько полно достигаются поставленные цели, то есть насколько корректны и эффективны архитектура и реализация механизмов безопасности в описанных спонсором условиях. Европейские Критерии рассматривают следующие составляющие информационной безопасности:
В Критериях проводится различие между системами и продуктами. Система — это конкретная аппаратно-программная конфигурация, построенная с вполне определенными целями и функционирующая в известном окружении. Продукт — это аппаратно-программный "пакет", который можно купить и по своему усмотрению встроить в ту или иную систему. Таким образом, с точки зрения информационной безопасности основное отличие между системой и продуктом состоит в том, что система имеет конкретное окружение, которое можно определить и изучить сколь угодно детально, а продукт должен быть рассчитан на использование в различных условиях. В Европейских Критериях средства, имеющие отношение к информационной безопасности, рассматриваются на трех уровнях детализации. Наиболее абстрактный взгляд касается лишь целей безопасности. На этом уровне мы получаем ответ на вопрос, зачем нужны функции безопасности. Второй уровень содержит спецификации функций безопасности. Мы узнаем, какая функциональность на самом деле обеспечивается. Наконец, на третьем уровне содержится информация о механизмах безопасности. Мы видим, как реализуется декларированная функциональность. Спецификации функций безопасности — важнейшая часть описания объекта оценки. Критерии рекомендуют выделить в этих спецификациях разделы со следующими заголовками:
Набор функций безопасности может специфицироваться с использованием ссылок на заранее определенные классы функциональности. В Европейских Критериях таких классов десять. Пять из них (F-C1, F-C2, F-B1, F-B2, F-B3) соответствуют классам безопасности "Оранжевой книги".
5. Стандарт ISO/IEC 15408 "Критерии оценки безопасности информационных технологий" Этот международный стандарт стал итогом почти десятилетней работы специалистов нескольких стран, он вобрал в себя опыт существовавших к тому времени документов национального и межнационального масштаба. Данный стандарт часто называют "Общими критериями" (ОК). "Общие критерии" на самом деле являются метастандартом, определяющим инструменты оценки безопасности ИС и порядок их использования. В отличие от "Оранжевой книги", ОК не содержат предопределенных "классов безопасности". Такие классы можно строить, исходя из требований безопасности, существующих для конкретной организации и/или конкретной информационной системы. ОК содержат два основных вида требований безопасности:
Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки - аппаратно-программного продукта или информационной системы. Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки. Выделяются следующие этапы:
В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами. В свою очередь, угрозы характеризуются следующими параметрами:
Уязвимые места могут возникать из-за недостатка:
Слабые места по возможности следует устранить, минимизировать или хотя бы постараться ограничить возможный ущерб от их преднамеренного использования или случайной активизации. С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия класс – семейство – компонент - элемент. Классы определяют наиболее общую, "предметную" группировку требований (например, функциональные требования подотчетности). Семейства в пределах класса различаются по строгости и другим нюансам требований. Компонент - минимальный набор требований, фигурирующий как целое. Элемент - неделимое требование. Между компонентами ОК могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Вообще говоря, не все комбинации компонентов имеют смысл, и понятие зависимости в какой-то степени компенсирует недостаточную выразительность библиотечной организации, хотя и не заменяет объединение функций в содержательные объектные интерфейсы. Формируется два вида нормативных документов: профиль защиты и задание по безопасности. Профиль защиты (ПЗ) представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях). Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности. В ОК нет готовых классов защиты. Сформировать классификацию в терминах "Общих критериев" - значит определить несколько иерархически упорядоченных (содержащих усиливающиеся требования) профилей защиты, в максимально возможной степени использующих стандартные функциональные требования и требования доверия безопасности. Выделение некоторого подмножества из всего множества профилей защиты во многом носит субъективный характер. По целому ряду соображений (одним из которых является желание придерживаться объектно-ориентированного подхода) целесообразно, на наш взгляд, сформировать сначала отправную точку классификации, выделив базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты. Функциональный пакет - это неоднократно используемая совокупность компонентов, объединенных для достижения определенных целей безопасности. "Общие критерии" не регламентируют структуру пакетов, процедуры верификации, регистрации и т.п., отводя им роль технологического средства формирования ПЗ. Базовый профиль защиты должен включать требования к основным (обязательным в любом случае) возможностям. Производные профили получаются из базового путем добавления необходимых пакетов расширения, то есть подобно тому, как создаются производные классы в объектно-ориентированных языках программирования. Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности. Всего в "Общих критериях" представлено 11 функциональных классов, 66 семейств, 135 компонентов. Это, конечно, значительно больше, чем число аналогичных сущностей в "Оранжевой книге". Перечислим классы функциональных требований ОК:
безопасности). "Общие критерии" - очень продуманный и полный документ с точки зрения функциональных требований. В то же время, хотелось бы обратить внимание и на некоторые недостатки. Первый - это отсутствие объектного подхода. Функциональные требования не сгруппированы в осмысленные наборы (объектные интерфейсы), к которым могло бы применяться наследование. Подобное положение, как известно из технологии программирования, чревато появлением слишком большого числа комбинаций функциональных компонентов, несопоставимых между собой. В современном программировании ключевым является вопрос накопления и многократного использования знаний. Стандарты - одна из форм накопления знаний. Подход в ОК сужает круг фиксируемых знаний, усложняет их корректное использование. К сожалению, в "Общих критериях" отсутствуют архитектурные требования, что является естественным следствием программистского подхода "снизу вверх". Технологичность средств безопасности, следование общепризнанным рекомендациям по протоколам и программным интерфейсам, а также апробированным архитектурным решениям, таким как менеджер/агент, - необходимые качества изделий информационных технологий, предназначенных для поддержки критически важных функций, к числу которых, безусловно, относятся функции безопасности. Без рассмотрения интерфейсных аспектов системы оказываются нерасширяемыми и изолированными. С практической точки зрения это недопустимо.
Каждый элемент требований доверия принадлежит одному из трех типов:
Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы:
6. Руководящие документы по защите от несанкционированного доступа Гостехкомиссии при Президенте РФ Под штатными средствами понимается совокупность программного, микропрограммного и технического обеспечения СВТ или АС. В Концепции формулируются следующие основные принципы защиты от НСД к информации:
В качестве главного средства защиты от НСД к информации в Концепции рассматривается система разграничения доступа (СРД) субъектов к объектам доступа.
Основными функциями СРД являются:
Кроме того, Концепция предусматривает наличие обеспечивающих средств для СРД, которые выполняют следующие функции:
Технические средства защиты от НСД, согласно Концепции, должны оцениваться по следующим основным параметрам:
Устанавливается семь классов защищенности СВТ от НСД к информации. Самый низкий класс — седьмой, самый высокий — первый. Классы подразделяются на четыре группы, отличающиеся качественным уровнем защиты:
Седьмой класс присваивают СВТ, к которым предъявлялись требования по защите от НСД к информации, но при оценке защищенность СВТ оказалась ниже уровня требований шестого класса. |