Информационные системы, уже подключенные к ЕСИА в соответствии с положениями Регламента версии 2.42 и ниже, могут продолжать применение действующих технических решений до 31 декабря 2026 года. При наступлении указанной даты все участники информационного взаимодействия обязаны применять техническое решение по реализации протокола OpenID Connect при взаимодействии с ЕСИА (создано в соответствии с техническим заданием, согласованным Минцифры России), а также прошедшее процедуру оценки влияния на выполнение предъявленных к СКЗИ требований.
Я правда думаю что срок перенесут, почти никто не готов будет.
За последние пару лет там всё сильно усложнилось, просто так не подключиться.
Во-первых, СКЗИ "КриптоПро CSP" нужен не абы какой, а в исполнении КС3. По требованиям формуляра там должен быть аппаратный модуль доверенной загрузки и замкнутая программная среда. Достаточно легко это настроить на Астре, на других ОС есть нюансы.
Во-вторых, для взаимодействия с ЕСИА нужно использовать либо одно из типовых решений (их по сути два и оба специфические), либо пройти процедуру оценки влияния среды функционирования на СКЗИ. Это полгода и 3-5 миллионов рублей.
Персоны - это простой, дешевый и быстрый метод, который приносит некоторую ограниченную пользу. Полноценные исследования (в том числе описанные в разделе "Что делать?") приводят к более качественному результату, но дольше и дороже.
Здесь не должно быть противопоставления, это методы из разных весовых категорий. В зависимости от ситуации на проекте можно использовать и тот, и другой.
Исследования лучше чем выдуманные из головы персоны, персоны лучше чем ничего.
Запрос №1 очень опасный. Если нет индекса по полю created_at, то будет sequence scan, что на большой таблице создаст нагрузку на систему. ORDER BY на больших таблицах надо с осторожностью использовать.
Не совсем понял про "Взаимодействие с ЕСИА будет осуществляться через шлюзовой модуль (API Gateway), доступный с 2025 года" - что изменяется с появлением данного модуля? Примеры кода приведены уже с его учетом или нет?
Если разбирались с этим вопросом, поясните пожалуйста в чем разница.
А меня пугает то что происходит в сообществе разработки ядра Linux. Процесс как-то движется вперед (а не тратит всё время на обсуждения и выяснение отношений) только на личном авторитете Торвальдса. Если он по какой-то причине перестанет участвовать в разработке ядра (bus-фактор никто не отменял) - вполне вероятен распад на несколько конкурирующих проектов и разруха.
Даже интересно стало что имели в виду авторы вопроса
Регламент ЕСИА, пункт 10.1:
Я правда думаю что срок перенесут, почти никто не готов будет.
За последние пару лет там всё сильно усложнилось, просто так не подключиться.
Во-первых, СКЗИ "КриптоПро CSP" нужен не абы какой, а в исполнении КС3. По требованиям формуляра там должен быть аппаратный модуль доверенной загрузки и замкнутая программная среда. Достаточно легко это настроить на Астре, на других ОС есть нюансы.
Во-вторых, для взаимодействия с ЕСИА нужно использовать либо одно из типовых решений (их по сути два и оба специфические), либо пройти процедуру оценки влияния среды функционирования на СКЗИ. Это полгода и 3-5 миллионов рублей.
Персоны - это простой, дешевый и быстрый метод, который приносит некоторую ограниченную пользу. Полноценные исследования (в том числе описанные в разделе "Что делать?") приводят к более качественному результату, но дольше и дороже.
Здесь не должно быть противопоставления, это методы из разных весовых категорий. В зависимости от ситуации на проекте можно использовать и тот, и другой.
Исследования лучше чем выдуманные из головы персоны, персоны лучше чем ничего.
Запрос №1 очень опасный. Если нет индекса по полю created_at, то будет sequence scan, что на большой таблице создаст нагрузку на систему. ORDER BY на больших таблицах надо с осторожностью использовать.
Спасибо за статью
Не совсем понял про "Взаимодействие с ЕСИА будет осуществляться через шлюзовой модуль (API Gateway), доступный с 2025 года" - что изменяется с появлением данного модуля? Примеры кода приведены уже с его учетом или нет?
Если разбирались с этим вопросом, поясните пожалуйста в чем разница.
А меня пугает то что происходит в сообществе разработки ядра Linux. Процесс как-то движется вперед (а не тратит всё время на обсуждения и выяснение отношений) только на личном авторитете Торвальдса. Если он по какой-то причине перестанет участвовать в разработке ядра (bus-фактор никто не отменял) - вполне вероятен распад на несколько конкурирующих проектов и разруха.
P.S. Недавно в блоге про это заметку писал: https://t.me/tnvblog/4
Не понял почему в заголовке ИЛИ.
Микросервисная архитектура - это с моей точки зрения про структуру системы, статика.
Событийно-ориентированная - про порядок взаимодействия, динамика.
Одно не исключает другого, эти вещи разного порядка.
Звучит как "вам яблоко большое или красное"
WSDL у вас выглядит неполным, не хватает binding и service
Даже интересно стало - что даст аналитику вдумчивое чтение 149-ФЗ. Если он не на госсектор работает, конечно.
Каналы из статьи в массе своей тоже правительственные
Вопрос только в том какой страны это правительство
Лично не использовал, поскольку не имею устройства на котором его можно запустить.
Под "интересное" имел в виду что общая логика приложения соответствует моему запросу и его стоило бы посмотреть. Другие похожие сильно дальше.
Статья интересна тем, что набор инструментов практически не пересекается с тем что использую я сам (и с тем что вижу вокруг). Есть о чем поразмыслить.
Ну не то чтобы прямо "здорового", но не жалуюсь :)
Что то смешались в одну кучу совершенно разные компании
Выручка Озона и выручка например Айтеко это две большие разницы
Лично видел систему где все суммы для оплаты в бюджет округлялись вверх - лучше переплатить полкопейки, чем потом доказывать что не верблюд.
Разные варианты бывают.
Неплохо бы для начала понять, а правильно ли с точки зрения бизнеса распределять погрешность округления по другим строкам.
Слышал разные точки зрения от бухгалтеров.
Написано интересно, но крайне раздражает привычка дробить и без того небольшие статьи ра части :(
Почему нельзя сразу мысль изложить до конца?
Похоже на раздел из руководства пользователя
Уточните пожалуйста, отдельный файл с миграциями именно на объект (например, таблицу)? То есть скрипты организованы по объектам, а не по версиям?
Обычно рекомендуют версионную организацию ченджсетов - на каждую версию системы создаётся файл x.y.z.xml, и в нём миграции этой версии.
Почему выбрали именно по-объектную модель?