Комментарии 15
А можно вот эти все требования как-то хотя бы приблизительно оцифровать?
Предположим, есть некий совершенно частный бизнес, который почему-то очень хочет аутентификацию через ЕСИА внедрить. Естественно, никто в здравом уме не будет везде в продукте использовать ГОСТовское шифрование, размещать на аттестованных площадках и т.п. Соответственно, надо будет выделить какую-то подсистему, которую уже и аттестовать/сертифицировать/использовать в ней духовноскрепные СКЗИ. Во сколько на круг всё это может обойтись?
Второй вопрос. Подбираясь к тому, зачем вдруг частному бизнесу захотелось странного. Есть некая ИС, в которой пользователи авторизуются через ЕСИА и делают всякие полезные для них действия. Хочется пользователям помочь и автоматизировать эти действия, потому что руками кликать десятки кнопок и прикладывать десятки файлов и так по многу раз в день - боль и страдание, а все исходные данные, которые надо туда отправить, как раз в нашей системе. Реализовать заполнение формочек и нажатие кнопочек тривиально, а вот с ЕСИА вопросы. Если мы в своей системе аутентифицируем пользователя через ЕСИА - сможем мы от его имени залогиниться вот в эту стороннюю ИС и там свершить желаемое? Естественно, пользователю покажем, какие полномочия от его имени запрашиваем.
" Естественно, никто в здравом уме не будет везде в продукте использовать ГОСТовское шифрование, размещать на аттестованных площадках и т.п "
Отдельно подсистему аутентификации через ЕСИА вы не сможете выделить из ИС.
Ну я понимаю, что придётся как-то посложнее извратиться, но это уже детали. Скажем, будет подсистема "подача документов в ХХХ" (где ХХХ - та самая сторонняя окологосударственная ИС, в которую хочется попадать от имени пользователя).
На первоначальном этапе хочется понять, насколько это вообще решаемо и насколько подъёмно по деньгам.
Думаю, задачка-то очень популярная. Кому не хочется упростить пользователю взаимодействие с расплодившимися во множестве ГИСами?
Не получится. К любым системам, которые подключаются к ИС, взаимодействующей с ЕСИА, должны применяться те-же требования.
По деньгам - нужно смотреть инфраструктуру. Так Вам никто не ответит.
К любым системам, которые подключаются к ИС, взаимодействующей с ЕСИА, должны применяться те-же требования.
ОК, я аттестую систему, у которой есть некий API (у любой нормальной системы есть API, иначе как с собственным фронтэндом-то общаться). Я без понятия, кто его будет использовать вообще. На момент аттестации - никто (ну кроме того самого собственного фронтэнда). А потом как получится.
А по стоимости - вообще говоря, в нормальном мире это должно быть бесплатно. Но имеем то, что имеем.
Вот тут приводят описание затрат на подключение в текущих реалиях…
По второму вопросу: технически - возможно, но с нюансами.
Как это выглядит:
Пользователь логинится в вашей системе через ЕСИА.
Вы получаете от ЕСИА access_token + refresh_token, иногда с дополнительными атрибутами (ФИО, СНИЛС и т.д.).
Однако, access_token, полученный вами, НЕЛЬЗЯ просто взять и использовать в сторонней ИС. Он выпущен для вашего client_id и для ваших callback-адресов.
Как вариант решения - проксирование действий пользователя через ваш backend.
- Пользователь аутентифицируется у вас через ЕСИА.
- Вы запрашиваете у пользователя согласие на выполнение действий (внутри вашего интерфейса).
- Через технического пользователя (согласованного с владельцем сторонней ИС), вы делаете действия от имени пользователя (подставляя его данные, но не от его имени формально).
ОК, понятно, буду разбираться. К сожалению, владелец сторонней ИС ничего не согласует - это 100%. Там либо государство (стена непробиваемая), либо присосавшаяся к государству коммерческая структура, которая за деньги продаёт своё решение для того же самого и отнюдь не мотивирована помогать конкурентам.
По деньгам - тоже довольно печально, больше 5 мультов за ИС. Малый бизнес - нет, не слышали, проходите мимо... Впрочем, там же альтернативное предложение "сэкономить" 3,5 мульта, воспользовавшись услугами посредника. Логично - всякий раз, когда государство создаёт бредовые невыполнимые требования, тут же возникают желающие создать за Вас видимость их исполнения, которая в силу закулисных договорённостей устроит регулятора, за свой скромный гешефт... ничего нового, но каждый раз зверски припекает от такого.
Каждый разработчик своего решения будет хвалить его и пугать всякими пугалками, в том числе финансовыми. Формально работа с ЕСИА требует аттестованную ИС на работу с ПДн. Эта аттестация по факту и без ЕСИА должна быть, т.к. ФЗ-115 никто не отменял. Остается использование сертифицированного СКЗИ (как пример КриптоПро, либо сертификация своего СКЗИ в ФСБ,ФСТЭК, наличие лицензий на разработку и тп. не наш вариант), оценка воздействия на СКЗИ. Тут есть нюансы в том, что если использовать библиотеки, уже имеющие оценку воздействия, то делать оценку своего софта, использующего эту библиотеку уже и не требуется. Насколько я понял, то вот криптопро пишет, что у их продукта Crypto JCP (для Java) уже есть оценка. Т.е. по факту покупаем лицензию на кропитопро и работает через Crypto JCP. Больше то ничего и не требуется. Ну а дальше бюрократия остаётся по регистрации участника и тп.
Не уверен, что эта схема законная. Все зависит от того, какие действия буду проводится.
Да элементарно. Есть некий ФГИС, в который надо заходить через авторизацию через Госуслуги и заполнять кучу идиотских отчётов по вопросам, в которые государству вообще свой нос не стóило бы совать. Но dura lex sed lex, заполняем. Родной портал ФГИСа кривой, косой, требует сертификатов Минцифры (которые ни один человек в здравом уме не установит) и заставляет пользователя заполнять кучу однотипной информации и прикладывать кучу файликов руками. Никакого API для взаимодействия с ФГИС, конечно же, нет. При этом есть наша система, в которой этот пользователь работает, и все исходные данные уже в ней имеются. Логично предложить пользователю опцию "автоматически подавать отчёты в ФГИС"? Логично.
Никакого API для взаимодействия с ФГИС, конечно же, нет.
(Вопросом заинтересованного обывателя)
Вроде бы сами Госуслуги для этого и были придуманы? Как хаб для пересылки разных бумажек из одной конторы в другую?
У некой ФГИС интеграция с ними есть, за компанию с авторизацией?
Тогда, наверное, шлем пачку документов через API Госуслуг с адресом назначения этой самой организации.
За компанию клиент в своем кабинете Госуслуг увидит, что он такой отчет посылал.
Я другую ситуацию имел в виду. Единственное, для чего ФГИС использует Госуслуги - для авторизации через ЕСИА, после чего пользователь работает на портале самого ФГИСа. Ну как в этой статье и описано для собственной системы, собственно.
Хотя доступ к API Госуслуг для простых смертных, если это вообще реально, - тоже интересная тема...
для этого придуман СМЭВ, просьба не путать.
Спасибо за статью
Не совсем понял про "Взаимодействие с ЕСИА будет осуществляться через шлюзовой модуль (API Gateway), доступный с 2025 года" - что изменяется с появлением данного модуля? Примеры кода приведены уже с его учетом или нет?
Если разбирались с этим вопросом, поясните пожалуйста в чем разница.
По некоторым источникам, шлюзовой модуль API Gateway Минцифры планирует к выпуску во втором квартале 2025 года (после завершения сертификационных процедур на соответствие требованиям по безопасности информации в отношении шлюзового модуля).
Из текущего описания не вполне ясен полный функционал, но можно сказать, что взаимодействие с API Gateway по сложности будет мало отличаться от взаимодействия напрямую с ЕСИА.
Аутентификация через ЕСИА: ключевые аспекты интеграции