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

[imbasoft]

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

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

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

[Vasiliy_Chapaev]

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

[imbasoft]

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

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

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

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

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

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

[KoTul]

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

[imbasoft]

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

[mikhail-lob]

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

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

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

[imbasoft]

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

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

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

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

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

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

[mikhail-lob]

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

[imbasoft]

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

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