imbasoft.ru

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

Это действительно сложно идентифицируемое событие, над которым мы с коллегами довольно долго спорили. Итоги наших рассуждений нашли свое отражение в п. 5.6.2 Методологии учета, приведу выдержку из него:
"Событие ввода в эксплуатацию ключевой информации возникает в момент, когда ключевая информация может использоваться в информационной системе (сервисе или бизнес-процессе) по назначению."

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

Добрый день. Заинтересовал ваш продукт Менеджмент безопасности 2.0, уже установил и начал наполнять базу. Столкнулся со следующей задачей: при увольнении сотрудник должен сдать носитель ключевой информации. Акт вывода и уничтожения ключевой информации сформированы, в Журнале ФАПСИ данные учтены, но куда вписать информацию о том что носитель изъят? Если написать в поле "Комментарий", то в Журнале ФАПСИ информация с этого поля не отображается, наверное, нужно предусмотреть поле "Примечание" в акте уничтожения ключей. Прошу прояснить данный вопрос.

при увольнении сотрудник должен сдать носитель ключевой информации

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

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

То есть по ПП-313 ключевой документ это в первую очередь ФАЙЛ, а затем носитель.
Приказ ФАПСИ 152 дает обратное определение, в котором ключевой документ это в первую очередь носитель. При разработке системы было принято решение строить идеологию отталкиваясь от определения данного в ПП-313. При этом руководствовались следующими соображениями. Во-первых ПП-313 с юридической точки зрения имеет больший вес и выпущено оно позже. Во-вторых, определение предоставляемое ПП-313 больше подходит к современным реалям, включающие такие явления как "облачные токены", HSM и все то, что было внедрено в криптографии после 2001 года.

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

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

Здравствуйте, прочитав статью о Вашей системе, сделал вывод, что она работает только в системе 1С Предприятие.
В нашей организации используется ИСУ "Парус".
Вопрос:
- Каким образом разработанную Вами Систему "Менеджмент безопасности" интегрировать в ИСУ Парус?

Добрый день.
Данная система работает только в среде 1С:Предприятие, интеграция с ИСУ Парус не предусмотрена.

imbasoft писал(а): ↑20 сен 2016, 12:20

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

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

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

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

Сертификат директора состоит из КИ двух типов: открытого и закрытого ключей. Если у вас есть прямой ЭДО с контрагентами, в рамках которого вы отправляете открытый ключ (сертификат) другой стороне для проверки полномочий, то необходимо регистрировать как открытый, так и закрытый ключ. Далее, для простоты, будем считать, что у вас УКЭП Директора, для сдачи отчетности, при которой вы только подписываете документы. В таком случае можно учитывать только закрытый ключ.

Типовая схема учета будет выглядеть следующим образом.
При создании УКЭП - формируете Акт Создания КД. Ответственное лицо: Адм. безопасности, КИ - УКЭП Директора, носитель - токен.
Будем считать, что при использовании УКЭП в других ИС вы делаете копию УКЭП, скажем на диск виртуальной машины, где настроен робот для автоматической подписи документов. В таком случае оформляются следующие документы:
1. Акт создания КД - КИ: УКЭП, Носитель - диск вирт. машины, Отв. - Адм. безопасности.
2. Акт передачи КИ - КИ: УКЭП, Носитель - диск вирт. машины, Передающий - Адм. безопасности. Принимающий - ответственный за работу виртуальной машины.
3. Акт ввода КИ в эксплуатацию: КИ - УКЭП, Ответственный: ответственный за работу виртуальной машины, Информационная система - ваша ИС.

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

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

Системе учета все равно, руководствуйтесь законодательством, соглашением об ЭДО, правилами безопасности СКЗИ.

Спасибо за ответ!
Еще один нюанс хотел прояснить для себя. Кто должен вводить в эксплуатацию КД? Админ безопасности или же отв.человек, к примеру на которого выдан сертификат и он будет работать в ИС по своему назначению?

Кто должен вводить в эксплуатацию КД? Админ безопасности или же отв.человек, к примеру на которого выдан сертификат и он будет работать в ИС по своему назначению?

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