Доброго дня, уважаемые пользователи системы "Менеджмент безопасности". В этой теме вы можете написать свои пожелания по улучшению системы. Лучшие идеи будут реализованы и включены в следующие релизы системы.
Запросы принятые в работу:
1. [Реализовано в версии 2.1] Исправить баг, приводящий к дублированию данных в отчете "Журнал учета СКЗИ (ФАПСИ 152)". Баг проявляется, если экземпляр СКЗИ был уничтожен по акту.
2. [Реализовано в версии 2.1] Реализовать отчет - Журнал ФАПСИ 152 для обладателей конфиденциальной информации.
3. Реализовать учет нескольких сертификатов на одно СКЗИ.
4. Реализовать учет ограниченных по времени лицензий на СКЗИ.
5. Реализовать учет для случаев когда одно и тоже физ. лицо работает в нескольких организациях или в одной на разных должностях.
6. Реализовать учет СЗИ по аналогии с СКЗИ
7. Реализовать визард, позволяющий создавать несколько документов по общим данным.
Менеджмент безопасности - список пожеланий и доработок (wishlist)
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Доброго времени суток.
Так сложилось, что меня «заставили захотеть» организовать работу органа криптозащиты в рамках работы удостоверяющего центра.
Полистал инструкцию ФАПСИ 152, попробовал завести журналы в бумажном виде. Понял, что автоматизации аналитики никакой нет и не предвидится в рамках бумаги, и пришла мысль немного все автоматизировать. В свое время не интересовался ни «Access», ни «Exel», ни тем более с «1С», но немного пообщался в такой программой как «Cronos Plus». Программа тоже платная, как и «1С», но её точно не купят под мои фантазии, а вот отжать одну лицензию на «1С» у бухгалтерии вполне реально. Поэтому принято решение попробовать организовать работу ОКЗ на основе вашего продукта.
Создал новую базу и для понимания как это будет выглядеть в реальности стал «учитывать» то, что по факту сейчас используется в организации (до того как мы начнем работу как удостоверяющий центр).
Очень понравился реализованный подход учета «по дейстиям», а не «по объектам», но к нему есть несколько вопросов, возможно потому, что я что –то недопонял в методологии учета или потому, что реальность зачастую расходится с теорией.
I. Вопрос первый возник, когда я понял, что для работы нам нужно вести не только журнал ОКЗ, но и журнал ОКИ. В программе по факту ведется учет сведений необходимых для заполнения ОКИ, но в итоговую форму «Журнала учета СКЗИ (ФАПСИ 152)» эта информация попадает в усеченном виде, так как он для ОКЗ. Предложение вытекающее из этого: вероятно стоит ввести форму «Жунала учета СКЗИ (ФАПСИ 152) для ОКИ» как раз для отражения движения СКЗИ внутри организации являющейся лицензиатом и одновременно ОКИ (для проверяющих).
II. Исходя из инструкции ФАПСИ 152, учет СКЗИ установленных на АРМ производится в составе этих АРМ, то есть в бумажном журнале ОКИ у меня четыре записи:
1. «СКЗИ ХХХ эталонный дистрибутив YYYY (инв.№00001) //получено тогда-то от того-то // выдано тому-то».
2. «СКЗИ ХХХ Формуляр эталонного дистрибутива YYYY (инв.№00001) // получено тогда-то от того-то // выдано тому-то».
3. «Лицензия на право использования СКЗИ ХХХ №666 от и до // полученная тогда-то от того-то // установлено тогда-то тем –то (примечание АРМ ZZZ)».
4. «СКЗИ ХХХ на АРМ ZZZ (инв.№00002) c эталонного дистрибутива YYYY (строка журнала №1) // выдано тому-то // установлено тогда-то тем -то».
В продукте же реализован учет по действиям и есть шесть записей:
1.СКЗИ XXX Дистрибутив YYYY (инв.№00001)
2.СКЗИ XXX Формуляр дистрибутива YYYY (инв.№00001)
3.Лицензия на право использования СКЗИ ХХХ №666
4.АРМ ZZZ
5.Акт поступления СКЗИ и лицензии
6.Акт передачи СКЗИ , формуляра и лицензии
7.Акт ввода в эксплуатацию СКЗИ на АРМ ZZZ
8.Акт ввода в эксплуатацию Лицензии на АРМ ZZZ
Предложение в целях экономии сил и бумаги реализовать возможность создания актов ввода(вывода) в эксплуатацию, как и Актов передачи по несколько штук, так как зачастую ставится (и удаляется) комплект, например: Континент-АП, Крипто-Про CSP и две Лицензии на эти СКЗИ?
_________________
III. Третий вопрос еще сложнее и вытекает из второго: казначейство выдает два дистрибутива СКЗИ с разными классами (КС1 и КС2) с разными рег.номерами на одном оптическом диске, 4 лицензии на право использования на одном бумажном листе и два формуляра. Провести учет СКЗИ в такой ситуации (для прозрачности) целесообразнее как два дистрибутива (две записи) или как один носитель (одна запись)? По факту устанавливается СКЗИ на четыре АРМ только с дистрибутива КС1. Четыре лицензии я могу записать каждую в отдельную строку с указанием в примечании, что все они на одном носителе. Но создать акт ввода в эксплуатацию с дистрибутива КС1 на второй, третий и четвертый АРМ я не могу, программа выдает ошибку «данный СКЗИ уже введен в эксплуатацию на другом объекте». В текущей реализации приходится создавать новый экземпляр СКЗИ с текстом «СКЗИ XXX Экземпляр SSSS установленный с эталонного дистрибутива YYYY (инв.№00001)», по логике инструкции ФАПСИ 152 все правильно, но для того, чтобы этот экземпляр ввести в эксплуатацию, программа требует сначала создать «акт поступления СКЗИ» (он ко мне не поступает, я его инсталлирую с эталона как и при установке на первый АРМ).
Предложение в том, что если учет происходит по действиям, то вполне возможно сделать учет для программных СКЗИ с возможностью множественной установки и отражением этого в форме «Журнале учета СКЗИ (ФАПСИ 152)».
______________________
IV. Я понимаю, что заполнение формы журнала учета СКЗИ по 152 ФАПСИ не главная задача продукта, но все же для обоснования соответствия организованного учета требованиям инструкции ФАПСИ 152 его необходимо если не распечатать , хотя бы то продемонстрировать регулятору при проверке.
Так вот первое, что мне непонятно в форме вывода, это то, что нет фиксации записей, то есть если вчера я выводил этот журнал на печать, а сегодня добавил несколько новых СКЗИ разных типов, то при печати журнала сегодня, эти СКЗИ запросто могут оказаться не последними по списку, а отнесенными к группам ранее вводимых СКЗИ, что соответственно изменяет нумерацию записей в журнале, если вчера экземпляр был 33, а сегодня он стал 38. Вопрос состоит в том, какой номер поставить в отметке о взятии на учет непосредственно на физическом экземпляре дистрибутива или документации? Логически получается, что это код из таблицы «Экземпляры СКЗИ», но он не отражается в выводимой форме «Журнала учета СКЗИ (ФАПСИ 152)». А предложение ввести жесткую привязку нумерации позиций выводимых в этом журнале.
_________________________
V. Предложение перекликается с III. ввести для таблицы «Модели СКЗИ» дополнительное поле маркирующее его как ПО, железо, лицензию.
VI. Предложение перекликается с II. И V. ввести для экземпляров СКЗИ промаркированных как «Лицензия» возможность вводить даты начала/окончания.
VII. На главной странице или в форме всплывающего уведомления при запуске проекта выводить уведомление о требующих участия внимания фактах как свершившихся, так и перспективных (неделя, месяц), таких как: окончание лицензии на право использования, окончание сертификата на СКЗИ, окончание действия ключей.
Все уведомления сделать не только отключаемыми(галочкой) но и возможностью комментария и/или прикрепления ссылки на документ по решению вопроса. Соответственно возможность организовать просмотра этих уведомлений и принятых решений в отдельном отчете.
VIII. У некоторых типов СКЗИ имеется несколько сертификатов соответствия, предлагаю включить возможность добавления больше одного сертификата, а так же поля с примечанием, чего именно касается этот сертификат.
IX. Понравилась организация вывода в «Журнал учета СКЗИ (ФАПСИ 152)» по подпунктам, даже не догадывался, что так можно, но непонятно зачем в этих подпунктах дублируется одна и та же информация по актам.
Предложение заключается в том, что бы помощью такой реализации сделать учет не только движение посредством актов, но и учет СКЗИ и документации к нему, как бы в составе комплекта, Например:
1.СКЗИ XXX Дистрибутив YYYY на CD (инв.№00001)
1.1.СКЗИ XXX Формуляр дистрибутива YYYY(ФСБ )
1.2.СКЗИ XXX Формуляр дистрибутива YYYY (ФСТЭК)
1.3.СКЗИ XXX Паспорт дистрибутива YYYY
1.4.СКЗИ XXX Эксплуатационная документация дистрибутива YYYY на CD
2.Лицензия на право использования СКЗИ ХХХ №666
Это так на первый взгляд, то чего мне не хватило в программе.
С со следующего месяца УЦ начинает свою работу, наверное буду пока вести учет комбинированно на бумаге и в Exel. Поизучаю Access, может, что-то сам напишу, конечно не такое всеобъемлющее как у вас, но на безрыбие ….
PS Извиняюсь за сумбурность мыслей, получился некий «салат» из вопросов и предложений, а не только предложения.
Так сложилось, что меня «заставили захотеть» организовать работу органа криптозащиты в рамках работы удостоверяющего центра.
Полистал инструкцию ФАПСИ 152, попробовал завести журналы в бумажном виде. Понял, что автоматизации аналитики никакой нет и не предвидится в рамках бумаги, и пришла мысль немного все автоматизировать. В свое время не интересовался ни «Access», ни «Exel», ни тем более с «1С», но немного пообщался в такой программой как «Cronos Plus». Программа тоже платная, как и «1С», но её точно не купят под мои фантазии, а вот отжать одну лицензию на «1С» у бухгалтерии вполне реально. Поэтому принято решение попробовать организовать работу ОКЗ на основе вашего продукта.
Создал новую базу и для понимания как это будет выглядеть в реальности стал «учитывать» то, что по факту сейчас используется в организации (до того как мы начнем работу как удостоверяющий центр).
Очень понравился реализованный подход учета «по дейстиям», а не «по объектам», но к нему есть несколько вопросов, возможно потому, что я что –то недопонял в методологии учета или потому, что реальность зачастую расходится с теорией.
I. Вопрос первый возник, когда я понял, что для работы нам нужно вести не только журнал ОКЗ, но и журнал ОКИ. В программе по факту ведется учет сведений необходимых для заполнения ОКИ, но в итоговую форму «Журнала учета СКЗИ (ФАПСИ 152)» эта информация попадает в усеченном виде, так как он для ОКЗ. Предложение вытекающее из этого: вероятно стоит ввести форму «Жунала учета СКЗИ (ФАПСИ 152) для ОКИ» как раз для отражения движения СКЗИ внутри организации являющейся лицензиатом и одновременно ОКИ (для проверяющих).
II. Исходя из инструкции ФАПСИ 152, учет СКЗИ установленных на АРМ производится в составе этих АРМ, то есть в бумажном журнале ОКИ у меня четыре записи:
1. «СКЗИ ХХХ эталонный дистрибутив YYYY (инв.№00001) //получено тогда-то от того-то // выдано тому-то».
2. «СКЗИ ХХХ Формуляр эталонного дистрибутива YYYY (инв.№00001) // получено тогда-то от того-то // выдано тому-то».
3. «Лицензия на право использования СКЗИ ХХХ №666 от и до // полученная тогда-то от того-то // установлено тогда-то тем –то (примечание АРМ ZZZ)».
4. «СКЗИ ХХХ на АРМ ZZZ (инв.№00002) c эталонного дистрибутива YYYY (строка журнала №1) // выдано тому-то // установлено тогда-то тем -то».
В продукте же реализован учет по действиям и есть шесть записей:
1.СКЗИ XXX Дистрибутив YYYY (инв.№00001)
2.СКЗИ XXX Формуляр дистрибутива YYYY (инв.№00001)
3.Лицензия на право использования СКЗИ ХХХ №666
4.АРМ ZZZ
5.Акт поступления СКЗИ и лицензии
6.Акт передачи СКЗИ , формуляра и лицензии
7.Акт ввода в эксплуатацию СКЗИ на АРМ ZZZ
8.Акт ввода в эксплуатацию Лицензии на АРМ ZZZ
Предложение в целях экономии сил и бумаги реализовать возможность создания актов ввода(вывода) в эксплуатацию, как и Актов передачи по несколько штук, так как зачастую ставится (и удаляется) комплект, например: Континент-АП, Крипто-Про CSP и две Лицензии на эти СКЗИ?
_________________
III. Третий вопрос еще сложнее и вытекает из второго: казначейство выдает два дистрибутива СКЗИ с разными классами (КС1 и КС2) с разными рег.номерами на одном оптическом диске, 4 лицензии на право использования на одном бумажном листе и два формуляра. Провести учет СКЗИ в такой ситуации (для прозрачности) целесообразнее как два дистрибутива (две записи) или как один носитель (одна запись)? По факту устанавливается СКЗИ на четыре АРМ только с дистрибутива КС1. Четыре лицензии я могу записать каждую в отдельную строку с указанием в примечании, что все они на одном носителе. Но создать акт ввода в эксплуатацию с дистрибутива КС1 на второй, третий и четвертый АРМ я не могу, программа выдает ошибку «данный СКЗИ уже введен в эксплуатацию на другом объекте». В текущей реализации приходится создавать новый экземпляр СКЗИ с текстом «СКЗИ XXX Экземпляр SSSS установленный с эталонного дистрибутива YYYY (инв.№00001)», по логике инструкции ФАПСИ 152 все правильно, но для того, чтобы этот экземпляр ввести в эксплуатацию, программа требует сначала создать «акт поступления СКЗИ» (он ко мне не поступает, я его инсталлирую с эталона как и при установке на первый АРМ).
Предложение в том, что если учет происходит по действиям, то вполне возможно сделать учет для программных СКЗИ с возможностью множественной установки и отражением этого в форме «Журнале учета СКЗИ (ФАПСИ 152)».
______________________
IV. Я понимаю, что заполнение формы журнала учета СКЗИ по 152 ФАПСИ не главная задача продукта, но все же для обоснования соответствия организованного учета требованиям инструкции ФАПСИ 152 его необходимо если не распечатать , хотя бы то продемонстрировать регулятору при проверке.
Так вот первое, что мне непонятно в форме вывода, это то, что нет фиксации записей, то есть если вчера я выводил этот журнал на печать, а сегодня добавил несколько новых СКЗИ разных типов, то при печати журнала сегодня, эти СКЗИ запросто могут оказаться не последними по списку, а отнесенными к группам ранее вводимых СКЗИ, что соответственно изменяет нумерацию записей в журнале, если вчера экземпляр был 33, а сегодня он стал 38. Вопрос состоит в том, какой номер поставить в отметке о взятии на учет непосредственно на физическом экземпляре дистрибутива или документации? Логически получается, что это код из таблицы «Экземпляры СКЗИ», но он не отражается в выводимой форме «Журнала учета СКЗИ (ФАПСИ 152)». А предложение ввести жесткую привязку нумерации позиций выводимых в этом журнале.
_________________________
V. Предложение перекликается с III. ввести для таблицы «Модели СКЗИ» дополнительное поле маркирующее его как ПО, железо, лицензию.
VI. Предложение перекликается с II. И V. ввести для экземпляров СКЗИ промаркированных как «Лицензия» возможность вводить даты начала/окончания.
VII. На главной странице или в форме всплывающего уведомления при запуске проекта выводить уведомление о требующих участия внимания фактах как свершившихся, так и перспективных (неделя, месяц), таких как: окончание лицензии на право использования, окончание сертификата на СКЗИ, окончание действия ключей.
Все уведомления сделать не только отключаемыми(галочкой) но и возможностью комментария и/или прикрепления ссылки на документ по решению вопроса. Соответственно возможность организовать просмотра этих уведомлений и принятых решений в отдельном отчете.
VIII. У некоторых типов СКЗИ имеется несколько сертификатов соответствия, предлагаю включить возможность добавления больше одного сертификата, а так же поля с примечанием, чего именно касается этот сертификат.
IX. Понравилась организация вывода в «Журнал учета СКЗИ (ФАПСИ 152)» по подпунктам, даже не догадывался, что так можно, но непонятно зачем в этих подпунктах дублируется одна и та же информация по актам.
Предложение заключается в том, что бы помощью такой реализации сделать учет не только движение посредством актов, но и учет СКЗИ и документации к нему, как бы в составе комплекта, Например:
1.СКЗИ XXX Дистрибутив YYYY на CD (инв.№00001)
1.1.СКЗИ XXX Формуляр дистрибутива YYYY(ФСБ )
1.2.СКЗИ XXX Формуляр дистрибутива YYYY (ФСТЭК)
1.3.СКЗИ XXX Паспорт дистрибутива YYYY
1.4.СКЗИ XXX Эксплуатационная документация дистрибутива YYYY на CD
2.Лицензия на право использования СКЗИ ХХХ №666
Это так на первый взгляд, то чего мне не хватило в программе.
С со следующего месяца УЦ начинает свою работу, наверное буду пока вести учет комбинированно на бумаге и в Exel. Поизучаю Access, может, что-то сам напишу, конечно не такое всеобъемлющее как у вас, но на безрыбие ….
PS Извиняюсь за сумбурность мыслей, получился некий «салат» из вопросов и предложений, а не только предложения.
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Идей много - аж 9 штук, это здорово.
Хочу начать с небольшого вступления, касательно стратегии учета и ФАПСИ 152.
ФАПСИ 152 - очень старый документ, ему больше 16 лет, за это время многое поменялось. Сама методика, описанная в ФАПСИ 152 идеально ложиться только на случаи, когда пользователи применяют ключи на отчуждаемых носителях, если используются не отчуждаемые носители ключей, например, ключи на жестких дисках серверов (SSL сертификаты), методика начинает "плыть", так как по ФАПСИ 152 ключевой документ это в первую очередь носитель, а потом уже записанная информация, соответственно для передачи подобного ключа нужно будет передавать винчестер, а если на нем уже есть другие ключи ? Логический коллапс.
Другим примером устаревания ФАПСИ 152 является необходимость росписи в журналах, но если вы работаете в филиальной структуре и скажем в удаленном филиале админ установил СКЗИ на компьютер, то вам нужно отправлять в удаленный филиал весь журнал учета СКЗИ для получения его росписи. Это особенно забавно выглядит если расстояние между офисами тысячи километров.
Подобных примеров можно привести большое количество. Я лично организовывал работу органа критозащиты и могу на своем опыте сказать, что на 100% реально работать по ФАПСИ 152 невозможно.
Но в то же время, этот документ является обязательным к применению для лицензиатов. Поэтому ему необходимо следовать там, где это возможно. Кстати говоря, сама ФСБ знает об устаревании документа и относится с пониманием к несоблюдению некоторых его требований - например, никто сейчас письменно не уведомляет ФСБ о создании органа криптозащиты и в тоже время это за это не наказывают. Более того, выполняя функцию администратора СКЗИ я получал большое количество ключей, но не один УЦ не заставлял подписывать в журнале учета (как того предписывает ФАПСИ 152), всем всегда хватает подписи в актах передачи. В тоже время некоторые подобные УЦ публикуют на сайте положительные заключения проверок ФСБ.
Поэтому идеологически программа строилась из необходимости организации реального учета в области СКЗИ, причем как отечественной, так и импортной криптографии с максимальным соответствием подобного учета методике ФАПСИ 152. И я считаю что это сделать удалось, поскольку к некоторым пользователям системы приходили проверки со стороны регулятора и претензий на подобную схему организации учета не поступало.
Идеология учета с помощью системы включает в себя два основных информационных ресурса:
1. Картотека подписанных бумажных первичных документов (актов);
2. Компьютерная база данных - непосредственно сама система "Менеджмент безопасности".
Картотека документов, содержит все необходимые сведения, указанные в ФАПСИ 152 и по сути является исчерпывающим ресурсом для проверяющих.
Для ответа на классический вопрос любой проверки - "Покажите журнал учета СКЗИ" в базе данных созданы отчеты, одним из которых является "Журнал учета СКЗИ (ФАПСИ 152)". Если все правильно ведется, то данный отчет будет являться "оглавлением" для картотеки документов. Корректность журнала, достигается путем распечатки и подписи каждого листа, перед передачей проверяющим. Журнал не предназначен для заполнения в ручную или фиксации в нем каких-либо данных это всего лишь отчет. Поэтому по большому счету нет никакой разницы в каком порядке там выводятся строки. Более того, если вы сдаете СКЗИ в аренду с последующим возвратом, то количество строк в журнале будет меняться. Новые строки могут добавляться в середину журнала, поэтому привязка СКЗИ к позиции в журнале практического смысла не имеет.
Компьютерная база данных - предназначена для практической ежедневной работы. Если вы опасаетесь вести учет в электронном виде то можете ее не показывать. Хотя из личных не официальных комментариев представителей регулятора, можно утверждать что, вести учет в электронном виде не является нарушением.
Разбор идей
Идея 1. Создание отчета - Журнал учета СКЗИ по форме, рекомендованной для обладателей конфиденциальной информации (ОКИ).
Сделать его конечно можно, но нужно ли? Дело в том, что для реальной работы подобное представление информации не удобно, а некоторые вопросы, например перенос одного СКЗИ на другой комп в нем вообще невозможно отразить. Если делать только как отчет для регуляторов, то пользователи могут запутаться какой журнал для чего нужен.
Результат рассмотрения идеи - сомнительная необходимость доработки.
Идея 2 и 3.
Организацию учета, которую вы привели в примерах можно существенно организационно упростить. Например, если вы реально будете передавать эталонный носитель админам для установки СКЗИ, то в один прекрасный момент, они его потеряют или он перестанет работать (проверено жизнью).
Поэтому рекомендуется организовать установку СКЗИ из сетевого репозитория, где будут лежать дистрибутивы СКЗИ и необходимая документация, защиту репозитория можно сделать с помощью хэшей и разграничения доступа по принципу - админ. СКЗИ полный дотуп, ИТ-работники - только чтение, это сразу избавит вас от двух актов - выдачи эталонного дистрибутива и возврата дистрибутива. В тоже время все законно.
С точки зрения учета, я бы рекомендовал на СКЗИ делать две записи
1. Само СКЗИ (для программных считай лицензия).
2. Эталонный дистрибутив и документация (включая формуляр).
Первое вы передаете актами. Второе однажды принимается и лежит в Органе криптозащиты. Подобный подход сэкономит еще порядочное число актов.
Касательно пример по казначейству. Я бы рекомендовал действовать следующим образом - эталонный носитель учитывается единожды и отмечается, что на нем хранится 2 дистрибутива СКЗИ. Получили его, скинули на репозиторий и прячем в сейф.
Лицензии на бумажном носителе - учитываем как 4 экземпляра СКЗИ. Учитывать саму бумажку отдельно большого смысла не имеет, можно включить ее в состав документации на СКЗИ.
Формуляры - 2 шт... это конечно неправильно. У вас 4 СКЗИ и должно быть 4 формуляра. Формуляр, это бумажка, по типу ПТС на автомобиль, нельзя давать один ПТС на два автомобиля. Но в последнее время на рынке правильной работы с формулярами на рынке правильной работе с формулярами нет нигде. Встречаются случаи когда один формуляр дают на десяток СКЗИ, а в нем вообще-то, должны быть указаны регистрационные номера СКЗИ, полученные разработчиком от ФСБ, а также персональная история каждого СКЗИ, кто ставил, куда ставил и т.д. На такие случаи в системе предусмотрена возможность генерации "электронного формуляра" - отчет "Справка об экземпляре СКЗИ". Формуляры учитываем в составе документации. Итого, получаем следующие записи:
- 1 запись - "Эталонный носитель и документация на СКЗИ"
- 4 записи - "Лицензионные номера СКЗИ"
Хочу также отметить, что КС2 подразумевает использование ПАК СЗИ НСД - "Аккорд" или "Соболь", казначейство вам их дало? (риторический вопрос)
Результат рассмотрения идеи - описанные примеры существенно упрощаются при оптимизации ведения учета. Касательно разработки средств автоматизации "множественной установки" отвечу в рассмотрении идеи 9.
Идея 4
Я думаю в предисловии подробно расписаны все мысли на этот счет.
Результат рассмотрения идеи - сомнительная необходимость доработки.
Идея 5 и 6
По поводу добавления полей, надо анализировать, но учет сроков действия лицензий необходим.
Результат рассмотрения идеи - необходимо реализовать учет сроком действия лицензий на СКЗИ.
Идея 7
Тут нужны дополнительные проработки. По сути это реализация планировщика задач, подобный функционал реализован в коммерческих библиотеках 1С (БСП), но для их использования у потребителей должна быть куплена 1С:ИТС, что превратит систему в платный софт (деньги пойдут в 1С). Делать тоже самое самому, конечно можно, но это отнимет время от других задач по развитию функционала. Как вариант можно приглашать сторонних разработчиков, но это тоже бесплатно вряд ли получится.
Результат рассмотрения идеи - совершенствование системы нотификации требует доработки. Работы по этому вопросу будут в режиме минимального приоритета.
Идея 8
Существующая система учета сертификатов неудобна и требует доработок.
Результат рассмотрения идеи - доработка системы учета сертификатов принята в работу.
Идея 9
В описании не совсем понял про дублирование, поясните пожалуйста, что имеется в виду.
Формирование нескольких документов "одной кнопкой" вполне реализуемо в 1С. Но в зависимости от принятой в организации системы учета, состав документов будет отличаться. Сделать одну универсальную обработку, которая подходила бы под всех клиентов системы не получится. Это кастомизация под конкретную организацию
Результат рассмотрения идеи - идея относится к работам по доработке системы под конкретные нужды и решается в индивидуальном порядке.
Итого, в работу точно взяты идеи по учету нескольких сертификатов на одно СКЗИ и учету сроков действия лицензий на СКЗИ, доработка системы уведомлений тоже взята но с минимальным приоритетом. По остальным идеям можно еще пообщаться.
P.S. При автоматизации работы УЦ большое внимание рекомендую отвести CRM. Тут будет много нюансов. В принципе можно даже связать обе системы или доработать "Менеджмент безопасности" под особенности взаимодействия с клиентами УЦ (жизненный цикл обслуживания клиентов, информирование клиентов о завершении сроков действия ключей и т.д.).
Хочу начать с небольшого вступления, касательно стратегии учета и ФАПСИ 152.
ФАПСИ 152 - очень старый документ, ему больше 16 лет, за это время многое поменялось. Сама методика, описанная в ФАПСИ 152 идеально ложиться только на случаи, когда пользователи применяют ключи на отчуждаемых носителях, если используются не отчуждаемые носители ключей, например, ключи на жестких дисках серверов (SSL сертификаты), методика начинает "плыть", так как по ФАПСИ 152 ключевой документ это в первую очередь носитель, а потом уже записанная информация, соответственно для передачи подобного ключа нужно будет передавать винчестер, а если на нем уже есть другие ключи ? Логический коллапс.
Другим примером устаревания ФАПСИ 152 является необходимость росписи в журналах, но если вы работаете в филиальной структуре и скажем в удаленном филиале админ установил СКЗИ на компьютер, то вам нужно отправлять в удаленный филиал весь журнал учета СКЗИ для получения его росписи. Это особенно забавно выглядит если расстояние между офисами тысячи километров.
Подобных примеров можно привести большое количество. Я лично организовывал работу органа критозащиты и могу на своем опыте сказать, что на 100% реально работать по ФАПСИ 152 невозможно.
Но в то же время, этот документ является обязательным к применению для лицензиатов. Поэтому ему необходимо следовать там, где это возможно. Кстати говоря, сама ФСБ знает об устаревании документа и относится с пониманием к несоблюдению некоторых его требований - например, никто сейчас письменно не уведомляет ФСБ о создании органа криптозащиты и в тоже время это за это не наказывают. Более того, выполняя функцию администратора СКЗИ я получал большое количество ключей, но не один УЦ не заставлял подписывать в журнале учета (как того предписывает ФАПСИ 152), всем всегда хватает подписи в актах передачи. В тоже время некоторые подобные УЦ публикуют на сайте положительные заключения проверок ФСБ.
Поэтому идеологически программа строилась из необходимости организации реального учета в области СКЗИ, причем как отечественной, так и импортной криптографии с максимальным соответствием подобного учета методике ФАПСИ 152. И я считаю что это сделать удалось, поскольку к некоторым пользователям системы приходили проверки со стороны регулятора и претензий на подобную схему организации учета не поступало.
Идеология учета с помощью системы включает в себя два основных информационных ресурса:
1. Картотека подписанных бумажных первичных документов (актов);
2. Компьютерная база данных - непосредственно сама система "Менеджмент безопасности".
Картотека документов, содержит все необходимые сведения, указанные в ФАПСИ 152 и по сути является исчерпывающим ресурсом для проверяющих.
Для ответа на классический вопрос любой проверки - "Покажите журнал учета СКЗИ" в базе данных созданы отчеты, одним из которых является "Журнал учета СКЗИ (ФАПСИ 152)". Если все правильно ведется, то данный отчет будет являться "оглавлением" для картотеки документов. Корректность журнала, достигается путем распечатки и подписи каждого листа, перед передачей проверяющим. Журнал не предназначен для заполнения в ручную или фиксации в нем каких-либо данных это всего лишь отчет. Поэтому по большому счету нет никакой разницы в каком порядке там выводятся строки. Более того, если вы сдаете СКЗИ в аренду с последующим возвратом, то количество строк в журнале будет меняться. Новые строки могут добавляться в середину журнала, поэтому привязка СКЗИ к позиции в журнале практического смысла не имеет.
Компьютерная база данных - предназначена для практической ежедневной работы. Если вы опасаетесь вести учет в электронном виде то можете ее не показывать. Хотя из личных не официальных комментариев представителей регулятора, можно утверждать что, вести учет в электронном виде не является нарушением.
Разбор идей
Идея 1. Создание отчета - Журнал учета СКЗИ по форме, рекомендованной для обладателей конфиденциальной информации (ОКИ).
Сделать его конечно можно, но нужно ли? Дело в том, что для реальной работы подобное представление информации не удобно, а некоторые вопросы, например перенос одного СКЗИ на другой комп в нем вообще невозможно отразить. Если делать только как отчет для регуляторов, то пользователи могут запутаться какой журнал для чего нужен.
Результат рассмотрения идеи - сомнительная необходимость доработки.
Идея 2 и 3.
Организацию учета, которую вы привели в примерах можно существенно организационно упростить. Например, если вы реально будете передавать эталонный носитель админам для установки СКЗИ, то в один прекрасный момент, они его потеряют или он перестанет работать (проверено жизнью).
Поэтому рекомендуется организовать установку СКЗИ из сетевого репозитория, где будут лежать дистрибутивы СКЗИ и необходимая документация, защиту репозитория можно сделать с помощью хэшей и разграничения доступа по принципу - админ. СКЗИ полный дотуп, ИТ-работники - только чтение, это сразу избавит вас от двух актов - выдачи эталонного дистрибутива и возврата дистрибутива. В тоже время все законно.
С точки зрения учета, я бы рекомендовал на СКЗИ делать две записи
1. Само СКЗИ (для программных считай лицензия).
2. Эталонный дистрибутив и документация (включая формуляр).
Первое вы передаете актами. Второе однажды принимается и лежит в Органе криптозащиты. Подобный подход сэкономит еще порядочное число актов.
Касательно пример по казначейству. Я бы рекомендовал действовать следующим образом - эталонный носитель учитывается единожды и отмечается, что на нем хранится 2 дистрибутива СКЗИ. Получили его, скинули на репозиторий и прячем в сейф.
Лицензии на бумажном носителе - учитываем как 4 экземпляра СКЗИ. Учитывать саму бумажку отдельно большого смысла не имеет, можно включить ее в состав документации на СКЗИ.
Формуляры - 2 шт... это конечно неправильно. У вас 4 СКЗИ и должно быть 4 формуляра. Формуляр, это бумажка, по типу ПТС на автомобиль, нельзя давать один ПТС на два автомобиля. Но в последнее время на рынке правильной работы с формулярами на рынке правильной работе с формулярами нет нигде. Встречаются случаи когда один формуляр дают на десяток СКЗИ, а в нем вообще-то, должны быть указаны регистрационные номера СКЗИ, полученные разработчиком от ФСБ, а также персональная история каждого СКЗИ, кто ставил, куда ставил и т.д. На такие случаи в системе предусмотрена возможность генерации "электронного формуляра" - отчет "Справка об экземпляре СКЗИ". Формуляры учитываем в составе документации. Итого, получаем следующие записи:
- 1 запись - "Эталонный носитель и документация на СКЗИ"
- 4 записи - "Лицензионные номера СКЗИ"
Хочу также отметить, что КС2 подразумевает использование ПАК СЗИ НСД - "Аккорд" или "Соболь", казначейство вам их дало? (риторический вопрос)
Результат рассмотрения идеи - описанные примеры существенно упрощаются при оптимизации ведения учета. Касательно разработки средств автоматизации "множественной установки" отвечу в рассмотрении идеи 9.
Идея 4
Я думаю в предисловии подробно расписаны все мысли на этот счет.
Результат рассмотрения идеи - сомнительная необходимость доработки.
Идея 5 и 6
По поводу добавления полей, надо анализировать, но учет сроков действия лицензий необходим.
Результат рассмотрения идеи - необходимо реализовать учет сроком действия лицензий на СКЗИ.
Идея 7
Тут нужны дополнительные проработки. По сути это реализация планировщика задач, подобный функционал реализован в коммерческих библиотеках 1С (БСП), но для их использования у потребителей должна быть куплена 1С:ИТС, что превратит систему в платный софт (деньги пойдут в 1С). Делать тоже самое самому, конечно можно, но это отнимет время от других задач по развитию функционала. Как вариант можно приглашать сторонних разработчиков, но это тоже бесплатно вряд ли получится.
Результат рассмотрения идеи - совершенствование системы нотификации требует доработки. Работы по этому вопросу будут в режиме минимального приоритета.
Идея 8
Существующая система учета сертификатов неудобна и требует доработок.
Результат рассмотрения идеи - доработка системы учета сертификатов принята в работу.
Идея 9
В описании не совсем понял про дублирование, поясните пожалуйста, что имеется в виду.
Формирование нескольких документов "одной кнопкой" вполне реализуемо в 1С. Но в зависимости от принятой в организации системы учета, состав документов будет отличаться. Сделать одну универсальную обработку, которая подходила бы под всех клиентов системы не получится. Это кастомизация под конкретную организацию
Результат рассмотрения идеи - идея относится к работам по доработке системы под конкретные нужды и решается в индивидуальном порядке.
Итого, в работу точно взяты идеи по учету нескольких сертификатов на одно СКЗИ и учету сроков действия лицензий на СКЗИ, доработка системы уведомлений тоже взята но с минимальным приоритетом. По остальным идеям можно еще пообщаться.
P.S. При автоматизации работы УЦ большое внимание рекомендую отвести CRM. Тут будет много нюансов. В принципе можно даже связать обе системы или доработать "Менеджмент безопасности" под особенности взаимодействия с клиентами УЦ (жизненный цикл обслуживания клиентов, информирование клиентов о завершении сроков действия ключей и т.д.).
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
1. По поводу ведения учета в электронной форме так и не понятно, что именно будет являться «реквизитом учета» (номером) конкретного экземпляра в конкретном ОКЗ, что именно написать в бирке на железке (диске).
Для понимания смысла идентификации, пример на основе учета в бумажном журнале: иду по коридору - вижу лежит СКЗИ на полу, если есть бирка с моей подписью, я понимаю, что надо кого-то наказать, а кого именно смотрю из строки журнала с № под которым учтен и промаркирован СКЗИ (надпись на бирке). В варианте электронной базы это тоже возможно, через поиск если на том элементе есть какие-то опознавательные знаки. Вот конкретный пример с АПКШ «Континент»: в комплекте есть куча всяких формуляров дисков и не на всех есть «рег.номер» или какие-то другие опознавательные знаки, а мне надо его «посчитать».
2. По поводу одного формуляра на несколько экземпляров СКЗИ, поступило предложение в одном формуляре фиксировать все движения и установки всех экземпляров.
3. Про дублирование, для примера скриншот из демонстрационной базы во вложении.
4. Структура нашей организации очень разветвленная и УЦ выдает ЭЦП по всей стране, при этом генерация закрытых ключей осуществляется в централизованном режиме. Передача ключевой информации пользователю осуществляется в контейнере, через оператора внутренней закрытой сети связи, до регионального представительства, а там такой же оператор выдает контейнер непосредственно владельцу. Ключ однозначно попадает к владельцу через доверенную среду. При ведении учета в программе возникает небольшое неудобство в том, что при передаче контейнера оператору закрытой связи, ему негде расписаться в распечатанном акте. Приходится от руки ставить пометки о том, каким сообщением ушло, кто принял в региональном центре. В программе делать аналогичные пометки в примечании к акту передачи. Подобные же пометки производятся, когда получает контейнер не пользователь, а другой человек (Администратор) по доверенности.
Причем если ставить в программе в качестве получателя контейнера не владельца ЭЦП (сотрудника удаленного подразделения), а оператора закрытой связи (сотрудника нашего подразделения) сбивается отражение информации в отчетах, например «Справка об организации».
Предложение добавить в формы актов передачи вариант с учетом реквизитов «третьего» документа (доверенности (письма по закрытой связи)) и ФИО доверенного (оператора закрытой связи) и без подписи получателя.
Для понимания смысла идентификации, пример на основе учета в бумажном журнале: иду по коридору - вижу лежит СКЗИ на полу, если есть бирка с моей подписью, я понимаю, что надо кого-то наказать, а кого именно смотрю из строки журнала с № под которым учтен и промаркирован СКЗИ (надпись на бирке). В варианте электронной базы это тоже возможно, через поиск если на том элементе есть какие-то опознавательные знаки. Вот конкретный пример с АПКШ «Континент»: в комплекте есть куча всяких формуляров дисков и не на всех есть «рег.номер» или какие-то другие опознавательные знаки, а мне надо его «посчитать».
2. По поводу одного формуляра на несколько экземпляров СКЗИ, поступило предложение в одном формуляре фиксировать все движения и установки всех экземпляров.
3. Про дублирование, для примера скриншот из демонстрационной базы во вложении.
4. Структура нашей организации очень разветвленная и УЦ выдает ЭЦП по всей стране, при этом генерация закрытых ключей осуществляется в централизованном режиме. Передача ключевой информации пользователю осуществляется в контейнере, через оператора внутренней закрытой сети связи, до регионального представительства, а там такой же оператор выдает контейнер непосредственно владельцу. Ключ однозначно попадает к владельцу через доверенную среду. При ведении учета в программе возникает небольшое неудобство в том, что при передаче контейнера оператору закрытой связи, ему негде расписаться в распечатанном акте. Приходится от руки ставить пометки о том, каким сообщением ушло, кто принял в региональном центре. В программе делать аналогичные пометки в примечании к акту передачи. Подобные же пометки производятся, когда получает контейнер не пользователь, а другой человек (Администратор) по доверенности.
Причем если ставить в программе в качестве получателя контейнера не владельца ЭЦП (сотрудника удаленного подразделения), а оператора закрытой связи (сотрудника нашего подразделения) сбивается отражение информации в отчетах, например «Справка об организации».
Предложение добавить в формы актов передачи вариант с учетом реквизитов «третьего» документа (доверенности (письма по закрытой связи)) и ФИО доверенного (оператора закрытой связи) и без подписи получателя.
- Вложения
-
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Поделюсь, как делаю я сам.1. По поводу ведения учета в электронной форме так и не понятно, что именно будет являться «реквизитом учета» (номером) конкретного экземпляра в конкретном ОКЗ, что именно написать в бирке на железке (диске).
Примеры идентификаторов ключевой информации:
SSL-сертификат www.company.ru SN:15 2E E8 41 9A f6 b8 17 9A 3E 27 90 C6 22 E5 03
Ключ УКЭП для ФТС (Иванова Дарья Игоревна). SN: 15 22 29 2a ce 1c cd 10 44 22 ad c0 e2 9c 51 33
Ключ шифрования для защиты транзакций с ООО "Алтаир" SN: 21 22 ed 29 fe
Примеры идентификаторов носителей ключевой информации:
Файловая система file-exch.internal (192.168.100.201)
Rutoken S 1673272567
Дискета "КА и шифр 2017 2299320"
DVD+R TDK Ключи шифрования ООО "Альтаир" 2017
Токены, идентифицируются по номеру нанесенному на корпус, дискеты, DVD маркируются перманентным маркером. Файловая система... - указывает на то, что ключи лежат на жестком диске такого-то сервера
Примеры идентификаторов экземпляров СКЗИ
Заводской номер 5DF1FBDQ. Модель АПКШ Континент IPC-1000
SN:21-42341-94526. Модель VIPNET Coordinator HW/KB 1000
39394-00000-023DE-2GDAT-033FF Модель СКЗИ Крипто-Про CSP 3.9
Упоминание модели, только для понимания, в лейблу не пишется. Идентификация конкретных устройств происходит по заводским или серийным номерам. Программных по лицензионным номерам. Если на корпусах аппаратных СКЗИ нет идентификаторов (такого не разу не видел), то можно приклеить бирку с номером.
В результате, идете по коридору, смотрите Континент валяется...
Так серийник такой-то, справка об экземпляре СКЗИ - ага, выдавался Ибрагимову Альберту.... Ата-та ему.
А если серьезно, то схема рабочая, сам проводил по ней инвентаризацию и вел разборки с пользователями в следующем виде:
- "ГДЕ КЛЮЧЕВОЙ НОСИТЕЛЬ XXXX???? Вы хоть понимаете сколько денег могут украсть если вы его потеряли? У токена который вы мне показываете другой серийник, где тот токен, которые вы получили по вот этому Акту?"
С формальной точки зрения это все равно нарушение, поэтому не вижу смысла этим заниматься. Пользуйтесь отчетом "Справка об экземпляре СКЗИ" там есть необходимая информация.2. По поводу одного формуляра на несколько экземпляров СКЗИ, поступило предложение в одном формуляре фиксировать все движения и установки всех экземпляров.
Это баг. Возникает при уничтожении экземпляра СКЗИ. Исправим в следующем релизе.3. Про дублирование, для примера скриншот из демонстрационной базы во вложении.
По пункту 4.
Передача должна вестись несколькими Актами, как по факту и есть
1. ОКЗ -> Курьер
2. Курьер -> Клиент
Так сбиваться ничего не должно, попробуйте.
Вы можете самостоятельно "заточить" форму акта под вашу организацию. В системе есть механизм подключения внешних печатных форм и есть шаблоны типовых актов. Можно взять шаблон и конфигураторе 1С внести требуемые вам изменения.Предложение добавить в формы актов передачи вариант с учетом реквизитов «третьего» документа
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Условие еще одной необходимой Задачи учета в программе :
По регламенту удостоверяющего центра Сертификат действует один год, ключ соответственно тоже. Порядок перевыпуска сертификата: по заявлению, с пометкой «персональные данные не изменялись». В случае перехода человека на другую должность или смене иных реквизитов сертификат аннулируется и выпускается новый, на вновь зарегистрированного пользователя с измененными данными. Вопрос: как прозрачно учесть передачу ключевой информации в программе?
При смене фамилии такое возможно осуществить без проблем, но при смене должности (или места работы), при условии того, что на новм месте пользователю тоже положена электронная подпись, это возможно только создавая нового человека в организации с фамилией вроде «Иванов Иван Иванович 1».
После этого можно уничтожить/передать все выданные на старого сотрудника ключи и выдавать всё новому, но по факту это один и тот же человек!
Предлагаю сделать учетными реквизитами субъекта не ФИО, а связку ФИО+должность или ФИО+должность+организация, так как один и тот же человек может работать в двух организациях, обслуживаемых одним ОКЗ и в каждом случае иметь право подписи. Можно конечно еще добавить в связку «Внутренние документы» учитывающие перемещение сотрудника (для контроля дат назначения на должность), но это не задача криптооргана, его задача «быть в курсе», тем более если это перемещение не внутри организации Лицензиата , а внутри обслуживаемой организации, то засорять учет информацией о приказах сторонних организаций неразумно и излишне трудоемко. Достаточно отметок о начале существования «связки» и окончании, ну и поле для примечания, чтоб реквизит приказа о перемещении по должности вписать, который принесет пользователь.
По регламенту удостоверяющего центра Сертификат действует один год, ключ соответственно тоже. Порядок перевыпуска сертификата: по заявлению, с пометкой «персональные данные не изменялись». В случае перехода человека на другую должность или смене иных реквизитов сертификат аннулируется и выпускается новый, на вновь зарегистрированного пользователя с измененными данными. Вопрос: как прозрачно учесть передачу ключевой информации в программе?
При смене фамилии такое возможно осуществить без проблем, но при смене должности (или места работы), при условии того, что на новм месте пользователю тоже положена электронная подпись, это возможно только создавая нового человека в организации с фамилией вроде «Иванов Иван Иванович 1».
После этого можно уничтожить/передать все выданные на старого сотрудника ключи и выдавать всё новому, но по факту это один и тот же человек!
Предлагаю сделать учетными реквизитами субъекта не ФИО, а связку ФИО+должность или ФИО+должность+организация, так как один и тот же человек может работать в двух организациях, обслуживаемых одним ОКЗ и в каждом случае иметь право подписи. Можно конечно еще добавить в связку «Внутренние документы» учитывающие перемещение сотрудника (для контроля дат назначения на должность), но это не задача криптооргана, его задача «быть в курсе», тем более если это перемещение не внутри организации Лицензиата , а внутри обслуживаемой организации, то засорять учет информацией о приказах сторонних организаций неразумно и излишне трудоемко. Достаточно отметок о начале существования «связки» и окончании, ну и поле для примечания, чтоб реквизит приказа о перемещении по должности вписать, который принесет пользователь.
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Предложение принято в работу.
Скорее всего сделаем следующим образом. Добавим справочник физ. лица., а из справочника ответственные лица уберем ФИО и дадим ссылку на справочник физ. лица, это позволит одному и тому же физ. лицу работать в различных организациях или занимать несколько должностей в рамках одной организации.
Скорее всего сделаем следующим образом. Добавим справочник физ. лица., а из справочника ответственные лица уберем ФИО и дадим ссылку на справочник физ. лица, это позволит одному и тому же физ. лицу работать в различных организациях или занимать несколько должностей в рамках одной организации.
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
По поводу Идеи 7.
Я так понимаю ее приоритет из минимального перешел в нулевой).
В ютубе нашел обучающее видео, и там в 9 уроке по результатам проделанной работы на рабочем столе программы есть поле "Имениники".
Как мне видится, при такой реализации вполне возможно сделать уведомление оператора о надвигающихся проблемах (на неделю/месяц/квартал) таких как окончание срока действия сертификатов, лицензий, ключей и пр.
Это позволит спланировать работу ОКЗ и не упустить, что то важное при больших объемах .
Ссылку на видео дам, если это неприемлемо, то удалите:
https://www.youtube.com/watch?v=HLrOAyj4NCs
Я так понимаю ее приоритет из минимального перешел в нулевой).
В ютубе нашел обучающее видео, и там в 9 уроке по результатам проделанной работы на рабочем столе программы есть поле "Имениники".
Как мне видится, при такой реализации вполне возможно сделать уведомление оператора о надвигающихся проблемах (на неделю/месяц/квартал) таких как окончание срока действия сертификатов, лицензий, ключей и пр.
Это позволит спланировать работу ОКЗ и не упустить, что то важное при больших объемах .
Ссылку на видео дам, если это неприемлемо, то удалите:
https://www.youtube.com/watch?v=HLrOAyj4NCs
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Приоритет не 0, но близкий к нему. В ближайшее время скорее всего заниматься этой проблемы не будем, чтобы реализовать намеченные планы итак много перепиливать придется, а потом видно будет.
Re: Менеджмент безопасности - список пожеланий и доработок (wishlist)
Еще идея: реализовать возможность добавления нескольких областей использования ключевой информации.