Политики оповещения | КриптоПро DSS

Политики оповещения | КриптоПро DSS ЭЦП
Содержание
  1. Блокировка устройства пользователя
  2. Криптопро | замена sms и push-уведомления при реализации требований 683-п и 684-п цб рф
  3. Назначение пользователю существующего мобильного устройства
  4. Обновление токена аутентификации simauth
  5. Оповещение операторов
  6. Оповещение пользователей
  7. Отключение оповещения обо всех событиях
  8. Отправка запроса к апплету на sim-карте
  9. Отправка запроса к апплету на обновление ключа аутентификации sim-карты
  10. Подтверждение адреса электронной почты пользователя
  11. Подтверждение номера телефона пользователя
  12. Получение qr-код с nonce
  13. Получение информации о ключах аутентификации mydss
  14. Получение информации о пользователе по идентификатору
  15. Получение результата выполнения запроса к апплету на sim-карте
  16. Примечание
  17. Сброс пароля пользователя
  18. Удаление вектора аутентификации пользователя
  19. Удаление всех векторов аутентификации mydss
  20. Повторная отправка кода активации на kinit
  21. Создание qr-кода с kinit
  22. Получение существующего qr-кода с kinit

Блокировка устройства пользователя

Пример запроса

Криптопро | замена sms и push-уведомления при реализации требований 683-п и 684-п цб рф

Политики оповещения | КриптоПро DSSЧем же заменить SMS и PUSH-уведомления при реализации кредитными и некредитными финансовыми организациями требований 683-П и 684-П ЦБ РФ?

Рассмотрим в рамках статьи два схожих и наиболее обсуждаемых пункта, опубликованных в один день на прошлой неделе  положений ЦБ РФ — 683-П и 684-П, оба от 17.04.2022.

Полностью эти положения называются так:

683-П: «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента».

684-П: «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций».

Оба положения устанавливают требования по защите информации для финансовых организаций, только 683-П распространяется на кредитные организации, а 684-П на некредитные.

ЭЦП:  Как бесплатно получить электронную подпись в ФНС после 1 июля 2021 года.- Контур.НДС

Далее по тексту будем пользоваться следующими сокращениями:

Рассмотрим наиболее значимые пукнты: в 683-П –  пункт 5.1, а в 684-П – пункт 10. 

683-П: «5.1. Кредитные организации должны обеспечивать подписание электронных сообщений способом, позволяющим обеспечить целостность и подтвердить составление указанного электронного сообщения уполномоченным на это лицом.

Признание электронных сообщений, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью, должно осуществляться в соответствии со ст. 6, 63-ФЗ «Об электронной подписи».

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

Признание электронных сообщений, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью, должно осуществляться в соответствии со статьей 6, 63-ФЗ «Об электронной подписи».

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

В настоящее время наибольшее количество дискуссий вызывает первый абзац рассматриваемого пункта. Экспертное сообщество по сути разделилось на два лагеря – одни эксперты говорят, что теперь финансовым организациям вместо использования уже привычных SMS и PUSH-уведомлений необходимо будет в обязательном порядке искать альтернативы, способные обеспечить целостность и авторство отправляемых электронных сообщений. Другие говорят, что можно будет остаться на SMS и PUSH, ограничившись небольшими доработками. Центральный банк пока же воздерживается от официальных комментариев по этому поводу.

Мы же, со своей стороны, не дожидаясь комментариев ЦБ РФ, предположим в нашей статье, что в соответствии с 683/684-П или по каким-то иным причинам, финансовым организациям придется искать альтернативу SMS и PUSH-уведомлениям.

Далее перейдем к анализу второго абзаца. Для этого обратимся к указанной в нем ст.6, 63-ФЗ (рассмотрим только пункты, относящиеся к обсуждаемому вопросу).

«Статья 6. Условия признания электронных документов (далее – ЭД), подписанных ЭП, равнозначными документам на бумажном носителе, подписанным собственноручной подписью

  1. Информация в электронной форме, подписанная КЭП признается ЭД, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством РФ, кроме случая, если ФЗ или принимаемыми в соответствии с ними НПА установлено требование о необходимости составления документа исключительно на бумажном носителе.
  2. Информация в электронной форме, подписанная ПЭП или НЭП, признается ЭД, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, в случаях, установленных ФЗ, принимаемыми в соответствии с ними НПА или соглашением между участниками электронного взаимодействия. НПА и соглашения между участниками электронного взаимодействия, устанавливающие случаи признания ЭД, подписанных НЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать порядок проверки электронной подписи. НПА и соглашения между участниками электронного взаимодействия, устанавливающие случаи признания ЭД, подписанных ПЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны соответствовать требованиям статьи 9 настоящего ФЗ».

Пойдем теперь по цепочке и рассмотрим пункты ст.9, 63-ФЗ, относящиеся к обсуждаемому вопросу:

«Статья 9. Использование ПЭП

  1. ЭД считается подписанным ПЭП при выполнении в том числе одного из следующих условий:
  2. 1) ПЭП содержится в самом ЭД;

    2) ключ ПЭП применяется в соответствии с правилами, установленными оператором ИС, с использованием которой осуществляются создание и (или) отправка ЭД, и в созданном и (или) отправленном ЭД содержится информация, указывающая на лицо, от имени которого был создан и (или) отправлен ЭД.

  3. НПА и (или) соглашения между участниками электронного взаимодействия, устанавливающие случаи признания ЭД, подписанных ПЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать, в частности:
  4. 1) правила определения лица, подписывающего ЭД, по его ПЭП;

    2) обязанность лица, создающего и (или) использующего ключ ПЭП, соблюдать его конфиденциальность».

И наконец, обратимся к определениям ПЭП, НЭП, КЭП в 63-ФЗ:

ПЭП является ЭП, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования ЭП определенным лицом.

НЭП является ЭП, которая:

1) получена в результате криптографического преобразования информации с использованием ключа ЭП;

2) позволяет определить лицо, подписавшее ЭД;

3) позволяет обнаружить факт внесения изменений в ЭД после момента его подписания;

4) создается с использованием средств ЭП.

КЭП является ЭП, которая соответствует всем признакам НЭП и следующим дополнительным признакам:

1) ключ проверки ЭП указан в квалифицированном сертификате;

2) для создания и проверки ЭП используются средства ЭП, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим ФЗ.

Подводя итоги, посмотрим, смогут ли все-таки финансовые организации продолжить использование SMS и PUSH уведомлений (по сути являющихся реализацией ПЭП. Из определения ПЭП и положений ст.9, 63-ФЗ следует, что это маловероятно. Если факт составления указанного электронного сообщения уполномоченным на это лицом (авторство) еще можно как-то доказать, прописав в соответствующих соглашениях, то обеспечить целостность средствами ПЭП без применения криптографических средств, практически невозможно. Даже по определению ПЭП – обеспечение целостности не ее задача.

Остается либо использовать НЭП, либо КЭП. В данном случае, при выборе между НЭП и КЭП есть всем известные за и против. Но в любом случае рекомендуем использовать именно сертифицированные ФСБ средства ЭП (в случае с КЭП это обязательное условие), т.к. их использование существенно снижает риски организации по оспариванию подписи клиентом, в том числе в суде. При этом, в случае, если  организацией будет использоваться НЭП, ей потребуется подписать со своими клиентами соответствующее соглашение, устанавливающее случаи признания ЭД, подписанных НЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью. Данное соглашение (в соответствии со ст.6, 63-ФЗ)  должно будет предусматривать порядок проверки электронной подписи, что не должно стать для  организации какой-то проблемой.

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

При этом и в случае с НЭП и в случае с КЭП — в качестве технических средств ЭП для решения поставленной задачи можно использовать, например, решение КриптоПро myDSS, которое представляет собой совместную разработку компаний КРИПТО-ПРО и SafeTech на базе программно-аппаратного комплекса облачной электронной подписи (ЭП) КриптоПро DSS и системы подтверждения электронных транзакций PayControl. На данный момент КриптоПро myDSS является единственным на рынке сертифицированным ФСБ решением, способным решить поставленную задачу. Подробнее о решении можно почитать тут.

Ну, и в заключение не очень приятный сюрприз. 683-П и 684-П официально опубликованы 21 мая и оба вступают в силу через 10 дней после опубликования, т.е. 1 июня 2022 года (за исключением некоторых пунктов, к которым п. 5.1 и п.10, соответственно, не относятся). Т.е. принимать соответствующие решения и переходить к реализации требований финансовым организациям формально нужно уже сейчас.

Павел Луцик

директор по продажам и развитию бизнеса

ООО «КРИПТО-ПРО»

Назначение пользователю существующего мобильного устройства

Пример запроса

Обновление токена аутентификации simauth

UpdateSimAuthToken

Пример запроса

Пример ответа

Оповещение операторов

Примечание

Для редактирования политики оповещения Операторов следует указывать параметр -Type Operator
и > НЕ использовать параметр –GroupId <ID группы>.

Получение политики оповещения Операторов

# Получение глобальной политики:
Get-DssNotificationPolicy -Type Operator
# Если в выводе данной команды содержится AllowOverride = False,
# Оператор не сможет самостоятельно настраивать политику в своем 
# личном кабинете на веб-интерфейсе.

# Просмотр списка событий с указанием настроенных способов доставки для каждого события:
(Get-DssNotificationPolicy -Type Operator ).EventNotifiers

Настройка политики оповещения Операторов без возможности редактирования

Данный пример позволяет настроить оповещение Операторов. При этом Операторы НЕ могут
изменять список событий, о которых они получают оповещения.**

Оповещение пользователей

Получение политики оповещения Пользователей по уровням

Отключение оповещения обо всех событиях

Для того чтобы отключить оповещение обо всех событиях, необходимо указать флаг
AllNotificationEvents и в параметре Notifier передать пустой список типов оповещения.

Отправка запроса к апплету на sim-карте

SendSimAuthTokenMessage

Пример запроса

Отправка запроса к апплету на обновление ключа аутентификации sim-карты

SendSimAuthTokenChangeKeyMessage

Подтверждение адреса электронной почты пользователя

Метод используется, если не требуется отправка одноразового пароля.

Подтверждение номера телефона пользователя

Метод используется, если не требуется отправка одноразового пароля.

Получение qr-код с nonce

Пример запроса

Получение информации о ключах аутентификации mydss

Пример запроса

Получение информации о пользователе по идентификатору

Get

Пример запроса

Получение результата выполнения запроса к апплету на sim-карте

GetSimAuthTokenMessage

Пример запроса

Примечание

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

Если требование подтверждения контактной информации отключено, то код активации KInit будет отправлен
на указанный номер телефона или Email. Значения номера телефона или Email не заносятся в профиль пользователя.

Сброс пароля пользователя

ResetPassword

Пример запроса

Удаление вектора аутентификации пользователя

Пример запроса

Удаление всех векторов аутентификации mydss

Пример запроса

Повторная отправка кода активации на kinit

Примечание

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

Если требование подтверждения контактной информации отключено, то код активации KInit будет отправлен
на указанный номер телефона или Email. Значения номера телефона или Email не заносятся в профиль пользователя.

Пример запроса

Создание qr-кода с kinit

Примечание

Если настройками сервера отключено требование кодов активации KInit, то параметры Msisdn и Email игнорируются.

Примечание

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

Если требование подтверждения контактной информации отключено, то код активации KInit будет отправлен
на указанный номер телефона или Email. Значения номера телефона или Email не заносятся в профиль пользователя.

Пример запроса

Получение существующего qr-кода с kinit

Пример запроса

Оцените статью
ЭЦП64