концентрация урансодержащих ионов составляет всего 3 мг на кубометр морской воды.
Факт 2.
акриловую пряжу, предварительно вымоченную в полимере, опускали в морскую воду с имитацией слабого течения. За один месяц удалось собрать 5 грамм закись-окись U308.
Вопрос
Cколько кубокиломентров воды «ученые» прогнали с помощью «слабого» течения сквозь пряжу??? Можно но ли считать этот гигантский поток слабым течением?
Подскажите в чем практический смысл данной библиотеки?
Если требуется российская криптография, то нужны сертифицированные СКЗИ. Если нужно просто шифрование (любое), то пользуются AES и Co под который миллиард библиотек и примеров.
При написании статьи, как всегда, пришлось сокращать объем. Но имеем то, что имеем.
Объем лучше не жать, лучше бить статьи по частям, на мой взгляд… то есть в моем аспекте :)
Если кто-то отлично справляется со своим делом и при этом ему надо обязательно считать, что земля плоская, пусть будет так, но не для всех, а только в его аспекте.
С одной стороны, вроде бы звучит здорово, но если сделать шаг дальше… Модель данных, обуславливает модели обработки данных: алгоритмы, потоки данных и т.д.
И тут возникает проблема (или вопрос):
Возьмем двух людей:
1-й — знает что форма Земли напоминает шар.
2-й — сторонник плоской Земли.
У первого есть алгоритм — построить путь кругосветного путешествия. Для второго подобный алгоритм не имеет смысла.
Получается что разбивка данных по аспектам, приводит и к последующей разбивки алгоритмов обработки?
То есть получается что на базе одной информационной системы мы получаем, n систем (где n — комбинаторное множество всех возможных аспектов данных)?
Если мое предположение верно то, как поддерживать все это многообразие?
Тема интересная, но подача материла сложная, а для читателя который сталкивается с темой впервые то и вовсе трудноусвояемая.
Очень много теоретических понятий, и мало практических примеров раскрывающих их «на пальцах». Желательно, после каждого блока понятий и абстракций приводить пример.
Вопрос по существу: «Кто формирует понятийный слой?»
Большинство людей с трудом формулируют свои мысли устно, не говоря уже о письменной речи. Тут же «модельер», то есть тот, кто формирует модель :) должен залезть в голову каждому конечному пользователю и выявить все нюансы. Если это делать разово — то это получится как обычная БД, если понятийный слой менять регулярно, то возникает вопрос квалификации и решения конфликтов восприятия…
Выглядит красиво, пока не вчитаешься. Не понятно на чем базируются рекомендации автора
Например,
Percival, 2009: AES-CTR с HMAC.
Latacora, 2018: KMS или XSalsa20+Poly1305
Тут происходит сравнение симметричных шифров с ассиметричной криптографией. AES — рекомендованный стандарт, прошел конкурс и т.д. XSalsa20 — просто «хороший» шифр, быстрый и т. д. Причем тут ассиметричный Poly1305 — непонятно.
Далее автор начинает прыгать через разные криптографические примитивы — шифрование токенов, шифрование API, нонсы и т.д. и пытается нацепить на все это одни требования, хотя задачи-то разные.
Скажите, если так все хорошо (на бумаге), то почему все так плохо (в реальности)?… И с каждым годом ситуация все хуже и хуже.
Информационная безопасность — это война, бесконечная война.
На ней бывают успехи, бывают неудачи. Когда люди долго занимаются одним и тем же, то многие вещи «замыливаются» и часто не хватает общего взгляда со стороны, для того чтобы объять всю проблему целиком.
Это исследование как раз и задумывалось, чтобы дать такой взгляд.
На ту проблему, что вы указали:
Пока безопасность не научится не мешать...
Это уже искусство. «Безопасникам» нужно научиться находить в защитных мерах баланс между достигаемых с их помощью безопасностью и создаваемыми от их реализации помехами в работе. Проблема усложнена тем, что многие специалисты, занимающиеся ИБ, подвержены догмам и пихают одни и те же подходы не учитывая специфики бизнеса, это и приводит к указанным вами конфликтам.
Собственно, ИБ и ставит своей целью мешать работать
Это неправильно ИБ.
Хорошее ИБ, как антивирус, должно быть невидимым, ловить «гадов», и в любой момент показать отчеты о своей деятельности. Хотя конечно, некоторый «дебаф» своей работой оно создавать будет.
Область применения стандарта PCI DSS, указывается в самом стандарте следующим образом: (русский перевод тут)
«Данный стандарт применяется для всех организаций, вовлеченных в обработку платежных карт: ТСП, процессинговых центров, эквайреров, эмитентов и поставщиков услуг, а также всех прочих организаций, которые хранят, обрабатывают или передают ДДК и (или) КАД.
…
Номер карты является определяющим фактором для ДДК» Примечание: ДДК — данные держателя карты.
Таким образом, обработка полного номера платежной карты является определяющим фактором отнесения информационной системы в зону действия стандарта PCI DSS.
Чтобы дальнейшая дискуссия была предметной предлагаю разбить рассуждения на пункты с которыми можно будет либо соглашаться либо дополнять /изменять.
(1) Законодательная база
Закон иного мнения. Нормативка по СКЗИ определяет алгоритм, наличие лицензий у разработчика и сертификацию ПО.
Начнем с того, что разработчик, имеющий лицензию ФСБ России на разработку криптосредств сертифицировать свою продукцию не обязан. Делает это он лишь для того, чтобы его криптосредства могли использоваться в тех случаях, когда есть требование по использованию сертифицированных криптосредств.
Для банка как для коммерческой организации (в случае если он не лицензиат ФСБ) обязательными требованиями ФСБ России будет только Приказ 378. ПКЗ-2005, Приказ ФАПСИ 152 будут носить только рекомендательный характер.
Приказ 378 говорит о том, что если для защиты ПДн применяется СКЗИ, то они должны быть сертифицированы и по соответствующему классу. Таким образом, нормативка ФСБ не обязывает использовать для взаимодействия с ЦБ серт. СКЗИ и тем более СКАД Сигнатуру (требования по обеспечению конфиденциальности ПДн при передаче могут быть закрыты использованием спец. операторов связи).
В тоже время, для банка обязательными будут требования нормативных документов Банка России и договора с МЦИ.
Нормативка ЦБ (552-П) не определяет конкретное СКЗИ, а говорит лишь о том, что оно должно правильно использоваться.
Договор в свою очередь уточняет какое конкретно СКЗИ должно использоваться.
(2) Технические возможности.
Говоря о совместимости сертифицированных СКЗИ, помимо реализации базовых рекомендованных криптоалгоритмов (ГОСТ Р 34.10-2012 и т.д.) следует также учитывать то, каким рекомендациям ТК26 СКЗИ соответствует. Например, как вырабатываеться общий ключ при шифровании файлов при передаче между абонентами (например, СХЕМЫ ВЫРАБОТКИ ОБЩЕГО КЛЮЧА С АУТЕНТИФИКАЦИЕЙ
НА ОСНОВЕ ОТКРЫТОГО КЛЮЧА). Если СКЗИ используют разные схемы, то они будут между собой не совместимы.
Говорить о совместимоти только на основании обработки «хитрого» OID на мой взгляд не совсем корректно. Так как OID это всего лишь параметр в сертификате.
Но скорее всего, учитывая то, что Валидата КС и СКАД Сигнатура одного производителя, то они предположительно совместимы между собой.
И еще, если мы говорим про альтернативы, почему бы тогда не рассмотреть VIPNET CSP? Он тоже сертифицированный, да и к тому же бесплатный. Ну или например, КриптоПРО HSM — он секъюрный.
(3) Альтернативы ЦБ
Так что пунктики про именно «Сигнатуру» могут быть от отсутствия альтернативы на момент написания шаблона.
Договор, есть договор. Чем руководствовалось ЦБ при его написании известно только ЦБ. Предлагаю исключить это из дальнейшего рассуждения.
А если завтра разработчик сервер «Сигнатурой» назовет? Или СКАД назовет «Валидата»? Уточните в ЦБ, что в этом случае делать!?!?
Если Валидата КС станет называться СКАД Сигнатура, то ЦБ должен будет ее всем раздать и получить взамен Акты готовности с новыми хэщ-суммами.
Если измениться название СКЗИ, то вносить изменение в договор, а ЦБ может это сделать в одностороннем порядке со всему дальнейшими процедурами — организацией перехода, раздачи СКЗИ и т.д.
Касательно контроля корректности встраивания СКАД Сигнатура в АРМ КБР.
Да, должно быть. Зона ответственности ЦБ. Поскольку именно он делал встраивание.
Документация на СКЗИ никак не договор
Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.
Если посмотреть на данный вопрос по другому. К вам пришла проверка и говорит (гипотетически): «Почему при работе АРМ КБР вы не соблюдаете требования док-ции СКЗИ „Вебра-OW?“. Ваш резонный ответ будет: „Договором обмена ЭС с МЦИ ЦБ РФ предусмотрено применение СКАД Сигнатура, а не Верба-OW“
Чему противоречит использование сертифицированного СКЗИ КС «Валидата» в соответствии с его формуляром?
Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.
Наказание за несоблюдение всегда интересная тема для дискуссии.
Приведу свои аргументы за то, что использование стороннего СКЗИ может послужить поводом к расторжению договора и отзыву лицензии.
Договор об обмене электронными сообщениями
при переводе денежных средств
в рамках платежной системы Банка России
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-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.
В комментарии выше я указывал на то, что в договоре явно прописано использование СКАД Сигнатуры.
Действительно в подписанном ЭС нет сведений о том, с помощью какого СКЗИ оно подписано и соответственно теоретически можно использовать любое другие средства подписи, хоть даже написать самому.
НО регуляторный риск (нарушение договора, нарушение 552-П) ставит на всем этом крест, слишком дорогие возможные последствия — расторжение договора с МЦИ / нарушение требований ЦБ -> отзыв лицензии.
В договоре с ЦБ прописана необходимость использования СКАД Сигнатуры и ПО для АРМ (это может быть АРМ КБР или другое ПО, предоставляемое ЦБ).
Договор об обмене электронными сообщениями
при переводе денежных средств
в рамках платежной системы Банка России
2.5. Для выполнения условий Договора Стороны применяют средство криптографической защиты информации «Система криптографической авторизации документов «Сигнатура»» (далее СКЗИ СКАД «Сигнатура»).
3.1.2. Заключает договор с Банком, в соответствии с которым получает от Банка:
— ПО для АРМ,
— СКЗИ.
В своих презентациях ЦБ упоминал про сервер «Валидаты», для того, чтобы его использовать нужно пере заключать договор.
Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись. См. Альбом УФЭБС и договор с ЦБ.
Про перенос ответственности вы это здорово подметили.
Я думаю проблема в том, что мы сейчас стали заложниками подхода ФСБ в части регулирования криптографии.
Сертифицированное криптоядро, например СКАД Сигнатура, это довольно «тяжелое» ПО, которое не может работать с другими криптоядрами и довольно глубоко встраиваться в систему (по крайней мере в ОС Windows). Сейчас нельзя например реализовать сертифицированное шифрование на том, же SQL, или скриптовых языках. Если бы это можно было могли бы появиться довольно элегантные решения, когда бы ЭП осуществлялась прямо SQL сервером, без лишних навесок.
Но что есть, то есть. Наверно решения ФСБ основываются на той информации и тех подходах которые нам неизвестны.
Факт 1.
Факт 2.
Вопрос
Cколько кубокиломентров воды «ученые» прогнали с помощью «слабого» течения сквозь пряжу??? Можно но ли считать этот гигантский поток слабым течением?
Если требуется российская криптография, то нужны сертифицированные СКЗИ. Если нужно просто шифрование (любое), то пользуются AES и Co под который миллиард библиотек и примеров.
Тут есть ссылки и про соц. инженерию и про преступные группы. Детальный анализ будет в следующих сериях.
Объем лучше не жать, лучше бить статьи по частям, на мой взгляд… то есть в моем аспекте :)
С одной стороны, вроде бы звучит здорово, но если сделать шаг дальше… Модель данных, обуславливает модели обработки данных: алгоритмы, потоки данных и т.д.
И тут возникает проблема (или вопрос):
Возьмем двух людей:
1-й — знает что форма Земли напоминает шар.
2-й — сторонник плоской Земли.
У первого есть алгоритм — построить путь кругосветного путешествия. Для второго подобный алгоритм не имеет смысла.
Получается что разбивка данных по аспектам, приводит и к последующей разбивки алгоритмов обработки?
То есть получается что на базе одной информационной системы мы получаем, n систем (где n — комбинаторное множество всех возможных аспектов данных)?
Если мое предположение верно то, как поддерживать все это многообразие?
Очень много теоретических понятий, и мало практических примеров раскрывающих их «на пальцах». Желательно, после каждого блока понятий и абстракций приводить пример.
Вопрос по существу: «Кто формирует понятийный слой?»
Большинство людей с трудом формулируют свои мысли устно, не говоря уже о письменной речи. Тут же «модельер», то есть тот, кто формирует модель :) должен залезть в голову каждому конечному пользователю и выявить все нюансы. Если это делать разово — то это получится как обычная БД, если понятийный слой менять регулярно, то возникает вопрос квалификации и решения конфликтов восприятия…
Например,
Percival, 2009: AES-CTR с HMAC.
Latacora, 2018: KMS или XSalsa20+Poly1305
Тут происходит сравнение симметричных шифров с ассиметричной криптографией. AES — рекомендованный стандарт, прошел конкурс и т.д. XSalsa20 — просто «хороший» шифр, быстрый и т. д. Причем тут ассиметричный Poly1305 — непонятно.
Далее автор начинает прыгать через разные криптографические примитивы — шифрование токенов, шифрование API, нонсы и т.д. и пытается нацепить на все это одни требования, хотя задачи-то разные.
Информационная безопасность — это война, бесконечная война.
На ней бывают успехи, бывают неудачи. Когда люди долго занимаются одним и тем же, то многие вещи «замыливаются» и часто не хватает общего взгляда со стороны, для того чтобы объять всю проблему целиком.
Это исследование как раз и задумывалось, чтобы дать такой взгляд.
На ту проблему, что вы указали:
Это уже искусство. «Безопасникам» нужно научиться находить в защитных мерах баланс между достигаемых с их помощью безопасностью и создаваемыми от их реализации помехами в работе. Проблема усложнена тем, что многие специалисты, занимающиеся ИБ, подвержены догмам и пихают одни и те же подходы не учитывая специфики бизнеса, это и приводит к указанным вами конфликтам.
Это неправильно ИБ.
Хорошее ИБ, как антивирус, должно быть невидимым, ловить «гадов», и в любой момент показать отчеты о своей деятельности. Хотя конечно, некоторый «дебаф» своей работой оно создавать будет.
«Данный стандарт применяется для всех организаций, вовлеченных в обработку платежных карт: ТСП, процессинговых центров, эквайреров, эмитентов и поставщиков услуг, а также всех прочих организаций, которые хранят, обрабатывают или передают ДДК и (или) КАД.
…
Номер карты является определяющим фактором для ДДК» Примечание: ДДК — данные держателя карты.
Таким образом, обработка полного номера платежной карты является определяющим фактором отнесения информационной системы в зону действия стандарта PCI DSS.
Подскажите, проверяли ли вы обнаружение антивирусами «вредоносного кода» упакованного более серьезными утилитами, например msfencode?
Если да, то насколько изменился процент обнаружения?
Поэтому в данном рассуждении я принял, что подписанный бумажный договор = заполненный типовой договор.
(1) Законодательная база
Начнем с того, что разработчик, имеющий лицензию ФСБ России на разработку криптосредств сертифицировать свою продукцию не обязан. Делает это он лишь для того, чтобы его криптосредства могли использоваться в тех случаях, когда есть требование по использованию сертифицированных криптосредств.
Для банка как для коммерческой организации (в случае если он не лицензиат ФСБ) обязательными требованиями ФСБ России будет только Приказ 378. ПКЗ-2005, Приказ ФАПСИ 152 будут носить только рекомендательный характер.
Приказ 378 говорит о том, что если для защиты ПДн применяется СКЗИ, то они должны быть сертифицированы и по соответствующему классу. Таким образом, нормативка ФСБ не обязывает использовать для взаимодействия с ЦБ серт. СКЗИ и тем более СКАД Сигнатуру (требования по обеспечению конфиденциальности ПДн при передаче могут быть закрыты использованием спец. операторов связи).
В тоже время, для банка обязательными будут требования нормативных документов Банка России и договора с МЦИ.
Нормативка ЦБ (552-П) не определяет конкретное СКЗИ, а говорит лишь о том, что оно должно правильно использоваться.
Договор в свою очередь уточняет какое конкретно СКЗИ должно использоваться.
(2) Технические возможности.
Говоря о совместимости сертифицированных СКЗИ, помимо реализации базовых рекомендованных криптоалгоритмов (ГОСТ Р 34.10-2012 и т.д.) следует также учитывать то, каким рекомендациям ТК26 СКЗИ соответствует. Например, как вырабатываеться общий ключ при шифровании файлов при передаче между абонентами (например, СХЕМЫ ВЫРАБОТКИ ОБЩЕГО КЛЮЧА С АУТЕНТИФИКАЦИЕЙ
НА ОСНОВЕ ОТКРЫТОГО КЛЮЧА). Если СКЗИ используют разные схемы, то они будут между собой не совместимы.
Говорить о совместимоти только на основании обработки «хитрого» OID на мой взгляд не совсем корректно. Так как OID это всего лишь параметр в сертификате.
Но скорее всего, учитывая то, что Валидата КС и СКАД Сигнатура одного производителя, то они предположительно совместимы между собой.
И еще, если мы говорим про альтернативы, почему бы тогда не рассмотреть VIPNET CSP? Он тоже сертифицированный, да и к тому же бесплатный. Ну или например, КриптоПРО HSM — он секъюрный.
(3) Альтернативы ЦБ
Договор, есть договор. Чем руководствовалось ЦБ при его написании известно только ЦБ. Предлагаю исключить это из дальнейшего рассуждения.
Если Валидата КС станет называться СКАД Сигнатура, то ЦБ должен будет ее всем раздать и получить взамен Акты готовности с новыми хэщ-суммами.
Если измениться название СКЗИ, то вносить изменение в договор, а ЦБ может это сделать в одностороннем порядке со всему дальнейшими процедурами — организацией перехода, раздачи СКЗИ и т.д.
Да, должно быть. Зона ответственности ЦБ. Поскольку именно он делал встраивание.
Договор определяет на какое конкретно СКЗИ необходимо пользоваться документацией.
Если посмотреть на данный вопрос по другому. К вам пришла проверка и говорит (гипотетически): «Почему при работе АРМ КБР вы не соблюдаете требования док-ции СКЗИ „Вебра-OW?“. Ваш резонный ответ будет: „Договором обмена ЭС с МЦИ ЦБ РФ предусмотрено применение СКАД Сигнатура, а не Верба-OW“
Смотря для каких целей. Если для реализации обмена ЭС с МЦИ ЦБ РФ, то соответствующему договору. Для других целей пожалуйста.
Приведу свои аргументы за то, что использование стороннего СКЗИ может послужить поводом к расторжению договора и отзыву лицензии.
Итого по расторжению договора:
1. Согласно договору СКЗИ — СКАД Сигнатура
2. Согласно Приложению 3 — Расчет хэш-сумм идет для СКАД Сигнатура
4. Согласно Приложению 6 — Банк оформляет сертификаты ключей для СКАД Сигнатура
3. Согласно Приложению 7 — СКЗИ должно устанавливать в соответствии с документацией на СКАД Сигнатуру
Таким образом, считаю что использование другого СКЗИ может быть основанием для Расторжения договора по пункту 9.5.4. или на основании п. 2.1. ст. 450 ГК РФ
Итого по отзыву лицензии:
Использование другого СКЗИ, вместо СКАД Сигнатуры будет нарушением п.2.4 552-П, в котором закреплено что банк должен соблюдать техническую документацию на СКЗИ, а в качестве СКЗИ договором закреплена СКАД Сигнатура.
Нарушение нормативных документов ЦБ, согласно п.6 ст. 20 Закона о банках и банковской деятельности может являться основанием для отзыва лицензии.
Действительно в подписанном ЭС нет сведений о том, с помощью какого СКЗИ оно подписано и соответственно теоретически можно использовать любое другие средства подписи, хоть даже написать самому.
НО регуляторный риск (нарушение договора, нарушение 552-П) ставит на всем этом крест, слишком дорогие возможные последствия — расторжение договора с МЦИ / нарушение требований ЦБ -> отзыв лицензии.
Пока это только «идеи» ЦБ. Для их реализации нужно перезаключать договор между Банком и ЦБ.
В своих презентациях ЦБ упоминал про сервер «Валидаты», для того, чтобы его использовать нужно пере заключать договор.
Банки не ставят ЗК, идет только простановка КА. ЗК — это технологическая мера, в то время как КА — электронная подпись. См. Альбом УФЭБС и договор с ЦБ.
Для шифрования должна использоваться только СКАД Сигнатура.
Я думаю проблема в том, что мы сейчас стали заложниками подхода ФСБ в части регулирования криптографии.
Сертифицированное криптоядро, например СКАД Сигнатура, это довольно «тяжелое» ПО, которое не может работать с другими криптоядрами и довольно глубоко встраиваться в систему (по крайней мере в ОС Windows). Сейчас нельзя например реализовать сертифицированное шифрование на том, же SQL, или скриптовых языках. Если бы это можно было могли бы появиться довольно элегантные решения, когда бы ЭП осуществлялась прямо SQL сервером, без лишних навесок.
Но что есть, то есть. Наверно решения ФСБ основываются на той информации и тех подходах которые нам неизвестны.