2.4.2.Технологическая гарантированность.
Технологическая гарантированность охватывает весь жизненный цикл системы, то есть периоды проектирования, реализации, тестирования, продажи и сопровождения. Все перечисленные действия должны выполняться в соответствии с жесткими стандартами, чтобы обезопаситься от утечки информации и нелегальных "закладок".
Первое, на что обычно обращают внимание, это тестирование. Изготовитель или поставщик выполняет набор тестов, документирует его и предоставляет на рассмотрение аттестационной комиссии, которая проверяет полноту набора и, быть может, выполняет свои тесты. Вообще говоря, тестированию подлежат как собственно механизмы безопасности, так и пользовательский интерфейс к ним. Тесты должны показать, что защитные механизмы функционируют в соответствии со своим описанием и что не существует очевидных способов обхода или разрушения защиты. Тесты должны продемонстрировать действенность средств управления доступом, защищенность регистрационной и аутентификационной информации. Должна быть уверенность, что надежную вычислительную базу нельзя привести в состояние, когда она перестанет обслуживать пользовательские запросы (пожалуй, это единственное упоминание в "Оранжевой книге" такого аспекта информационной безопасности, как доступность).
Верификация описания архитектуры — это выполненное автоматически формальное доказательство того, что архитектура системы соответствует сформулированной политике безопасности. Национальный центр компьютерной безопасности США располагает двумя системами для проведения подобных формальных доказательств — Gypsy Verification Environment (GVE) компании Computational Logic, Inc. и Formal Development Methodology (FDM) корпорации UNISYS.
Средства конфигурационного управления защищают надежную систему в процессе проектирования, реализации и сопровождения. Конфигурационное управление включает в себя идентификацию, протоколирование и анализ всех изменений, вносимых в надежную вычислительную базу (независимо от того, идет ли речь об аппаратуре или программах), а также (что прямо следует из названия) управление процессом внесения изменений.
Конфигурационное управление давно и широко используется разработчиками программного обеспечения отнюдь не только (и не столько) по соображениям безопасности. Специфика подхода "Оранжевой книги" — в тотальном контроле за изменениями и в строгой дисциплине их проведения.
Надежное распределение защищает систему в процессе ее передачи от поставщика клиенту. Оно включает в себя два комплекса мер — по защите и по проверке. Защитная часть работает на пути от поставщика к клиенту. Она позволяет поставщику утверждать, что клиент получил именно то, поставщик отгрузил, что передана нужная версия, все последние изменения, и что по дороге система не была вскрыта и в нее не были внесены изменения. Среди защитных механизмов — надежная упаковка, предохраняющая от вредного воздействия окружающей среды, надежная транспортировка и, наконец, надежная инсталляция аппаратуры и программ.
Проверочные меры применяются клиентом, чтобы убедиться, что он получил именно то, что заказал, и что система не подверглась нелегальным изменениям. Клиент должен убедиться, что полученный им продукт—точная копия эталонного варианта, имеющегося у поставщика. Для этого существует целый спектр методов, начиная от проверок серийных номеров аппаратных компонентов и кончая верификацией контрольных сумм программ и данных. Следует отметить, что современная практика поставки программного обеспечения на CD-ROM'ax существенно затрудняет (по сравнению с дискеточным вариантом) внесение нелегальных изменений.
2.5.Документация.
Документация — необходимое условие гарантированной надежности системы и, одновременно, — инструмент проведения политики безопасности. Без документации люди не будут знать, какой политике следовать и что для этого нужно делать.
Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома:
• Руководство пользователя по средствам безопасности.
• Руководство администратора по средствам безопасности.
• Тестовая документация.
• Описание архитектуры.
Разумеется, на практике требуется еще, по крайней мере, одна книга — письменное изложение политики безопасности данной организации.
Руководство пользователя по средствам безопасности предназначено для обычных, непривилегированных людей. Оно должно содержать сведения о механизмах безопасности и способах их использования. Руководство должно давать ответы по крайней мере на следующие вопросы:
• Как входить в систему? Как вводить имя и пароль? Как менять пароль? Как часто это нужно делать? Как выбирать новый пароль?
• Как защищать файлы и другую информацию? Как задавать права доступа к файлам? Из каких соображений это нужно делать?
• Как импортировать и экспортировать информацию, не нарушая правил безопасности?
• Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?
Руководство администратора по средствам безопасности предназначено и для системного администратора, и для администратора безопасности. В Руководстве освещаются вопросы начального конфигурирования системы, перечисляются текущие обязанности администратора, анализируется соотношения между безопасностью и эффективностью функционирования.
Типичное оглавление Руководства администратора включает в себя следующие пункты:
• Каковы основные защитные механизмы?
• Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?
• Как администрировать средства произвольного управления доступом? Как защищать системную информацию? Как обнаруживать слабые места?
• Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?
• Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности?
• Как генерировать новую, переконфигурированную надежную вычислительную базу?
• Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?
• Как разделить обязанности системного администратора и
оператора?
Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того (вернее, перед тем), тестовая документация должна содержать план тестирования и условия, налагаемые на тестовое окружение.
Описание архитектуры в данном контексте должно включать в себя по крайней мере сведения о внутреннем устройстве надежной вычислительной базы. Вообще говоря, это описание должно быть формальным, допускающим автоматическое сопоставление с политикой безопасности на предмет соответствия требованиям последней. Объем описания архитектуры может оказаться сопоставимым с объемом исходных текстов программной реализации системы.
|
