Главная страница категории

Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.

Перейти на страницу

Вопрос о доверенном статусе для SaaS-продуктов — один из наиболее частых и наименее однозначных. Распространённое заблуждение: SaaS не может получить доверенный статус, потому что работает «в облаке» и не устанавливается на компьютер пользователя. Это неверно. Постановление № 1937 не содержит ограничений по модели распространения программного обеспечения. Получить доверенный статус для SaaS-продукта можно — но с рядом принципиальных условий, которые нужно выполнить. Главное из них касается инфраструктуры: она должна быть российской. Всё остальное — вопрос технической и юридической подготовки.

Почему SaaS может получить доверенный статус

Постановление № 1937 оперирует понятием «программное обеспечение» без разграничения по модели распространения. Требования к доверенному статусу — российский контроль над правообладателем, наличие реестровой записи, совместимость с доверенными ОС, соответствие требованиям информационной безопасности — не содержат слов «только коробочное» или «только локально устанавливаемое».

Практика включения SaaS-продуктов в реестр российского ПО существует с момента его создания. Для таких продуктов в реестре предусмотрен специальный признак «программное обеспечение как услуга». Наличие такой записи является необходимым предварительным условием для получения доверенного статуса — как и для любого другого программного продукта.

Ключевое условие: российская инфраструктура

Это требование является определяющим для SaaS при оценке возможности получения доверенного статуса. Если серверная инфраструктура, на которой работает продукт, размещена за пределами России или использует иностранные облачные сервисы как неотъемлемые компоненты — это создаёт принципиальную проблему.

Российские дата-центры и облака

Инфраструктура размещена в российских дата-центрах или на мощностях российских облачных провайдеров — Яндекс Облако, VK Cloud, Selectel, МТС Облако, Сбер Облако и других. Данные обрабатываются и хранятся на территории России. Это соответствует требованиям.

Собственная серверная инфраструктура в России

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

🔴

Иностранные облачные провайдеры

AWS, Google Cloud, Azure, иные иностранные облачные платформы — размещение на них создаёт принципиальную проблему. Данные обрабатываются за пределами российской юрисдикции, инфраструктура находится под иностранным контролем. Это препятствие для получения доверенного статуса.

⚠️

Гибридная инфраструктура

Часть компонентов на российской инфраструктуре, часть — на иностранной. Требует детального анализа: что именно обрабатывается на иностранной инфраструктуре, является ли это неотъемлемой частью продукта или дополнительным сервисом. Каждый случай оценивается индивидуально.

Как проверяется совместимость с доверенными ОС для SaaS

Требование о совместимости с двумя доверенными операционными системами для SaaS интерпретируется иначе, чем для десктопного или серверного ПО. Клиентская часть SaaS-продукта — это браузерное приложение, работающее на устройстве пользователя. Именно это и является объектом проверки совместимости.

1

Совместимость клиентской части с доверенными ОС

Центр тестирования устанавливает доверенные ОС — Astra Linux, РЕД ОС и другие из актуального перечня. На них запускается доверенный браузер и проверяется работоспособность web-интерфейса SaaS-продукта. Вся заявленная функциональность должна корректно работать в этой среде: загрузка, отображение интерфейса, выполнение операций, работа с данными.

2

Доверенный браузер как точка тестирования

Тестирование проводится в доверенном браузере, включённом в перечень Минцифры. По состоянию на начало 2026 года это Яндекс Браузер для организаций. Продукт должен корректно работать именно в этом браузере — несовместимость с конкретной версией доверенного браузера является замечанием при экспертизе.

3

Серверная часть и её взаимодействие с тестовой средой

Центр тестирования взаимодействует с реальной серверной инфраструктурой продукта. Для экспертизы предоставляется тестовый стенд или тестовый экземпляр продукта, в котором воспроизводится полная функциональность. Изолированное тестовое окружение на российской инфраструктуре — стандартная практика.

Специфика проверки информационной безопасности для SaaS

Блок информационной безопасности при экспертизе SaaS-продукта имеет свою специфику по сравнению с локально устанавливаемым ПО. Ряд аспектов проверяется более пристально — именно потому, что данные пользователей обрабатываются на инфраструктуре правообладателя, а не на оборудовании заказчика.

Аспект безопасности Что проверяется Специфика для SaaS
Хранение данных Где физически хранятся данные пользователей Только Россия — иностранные юрисдикции недопустимы
Передача данных Каналы передачи, шифрование, внешние соединения Передача данных за пределы России должна быть задокументирована и обоснована
Разграничение доступа Изоляция данных разных клиентов (tenants) Мультитенантная архитектура требует подтверждения надёжной изоляции
Аутентификация Механизмы входа, MFA, управление сессиями Повышенные требования — критичность компрометации аккаунта выше
Журналирование Логирование действий пользователей и администраторов Государственные заказчики требуют возможности аудита действий в системе
Зависимости иностранных сервисов CDN, аналитика, внешние API Иностранные сервисы как неотъемлемые компоненты — замечание при экспертизе

Частые технические проблемы SaaS-продуктов при экспертизе

По практике сопровождения SaaS-разработчиков через реестровые процедуры одни и те же технические проблемы встречаются регулярно. Знание этих точек риска позволяет устранить их до экспертизы.

⚠️
Иностранные CDN для статических ресурсов

Интерфейс продукта подгружает JS-библиотеки, шрифты или изображения с иностранных CDN — Cloudflare, jsDelivr, Google Fonts. При работе в изолированной тестовой среде без доступа к иностранным ресурсам интерфейс не загружается или работает некорректно. Решение: хостинг всех ресурсов на собственной российской инфраструктуре.

⚠️
Иностранные сервисы аналитики и мониторинга

Google Analytics, Sentry, Datadog, иностранные сервисы ошибок и метрик встроены в продукт как неотъемлемые компоненты. Они устанавливают соединения с иностранными серверами. Решение: замена на российские аналоги или собственную инфраструктуру, полное отключение внешней телеметрии.

⚠️
Несовместимость с доверенным браузером

Интерфейс разрабатывался под Chrome или Firefox актуальных версий. Яндекс Браузер для организаций может иметь иные версии движка, иные политики безопасности. Специфические CSS, WebGL или API могут работать иначе. Решение: тестирование именно в доверенном браузере до официальной экспертизы.

⚠️
Мультитенантная архитектура без подтверждённой изоляции

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

Если инфраструктура сейчас иностранная: что делать

SaaS-продукты, работающие на иностранной облачной инфраструктуре, могут получить доверенный статус после миграции на российскую инфраструктуру. Это реальная задача — многие российские SaaS-компании прошли аналогичный путь после 2022 года в рамках деофшоризации и перехода на российские облака.

1

Аудит зависимостей от иностранной инфраструктуры

Инвентаризация всех компонентов, использующих иностранную инфраструктуру: хостинг серверной части, объектное хранилище, очереди сообщений, базы данных, CDN, внешние API. Для каждого компонента — оценка наличия российского аналога и сложности миграции.

2

Выбор российского облачного провайдера

Яндекс Облако, VK Cloud, Selectel, МТС Облако, Сбер Облако, облака операторов связи — рынок российских облачных провайдеров развит. Выбор зависит от архитектурных требований, набора управляемых сервисов, регионального присутствия и ценовых условий.

3

Миграция инфраструктуры

Последовательная или параллельная миграция компонентов на российскую инфраструктуру. Срок зависит от сложности архитектуры — от нескольких недель для простых продуктов до нескольких месяцев для сложных мультисервисных систем. Миграцию нужно завершить до начала официальной процедуры получения доверенного статуса.

4

Получение или актуализация реестровой записи

После миграции — проверка реестровой записи или получение новой. Запись должна отражать актуальную инфраструктуру и функциональность продукта. Только после этого можно подавать заявление на доверенный статус.

Вопросы о доверенном статусе для SaaS

Наш SaaS работает на Яндекс Облаке — этого достаточно для соответствия требованиям по инфраструктуре?

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

SaaS с мобильным приложением — как проверяется совместимость с доверенными ОС?

Если у SaaS-продукта есть мобильное приложение — оно рассматривается как отдельный клиент. Основной объект проверки совместимости для SaaS — браузерная клиентская часть на доверенной ОС в доверенном браузере. Нативное мобильное приложение на Android или iOS является дополнительным каналом доступа, специфика его проверки зависит от того, как именно оно заявлено в реестровой записи. Этот вопрос требует индивидуального анализа.

Мы предоставляем SaaS по модели подписки — как это влияет на 44-ФЗ и 223-ФЗ?

Модель подписки совместима с государственными закупками — государственные заказчики закупают доступ к SaaS-продуктам по 44-ФЗ и 223-ФЗ. Доверенный статус работает так же, как для коробочного ПО: при наличии конкурентов без статуса ваш продукт получает приоритет. На практике государственные заказчики всё активнее переходят на SaaS-модели, и наличие доверенного статуса становится конкурентным преимуществом в этом сегменте.

Часть функциональности нашего SaaS использует API иностранного сервиса — это блокирует получение статуса?

Зависит от характера использования. Если иностранный API является неотъемлемой частью основной функциональности продукта — это создаёт проблему: продукт функционирует с зависимостью от иностранного сервиса. Если это дополнительная интеграция, которую можно отключить без потери основной функциональности, — ситуация другая. В любом случае нужен технический аудит и оценка: насколько эта зависимость принципиальна, есть ли российские аналоги, как её можно задокументировать или устранить.

SaaS и доверенный статус — решаемая задача при правильной подготовке

Реестр Гарант сопровождает получение доверенного статуса для SaaS-продуктов — это специфический сегмент с собственными техническими и юридическими нюансами, который мы знаем хорошо. Начинаем с технического аудита инфраструктуры и клиентской части, оцениваем соответствие требованиям и составляем конкретный план подготовки. Если инфраструктура требует миграции — помогаем спланировать её параллельно с остальными подготовительными работами.

SaaS может получить доверенный статус при российской инфраструктуре
4–6 мес. срок получения при готовой инфраструктуре
95% наших клиентов проходят экспертизу с первого раза
от 190 000 ₽ сопровождение под ключ

Оценить возможность получения доверенного статуса для вашего SaaS

Расскажите об архитектуре продукта и инфраструктуре — оценим соответствие требованиям и составим план подготовки.

Телефон / WhatsApp / Telegram: +7 920-898-17-18

Email: reestrgarant@mail.ru

Первичная консультация бесплатная в рабочее время.