Комментарии 41
Коль скоро вы рассматриваете информационную безопасность, то неплохо бы упомянуть основную причину внедрения АРМ КБР-Н, а именно потенциальную незащищенность канала АБС <=> «старый» АРМ КБР.
Угрозы ИБ будут рассмотрены в следующих частях. Забегая вперед можно сказать что АРМ КБР-Н увеличит безопасность только при ОЧЕНЬ качественной реализации функций подписи в модулях интеграции АБС. Если все будет как обычно, то станет только хуже.
Под «как обычно» имеете в виду реализацию наложения ЗК и КА во внешнем по отношению к АБС модуле? Ну, так-то да, имеет место, если не хотят обращаться к вендору АБС. Кроилово ведет к попадалову.
А реализация внутри АБС и передача в АРМ КБР-Н уже защищенного файла, ИМХО, больших рисков не несет.
А реализация внутри АБС и передача в АРМ КБР-Н уже защищенного файла, ИМХО, больших рисков не несет.
Многие АБС построены на базе СУБД, работающей под ОС *nix семейства. Далеко не факт, что технически будет возможно установить на сервер АБС СКАД Сигнатуру, а с учетом того, что в больших АБС серверов значительно больше 1, то идея установки «СКЗИ на АБС» превращается в сложно реализуемую.
Таким образом в большинстве случаев криптография будет реализовываться внешним отношению к АБС модулем. В данном исследовании мы их называем модуль интеграции АБС-АРМ КБР. То есть то, о чем вы и сказали — «кроилово».
В данном случае незащищенный канал АБС-АРМ КБР, может поменяется на незащищенный канал АБС-модуль интеграции АБС-КБР. Плюс к этому появятся дополнительные угрозы свалянные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.
Конечно можно сделать все и по уму — защищая канал АБС-модуль интеграции АБС-АРМ-КБР. Все будет зависеть от конкретной реализации.
Таким образом в большинстве случаев криптография будет реализовываться внешним отношению к АБС модулем. В данном исследовании мы их называем модуль интеграции АБС-АРМ КБР. То есть то, о чем вы и сказали — «кроилово».
В данном случае незащищенный канал АБС-АРМ КБР, может поменяется на незащищенный канал АБС-модуль интеграции АБС-КБР. Плюс к этому появятся дополнительные угрозы свалянные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.
Конечно можно сделать все и по уму — защищая канал АБС-модуль интеграции АБС-АРМ-КБР. Все будет зависеть от конкретной реализации.
Многие АБС построены на базе СУБД, работающей под ОС *nix семейства. Далеко не факт, что технически будет возможно установить на сервер АБС СКАД Сигнатуру.
Во-первых, Валидата сказала, что у них есть библиотеки, совместимые по ключам с Сигнатурой и работающие под никсами.
Во-вторых, криптография может выполняться на рабочем месте сотрудника, ответственного за расчеты по платежной системе ЦБ, и, вообще говоря, это хорошее решение, хоть и не единственное.
В-третьих, хотя СУБД и на *nix, сервер приложений, запускающий криптографию, вполне может быть под Windows.
Смотрите, сейчас я вас раскручу на все секреты из вашей следующей статьи :)
Кстати, по поводу *nix — оказывается Сигнатура и для Linux есть:
www.x509.ru/forum/viewtopic.php?id=14889
www.x509.ru/forum/viewtopic.php?id=14889
Плюс к этому появятся дополнительные угрозы связанные с еще одним СКЗИ. Если раньше оно было только одно на АРМ КБР, то теперь их будет 2: АРМ КБР-Н и модуль интеграции АБС-АРМ КБР.
А в чем угроза из-за появления второго СКЗИ?
СКЗИ — одно из наиболее критичных с точки зрения атаки мест. Появление второго СКЗИ, создает дополнительное критичное место.
Слишком общий ответ. Можете предложить возможный кейс?
Безопасность платежей на 99% обеспечивается применением шифрования и ЭП.
То и другое может быть вскрыто, как путем похищения закрытых ключей, так и вмешательством в работу в самого СКЗИ.
Соответственно, применение второго СКЗИ, добавляет место откуда могут быть похищены ключи или на которое может быть оказано вредоносное воздействие.
Если оба СКЗИ работают на разных ключах, и оба выполняют и шифрование и ЭП (эшелонированная защита), то подобных проблем не будет.
В случае применения АРМ КБР-Н, такого нет. ЭП подпись выполняется на стороне АБС, а шифрование выполняется на стороне АРМ КБР-Н.
Более чем уверен, что будут банки которые это будут делать на базе одних и тех же ключей.
То и другое может быть вскрыто, как путем похищения закрытых ключей, так и вмешательством в работу в самого СКЗИ.
Соответственно, применение второго СКЗИ, добавляет место откуда могут быть похищены ключи или на которое может быть оказано вредоносное воздействие.
Если оба СКЗИ работают на разных ключах, и оба выполняют и шифрование и ЭП (эшелонированная защита), то подобных проблем не будет.
В случае применения АРМ КБР-Н, такого нет. ЭП подпись выполняется на стороне АБС, а шифрование выполняется на стороне АРМ КБР-Н.
Более чем уверен, что будут банки которые это будут делать на базе одних и тех же ключей.
В случае применения АРМ КБР-Н, такого нет. ЭП подпись выполняется на стороне АБС, а шифрование выполняется на стороне АРМ КБР-Н.По-моему, ЗК на сообщение и шифрование уже сейчас, со старым АРМ, могут быть сделаны на разных ключах. Только пока это по желанию банка.
Более чем уверен, что будут банки которые это будут делать на базе одних и тех же ключей.По-моему, ЦБ при переходе на АРМ КБР-Н будет обязывать использовать раздельные ключи, АРМ КБР-Н уже предварительно проверяет верность ЗК в сообщениях, полученных от АБС.
Я все жду, когда ЦБ потребует использовать или хотя бы реализует callback из АРМ-а в АБС с вопросом — «ты правда посылал такой платеж?». Сами рекомендовали, но ничего не делают.
По Альбому УЭФБС применение ЗК для банков не обязательно, применяют только КА.
Да, могут.
Пока таких требований не видел.
В общем, платежная система Банка России довольно неплохо защищена, если грамотно применять защитные меры. Другое дело в том, что банки не всегда это делают, и как мне кажется основная причина в том, что до конца не осознают системность проблемы.
Данное исследование и было предпринято, как раз что бы и банки и ЦБ смогли в комплексе увидеть все нюансы безопасности.
По-моему, ЗК на сообщение и шифрование уже сейчас, со старым АРМ, могут быть сделаны на разных ключах. Только пока это по желанию банка.
Да, могут.
По-моему, ЦБ при переходе на АРМ КБР-Н будет обязывать использовать раздельные ключи, АРМ КБР-Н уже предварительно проверяет верность ЗК в сообщениях, полученных от АБС.
Пока таких требований не видел.
В общем, платежная система Банка России довольно неплохо защищена, если грамотно применять защитные меры. Другое дело в том, что банки не всегда это делают, и как мне кажется основная причина в том, что до конца не осознают системность проблемы.
Данное исследование и было предпринято, как раз что бы и банки и ЦБ смогли в комплексе увидеть все нюансы безопасности.
Наиболее критичное место это файл. В АРМ-КБР он отдавался без средств контроля неизменности от момента формирования и выгружался из нее так же так же обычный xml. Изменить в нем счет получателя относительно несложно, защита правами на запись давно уже не является защитой.
Да, это так, АРМ КБР-Н как раз должен это поправить.
Но надо смотреть на всю картину в целом, а не только на КБР.
Но надо смотреть на всю картину в целом, а не только на КБР.
Если раньше надо было взломать АРМ КБР и незаметно подменить реквизиты в файле перед подписью, то теперь надо взламывать АБС, чтобы подменить там перед подписью.
Больше напоминает перераспределение отвественности. АБС это точно вотчина банка, а АРМ КБР-Н, это просто транспорт который и ломать теперь смысла особого нет.
Ну и взлом АБС требует болеет высокой квалификации хакера, особенно если все операции подписи будут производиться на лету внутренней логикой системы. Это не файлик на диске поправить.
Больше напоминает перераспределение отвественности. АБС это точно вотчина банка, а АРМ КБР-Н, это просто транспорт который и ломать теперь смысла особого нет.
Ну и взлом АБС требует болеет высокой квалификации хакера, особенно если все операции подписи будут производиться на лету внутренней логикой системы. Это не файлик на диске поправить.
Про перенос ответственности вы это здорово подметили.
Я думаю проблема в том, что мы сейчас стали заложниками подхода ФСБ в части регулирования криптографии.
Сертифицированное криптоядро, например СКАД Сигнатура, это довольно «тяжелое» ПО, которое не может работать с другими криптоядрами и довольно глубоко встраиваться в систему (по крайней мере в ОС Windows). Сейчас нельзя например реализовать сертифицированное шифрование на том, же SQL, или скриптовых языках. Если бы это можно было могли бы появиться довольно элегантные решения, когда бы ЭП осуществлялась прямо SQL сервером, без лишних навесок.
Но что есть, то есть. Наверно решения ФСБ основываются на той информации и тех подходах которые нам неизвестны.
Я думаю проблема в том, что мы сейчас стали заложниками подхода ФСБ в части регулирования криптографии.
Сертифицированное криптоядро, например СКАД Сигнатура, это довольно «тяжелое» ПО, которое не может работать с другими криптоядрами и довольно глубоко встраиваться в систему (по крайней мере в ОС Windows). Сейчас нельзя например реализовать сертифицированное шифрование на том, же SQL, или скриптовых языках. Если бы это можно было могли бы появиться довольно элегантные решения, когда бы ЭП осуществлялась прямо SQL сервером, без лишних навесок.
Но что есть, то есть. Наверно решения ФСБ основываются на той информации и тех подходах которые нам неизвестны.
Нет никакой проблемы стойко шифровать средствами SQL сервера. Или на сервере. Отдельным процессом/потоком/службой. Вопрос в ключах. У кого они? То же самое с ЭП, вопрос опять же в ключах, вся «элегантность» подписи на сервере ломается необходимостью передать ключ на этот сервер, опять все упрется в защиту канала. С точки зрения же возможных последствий от его компрометации лучше гонять платежный документ (его можно сверить перед отправкой), чем ключ, которым можно заверить документ созданный вообще не в банке.
Шифровать на SQL-сервере нельзя с точки зрения «нормативки» и договоров с ЦБ.
Для шифрования должна использоваться только СКАД Сигнатура.
Для шифрования должна использоваться только СКАД Сигнатура.
Шифрование и дешифрование происходит в АРМ КБР-Н, а там вопрос с SQL-сервером, передачей ключей и Сигнатурой не стоит.
Использование АРМ КБР-Н не является обязательным. Шифровать можно и другим ПО, главное использовать форматы и ключи ЦБ. Кстати, оно в отличи от АРМ КБР-Н может быть сертифицировано ФСТЭК/ФСБ и проведен контроль влияния среды на СКЗИ. Другой вопрос — зачем? В АРМ КБР-Н приходит защищенный минимум одной ЭП файл. Шифрование там выполняет функцию защиты от компрометации, целостность защищена уже в АБС простановкой ЭП.
Не только. Можно использовать криптосервер той же «Валидаты». Другой вопрос, что это ничего дополнительно не улучшает, после постановке подписи (ЗК) документ менять нет смысла, а ЗК можно (нужно!) проставлять в доверенном контуре.
В договоре с ЦБ прописана необходимость использования СКАД Сигнатуры и ПО для АРМ (это может быть АРМ КБР или другое ПО, предоставляемое ЦБ).
В своих презентациях ЦБ упоминал про сервер «Валидаты», для того, чтобы его использовать нужно пере заключать договор.
Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись. См. Альбом УФЭБС и договор с ЦБ.
Договор об обмене электронными сообщениями
при переводе денежных средств
в рамках платежной системы Банка России
2.5. Для выполнения условий Договора Стороны применяют средство криптографической защиты информации «Система криптографической авторизации документов «Сигнатура»» (далее СКЗИ СКАД «Сигнатура»).
3.1.2. Заключает договор с Банком, в соответствии с которым получает от Банка:
— ПО для АРМ,
— СКЗИ.
В своих презентациях ЦБ упоминал про сервер «Валидаты», для того, чтобы его использовать нужно пере заключать договор.
Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись. См. Альбом УФЭБС и договор с ЦБ.
В своих презентациях ЦБ упоминал про сервер «Валидаты», для того, чтобы его использовать нужно пере заключать договор.
Теоретически. Практически в документе нет информации о ПО, которым была наложена подпись. Если бы не особый OID то и КриптоПро без проблем бы подписывал ГОСТом с ключами «Сигнатуры».
Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись.
Пока не ставят и то не все. Смотрите третий вариант защиты. Но это не суть, можно ставить КА и/или ЗК+КА. Не важно, суть в том, что после простановки ЭП (и ЗК и КА на самом деле ЭП) документ изменять/подменять бессмысленно.
В комментарии выше я указывал на то, что в договоре явно прописано использование СКАД Сигнатуры.
Действительно в подписанном ЭС нет сведений о том, с помощью какого СКЗИ оно подписано и соответственно теоретически можно использовать любое другие средства подписи, хоть даже написать самому.
НО регуляторный риск (нарушение договора, нарушение 552-П) ставит на всем этом крест, слишком дорогие возможные последствия — расторжение договора с МЦИ / нарушение требований ЦБ -> отзыв лицензии.
Действительно в подписанном ЭС нет сведений о том, с помощью какого СКЗИ оно подписано и соответственно теоретически можно использовать любое другие средства подписи, хоть даже написать самому.
НО регуляторный риск (нарушение договора, нарушение 552-П) ставит на всем этом крест, слишком дорогие возможные последствия — расторжение договора с МЦИ / нарушение требований ЦБ -> отзыв лицензии.
отзыв лицензии.
...->расстрел… )))
Даже расторжения нет по причине использования иного ПО для простановке ЭП. Указание использования СКАД «Сигнатура» вписано в «Общие положения», ни в условиях ни в перечне причин расторжения нет пункта о расторжении по причине неиспользования Сигнатуры. Зато есть требования ФСБ о необходимости соблюдать требования формуляров к СКЗИ, в котором у «Сигнатуры» есть требование проводить «оценку влияния...» при встраивании. В АРМ_ах «Сигнатура» встроена, а оценки влияния нет! Какое из нарушений более существенно? Я не призываю использовать криптосервер, повторюсь, там другие проблемы есть. Подписать документ нужно как можно в более доверенной среде и не загруженный файл, а после совершения расчетной операции! В полном соответствии приложением 2 к письму 58 МЦИ.
Наказание за несоблюдение всегда интересная тема для дискуссии.
Приведу свои аргументы за то, что использование стороннего СКЗИ может послужить поводом к расторжению договора и отзыву лицензии.
Итого по расторжению договора:
1. Согласно договору СКЗИ — СКАД Сигнатура
2. Согласно Приложению 3 — Расчет хэш-сумм идет для СКАД Сигнатура
4. Согласно Приложению 6 — Банк оформляет сертификаты ключей для СКАД Сигнатура
3. Согласно Приложению 7 — СКЗИ должно устанавливать в соответствии с документацией на СКАД Сигнатуру
Таким образом, считаю что использование другого СКЗИ может быть основанием для Расторжения договора по пункту 9.5.4. или на основании п. 2.1. ст. 450 ГК РФ
Итого по отзыву лицензии:
Использование другого СКЗИ, вместо СКАД Сигнатуры будет нарушением п.2.4 552-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.
Нарушение нормативных документов ЦБ, согласно п.6 ст. 20 Закона о банках и банковской деятельности может являться основанием для отзыва лицензии.
Приведу свои аргументы за то, что использование стороннего СКЗИ может послужить поводом к расторжению договора и отзыву лицензии.
Договор об обмене электронными сообщениями
при переводе денежных средств
в рамках платежной системы Банка России
1. Предмет договора
1.1. Договор определяет… а также требования к защите информации в платежной системе Банка России.
2. Общие положения
2.5. Для выполнения условий Договора Стороны применяют средство криптографической защиты информации «Система криптографической авторизации документов «Сигнатура»» (далее СКЗИ СКАД «Сигнатура»).
Для защиты ЭС от доступа к ним посторонних лиц при передаче по незащищенным каналам связи применяется шифрование.
Порядок управления ключами КА (ЭП) и ключами шифрования, применяемыми при обмене ЭС при переводе денежных средств в рамках платежной системы Банка России, определяется в Приложении 6 к настоящему Договору.
Порядок обеспечения информационной безопасности при использовании СКЗИ определяется в Приложении 7 к настоящему Договору.
3. Условия участия в обмене ЭС, приостановления
И прекращения участия в обмене ЭС
3.1. Клиент для участия в обмене ЭС выполняет следующие действия.
3.1.5. Выполняет требования к защите информации в платежной системе Банка России для клиентов Банка России, в том числе требования к защите информации при обмене ЭС, приведенные в приложении 1 к настоящему Договору.
3.5. Клиент до начала обмена ЭС представляет акт о готовности к обмену электронными сообщениями с Банком России при переводе денежных средств в рамках платежной системы Банка России по форме, приведенной в Приложении 3 к настоящему Договору.
5.2. Клиент обязан:
5.2.7. Использовать актуальные версии ПО для АРМ, СКЗИ, нормативно-справочной информации.
9. Срок действия договора, порядок его изменения и расторжения
9.5.4. При нарушении Клиентом требований к обмену ЭС и обеспечению безопасности при обмене ЭС, предусмотренных законодательством Российской Федерации, и условий Договора.
Приложение 3 к договору (Акт готовности)
4. Все АРМ паспортизованы. Значения результатов вычисления хэш-функции исполняемых модулей (контрольных сумм) программного обеспечения (далее — ПО) СКАД «Сигнатура», утвержденные руководителем и заверенные печатью организации, зафиксированы в Приложении к настоящему Акту. Указанное Приложение является неотъемлемой частью Акта.
Приложение 6 к договору (Порядок управления ключами)
1. Общие положения.
1.2. В ходе функционирования Клиентом должны формироваться и храниться в бумажном виде следующие документы СКАД «Сигнатура»:…
2.2. Основными функциями Клиента являются следующие:
— ответственное хранение хэш-функций ПО СКАД «Сигнатура»;
Приложение 7 — Порядок обеспечения информационной безопасности при использовании СКЗИ
1. Установка и настройка СКЗИ на АРМ выполняются с учетом требований, изложенных в эксплуатационной документации на СКЗИ, в присутствии АИБ, назначаемого Клиентом. При каждом запуске АРМ должен быть обеспечен контроль целостности установленного программного обеспечения СКЗИ.
Положение Банка России от 24 августа 2016 г. № 552-П “О требованиях к защите информации в платежной системе Банка России”
2.4. Участники должны обеспечивать выполнение требований эксплуатационной документации на системы защиты информации от несанкционированного доступа (далее — СЗИ от НСД), СКЗИ, средства защиты от воздействий вредоносного кода (далее — СЗ от ВВК), применяемые на участке ПС БР, в течение всего срока их эксплуатации, в том числе при установке и настройке, а также обеспечить восстановление указанных технических средств защиты информации в случаях сбоев и (или) отказов в их работе.
Итого по расторжению договора:
1. Согласно договору СКЗИ — СКАД Сигнатура
2. Согласно Приложению 3 — Расчет хэш-сумм идет для СКАД Сигнатура
4. Согласно Приложению 6 — Банк оформляет сертификаты ключей для СКАД Сигнатура
3. Согласно Приложению 7 — СКЗИ должно устанавливать в соответствии с документацией на СКАД Сигнатуру
Таким образом, считаю что использование другого СКЗИ может быть основанием для Расторжения договора по пункту 9.5.4. или на основании п. 2.1. ст. 450 ГК РФ
Итого по отзыву лицензии:
Использование другого СКЗИ, вместо СКАД Сигнатуры будет нарушением п.2.4 552-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.
Нарушение нормативных документов ЦБ, согласно п.6 ст. 20 Закона о банках и банковской деятельности может являться основанием для отзыва лицензии.
Использование другого СКЗИ, вместо СКАД Сигнатуры будет нарушением п.2.4 552-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.
Документация на СКЗИ никак не договор, а Формуляр, по которому для использования в АРМ должно быть заключение ФСБ России по результатам оценки влияния среды функционирования СКЗИ. Может быть для «АРМ» оно уже появилось и пропустил это? Чему противоречит использование сертифицированного СКЗИ КС «Валидата» в соответствии с его формуляром?
Касательно контроля корректности встраивания СКАД Сигнатура в АРМ КБР.
Да, должно быть. Зона ответственности ЦБ. Поскольку именно он делал встраивание.
Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.
Если посмотреть на данный вопрос по другому. К вам пришла проверка и говорит (гипотетически): «Почему при работе АРМ КБР вы не соблюдаете требования док-ции СКЗИ „Вебра-OW?“. Ваш резонный ответ будет: „Договором обмена ЭС с МЦИ ЦБ РФ предусмотрено применение СКАД Сигнатура, а не Верба-OW“
Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.
Да, должно быть. Зона ответственности ЦБ. Поскольку именно он делал встраивание.
Документация на СКЗИ никак не договор
Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.
Если посмотреть на данный вопрос по другому. К вам пришла проверка и говорит (гипотетически): «Почему при работе АРМ КБР вы не соблюдаете требования док-ции СКЗИ „Вебра-OW?“. Ваш резонный ответ будет: „Договором обмена ЭС с МЦИ ЦБ РФ предусмотрено применение СКАД Сигнатура, а не Верба-OW“
Чему противоречит использование сертифицированного СКЗИ КС «Валидата» в соответствии с его формуляром?
Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.
Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.Закон иного мнения. Нормативка по СКЗИ определяет алгоритм, наличие лицензий у разработчика и сертификацию ПО. КС разработан разработчиком с лицензией, имеет сертификат ФСБ, использует отечественную предписанную криптографию. С «необычными» OID работает. То есть законодательству РФ соответствует и технологически подписывает/шифрует правильно. Более того, разработчик один и тот же. Так что пунктики про именно «Сигнатуру» могут быть от отсутствия альтернативы на момент написания шаблона. А если завтра разработчик сервер «Сигнатурой» назовет? Или СКАД назовет «Валидата»? Уточните в ЦБ, что в этом случае делать!?!?
Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.
В 552-П нет ничего про договор. Есть формуляр на используемое СКЗИ. СКЗИ используется в соответствии с ним. Это если по существу.
Чтобы дальнейшая дискуссия была предметной предлагаю разбить рассуждения на пункты с которыми можно будет либо соглашаться либо дополнять /изменять.
(1) Законодательная база
Начнем с того, что разработчик, имеющий лицензию ФСБ России на разработку криптосредств сертифицировать свою продукцию не обязан. Делает это он лишь для того, чтобы его криптосредства могли использоваться в тех случаях, когда есть требование по использованию сертифицированных криптосредств.
Для банка как для коммерческой организации (в случае если он не лицензиат ФСБ) обязательными требованиями ФСБ России будет только Приказ 378. ПКЗ-2005, Приказ ФАПСИ 152 будут носить только рекомендательный характер.
Приказ 378 говорит о том, что если для защиты ПДн применяется СКЗИ, то они должны быть сертифицированы и по соответствующему классу. Таким образом, нормативка ФСБ не обязывает использовать для взаимодействия с ЦБ серт. СКЗИ и тем более СКАД Сигнатуру (требования по обеспечению конфиденциальности ПДн при передаче могут быть закрыты использованием спец. операторов связи).
В тоже время, для банка обязательными будут требования нормативных документов Банка России и договора с МЦИ.
Нормативка ЦБ (552-П) не определяет конкретное СКЗИ, а говорит лишь о том, что оно должно правильно использоваться.
Договор в свою очередь уточняет какое конкретно СКЗИ должно использоваться.
(2) Технические возможности.
Говоря о совместимости сертифицированных СКЗИ, помимо реализации базовых рекомендованных криптоалгоритмов (ГОСТ Р 34.10-2012 и т.д.) следует также учитывать то, каким рекомендациям ТК26 СКЗИ соответствует. Например, как вырабатываеться общий ключ при шифровании файлов при передаче между абонентами (например, СХЕМЫ ВЫРАБОТКИ ОБЩЕГО КЛЮЧА С АУТЕНТИФИКАЦИЕЙ
НА ОСНОВЕ ОТКРЫТОГО КЛЮЧА). Если СКЗИ используют разные схемы, то они будут между собой не совместимы.
Говорить о совместимоти только на основании обработки «хитрого» OID на мой взгляд не совсем корректно. Так как OID это всего лишь параметр в сертификате.
Но скорее всего, учитывая то, что Валидата КС и СКАД Сигнатура одного производителя, то они предположительно совместимы между собой.
И еще, если мы говорим про альтернативы, почему бы тогда не рассмотреть VIPNET CSP? Он тоже сертифицированный, да и к тому же бесплатный. Ну или например, КриптоПРО HSM — он секъюрный.
(3) Альтернативы ЦБ
Договор, есть договор. Чем руководствовалось ЦБ при его написании известно только ЦБ. Предлагаю исключить это из дальнейшего рассуждения.
Если Валидата КС станет называться СКАД Сигнатура, то ЦБ должен будет ее всем раздать и получить взамен Акты готовности с новыми хэщ-суммами.
Если измениться название СКЗИ, то вносить изменение в договор, а ЦБ может это сделать в одностороннем порядке со всему дальнейшими процедурами — организацией перехода, раздачи СКЗИ и т.д.
(1) Законодательная база
Закон иного мнения. Нормативка по СКЗИ определяет алгоритм, наличие лицензий у разработчика и сертификацию ПО.
Начнем с того, что разработчик, имеющий лицензию ФСБ России на разработку криптосредств сертифицировать свою продукцию не обязан. Делает это он лишь для того, чтобы его криптосредства могли использоваться в тех случаях, когда есть требование по использованию сертифицированных криптосредств.
Для банка как для коммерческой организации (в случае если он не лицензиат ФСБ) обязательными требованиями ФСБ России будет только Приказ 378. ПКЗ-2005, Приказ ФАПСИ 152 будут носить только рекомендательный характер.
Приказ 378 говорит о том, что если для защиты ПДн применяется СКЗИ, то они должны быть сертифицированы и по соответствующему классу. Таким образом, нормативка ФСБ не обязывает использовать для взаимодействия с ЦБ серт. СКЗИ и тем более СКАД Сигнатуру (требования по обеспечению конфиденциальности ПДн при передаче могут быть закрыты использованием спец. операторов связи).
В тоже время, для банка обязательными будут требования нормативных документов Банка России и договора с МЦИ.
Нормативка ЦБ (552-П) не определяет конкретное СКЗИ, а говорит лишь о том, что оно должно правильно использоваться.
Договор в свою очередь уточняет какое конкретно СКЗИ должно использоваться.
(2) Технические возможности.
Говоря о совместимости сертифицированных СКЗИ, помимо реализации базовых рекомендованных криптоалгоритмов (ГОСТ Р 34.10-2012 и т.д.) следует также учитывать то, каким рекомендациям ТК26 СКЗИ соответствует. Например, как вырабатываеться общий ключ при шифровании файлов при передаче между абонентами (например, СХЕМЫ ВЫРАБОТКИ ОБЩЕГО КЛЮЧА С АУТЕНТИФИКАЦИЕЙ
НА ОСНОВЕ ОТКРЫТОГО КЛЮЧА). Если СКЗИ используют разные схемы, то они будут между собой не совместимы.
Говорить о совместимоти только на основании обработки «хитрого» OID на мой взгляд не совсем корректно. Так как OID это всего лишь параметр в сертификате.
Но скорее всего, учитывая то, что Валидата КС и СКАД Сигнатура одного производителя, то они предположительно совместимы между собой.
И еще, если мы говорим про альтернативы, почему бы тогда не рассмотреть VIPNET CSP? Он тоже сертифицированный, да и к тому же бесплатный. Ну или например, КриптоПРО HSM — он секъюрный.
(3) Альтернативы ЦБ
Так что пунктики про именно «Сигнатуру» могут быть от отсутствия альтернативы на момент написания шаблона.
Договор, есть договор. Чем руководствовалось ЦБ при его написании известно только ЦБ. Предлагаю исключить это из дальнейшего рассуждения.
А если завтра разработчик сервер «Сигнатурой» назовет? Или СКАД назовет «Валидата»? Уточните в ЦБ, что в этом случае делать!?!?
Если Валидата КС станет называться СКАД Сигнатура, то ЦБ должен будет ее всем раздать и получить взамен Акты готовности с новыми хэщ-суммами.
Если измениться название СКЗИ, то вносить изменение в договор, а ЦБ может это сделать в одностороннем порядке со всему дальнейшими процедурами — организацией перехода, раздачи СКЗИ и т.д.
Слайд с презентации ЦБ
Способы формирования и простановки КА/ЗК
1. «Встраивание» СКЗИ в ПО АС клиента
2. Разработка промежуточного ПО между АС клиента и ПК обеспечения электронного обмена вместо ПС КБР
3. Использование Криптографического сервера разработки ООО «Валидата»
Если раньше надо было взломать АРМ КБР и незаметно подменить реквизиты в файле перед подписьюЧтобы подменить реквизиты в файле, не нужно было взламывать АРМ КБР. Целью атаки являлся канал.
Больше напоминает перераспределение ответственности.Именно так. Представители ЦБ нам прямо сказали, что ЦБ не собирается отвечать за действия, происходящие вне его контроля. Собственно, это единственная причина появления АРМ КБР-Н. Остальные плюшки (отсутствие ручного ввода и, следовательно, нет необходимости его поддерживать, повышение защищенности платежной системы в целом) идут бонусом.
Видимо, чтобы не подставлять некоторые крупные банки, АБС которых всё ещё не может подписывать посылки в АРМ КБР
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка