Спасибо за важное замечание! Да, в нашем примере Telegram используется как пользовательский интерфейс — бот принимает файл, включая весь архив (подписанный документ и sig-файл), а саму проверку подписи выполняет локальный сервер с установленным КриптоАРМ Server. Вся логика и обработка чувствительных данных происходят внутри вашей инфраструктуры, и Telegram используется исключительно для передачи файла на этап проверки.
Тем не менее, если уровень конфиденциальности документа выше, чем может обеспечить публичный канал, такой как Telegram, — даже с учётом шифрования и ограниченного времени хранения файлов — сам факт передачи данных через внешнюю облачную платформу может противоречить политикам безопасности или регуляторным нормам (например, в случае с ПДн, КД и т.п.).
В таких случаях рекомендуется использовать полностью локальные решения для проверки ЭП — например, КриптоАРМ ГОСТ и другие офлайн-инструменты, работающие внутри закрытого контура, без необходимости передачи данных за пределы организации. Это обеспечит максимальный уровень безопасности и контроль над обработкой данных.
Спасибо за комментарий! Да, реализацию можно сделать по-разному — и с помощью bash, особенно если есть опыт и нужные инструменты.
Мы показали вариант для тех, кто не умеет готовить bash :) Такой подход проще в поддержке, не требует лезть в терминал и удобно встраивается в бизнес-процессы — особенно когда нужно быстро отдать задачу в техподдержку или передать её тем, кто не пишет код.
По некоторым источникам, шлюзовой модуль API Gateway Минцифры планирует к выпуску во втором квартале 2025 года (после завершения сертификационных процедур на соответствие требованиям по безопасности информации в отношении шлюзового модуля). Из текущего описания не вполне ясен полный функционал, но можно сказать, что взаимодействие с API Gateway по сложности будет мало отличаться от взаимодействия напрямую с ЕСИА.
Вот тут приводят описание затрат на подключение в текущих реалиях…
По второму вопросу: технически - возможно, но с нюансами.
Как это выглядит:
Пользователь логинится в вашей системе через ЕСИА.
Вы получаете от ЕСИА access_token + refresh_token, иногда с дополнительными атрибутами (ФИО, СНИЛС и т.д.).
Однако, access_token, полученный вами, НЕЛЬЗЯ просто взять и использовать в сторонней ИС. Он выпущен для вашего client_id и для ваших callback-адресов.
Как вариант решения - проксирование действий пользователя через ваш backend.
- Пользователь аутентифицируется у вас через ЕСИА.
- Вы запрашиваете у пользователя согласие на выполнение действий (внутри вашего интерфейса).
- Через технического пользователя (согласованного с владельцем сторонней ИС), вы делаете действия от имени пользователя (подставляя его данные, но не от его имени формально).
Спасибо за важное замечание! Да, в нашем примере Telegram используется как пользовательский интерфейс — бот принимает файл, включая весь архив (подписанный документ и sig-файл), а саму проверку подписи выполняет локальный сервер с установленным КриптоАРМ Server. Вся логика и обработка чувствительных данных происходят внутри вашей инфраструктуры, и Telegram используется исключительно для передачи файла на этап проверки.
Тем не менее, если уровень конфиденциальности документа выше, чем может обеспечить публичный канал, такой как Telegram, — даже с учётом шифрования и ограниченного времени хранения файлов — сам факт передачи данных через внешнюю облачную платформу может противоречить политикам безопасности или регуляторным нормам (например, в случае с ПДн, КД и т.п.).
В таких случаях рекомендуется использовать полностью локальные решения для проверки ЭП — например, КриптоАРМ ГОСТ и другие офлайн-инструменты, работающие внутри закрытого контура, без необходимости передачи данных за пределы организации. Это обеспечит максимальный уровень безопасности и контроль над обработкой данных.
Спасибо за комментарий! Да, реализацию можно сделать по-разному — и с помощью bash, особенно если есть опыт и нужные инструменты.
Мы показали вариант для тех, кто не умеет готовить bash :) Такой подход проще в поддержке, не требует лезть в терминал и удобно встраивается в бизнес-процессы — особенно когда нужно быстро отдать задачу в техподдержку или передать её тем, кто не пишет код.
По некоторым источникам, шлюзовой модуль API Gateway Минцифры планирует к выпуску во втором квартале 2025 года (после завершения сертификационных процедур на соответствие требованиям по безопасности информации в отношении шлюзового модуля).
Из текущего описания не вполне ясен полный функционал, но можно сказать, что взаимодействие с API Gateway по сложности будет мало отличаться от взаимодействия напрямую с ЕСИА.
Вот тут приводят описание затрат на подключение в текущих реалиях…
По второму вопросу: технически - возможно, но с нюансами.
Как это выглядит:
Пользователь логинится в вашей системе через ЕСИА.
Вы получаете от ЕСИА access_token + refresh_token, иногда с дополнительными атрибутами (ФИО, СНИЛС и т.д.).
Однако, access_token, полученный вами, НЕЛЬЗЯ просто взять и использовать в сторонней ИС. Он выпущен для вашего client_id и для ваших callback-адресов.
Как вариант решения - проксирование действий пользователя через ваш backend.
- Пользователь аутентифицируется у вас через ЕСИА.
- Вы запрашиваете у пользователя согласие на выполнение действий (внутри вашего интерфейса).
- Через технического пользователя (согласованного с владельцем сторонней ИС), вы делаете действия от имени пользователя (подставляя его данные, но не от его имени формально).