Обсуждение системы

[Борис]

Добрый день.

Мы в нашей организации заинтересовались вашим продуктом для учета СКЗИ и
ключевой информации. Однако сразу возникла довольно большое препятствие для
перевода наших текущих процессов учета на ваш продукт. Дело в том, что
многие наши сотрудники работают сразу с несколькими ключами электронной
подписи для разных информационных систем, при этом мы стараемся по
возможности размещать такие ключи на одном носителе, чтобы получался один
ключевой документ. Ваш же продукт, насколько я понял подразумевает только
одну ключевую информацию на одном носителе. Из этого вытекает второй вопрос
- какой порядок действий на данный момент подразумевается при обновлении
ключа электронной подписи (при истечении срока действия сертификата)? Не
планируете ли вы добавить возможность учета нескольких ключевых информаций
на одном носителе и ввести понятие "обновления" ключевого документа в
случае, когда на одном носителе записано несколько ключей, но обновляется
только один из них?

[imbasoft]

Добрый день, Борис.

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

В программе это делается следующим образом:
1. Ключевой носитель регистрируется в справочнике "Носители конфиденциальной информации". Например, пусть это будет ruToken № 234002
2. Предположим вы на этом токене записали ключи для сдачи отчетности и ключи для Интернет Клиент-Банка. Тогда перечисленную ключевую информацию (ключи) вы регистрируете в справочнике "Ключевая информация", например, как "Ключ отчетности 2016 (Иванов И. И,) SN: 12 22 FA" и "Ключ ДБО СуперБанк 2016 (Иванов И. И.) SN: 01 22"
3. Затем вы делаете 2 акта создания ключевых документов:
3.1. В первом Акте вы указываете ключевую информацию "Ключ отчетности 2016 (Иванов И. И,) SN: 12 22 FA" и ключевой носитель ruToken № 234002
3.2. Во втором Акте вы указываете ключевую информацию "Ключ ДБО СуперБанк 2016 (Иванов И. И.) SN: 01 22" и ключевой носитель ruToken № 234002
4. Таким образом у вас в системе будет зарегистрировано два ключевых документа:
4.1. "Ключ отчетности 2016 (Иванов И. И,) SN: 12 22 FA" на носителе ruToken № 234002
4.2. "Ключ ДБО СуперБанк 2016 (Иванов И. И.) SN: 01 22" на носителе ruToken № 234002

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

[Борис]

4. Таким образом у вас в системе будет зарегистрировано два ключевых документа:
4.1. "Ключ отчетности 2016 (Иванов И. И,) SN: 12 22 FA" на носителе ruToken № 234002
4.2. "Ключ ДБО СуперБанк 2016 (Иванов И. И.) SN: 01 22" на носителе ruToken № 234002

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

[imbasoft]

Давайте взглянем на определение ключевого документа, приведенное в документации к программе (Методология учета) и так же указано в Постановлении Правительства № 313:

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

Из определения видно, что ключевой документ это совокупность ключевой информации и ключевого носителя.

Да, таким образом получается как бы два ключевых документа. Хотя на самом деле он один.

После ввода двух Актов создания КД мы в результате получили два ключевых документа, Это легко можно проверить, путем построения отчет "Перечень ключевых документов"

[Борис]

Спасибо за быстрые ответы!

У нас все-таки немного разное понимание термина "ключевой документ"

Из определения видно, что ключевой документ это совокупность ключевой информации и ключевого носителя.

это так. И при связке "один носитель - одна ключевая информация" у нас нет противоречий. А вот когда на один носитель записывается несколько ключевых иноформаций, на наш взгляд, это один ключевой документ, а не несколько. Определение не обязывает, чтобы на одном ключевом документе была только одна ключевая информация.

После ввода двух Актов создания КД мы в результате получили два ключевых документа, Это легко можно проверить, путем построения отчет "Перечень ключевых документов"

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

Надеюсь я понятно изложил свою позицию =)

[imbasoft]

В программе разная ключевая информация записанная на одном ключевом носителе образует разные ключевые документы.

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

Вероятно, вы интуитивно используете определение приведенное в ФАПСИ 152, а именно:

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

Это определение коренным образом отличается от определения приведенном в ПП-313!

Если в ФАПСИ-152 КД это в первую очередь НОСИТЕЛЬ, то в ПП-313 это в первую очередь ЭЛЕКТРОННЫЙ ДОКУМЕНТ.

С учетом организации конституционного строя в законодательства в РФ, Постановление Правительства имеет больший вес, нежели нормативный правовой акт органа государственной власти поэтому в программе используется определение представленное в ПП-313.

Так зачем множить сущности и оформлять один носитель как несколько ключевых документов?

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

[Борис]

Это определение коренным образом отличается от определения приведенном в ПП-313!

Если в ФАПСИ-152 КД это в первую очередь НОСИТЕЛЬ, то в ПП-313 это в первую очередь ЭЛЕКТРОННЫЙ ДОКУМЕНТ.

Спасибо! Все верно, мы пользуемся определением из 152 инструкции. Постараемся обдумать, какой из двух вариантов для нас будет более подходящим.

[Борис]

С вашего позволения, продолжу дискуссию =)

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

[imbasoft]

Вам не кажется, что при вашем подходе, когда ключевой документ это по сути сам ключ подписи, идет некоторое дублирование между "ключевой информацией" и "ключевым документом"?

Нет, дублирования нет. Для интуитивного понимания термин ключевая информация можно заменить на ключ, тогда ключевой документ будет экземпляром ключа. Или еще вариант, для программистов ключевая информация - класс, ключевой документ - объект.

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

В точку! Дело в том, что для Организаций, которые только начала учет первым этапом будет определить какая ключевая информация вообще есть. Затем определяют где это ключевая информация записана (например, для wildcart сертификатов, используемых в большом количестве систем, это очень важно). А затем, когда бизнес-процессы налажены определяют ответственных лиц.
Программа построена таким образом, чтобы вы могли сразу вести учет с фиксацией всех, требуемых нормативными документами параметров - ответственных лиц и носителей. С практической точки зрения подобный формализм очень хорошо способствует повышению дисциплины в коллективе, а также существенно упрощает служебные расследования и аудит.

Почему бы не уйти от использования понятия "ключевая информация" и считать начальной точкой сразу "ключевой документ"

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

[Борис]

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

Если ввести термин копии КД и рассматривать одну и ту же ключевую информацию на разных носителях как копии одного и того же КД на разных носителях, то ничего не потеряется. Но я понял вашу позицию.

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