imbasoft.ru

Установил менеджер безопасности 2.1
Отличная и задумка, и реализация.
Я человек, который работал в 1с еще со времен 7-ой версии и понимая её работу, разобрался в менеджере безопасности за 30 минут.
-Заметил не доработку, когда при формировании журнала ключевых документов по ФАПСИ 152 для обладателя конф.информации, в первом столбце формируется не наименование ключевого документа, а просто название ключевой информации. Хотя в журнале для органа крипто защиты формируется именно наименование ключевого документа(носитель+ключевая информация).
-И опять же в журнале ключевых документов по ФАПСИ 152 для обладателя конф.информации пустой столбец №7, который должен содержать ФИО пользователя СКЗИ, того кто в данный момент владеет ключевым документом, а данное поле пустое.
Это сделана намеренно из каких-то соображений или это ошибка??

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

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

Добрый день.

Рад, что вы смогли быстро разобраться в программе, а теперь к вопросам.

-Заметил не доработку, когда при формировании журнала ключевых документов по ФАПСИ 152 для обладателя конф.информации, в первом столбце формируется не наименование ключевого документа, а просто название ключевой информации. Хотя в журнале для органа крипто защиты формируется именно наименование ключевого документа(носитель+ключевая информация).

Это не баг, это фича , а если серьезно, то давайте разберемся поглубже с этими журналами.

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

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

Данные отличия вызваны особенностью работы ОКЗ и ОКИ, а также различиями в определениях КИ и КД. КД нельзя ввести в эксплуатацию, эксплуатировать можно только КИ.

Поясню на примере.
Организация купила в удостоверяющем центре квалифицированную электронную подпись (КЭП) Директора. В организации КЭП храниться на трех носителях:
1 - ruToken, которым пользуется главбух.
2 - eToken, которым пользуется директор
3 - CD-R, который содержит резервную копию ключевой информации и храниться в сейфе у начальника отдела ИБ.

Здесь "КЭП директора", это КИ, КД будут:
1. КЭП директора на ruToken
2. КЭП директора на eToken
3. КЭП директора на CD-R

Глав. бух использует КЭП для сдачи отчетности в ПФР и налоговую. Директор использует КЭП для участия в электронных торгах. Начальник отдела ИБ никак не использует КЭП, а просто хранит носитель (CD-R).

Таким образом КЭП используется в двух информационных системах:
1. Системе сдачи отчетности
2. Системы электронных торгов.

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

-И опять же в журнале ключевых документов по ФАПСИ 152 для обладателя конф.информации пустой столбец №7, который должен содержать ФИО пользователя СКЗИ, того кто в данный момент владеет ключевым документом, а данное поле пустое. Это сделана намеренно из каких-то соображений или это ошибка??

Это сделано намеренно. Как уже писал выше Журнал учета ключей для ОКЗ служит для отражения жизни ключевых документов, журнал учета ключей для ОКИ служит для отражения жизни КИ.
Проблема с журналами заключается в том, что они придумывались почти 20 лет назад (в 2001 году принят приказ ФАПСИ 152). В те времена было просто, один ключ, один носитель, одна система. В реально жизни, например у банков, ситуация не вписывается в эту парадигму. Там используется множество КД одной и той же КИ, которая может в разное время эксплуатироваться в различных системах.

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

Поясните более подробно про какие формы ввода идет речь Акты? Справочники?

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

Причину объяснил выше.

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

Если организация имеет одну УКЭП на трех носителях ( т.е по сути три ключевых документа). То все эти три ключевых документа(КН + КИ) и должны регистрироваться в журнале ОКИ и каждый под своим номером, а в столбце №4 на против каждого ключевого документа указывается номер экземпляра(1 экз., 2 экз., 3 экз). Должен вестись учет именно КД, а единицей учета должен выступать ключевой носитель, так написано 152 ФАПСИ.

Ввод в эксплуатация для ключевых документов в журнале ОКИ не указывается вовсе, ввод в эксплуатацию указывается только для СКЗИ(столбцы 9, 10, 11 относятся только к СКЗИ, а к ключевым документам не относятся. Они объединены и в шапке написано Отметка о подключении (установке) СКЗИ). А вот столбцы 7,8 заполняются где указывается информация о Пользователе СКЗИ, у которого сейчас КД.

Пример:
Администратор безопасности ООО "Шальная пуля" Иванов И.И по доверенности получает в УЦ "Криптон" УКЭП на носителе JaCarta, УКЭП оформленную на руководителя организации Петрова П.П для работы в АИС "Молния".
Ответственный сотрудник УЦ "Криптон" заполняет журнал Журнал учета ключей ОКЗ (орган криптозащиты) в котором указывает, что была сформирована(кем сформирована и когда) некая КИ в виде УКЭП на имя директора ООО "Шальная пуля" Петрова П.П , записана на JaCarta и передана по акту Иванову И.И по доверенности.
Далее сотрудник УЦ делает отметку в Журнале учета ключей ОКЗ (органа криптозащиты) о вводе КИ в эксплуатацию (т.е подгружает сам в АИС "Молния" открытый ключ на УКЭП Иванова П.П. или сообщает администратору системы, что создана новая КИ на Иванова П.П. и необходимо сертификат или открытый ключ подгрузить в информационную систему АИС "Молния" или это вообще делается подгрузка автоматически).
На этом заполнение Журнала учета ключей ОКЗ (органа криптозащиты) заканчивается.

Иванов И.И приезжает в офис ООО "Шальная пуля" берет Журнал учета ключей ОКИ (обладателя ключевой информации) и заполняет там столбцы 1,2,3,4,5,6,7,8,
столбец 1: номер по порядку,
столбец 2: УКЭП Иванов И.И носитель JaCarta s/n:123456,
Столбец 3: номера серии кд: "серийный номер сертификата или КИ",
Столбец 4:" 1(первый) экземпляр",
Столбец 5: "получены от УЦ "Криптон"
Столбец 6: получены по акту №56 от 12.12.12г
Далее делает отметку о выдаче (т.е кому в организации он передает этот КД) - может так же составляется Акт
Столбец 7: заместитель Бухгалтер ООО "Шальная пуля", Сидорова С.С (это как пример)
Столбец 8: подпись Сидоровой С.С. в получении (можно без подписи, если передавалось от администратора бухгалтеру по акту)

Если администратор делает копии для директора и резервную для себя, то снова вносит отметки в журнал заполняя столбцы 1,2,3,4,5,6,7,8, но только в столбце 4 указывает номер экземпляра(соответственно 1,2,3,).
на этом заполнение Журнал учета ключей ОКИ (обладателя ключевой информации) заканчивается.

Если например зам бухгалтера увольняется, то он сдает КД (УКЭП на имя директора на носителе JaCarta) администратору безопасности, админ удаляет с носителя КИ (УКЭП на имя директора) вносит данные об этом в Журнал учета ключей ОКИ (обладателя ключевой информации) столбцы 12,13,14, ну или все это делает по акту.
Или может передает КД (УКЭП на имя директора на носителе JaCarta) другому сотруднику по акту передачи ключевых документов и опять же делает отметку в Журнале учета ключей ОКИ (обладателя ключевой информации).(новой строкой заполняя все столбцы с 1 по 8 и указывая в столбце 7 и 8 нового сотрудника). А в старой строке делает отметку в столбце комментарий, что передано по Акту, с сылкой на новый номер записи по Журналу учета ключей ОКИ (обладателя ключевой информации).


Т.е подвожу итог:
Орган крипо защиты не может знать, как КД будет двигаться после передачи их в другую организацию и естественно не может отразить в Журнале учета ключей ОКЗ (органа криптозащиты) движение внутри другой фирмы, для этого и нужен Журнал для ОКИ.

Единственно, что может еще сделать УЦ "Криптон" и отразить в Журнале учета ключей ОКЗ (органа криптозащиты) это:
1. вывести КИ из эксплуатации (ну к примеру аннулировать сертификат или удалить его из АИС "Молния" по заявлению Иванова П.П. в случае компрометации его УКЭП ) и отразить это в Журнале учета ключей ОКЗ (органа криптозащиты) .
2.получить УКЭП обратно, тоже с отметками в Журнале учета ключей ОКЗ
3. Если получает обратно, то может еще и уничтожить УКЭП и опять же с пометками в Журнале учета ключей ОКЗ.

Получается, что сейчас в менеджере безопасности Журнал учета ключей ОКИ (обладателя ключевой информации)-это просто журнал учета ключевой информации для органа крипто защиты с информацией в какой АИС она функционирует. Хотя вся эта информация есть и в Журнале учета ключей ОКЗ (органа криптозащиты) за исключение информации о АИС. Так получается???


Вдруг если показался груб, простите.
Я не критикую, мне очень нравиться Ваше решение.

Забыл, дать ссылки на ФАПСИ 152
пункт 27 Все полученные обладателем конфиденциальной информации экземпляры СКЗИ, эксплуатационной и технической документации к ним, ключевых документов должны быть выданы под расписку в соответствующем журнале поэкземплярного учета пользователям СКЗИ, несущим персональную ответственность за их сохранность.

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

Вы говорите:
Проблема с журналами заключается в том, что они придумывались почти 20 лет назад (в 2001 году принят приказ ФАПСИ 152). В те времена было просто, один ключ, один носитель, одна система....

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

Еще вопрос:
Привожу пример
1. формирую ключевую информацию называю тест_1
2. формирую ключевую информацию называю тест_2
3. Записываю тест_1 и тест_2 на ключевой носитель Носитель_1
4. передаю ключевую информацию тест_1 Иванову И.И.
5. передаю ключевую информацию тест_2 Петрову П.П.
6. Ввожу тест_1 и тест_2 в эксплуатацию
Всё проводки прошли всё хорошо

Делаю отчет: Журнал учета КД для ОКЗ и там вижу, что один ключевой носитель одновременно у двух человек находится.

Это тоже фича???

Еще вопрос:
Привожу пример
1. формирую ключевую информацию называю тест_1
2. формирую ключевую информацию называю тест_2
3. Записываю тест_1 и тест_2 на ключевой носитель Носитель_1
4. передаю ключевую информацию тест_1 Иванову И.И.
5. передаю ключевую информацию тест_2 Петрову П.П.
6. Ввожу тест_1 и тест_2 в эксплуатацию
Всё проводки прошли всё хорошо
Делаю отчет: Журнал учета КД для ОКЗ и там вижу, что один ключевой носитель одновременно у двух человек находится.
Это тоже фича???

Посмотрите отчет внимательно, у двух ответственных лиц находятся два ключевых документа, а не два ключевых носителя, это совершенно разные вещи.

Проблема в том, что определение ключевого документа в ФАПСИ 152 и Постановления Правительства 313 существенно отличаются. В ФАПСИ 152 КД - это НОСИТЕЛЬ, содержащий ключевую информацию, в ПП-313 - это КЛЮЧЕВАЯ ИНФОРМАЦИЯ, хранящаяся на носителе.

Другими словами по ПП-313 КД - это файл, записанный на флэшке, а по ФАПСИ 152 это флэшка, содержащая файл. С точки зрения российского законодательства Постановление Правительства имеет больший приоритет, нежели нормативно методический документ федерального органа исполнительной власти (ФАПСИ / ФСБ), поэтому выбрано именно оно.

Кроме всего прочего определение из ПП-313 лучше описывает современную действительность. Так по определению из ФАПСИ 152 нельзя описать передачу ключевого документа, при которой криптографические ключи хранятся в централизованном корпоративном хранилище, например в HSM (например, КриптоПРО DSS) или облачных ключевых провайдерах, по факту ведь HSM не передается из рук в руки, а аппаратуру облачного провайдера вообще невозможно передать.

Другими словами по ПП-313 КД - это файл, записанный на флэшке, а по ФАПСИ 152 это флэшка, содержащая файл. С точки зрения российского законодательства Постановление Правительства имеет больший приоритет, нежели нормативно методический документ федерального органа исполнительной власти (ФАПСИ / ФСБ), поэтому выбрано именно оно.

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

А тут получается что JaCarta с серийным номером 123456, находиться у двух человек одновременно. Такого быть не может

А как описать передачу передачу ключевого документа при которой криптографические ключи хранятся в централизованном корпоративном хранилище, например в HSM (например, КриптоПРО DSS) или облачных ключевых провайдерах, по факту ведь HSM не передается из рук в руки, а аппаратуру облачного провайдера вообще невозможно передать по ПП-313.

В ПП-313 вообще нет описание, как что передавать