Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Материал точно опровергал заблуждение «SaaS не может получить доверенный статус» и давал детальный разбор требований к инфраструктуре, специфике проверки совместимости и типичных технических проблем. Но описывал Яндекс Браузер как единственный официально закреплённый «доверенный браузер» — отдельного утверждённого реестра браузеров не существует. Уточняем этот момент, оставляем остальную техническую часть, убираем фразу о практике сопровождения и цены.
Главное: SaaS-продукт может получить доверенный статус — постановление №1937 не ограничивает механизм по модели распространения ПО. Определяющее условие: российская инфраструктура. Серверная часть должна быть размещена в российских дата-центрах или на мощностях российских облачных провайдеров, а не на иностранных платформах вроде AWS, Google Cloud или Azure. Совместимость с доверенными ОС для SaaS проверяется через клиентскую браузерную часть, работающую на доверенной операционной системе в поддерживаемом российском браузере.
| Утверждение из старой версии статьи | Реальное положение дел |
|---|---|
| «Тестирование проводится в доверенном браузере, включённом в перечень Минцифры. По состоянию на начало 2026 года это Яндекс Браузер для организаций» — как об официально закреплённом единственном варианте | Отдельного официального реестра доверенных браузеров не существует; требование заключается в поддержке российских браузеров как части общей проверки, Яндекс Браузер — самый распространённый практический кандидат, но не единственный официально закреплённый вариант |
| «По практике сопровождения SaaS-разработчиков через реестровые процедуры»; статистика «95%»; цена «от 190 000 ₽» | Доверенный статус существует с марта 2026 года, практики и статистики по нему быть не может; стоимость сопровождения не подтверждается официальными источниками |
Почему SaaS может получить доверенный статус
Постановление №1937 оперирует понятием «программное обеспечение» без разграничения по модели распространения: требования к доверенному статусу, среди которых российский контроль над правообладателем, наличие реестровой записи, совместимость с доверенными ОС и соответствие требованиям информационной безопасности, не содержат оговорок «только коробочное» или «только локально устанавливаемое». Практика включения SaaS-продуктов в реестр российского ПО существует с момента его создания — для таких продуктов предусмотрен специальный признак «программное обеспечение как услуга», наличие такой записи остаётся необходимым предварительным условием для доверенного статуса, как и для любого другого продукта.
Ключевое условие: российская инфраструктура
Это требование остаётся определяющим для SaaS при оценке возможности получения статуса: если серверная инфраструктура размещена за пределами России или использует иностранные облачные сервисы как неотъемлемые компоненты, возникает принципиальная проблема. Размещение в российских дата-центрах или на мощностях российских облачных провайдеров (Яндекс Облако, VK Cloud, Selectel, МТС Облако, Сбер Облако и других) соответствует требованиям, как и собственная серверная инфраструктура правообладателя, физически расположенная в России. Иностранные облачные провайдеры вроде AWS, Google Cloud или Azure создают принципиальное препятствие, поскольку данные обрабатываются за пределами российской юрисдикции, а инфраструктура находится под иностранным контролем. Гибридная инфраструктура, где часть компонентов работает на российских мощностях, а часть на иностранных, требует детального анализа каждого случая: важно, является ли иностранный компонент неотъемлемой частью продукта или дополнительным необязательным сервисом.
Как проверяется совместимость с доверенными ОС для SaaS
Требование о совместимости с двумя доверенными операционными системами для SaaS интерпретируется иначе, чем для десктопного или серверного ПО. Клиентская часть SaaS-продукта: браузерное приложение на устройстве пользователя, и именно оно становится объектом проверки. Центр тестирования разворачивает доверенные ОС из актуального перечня, запускает на них поддерживаемый российский браузер и проверяет работоспособность веб-интерфейса продукта: загружается ли приложение, корректно ли отображается интерфейс, выполняются ли основные операции и сохраняются ли данные без ошибок.
Проверка проводится в конкретном браузере, который согласовывается с центром тестирования. На практике это чаще всего Яндекс Браузер как самый распространённый российский браузер, но требование постановления сформулировано шире: как поддержка российских браузеров в целом, а не привязка к единственному названию. Продукт должен корректно работать именно в той версии браузера, которую использует центр при экспертизе, и несовместимость с ней фиксируется как замечание, поэтому конкретный браузер и его версию для тестирования разумно уточнить у центра заранее, а не полагаться на предположение. Серверная часть проверяется через тестовый стенд или тестовый экземпляр продукта на российской инфраструктуре, в котором воспроизводится полная функциональность. Изолированное тестовое окружение здесь стандартная практика.
Специфика проверки информационной безопасности для SaaS
| Аспект безопасности | Что проверяется | Специфика для SaaS |
|---|---|---|
| Хранение данных | Где физически хранятся данные пользователей | Только Россия — иностранные юрисдикции недопустимы |
| Передача данных | Каналы передачи, шифрование, внешние соединения | Передача данных за пределы России должна быть задокументирована и обоснована |
| Разграничение доступа | Изоляция данных разных клиентов (tenants) | Мультитенантная архитектура требует подтверждения надёжной изоляции |
| Аутентификация | Механизмы входа, MFA, управление сессиями | Повышенные требования — критичность компрометации аккаунта выше |
| Журналирование | Логирование действий пользователей и администраторов | Государственные заказчики требуют возможности аудита действий в системе |
| Зависимости иностранных сервисов | CDN, аналитика, внешние API | Иностранные сервисы как неотъемлемые компоненты — замечание при экспертизе |
Частые технические проблемы SaaS-продуктов при экспертизе
Иностранные CDN для статических ресурсов — частая проблема. Когда интерфейс подгружает JS-библиотеки, шрифты или изображения с иностранных CDN вроде Cloudflare, jsDelivr или Google Fonts, в изолированной тестовой среде без доступа к ним интерфейс не загружается или работает некорректно, а решение — хостинг всех ресурсов на собственной российской инфраструктуре. Иностранные сервисы аналитики и мониторинга, такие как Google Analytics, Sentry или Datadog, встроенные как неотъемлемые компоненты, устанавливают соединения с иностранными серверами. Решение — замена на российские аналоги или собственную инфраструктуру и полное отключение внешней телеметрии. Несовместимость с российским браузером возникает, когда интерфейс разрабатывался под Chrome или Firefox актуальных версий, а у выбранного для тестирования браузера иные версии движка и политики безопасности, из-за чего специфические CSS, WebGL или API работают иначе. Решение здесь одно: тестировать именно в целевом браузере до официальной экспертизы. Мультитенантная архитектура без подтверждённой изоляции требует детальной документации архитектуры — центр тестирования запрашивает архитектурное описание и может проверять изоляцию данных между клиентами на практике.
Если инфраструктура сейчас иностранная: что делать
SaaS-продукты на иностранной облачной инфраструктуре могут получить доверенный статус после миграции на российскую. Многие российские SaaS-компании прошли аналогичный путь после 2022 года в рамках деофшоризации и перехода на российские облака. Первый шаг — аудит зависимостей от иностранной инфраструктуры: инвентаризация всех компонентов (хостинг серверной части, объектное хранилище, очереди сообщений, базы данных, CDN, внешние API) с оценкой наличия российского аналога и сложности миграции для каждого. Второй шаг — выбор российского облачного провайдера в зависимости от архитектурных требований, набора управляемых сервисов и регионального присутствия. Третий — сама миграция, последовательная или параллельная, срок которой зависит от сложности архитектуры — от нескольких недель для простых продуктов до нескольких месяцев для сложных мультисервисных систем. Завершить её нужно до начала официальной процедуры получения статуса. Четвёртый — получение или актуализация реестровой записи после миграции, чтобы она отражала актуальную инфраструктуру и функциональность продукта.
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
SaaS работает на Яндекс Облаке — этого достаточно для соответствия требованиям по инфраструктуре?
Яндекс Облако — российский провайдер с инфраструктурой на территории России, что в целом соответствует требованиям, но одного факта размещения на российском облаке недостаточно для полного соответствия. Нужно убедиться, что данные обрабатываются в российских регионах провайдера без автоматической репликации в иностранные регионы, что сторонние сервисы, интегрированные в продукт, тоже соответствуют требованиям, и что нет неотъемлемых зависимостей от иностранных компонентов — это вопрос для отдельного технического аудита.
SaaS с мобильным приложением — как проверяется совместимость с доверенными ОС?
Мобильное приложение рассматривается как отдельный клиент. Основной объект проверки совместимости для SaaS — браузерная клиентская часть на доверенной ОС в поддерживаемом браузере. Нативное мобильное приложение на Android или iOS становится дополнительным каналом доступа, специфика его проверки зависит от того, как именно оно заявлено в реестровой записи, и требует индивидуального анализа.
SaaS предоставляется по модели подписки — как это влияет на 44-ФЗ и 223-ФЗ?
Модель подписки совместима с государственными закупками: государственные заказчики закупают доступ к SaaS-продуктам по 44-ФЗ и 223-ФЗ, а доверенный статус работает так же, как для коробочного ПО — при наличии конкурентов без статуса продукт получает приоритет. Государственные заказчики всё активнее переходят на SaaS-модели, и наличие доверенного статуса становится конкурентным преимуществом именно в этом сегменте.
Часть функциональности SaaS использует API иностранного сервиса — это блокирует получение статуса?
Зависит от характера использования. Если иностранный API — неотъемлемая часть основной функциональности, это создаёт проблему: продукт функционирует с зависимостью от иностранного сервиса. Если это дополнительная интеграция, которую можно отключить без потери основной функциональности, ситуация другая. В любом случае нужен технический аудит с оценкой, насколько эта зависимость принципиальна, есть ли российские аналоги и можно ли её задокументировать или устранить.
Источники
- КонсультантПлюс, порядок формирования перечня доверенного ПО: требования к SaaS-продуктам по постановлению №1937.
- Реестр российского программного обеспечения, Минцифры России: признак «программное обеспечение как услуга» в реестровой записи.
