imbasoft.ru

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

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

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

Организации-лицензиаты ФСБ России по криптографии, а также "Госики" должны, как минимум, соответствовать следующим документам:
1. Приказ ФАПСИ 152
2. ПКЗ 2005
3. (Только лицензиаты) ПП 313.

В этих документах указаны различные определения СКЗИ. В частности по ФАПСИ 152 КД не относится к СКЗИ, а в ПП 313 и ПКЗ-2005 относятся.

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

Журналы ФАПСИ 152 описывает слишком примитивный жизненный цикл ключевой информации / ключевых документов.
Так Журнал учета КД для ОКЗ описывает ситуацию, когда КД сначала формируется (столбцы 5,6), затем КД передается (столбцы 5-9), затем он возвращается (10,11) и уничтожается (столбцы 14, 15). Все вроде бы здорово, но как быть если один и тоже ключевой документ эксплуатируется несколькими лицами по очереди? Например, КЭП сформирован на токене с неизвлекаемым ключом, этим токеном пользуется сначала один работник, потом он увольняется и им пользуется другой работник? Перегенерация в данном случае не требуется, поскольку лицо эксплуатирующее ключевую информацию не может ее скомпрометировать.

Журнал учета КД для ОКИ описывает жизненный цикл, при котором ключи сначала получаются (столбцы 5, 6), от ОКЗ, затем выдаются ответственному лицу (столбцы 7,8), затем устанавливаются / вводятся в эксплуатацию (стоблцы 9-11), и выводятся из эксплуатации (столбцы 12-14). Опять таки это слишком примитивный жизненный цикл, который не может описать все современные варианты использования СКЗИ. Например, когда одна и таже ключевая информация используется для различных информационных систем. Пример, КД, содержащий КЭП директора используется для сдачи отчетности в налоговую, затем в для участия в электронных торгах, а затем в электронном документообороте с контрагентами.

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

После это возник выбор либо вести имитацию учета в строгом соответствии с ФАПСИ 152, либо минимальным образом адаптировать методику, но вести честный учет.

Был выбран второй путь.

Поскольку методик ведения журнала в ФАПСИ 152 не прописано. Было принято решение, что учет движения КД будет вестись в журнале ОКЗ, а учет эксплуатации КИ будет вестись в журнале учета ОКИ.

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

Потому что передается не JaCarta, а файлы на ней.

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

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

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

Ещё вопрос.
Почему не заполняются столбцы 7,8 в журнале учета СКЗИ для ОКИ???
Пример:
1.Оформляю АКТ поступления СКЗИ
2.Делаю АКТ передачи СКЗИ
3.Акт ввода в эксплуатацию СКЗИ
проверяю журнал для ОКЗ там столбцы 7,8 заполнены(написано что-то передано тому-то, тому-то)
а в журнале ОКИ столбцы 7,8 пусто.

После уничтожения ключевой информации в Журнал для ОКИ в столбец №13("Ф.И.О. сотрудников производивших изъятие(уничтожение)") выводиться информация о владельце КД, а не о сотруднике который уничтожал.

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

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

После уничтожения ключевой информации в Журнал для ОКИ в столбец №13("Ф.И.О. сотрудников производивших изъятие(уничтожение)") выводиться информация о владельце КД, а не о сотруднике который уничтожал.

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

Ещё вопрос.
Почему не заполняются столбцы 7,8 в журнале учета СКЗИ для ОКИ???
Пример:
1.Оформляю АКТ поступления СКЗИ
2.Делаю АКТ передачи СКЗИ
3.Акт ввода в эксплуатацию СКЗИ
проверяю журнал для ОКЗ там столбцы 7,8 заполнены(написано что-то передано тому-то, тому-то)
а в журнале ОКИ столбцы 7,8 пусто.

Тут таже ситуация что и с КД и КИ. Журнал СКЗИ ОКЗ - показывает жизненный цикл "перемещения" СКЗИ, то есть поступление, передачу, списание.
Журнал СКЗИ ОКИ - показывает жизненный цикл СКЗИ в части эксплуатации.

Хочу еще дать отдельный комментарий, касательно Журналов КД/СКЗИ для ОКИ и ОКЗ.

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

Но с точки зрения реальной жизни ситуация сложнее. Из всего всего множества криптоключей, с которыми работает банк часть он выпускает (генерирует / сертифицирует) сам, например, ключи для клиентов - пользователей системы дистанционного банковского обслуживания Интернет Клиент-банк (ДБО ИКБ). Другую часть ключей банк получает от сторонних организаций: казначейства, ЦБ, банков-партнеров, платежных систем и т.д.

Сразу возникает вопрос какие журналы должен вести банк?

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

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

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

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

ОКЗ, с точки зрения практики - это в первую очередь распределение ключей/СКЗИ, а ОКИ - это эксплуатация. Учитывая то, что современные лицензиаты ФСБ это и ОКИ и ОКЗ в одном флаконе было принято решение сделать журналы ОКЗ, учитывающими жизненный цикл ключей/СКЗИ с точки зрения распределения, а журналы ОКИ с точки зрения эксплуатации.

Данный подход показал свою состоятельность, как при проверках со стороны регуляторов, так и при проведении внутренних расследований.