Выпуск и управление сертификатами

В документе [66] предлагается упорядоченное семейство из четырех профилей защиты для аппаратно-программных компонентов, реализующих выпуск, аннулирование и управление сертификатами открытых ключей (удовлетворяющими, например, спецификациям X.509) (Certificate Issuing and Management Components, CIMC).

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

Объект оценки в профилях из [66] является элементом инфраструктуры открытых ключей и в общем случае включает нижеследующие функциональные компоненты:

центр выпуска и аннулирования сертификатов (именуемый также удостоверяющим центром, УЦ). Это - ядро ОО. Сгенерированная информация помещается в хранилище (см. далее). Между различными УЦ могут существовать отношения доверия;
центры приема пользовательских запросов на создание сертификатов или изменение их статуса. Обязательные компоненты объекта оценки, которые верифицируют представленные пользователем данные;
серверы, обслуживающие протокол оперативной выдачи статуса сертификатов. Этот компонент может отсутствовать или находиться за пределами ОО;
серверы восстановления и/или распространения секретного ключевого материала - дополнительная функция.

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

Помимо функциональных, в объект оценки входят инфраструктурные компоненты:

криптографический модуль. Он подписывает сертификаты и списки их аннулирования, при необходимости генерирует криптографические ключи. Требования безопасности, предъявляемые к криптографическим модулям, изложены в федеральном стандарте США FIPS PUB 140-2 [44], заменившем FIPS PUB 140-1 (см. [39]);
модуль администрирования;
модуль идентификации и аутентификации;
модуль ролевого управления доступом;
модуль протоколирования и аудита.

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

Переходя к специфическим функциональным требованиям безопасности для среды, отметим выделение в [66] четырех ролей:

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

В соответствии с компонентом FMT_SMR.2 (ограничения на роли безопасности), один пользователь не может выступать более чем в одной из перечисленных выше ролей (FMT_SMR.2.3).

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

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

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

инициирование и обработка события подписывания регистрационного журнала (FPT_CIMC_TSP.1), выполняемого с конфигурируемой периодичностью. Подпись должна контролировать целостность по крайней мере тех регистрационных записей, которые появились после предыдущего подписывания. В регистрационной записи о самом событии подписывания присутствуют электронная цифровая подпись, значение хэш-функции или имитовставка аналогичного назначения;
инициирование и обработка события постановки третьей стороной подписанных меток времени (FPT_CIMC_TSP.2). Этот компонент аналогичен предыдущему и обеспечивает дополнительный контроль целостности регистрационных данных (например, на случай компрометации объекта оценки);
резервное копирование и восстановление (FDP_CIMC_BKP.1), с дополнительными (криптографическими) мерами контроля целостности и обеспечения конфиденциальности (FDP_CIMC_BKP.2), с точностью до последней завершенной транзакции (FDP_CIMC_BKP.3). Названные компоненты направлены на безопасное (в том числе свободное от внедрения вредоносного кода) восстановление. Отметим, что подобные требования полезны также для СУБД и других систем с транзакциями;
принудительные доказательство и верификация подлинности источника данных о статусе сертификатов и других данных, критичных для безопасности (FCO_NRO_CIMC.3). Аналогично должны контролироваться заявки на регистрацию сертификатов. Предпочтительный способ доказательства подлинности - цифровые подписи (FCO_NRO_CIMC.4).;
экспортируемая информация об изменении статуса сертификатов должна иметь формат, описанный в спецификациях X.509 для списков аннулирования или RFC 2560 для протокола оперативной выдачи статуса сертификатов (FDP_CIMC_CSE.1);
защита конфиденциальности секретных ключей пользователей (FDP_ACF_CIMC.2) и функций безопасности (FMT_MTD_CIMC.4). Секретные ключи обслуживающего персонала и функций безопасности объекта оценки должны храниться в стандартном криптографическом модуле или шифроваться стандартными методами. Секретные ключи пользователей шифруются с помощью долговременных ключей защиты.

Аналогичные требования предъявляются к хранению секретных ключей симметричных методов шифрования (FDP_ACF_CIMC.3 и FMT_MTD_CIMC.5);
секретные ключи должны экспортироваться либо в зашифрованном виде, либо с использованием процедур разделения знаний (FDP_ETC_CIMC.4, FDP_ETC_CIMC.5, FMT_MTD_CIMC.6, FMT_MTD_CIMC.7);
контроль целостности хранимых открытых ключей (FDP_DSI_CIMC.3). Открытые ключи, хранимые в объекте оценки вне криптографического модуля, нужно защитить от несанкционированного изменения стандартными криптографическими методами. Проверку целостности требуется производить при каждом доступе к ключу;
обнуление секретных ключей (FCS_CKM_CIMC.5). Функции безопасности должны обеспечить обнуление открытого представления секретных ключей в криптографическом модуле;
контроль допустимости значений полей сертификатов (FMT_MOF_CIMC.3). Функции безопасности контролируют значения полей сертификатов в соответствии с правилами, заданными администратором. Аналогичные проверки необходимо производить для списков аннулированных сертификатов (FMT_MOF_CIMC.5) и сообщений протокола оперативной выдачи статуса сертификатов (FMT_MOF_CIMC.6);
генерация сертификатов (FDP_CIMC_CER.1). Генерируются только корректные сертификаты, удовлетворяющие требованиям стандарта (X.509) и правилам, заданным администратором. Такие же требования должны выполняться для списков аннулированных сертификатов (FDP_CIMC_CRL.1) и сообщений протокола оперативной выдачи статуса сертификатов (FDP_CIMC_OCSP.1). До выпуска сертификата необходимо убедиться, что его предполагаемый владелец обладает секретным ключом, ассоциированным с открытым ключом из сертификата.

Требования доверия безопасности усиливаются параллельно с возрастанием выбранного уровня профиля защиты. Для верхнего, четвертого уровня используются в основном требования ОУД4 и, частично, ОУД5, а также требование ALC_FLR.3 (систематическое устранение недостатков), не входящее ни в один ОУД.

На наш взгляд, рассмотренное семейство профилей может служить примером при построении классификационных схем в Руководящих документах Гостехкомиссии России.

Содержание раздела