В этом разделе рассматриваются основы подхода к информационной безопасности, который можно назвать классическим. Существуют разные мнения по поводу практической применимости этого подхода, однако в любом случае необходимо владеть базовыми понятиями, введенными по большей части в работах, выполненных по заказу Министерства обороны США.
На наш взгляд, знание критериев оценки информационной безопасности способно помочь при выборе и комплектовании аппаратно-программной конфигурации. Кроме того, в своей повседневной работе администратор безопасности вынужден хотя бы до некоторой степени повторять действия сертифицирующих органов, поскольку обслуживаемая система, скорее всего, время от времени претерпевает изменения и нужно, во-первых, оценивать целесообразность модификаций и их последствия, а, во-вторых, соответствующим образом корректировать повседневную практику пользования и администрирования. Если знать, на что обращают внимание при сертификации, можно сконцентрироваться на анализе критически важных аспектов, экономя время и силы и повышая качество защиты.
Данный труд, называемый чаще всего по цвету обложки "Оранжевой книгой", был впервые опубликован в августе 1983 года. Уже его название заслуживает комментария. Речь идет не о безопасных, а о надежных системах, причем слово "надежный" трактуется так же, как в сочетании "надежный человек" — человек, которому можно доверять.
"Оранжевая книга" поясняет понятие безопасной системы, которая "управляет, посредством соответствующих средств, доступом к информации, так что только должным образом авторизованные лица или процессы, действующие от их имени, получают право читать, писать, создавать и удалять информацию". Очевидно, однако, что абсолютно безопасных систем не существует, что это абстракция. Любую систему можно "взломать", если располагать достаточно большими материальными и временными ресурсами. Есть смысл оценивать лишь степень доверия, которое разумно оказать той или иной системе.
В "Оранжевой книге" надежная система определяется как "система, использующая достаточные аппаратные и программные средства, чтобы обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа".
Степень доверия, или надежность систем, оценивается по двум основным критериям:
Политика безопасности. набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь имеет право оперировать с определенными наборами данных. Чем надежнее система, тем строже и многообразнее должна быть политика безопасности. В зависимости от сформулированной политики можно выбирать конкретные механизмы, обеспечивающие безопасность системы. Политика безопасности — это активный компонент защиты, включающий в себя анализ возможных угроз и выбор мер противодействия.
Гарантированность. мера доверия, которая может быть оказана архитектуре и реализации системы. Гарантированность может проистекать как из тестирования, так и из проверки (формальной или нет) общего замысла и исполнения системы в целом и ее компонентов.
Гарантированность показывает, насколько корректны механизмы, отвечающие за проведение в жизнь политики безопасности. Гарантированность можно считать пассивным компонентом защиты, надзирающим за самими защитниками.
Важным средством обеспечения безопасности является механизм подотчетности (протоколирования). Надежная система должна фиксировать все события, касающиеся безопасности. Ведение протоколов должно дополняться аудитом, то есть анализом регистрационной информации.
Концепция надежной вычислительной базы является центральной при оценке степени гарантированности, с которой систему можно считать надежной. Надежная вычислительная база — это совокупность защитных механизмов компьютерной системы (включая аппаратное и программное обеспечение), отвечающих за проведение в жизнь политики безопасности. Надежность вычислительной базы определяется исключительно ее реализацией и корректностью исходных данных, которые вводит административный персонал (например, это могут быть данные о степени благонадежности пользователей).
Вообще говоря, компоненты вне вычислительной базы могут не быть надежными, однако это не должно влиять на безопасность системы в целом. В результате, для оценки надежности компьютерной системы достаточно рассмотреть только ее вычислительную базу, которая, как можно надеяться, достаточно компактна.
Основное назначение надежной вычислительной базы — выполнять функции монитора обращений, то есть контролировать допустимость выполнения субъектами определенных операций над объектами. Монитор проверяет каждое обращение пользователя к программам или данным на предмет согласованности со списком действий, допустимых для пользователя.
От монитора обращений требуется выполнение трех свойств:
Реализация монитора обращений называется ядром безопасности. Ядро безопасности — это основа, на которой строятся все защитные механизмы. Помимо перечисленных выше свойств монитора обращений, ядро должно гарантировать собственную неизменность.
Границу надежной вычислительной базы называют периметром безопасности. Как уже указывалось, от компонентов, лежащих вне периметра безопасности, вообще говоря, не требуется надежности. С развитием распределенных систем понятию "периметр безопасности" все чаще придают другой смысл, имея в виду границу владений определенной организации. То, что внутри владений, считается надежным, а то, что вне — нет. Связь между внутренним и внешним мирами осуществляют посредством шлюзовой системы, которая по идее способна противостоять потенциально ненадежному или даже враждебному окружению.
Согласно "Оранжевой книге", политика безопасности должна включать в себя по крайней мере следующие элементы:
Ниже следует подробное рассмотрение перечисленных элементов.
Произвольное управление доступом — это метод ограничения доступа к объектам, основанный на учете личности субъекта или группы, в которую субъект входит. Произвольность управления состоит в том, что некоторое лицо (обычно владелец объекта) может по своему усмотрению давать другим субъектам или отбирать у них права доступа к объекту.
С концептуальной точки зрения текущее состояние прав доступа при произвольном управлении описывается матрицей, в строках которой перечислены субъекты, а в столбцах — объекты. В клетках, расположенных на пересечении строк и столбцов, записываются способы доступа, допустимые для субъекта по отношению к объекту — например, чтение, запись, выполнение, возможность передачи прав другим субъектам и т.п.
Очевидно, прямолинейное представление подобной матрицы невозможно (поскольку она очень велика), да и не нужно (поскольку она разрежена, то есть большинство клеток в ней пусты). В операционных системах более компактное представление матрицы доступа основывается или на структурировании совокупности субъектов (владелец/группа/прочие в ОС UNIX), или на механизме списков управления доступом, то есть на представлении матрицы по столбцам, когда для каждого объекта перечисляются субъекты вместе с их правами доступа. За счет использования метасимволов можно компактно описывать группы субъектов, удерживая тем самым размеры списков управления доступом в разумных рамках.
Большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом. Главное его достоинство — гибкость, главные недостатки — рассредоточенность управления и сложность централизованного контроля, а также оторванность прав доступа от данных, что позволяет копировать секретную информацию в общедоступные файлы.
Безопасность повторного использования объектов — важное на практике дополнение средств управления доступом, предохраняющее от случайного или преднамеренного извлечения секретной информации из "мусора". Безопасность повторного использования должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т.п.), для дисковых блоков и магнитных носителей в целом.
Важно обратить внимание на следующий момент. Поскольку информация о субъектах также представляет собой объект, необходимо позаботиться о безопасности "повторного использования субъектов". Когда пользователь покидает организацию, следует не только лишить его возможности входа в систему, но и запретить доступ ко всем объектам. В противном случае, новый сотрудник может получить ранее использовавшийся идентификатор а с ним и все права своего предшественника.
Современные интеллектуальные периферийные устройства усложняют обеспечение безопасности повторного использования объектов. Действительно, принтер может буферизовать несколько страниц документа, которые останутся в памяти даже после окончания печати. Необходимо предпринять специальные меры, чтобы "вытолкнуть" их оттуда.
Впрочем, иногда организации защищаются от повторного использования слишком ревностно — путем уничтожения магнитных носителей. На практике заведомо достаточно троекратной записи случайных последовательностей бит.
Для реализации принудительного управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка субъекта описывает его благонадежность, метка объекта — степень закрытости содержащейся в нем информации.
Согласно "Оранжевой книге", метки безопасности состоят из двух частей — уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:
Впрочем, для разных систем набор уровней секретности может различаться.
Категории образуют неупорядоченный набор. Их назначение — описать предметную область, к которой относятся данные. В военном окружении каждая категория может соответствовать, например, определенному виду вооружений. Механизм категорий позволяет разделить информацию по отсекам, что способствует лучшей защищенности. В Разд. Принудительное управление доступом мы подробно рассмотрим правила принудительного управления доступом, здесь же отметим, что субъект не может получить доступ к "чужим" категориям, даже если его уровень благонадежности — "совершенно секретно". Специалист по танкам не узнает тактико-технические данные самолетов.
Главная проблема, которую необходимо решать в связи с метками, это обеспечение их целостности. Во-первых, не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши. Во-вторых, при любых операциях с данными метки должны оставаться правильными. В особенности это относится к экспорту и импорту данных. Например, печатный документ должен открываться заголовком, содержащим текстовое и/или графическое представление метки безопасности. Аналогично, при передаче файла по каналу связи должна передаваться и ассоциированная с ним метка, причем в таком виде, чтобы удаленная система могла ее протрактовать, несмотря на возможные различия в уровнях секретности и наборе категорий.
Одним из средств обеспечения целостности меток безопасности является разделение устройств на многоуровневые и одноуровневые. На многоуровневых устройствах может храниться информация разного уровня секретности (точнее, лежащая в определенном диапазоне уровней). Одноуровневое устройство можно рассматривать как вырожденный случай многоуровневого, когда допустимый диапазон состоит из одного уровня. Зная уровень устройства, система может решить, допустимо ли записывать на него информацию с определенной меткой. Например, попытка напечатать совершенно секретную информацию на принтере общего пользования с уровнем "несекретно" потерпит неудачу.
Метки безопасности, ассоциируемые с субъектами, более подвижны, чем метки объектов. Субъект может в течение сеанса работы с системой изменять свою метку, естественно, не выходя за предопределенные для него рамки. Иными словами, он может сознательно занижать свой уровень благонадежности, чтобы уменьшить вероятность непреднамеренной ошибки. Вообще, принцип минимизации привилегий — весьма разумное средство защиты.
Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта.
Субъект может читать информацию из объекта, если уровень секретности субъекта не ниже, чем у объекта, а все категории, перечисленные в метке безопасности объекта, присутствуют в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Смысл сформулированного правила понятен — читать можно только то, что положено.
Субъект может записывать информацию в объект, если метка безопасности объекта доминирует над меткой субъекта. В частности, "конфиденциальный" субъект может писать в секретные файлы, но не может — в несекретные (разумеется, должны также выполняться ограничения на набор категорий). На первый взгляд подобное ограничение может показаться странным, однако оно вполне разумно. Ни при каких операциях уровень секретности информации не должен понижаться, хотя обратный процесс вполне возможен. Посторонний человек может случайно узнать секретные сведения и сообщить их куда следует, однако лицо, допущенное к работе с секретными документами, не имеет права раскрывать их содержание простому смертному.
Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение "разрешить доступ к объекту X еще и для пользователя Y". Конечно, можно изменить метку безопасности пользователя Y, но тогда он скорее всего, получит доступ ко многим дополнительным объектам, а не только к X.
Принудительное управление доступом реализовано во многих вариантах операционных систем и СУБД, отличающихся повышенными мерами безопасности. Независимо от практического использования, принципы принудительного управления являются удобным методологическим базисом для начальной классификации информации и распределения прав доступа. Удобнее мыслить в терминах уровней секретности и категорий, чем заполнять неструктурированную матрицу доступа. Впрочем, в реальной жизни произвольное и принудительное управление доступом сочетается в рамках одной системы, что позволяет использовать сильные стороны обоих подходов.
Если понимать политику безопасности узко, то есть как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности — в каждый момент времени знать, кто работает в системе и что он делает. Средства подотчетности делятся на три категории:
Рассмотрим эти категории подробнее.
Каждый пользователь, прежде чем получить право совершать какие-либо действия в системе, должен идентифицировать себя. Обычный способ идентификации — ввод имени пользователя при входе в систему. В свою очередь, система должна проверить подлинность личности пользователя, то есть что он является именно тем, за кого себя выдает. Стандартное средство проверки подлинности (аутентификации) — пароль, хотя в принципе могут использоваться также разного рода личные карточки, биометрические устройства (сканирование роговицы или отпечатков пальцев) или их комбинация.
Идентификация и аутентификация — первый и важнейший программно-технический рубеж информационной безопасности. Если не составляет проблемы получить доступ к системе под любым именем, то другие механизмы безопасности, например, управление доступом, очевидно, теряют смысл. Очевидно и то, что без идентификации пользователей невозможно протоколирование их действий. В силу перечисленных причин проверке подлинности должно придаваться первостепенное значение. Существует целая серия публикаций правительственных ведомств США, разъясняющих вопросы аутентификации и, в частности, проблемы, связанные с паролями. Например, декларируется, что пользователю должно быть позволено менять свой пароль, что пароли, как правило, должны быть машинно-сгенерированными (а не выбранными "вручную"), что пользователю должна предоставляться некоторая регистрационная информация (дата и время последнего входа в систему и т.п.).
Надежный путь связывает пользователя непосредственно с надежной вычислительной базой, минуя другие, потенциально опасные компоненты системы. Цель предоставления надежного пути — дать пользователю возможность убедиться в подлинности обслуживающей его системы.
Относительно несложно реализовать надежный путь, если используется неинтеллектуальный терминал — достаточно иметь зарезервированную управляющую последовательность (при условии защищенности линии связи между терминалом и системой). Если же пользователь общается с интеллектуальным терминалом, персональным компьютером или рабочей станцией, задача обеспечения надежного пути становится чрезвычайно сложной, если вообще разрешимой. Как гарантировать, что пользователь общается с подлинной программой login, а не с "Троянским конем"? Возможно, по этой причине о предоставлении надежного пути упоминают редко, хотя на практике данный аспект весьма важен.
Аудит имеет дело с действиями (событиями), так или иначе затрагивающими безопасность системы. К числу таких событий относятся:
Можно назвать и другие события — например, смену набора регистрируемых действий. Полный перечень событий, потенциально подлежащих регистрации, зависит от избранной политики безопасности и от специфики системы.
Если фиксировать все события, объем регистрационной информации, скорее всего, будет расти слишком быстро, а ее эффективный анализ станет невозможным. "Оранжевая книга" предусматривает наличие средств выборочного протоколирования, как в отношении пользователей (внимательно следить только за подозрительными), так и в отношении событий.
Протоколирование помогает следить за пользователями и реконструировать прошедшие события. Слежка важна в первую очередь как профилактическое средство. Можно надеяться, что многие воздержатся от нарушений безопасности, зная, что их действия фиксируются. Реконструкция событий позволяет проанализировать случаи нарушений, понять, почему они стали возможны, оценить размеры ущерба и принять меры по недопущению подобных нарушений в будущем.
При протоколировании события записывается по крайней мере следующая информация:
Необходимо подчеркнуть важность не только сбора информации, но и ее регулярного и целенаправленного анализа. В плане анализа выгодное положение занимают средства аудита СУБД, поскольку к регистрационной информации могут естественным образом применяться произвольные SQL-запросы. Следовательно, появляется возможность для выявления подозрительных действий применять сложные эвристики.
Гарантированность — это мера уверенности, с которой можно утверждать, что для проведения в жизнь сформулированной политики безопасности выбран подходящий набор средств, и что каждое из этих средств правильно исполняет отведенную ему роль.
В "Оранжевой книге" рассматривается два вида гарантированности — операционная и технологическая. Операционная гарантированность относится к архитектурным и реализационным аспектам системы, в то время как технологическая — к методам построения и сопровождения.
Операционная гарантированность включает в себя проверку следующих элементов:
Операционная гарантированность — это способ убедиться в том, что архитектура системы и ее реализация действительно проводят в жизнь избранную политику безопасности.
Архитектура системы должна способствовать реализации мер безопасности или прямо поддерживать их. Примеры подобных архитектурных решений в рамках аппаратуры и операционной системы — разделение команд по уровням привилегированности, защита различных процессов от взаимного влияния за счет выделения каждому своего виртуального пространства, особая защита ядра ОС.
В принципе меры безопасности не обязательно должны быть заранее встроены в систему — достаточно принципиальной возможности дополнительной установки защитных продуктов. Так, сугубо ненадежная система MS-DOS может быть улучшена за счет средств проверки паролей доступа к компьютеру и/или жесткому диску, за счет борьбы с вирусами путем отслеживания попыток записи в загрузочный сектор CMOS-средствами и т.п. Тем не менее, по-настоящему надежная система должна изначально проектироваться с упором на механизмы безопасности.
Среди архитектурных решений, предусматриваемых "Оранжевой книгой", упомянем следующие:
Целостность системы в данном контексте означает, что аппаратные и программные компоненты надежной вычислительной базы работают должным образом и что имеется аппаратное и программное обеспечение для периодической проверки целостности.
Анализ тайных каналов передачи информации — тема, специфичная для режимных систем, когда главное — обеспечить конфиденциальность информации. Тайным называется канал передачи информации, не предназначенный для обычного использования. Шпионская аналогия — горшок с геранью в окне как сигнал опасности.
Различают тайные каналы с памятью и временные (ударение на "ы"). Тайные каналы с памятью используют изменения хранимых объектов. Тайным знаком может быть размер файла, имя файла (составленное, например, из входного имени и пароля атакуемого субъекта), число пробелов между словами и т.д. Тайный канал считается быстрым, если с его помощью можно передавать 100 или более бит в секунду.
Временные каналы передают информацию за счет изменения временных характеристик процессов — времени обработки запроса, например. Когда-то давно мой товарищ, Андрей Ходулев, написал программу, угадывавшую мысли. Точнее, она отгадывала задуманное число (от 1 до 4). Человеку предлагалось в уме проделать определенные вычисления, естественно, не сообщая программе ответ. "Соль" программы состояла в том, что для разных чисел некоторые вычисления проделать легко, а для других — трудно. Анализируя распределение времени, затраченного на вычисления, программа угадывала задуманное число. Человек, сам того не ведая, передавал программе информацию по тайному временному каналу.
Обычно тайные каналы используются не столько для передачи информации от одного злоумышленника другому, сколько для получения злоумышленником сведений от внедренного в систему "Троянского коня".
Не очень понятно, как на практике, в распределенной системе, выявлять тайные каналы (хотя, после выявления, пропускную способность оценить можно). Как показывают предыдущие рассмотрения, тайным каналом может служить почти все, что угодно, а скорости современных процессоров и периферийных устройств делают опасными даже прямолинейные способы передачи. Вероятно, только для статичной конфигурации можно с разумной полнотой описать возможные тайные каналы передачи информации.
Надежное администрирование в трактовке "Оранжевой книги" означает всего лишь, что должны быть логически выделены три роли — системного администратора, системного оператора и администратора безопасности. Физически эти обязанности может выполнять один человек, но, в соответствии с принципом минимизации привилегий, в каждый момент времени он должен выполнять только одну из трех ролей. Конкретный набор обязанностей администраторов и оператора зависит от специфики организации.
Надежное восстановление после сбоев — вещь необходимая, однако ее реализация может быть сопряжена с серьезными техническими трудностями. Прежде всего, должна быть сохранена целостность информации и, в частности, целостность меток безопасности. В принципе возможна ситуация, когда сбой приходится на момент записи нового файла с совершенно секретной информацией. Если файл окажется с неправильной меткой, информация может быть скомпрометирована. Далее, на период восстановления система не должна оставаться беззащитной. Нельзя допускать промежуточных состояний, когда защитные механизмы полностью или частично отключены, а доступ пользователей разрешен.
Вообще говоря, надежное восстановление включает в себя два вида деятельности — подготовку к сбою (отказу) и собственно восстановление. Подготовка к сбою — это и регулярное выполнение резервного копирования, и выработка планов действий в экстренных случаях, и поддержание запаса резервных компонентов. Восстановление, вероятно, связано с перезагрузкой системы и выполнением ремонтных и/или административных процедур.
Технологическая гарантированность охватывает весь жизненный цикл системы, то есть периоды проектирования, реализации, тестирования, продажи и сопровождения. Все перечисленные действия должны выполняться в соответствии с жесткими стандартами, чтобы обезопаситься от утечки информации и нелегальных "закладок".
Первое, на что обычно обращают внимание, это тестирование. Изготовитель или поставщик выполняет набор тестов, документирует его и предоставляет на рассмотрение аттестационной комиссии, которая проверяет полноту набора и, быть может, выполняет свои тесты. Вообще говоря, тестированию подлежат как собственно механизмы безопасности, так и пользовательский интерфейс к ним. Тесты должны показать, что защитные механизмы функционируют в соответствии со своим описанием и что не существует очевидных способов обхода или разрушения защиты. Тесты должны продемонстрировать действенность средств управления доступом, защищенность регистрационной и аутентификационной информации. Должна быть уверенность, что надежную вычислительную базу нельзя привести в состояние, когда она перестанет обслуживать пользовательские запросы (пожалуй, это единственное упоминание в "Оранжевой книге" такого аспекта информационной безопасности, как доступность).
Верификация описания архитектуры — это выполненное автоматически формальное доказательство того, что архитектура системы соответствует сформулированной политике безопасности. Национальный центр компьютерной безопасности США располагает двумя системами для проведения подобных формальных доказательств — Gypsy Verification Environment (GVE) компании Computational Logic, Inc. и Formal Development Methodology (FDM) корпорации UNISYS.
Средства конфигурационного управления защищают надежную систему в процессе проектирования, реализации и сопровождения. Конфигурационное управление включает в себя идентификацию, протоколирование и анализ всех изменений, вносимых в надежную вычислительную базу (независимо от того, идет ли речь об аппаратуре или программах), а также (что прямо следует из названия) управление процессом внесения изменений.
Конфигурационное управление давно и широко используется разработчиками программного обеспечения отнюдь не только (и не столько) по соображениям безопасности. Специфика подхода "Оранжевой книги" — в тотальном контроле за изменениями и в строгой дисциплине их проведения.
Надежное распределение защищает систему в процессе ее передачи от поставщика клиенту. Оно включает в себя два комплекса мер — по защите и по проверке. Защитная часть работает на пути от поставщика к клиенту. Она позволяет поставщику утверждать, что клиент получил именно то, поставщик отгрузил, что передана нужная версия, все последние изменения, и что по дороге система не была вскрыта и в нее не были внесены изменения. Среди защитных механизмов — надежная упаковка, предохраняющая от вредного воздействия окружающей среды, надежная транспортировка и, наконец, надежная инсталляция аппаратуры и программ.
Проверочные меры применяются клиентом, чтобы убедиться, что он получил именно то, что заказал, и что система не подверглась нелегальным изменениям. Клиент должен убедиться, что полученный им продукт — точная копия эталонного варианта, имеющегося у поставщика. Для этого существует целый спектр методов, начиная от проверок серийных номеров аппаратных компонентов и кончая верификацией контрольных сумм программ и данных. Следует отметить, что современная практика поставки программного обеспечения на CD-ROM'ах существенно затрудняет (по сравнению с дискеточным вариантом) внесение нелегальных изменений.
Документация — необходимое условие гарантированной надежности системы и, одновременно, — инструмент проведения политики безопасности. Без документации люди не будут знать, какой политике следовать и что для этого нужно делать.
Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома:
Разумеется, на практике требуется еще по крайней мере одна книга — письменное изложение политики безопасности данной организации.
Руководство пользователя по средствам безопасности предназначено для обычных, непривилегированных людей. Оно должно содержать сведения о механизмах безопасности и способах их использования. Руководство должно давать ответы по крайней мере на следующие вопросы:
Руководство администратора по средствам безопасности предназначено и для системного администратора, и для администратора безопасности. В Руководстве освещаются вопросы начального конфигурирования системы, перечисляются текущие обязанности администратора, анализируется соотношения между безопасностью и эффективностью функционирования.
Типичное оглавление Руководства администратора включает в себя следующие пункты:
Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того (вернее, перед тем), тестовая документация должна содержать план тестирования и условия, налагаемые на тестовое окружение.
Описание архитектуры в данном контексте должно включать в себя по крайней мере сведения о внутреннем устройстве надежной вычислительной базы. Вообще говоря, это описание должно быть формальным, допускающим автоматическое сопоставление с политикой безопасности на предмет соответствия требованиям последней. Объем описания архитектуры может оказаться сопоставимым с объемом исходных текстов программной реализации системы.
"Критерии" Министерства обороны США открыли путь к ранжированию информационных систем по степени надежности. В "Оранжевой книге" определяется четыре уровня безопасности (надежности) — D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он содержит две подсистемы управления доступом для ПК. По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности — C1, C2, B1, B2, B3, A1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, мы, следуя [26] , будем выписывать лишь то новое, что присуще данному классу, группируя требования в согласии с предшествующим изложением.
Итак, ниже следуют критерии оценки надежных компьютерных систем.
Требования к политике безопасности, проводимой системой, подразделяются в соответствии с основными направлениями политики, предусматриваемыми "Оранжевой книгой".
Класс C1. надежная вычислительная база должна управлять доступом именованных пользователей к именованным объектам. Механизм управления (права для владельца/группы/прочих, списки управления доступом) должен позволять пользователям специфицировать разделение файлов между индивидами и/или группами.
Класс C2. в дополнение к C1, права доступа должны гранулироваться с точностью до пользователя. Механизм управления должен ограничивать распространение прав доступа — только авторизованный пользователь (например, владелец объекта) может предоставлять права доступа другим пользователям. Все объекты должны подвергаться контролю доступа.
Класс B3. в дополнение к C2, должны обязательно использоваться списки управления доступом с указанием разрешенных режимов. Должна быть возможность явного указания пользователей или их групп, доступ которых к объекту запрещен.
Класс 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. в дополнение к С1, должны описываться процедуры обработки регистрационной информации и управления файлами с такой информацией, а также структура записей для каждого типа регистрируемых событий.
Класс B1. в дополнение к C2, руководство должно описывать функции оператора и администратора, затрагивающие безопасность, в том числе действия по изменению характеристик пользователей. Должны быть представлены рекомендации по согласованному и эффективному использованию средств безопасности, их взаимодействию друг с другом, по безопасной генерации новых версий надежной вычислительной базы.
Класс B2. в дополнение к B1, должны быть указаны модули надежной вычислительной базы, содержащие механизмы проверки обращений. Должна быть описана процедура безопасной генерации новой версии базы после внесения изменений в исходные тексты.
Класс B3. в дополнение к B2, должна быть описана процедура, обеспечивающая безопасность начального запуска системы и возобновления ее работы после сбоя.
Класс C1. разработчик системы должен представить экспертному совету документ, содержащий план тестов, процедуры прогона тестов и результаты тестов.
Класс B2. в дополнение к C1, тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации.
Класс A1. в дополнение к B2, должно быть описано соответствие между формальными спецификациями верхнего уровня и исходными текстами.
Класс C1. должны быть описаны подход к безопасности, используемый производителем, и применение этого подхода при реализации надежной вычислительной базы. Если база состоит из нескольких модулей, должен быть описан интерфейс между ними.
Класс B1. в дополнение к C1, должно быть представлено неформальное или формальное описание модели политики безопасности, проводимой в жизнь надежной вычислительной базой. Необходимо наличие аргументов в пользу достаточности избранной модели для реализации политики безопасности. Должны быть описаны защитные механизмы базы и их место в модели.
Класс B2. в дополнение к B1, модель политики безопасности должна быть формальной и доказательной. Должно быть показано, что описательные спецификации верхнего уровня точно отражают интерфейс надежной вычислительной базы. Должно быть показано, как база реализует концепцию монитора обращений, почему она устойчива к попыткам отслеживания ее работы, почему ее нельзя обойти и почему она реализована корректно. Должна быть описана структура базы, чтобы облегчить ее тестирование и проверку соблюдения принципа минимизации привилегий. Документация должна содержать результаты анализа тайных каналов передачи информации и описание мер протоколирования, помогающих выявлять каналы с памятью.
Класс B3. в дополнение к B2, должно быть неформально продемонстрировано соответствие между описательными спецификациями верхнего уровня и реализацией надежной вычислительной базы.
Класс A1. в дополнение к B3, должно быть неформально продемонстрировано соответствие между формальными спецификациями верхнего уровня и реализацией надежной вычислительной базы.
Поучительно проследить, как именно требования к политике безопасности и к гарантированности распределены по классам безопасности. В "младших" классах политика довольно быстро ожесточается, по существу достигая пика к классу B1. Напротив, меры гарантированности отнесены в основном в "старшие" классы, начиная с B2. Это подтверждает независимость двух основных групп критериев надежности и методологическую целесообразность их разделения по Европейскому образцу (см. Разд. Гармонизированные критерии Европейских стран ).
Распределение требований по классам вызывает ряд конкретных возражений. Неоправданно далеко отодвинуты такие очевидные требования, как извещение о нарушении защиты, конфигурационное управление, безопасный запуск и восстановление после сбоев. Возможно, это оправдано в физически защищенной военной среде, но никак не в коммерческой, когда постоянное слежение за перемещениями сотрудников может быть очень дорогим удовольствием.
В представленном виде "Критерии" полностью игнорируют коммуникационный аспект, присущий современным распределенным системам. Далее мы покажем, сколь специфична эта область, сколько потенциальных угроз безопасности она содержит, какие новые защитные механизмы следует использовать. Примечательно, что изданные позднее толкования "Критериев" для сетевых конфигураций примерно в три раза толще самой "Оранжевой книги".
Очень важный методологический недостаток "Оранжевой книги" — явная ориентация на производителя и оценщика, а не на покупателя систем. Она не дает ответ на вопрос, как безопасным образом строить систему, как наращивать отдельные компоненты и конфигурацию в целом. "Критерии" рассчитаны на статичные, замкнутые системы, которые, вероятно, доминируют в военной среде, но крайне редки в среде коммерческой. Покупателям нужны более динамичные и структурированные критерии.
Тем не менее следует подчеркнуть, что публикация "Оранжевой книги" без всякого преувеличения стала эпохальным событием в области защиты коммерческих информационных систем. Появился общепризнанный понятийный базис, без которого даже обсуждение проблем безопасности было бы затруднительным. Именно в этом видится главная ценность Критериев оценки надежных компьютерных систем Министерства обороны США.
Отметим, что огромный идейный потенциал "Оранжевой книги" пока во многом остается невостребованным. Прежде всего, это касается концепции технологической гарантированности, охватывающей весь жизненный цикл системы — от выработки спецификаций до фазы эксплуатации. При современной технологии программирования результирующая система не содержит информации, присутствующей в исходных спецификациях. В то же время, наличие подобной информации (быть может, в предварительно обработанном виде) на этапе выполнения, позволило бы по-новому поставить и решить многие проблемы информационной безопасности. Например, знание монитором обращений того, к каким объектам (или классам объектов) может осуществлять доступ программа, существенно затруднило бы создание "троянских коней" и распространение вирусов. К сожалению, пока для принятия решения о допустимости того или иного действия, используется скудная и, в основном, косвенная информация (как правило — идентификатор владельца процесса), не имеющая отношения к семантике действия.
Следуя по пути интеграции, Европейские страны приняли согласованные критерии оценки безопасности информационных технологий (Information Technology Security Evaluation Criteria, ITSEC). Наше изложение основывается на версии 1.2 этих Критериев, опубликованной в июне 1991 года от имени соответствующих органов четырех стран — Франции, Германии, Нидерландов и Великобритании. Выгода от использования согласованных критериев очевидна для всех — и для производителей, и для потребителей, и для самих органов сертификации.
Принципиально важной чертой Европейских Критериев является отсутствие априорных требований к условиям, в которых должна работать информационная система. (Напомним, что в "Критериях" Министерства обороны США очевидна привязка к условиям правительственной системы, обрабатывающей секретную информацию.) Так называемый спонсор, то есть организация, запрашивающая сертификационные услуги, формулирует цель оценки, то есть описывает условия, в которых должна работать система, возможные угрозы ее безопасности и предоставляемые ею защитные функции. Задача органа сертификации — оценить, насколько полно достигаются поставленные цели, то есть насколько корректны и эффективны архитектура и реализация механизмов безопасности в описанных спонсором условиях. Таким образом, в терминологии "Оранжевой книги", Европейские Критерии относятся к гарантированности безопасной работы системы. Требования к политике безопасности и к наличию защитных механизмов не являются составной частью Критериев. Впрочем, чтобы облегчить формулировку цели оценки, Критерии содержат в качестве приложения описание десяти примерных классов функциональности, типичных для правительственных и коммерческих систем.
Перейдем к систематическому изложению подхода, развиваемого в Европейских Критериях.
Европейские Критерии рассматривают следующие составляющие информационной безопасности:
В Критериях проводится различие между системами и продуктами. Система — это конкретная аппаратно-программная конфигурация, построенная с вполне определенными целями и функционирующая в известном окружении. Продукт — это аппаратно-программный "пакет", который можно купить и по своему усмотрению встроить в ту или иную систему. Таким образом, с точки зрения информационной безопасности основное отличие между системой и продуктом состоит в том, что система имеет конкретное окружение, которое можно определить и изучить сколь угодно детально, а продукт должен быть рассчитан на использование в различных условиях. Угрозы безопасности системы носят вполне конкретный и реальный характер. Относительно угроз продукту можно лишь строить предположения. Разработчик может специфицировать условия, пригодные для функционирования продукта; дело покупателя — обеспечить выполнение этих условий.
Из практических соображений важно обеспечить единство критериев оценки продуктов и систем — например, чтобы облегчить и удешевить оценку системы, составленной из ранее сертифицированных продуктов. В этой связи для систем и продуктов вводится единый термин — объект оценки. В соответствующих местах делаются оговорки, какие требования относятся исключительно к системам, а какие — только к продуктам.
Каждая система и/или продукт предъявляет свои требования к обеспечению конфиденциальности, целостности и доступности. Чтобы удовлетворить эти требования, необходимо предоставить соответствующий набор функций (сервисов) безопасности, таких как идентификация и аутентификация, управление доступом или восстановление после сбоев.
Сервисы безопасности реализуются посредством конкретных механизмов. Например, для реализации функции идентификации и аутентификации можно использовать такой механизм, как сервер аутентификации Kerberos.
Чтобы объект оценки можно было признать надежным, необходима определенная степень уверенности в наборе функций и механизмов безопасности. Степень уверенности мы будем называть гарантированностью. Гарантированность может быть большей или меньшей в зависимости от тщательности проведения оценки.
Гарантированность затрагивает два аспекта — эффективность и корректность средств безопасности. При проверке эффективности анализируется соответствие между целями, сформулированными для объекта оценки, и имеющимся набором функций безопасности. Точнее говоря, рассматриваются вопросы адекватности функциональности, взаимной согласованности функций, простоты их использования, а также возможные последствия эксплуатации известных слабых мест защиты. Кроме того, в понятие эффективности входит способность механизмов защиты противостоять прямым атакам (мощность механизма). Определяется три градации мощности — базовая, средняя и высокая.
Под корректностью понимается правильность реализации функций и механизмов безопасности. В Критериях определяется семь возможных уровней гарантированности корректности — от E0 до E6 (в порядке возрастания). Уровень E0 обозначает отсутствие гарантированности (аналог уровня D "Оранжевой книги"). При проверке корректности анализируется весь жизненный цикл объекта оценки — от проектирования до эксплуатации и сопровождения.
Общая оценка системы складывается из минимальной мощности механизмов безопасности и уровня гарантированности корректности. Теоретически эти два аспекта независимы, хотя на практике нет смысла проверять правильность реализации "по высшему разряду", если механизмы безопасности не обладают даже средней мощностью.
В Европейских Критериях средства, имеющие отношение к информационной безопасности, рассматриваются на трех уровнях детализации. Наиболее абстрактный взгляд касается лишь целей безопасности. На этом уровне мы получаем ответ на вопрос, зачем нужны функции безопасности. Второй уровень содержит спецификации функций безопасности. Мы узнаем, какая функциональность на самом деле обеспечивается. Наконец, на третьем уровне содержится информация о механизмах безопасности. Мы видим, как реализуется декларированная функциональность.
Спецификации функций безопасности — важнейшая часть описания объекта оценки. Критерии рекомендуют выделить в этих спецификациях разделы со следующими заголовками:
Большинство из перечисленных тем мы рассматривали при анализе "Оранжевой книги". Здесь мы остановимся лишь на моментах, специфичных для Европейских Критериев.
Под идентификацией и аутентификацией понимается не только проверка подлинности пользователей в узком смысле, но и функции для регистрации новых пользователей и удаления старых, а также функции для генерации, изменения и проверки аутентификационной информации, в том числе средства контроля целостности. Сюда же относятся функции для ограничения числа повторных попыток аутентификации.
Средства управления доступом также трактуются Европейскими Критериями достаточно широко. В этот раздел попадают, помимо прочих, функции, обеспечивающие временное ограничение доступа к совместно используемым объектам с целью поддержания целостности этих объектов — мера, типичная для систем управления базами данных. В этот же раздел попадают функции для управления распространением прав доступа и для контроля за получением информации путем логического вывода и агрегирования данных (что также типично для СУБД).
Под точностью в Критериях понимается поддержание определенного соответствия между различными частями данных (точность связей) и обеспечение неизменности данных при передаче между процессами (точность коммуникаций). Точность выступает как один из аспектов целостности информации.
Функции надежности обслуживания должны гарантировать, что действия, критичные по времени, будут выполнены ровно тогда, когда нужно — не раньше и не позже, и что некритичные действия нельзя перевести в разряд критичных. Далее, должна быть гарантия, что авторизованные пользователи за разумное время получат запрашиваемые ресурсы. Сюда же относятся функции для обнаружения и нейтрализации ошибок, необходимые для минимизации простоев, а также функции планирования, позволяющие гарантировать время реакции на внешние события.
К области обмена данными относятся функции, обеспечивающие коммуникационную безопасность, то есть безопасность данных, передаваемых по каналам связи. Здесь Европейские Критерии следуют в фарватере рекомендаций X.800, предлагая следующие подзаголовки:
Перечисленные темы мы рассмотрим позднее, в Разд. Особенности информационной безопасности компьютерных сетей , посвященном особенностям информационной безопасности компьютерных сетей.
Набор функций безопасности может специфицироваться с использованием ссылок на заранее определенные классы функциональности. В Европейских Критериях таких классов десять. Пять из них (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.
Обратим внимание на то, что анализ слабых мест производится в контексте целей, декларируемых для объекта оценки. Например, можно примириться с наличием тайных каналов передачи информации, если отсутствуют требования к конфиденциальности. Далее, слабость конкретного защитного механизма может не иметь значения, если она компенсируется другими средствами обеспечения безопасности, то есть если механизм не является критически важным.
При проверке корректности объекта оценки применяются две группы критериев. Первая группа относится к конструированию и разработке системы или продукта, вторая — к эксплуатации. Оцениваются следующие аспекты:
Уровни корректности от E1 до E6 выстроены по нарастанию требований к тщательности оценки. Так, на уровне E1 анализируется лишь общая архитектура объекта — вся остальная уверенность может быть следствием функционального тестирования. На уровне E3 к анализу привлекаются исходные тексты программ и схемы аппаратуры. На уровне E6 требуется формальное описание функций безопасности, общей архитектуры, а также модели политики безопасности. В общем распределение требований по уровням гарантированности в Европейских Критериях соответствует аналогичному распределению для классов безопасности C1 - A1 из "Оранжевой книги".
В 1992 году Гостехкомиссия при Президенте РФ опубликовала пять Руководящих документов, посвященных проблеме защиты от несанкционированного доступа (НСД) к информации [1] . Мы рассмотрим важнейшие из них.
Идейной основой набора Руководящих документов является "Концепция защиты СВТ и АС от НСД к информации". Концепция "излагает систему взглядов, основных принципов, которые закладываются в основу проблемы защиты информации от несанкционированного доступа (НСД), являющейся частью общей проблемы безопасности информации."
В Концепции различаются понятия средств вычислительной техники (СВТ) и автоматизированной системы (АС), аналогично тому, как в Европейских Критериях проводится деление на продукты и системы. Более точно,
Концепция предусматривает существование двух относительно самостоятельных и, следовательно, имеющих отличие направлений в проблеме защиты информации от НСД. Это — направление, связанное с СВТ, и направление, связанное с АС.
Отличие двух направлений порождено тем, что СВТ разрабатываются и поставляются на рынок лишь как элементы, из которых в дальнейшем строятся функционально ориентированные АС, и поэтому, не решая прикладных задач, СВТ не содержат пользовательской информации.
Помимо пользовательской информации при создании АС появляются такие отсутствующие при разработке СВТ характеристики АС, как полномочия пользователей, модель нарушителя, технология обработки информации.
Существуют различные способы покушения на информационную безопасность — радиотехнические, акустические, программные и т.п. Среди них НСД выделяется как
доступ к информации, нарушающий установленные правила разграничения доступа, с использованием штатных средств, предоставляемых СВТ или АС.
Под штатными средствами понимается совокупность программного, микропрограммного и технического обеспечения СВТ или АС.
В Концепции формулируются следующие основные принципы защиты от НСД к информации:
Концепция ориентируется на физически защищенную среду, проникновение в которую посторонних лиц считается невозможным, поэтому нарушитель определяется как
В качестве главного средства защиты от НСД к информации в Концепции рассматривается система разграничения доступа (СРД) субъектов к объектам доступа. Основными функциями СРД являются:
Кроме того, Концепция предусматривает наличие обеспечивающих средств для СРД, которые выполняют следующие функции:
Мы видим, что функции системы разграничения доступа и обеспечивающих средств, предлагаемые в Концепции, по сути близки к аналогичным положениям "Оранжевой книги". Это вполне естественно, поскольку близки и исходные посылки — защита от несанкционированного доступа к информации в условиях физически безопасного окружения.
Технические средства защиты от НСД, согласно Концепции, должны оцениваться по следующим основным параметрам:
Здесь усматривается аналогия с гарантированностью эффективности и корректности в Европейских гармонизированных Критериях, что можно только приветствовать.
Переходя к рассмотрению предлагаемой Гостехкомиссией при Президенте РФ классификации средств вычислительной техники по уровню защищенности от несанкционированного доступа к информации, отметим ее близость к классификации "Оранжевой книги". Процитируем соответствующий Руководящий документ:
Устанавливается семь классов защищенности СВТ от НСД к информации. Самый низкий класс — седьмой, самый высокий — первый.
Классы подразделяются на четыре группы, отличающиеся качественным уровнем защиты:
- первая группа содержит только один седьмой класс;
- вторая группа характеризуется дискреционной защитой и содержит шестой и пятый классы;
- третья группа характеризуется мандатной защитой и содержит четвертый, третий и второй классы;
- четвертая группа характеризуется верифицированной защитой и содержит только первый класс.
Седьмой класс присваивают СВТ, к которым предъявлялись требования по защите от НСД к информации, но при оценке защищенность СВТ оказалась ниже уровня требований шестого класса.
Приведем сводную таблицу распределения показателей защищенности по шести классам СВТ ( Таб. 1 ).
Классификация автоматизированных систем устроена иначе. Снова обратимся к соответствующему Руководящему документу:
Устанавливается девять классов защищенности АС от НСД к информации.
Каждый класс характеризуется определенной минимальной совокупностью требований по защите.
Классы подразделяются на три группы, отличающиеся особенностями обработки информации в АС.
В пределах каждой группы соблюдается иерархия требований по защите в зависимости от ценности (конфиденциальности) информации и, следовательно, иерархия классов защищенности АС.
Третья группа классифицирует АС, в которых работает один пользователь, допущенный ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса — 3Б и 3А.
Вторая группа классифицирует АС, в которых пользователи имеют одинаковые права доступа (полномочия) ко всей информации АС, обрабатываемой и (или) хранимой на носителях различного уровня конфиденциальности.
Группа содержит два класса — 2Б и 2А.
Первая группа классифицирует многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности и не все пользователи имеют право доступа ко всей информации АС.
Группа содержит пять классов — 1Д, 1Г, 1В, 1Б и 1А.
Сведем в таблицу требования ко всем девяти классам защищенности АС ( Таб. 2 ).
Приведем подробное изложение требований к достаточно представительному классу защищенности — 1В. Мы позволяем себе многостраничное цитирование по двум причинам. Во-первых, данные требования, несомненно, важны с практической точки зрения. Лица, отвечающие за информационную безопасность, должны сопоставлять свои действия с Руководящими указаниями, чтобы обеспечить систематичность защитных мер. Во-вторых, брошюры Гостехкомиссии при Президенте РФ являются библиографической редкостью, и ознакомиться с ними в подлиннике затруднительно.
Требования к классу защищенности 1В:
- Подсистема управления доступом:
- должна осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов;
должна осуществляться идентификация терминалов, ЭВМ, узлов сети ЭВМ, каналов связи, внешних устройств ЭВМ по логическим именам и/или адресам;
- должна осуществляться идентификация программ, томов, каталогов, файлов, записей, полей записей по именам;
- должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа;
- должно осуществляться управление потоками информации с помощью меток конфиденциальности. При этом уровень конфиденциальности накопителей должен быть не ниже уровня конфиденциальности записываемой на него информации.
- Подсистема регистрации и учета:
- должна осуществляться регистрация входа/выхода субъектов доступа в систему/из системы, либо регистрация загрузки и инициализации операционной системы и ее программного останова;
- должна осуществляться регистрация выдачи печатных (графических) документов на "твердую" копию;
- должна осуществляться регистрация запуска/завершения программ и процессов (заданий, задач), предназначенных для обработки защищаемых файлов;
- должна осуществляться регистрация попыток доступа программных средств к следующим дополнительным защищаемым объектам доступа: терминалам, ЭВМ, узлам сети ЭВМ, линиям (каналам) связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей;
- должна осуществляться регистрация изменений полномочий субъектов доступа и статуса объектов доступа;
- должен осуществляться автоматический учет создаваемых защищаемых файлов с помощью их дополнительной маркировки, используемой в подсистеме управления доступом. Маркировка должна отражать уровень конфиденциальности объекта;
- должен проводиться учет всех защищаемых носителей информации с помощью их любой маркировки;
- должна осуществляться очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей. Очистка осуществляется двукратной произвольной записью в любую освобождаемую область памяти, использованную для хранения защищаемой информации;
- должна осуществляться сигнализация попыток нарушения защиты.
- Подсистема обеспечения целостности:
- должна быть обеспечена целостность программных средств СЗИ НСД, а также неизменность программной среды, при этом:
- целостность СЗИ НСД проверяется при загрузке системы по контрольным суммам компонент СЗИ, целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ при обработке и (или) хранении защищаемой информации;
- должна осуществляться физическая охрана СВТ (устройств и носителей информации), предусматривающая постоянное наличие охраны территории и здания, где размещается АС, с помощью технических средств охраны и специального персонала, использование строгого пропускного режима, специальное оборудование помещений АС;
- должен быть предусмотрен администратор (служба) защиты информации, ответственный за ведение, нормальное функционирование и контроль работы СЗИ НСД. Администратор должен иметь свой терминал и необходимые средства оперативного контроля и воздействия на безопасность АС;
- должно проводиться периодическое тестирование всех функций СЗИ НСД с помощью специальных программных средств не реже одного раза в год;
- должны быть в наличии средства восстановления СЗИ НСД, предусматривающие ведение двух копий программных средств СЗИ НСД и их периодическое обновление и контроль работоспособности;
- должны использоваться сертифицированные средства защиты.
По существу перед нами — минимум требований, которым необходимо следовать, чтобы обеспечить конфиденциальность защищаемой информации.
"Оранжевая книга" Министерства обороны США и Руководящие документы Гостехкомиссии при Президенте РФ создавались в расчете на централизованные конфигурации, основу которых составляют большие машины. Распределенная организация современных информационных систем требует внесения существенных изменений и дополнений как в политику безопасности, так и в способы проведения ее в жизнь. Появились новые угрозы, для противодействия которым нужны новые функции и механизмы защиты.
Основополагающим документом в области защиты распределенных систем стали рекомендации X.800 [16] . В данном разделе мы рассмотрим эту работу, а также интерпретацию "Критериев" Министерства обороны США для сетевых конфигураций [14] .
Рекомендации X.800 — документ довольно обширный. Мы сосредоточим внимание на специфически сетевых функциях (сервисах) безопасности, а также на необходимых для их реализации защитных механизмах. Одновременно мы познакомимся с основными понятиями данной области информационной безопасности.
Чтобы почувствовать специфику распределенных систем, достаточно рассмотреть такое стандартное средство защиты, как подотчетность. Помимо других целей, записи в регистрационном журнале могут служить доказательством того, что определенный пользователь совершил то или иное действие (точнее, действие было совершено от его имени). В результате пользователь не может отказаться от содеянного и в некоторых случаях несет за это наказание. В распределенных системах действие порой совершается на нескольких компьютерах и, вообще говоря, не исключено, что их регистрационные журналы противоречат друг другу. Так бывает, когда злоумышленнику удается подделать сетевой адрес и имя другого пользователя. Значит, нужны иные средства обеспечения "неотказуемости" (невозможности отказаться) от совершенных действий.
Перечислим сервисы безопасности, характерные для распределенных систем, и роли, которые они могут играть. Вопросы реализации этих сервисов рассматриваются в Разд. Механизмы безопасности .
Данная функция обеспечивает аутентификацию партнеров по общению и аутентификацию источника данных.
Аутентификация партнеров по общению используется при установлении соединения и, быть может, периодически во время сеанса. Она служит для предотвращения таких угроз, как маскарад и повтор предыдущего сеанса связи.
Аутентификация источника данных — это подтверждение подлинности источника отдельной порции данных. Функция не обеспечивает защиты против повторной передачи данных.
Управление доступом обеспечивает защиту от несанкционированного использования ресурсов, доступных по сети.
Данная функция обеспечивает защиту от несанкционированного получения информации. Различают следующие виды конфиденциальности:
Данная функция подразделяется на подвиды в зависимости от того, какой тип общения используют партнеры — с установлением соединения или без такового, защищаются ли все данные или только отдельные поля, обеспечивается ли восстановление в случае нарушения целостности.
Данная функция (невозможность отказаться от совершенных действий) обеспечивает два вида услуг:
Побочным продуктом неотказуемости является аутентификация источника данных.
В Таб. 3 указаны уровни эталонной семиуровневой модели OSI, на которых могут быть реализованы функции безопасности. Отметим, что прикладные процессы в принципе могут взять на себя поддержку всех защитных сервисов.
Для реализации функций безопасности могут использоваться следующие механизмы и их комбинации.
Шифрование подразделяется на симметричное (с секретным ключом, когда знание ключа шифрования влечет знание ключа расшифровки) и асимметричное (с открытым ключом, когда знание ключа шифрования не позволяет узнать ключ расшифровки).
Различают также обратимое и необратимое шифрование. Последнее может использоваться для вычисления криптографических контрольных сумм (хзш-функций, дайджестов, имитовставок).
Механизм электронной подписи включает в себя две процедуры:
Процедура выработки подписи использует информацию, известную только подписывающему порцию данных. Процедура проверки подписи является общедоступной, она не должна позволять найти секретный ключ подписывающего.
При принятии решений по поводу предоставления запрашиваемого типа доступа могут использоваться следующие виды и источники информации:
Механизмы управления доступом могут располагаться на любой из общающихся сторон или в промежуточной точке. В промежуточных точках целесообразно проверять права доступа к коммуникационным ресурсам. Очевидно, требования механизма, расположенного на приемном конце, должны быть известны заранее, до начала общения.
Различают два аспекта целостности: целостность отдельного сообщения или поля информации и целостность потока сообщений или полей информации. Вообще говоря, контроль двух видов целостности осуществляется различными механизмами, хотя контролировать целостность потока, не проверяя отдельные сообщения, едва ли имеет смысл.
Процедура контроля целостности отдельного сообщения (поля) включает в себя два процесса — один на передающей стороне, другой на приемной. На передающей стороне к сообщению добавляется избыточная информация, которая является функцией от сообщения (та или иная разновидность контрольной суммы). На приемной стороне независимо генерируется контрольная сумма полученного сообщения с последующим сравнением результатов. Данный механизм сам по себе не защищает от дублирования сообщений.
Для проверки целостности потока сообщений (то есть для защиты от кражи, переупорядочивания, дублирования и вставки сообщений) используются порядковые номера, временные штампы, криптографическое связывание (когда результат шифрования очередного сообщения зависит от предыдущего) или иные аналогичные приемы.
При общении в режиме без установления соединения использование временных штампов может обеспечить ограниченную форму защиты от дублирования сообщений.
Аутентификация может достигаться за счет использования паролей, личных карточек или иных устройств аналогичного назначения, криптографических методов (когда демонстрируется знание секретного ключа), устройств измерения и анализа биометрических характеристик.
Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней (взаимной). Пример односторонней аутентификации — процедура входа пользователя в систему.
Для защиты от дублирования аутентификационной информации могут использоваться временные штампы и синхронизация часов в узлах сети.
Механизмы дополнения трафика, разумеется, эффективны только в сочетании со средствами обеспечения конфиденциальности, поскольку в противном случае злоумышленнику будет очевиден фиктивный характер дополнительных сообщений.
Маршруты могут выбираться статически или динамически. Оконечная система, зафиксировав неоднократные атаки на определенном маршруте, может отказаться от его использования. На выбор маршрута способна повлиять метка безопасности, ассоциированная с передаваемыми данными.
Механизм нотаризации служит для заверения таких коммуникационных характеристик, как целостность, время, личности отправителя и получателей. Заверение обеспечивается надежной третьей стороной, которая обладает достаточной информацией, чтобы ее заверениям можно было доверять. Обычно нотаризация опирается на механизм электронной подписи.
В Таб. 4 сведены функции и механизмы безопасности. Таблица показывает, какие механизмы (по одиночке или в комбинации с другими) могут использоваться для реализации той или иной функции.
Администрирование средств безопасности включает в себя распространение информации, необходимой для работы функций и механизмов безопасности, а также сбор и анализ информации об их функционировании. Примерами могут служить распространение криптографических ключей, установка значений параметров защиты, ведение регистрационного журнала и т.п.
Концептуальной основой администрирования является информационная база управления безопасностью. Эта база может не существовать как единое (распределенное) хранилище, но каждая из оконечных систем должна располагать информацией, необходимой для проведения в жизнь избранной политики безопасности.
Усилия администратора средств безопасности должны распределяться по трем направлениям:
Среди действий, относящихся к системе в целом, отметим поддержание актуальности политики безопасности, взаимодействие с другими административными службами, реагирование на происходящие события, аудит и безопасное восстановление.
Администрирование функций безопасности включает в себя определение защищаемых объектов, выработку правил подбора механизмов безопасности (при наличии альтернатив), комбинирование механизмов для реализации функции безопасности, взаимодействие с другими администраторами для обеспечения согласованной работы.
Обязанности администратора механизмов безопасности определяются перечнем задействованных механизмов. Типичный список таков:
Мы видим, что администрирование средств безопасности в распределенной среде имеет много особенностей по сравнению с централизованными системами.
В 1987 году Национальный центр компьютерной безопасности США выпустил в свет интерпретацию "Оранжевой книги" для сетевых конфигураций [14] . Данный документ состоит из двух частей. Первая содержит собственно интерпретацию, во второй рассматриваются сервисы безопасности, специфичные или особенно важные для сетевых конфигураций.
В первой части вводится минимум новых понятий. Важнейшее из них — сетевая надежная вычислительная база, распределенный аналог надежной вычислительной базы изолированных систем. Сетевая надежная вычислительная база формируется из всех частей всех компонентов сети, обеспечивающих информационную безопасность. Надежная сетевая система должна обеспечивать такое распределение защитных механизмов, чтобы общая политика безопасности проводилась в жизнь несмотря на уязвимость коммуникационных путей и на параллельную, асинхронную работу компонентов.
Не существует прямой зависимости между вычислительными базами компонентов, рассматриваемых как изолированные системы, и фрагментами сетевой вычислительной базы. Более того, нет прямой зависимости и между уровнями безопасности отдельных компонентов и уровнем безопасности всей сетевой конфигурации. Например, в результате объединения двух систем класса B1, обладающих несовместимыми правилами кодирования меток безопасности, получается сеть, не удовлетворяющая требованию обеспечения целостности меток. В качестве противоположного примера рассмотрим объединение двух компонентов, один из которых сам не обеспечивает протоколирование действий пользователя, но передает необходимую информацию другому компоненту, который и ведет протокол. В таком случае сеть в целом, несмотря на слабость компонента, удовлетворяет требованию подотчетности.
Чтобы понять суть положений, вошедших в первую часть, рассмотрим интерпретацию требований к классу безопасности C2. Первое требование к этому классу — поддержка произвольного управления доступом. Интерпретация предусматривает различные варианты распределения сетевой надежной вычислительной базы по компонентам и, соответственно, различные варианты распределения механизмов управления доступом. В частности, некоторые компоненты, закрытые от прямого доступа пользователей (например, коммутаторы пакетов, оперирующие на третьем уровне семиуровневой модели OSI), могут вообще не содержать подобных механизмов.
Пользователь осуществляет доступ к удаленному ресурсу посредством суррогатного процесса, выполняющегося на удаленной системе от его имени. Данный процесс подвергается стандартным локальным процедурам контроля доступа. Интерпретация предусматривает различные способы ассоциирования идентификатора пользователя с суррогатным процессом. Может существовать единая идентификационная база данных, доступная каждому компоненту; могут быть реализованы лишь локальные базы, и тогда суррогатный процесс выполняется от имени незарегистрированного пользователя или по некоторым правилам получает идентификатор кого-либо из локальных пользователей.
Идентификация групп пользователей может строиться на основе сетевых адресов хостов или (под)сетей. В то же время регистрационный журнал должен содержать достаточно информации для ассоциирования действий с конкретным пользователем. Сетевой адрес может являться частью глобального идентификатора пользователя.
В принципе возможен централизованный контроль доступа, когда решения принимает специальный сервер авторизации. Возможен и смешанный вариант, когда сервер авторизации разрешает соединение двух хостов, а дальше в дело вступают локальные механизмы хоста, содержащего объект доступа.
Аналогично, идентификация и аутентификация пользователей может производиться как централизованно (соответствующим сервером), так и локально — той системой, с которой пользователь непосредственно взаимодействует. Возможна передача идентификационной и аутентификационной информации между хостами (чтобы избавить пользователя от многократной аутентификации). При передаче аутентификационная информация должна быть защищена не слабее, чем на каждом из компонентов сетевой конфигурации.
В идентификации и аутентификации могут нуждаться не только пользователи, но и компоненты сети, такие как хосты.
Регистрационная информация в сетевом случае может включать в себя записи новых видов, например, сведения об установлении и разрыве соединений, о потенциальном нарушении целостности данных (в частности, ввиду неправильной маршрутизации датаграмм), об изменениях в конфигурации сети. "Адресное пространство пользователей" становится распределенным, а в число регистрируемых событий попадают действия с удаленными объектами (открытие, переименование и т.п.).
При ведении регистрационного журнала могут использоваться локальные или глобальные синхронизированные часы.
Регистрационные журналы разных компонентов сети должны быть согласованы между собой; должны предоставляться средства для комплексного анализа совокупности регистрационных журналов с целью глобального отслеживания деятельности пользователей.
Возможно выделение в сети одного или нескольких серверов протоколирования и аудита, обслуживающих другие компоненты, которые не имеют ресурсов или по иным причинам не желают вести протоколирование самостоятельно.
Переходя к рассмотрению вопросов гарантированности, отметим, что каждая часть сетевой надежной вычислительной базы, расположенная на отдельном компоненте, должна поддерживать отдельную область для собственного выполнения, защищенную от внешних воздействий.
Интерпретация отличается от самих "Критериев" учетом динамичности сетевых конфигураций. Предусматривается наличие средств проверки подлинности и корректности функционирования компонентов перед их включением в сеть, наличие протокола взаимной проверки компонентами живучести и корректности функционирования друг друга, доступность средств оповещения администратора о неполадках в сети. Сетевая конфигурация должна быть устойчива к отказам отдельных компонентов или коммуникационных путей.
Динамичность, согласно Интерпретации, должна найти отражение в Руководстве администратора по средствам безопасности. Помимо прочих, это Руководство обязано освещать такие темы, как аппаратное конфигурирование сети, учет последствий подключения новых компонентов или отключения старых.
В качестве еще одного отличительного момента Интерпретации отметим повышенное внимание к целостности информации вообще и меток безопасности в частности (мы переходим к рассмотрению некоторых аспектов принудительного управления доступом, характерного для уровня безопасности B). Для контроля целостности меток и для их защиты от нелегального изменения в Интерпретации рекомендуется широкое использование криптографических методов. Далее, чтобы принудительное управление доступом в распределенной конфигурации имело смысл, совокупность уровней секретности и категорий должна поддерживаться централизованно. В этом одно из принципиальных отличий от произвольного управления доступом.
В целом следует отметить довольно очевидный характер первой части Интерпретации, что, впрочем, является прямым следствием выбранного методологического подхода. Описание существенно новых сервисов и механизмов вынесено во вторую часть документа. Если первая часть посвящена в основном управлению доступом к информации, то во второй нашли отражение все основные аспекты безопасности — конфиденциальность, целостность и доступность.
Рассматриваемый документ создавался примерно в то же время, что и рекомендации X.800. Естественно, что две рабочие группы обменивались информацией, поэтому во многих отношениях их подходы схожи. Имеются, однако, и важные различия. Интерпретация не замыкается на эталонной семиуровневой модели, ее цель — оценка безопасности всей распределенной конфигурации, а не только чисто сетевых аспектов. Рекомендации X.800 в основном имеют дело с функциональностью (с сервисами безопасности) и в меньшей степени с защитными механизмами. В Разд. Гармонизированные критерии Европейских стран анализируется еще одна важнейшая характеристика — гарантированность.
Основой функционирования сетей вообще и коммуникационной безопасности в частности являются сетевые протоколы. Многие защитные механизмы встраиваются в протоколы. От протоколов зависит защита системы от тупиков и иных обстоятельств, способных повлиять на доступность сервисов, а также наличие средств обнаружения ситуаций недоступности. Протоколы влияют и на возможность поддержания целостности данных.
Среди защитных механизмов в сетевых конфигурациях на первом месте стоит криптография, помогающая поддерживать как конфиденциальность, так и целостность. Следствием использования криптографических методов является необходимость реализации механизмов управления ключами.
Для поддержания целостности (в аспектах, относящихся к коммуникациям) используются аутентификация, контроль целостности полей и механизмы обеспечения неотказуемости. Мы не останавливаемся подробно на этом и предыдущем сервисах, поскольку они подробно рассматривались в связи с рекомендациями X.800.
Новым по сравнению с X.800 является рассмотрение вопросов доступности. Сетевой сервис перестает быть доступным, когда пропускная способность коммуникационных каналов падает ниже минимально допустимого уровня или сервис не в состоянии обслуживать запросы. Удаленный ресурс может стать недоступным и вследствие нарушения равноправия в обслуживании пользователей. Надежная система должна быть в состоянии обнаруживать ситуации недоступности, уметь возвращаться к нормальной работе и противостоять атакам на доступность.
Для обеспечения непрерывности функционирования могут применяться следующие защитные меры:
С точки зрения оценки надежности систем, критерии Разд. Гармонизированные критерии Европейских стран дополняют "Оранжевую книгу". Каждый сервис безопасности рассматривается независимо и может получить одну из трех положительных оценок. Таким образом, общая оценка сетевой конфигурации выглядит примерно так: класс безопасности C2, сервис_1 — удовлетворительно, сервис_2 — хорошо и т.д. Заказчик, зная свои потребности, в состоянии принять решение о пригодности той или иной конфигурации.
В Разд. Критерии оценки надежных компьютерных систем ("Оранжевая книга" Министерства обороны США) Интерпретации излагается подход к оценке надежности сетевой конфигурации как единого целого. В то же время имеет право на существование и другой взгляд, когда сеть составляется из предварительно проверенных компонентов, а общая оценка по определенным правилам выводится из их "рейтинга". Подобная точка зрения является предметом рассмотрения приложений к Интерпретации, где анализируются три главных вопроса:
Предварительным условием надежности сетевой конфигурации является наличие единой политики безопасности, с которой должны быть согласованы поведение каждого компонента и характер связей между ними. В Интерпретации рассматриваются следующие аспекты политики безопасности:
Одним из важнейших в "Оранжевой книге" является понятие монитора обращений (см. Разд. Основные понятия ). Применительно к структурированию сетевой конфигурации можно сформулировать следующее утверждение, дающее достаточное условие корректности фрагментирования монитора обращений.
Утверждение 1. Пусть каждый субъект (то есть процесс, действующий от имени какого-либо пользователя) заключен внутри одного компонента и может осуществлять непосредственный доступ к объектам только в пределах этого компонента. Пусть, далее, каждый компонент содержит свой монитор обращений, отслеживающий все локальные попытки доступа, и все мониторы проводят в жизнь согласованную политику безопасности. Пусть, наконец, коммуникационные каналы, связывающие компоненты, сохраняют конфиденциальность и целостность передаваемой информации. Тогда совокупность всех мониторов образует единый монитор обращений для всей сетевой конфигурации.
Истинность этого утверждения непосредственно следует из определения монитора обращений.
Отметим разумность структурирования на компоненты, содержащие собственные мониторы обращений. Обычно каждый такой компонент предоставляет законченный набор услуг, а, значит, его выделение естественно и целесообразно не только с точки зрения безопасности, но и с функциональной точки зрения.
Таким образом, сетевые конфигурации рекомендуется структурировать на компоненты, предоставляющие определенные виды сервиса и отслеживающие обращения к своим объектам, и на коммуникационные каналы, защищенные надежными сетевыми сервисами (использующими, как правило, криптографические механизмы).
Оценка компонентов производится по обычным критериям "Оранжевой книги" с одной важной оговоркой. Каждый компонент, вообще говоря, не обязан поддерживать все перечисленные выше аспекты политики безопасности. В таком случае к нему нужно применять соответствующее подмножество критериев. Компоненты, поддерживающие лишь часть аспектов политики безопасности, должны обладать программными и/или протокольными интерфейсами, чтобы получить недостающие им сервисы от других компонентов (предоставляющих такую возможность).
При оценке сетевой конфигурации принимается во внимание тип компонентов и присвоенный им класс безопасности. Комбинируя четыре аспекта политики безопасности, каждый из которых может независимо поддерживаться или не поддерживаться, получаем 15 типов компонентов и их комбинаций (случай, когда не поддерживается ни один аспект, не рассматривается). Как правило, условия корректности комбинаций и итоговый класс безопасности очевидным образом следуют из обычных критериев. Так, при объединении двух компонентов, поддерживающих произвольное управление доступом, необходимо, чтобы был определен протокол передачи идентификационной информации, на которой основываются решения о предоставлении запрашиваемого вида доступа. Политика безопасности каждого компонента и их объединения должна быть согласована с общей политикой. Итоговый класс безопасности объединения равен минимальному из классов, присвоенных компонентам.
При объединении компонента с произвольным управлением доступом и компонента, поддерживающего идентификацию и аутентификацию, должны сохраниться возможности обоих компонентов и, кроме того, для классов C2 и выше, необходимо наличие интерфейса к компонентам протоколирования и аудита. Если компонент идентификации отнесен к классу безопасности C2, то итоговый класс объединения совпадает с классом компонента с добровольным управлением доступом.
Мы не будем останавливаться на всех возможных способах построения составных компонентов.
|
|
|
| Информационная безопасность | Содержание | Практический подход к созданию и поддержанию режима информационной безопасности |
| Copyright ╘ 1993-2000, Jet Infosystems |
