Требования к серверной инфраструктуре и размещению данных

В какой-то момент любая команда, которая готовится к включению в реестр, сталкивается с вопросом инфраструктуры. Особенно остро это проявляется у SaaS-продуктов, но на самом деле касается практически всех современных систем. Потому что сегодня программное обеспечение редко существует «в вакууме» — оно всегда связано с серверами, базами данных, облачными платформами и внешними сервисами. И именно здесь начинается зона повышенного внимания со стороны экспертизы.

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

На что обращают внимание в заявке

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

Самая распространённая ошибка — формулировка «мы используем облако». С точки зрения экспертизы это ничего не объясняет. Облако — это просто модель. Важно: чьё это облако, где оно расположено, на каких условиях используется и кто имеет доступ к управлению.

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

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

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

Архитектурное описание

Этот раздел напрямую связан с архитектурным описанием, о котором мы говорили ранее. Потому что инфраструктура — это физическое отражение архитектуры. И если между этими разделами есть несоответствия, это сразу вызывает вопросы.

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

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

И если вы сомневаетесь, соответствует ли ваша инфраструктура требованиям — лучше разобраться с этим до подачи заявки. Потому что этот блок гораздо проще скорректировать на этапе подготовки, чем объяснять уже в процессе экспертизы.

Далее мы перейдём к частному, но очень популярному кейсу — мобильным приложениям и их включению в реестр.