Цифровые закупки для образования: какие требования возникают к безопасности платформы

47 минут назад

© Изображение сгенерировано нейросетью

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

Для журнала RUБЕЖ тему прокомментировали Михаил Болдырев — директор Центра проектной деятельности и коммуникационных технологий РГГУ, научный руководитель АНО «Национальный центр платформенной экономики»; Лилия Ежова — кандидат экономических наук, доцент кафедры бизнес-информатики факультета информационных технологий и анализа больших данных Финансового университета при Правительстве РФ; Юлия Бузыкова — доцент кафедры информационных технологий факультета информационных технологий и анализа больших данных Финансового университета при Правительстве РФ.

Прозрачность условий сделки

По словам Болдырева, с 1 октября 2026 года постановление Правительства РФ № 1279 распространило на маркетплейсы, участвующие в эксперименте по образовательным закупкам, требования к электронным площадкам по постановлению № 656 — с отдельными исключениями.

Среди них эксперт выделяет класс защищенности не ниже второго, аттестацию площадки, применение электронной подписи, учёт действий участников и хранение подписанных данных не менее десяти лет.

«В отличие от обычного маркетплейса, здесь требуется обеспечить доказуемость не только самой сделки, но и условий, на которых она совершалась», — отметил Болдырев.

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

Усиленный контроль критичных операций

Эксперты сходятся во мнении, что наиболее рискованные изменения касаются банковских реквизитов, цен, характеристик товаров, сроков поставки и прав доступа пользователей.

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

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

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

В такой модели многофакторная аутентификация защищает доступ к системе, ролевая модель ограничивает полномочия пользователей, а журналирование позволяет восстановить последовательность действий и провести проверку.

Контроль изменений в карточках товаров

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

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

Бузыкова считает, что для этого необходимы версионирование карточек и контроль целостности данных.

«Карточки товаров, цены и условия поставки должны храниться с версионированием и контролем целостности через хеширование: любая правка оставляет след, который невозможно незаметно переписать», — пояснила Бузыкова.

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

Безопасность на этапе пилота

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

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

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

«Если эти механизмы добавить уже после масштабирования, придется перестраивать не только ИТ-систему, но и сами закупочные процессы», — отметила она.

Ранее RUБЕЖ рассказывал о фишинге под банки и маркетплейсы.