Технологическая гарантированность

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

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

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

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

Конфигурационное управление давно и широко используется разработчиками программного обеспечения отнюдь не только (и не столько) по соображениям безопасности. Специфика подхода "Оранжевой книги" — в тотальном контроле за изменениями и в строгой дисциплине их проведения.

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

Проверочные меры применяются клиентом, чтобы убедиться, что он получил именно то, что заказал, и что система не подверглась нелегальным изменениям. Клиент должен убедиться, что полученный им продукт — точная копия эталонного варианта, имеющегося у поставщика. Для этого существует целый спектр методов, начиная от проверок серийных номеров аппаратных компонентов и кончая верификацией контрольных сумм программ и данных. Следует отметить, что современная практика поставки программного обеспечения на CD-ROM'ах существенно затрудняет (по сравнению с дискеточным вариантом) внесение нелегальных изменений.

Документация

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

Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома:

· Руководство пользователя по средствам безопасности;

· Руководство администратора по средствам безопасности;

· Тестовая документация;

· Описание архитектуры.

Разумеется, на практике требуется еще по крайней мере одна книга — письменное изложение политики безопасности данной организации.

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

· Как входить в систему? Как вводить имя и пароль? Как менять пароль? Как часто это нужно делать? Как выбирать новый пароль?

· Как защищать файлы и другую информацию? Как задавать права доступа к файлам? Из каких соображений это нужно делать?

· Как импортировать и экспортировать информацию, не нарушая правил безопасности?

· Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?

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

Типичное оглавление Руководства администратора включает в себя следующие пункты:

· Каковы основные защитные механизмы?

· Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?

· Как администрировать средства произвольного управления доступом? Как защищать системную информацию? Как обнаруживать слабые места?

· Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?

· Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности?

· Как генерировать новую, переконфигурированную надежную вычислительную базу?

· Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?

· Как разделить обязанности системного администратора и оператора?

Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того (вернее, перед тем), тестовая документация должна содержать план тестирования и условия, налагаемые на тестовое окружение.

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