Comments 16
А можно вот эти все требования как-то хотя бы приблизительно оцифровать?
Предположим, есть некий совершенно частный бизнес, который почему-то очень хочет аутентификацию через ЕСИА внедрить. Естественно, никто в здравом уме не будет везде в продукте использовать ГОСТовское шифрование, размещать на аттестованных площадках и т.п. Соответственно, надо будет выделить какую-то подсистему, которую уже и аттестовать/сертифицировать/использовать в ней духовноскрепные СКЗИ. Во сколько на круг всё это может обойтись?
Второй вопрос. Подбираясь к тому, зачем вдруг частному бизнесу захотелось странного. Есть некая ИС, в которой пользователи авторизуются через ЕСИА и делают всякие полезные для них действия. Хочется пользователям помочь и автоматизировать эти действия, потому что руками кликать десятки кнопок и прикладывать десятки файлов и так по многу раз в день - боль и страдание, а все исходные данные, которые надо туда отправить, как раз в нашей системе. Реализовать заполнение формочек и нажатие кнопочек тривиально, а вот с ЕСИА вопросы. Если мы в своей системе аутентифицируем пользователя через ЕСИА - сможем мы от его имени залогиниться вот в эту стороннюю ИС и там свершить желаемое? Естественно, пользователю покажем, какие полномочия от его имени запрашиваем.
" Естественно, никто в здравом уме не будет везде в продукте использовать ГОСТовское шифрование, размещать на аттестованных площадках и т.п "
Отдельно подсистему аутентификации через ЕСИА вы не сможете выделить из ИС.
Ну я понимаю, что придётся как-то посложнее извратиться, но это уже детали. Скажем, будет подсистема "подача документов в ХХХ" (где ХХХ - та самая сторонняя окологосударственная ИС, в которую хочется попадать от имени пользователя).
На первоначальном этапе хочется понять, насколько это вообще решаемо и насколько подъёмно по деньгам.
Думаю, задачка-то очень популярная. Кому не хочется упростить пользователю взаимодействие с расплодившимися во множестве ГИСами?
Не получится. К любым системам, которые подключаются к ИС, взаимодействующей с ЕСИА, должны применяться те-же требования.
По деньгам - нужно смотреть инфраструктуру. Так Вам никто не ответит.
К любым системам, которые подключаются к ИС, взаимодействующей с ЕСИА, должны применяться те-же требования.
ОК, я аттестую систему, у которой есть некий 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 по сложности будет мало отличаться от взаимодействия напрямую с ЕСИА.
В рекомендациях нет чёткого указания на интеграцию через шлюз.
Есть рекомендации.
Если система использует СКЗИ сертифицированные по КС3, то ей никакой шлюз не нужен.
Шлюз нужен только для систем использующих СКЗИ сертифицированных по КС1.
Не знаю намеренно или нет так перевернули этот момент.
Но сдаётся мне это реклама своих ПАК для интеграции с ЕСИА.
По вашей же ссылке, аргументом в пользу покупки шлюза является не его прямая необходимость, а сложность аттестации площадки для соответствия требованиям КС3.
Аутентификация через ЕСИА: ключевые аспекты интеграции