Важность проблемы информационной безопасности сейчас, к сожалению, очевидна далеко не для всех. Однако даже небольшого размышления достаточно, чтобы понять ее проблемы и сложность, проистекающие как из сложности и разнородности современных информационных систем, так и из необходимости комплексного подхода к безопасности с привлечением законодательных, административных и программно-технических мер.
Введение
Информационной безопасностью занимаются давно. Первоначально это было прерогативой государственных организаций, имеющих дело с секретной информацией или отвечающих за обеспечение режима секретности. В 1983 году министерство обороны США выпустило книгу в оранжевой обложке с названием "Критерии оценки надежных компьютерных систем" (Trusted Computer Systems Evaluation Criteria, TCSEC) [8], положив тем самым начало систематическому распространению знаний об информационной безопасности за пределами правительственных ведомств. Во второй половине 1980-х годов аналогичные по назначению документы были изданы в ряде европейских стран [9]. В 1992 году в России Гостехкомиссия при Президенте РФ издала серию брошюр, посвященных проблеме защиты от несанкционированного доступа [1-5].
Сегодня в России наблюдается всплеск интереса к информационной безопасности, который объясняется в первую очередь развитием банковского бизнеса (хотя, конечно, в защите нуждаются не только банки). В этих условиях ощущается острая нехватка литературы на русском языке, посвященной данной тематике. Пожалуй, сейчас можно рекомендовать лишь работы [6, 7], в которых превосходно излагаются общие вопросы информационной безопасности. В то же время даже человеку, имеющему практически неограниченный доступ к англоязычной литературе, крайне сложно приобрести навыки, полезные на практике. Как строить безопасные, надежные системы? Как поддерживать режим безопасности? "Оранжевая книга" и издания, следующие в ее фарватере, не дают ответов на эти вопросы, поскольку ориентированы в первую очередь на разработчиков информационных систем, а не на пользователей или-системных администраторов. Конечно, основы знать необходимо, однако от основ до практики - "дистанция огромного размера". Да и оценки важности различных аспектов безопасности в государственных и коммерческих структурах весьма различны.
Все сходятся на том, что защитные мероприятия призваны обеспечить конфиденциальностпь, целостносчпь и доступность информации, однако если для режимных государственных организаций на первом месте стоит конфиденциальность, а целостность понимается исключительно как неизменность информации, то для коммерческих структур, вероятно, важнее всего целостность (актуальность) и доступность данных и услуг по их обработке. По сравнению с государственными, коммерческие организации более открыты и динамичны, поэтому вероятные угрозы для них отличаются и количественно, и качественно.
Данная статья открывает серию публикаций, посвященных информационной безопасности коммерческих систем. В качестве методологической основы для изложения программно-технического аспекта защиты выбран подход клиент/сервер. Это объясняется двумя основными причинами. Во-первых, подход клиент/сервер позволяет провести декомпозицию сложной информационной системы, после чего можно относительно независимо рассматривать вопросы защиты отдельных компонентов (сервисов). Во-вторых, ряд защитных услуг реализуется с помощью серверов в строгом смысле этого слова (пример - сервер аутентификации Kerberos).
Стандарты и рекомендации в области информационной безопасности
Существуют разные мнения по поводу практической применимости классического подхода к информационной безопасности, однако в любом случае необходимо владеть базовыми понятиями, введенными по большей части в работах, выполненных по заказу министерства обороны США.
Знание критериев оценки информационной безопасности способно помочь при выборе и комплектовании аппаратно-программной конфигурации. Кроме того, в своей повседневной работе администратор по безопасности вынужден хотя бы до некоторой степени повторять действия сертифицирующих органов, поскольку обслуживаемая система, скорее всего, время от времени претерпевает изменения и нужно, во-первых, оценивать целесообразность модификаций и их последствия, а во-вторых, соответствующим образом корректировать повседневную практику пользования и администрирования. Если знать, на что обращают внимание при сертификации, то можно сконцентрироваться на анализе критически важных аспектов, экономя время и силы и повышая качество защиты.
Критерии оценки надежных компьютерных систем
"Оранжевая книга" министерства обороны США, называемая так по цвету обложки, была впервые опубликована в августе 1983 года. Само название заслуживает комментария - речь идет не о безопасных, а о надежных системах, причем слово "надежный" трактуется так же, как в сочетании "надежный человек" - человек, которому можно доверять.
"Оранжевая книга" поясняет понятие безопасной системы, которая "управляет, посредством соответствующих средств, доступом к информации, так что только должным образом авторизованные лица или процессы, действующие от их имени, получают право читать, писать, создавать и удалять информацию". Очевидно, однако, что абсолютно безопасных систем не существует, что это абстракция. Любую систему можно "взломать", если располагать достаточно большими материальными и временными ресурсами. Есть смысл оценивать лишь степень доверия, которое разумно оказать той или иной системе.
Основные понятия
В "Оранжевой книге" надежная система определяется как "система, использующая достаточные аппаратные и программные средства, чтобы обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа".
Степень доверия, или надежность систем, оценивается по двум основным критериям:
- Политика безопасности - набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь имеет право оперировать с определенными наборами данных. Чем надежнее система, тем строже и-многообразнее должна быть политика безопасности. В зависимости от сформулированной политики можно выбирать конкретные механизмы, обеспечивающие безопасность системы. Политика безопасности - это активный компонент защиты, включающий в себя анализ возможных угроз и выбор мер противодействия.
- Гарантированность - мера доверия, которая может быть оказана архитектуре и реализации системы. Гарантированность может проистекать как из тестирования, так и из проверки (формальной или нет) общего замысла и исполнения системы в целом и ее компонентов. Гарантированность показывает, насколько корректны механизмы, отвечающие за проведение в жизнь политики безопасности. Гарантированность можно считать пассивным компонентом защиты, надзирающим за самими защитниками.
Важным средством обеспечения безопасности является механизм подотчетности или протоколирования. Надежная система должна фиксировать все события, касающиеся безопасности, а ведение протоколов дополняется аудитом - анализом регистрационной информации.
Концепция надежной вычислительной базы является центральной при оценке степени гарантированности, с которой систему можно считать надежной. Надежная вычислительная база - это совокупность защитных механизмов компьютерной системы в целом, отвечающих за проведение в жизнь политики безопасности. Надежность вычислительной базы определяется исключительно ее реализацией и корректностью исходных данных, вводимых административным персоналом. Вообще говоря, компоненты вне вычислительной базы могут не быть надежными, однако это не должно влиять на безопасность системы в целом. В результате, для оценки надежности компьютерной системы достаточно рассмотреть только ее вычислительную базу, которая, как можно надеяться, достаточно компактна.
Основное назначение надежной вычислительной базы - выполнять функции монитора обращений, то есть контролировать допустимость выполнения субъектами определенных операций над объектами. Монитор проверяет каждое обращение пользователя к программам или данным на предмет их согласованности со списком допустимых действий.
От монитора обращений требуется выполнение трех свойств:
- Изолированность. Монитор должен быть защищен от отслеживания своей работы.
- Полнота. Монитор вызывается при каждом обращении, причем не должно быть способов его обхода.
- Верифицируемость. Монитор должен быть компактным, чтобы его можно было проанализировать и протестировать, при наличии, конечно, уверенности в полноте тестирования.
Реализация монитора обращений называется ядром безопасности, который является основой построения всех защитных механизмов. Помимо перечисленных выше свойств монитора обращений, ядро должно гарантировать собственную неизменность.
Границу надежной вычислительной базы называют периметром безопасности. Как уже указывалось, от компонентов, лежащих вне периметра безопасности, вообще говоря, не требуется надежности. С развитием распределенных систем понятию "периметр безопасности" все чаще придают другой смысл, имея в виду границу владений определенной организации. То, что внутри владений, считается надежным, а то, что вне - нет. Связь между внутренним и внешним мирами осуществляют посредством шлюзовой системы, которая по идее способна противостоять потенциально ненадежному или даже враждебному окружению.
Основные элементы политики безопасности
Согласно "Оранжевой книге", политика безопасности должна включать в себя по крайней мере следующие элементы:
Рассмотрим перечисленные элементы более подробно.
Добровольное управление доступом. Добровольное управление доступом - это метод ограничения доступа к объектам, основанный на учете личности субъекта или группы, в которую субъект входит. Добровольность управления состоит в том, что некоторое лицо (обычно владелец объекта) может по своему усмотрению давать другим субъектам или отбирать у них права доступа к объекту.
С концептуальной точки зрения текущее состояние прав доступа при добровольном управлении описывается матрицей, в строках которой перечислены субъекты, а в столбцах - объекты. В клетках, расположенных на пересечении строк и столбцов, записываются способы доступа, допустимые для субъекта по отношению к объекту - например: чтение, запись, выполнение, возможность передачи прав другим субъектам и т. п.
Очевидно, прямолинейное представление подобной матрицы вследствие ее больших размеров невозможно, да и не нужно, поскольку она разрежена и большинство клеток в ней пусты. В операционных системах более компактное представление матрицы доступа основывается или на структурировании совокупности субъектов (владелец/группа/прочие как в ОС UNIX), или на механизме списков управления доступом, когда матрица представляется по столбцам и для каждого объекта перечисляются субъекты вместе с их правами доступа. За счет использования метасимволов можно компактно описывать группы субъектов, удерживая тем самым размеры списков управления доступом в разумных пределах.
Большинство операционных систем и СУБД реализуют именно добровольное управление доступом. Главное его достоинство - гибкость, главные недостатки - рассредоточенность управления и сложность централизованного контроля, а также оторванность прав доступа от данных, что позволяет копировать секретную информацию в общедоступные файлы.
Безопасность повторного использования объектов. Безопасность повторного использования объектов - важное на практике дополнение средств управления доступом, предохраняющее от случайного или преднамеренного извлечения секретной информации из "мусора". Безопасность повторного использования должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т.п.), для дисковых блоков и магнитных носителей в целом.
Важно обратить внимание на следующий момент. Поскольку информация о субъектах также представляет собой объект, необходимо позаботиться о безопасности "повторного использования субъектов". Когда пользователь покидает организацию, следует не только лишить его возможности входа в систему, но и запретить доступ ко всем объектам. В противном случае, новый сотрудник может получить ранее использовавшийся идентификатор, а с ним и все права своего предшественника.
Современные интеллектуальные периферийные устройства усложняют обеспечение безопасности повторного использования объектов. Действительно, принтер может буферизовать несколько страниц документа, которые останутся в памяти даже после окончания печати. Необходимо предпринять специальные меры, чтобы "вытолкнуть" их оттуда. Впрочем, иногда организации защищаются от повторного использования слишком ревностно - путем уничтожения магнитных носителей. На практике заведомо достаточно троекратной записи случайных последовательностей бит.
Метки безопасности. Для реализации принудительного управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка субъекта описывает его благонадежность, метка объекта - степень закрытости содержащейся в нем информации.
Согласно "Оранжевой книге", метки безопасности состоят из двух частей - уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:
Впрочем, для разных систем набор уровней секретности может различаться.
Категории образуют неупорядоченный набор. Их назначение - описать предметную область, к которой относятся данные. В военном окружении каждая категория может соответствовать, например, определенному виду вооружений. Механизм категорий позволяет разделить информацию по отсекам, что способствует лучшей защищенности. В последующем мы подробно рассмотрим правила принудительного управления доступом, пока же отметим, что субъект не может получить доступ к "чужим" категориям, даже если его уровень благонадежности "совершенно секретно". Специалист по танкам не узнает тактико-технические данные самолетов.
Главная проблема, которую необходимо решать в связи с метками, это обеспечение их целостности. Во-первых, не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши. Во-вторых, при любых операциях с данными метки должны оставаться правильными. В особенности это относится к экспорту и импорту данных. Например, печатный документ должен открываться заголовком, содержащим текстовое и/или графическое представление метки безопасности. Аналогично при передаче файла по каналу связи должна передаваться и ассоциированная с ним метка, причем в таком виде, чтобы удаленная система могла ее разобрать, несмотря на возможные различия в уровнях секретности и наборе категорий.
Одним из средств обеспечения целостности меток безопасности является разделение устройств на многоуровневые и одноуровневые. На многоуровневых устройствах может храниться информация разного уровня секретности (точнее, лежащая в определенном диапазоне уровней). Одноуровневое устройство можно рассматривать как вырожденный случай многоуровневого, когда допустимый диапазон состоит из одного уровня. Зная уровень устройства, система может решить, допустимо ли записывать на него информацию с определенной меткой. Например, попытка напечатать совершенно секретную информацию на принтере общего пользования с уровнем "несекретно" потерпит неудачу.
Метки безопасности, ассоциируемые с субъектами, более подвижны, чем метки объектов. Субъект может в течение сеанса работы с системой изменять свою метку, естественно, не выходя за предопределенные для него рамки. Иными словами, он может сознательно занижать свой уровень благонадежности, чтобы уменьшить вероятность непреднамеренной ошибки. Вообще, принцип минимизации привилегий - весьма разумное средство защиты.
Принудительное управление доступом. Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта.
Субъект может читать информацию из объекта, если уровень секретности субъекта не ниже, чем у объекта, а все категории, перечисленные в метке безопасности объекта, присутствуют в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Смысл сформулированного правила понятен - читать можно только то, что положено.
Субъект может записывать информацию в объект, если метка безопасности объекта доминирует над меткой субъекта. В частности, "конфиденциальный" субьект может писать в секретные файлы, но не может - в несекретные (разумеется, должны также выполняться ограничения на набор категорий). На первый взгляд подобное ограничение может показаться странным, однако оно вполне разумно.Ни при каких операциях уровень секретности информации не должен понижаться, хотя обратный процесс вполне возможен. Посторонний человек может случайно узнать секретные сведения и сообщить их куда следует, однако лицо, допущенное к работе с секретными документами, не имеет права раскрывать их содержание простому смертному.
Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов, на месте которых могут оказаться даже системные администраторы. После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение "разрешить доступ к объекту Х еще и для пользователя Y". Конечно, можно изменить метку безопасности пользователя Y, но тогда он скорее всего получит доступ ко многим дополнительным объектам, а не толькок Х.
Принудительное управление доступом реализовано во многих вариантах операционных систем и СУБД, отличающихся повышенными мерами безопасности. В частности, такие варианты существуют для SunOS и СУБД Ingres. Независимо от практического использования принципы принудительного управления являются удобным методологическим базисом для начальной классификации информации и распределения прав доступа. Удобнее мыслить в терминах уровней секретности и категорий, чем заполнять неструктурированную матрицу доступа. Впрочем, в реальной жизни добровольное и принудительное управление доступом сочетается в рамках одной системы, что позволяет использовать сильные стороны обоих подходов.
Подотчетность
Если понимать политику безопасности узко, то есть как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности - в каждый момент времени знать, кто работает в системе и что он делает. Средства подотчетности делятся на три категории:
Идентификация и аутентификация. Каждый пользователь, прежде чем получить право совершать какиелибо действия в системе, должен идентифицировать себя. Обычный способ идентификации - ввод имени пользователя при входе в систему. В свою очередь, система должна проверить подлинность личности пользователя, то есть что он является именно тем, за кого себя выдает. Стандартное средство проверки подлинности (аутентификации) - пароль, хотя в принципе могут использоваться также разного рода личные карточки, биометрические устройства (сканирование радужной оболочки глаза или отпечатков пальцев) или их комбинация.
Идентификация и аутентификация - первый и важнейший программно-технический рубеж информационной безопасности. Если не составляет проблемы получить доступ к системе под любым именем, то другие механизмы безопасности, например, управление доступом, очевидно, теряют смысл. Очевидно и то, что без идентификации пользователей невозможно протоколирование их действий. В силу перечисленных причин проверке подлинности должно придаваться первостепенное значение, Существует целая серия публикаций правительственных ведомств США, разъясняющих вопросы аутентификации и, в частности, проблемы, связанные с паролями. Например, декларируется, что пользователю должно быть позволено менять свой пароль, что пароли, как правило, должны генерироваться компьютером, что пользователю должна предоставляться некоторая регистрационная информация (дата и время последнего входа в систему и т.п.).
Предоставление надежного пути. Надежный путь связывает пользователя непосредственно с надежной вычислительной базой, минуя другие, потенциально опасные компоненты системы. Цель предоставления надежного пути - дать пользователю возможность убедиться в подлинности обслуживающей его системы.
Относительно несложно реализовать надежный путь, если используется неинтеллектуальный терминал - достаточно иметь зарезервированную управляющую последовательность, конечно при условии защищенности линии связи между терминалом и системой. В случае общения пользователя с интеллектуальным терминалом, ПК или рабочей станцией задача обеспечения надежного пути становится чрезвычайно сложной, если вообще разрешимой. Как гарантировать, что пользователь взаимодействует с подлинной программой login, а не с "Троянским конем"? Возможно, по этой причине о предоставлении надежного пути упоминают редко, хотя на практике данный аспект весьма важен.
Анализ регистрационной информации. Аудит имеет дело с действиями, событиями, так или иначе затрагивающими безопасность системы. К числу таких событий относятся:
Можно назвать и другие события - например, смену набора регистрируемых действий. Полный перечень событий, потенциально подлежащих регистрации, зависит от избранной политики безопасности и от специфики системы.
Если фиксировать все события, объем регистрационной информации, скорее всего, будет расти слишком быстро, а ее эффективный анализ станет невозможным. "Оранжевая книга" предусматривает наличие средств выборочного протоколирования, как в отношении пользователей, когда слежение осуществляется только за подозрительными личностями, так и в отношении событий.
Протоколирование помогает следить за пользователями и реконструировать прошедшие события. Слежка важна в первую очередь как профилактическое средство. Можно надеяться, что многие воздержатся от нарушений безопасности, зная, что их действия фиксируются. Реконструкция событий позволяет проанализировать случаи нарушений, понять, почему они стали возможны, оценить размеры ущерба и принять меры по исключению подобных нарушений в будущем.
При протоколировании события записывается по крайней мере следующая информация:
Необходимо подчеркнуть важность не только сбора информации, но и ее регулярного и целенаправленного анализа. В плане анализа выгодное положение занимают средства аудита СУБД, поскольку к регистрационной информации могут естественным образом применяться произвольные SQL-запросы. Следовательно, появляется возможность для выявления подозрительных действий применять сложные эвристики.
Гарантированность
Гарантированность - это мера уверенности, с которой можно утверждать, что для проведения в жизнь сформулированной политики безопасности выбран подходящий набор средств и что каждое из этих средств правильно исполняет отведенную ему роль.
В "Оранжевой книге" рассматривается два вида гарантированности - операционная и технологическая. Первая относится к архитектурным и реализационным аспектам системы, а вторая - к методам построения и сопровождения.
Операционная гарантированность включает в себя проверку следующих элементов:
Операционная гарантированность - это способ убедиться в том, что архитектура системы и ее реализация действительно проводят в жизнь избранную политику безопасности.
Архитектура системы должна способствовать реализации мер безопасности или прямо поддерживать их. Примеры подобных архитектурных решений в рамках аппаратуры и операционной системы - разделение команд по уровням привилегированности, защита различных процессов от взаимного влияния за счет выделения каждому своего виртуального пространства, особая защита ядра ОС.
В принципе меры безопасности не обязательно должны быть заранее встроены в систему - достаточно принципиальной возможности дополнительной установки защитных продуктов. Так, сугубо ненадежная система MS-DOS может быть улучшена за счет средств проверки паролей доступа к компьютеру и/или жесткому диску, за счет борьбы с вирусами путем отслеживания попыток записи в загрузочный сектор CMOS-средствами и т.п. Тем не менее, по-настоящему надежная система должна изначально проектироваться с акцентом на механизмы безопасности.
Среди архитектурных решений, предусматриваемых "Оранжевой книгой", упомянем следующие:
Целостность системы в данном контексте означает, что аппаратные и программные компоненты надежной вычислительной базы работают должным образом и что имеется аппаратное и программное обеспечение для периодической проверки целостности.
Анализ тайных каналов передачи информации - тема, специфичная для режимных систем, когда главное - обеспечить конфиденциальность информации. Тайным называется канал передачи информации, не предназначенный для обычного использования. Шпионская аналогия - горшок с геранью в окне как сигнал опасности. Различают тайные каналы с памятью и временные (ударение на "ы"). Тайные каналы с памятью используют изменения хранимых объектов. Тайным знаком может быть размер файла, имя файла (составленное, например, из входного имени и пароля атакуемого субъекта), число пробелов между словами и т.д. Тайный канал считается быстрым, если с его помощью можно передавать 100 или более бит в секунду.
Временные каналы передают информацию за счет изменения временных характеристик процессов - времени обработки запроса, например. Когда-то давно мой товарищ, Андрей Ходулев, написал программу, угадывавшую мысли. Точнее, она отгадывала задуманное число (от 1 до 4). Человеку предлагалось в уме проделать определенные вычисления, естественно, не сообщая программе ответ. "Соль" программы состояла в том, что для разных чисел некоторые вычисления проделать легко, а для других - трудно. Анализируя распределение времени, затраченного на вычисления, программа угадывала задуманное число. Человек, сам того не ведая, передавал программе информацию по тайному временному каналу.
Обычно тайные каналы используются не столько для передачи информации от одного злоумышленника другому, сколько для получения злоумышленником сведений от внедренного в систему "Троянского коня".
Не очень понятно, как на практике, в распределенной системе, выявлять тайные каналы (хотя, после выявления пропускную способность оценить можно). Как следует из предыдущего рассмотрения, тайным каналом может служить почти все что угодно, а скорости современных процессоров и периферийных устройств делают опасными даже прямолинейные способы передачи. Вероятно, только для статичной конфигурации можно с разумной полнотой описать возможные тайные каналы передачи информации.
Надежное администрирование в трактовке "Оранжевой книги" означает всего лишь, что должны быть логически выделены три роли: системного администратора, системного оператора и администратора безопасности. Физически эти обязанности может выполнять один человек, но, в соответствии с принципом минимизации привилегий, в каждый момент времени он должен выполнять только одну из трех ролей. Конкретный набор обязанностей администраторов и оператора зависит от специфики организации.
Надежное восстановление после сбоев - вещь необходимая, однако ее реализация может быть сопряжена с серьезными техническими трудностями. Прежде всего должна быть сохранена целостность информации и, в частности, целостность меток безопасности. В принципе возможна ситуация, когда сбой приходится на момент записи нового файла с совершенно секретной информацией. Если файл окажется с неправильной меткой, информация может быть скомпрометирована. Далее, на период восстановления система не должна оставаться беззащитной. Нельзя допускать промежуточных состояний, когда защитные механизмы полностью или частично отключены, а доступ пользователей разрешен.
Вообще говоря, надежное восстановление включает в себя два вида деятельности: подготовку к сбою (отказу) и собственно восстановление. Подготовка к сбою - это и регулярное выполнение резервного копирования, и выработка планов действий в экстренных случаях, и поддержание запаса резервных компонентов. Восстановление, вероятно, связано с перезагрузкой системы и выполнением ремонтных и/или административных процедур.
Технологическая гарантированность охватывает весь жизненный цикл системы, то есть периоды проектирования, реализации, тестирования, продажи и сопровождения. Все перечисленные действия должны выполняться в соответствии с жесткими стандартами, чтобы обезопаситься от утечки информации и нелегальных "закладок".
Первое, на что обычно обращают внимание, это тестирование. Изготовитель или поставщик выполняет набор тестов, документирует его и предоставляет на рассмотрение аттестационной комиссии, которая проверяет полноту набора и, быть может, выполняет свои тесты. Вообще говоря, тестированию подлежат как собственно механизмы безопасности, так и пользовательский интерфейс к ним. Тесты должны показать, что защитные механизмы функционируют в соответствии со своим описанием и не существует очевидных способов обхода или разрушения защиты. Тесты должны продемонстрировать действенность средств управления доступом, защищенность регистрационной и аутентификационной информации. Должна быть уверенность, что надежную вычислительную базу нельзя привести в состояние, когда она перестанет обслуживать пользовательские запросы (пожалуй, это единственное упоминание в "Оранжевой книге" такого аспекта информационной безопасности, как доступность или обслуживаемость). Верификация описания архитектуры - это выполненное автоматически формальное доказательство того, что архитектура системы соответствует сформулированной политике безопасности. Национальный центр компьютерной безопасности США располагает двумя системами для проведения подобных формальных доказательств - Gypsy Verification Environment (GVE) компании Computational Logic, Inc. и Formal Development Methodology (FDM) корпорации UNISYS.
Средства конфигурационного управления защищают надежную систему в процессе проектирования, реализации и сопровождения. Конфигурационное управление включает в себя идентификацию, протоколирование и анализ всех изменений, вносимых в надежную вычислительную базу независимо от того, идет ли речь об аппаратуре или программах, а также, что прямо следует из названия, управление процессом внесения изменений.
Конфигурационное управление давно и широко используется разработчиками программного обеспечения отнюдь не только и не столько по соображениям безопасности. Специфика подхода "Оранжевой книги" - в тотальном контроле за изменениями и в строгой дисциплине их проведения.
Надежное распределение защищает систему в процессе ее передачи от поставщика клиенту. Оно включает в себя два комплекса мер - по защите и по проверке. Защитная часть работает на пути от поставщика к клиенту. Она позволяет поставщику утверждать - клиент получил именно то, что поставщик отгрузил; что передана нужная версия, содержащая все последние изменения, и что по дороге система не была вскрыта и в нее не были внесены коррективы. Среди защитных механизмов - надежная упаковка, предохраняющая от вредного воздействия окружающей среды, надежная транспортировка и, наконец, надежная инсталляция аппаратуры и программ.
Проверочные меры применяются клиентом, чтобы убедиться, что он получил именно то, что заказал, и система не подверглась нелегальным изменениям. Клиент должен убедиться, что полученный им продукт - точная копия эталонного варианта, имеющегося у поставщика. Для этого существует целый спектр методов, начиная от проверок серийных номеров аппаратных компонентов и кончая верификацией контрольных сумм программ и данных. Следует отметить, что современная практика поставки программного обеспечения на CD-ROM существенно затрудняет, по сравнению, например, с поставкой на дискетах, внесение нелегальных изменений.
Документация
Документация - необходимое условие гарантированной надежности системы и, одновременно, инструмент проведения политики безопасности. Без документации люди не будут знать, какой политике следовать и что для этого нужно делать.
Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома:
Разумеется, на практике требуется еще по крайней мере одна книга - письменное изложение политики безопасности данной организации.
Руководство пользователя по средствам безопасности предназначено для обычных людей, не имеющих каких-либо привилегий доступа к системе. Оно должно содержать сведения о механизмах безопасности и способах их использования. Руководство должно давать ответы, по крайней мере, на следующие вопросы:
- Как входить в систему? Как вводить имя и пароль? Как менять пароль? Как часто это нужно делать? Как выбирать новый пароль?
- Как защищать файлы и другую информацию? Как задавать права доступа к файлам? Из каких соображений это нужно делать?
- Как импортировать и экспортировать информацию, не нарушая правил безопасности?
- Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?
Руководство администратора по средствам безопасности предназначено и для системного администратора,и для администратора безопасности. В Руководстве освещаются вопросы начального конфигурирования системы, перечисляются текущие обязанности администратора, анализируется соотношения между безопасностью и эффективностью функционирования.
Типичное оглавление Руководства администратора включает в себя следующие пункты:
- Каковы основные защитные механизмы?
- Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?
- Как администрировать средства добровольного управления доступом? Как защищать системную информацию? Как обнаруживать слабые места?
- Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?
- Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности?
- Как генерировать новую, переконфигурированную надежную вычислительную базу?
- Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?
- Как разделить обязанности системного администратора и оператора?
Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того (точнее, перед тем), тестовая документация должна содержать план тестирования и требования, предъявляемые к тестовому окружению.
Описание архитектуры в данном контексте должно включать в себя по крайней мере сведения о внутреннем устройстве надежной вычислительной базы. Вообще говоря, это описание должно быть формальным, допускающим автоматическое сопоставление с политикой безопасности на предмет соответствия требованиям последней. Объем описания архитектуры может оказаться сопоставимым с объемом исходных текстов программной реализации системы.
Классы безопасности
"Критерии" министерства обороны США открыли путь к ранжированию информационных систем по степени надежности. В "Оранжевой книге" определяется четыре уровня безопасности - D , С , В и А . Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он пуст и ситуация едва ли когда-нибудь изменится. По мере перехода от уровня С до А к надежности систем предъявляются все более жесткие требования. Уровни С и В подразделяются на классы ( C1, С2, В1, В2, В З ) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности - С1, С2, В1, В2, ВЗ, А1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять оговоренным требованиям.
В данной статье мы не будем останавливаться на подробном описании требований к классам безопасности, а сделаем это позднее, при изложении Руководящих документов Гостехкомиссии при Президенте РФ. Пока отметим лишь, что в "младших" классах политика довольно быстро ужесточается, по существу достигая пика к классу Bl. Напротив, меры гарантированности отнесены в основном в "старшие" классы, начиная с В2. Это подтверждает независимость двух основных групп критериев надежности и методологическую целесообразность их разделения по Европейскому образцу [7].
Распределение требований по классам вызывает ряд конкретных возражений. Неоправданно далеко отодвинуты такие очевидные требования, как извещение о нарушении защиты, конфигурационное управление, безопасный запуск и восстановление после сбоев. Возможно, это оправдано в физически защищенной военной среде, но никак не в коммерческой, когда постоянное слежение за перемещениями сотрудников может быть очень дорогим удовольствием.
Некоторые комментарии
В представленном виде "Критерии" полностью игнорируют коммуникационный аспект, присущий современным распределенным системам. Далее мы покажем, сколь специфична эта область, сколько потенциальных угроз безопасности она содержит, какие новые защитные механизмы следует использовать. Примечательно, что изданные позднее толкования "Критериев" для сетевых конфигураций примерно в три раза толще самой "Оранжевой книги".
Очень важный методологический недостаток "Оранжевой книги" - явная ориентация на производителя и оценщика, а не на покупателя систем. Она не дает ответ на вопрос, как безопасным образом строить систему, как наращивать отдельные компоненты и конфигурацию в целом. "Критерии" рассчитаны на статичные, замкнутые системы, которые, вероятно, доминируют в военной среде, но крайне редки в среде коммерческой. Покупателям нужны более динамичные и структурированные критерии.
Тем не менее следует подчеркнуть, что публикация "Оранжевой книги" без всякого преувеличения стала эпохальным событием в области защиты коммерческих информационных систем. Появился общепризнанный понятийный базис, без которого даже обсуждение проблем безопасности было бы затруднительным. Именно в этом видится главная ценность "Критериев оценки надежных компьютерных систем" министерства обороны США.
В. А. Галатенко Vladimir.Galatenko@jet.msk.su
АО "Инфосистемы Джет"
Литература
[1] Гостехкомиссия России. Руководящий документ. Концепция защиты СВТ и АС от НСД к информации. - Москва, 1992.
[2] Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации. - Москва, 1992.
[3] Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. - Москва, 1992.
[4] Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от НСД в автоматизированных системах и средствах вычислительной техники. - Москва, 1992.
[5] Гостпехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения. - Москва, 1992.
[6] Гайкович В., Першин А. Везопасность электронных банковских систем. - Москва, "Единая Европа", 1994.
[7] Левин В.К. Защита информации в информационно-вычислительных системах и сетях. // "Программирование", М 5, 1994, с. 5-16.
[8] Department of Defense Trusted Computer System Evaliation Criteria. - DoD 5200.28-STD, 1993.
[9] lnformation Technology Security Evaluation Criteria (ITSEC). Harmonised Criteria of France - Germany - the Netherlands - the United Kingdom. - Department of Trade and Industry, London, 1991.
