Доверенный статус для SaaS: три реальных сценария и когда это невозможно

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

Главное: постановление №1937 не содержит прямого запрета на доверенный статус для SaaS-продуктов, но требования создавались с расчётом на классическую модель распространения ПО, когда продукт устанавливается в инфраструктуре заказчика, а не работает на серверах разработчика. Для облачных продуктов это создаёт специфические сложности: интерпретацию требования совместимости с доверенными ОС применительно к клиентской части, обязательную локализацию данных государственных заказчиков на территории России по 149-ФЗ и 152-ФЗ, и необходимость разбирать все внешние зависимости на предмет того, какие из них касаются данных заказчиков.

Что именно создаёт трудности для SaaS

Для SaaS серверная часть работает на инфраструктуре разработчика, а не заказчика, поэтому требование совместимости с двумя доверенными операционными системами на практике интерпретируется применительно к клиентской части: web-интерфейс должен корректно работать через доверенные браузеры на доверенных ОС у пользователя, а серверная среда проверяется отдельно. Данные государственных заказчиков должны обрабатываться на серверах на территории России — если платформа использует зарубежные дата-центры или международные CDN для хранения и обработки данных, это серьёзное препятствие. Поскольку при SaaS-модели данные заказчика физически находятся на серверах разработчика, отдельно проверяются механизмы защиты, изоляция данных между разными клиентами и возможность полного удаления данных по требованию заказчика. Наконец, каждая зависимость от стороннего API, облачного сервиса или CDN иностранного провайдера становится предметом отдельной проверки — продукт, который не может работать без подключения к иностранному сервису, сталкивается с принципиальным препятствием.

Три реалистичных сценария для SaaS-продуктов

Первый сценарий — SaaS полностью на российской инфраструктуре, без иностранных зависимостей, с данными, не покидающими территорию России: это наиболее реалистичный путь к доверенному статусу, требующий документального подтверждения локализации данных. Второй — гибридная модель, когда продукт существует и как облачная версия, и как полнофункциональная on-premise версия для развёртывания в инфраструктуре заказчика: доверенный статус в этом случае получает именно on-premise версия, а это самая распространённая стратегия среди корпоративных B2B-разработчиков. Третий сценарий — чистый SaaS на зарубежных облачных платформах с архитектурно неотъемлемыми иностранными зависимостями: в текущей конфигурации доверенный статус недостижим, а миграция на российскую инфраструктуру с заменой зависимостей может занять от полугода до нескольких лет в зависимости от масштаба архитектурных изменений.

Большинство SaaS-продуктов накапливают иностранные зависимости органически, в процессе роста, а не по стратегическому решению: платёжный шлюз, почтовый сервис, CDN, система поддержки клиентов — типичный набор внешних интеграций. Для оценки шансов на доверенный статус критично разделить эти зависимости на два класса: те, что обрабатывают данные заказчиков (их придётся заменить на российские аналоги), и те, что не касаются данных государственных заказчиков напрямую (по ним можно предметно обсуждать допустимость). Эта граница устанавливается только при детальном техническом аудите конкретной архитектуры, а не по общему списку сервисов.

На какую российскую облачную инфраструктуру можно опираться

Отечественные облачные провайдеры — Яндекс Облако, SberCloud, МТС Cloud, Selectel — обеспечивают хранение и обработку данных на серверах в России, и работа на их инфраструктуре снимает базовый вопрос локализации данных. Но сам факт использования российского провайдера не гарантирует автоматического соответствия всем требованиям: если платформа при этом продолжает использовать иностранные CDN для статических ресурсов, зарубежные почтовые шлюзы или иностранные системы аналитики, каждая такая зависимость всё равно подлежит отдельной проверке при экспертизе.

Как выбрать стратегию, а не гадать заранее

Прежде чем принимать решение о миграции инфраструктуры или разработке отдельной on-premise версии, разумно провести инвентаризацию: какие внешние зависимости у продукта есть на самом деле, какие из них обрабатывают данные заказчиков, а какие технически заменимы без больших архитектурных изменений. Часто оказывается, что продукт ближе к первому сценарию (готовая российская инфраструктура), чем предполагала команда до аудита, — просто часть очевидно заменимых зависимостей никогда не пересматривалась за годы эксплуатации. И наоборот: то, что казалось второстепенной интеграцией, на поверку оказывается архитектурно неотъемлемым компонентом, требующим серьёзной переработки.

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

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: требования постановления №1937 применительно к архитектуре продукта.
• Реестр российского программного обеспечения, Минцифры России: базовые требования к продукции, включая облачные сервисы.