- •1.1. Введение. Понятие политики безопасности
- •Рис. 1. Основные каналы утечки информации при ее обработке на отдельной ПЭВМ
- •1.2. Модель компьютерной системы. Понятие доступа и монитора безопасности
- •Рис. 2. Порождения субъекта и понятие потока
- •Рис. 3. Примеры потоков в КС
- •1.3. Описание типовых политик безопасности
- •1.3.1. Модели на основе дискретных компонент
- •1.3.1.1. Модель АДЕПТ-50
- •1.3.1.2. Пятимерное пространство безопасности Хартстона
- •1.3.1.3. Резюме по моделям Адепт и Хартстона
- •1.3.2. Модели на основе анализа угроз системе
- •1.3.2.1. Игровая модель
- •1.3.2.2. Модель системы безопасности с полным перекрытием
- •1.3.2.3. Резюме по моделям анализа угроз
- •1.3.3. Модели конечных состояний.
- •1.3.3.1. Модель Белла-ЛаПадула.
- •1.3.3.2. Модель low-water-mark (LWM)
- •Таблица 1. Операции в модели LWM
- •1.3.3.3. Модель Лендвера
- •Определение 10
- •1.3.3.4. Резюме по моделям состояний
- •1.4. Обеспечение гарантий выполнения политики безопасности
- •Утверждение 1 (достаточное условие гарантированного выполнения политики безопасности в КС 1).
- •Утверждение 2 (достаточное условие гарантированного выполнения политики безопасности в КС 2).
- •Утверждение 3 (базовая теорема ИПС)
- •Рис. 5. Классическая модель ядра безопасности
- •Рис. 6. Ядро безопасности с учетом контроля порождения субъектов
- •1.5. Метод генерации изолированной программной среды при проектировании механизмов гарантированного поддержания политики безопасности
- •Таблица 2. Иерархия уровней при загрузке ОС
- •Утверждение 4 (условие одинакового состояния КС).
- •Утверждение 5 (достаточное условие ИПС при ступенчатой загрузке).
- •Утверждение 6 (требования к субъектному наполнению изолированной программной среды).
- •Утверждение 7 (достаточное условие чтения реальных данных).
- •1.6. Реализация гарантий выполнения заданной политики безопасности
- •Утверждение 8 (условия генерации ИПС при реализации метода доверенной загрузки).
- •1.7. Опосредованный несанкционированный доступ в компьютерной системе. Модель опосредованного НСД
- •Таблица 3. Полная группа событий в системе «ПП-РПВ»
- •Утверждение 9 (условия невозможности опосредованного НСД в ИПС).
- •Литература к первой части
- •Часть 2. Модели безопасного субъектного взаимодействия в компьютерной системе. Аутентификация пользователей. Сопряжение защитных механизмов
- •2.1. Введение
- •2.1. Процедура идентификации и аутентификации
- •Таблица 1. Объект-эталон для схемы 1
- •Таблица 2. Объект-эталон для схемы 2
- •Утверждение 1 (о подмене эталона).
- •2.2. Формализация задачи сопряжения. Методы сопряжения
- •Утверждение 2. (необходимое условие корректного взаимодействия сопрягаемых субъектов)
- •Утверждение 3. (о свойствах модуля сопряжения)
- •Рис. 1. Методы эмуляции органов управления и замены аутентифицирующего субъекта
- •2.3. Типизация данных, необходимых для обеспечения работы средств сопряжения
- •Таблица 3. Структура объекта вторичной аутентификации
- •Утверждение 4 (о свойствах объекта первичной аутентификации).
- •Утверждение 5 (об изменении информации пользователя в АНП).
- •2.4. Использование внешних субъектов при реализации и гарантировании политики безопасности
- •2.5. Понятие внешнего разделяемого сервиса безопасности. Постановка задачи
- •Рис. 2. Схема взаимодействия МРЗФ с МБО И МБС
- •2.6. Понятие и свойства модуля реализации защитных функций
- •Утверждение 6 (о потенциальной возможности некорректного возврата результата из МРЗФ)
- •Утверждение 7 (о потенциально возможном некорректном вызове МРЗФ)
- •2.7. Проектирование модуля реализации защитных функций в среде гарантирования политики безопасности
- •Утверждение 8 (достаточные условия корректного использования МРЗФ)
- •2.8. Передача параметров при составном потоке
- •Таблица 4. (Свойства составного потока при использовании МРЗФ)
- •2.9. Методика проверки попарной корректности субъектов при проектировании механизмов обеспечения безопасности с учетом передачи параметров
- •Заключение
- •Литература ко второй части
- •Часть 3. Управление безопасностью в компьютерной системе
- •3.1. Введение
- •3.2. Модель управления безопасностью. Термины
- •Утверждение 1 (о корректном управлении в ИПС).
- •Утверждение 2 (условия нарушения корректности управления).
- •Рис. 1. Локализация субъекта и объектов управления в распределенной КС
- •Таблица 1. (локализация управляющего субъекта и объекта управления)
- •3.3. Система удаленного управления безопасностью в отсутствии локального объекта управления
- •Утверждение 3 (необходимое условие 1 для создания системы корректного управления)
- •Утверждение 4 (необходимое условие 2 для создания системы корректного управления)
- •Утверждение 5
- •3.5. Метод “мягкого администрирования”. Автоматизированное формирование списков разрешенных задач и правил разграничения доступа
- •Утверждение 6 (лемма для обоснования метода мягкого администрирования)
- •3.6. Системы управления безопасностью при распределенном объекте управления
- •Утверждение 7 (условия корректности управления при мягком администрировании).
- •Заключение
- •Литература к третьей части
- •Часть 4. Модели сетевых сред. Создание механизмов безопасности в распределенной компьютерной системе
- •4.1. Введение
- •4.2.Модели воздействия внешнего злоумышленника на локальный сегмент компьютерной системы
- •Рис. 1. К моделям воздействия внешнего злоумышленника на локальный сегмент КС
- •4.3. Механизмы реализации политики безопасности в локальном сегменте компьютерной системы
- •Утверждение 1 (о распределенной КС с полным проецированием прав пользователя на субъекты).
- •Утверждение 2 (о доступе в системе с проецированием прав)
- •Таблица 1. Групповые правила разграничения доступа в ЛС КС
- •Таблица 2. Правила разграничения доступа при запрете транспортировки вовне избранных объектов
- •4.4. Метод межсетевого экранирования. Свойства экранирующего субъекта
- •Утверждение 3 (о существовании декомпозиции на подобъекты).
- •Утверждение 4 (Основная теорема о корректном экранировании).
- •Утверждение 6 (о тождестве фильтра сервисов и изолированной программной среды в рамках локального сегмента КС)
- •4.5. Модель политики безопасности в распределенной системе
- •4.6. Архитектура фильтрующего субъекта и требования к нему
- •Таблица 3. Показатели и классы защищенности межсетевого экрана
- •Заключение
- •Литература к четвертой части
- •Часть 5. Нормативные документы для решения задач компьютерной безопасности
- •Введение к пятой части
- •5.1.2. Структура требований безопасности
- •5.1.3. Показатели защищенности средств вычислительной техники от несанкционированного доступа
- •Таблица 1. Требования к защите от НСД СВТ
- •5.1.5. Классы защищенности автоматизированных систем
- •Таблица 2. Требования к защите от НСД АС
- •5.1.6. Выводы
- •5.2. Критерии безопасности компьютерных систем Министерства обороны США (“Оранжевая книга”)
- •5.2.1. Цель разработки
- •5.2.2. Общая структура требований «Оранжевой книги»
- •5.2.3. Классы безопасности компьютерных систем
- •Таблица 3. Требования «Оранжевой книги»
- •5.2.4. Интерпретация и развитие “Оранжевой книги”
- •5.2.5. Выводы
- •5.3. Европейские критерии безопасности информационных технологий
- •5.3.1. Основные понятия
- •5.3.2. Функциональные критерии
- •5.3.3. Критерии адекватности
- •5.3.4. Выводы
- •5.4. Федеральные критерии безопасности информационных технологий
- •5.4.1. Цель разработки
- •5.4.2. Основные положения
- •5.4.3. Профиль защиты
- •Назначение и структура Профиля защиты
- •Этапы разработки Профиля защиты
- •5.4.4. Функциональные требования к продукту информационных технологий
- •Таблица 4. Применение критериев ранжирования
- •5.4.5. Требования к процессу разработки продукта информационных технологий
- •5.4.6. Требования к процессу сертификации продукта информационных технологий
- •5.4.7. Выводы
- •Литература к пятой части
- •Заключение. Процесс построения защищенной компьютерной системы
- •Рис. 1. Взаимосвязь методов проектирования защищенной КС.
- •Список сокращений
-120-
Рассмотрим другие операции, модифицирующие атрибуты безопасности субъектов и объектов. Обычно они включают операции, изменяющие степень доверия к субъектам, классификацию информационных блоков, а также множества доступа к информационным блокам. В случае модели безопасности сети, необходимо добавить операции, такие как присвоение классификации сетевым компонентам и изменение ролей пользователей.
Присвоение классификации сетевому компоненту
Операция assign-sclass-ncobj(nc,scls) позволяет субъекту sub установить классификацию сетевому компоненту nc. То есть objcls'(nc)={scls}. Данная операция применима только в том случае, когда компонент не используется. Более того, только Администратор Безопасности Сети авторизован для проведения данной операции.
Присвоение степени доверия пользователю
Операция assign-sclass-user(usr, scls) позволяет субъекту sub установить степень доверия пользователю usr.
Присвоение пользователю текущей степени доверия
Операция assign-curclass-user(usr,scls) позволяет субъекту sub установить текущую степень доверия к пользователю usr.
Присвоение пользователю роли
Операция assign-role-user(usr, rlset) позволяет субъекту sub установить пользователю usr множество ролей.
Присвоение пользователю текущей роли
Операция assign-currole-user(usr,rl) позволяет субъекту sub изменить текущую роль пользователя usr.
Установка списка доступа
Операция setauthlist(al) позволяет субъекту установить список доступа. Функции системы.
Функции системы описывают переход системы из одного состояния в другое, поле применения одиночной операции или их последовательности, так как это было описано выше. То есть:
A: Sub x O x S → S
s'=A(sub, op, s) - результирующее состояние после применения операции о
О, примененной субъектом sub Sub в состоянии s S.
Офункции А говорят, что переход безопасен, если он удовлетворяет условиям, описанным в предыдущих пунктах.
4.6.Архитектура фильтрующего субъекта и требования к нему
Дополнительно уточним некоторые термины (нижеследующий материал приводится по [2]). Для обозначения программно-технического решения субъекта-фильтра, рассмотренного выше, применяется название межсетевой экран (МЭ).
Администратор МЭ - лицо, ответственное за сопровождение МЭ и обеспечивающее адекватность заданной политики безопасности, реализованной с помощью МЭ, в течение всего времени эксплуатации.
-121-
Дистанционное управление компонентами МЭ - выполнение функций по сопровождению (управлению) МЭ администратором МЭ с узла сети, на котором не функционирует МЭ, с использованием сетевых протоколов.
Критерии фильтрации - параметры, атрибуты, характеристики, на основе которых осуществляется разрешение или запрещение дальнейшей передачи пакета в соответствии с заданными правилами разграничения доступа (правила фильтрации). В качестве таких параметров могут использоваться служебные поля пакетов, содержащие сетевые адреса, идентификаторы, адреса интерфейсов, портов и другие значимые данные, а также внешние характеристики, например, временные, частотные характеристики сетевого обмена, объем данных и т.п.
Локальное (местное) управление компонентами МЭ — выполнение функции по сопровождению МЭ (компоненты) администратором МЭ на том же узле (платформе), на котором функционирует МЭ (компонента) с использованием интерфейса МЭ.
Межсетевой экран (МЭ) — это локальное (однокомпонентное) или функционально-распределенное программное (или программно-аппаратное) средство (комплекс), реализующее контроль над потоком информации, поступающей в КС и/или выходящей из КС. МЭ обеспечивает защиту КС посредством фильтрации информации, т.е. ее анализа по ñîвокупности критериев и принятия решения о ее распространении в (из) КС на основе заданных правил, проводя, таким образом, разграничение доступа субъектов из одной КС к объектам другой КС. Каждое правило запрещает или разрешает передачу информации определенного вида между субъектами и объектами. Как следствие, субъекты из одной КС получают доступ только к разрешенным информационным объектам из другой КС. Интерпретация набора правил выполняется последовательностью фильтров, которые разрешают или запрещают передачу данных (пакетов) на следующий фильтр или уровень протокола.
Таким образом, МЭ реализует некоторую ПБ на некотором заданном ему уровне.
Правила фильтрации — перечень условий, по которым с использованием заданных критериев фильтрации осуществляется разрешение или запрещение дальнейшей передачи пакетов (данных) и перечень действий, производимых МЭ по регистрации и/или осуществлению защитных функций.
Межсетевой экран может строиться с помощью экранирующих агентов (субъектов), которые обеспечивают установление соединения между субъектом и объектом, а затем пересылают информацию, осуществляя контроль и/или регистрацию. Использование экранирующих агентов позволяет предоставить дополнительную защитную функцию — сокрытие от субъекта истинного объекта. R то же время, субъекту кажется, что он непосредственно взаимодействует с объектом. Обычно экран не является симметричным, для него определены понятия «внутри» и «снаружи». При этом задача экранирования формулируется как задача защиты внутренней области от
-122-
воздействия злоумышленника из неконтролируемой и потенциально враждебной внешней области.
Сетевые адреса — адресные данные, идентифицирующие субъекты и объекты и используемые протоколом сетевого уровня модели международной организации по стандартизации взаимодействия открытых систем (ISO OSI). Сетевой протокол выполняет управление коммуникационными ресурсами, маршрутизацию пакетов, их компоновку для передачи в сети. В этих протоколах решается возможность доступа к подсети, определяется маршрут передачи и осуществляется трансляция сообщений. Управление доступом на сетевом уровне позволяет отклонить нежелательные вызовы и дает возможность различным подсетям управлять использованием ресурсов сетевого уровня.
Трансляция адреса - функция МЭ, скрывающая внутренние адреса объектов ЛС КС от внешних субъектов.
Транспортные адреса - адресные данные, идентифицирующие субъекты и объекты и используемые протоколом транспортного уровня модели ISO.
Состав и сущность требований к межсетевому экрану задается таблицей 3.
Таблица 3. Показатели и классы защищенности межсетевого экрана
Показатели защищенности |
5 |
4 |
3 |
2 |
1 |
Управление доступом (фильтрация данных и |
+ |
+ |
+ |
+ |
= |
трансляция адресов) |
|
|
|
|
|
Идентификация и аутентификация |
- |
- |
+ |
= |
+ |
Регистрация |
- |
+ |
+ |
+ |
= |
Администрирование (идентификация и |
+ |
= |
+ |
+ |
+ |
аутентификация) |
|
|
|
|
|
Администрирование (регистрация) |
+ |
+ |
+ |
= |
= |
Администрирование (простота использования) |
- |
- |
+ |
= |
+ |
Целостность |
+ |
= |
+ |
+ |
+ |
Восстановление |
+ |
= |
= |
+ |
= |
Тестирование |
+ |
+ |
+ |
+ |
+ |
Руководство администратора защиты |
+ |
= |
= |
= |
= |
Тестовая документация |
+ |
+ |
+ |
+ |
+ |
Конструкторская (проектная) документация |
+ |
= |
+ |
= |
+ |
Обозначения:
“-” - нет требований к данному классу; “+” - новые или дополнительные требования;
“=“ - требования совпадают с требованиями к МЭ предыдущего класса.
4.6.1. Требования к пятому классу защищенности МЭ
4.6.1.1. Управление доступом МЭ должен обеспечивать фильтрацию на сетевом уровне.
Решение по фильтрации может приниматься для каждого сетевого пакета независимо на основе, по крайней мере, сетевых адресов отправителя и получателя.
-123-
4.6.1.2.Администрирование (идентификация и аутентификация)
МЭ должен обеспечивать идентификацию и аутентификацию администратора защиты при его локальных запросах на доступ. МЭ должен предоставлять возможность для идентификации и аутентификации по идентификатору (коду) и паролю условно-постоянного действия.
4.6.1.3. Администрирование (регистрация)
МЭ должен обеспечивать регистрацию следующих событий:
-вход (выход) администратора защиты в систему (из системы) либо загрузку и инициализацию системы и ее программного останова. Регистрация выхода из системы не проводится в моменты аппаратурного отключения МЭ.
Впараметрах регистрации указываются:
-дата, время и код регистрируемого события;
-результат попытки осуществления регистрируемого события (успешная или неуспешная);
-идентификатор администратора защиты, предъявленный при попытке осуществления регистрируемого события.
4.6.1.4.Целостность МЭ должен содержать средства контроля за целостностью своей
программной и информационной части.
4.6.1.5.Восстановление МЭ должен предусматривать процедуру восстановления после сбоев и
отказов оборудования, которые должны обеспечивать восстановление свойств МЭ.
4.6.1.6.Тестирование
ВМЭ должна обеспечиваться возможность регламентного тестирования:
-реализации правил фильтрации (см. п. 4.6.1.1);
-процесса идентификации и аутентификации администратора защиты (см.
п. 4.6.1.2);
-процесса регистрации действий администратора защиты (см. п. 4.6.1.3.);
-процесса контроля за целостностью программной и информационной части МЭ (см. п. 4.6.1.4);
-процедуры восстановления (см. п. 4.6.1.5.).
4.6.1.7.Руководство администратора защиты
Должно содержать:
-описание контролируемых функций МЭ;
-руководство по настройке и конфигурированию МЭ;
-описание старта МЭ и процедур проверки правильности старта;
-руководство по процедуре восстановления.
4.6.1.8. Тестовая документация Должна содержать описание тестов и испытаний, которым подвергался МЭ
(в соответствии с п. 4.6.1.6), и результаты тестирования. 4.6.1.9. Конструкторская (проектная) документация Должна содержать:
- общую схему МЭ;
-124-
-общее описание принципов работы МЭ;
-описание правил фильтрации;
-описание средств и процесса идентификации и аутентификации;
-описание средств и процесса регистрации;
-описание средств и процесса контроля за целостностью программной и информационной части МЭ;
-описание процедуры восстановления свойств МЭ.
4.6.2. Требования к четвертому классу защищенности МЭ
4.6.2.1. Управление доступом Данные требования включают аналогичные требования пятого класса
(п.4.6.1.1).
Дополнительно МЭ должен обеспечивать:
-фильтрацию служебных протоколов, служащих для диагностики и управления работой сетевых устройств;
-фильтрацию с учетом входного и выходного сетевого интерфейса как средство проверки подлинности сетевых адресов;
-фильтрацию с учетом любых значимых полей сетевых пакетов.
4.6.2.2. Регистрация МЭ должен обеспечивать возможность регистрации и учета фильтруемых
пакетов. В параметры регистрации включаются адрес, время и результат фильтрации.
4.6.2.3. Администрирование (идентификация и аутентификация)
Данные требования полностью совпадают с аналогичными требованиями пятого класса (п.4.6.1.2).
4.6.2.4. Администрирование (регистрация)
Данные требования включают аналогичные требования пятого класса
(п.4.6.1.3).
Дополнительно МЭ должен обеспечивать регистрацию запуска программ и процессов (заданий, задач).
4.6.2.5. Целостность Данные требования полностью совпадают с аналогичными требованиями
пятого класса (п.4.6.1.4). 4.6.2.6. Восстановление
Данные требования полностью совпадают с аналогичными требованиями пятого класса (п.4.6.1.5).
4.6.2.7. Тестирование В МЭ должна обеспечиваться возможность регламентного тестирования:
-реализации правил фильтрации (см. п. 4.6.2.1);
-процесса регистрации (см. п. 4.6.2.2);
-процесса идентификации и аутентификации администратора защиты (см.
п. 4.6.2.3);
-процесса регистрации действий администратора защиты (см. п. 4.6.2.4);
-процесса контроля за целостностью программной и информационной части МЭ (см. п. 4.6.2.5);
-125-
-процедуры восстановления (см. п. 4.6.2.6). 4.6.2.8. Руководство администратора защиты
Данные требования полностью совпадают с аналогичными требованиями
пятого класса (п. 4.6.1.7).
4.6.2.9. Тестовая документация Должна содержать описание тестов и испытаний, которым подвергался МЭ
(в соответствии с п. 4.6.2.7), и результаты тестирования. 4.6.2.10. Конструкторская (проектная) документация Должна содержать:
-общую схему МЭ;
-общее описание принципов работы МЭ;
-описание правил фильтрации;
-описание средств и процесса идентификации и аутентификации;
-описание средств и процесса регистрации;
-описание средств и процесса контроля за целостностью программной и информационной части МЭ;
-описание процедуры восстановления свойств МЭ.
4.6.3. Требования к третьему классу защищенности МЭ
4.6.3.1. Управление доступом Данные требования включают аналогичные требования четвертого класса
(п. 4.6.2.1).
Дополнительно МЭ должен обеспечивать:
-фильтрацию на транспортном уровне запросов на установление виртуальных соединений. При этом, по крайней мере, учитываются транспортные адреса отправителя и получателя;
-фильтрацию на прикладном уровне запросов к прикладным сервисам. При этом, по крайней мере, учитываются прикладные адреса отправителя и получателя;
-фильтрацию с учетом даты/времени.
4.6.3.2. Идентификация и аутентификация МЭ должен обеспечивать возможность аутентификации входящих и
исходящих запросов методами, устойчивыми к пассивному и/или активному прослушиванию сети.
4.6.3.3. Регистрация Данные требования включают аналогичные требования четвертого класса
(п.4.6.2.2).
Дополнительно МЭ должен обеспечивать:
-регистрацию и учет запросов на установление виртуальных соединений;
-локальную сигнализацию попыток нарушения правил фильтрации. 4.6.3.4. Администрирование (идентификация и аутентификация)
Данные требования включают аналогичные требования пятого класса
(п.4.6.1.2).
-126-
Дополнительно МЭ должен препятствовать доступу неидентифицированного субъекта или объекта, подлинность идентификации которого при аутентификации не подтвердилась.
При удаленных запросах администратора на доступ идентификация и аутентификация должны обеспечиваться методами, устойчивыми к пассивному и активному перехвату информации.
4.6.3.5. Администрирование (регистрация)
Данные требования включают аналогичные требования четвертого класса
(п.4.6.2.4).
Дополнительно МЭ должен обеспечивать регистрацию действия администратора защиты по изменению правил фильтрации.
4.6.3.6. Администрирование (простота использования) Многокомпонентный МЭ должен обеспечивать возможность
дистанционного управления своими компонентами, в том числе возможность конфигурирования фильтров, проверки взаимной согласованности всех фильтров, анализа регистрационной информации.
4.6.3.7. Целостность Данные требования включают аналогичные требования пятого класса
(п.4.6.1.4).
Дополнительно должен обеспечиваться контроль целостности программной и информационной части МЭ по контрольным суммам.
4.6.3.8. Восстановление Данные требования полностью совпадают с аналогичными требованиями
пятого класса (п.4.6.1.5). 4.6.3.9. Тестирование
В МЭ должна обеспечиваться возможность регламентного тестирования:
-реализации правил фильтрации (см. п. 4.6.3.1);
-процесса регистрации (см. п. 4.6.3.3);
-процесса идентификации и аутентификации администратора защиты (см.
п. 4.6.3.4);
-процесса регистрации действий администратора защиты (см. п. 4.6.3.5);
-процесса контроля за целостностью программной и информационной части МЭ (см. п. 4.6.3.7);
-процедуры восстановления (см. п. 4.6.3.8.).
4.6.3.10.Руководство администратора защиты
Данные требования полностью совпадают с аналогичными требованиями пятого класса (п.4.6.1.7).
4.6.3.11. Тестовая документация Должна содержать описание тестов и испытаний, которым подвергался МЭ
(в соответствии с п. 4.6.3.9), и результаты тестирования. 4.6.3.12. Конструкторская (проектная) документация Должна содержать:
-общую схему МЭ;
-общее описание принципов работы МЭ;
-127-
- описание правил фильтрации; - описание средств и процесса идентификации и аутентификации;
- описание средств и процесса регистрации; - описание средств и процесса контроля за целостностью программной и
информационной части МЭ; - описание процедуры восстановления свойств МЭ.
4.6.4. Требования ко второму классу защищенности МЭ
4.6.4.1. Управление доступом Данные требования включают аналогичные требования третьего класса
(п.4.6.3.1).
Дополнительно МЭ должен обеспечивать:
-возможность сокрытия субъектов (объектов) и/или прикладных функций защищаемой сети;
-возможность трансляции сетевых адресов.
4.6.4.2. Идентификация и аутентификация Данные требования полностью совпадают с аналогичными требованиями
третьего класса (п.4.6.3.2). 4.6.4.3. Регистрация
Данные требования включают аналогичные требования третьего класса
(п.4.6.3.3).
Дополнительно МЭ должен обеспечивать:
-дистанционную сигнализацию попыток нарушения правил фильтрации;
-регистрацию и учет запрашиваемых сервисов прикладного уровня;
-программируемую реакцию на события в МЭ.
4.6.4.4. Администрирование (идентификация и аутентификация)
МЭ должен обеспечивать идентификацию и аутентификацию администратора защиты при его запросах на доступ. МЭ должен предоставлять возможность для идентификации и аутентификации по идентификатору (коду) и паролю временного действия. МЭ должен препятствовать доступу неидентифицированного субъекта или объекта, подлинность идентификации которого при аутентификации не подтвердилась.
4.6.4.5. Администрирование (регистрация)
Данные требования полностью совпадают с аналогичными требованиями четвертого класса (п.4.6.3.5).
4.6.4.6. Администрирование (простота использования)
Данные требования полностью совпадают с аналогичными требованиями четвертого класса (п.4.6.3.6).
4.6.4.7. Целостность МЭ должен содержать средства контроля за целостностью своей
программной и информационной части по контрольным суммам как в процессе загрузки, так и динамически.
4.6.4.8. Восстановление
-128-
МЭ должен предусматривать процедуру восстановления после сбоев и отказов оборудования, которые должны обеспечивать оперативное восстановление свойств МЭ.
4.6.4.9. Тестирование В МЭ должна обеспечиваться возможность регламентного тестирования:
-реализации правил фильтрации (см. п. 4.6.4.1);
-процесса идентификации и аутентификации (см. п. 4.6.4.2);
-процесса регистрации (см. п. 4.6.4.3);
-процесса идентификации и аутентификации администратора защиты (см.
п. 4.6.4.4);
процесса регистрации действий администратора защиты (см. п. 4.6.4.5);
-процесса контроля за целостностью программной и информационной части МЭ (см. п. 4.6.4.7);
-процедуры восстановления (см. п. 4.6.4.8).
4.6.4.10. Руководство администратора защиты Данные требования полностью совпадают с аналогичными требованиями
пятого класса (п.4.6.1.7).
4.6.4.11. Тестовая документация Должна содержать описание тестов и испытаний, которым подвергался МЭ
(в соответствии с п. 4.6.4.9), и результаты тестирования. 4.6.4.12. Конструкторская (проектная) документация Должна содержать:
-общую схему МЭ;
-общее описание принципов работы МЭ;
-описание правил фильтрации;
-описание средств и процесса идентификации и аутентификации;
-описание средств и процесса регистрации;
-описание средств и процесса контроля за целостностью программной и информационной части МЭ;
-описание процедуры восстановления свойств МЭ.
4.6.5. Требования к первому классу защищенности МЭ
4.6.5.1. Управление доступом Данные требования полностью совпадают с аналогичными требованиями
второго класса (п.4.6.4.1).
4.6.5.2. Идентификация и аутентификация Данные требования полностью включают аналогичные требования второго
класса (п.4.6.4.2).
Дополнительно МЭ должен обеспечивать идентификацию и аутентификацию всех субъектов прикладного уровня.
4.6.5.3. Регистрация Данные требования полностью совпадают с аналогичными требованиями
второго класса (п.4.6.4.3).
4.6.5.4. Администрирование (идентификация и аутентификация)
-129-
МЭ должен обеспечивать идентификацию и аутентификацию администратора защиты при его запросах на доступ. МЭ должен предоставлять возможность для идентификации и аутентификации по биометрическим характеристикам или специальным устройствам (жетонам, картам, электронным ключам) и паролю временного действия. МЭ должен препятствовать доступу неидентифицированного субъекта или объекта, подлинность идентификации которого при аутентификации не подтвердилась.
4.6.5.5. Администрирование (регистрация)
Данные требования полностью совпадают с аналогичными требованиями третьего класса (п.4.6.3.5).
4.6.5.6. Администрирование: простота использования Многокомпонентный МЭ должен обеспечивать возможность
централизованного управления своими компонентами, в том числе, конфигурированием фильтров, проверкой взаимной согласованности всех фильтров, анализом регистрационной информации.
Должен быть предусмотрен графический интерфейс для управления МЭ. 4.6.5.7. Целостность МЭ должен содержать средства контроля за целостностью своей
программной и информационной части по контрольным суммам аттестованного алгоритма как в процессе загрузки, так и динамически.
4.6.5.8. Восстановление Данные требования полностью совпадают с аналогичными требованиями
второго класса (п.4.6.4.8). 4.6.5.9. Тестирование
ВМЭ должна обеспечиваться возможность регламентного тестирования:
-реализации правил фильтрации (см. п. 4.6.5.1);
-процесса идентификации и аутентификации (см. п. 4.6.5.2);
-процесса регистрации (см. п. 4.6.5.3);
-процесса идентификации и аутентификации администратора защиты (см.
п. 4.6.5.4);
-процесса регистрации действий администратора защиты (см. п. 4.6.5.5);
-процесса централизованного управления компонентами МЭ и графического интерфейса для управления МЭ (см. п. 4.6.5.6);
-процесса контроля за целостностью программной и информационной части МЭ (см. п. 4.6.5.7);
процедуры восстановления (см. п. 4.6.5.8). 4.6.5.10. Руководство администратора защиты
Данные требования полностью совпадают с аналогичными требованиями пятого класса (п.4.6.1.7).
4.6.5.11. Тестовая документация Должна содержать описание тестов и испытаний, которым подвергался МЭ
(в соответствии с п. 4.6.5.9), и результаты тестирования. 4.6.5.12. Конструкторская (проектная) документация Должна содержать: