«Утверждаю»
Генеральный директор
«Партнер»
__________
Регламент Удостоверяющего Центра
РПЦ «Партнер»
РПЦ «Партнер» 2004
1. Введение.. 7
1.1. Обзорная информация.. 7
1.2. Идентификация.. 7
1.3. Общность и применимость. 7
1.3.1. Центр сертификации.. 7
1.3.2. Центр регистрации.. 7
1.3.3. Владельцы сертификатов.. 8
1.3.4. Пользователи сертификатов.. 8
1.3.5. Область применения Регламента.. 8
1.4. Контактная информация.. 8
2. Общие положения.. 8
2.1 Обязанности.. 8
2.1.1. Обязанности ЦС.. 8
2.1.2. Обязанности ЦР.. 9
2.1.3. Обязанности владельца сертификата.. 10
2.1.4. Обязанности пользователей сертификатов.. 10
2.2. Ответственность. 11
2.2.1. Отказ от гарантий и обязательств.. 11
2.2.2. Ограничения ответственности.. 11
2.3. Финансовые обязательства.. 11
2.4 Контроль за соблюдением Регламента.. 11
2.5 Платность услуг. 11
2.6 Опубликование и реестр сертификатов.. 11
2.6.1 Предоставление информация о Регламенте.. 11
2.6.2 Предоставление сертификатов и СОС.. 11
2.6.3 Периодичность рассылки.. 12
2.7 Проверка соответствия.. 12
2.7.1 Периодичность проверок соответствия.. 12
2.7.2 Личность и квалификация аудитора УЦ.. 12
2.7.3 Отношение аудитора к проверяемому УЦ.. 12
2.7.4 Предметы проверки.. 12
2.7.5 Действия, предпринимаемые по результатам проверки.. 12
2.7.6 Сообщение результатов.. 12
2.8 Политика конфиденциальности.. 13
2.8.1 Типы конфиденциальной информации.. 13
2.8.2 Типы информации, не относящейся к конфиденциальной.. 13
2.8.3 Оглашение информации об отзывах сертификатов.. 13
2.8.4 Исключительные полномочия официальных лиц.. 13
2.9 Права на интеллектуальную собственность. 13
3. Идентификация и аутентификация.. 14
3.1 Начальная регистрация.. 14
3.1.1 Типы имен.. 14
3.1.2 Осмысленность имен.. 14
3.1.3 Правила интерпретации различных форм имен.. 14
3.1.4 Уникальность имен.. 14
3.1.5 Метод доказательства обладания секретным ключом.. 14
3.1.6 Регистрация частных лиц.. 14
3.1.7 Аутентификация устройств и программных приложений.. 15
3.2 Процедура смены сертифицируемого ключа.. 15
3.3 Смена сертифицируемого ключа после отзыва сертификата.. 15
3.4 Запрос на отзыв сертификата.. 15
3.5 Список всех действий пользователя, выполнение которых разрешено до его идентификации и аутентификации.. 15
3.6 Перечень подлежащих защите данных, поступающих в УЦ.. 15
3.7 Перечень подлежащих защите данных, экспортируемых из УЦ.. 15
3.8 Перечень процессов, для которых допускается обращение к техническим средствам УЦ.. 16
3.9 Список объектов доступа и целевых функций УЦ.. 16
4. Эксплуатационные требования.. 17
4.1 Запрос на выдачу сертификата.. 17
4.2 Издание сертификата.. 17
4.3 Получение сертификата.. 17
4.4 Приостановка действия и аннулирование сертификата.. 17
4.4.1 Условия отзыва.. 17
4.4.2 Кто может потребовать отзыв.. 17
4.4.3 Процедура запроса на отзыв.. 17
4.4.4 Время обработки запроса на отзыв.. 18
4.4.5 Условия приостановления действия.. 18
4.4.6 Кто может потребовать приостановления действия.. 18
4.4.7 Процедура запроса на приостановление действия.. 18
4.4.8 Ограничения периода временного приостановления.. 18
4.4.9 Периодичность издания СОС.. 18
4.4.10 Требования к проверке СОС.. 18
4.4.11 Возможность проверки статуса сертификата в режиме on-line 18
4.4.12 Требования к проверке статуса сертификата в режиме on-line 19
4.4.13 Иные формы извещения об отзыве.. 19
4.4.14 Проверка требований для иных форм извещения об отзыве.. 19
4.4.15 Действия при компрометации ключей.. 19
4.4.16 Механизм проверки подписи в сертификате по запросу пользователя 19
4.5 Процедуры аудита безопасности.. 19
4.5.1 Типы записываемых событий.. 19
4.5.2 Частота обработки журнала аудита.. 20
4.5.3 Срок хранения информации в журнале аудита.. 20
4.5.4 Защита журнала аудита.. 20
4.5.5 Процедуры резервного копирования журнала аудита.. 20
4.5.6 Система сбора данных о регистрируемых событиях.. 21
4.5.7 Оповещение субъекта, активировавшего событие.. 21
4.5.8 Оценка уязвимости.. 21
4.6 Архивирование документов.. 21
4.6.1 Типы архивируемых данных.. 21
4.6.2 Срок архивного хранения.. 21
4.6.3 Защита архива.. 21
4.6.4 Процедуры резервного копирования архива.. 21
4.6.5 Система сбора данных для архива.. 21
4.6.6 Процедуры получения и проверки архивной информации.. 21
4.7 Обновление ключей.. 22
4.8 Восстановление после компрометации и прочих бедствий.. 22
4.8.1 Восстановление после компрометации.. 22
4.8.2 Восстановление после прочих бедствий.. 22
4.9 Прекращение функционирования УЦ.. 22
5. Физический, процедурный и персональный контроль безопасности 22
5.1 Физический контроль безопасности.. 22
5.1.1 Размещение и построение технических средств УЦ.. 22
5.1.2 Физический доступ.. 23
5.1.3 Электроснабжение и кондиционирование воздуха.. 23
5.1.4 Подверженность воздействию влаги.. 23
5.1.5 Предупреждение и защита от возгорания.. 23
5.1.6 Хранение носителей.. 23
5.1.7 Уничтожение носителей.. 23
5.1.8 Стороннее архивирование.. 23
5.1.9 Перечень данных, сохраняемых при резервном копировании.. 23
5.2 Процедурный контроль безопасности.. 23
5.2.1 Доверенные роли.. 23
5.2.2 Ролевая идентификация и аутентификация.. 24
5.3 Персональный контроль безопасности.. 24
5.3.1 Требования к биографическим данным, квалификации, опыту и уровню допуска.. 24
5.3.2 Процедуры проверки биографии.. 24
5.3.3 Требования к подготовке.. 24
5.3.4 Требования к переподготовке, частота переподготовки.. 25
5.3.5 Очередность работ. 25
5.3.6 Санкции к неавторизованным действиям.. 25
5.3.7 Служащие по контракту.. 25
5.3.8 Документация, предоставляемая служащим.. 25
6. Технический контроль безопасности.. 25
6.1 Генерация и ввод в действие пар ключей.. 25
6.1.1 Генерация пары ключей.. 25
6.1.2 Доставка закрытого ключа до пользователя.. 25
6.1.3 Доставка открытого ключа до издателя сертификата.. 25
6.1.4 Доставка открытого ключа УЦ до пользователей.. 25
6.1.5 Размеры асимметричных ключей.. 26
6.1.6 Генерация параметров открытого ключа.. 26
6.1.7 Проверка качества параметров.. 26
6.1.8 Аппаратная и программная генерация ключа.. 26
6.1.9 Цели использования ключа.. 26
6.2 Защита закрытого ключа.. 26
6.2.1 Стандарты для криптографического модуля.. 26
6.2.2 Мультиперсональный контроль закрытого ключа.. 26
6.2.3 Депонирование закрытого ключа.. 26
6.2.4 Резервное хранение закрытого ключа.. 26
6.2.5 Архивирование закрытого ключа.. 26
6.2.6 Введение закрытого ключа в криптографический модуль. 27
6.2.7 Метод активации закрытого ключа.. 27
6.2.8 Метод деактивации закрытого ключа.. 27
6.2.9 Метод уничтожения закрытого ключа.. 27
6.3 Иные аспекты управления парами ключей.. 27
6.3.1 Архивирование открытого ключа.. 27
6.3.2 Сроки действия для открытых и закрытых ключей.. 27
6.3.3 Описание формируемой и/или хранимой в УЦ ключевой информации 28
6.3.4 Допустимые объемы формируемой и/или хранимой в УЦ ключевой информации.. 28
6.3.5 Процедура контроля соответствия электронного сертификата бумажной копии.. 28
6.4 Данные активации.. 28
6.4.1 Генерация и инсталляция активационных данных.. 28
6.4.2 Защита активационных данных.. 28
6.4.3 Иные особенности активационных данных.. 28
6.5 Контроль защищенности вычислительной техники.. 28
6.5.1 Технические требования по компьютерной безопасности.. 28
6.5.2 Рейтинг компьютерной безопасности.. 29
6.5.3 Класс используемых СКЗИ.. 29
6.5.4 Меры, принятые для обеспечения надежности и устойчивости функционирования УЦ.. 29
6.6 Контроль защищенности на протяжении жизненного цикла.. 29
6.6.1 Контроль процесса разработки системы.. 29
6.6.2 Контроль управления безопасностью.. 29
6.7 Контроль защищенности сетевой среды.. 29
6.8 Контроль разработки криптографических модулей.. 29
7. Структуры сертификатов и СОС.. 30
7.1 Структура сертификата.. 30
7.1.1 Номер версии.. 30
7.1.2 Дополнения сертификата.. 30
7.1.3 Объектные идентификаторы алгоритма.. 30
7.1.4 Формы имени.. 30
7.1.5 Ограничения на имена.. 30
7.1.6 Объектный идентификатор Регламента.. 30
7.1.7 Использование дополнения Policy Constraints. 31
7.1.8 Синтаксис и семантика спецификаторов Регламента (Policy Qualifiers) 31
7.1.9 Обработка критичного дополнения Certificate Policy.. 31
7.2 Структура СОС.. 31
7.2.1 Номер версии.. 31
7.2.2 Дополнения СОС.. 31
8. Технические требования к администрированию.. 31
8.1 Процедуры изменения спецификации.. 31
8.1.1 Пункты, которые могут изменяться без извещения.. 31
8.1.2 Изменения с оповещением.. 31
8.2 Процедуры опубликования и оповещения.. 31
8.3 Процедуры подтверждения практических положений Регламента системы 32
Приложение 1. 33
Сокращения.. 33
Приложение
Термины.. 34
1. Введение
1.1. Обзорная информация
Настоящий Регламент определяет обязанности пользователей и членов группы администраторов удостоверяющего центра (УЦ) РПЦ «Партнер», протоколы работы, принятые форматы данных, основные организационно-технические мероприятия, необходимые для безопасной работы УЦ.
1.2. Идентификация
Наименование документа: «Регламент Удостоверяющего Центра РПЦ «Партнер».
Версия: 1.0.
Дата: ___.___.04
1.3. Общность и применимость
УЦ состоит из следующих компонент:
· центр сертификации (ЦС);
· центр регистрации (ЦР).
Все пользователи УЦ в данном Регламенте подразделяются на 2 категории:
· владельцы сертификатов;
· пользователи сертификатов (пользователи, не имеющие собственных сертификатов, но использующие сертификаты других пользователей для каких-либо целей).
В настоящем разделе приводится описание предназначения каждого из компонент УЦ и каждой категории пользователей.
1.3.1. Центр сертификации
Центр сертификации (ЦС) предназначен для:
· формирования сертификатов пользователей;
· формирования сертификатов подчиненных УЦ;
· отзыва сертификатов путем включения их в списки отозванных сертификатов (СОС);
· ведения базы всех изготовленных в ЦС сертификатов и СОС в течение срока их действия;
· ведения архива всех изготовленных в ЦС сертификатов.
1.3.2. Центр регистрации
ЦР предназначен для:
· регистрации пользователей и подчиненных УЦ;
· обеспечения взаимодействия пользователей и подчиненных УЦ с УЦ РПЦ «Партнер».
1.3.3. Владельцы сертификатов
Владелец сертификата ключа подписи - физическое лицо, на имя которого удостоверяющим центром выдан сертификат ключа подписи и которое владеет соответствующим закрытым ключом электронной цифровой подписи, позволяющим с помощью средств электронной цифровой подписи создавать свою электронную цифровую подпись в электронных документах (подписывать электронные документы).
В тех случаях, когда сертификаты требуются для работы каких-либо устройств или программных приложений, назначается ответственное лицо, на имя которого издается сертификат.
1.3.4. Пользователи сертификатов
Пользователем сертификата может быть любое лицо, устройство или программное приложение.
1.3.5. Область применения Регламента
Данный Регламент применяется для работы с сертификатами, используемыми для защиты конфиденциальной информации, представляющей собой налоговую или коммерческую тайну, которая циркулирует в системах электронного документооборота хозяйствующих субъектов и государственных органов, собирающих отчетность организаций, таких как МНС России, Пенсионный Фонд, Комитет статистики и т. д.
1.4. Контактная информация
Администрирование данного Регламента осуществляет ЦС.
Контактный телефон: (84, Администратор информационной безопасности.
2. Общие положения
2.1 Обязанности
2.1.1. Обязанности ЦС
В своей деятельности ЦС должен руководствоваться данным Регламентом, постановлениями органов государственной власти РФ, законом РФ «Об электронной цифровой подписи» другими федеральными законами и принимаемыми в соответствии с ними иными нормативными правовыми актами Российской Федерации. ЦС должен гарантировать, что все ЦР, действующие от его имени, удовлетворяют соответствующим положениям данного Регламента касательно деятельности ЦР. ЦС должен принимать все допустимые меры для ознакомления владельцев и пользователей сертификатов с их правами и обязанностями в плане управления ключевой информацией, сертификатами и программно-аппаратным обеспечением, используемым при взаимодействии с УЦ.
ЦС обязан:
- публиковать данный Регламент; располагать механизмами и процедурами, позволяющими гарантировать, что все ЦР и пользователи сознательно согласны следовать положениям данного Регламента; гарантировать, что собственные сервисы издания и отзыва сертификатов, издания списков отозванных сертификатов согласуются с данным Регламентом.
2.1.1.1. Уведомление об издании и отзыве сертификата
Официальным уведомлением пользователя об издании сертификата является отправка (передача) ему сертификата. Официальным уведомлением об отзыве сертификата является ежемесячная публикация СОС на веб-сервере «Партнер».
2.1.1.2. Точность представления
Когда ЦС рассылает сертификат, он подтверждает, что информация, содержащаяся в сертификате, прошла проверку согласно данному Регламенту.
2.1.1.3. Время между подачей запроса и изданием сертификата
Время рассмотрения запроса на сертификат не может превышать двух недель. По истечении этого времени должен быть издан сертификат или дан мотивированный отказ в его издании.
2.1.1.4. Отзыв и обновление сертификата
ЦС должен гарантировать, что процедуры отзыва и переиздания сертификата согласуются с соответствующими положениями данного Регламента. ЦС должен гарантировать, что данные об отзываемом сертификате будут занесены в СОС в сроки, устанавливаемые в пунктах 4.4.4 и 4.4.9. СОС ежемесячно публикуется на веб-сервере «Партнер». ЦС осуществляет контроль за соблюдением сроков публикации.
2.1.1.5. Защита закрытых ключей
ЦС должен обеспечивать защиту всех используемых закрытых ключей и данных, используемых при их генерации, в соответствии с требованиями разделов 4 и 6.
2.1.1.6. Ограничения на использование закрытых ключей ЦС
ЦС должен гарантировать, что закрытый ключ, предназначенный для подписи сертификатов и СОС, не используется ни для каких иных целей.
ЦС должен использовать свои ключи и сертификаты только для целей, допустимых данным Регламентом.
2.1.2. Обязанности ЦР
В своей деятельности ЦР должен руководствоваться данным Регламентом.
ЦР отвечает за доведение до сведения владельцев сертификатов доступности всей информации, касающейся прав и обязанностей ЦС, ЦР, владельцев и пользователей сертификатов, содержащейся в данном Регламенте.
2.1.2.1. Уведомление об издании и отзыве сертификата
Не регламенировано.
2.1.2.2. Точность представления
Когда ЦР передает на рассмотрение ЦС информацию о пользователе, он должен гарантировать ЦС, что проверка личности пользователя и уполномоченного лица была проведена в соответствии с разделом 3 данного Регламента.
2.1.2.3. Защита закрытых ключей
Каждый ЦР должен гарантировать, что все используемые им закрытые ключи защищены в соответствии с требованиями разделов 5 и 6.
2.1.2.4. Ограничения на использование закрытых ключей ЦР
ЦР должен использовать свои ключи и сертификаты только для целей, допустимых данным Регламентом.
2.1.3. Обязанности владельца сертификата
Владелец сертификата обязан выразить согласие с положениями данного Регламента и следовать ему.
2.1.3.1. Точность представления
Любая информация, предоставляемая ЦР и связанная с сертификатами, должна быть исчерпывающей и достоверной.
2.1.3.2. Защита закрытых ключей владельцев сертификатов
Владельцы сертификатов обязаны защищать свои закрытые ключи в соответствии с требованиями раздела 6, федеральными законами РФ, иными нормативными документами и принимать все возможные меры для предотвращения их потери, раскрытия, модифицирования или несанкционированного использования.
2.1.3.3. Ограничения на использование закрытых ключей владельца сертификата
Владелец сертификата должен использовать ключи и сертификаты только для целей, разрешенных соответствующими дополнениями сертификата и данным Регламентом.
2.1.3.4. Оповещение о компрометации закрытого ключа
Если Владелец сертификата подозревает, что его ключ скомпрометирован, он должен немедленно оповестить об этом ЦР любым доступным способом с учётом требований, описанных в данном Регламенте.
2.1.4. Обязанности пользователей сертификатов
Пользователь сертификата обязан выразить согласие с положениями данного Регламента и следовать ему.
2.1.4.1. Использование сертификатов по назначению
Перед тем как использовать сертификат пользователь сертификата должен удостовериться, что назначение сертификата соответствует предполагаемому использованию.
2.2. Ответственность
2.2.1. Отказ от гарантий и обязательств
УЦ не несет никакой ответственности в случае нарушения пользователями или владельцами сертификатов положений данного Регламента.
2.2.2. Ограничения ответственности
Претензии к УЦ ограничиваются указанием на несоответствие его действий данному Регламенту.
2.3. Финансовые обязательства
В соответствии с действующем законодательством РФ.
2.4 Контроль за соблюдением Регламента
Положения настоящего Регламента должны рассматриваться в соответствии с нормативными документами по информационной безопасности и законами РФ.
Любые разногласия в отношении управления ключами и сертификатами должны разрешаться посредством соответствующего механизма урегулирования споров. По возможности, разногласия должны разрешаться путем совместных переговоров. В случаях, когда договоренность не достигается, спорная ситуация разрешается в судебном порядке в соответствии с законами РФ.
2.5 Платность услуг
Услуги УЦ предоставляются платно.
2.6 Опубликование и реестр сертификатов
УЦ не обязан публиковать никакой информации кроме СОС.
2.6.1 Предоставление информация о Регламенте
ЦР от имени ЦС предоставляет полную версию данного Регламента владельцам сертификатов при их регистрации.
ЦС предоставляет полную текстовую версию данного Регламента, когда это необходимо для целей аудита.
2.6.2 Предоставление сертификатов и СОС
ЦС отсылает (передаёт) пользователям их цифровые сертификаты открытых ключей после создания сертификата. СОС публикуется на веб-сервере «Партнер».
2.6.3 Периодичность рассылки
Публикация СОС должна производиться в соответствии с положениями раздела 4 данного Регламента.
Публикация Регламента производиться в соответствии с положениями раздела 8 данного Регламента.
2.7 Проверка соответствия
Проверка соответствия определяет соответствие реализации УЦ требованиям, предъявленным в его Регламенте.
2.7.1 Периодичность проверок соответствия
Проверка УЦ должна проводиться ежегодно.
2.7.2 Личность и квалификация аудитора УЦ
Для проведения проверок УЦ назначается лицо, обладающее богатым опытом работы с инфрастуктурой открытых ключей (ИОК), криптографическими технологиями, программным обеспечением УЦ и четко представляющее положения данного Регламента.
2.7.3 Отношение аудитора к проверяемому УЦ
Для проведения объективных и независимых проверок аудитор должен быть организационно независимым от проверяемого УЦ.
2.7.4 Предметы проверки
Предметом проверки соответствия является реализация в УЦ положений данного Регламента.
2.7.5 Действия, предпринимаемые по результатам проверки
Любые расхождения между действиями УЦ и положениями данного Регламента должны быть доложены уполномоченному лицу УЦ и лицу, ответственному за информационную безопасность системы, использующей данный УЦ. Должны быть определены меры по устранению нарушений, в том числе время устранения нарушений.
Меры могут включать следующие процедуры:
· указать на нарушения, но разрешить УЦ продолжать деятельность до следующей плановой проверки;
· разрешить УЦ продолжать деятельность, обязав в тридцатидневный срок устранить все нарушения (иначе, деятельность УЦ будет прекращена);
· временно прекратить деятельность УЦ.
Решение о применении конкретного действия должно базироваться на степени тяжести нарушений и степени возникающих рисков.
2.7.6 Сообщение результатов
Результаты проверки должны быть сообщены УЦ сразу после завершения проверки. Доведение результатов проверки до пользователей УЦ определяется выявленными нарушениями и принимаемыми мерами по их устранению.
Необходимые меры должны быть определены и сообщены УЦ в максимально короткие сроки для снижения возникших рисков. Для определения эффективности предпринимаемых мер может быть назначена дополнительная проверка.
2.8 Политика конфиденциальности
2.8.1 Типы конфиденциальной информации
Закрытый ключ подписи владельца сертификата является конфиденциальной информацией данного пользователя. УЦ не имеет никакого доступа к этим ключам.
Персональная и корпоративная информация, содержащаяся в ЦС и ЦР, не подлежащая непосредственной рассылке в качестве части цифрового сертификата, СОС или данного Регламента, считается конфиденциальной и не должна опубликовываться.
Обработка всей информации, содержащейся в локальных хранилищах в ЦС или ЦР должна учитывать критичный характер этой информации; правами доступа должны обладать только те служащие, для которых это необходимо для выполнения своих служебных обязанностей.
Информация, хранящаяся в журналах аудита, считается конфиденциальной и не подлежит разглашению.
Результаты ежегодных проверок являются конфиденциальными, за исключением случаев, описанных в разделе 2.7.
2.8.2 Типы информации, не относящейся к конфиденциальной
Информация, включаемая в сертификаты и СОС, издаваемые ЦС, считается не конфиденциальной.
Также не считается конфиденциальной информация о Регламенте и сам Регламент.
2.8.3 Оглашение информации об отзывах сертификатов
Когда сертификат отзывается или его действие приостанавливается, в элемент СОС включается код причины. Данный код причины не считается конфиденциальным и доступен всем пользователям. Однако никакие иные подробности отзыва не должны раскрываться.
2.8.4 Исключительные полномочия официальных лиц
УЦ не должен раскрывать информацию, касающуюся сертификатов, каким бы то ни было третьим сторонам за исключением случаев:
· санкционированных данным Регламентом;
· требующих раскрытия в соответствии с действующим законодательством или при наличии судебного постановления.
2.9 Права на интеллектуальную собственность
Сертификаты и СОС, изданные УЦ и настоящий Регламент являются собственностью организации, ответственной за эксплуатацию УЦ.
Отличительные имена (DN), используемые для представления пользователей в хранилищах и в сертификатах, включая относительные отличительные имена (RDN), также являются собственностью организации, ответственной за эксплуатацию УЦ.
3. Идентификация и аутентификация
3.1 Начальная регистрация
3.1.1 Типы имен
В качестве имен издателей и владельцев сертификатов используется форма отличительного имени X.500.
Все атрибуты отличительного имени должны соответствовать ITU-T рекомендации X.521 Информационная Технология – Взаимодействие Открытых Систем - Директорий: Классы Избранных Объектов (1988).
3.1.2 Осмысленность имен
Содержимое поля имя издателя и имя владельца в любом сертификате должно непосредственно ассоциироваться с установленным именем пользователя.
3.1.3 Правила интерпретации различных форм имен
Не регламентируется.
3.1.4 Уникальность имен
Отличительные имена должны быть уникальны для всех пользователей. Уникальность отличительных имен X.500 должна обеспечиваться ЦС и ЦР, удостоверяющих соответствующих пользователей.
3.1.5 Метод доказательства обладания секретным ключом
Не регламентировано.
3.1.6 Регистрация частных лиц
Заявление частного лица на включение в число пользователей системы подается данным лицом в письменной форме и заверяется собственноручной подписью.
Ответственность за проведение проверки личности лица, обращающегося за получением сертификата, возлагается на ЦР. ЦР должен получить подтверждение об идентичности абонента. ЦР должен регистрировать и архивировать аутентифицирующие данные, описанные ниже.
Идентификация и аутентификация личности должна включать следующие мероприятия:
· ЦР должен сохранить и записать дату проведения проверки идентичности;
· ЦР должен сохранить и записать паспортные данные проверяемого лица.
Податель заявления подтверждает в письменном виде, что он ознакомлен с порядком и условиями, определяющими использование сертификатов.
3.1.7 Аутентификация устройств и программных приложений
Для получения сертификатов, требующихся для работы устройств и программных приложений, назначается ответственное лицо, на имя которого выдается сертификат. Регистрация ответственного лица должна производиться в соответствии с требованиями пункта 3.1.6, как если частное лицо обращается с заявлением на включение в число пользователей системы.
ЦР должен также проверить идентичность частного лица, делающего заявку, а также полномочия заявителя на право получения ключей для устройства или приложения.
3.2 Процедура смены сертифицируемого ключа
Владелец сертификата обязан периодически, в соответствии с установленными срока действия открытых и закрытых ключей (п. 6.3.2) сменять свои ключи и сертификаты. Запрос на смену сертификата может быть сделан только его владельцем.
3.3 Смена сертифицируемого ключа после отзыва сертификата
Используется процедура, описанная в разделе 3.1.
3.4 Запрос на отзыв сертификата
ЦС или ЦР должны установить подлинность запроса на отзыв сертификата.
3.5 Список всех действий пользователя, выполнение которых разрешено до его идентификации и аутентификации
До идентификации и аутентификации пользователя никакие действия ему не разрешаются.
3.6 Перечень подлежащих защите данных, поступающих в УЦ
Следующие данные, поступающие в УЦ, должны быть подписаны пользователями с использованием их рабочих закрытых ключей:
· запрос на сертификат.
3.7 Перечень подлежащих защите данных, экспортируемых из УЦ
Не регламентировано.
3.8 Перечень процессов, для которых допускается обращение к техническим средствам УЦ
К техническим средствам УЦ имеют доступ следующие процессы.
Центр Сертификации:
· Cpinit. exe – служба инициализации КриптоПро.
· Cprmcsp. exe – служба хранения и использования ключей КриптоПро.
· Certsrv. exe – службы сертификации.
· Dllhost. exe.
· Inetinfo. exe – обеспечивает связь и администрирование веб-узла.
· Services. exe – защищенное хранилище.
· System. exe.
· Logon. exe.
Центр Регистрации:
· Cpinit. exe – служба инициализации КриптоПро.
· Cprmcsp. exe – служба хранения и использования ключей КриптоПро.
· Dllhost. exe.
· Inetinfo. exe – обеспечивает связь и администрирование веб-узла.
· Services. exe – защищенное хранилище.
· Sqlservr. exe – MSSQLSERVER.
· System. exe.
· Logon. exe.
АРМ Администратора:
· Cpinit. exe – служба инициализации КриптоПро.
· Cprmcsp. exe – служба хранения и использования ключей КриптоПро.
· Dllhost. exe.
· System. exe.
· Logon. exe.
3.9 Список объектов доступа и целевых функций УЦ
Администраторы УЦ должны контролировать доступ к следующим объектам:
· криптографические ключи;
· база данных ЦС;
· база данных ЦР;
· хранилище сертификатов ЦС;
· запросы на сертификат;
· технические средства УЦ.
Администраторы УЦ должны контролировать доступ к следующим целевым функциям УЦ:
· формирование ключей;
· формирование сертификатов;
· отзыв сертификатов;
· формирование СОС;
· рассылка сертификатов и публикация СОС;
· резервное копирование и восстановление баз данных УЦ;
· регистрация пользователей.
4. Эксплуатационные требования
4.1 Запрос на выдачу сертификата
Запрос на выдачу сертификата формируется пользователем и передается через ЦР в ЦС, где и обрабатывается. Запрос на выдачу сертификата заверяется с использованием закрытого рабочего ключа.
Подача запроса на получение сертификата не обязывает ЦС издавать сертификат.
4.2 Издание сертификата
Процедура издания сертификата заключается в следующем: ЦС генерирует и подписывает сертификат, а затем отсылает (передаёт) его пользователю через ЦР.
4.3 Получение сертификата
Не регламентировано.
4.4 Приостановка действия и аннулирование сертификата
4.4.1 Условия отзыва
Сертификат должен быть отозван, если информация в нем более не может пользоваться доверием. Причины отзыва сертификата:
· компрометация или подозрение на компрометацию закрытого ключа;
· изменение идентифицирующей информации или атрибутов в сертификате пользователя до истечения срока действия сертификата;
· увольнение владельца сертификата;
· невыполнение владельцем сертификата своих обязательств, изложенных в данном Регламенте и других регламентирующих документах.
4.4.2 Кто может потребовать отзыв
Запрос на отзыв сертификата может быть сделан:
· владельцем сертификата;
· ЦС;
· ЦР.
4.4.3 Процедура запроса на отзыв
Запросы на отзыв должны содержать:
· информацию, позволяющую идентифицировать сертификат, который следует отозвать;
· причину отзыва;
· данные, позволяющие проверить аутентичность запроса.
По принятии и согласии с запросом на отзыв сертификата, ЦС должен отозвать сертификат. Аутентифицированный запрос на отзыв и результат действий, предпринятых ЦС или ЦР, должны быть сохранены в архиве.
ЦС должен включить данные об отозванном сертификате в очередной СОС.
4.4.4 Время обработки запроса на отзыв
Любое действие, являющееся реакцией на запрос на отзыв сертификата, должно быть произведено в течение одного рабочего дня с момента приема отзыва.
4.4.5 Условия приостановления действия
ЦС может приостановить действие сертификата в случае временного прекращения выполнения владельцем своих обязанностей.
4.4.6 Кто может потребовать приостановления действия
Лица и организации, указанные в разделе 4.4.2.
4.4.7 Процедура запроса на приостановление действия
Запросы на приостановление действия должны содержать:
· информацию, позволяющую идентифицировать сертификат, действие которого следует приостановить;
· причину приостановления действия;
· данные, позволяющие проверить аутентичность запроса.
По принятии и согласии с запросом на приостановление действия сертификата, ЦС должен приостановить действие сертификата. Аутентифицированный запрос на приостановление действия и результат действий, предпринятых ЦС или ЦР, должны быть сохранены в архиве.
ЦС должен включить данные о сертификате в очередной СОС.
4.4.8 Ограничения периода временного приостановления
Период времени, на который приостанавливается действие сертификата, должен быть указан в запросе на приостановление действия сертификата.
4.4.9 Периодичность издания СОС
ЦС должен выпускать и обновлять СОС не реже чем раз в месяц, даже если за время с последнего момента обновления СОС не произошло никаких изменений.
4.4.10 Требования к проверке СОС
Не регламентируется.
4.4.11 Возможность проверки статуса сертификата в режиме on-line
Не регламентируется.
4.4.12 Требования к проверке статуса сертификата в режиме on-line
Не регламентируется.
4.4.13 Иные формы извещения об отзыве
Не регламентируется.
4.4.14 Проверка требований для иных форм извещения об отзыве
Не регламентируется.
4.4.15 Действия при компрометации ключей
В случае компрометации или подозрения на компрометацию ключа ЦС, используемого для подписи сертификатов и СОС, ЦС обязан немедленно оповестить об этом всех пользователей.
В любом случае компрометации ключа пользователь обязан немедленно оповестить об этом ЦС, издавший сертификат, или соответствующий ЦР.
4.4.16 Механизм проверки подписи в сертификате по запросу пользователя
УЦ должен производить проверку подписи в сертификате по запросу пользователя. Проверку подписи осуществляет ЦС с использованием стандартной процедуры проверки цепочки сертификатов, описанной в RFC 2459, и своего хранилища сертификатов и СОС.
4.5 Процедуры аудита безопасности
4.5.1 Типы записываемых событий
УЦ записывает в файлах журнала аудита все события, имеющие отношение к системе безопасности УЦ.
События, записываемые в журнал безопасности операционной системы:
· событие входа в систему с учетной записью;
· управление учетной записью;
· события входа в систему;
· изменение политики;
· использование привилегий;
Структура записи события:
· выполненное действие;
· пользователь, выполнивший это действие;
· описание события, произошедшего при этом, а также, было ли оно успешно.
События, записываемые в журнал регистрации событий на ЦР:
· регистрация пользователей;
· выпуск сертификатов;
· отзыв сертификатов;
· запросы на сертификат.
Структура записи события:
· дата события;
· тип события;
· объект;
· субъект.
События, записываемые в журнал web-сервера на ЦР (сведения о действиях пользователей):
· дата возникновения события;
· время возникновения события;
· IP-адрес клиента, получающего доступ к серверу;
· имя пользователя, получающего доступ к серверу;
· номер порта, к которому подключен клиент;
· действие, которое пытался выполнить клиент
· ресурс, к которому осуществляется доступ
· запрос (если имеется), который пытался выполнить клиент
· состояние действия
· заняло времени;
4.5.2 Частота обработки журнала аудита
УЦ должен гарантировать, что его журналы аудита подвергаются просмотру не реже одного раза в две недели. Подобные просмотры включают проверку того, что журнал не подвергался искажениям, а также краткому изучению всех событий в журнале с обращением особого внимания на сообщения о несоответствиях и предупреждения об опасных ситуациях. При возникновении записей о подозрительных действиях применяется сопоставление журналов аудита ЦС и ЦР.
4.5.3 Срок хранения информации в журнале аудита
УЦ обязан сохранять свои журналы аудита на месте эксплуатации по крайней мере в течении месяца и последовательно переводить их в режим архивного хранения согласно описанному в разделе 4.6 данного Регламента.
4.5.4 Защита журнала аудита
Система ведения электронного журнала аудита должна включать механизмы защиты файлов журнала от неавторизованного просмотра, модификации и удаления. Рукописные журналы должны быть заверены подписью одного из авторизованных служащих УЦ.
4.5.5 Процедуры резервного копирования журнала аудита
Должно выполняться резервное копирование журналов аудита.
4.5.6 Система сбора данных о регистрируемых событиях
Не регламентируется.
4.5.7 Оповещение субъекта, активировавшего событие
В случае попадания события в систему регистрации, оповещение лиц, организаций, устройств и приложений, активизировавших данное событие, не является обязательным, но также и не запрещается.
4.5.8 Оценка уязвимости
Персонал УЦ должен проявлять бдительность по отношению к попыткам нарушения целостности системы управления сертификатами. УЦ должен использовать процессы, определенные в разделе 4.5 данного Регламента, для мониторинга и оценки уязвимостей, а также проведения работ по их устранению.
4.6 Архивирование документов
4.6.1 Типы архивируемых данных
Архивированию подлежат, как минимум, следующие данные:
· сертификаты;
· данные аудита согласно положениям раздела 4.5;
· заявки на получение сертификатов;
· идентифицирующая и аутентифицирующая информация, предоставленная пользователями.
4.6.2 Срок архивного хранения
Все данные, перечисленные в разделе 4.6.1, должны содержаться в архиве на протяжении 5 лет.
4.6.3 Защита архива
Защита архивируемой информации должна осуществляться методами физического обеспечения безопасности или комбинацией методов физической и криптографической защиты.
4.6.4 Процедуры резервного копирования архива
Все резервные файлы архивируемой информации должны храниться в защищенном месте.
4.6.5 Система сбора данных для архива
Не регламентируется.
4.6.6 Процедуры получения и проверки архивной информации
Только уполномоченный персонал имеет доступ к архивной информации. Процедуры получения и проверки архивной информации не регламентируются.
4.7 Обновление ключей
Владельцы сертификатов должны предпринять все необходимые действия для обновления своих ключей ЭЦП и сертификатов, прежде чем срок их действия истечет.
4.8 Восстановление после компрометации и прочих бедствий
4.8.1 Восстановление после компрометации
В случае компрометации ключа ЦС, используемого для подписи сертификатов и СОС, вся система должна быть остановлена.
Для восстановления системы необходимо:
· повторно произвести формирование ключа и сертификата ЦС;
· произвести выпуск новых сертификатов всех пользователей;
· обеспечить получение новых личных сертификатов пользователями системы.
4.8.2 Восстановление после прочих бедствий
В случае повреждения оборудования ЦС вследствие каких-либо бедствий ЦС должен принять все возможные меры для скорейшего восстановления своей работоспособности. Приоритет должен быть отдан возможности отзыва сертификатов и выпуска СОС. В случае невозможности восстановления функции отзыва сертификатов до окончания срока действия СОС ЦС должен объявить свои ключи скомпрометированными и действовать в соответствии с разделом 4.8.1.
4.9 Прекращение функционирования УЦ
Деятельность УЦ может быть прекращена в порядке, установленном гражданским законодательством.
В случае прекращения деятельности УЦ все сертификаты, выданные этим УЦ, могут быть переданы другому УЦ.
Сертификаты, не переданные в другой УЦ, аннулируются.
Архивы УЦ должны быть сохранены в порядке и на сроки, указанные в разделе 4.6 данного Регламента.
5. Физический, процедурный и персональный контроль безопасности
5.1 Физический контроль безопасности
5.1.1 Размещение и построение технических средств УЦ
Технические средства УЦ должны удовлетворять следующим требованиям:
· доступ к ним имеет только уполномоченный персонал;
· сервера УЦ постоянно находятся в режиме ручного и/или электронного обнаружения неавторизованных вторжений;
· доступом без сопровождения к техническим средствам УЦ обладает только персонал, определенный в списке доступа;
· персонал, не находящийся в списке доступа, соответствующим образом сопровождается и контролируется.
5.1.2 Физический доступ
Контроль целостности технических средств УЦ должен осуществляться при каждой загрузке ЦС и ЦР, но не реже 1 раза в неделю.
Оборудование УЦ в активированном состоянии должно быть защищено от неавторизованного доступа.
После ввода пароля, защищающего закрытый ключ, пользователи не должны оставлять свои рабочие места без присмотра.
5.1.3 Электроснабжение и кондиционирование воздуха
Помещение, в котором размещается оборудование УЦ, должно быть обеспечено электроснабжением и системой кондиционирования в объеме достаточном для создания приемлемых условий работы.
5.1.4 Подверженность воздействию влаги
Оборудование УЦ должно быть установлено таким образом, чтобы не было угрозы со стороны воздействия влаги.
5.1.5 Предупреждение и защита от возгорания
Система пожаротушения должна применяться в соответствии с принятой в организации системой правил.
5.1.6 Хранение носителей
УЦ должен гарантировать, что хранение носителей информации, используемых в системе УЦ, защищено от угроз со стороны таких внешних факторов как температура, влажность и электромагнитное воздействие.
5.1.7 Уничтожение носителей
Носители, используемые для хранения такой информации как ключи, активационные данные или файлы УЦ должны быть уничтожены после окончания использования этих носителей.
5.1.8 Стороннее архивирование
Не регламентируется.
5.1.9 Перечень данных, сохраняемых при резервном копировании
ЦС должен осуществлять резервное копирование выданных сертификатов и очереди запросов на сертификаты.
ЦР должен осуществлять полное резервное копирование своей базы данных.
5.2 Процедурный контроль безопасности
5.2.1 Доверенные роли
УЦ должен обеспечивать поддержку следующих ролей:
· Системный администратор – администратор системы, выполняющий настройку и модификацию эксплуатационных параметров системы, диагностику и тестирование;
· Уполномоченное лицо УЦ – физическое лицо, на имя которого выписан сертификат, используемый для подписи от имени УЦ сертификатов и СОС;
· Администратор АРМ ЦР – администратор по работе с сертификатами.
5.2.2 Ролевая идентификация и аутентификация
Идентификация и аутентификация для служащих УЦ должны следовать требованиям, определенным в разделах 5.3, 5.3.1 и 5.3.2. Пункты этих разделов должны быть выполнены, прежде чем:
· служащие будут включены в список доступа к серверу УЦ.
5.3 Персональный контроль безопасности
Члены группы администраторов ЦС или ЦР, должны:
· назначаться уполномоченным лицом УЦ;
· иметь всестороннюю подготовку с уделением особого внимания выполнению их непосредственных обязанностей;
· не иметь обязанностей, способных привести к конфликтам интересов с их обязанностями в плане операций ЦС или ЦР.
5.3.1 Требования к биографическим данным, квалификации, опыту и уровню допуска
Уполномоченное лицо УЦ должно иметь высшее профессиональное образование или профессиональную подготовку в области информационной безопасности.
Члены группы администраторов должны иметь высшее профессиональное образование или пройти переподготовку (повышение квалификации).
5.3.2 Процедуры проверки биографии
Не регламентированы.
5.3.3 Требования к подготовке
Персонал, выполняющий обязанности, связанные с операциями ЦС или ЦР, должен достаточные знания в следующих областях:
· принципы и механизмы безопасности ЦС и ЦР, основные положения данного Регламента;
· принципы работы программного и/или аппаратного обеспечения, используемого в системе УЦ;
· конкретные обязанности, выполнение которых предусмотрено для этого персонала.
5.3.4 Требования к переподготовке, частота переподготовки
Переподготовка членов группы администраторов должна проводиться с учетом изменений в системе УЦ.
5.3.5 Очередность работ
Не регламентируется.
5.3.6 Санкции к неавторизованным действиям
В случае реального или предполагаемого неавторизованного действия лицом, выполняющим обязанности, связанные с операциями ЦС или ЦР, ЦС или ЦР могут приостановить доступ этого лица к системе УЦ.
5.3.7 Служащие по контракту
Служащие по контракту, обеспечивающие деятельность какой-либо из частей ЦС или ЦР должны пройти проверку на надежность, соответствующую уровню, которого требует выполняемая роль согласно разделу 5.3.1.
5.3.8 Документация, предоставляемая служащим
ЦС должен обеспечить доступ служащим этого ЦС и соответствующего ЦР к данному Регламенту и иной документации, достаточной для определения обязанностей и процедур, соответствующих положениям этих служащих.
6. Технический контроль безопасности
6.1 Генерация и ввод в действие пар ключей
6.1.1 Генерация пары ключей
Генерация ключей подчиненного УЦ производится на АРМ администратора соответствующего УЦ.
Генерация рабочих ключей пользователей осуществляется СКЗИ, входящим в состав абонентского комплекта СКЗИ.
6.1.2 Доставка закрытого ключа до пользователя
Рабочие ключи формируются самим пользователем или, в случае согласия пользователя, сотрудниками РЦ.
6.1.3 Доставка открытого ключа до издателя сертификата
Открытый ключ доставляется пользователем до ЦР в составе запроса на сертификат любым способом, включая передачу по открытым каналам связи. ЦР пересылает (передаёт) его в ЦС.
6.1.4 Доставка открытого ключа УЦ до пользователей
Открытый ключ ЦС, используемый для подписи сертификатов и СОС, должен передаваться пользователю при его регистрации.
6.1.5 Размеры асимметричных ключей
При использовании алгоритма ГОСТ Р 34.10-94 длина закрытого ключа должна быть не менее 256 бит, открытого - 1024 бит. Использование алгоритма ГОСТ Р 34.10-94 допускается до 01.01.2007.
При использовании алгоритма ГОСТ Р 34.10-2001 длина закрытого ключа должна быть не менее 256 бит, открытого - 512 бит.
6.1.6 Генерация параметров открытого ключа
Не регламентируется.
6.1.7 Проверка качества параметров
Не регламентируется.
6.1.8 Аппаратная и программная генерация ключа
Генерация всех ключей осуществляется программным способом.
6.1.9 Цели использования ключа
Ключи должны использоваться только для тех целей, которые указаны в дополнениях сертификата KeyUsage и ExtendedKeyUsage.
6.2 Защита закрытого ключа
Владелец сертификата обязан обеспечить защиту своих закрытых ключей от раскрытия.
Закрытые ключи пользователей должны быть защищены от неавторизованного использования при помощи комбинации механизмов криптографического и физического контроля доступа.
6.2.1 Стандарты для криптографического модуля
Криптографические модули не используются.
6.2.2 Мультиперсональный контроль закрытого ключа
Мультиперсональный контроль закрытого ключа не используется.
6.2.3 Депонирование закрытого ключа
Депонирование закрытых ключей не должно осуществляться ни при каких обстоятельствах.
6.2.4 Резервное хранение закрытого ключа
Копирование любых закрытых ключей УЦ и пользователей не допускается за исключением создания резервных копий ключей. В этом случае дубликаты ключей должны храниться и регистрироваться наравне с оригиналом.
6.2.5 Архивирование закрытого ключа
Не регламентировано.
6.2.6 Введение закрытого ключа в криптографический модуль
Криптографические модули не используются.
6.2.7 Метод активации закрытого ключа
Активация закрытого ключа должна осуществляться после введения пароля. Ввод активационных данных должен быть защищен от вскрытия, например, вводимые данные не должны отображаться на экране.
6.2.8 Метод деактивации закрытого ключа
Закрытые ключи после активации не должны оставляться без присмотра или иным образом открытыми для неавторизованного доступа. После использования они должны быть деактивированы, например, посредством ручного выполнения процедуры выхода или по истечении определенного времени отсутствия активности оператора. Ключевые носители, не находящиеся в данный момент в использовании, должны быть изъяты и помещены в надежное место хранения.
После деактивации ключей они должны быть удалены из памяти, перед тем как память будет освобождена. Любые места на дисковых накопителях, где были сохранены ключи, должны быть перезаписаны перед тем, как данные места освободятся для использования операционной системой.
После деактивации, закрытые ключи должны храниться только в зашифрованном виде.
6.2.9 Метод уничтожения закрытого ключа
После завершения использования закрытого ключа он должен быть удален с ключевого носителя средствами СКЗИ (Крипто-Про CSP).
6.3 Иные аспекты управления парами ключей
6.3.1 Архивирование открытого ключа
Архивирование открытого ключа осуществляется при архивировании сертификата.
6.3.2 Сроки действия для открытых и закрытых ключей
Срок действия ключей и сертификатов:
· закрытый ключ ЦС (используемый для подписи сертификатов и СОС) - 5 лет при использовании СКЗИ «Крипто-Про CSP» (формуляр ЖТЯИ.00005;
· открытый ключ и сертификат ЦС - 5 лет;
· другие закрытые и открытые ключи и сертификаты ЦС и ЦР – 1 год;
· закрытые и открытые ключи и сертификаты пользователей - 1 год.
6.3.3 Описание формируемой и/или хранимой в УЦ ключевой информации
В процессе функционирования УЦ формирует и/или хранит следующие пары закрытых и открытых ключей:
· ключ ЦС (ключ, используемый для подписи сертификатов и СОС);
· ключ подписи сервера УЦ;
· ключ шифрования сервера УЦ;
· ключ ЦР;
· ключ администратора АРМ ЦР;
6.3.4 Допустимые объемы формируемой и/или хранимой в УЦ ключевой информации
Объем формируемой в УЦ ключевой информации не ограничивается.
Закрытые ключи пользователей не хранятся в УЦ.
6.3.5 Процедура контроля соответствия электронного сертификата бумажной копии
Контроль соответствия электронного сертификата бумажной копии осуществляется путем сравнения содержимого каждого поля сертификата на его бумажной копии и в диалоге отображения сертификата.
6.4 Данные активации
6.4.1 Генерация и инсталляция активационных данных
В качестве данных активации закрытых ключей должны использоваться пароли.
Пользователь имеет возможность изменения пароля в любое время.
6.4.2 Защита активационных данных
Активационные данные должны пересылаться непосредственно в оперативную память без записи на диск.
Активационные данные ни при каких условиях не должны разглашаться.
6.4.3 Иные особенности активационных данных
Не регламентируется.
6.5 Контроль защищенности вычислительной техники
6.5.1 Технические требования по компьютерной безопасности
Технические средства УЦ должны включать следующую функциональность:
· контроль доступа к сервисам УЦ и ролям УЦ;
· идентификацию и аутентификацию ролей УЦ и соответствующих членов группы администраторов;
· криптографическую защиту передаваемых сообщений и базы данных;
· архивирование данных пользователей и аудита УЦ;
· аудит событий, относящихся к обеспечению безопасности;
· механизмы восстановления ключей и системы УЦ.
Данная функциональность может предоставляться средствами операционной системы или комбинацией средств операционной системы, программного обеспечения УЦ и физических средств обеспечения безопасности.
6.5.2 Рейтинг компьютерной безопасности
Не регламентируется.
6.5.3 Класс используемых СКЗИ
В УЦ используются средства криптографической защиты информации класса КС1.
6.5.4 Меры, принятые для обеспечения надежности и устойчивости функционирования УЦ
Для обеспечения надежности и устойчивости функционирования УЦ должны использоваться:
· резервное копирование данных в соответствии с разделом 5.1.9 данного Регламента;
· межсетевые экраны (в случае использования удалённого доступа к УЦ).
6.6 Контроль защищенности на протяжении жизненного цикла
6.6.1 Контроль процесса разработки системы
Не регламентируется.
6.6.2 Контроль управления безопасностью
Для управления безопасностью ЦС:
· оборудование ЦС не должно иметь установленных приложений или компонент программного обеспечения, не требующихся для работы ЦС;
· обновление оборудования УЦ должно производиться доверенным и подготовленным персоналом.
6.7 Контроль защищенности сетевой среды
Удаленный доступ к УЦ должен быть защищен с использованием протокола безопасного соединения.
6.8 Контроль разработки криптографических модулей
Криптографические модули не используются.
7. Структуры сертификатов и СОС
7.1 Структура сертификата
7.1.1 Номер версии
ЦС издает сертификаты формата X.509 версии 3.
Поддерживаются следующие базовые поля X.509:
Signature: | подпись ЦС |
Issuer: | отличительное имя ЦС |
Validity: | даты начала и окончания срока действия сертификата |
Subject: | отличительное имя владельца сертификата |
SubjectPublicKeyInformation: | идентификатор алгоритма, ключ |
Version: | версия сертификата формата X.509 - версия 3 |
SerialNumber: | уникальный серийный номер сертификата |
7.1.2 Дополнения сертификата
Поддерживаются следующие дополнения сертификата:
AuthorityKeyIdentifier | идентификатор ключа издателя сертификата |
SubjectKeyIdentifier | идентификатор ключа владельца сертификата |
KeyUsage | область применения ключа |
EnhancedKeyUsage | расширенная область применения ключа |
CRLDistributionPoint | точка распространения СОС |
7.1.3 Объектные идентификаторы алгоритма
УЦ поддерживает следующие алгоритмы:
ГОСТ Р 34.10-94 | 1.2.643.2.2.20 |
Диффи-Хеллмана | 1.2.643.2.2.99 |
ГОСТ Р 34.10-2001 | 1.2.643.2.2.19 |
Диффи-Хеллмана | 1.2.643.2.2.98 |
ГОСТ Р 34.11-94 | 1.2.643.2.2.9 |
ГОСТ | 1.2.643.2.2.21 |
7.1.4 Формы имени
В сертификате поля отличительных имен издателя и владельца сертификата содержат полное X.500 отличительное имя издателя и владельца сертификата соответственно.
7.1.5 Ограничения на имена
Не регламентируется.
7.1.6 Объектный идентификатор Регламента
Не регламентируется.
7.1.7 Использование дополнения Policy Constraints
Не регламентируется.
7.1.8 Синтаксис и семантика спецификаторов Регламента (Policy Qualifiers)
Не регламентируется.
7.1.9 Обработка критичного дополнения Certificate Policy
Дополнение Certificate Policy в системе не используется.
7.2 Структура СОС
7.2.1 Номер версии
ЦС издает СОС формата X.509 версии 2.
7.2.2 Дополнения СОС
Поддерживаются следующие дополнения СОС:
Authority Key Identifier | идентификатор ключа ЦС |
8. Технические требования к администрированию
8.1 Процедуры изменения спецификации
Все положения данного Регламента должны ежегодно анализироваться. Ошибки, обновления или предложения по изменению данного документа должны сообщаться согласно разделу 1.4.
8.1.1 Пункты, которые могут изменяться без извещения
Изменения в пункты данного Регламента, которые по оценкам УЦ не оказывают либо оказывают минимальное влияние на пользователей, использующих сертификаты и СОС, изданные в соответствии с данным Регламентом, могут вноситься без изменения номера версии документа и оповещения пользователей.
8.1.2 Изменения с оповещением
Изменения в Регламенте, которые, по оценкам УЦ, могут иметь значительное влияние на пользователей, использующих сертификаты и СОС, изданные в соответствии с данным Регламентом, могут вноситься при условиях оповещения пользователей в течение 30 дней и соответствующего увеличения номера версии документа.
8.2 Процедуры опубликования и оповещения
Регламент публикуется на web-сайте «Партнер».
В случае необходимости должно осуществляться распространение Регламента всем запросившим по электронной почте.
8.3 Процедуры подтверждения практических положений Регламента системы
Не регламентируется.
Разработан ____________________
«01» сентября 2004 г.
Приложение 1.
Сокращения
РФ – Российская Федерация;
СОС – список отозванных сертификатов;
УЦ – удостоверяющий центр;
ЦР – центр регистрации;
ЦС – центр сертификации;
ИОК – инфраструктура открытых ключей.
Разработан ____________________
«01» сентября 2004 г.
Приложение 2.
Термины
Аутентификация
Проверка принадлежности субъекту доступа предъявленного им идентификатора, подтверждение подлинности.
Закрытый ключ
Криптографический ключ, который хранится пользователем системы в тайне. Он используется для формирования электронной цифровой подписи и/или шифрования данных.
Запрос на сертификат
Сообщение, содержащее необходимую информацию для получения сертификата.
Запрос на отзыв сертификата
Сообщение, содержащее необходимую информацию для отзыва сертификата.
Идентификация
Присвоение субъектам и объектам доступа идентификатора и (или) сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов.
Ключ (криптографический ключ)
Конкретное секретное состояние некоторых параметров алгоритма криптографического преобразования данных, обеспечивающее выбор одного преобразования из совокупности всевозможных для данного алгоритма преобразований.
Ключевая пара
Открытый и закрытый ключи.
Ключевой носитель
Носитель, содержащий один или несколько ключей.
Компрометация ключа
Утрата доверия к тому, что используемые ключи обеспечивают безопасность информации.
Открытый ключ
Криптографический ключ, который связан с закрытым ключом с помощью особого математического соотношения. Открытый ключ известен другим пользователям системы и предназначен для проверки электронной цифровой подписи и шифрования. При этом открытый ключ не позволяет вычислить закрытый ключ.
Плановая смена ключей
Смена ключей с установленной в системе периодичностью, не вызванная компрометацией ключей.
Сертификат
Цифровой документ, который содержит открытый ключ субъекта и подписан электронной цифровой подписью его издателя. Сертификат также содержит сведения о владельце открытого ключа, например, информацию, которая его дополнительно идентифицирует. Таким образом, выдавая сертификат, издатель удостоверяет подлинность связи между открытым ключом субъекта и информацией, которая его идентифицирует.
Формат сертификата определен в рекомендациях ITU-T 1997 года X.509 и рекомендациях IETF 1999 года RFC 2459.
Список отозванных сертификатов
Созданный ЦС список сертификатов, отозванных до окончания срока их действия.
Центр сертификации
Компонент удостоверяющего центра. Выполняет функции службы сертификации: выпуск сертификатов, отзыв сертификатов, а также генерацию списков отзыва.
Центр регистрации
Компонент удостоверяющего центра. Выполняет функции промежуточного звена, осуществляющего передачу запросов от пользователей и администраторов центра регистрации центру сертификации.
Разработан ____________________
«01» сентября 2004 г.
