Информационная безопасность - основы | Системы управления базами данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Литература

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