Работа с госзаказчиком: какие требования прилетают к вашей инфраструктуре

MAATRIX

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

Локализация данных: где физически может стоять сервер

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

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

• Просто «данные должны обрабатываться на территории РФ» — самый частый и относительно мягкий вариант. Он закрывается размещением серверов у российского провайдера или в российском дата-центре без дополнительных требований к владельцу инфраструктуры.
• «Обработка на территории РФ у оператора, включённого в профильный реестр» — здесь важен не только физический адрес сервера, но и статус хостинг-провайдера: даёт ли он услуги как оператор, отвечающий определённым формальным критериям, или нет. Мы разбирали, что это меняет для клиента, в статье про реестр хостинг-провайдеров.
• «Обработка исключительно на инфраструктуре заказчика или на выделенном контуре» — самый строгий вариант, при котором облачная модель с общей инфраструктурой провайдера вообще не подходит, и разговор идёт про выделенные серверы или изолированный сегмент.

Отдельно стоит различать локализацию персональных данных и локализацию вообще всех данных по контракту — это разные по объёму требования. Первое регулируется отдельно и касается конкретно персональных данных граждан, если они вообще есть в контуре системы; подробно об этом писали в статье про локализацию баз ПДн. Второе — шире, это уже требование заказчика по контракту, которое может касаться любых данных системы независимо от того, персональные они или нет. На этапе оценки контракта нужно понять, идёт речь про первое, про второе или про оба сразу — от этого сильно зависит, сколько инфраструктуры придётся пересобирать.

Сертифицированные средства защиты информации

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

Для практики это означает несколько вещей сразу:

• Ваш привычный стек может не подойти как есть. Опенсорсный WireGuard или обычный iptables как единственная линия защиты периметра в контракте с таким требованием, скорее всего, не пройдёт — придётся ставить сертифицированный шлюз или криптомаршрутизатор поверх или вместо привычного решения.
• Сертифицированные СЗИ стоят денег и требуют лицензий. Это не разовая покупка — часто нужна поддержка вендора, продление сертификата актуальности версии, иногда отдельная лицензия на каждый узел или канал.
• Требования к квалификации персонала. Обслуживание некоторых категорий средств защиты подразумевает, что у компании или у конкретных сотрудников есть определённый допуск или лицензия на деятельность по защите информации — это отдельный организационный вопрос, который не решается покупкой оборудования.
• Совместимость с остальной архитектурой. Сертифицированный межсетевой экран может иначе вести себя под нагрузкой, иметь свои ограничения по пропускной способности и правилам маршрутизации — это нужно закладывать в архитектуру заранее, а не патчить постфактум.

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

Российское ПО из реестра в стеке инфраструктуры

Третья категория — требование использовать программное обеспечение, включённое в реестр российского ПО: операционные системы, СУБД, офисные пакеты, антивирусы, средства виртуализации. Мы подробно разбирали, что реестр даёт бизнесу и когда становится обязательным, в отдельной статье про реестр российского ПО — здесь остановимся именно на инфраструктурном срезе вопроса.

Для инженерной команды это выливается в несколько практических задач:

• Пересборка базового образа. Если система должна работать на отечественной ОС, а ваша команда годами разворачивала всё на Ubuntu или Debian, потребуется тестовый стенд, миграция плейбуков и проверка, что весь софтверный стек вообще совместим с целевым дистрибутивом.
• Замена компонентов среднего слоя. СУБД, брокеры сообщений, системы виртуализации из реестра могут вести себя иначе под нагрузкой, иметь другие лимиты и другую документацию — закладывайте время на нагрузочное тестирование заново, а не переносите старые цифры.
• Лицензионная схема. Реестровое ПО не обязательно бесплатное — модель лицензирования (по ядрам, по пользователям, по инстансам) нужно уточнять у поставщика заранее, потому что при масштабировании инфраструктуры расходы на лицензии могут вырасти сильнее, чем расходы на сами серверы.

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

Сетевая сегментация и изоляция контура обработки

Четвёртая категория — требования к архитектуре сети: разделение системы на изолированные сегменты по уровню критичности и типу обрабатываемых данных, с контролируемыми точками перехода между ними.

Типичный, сильно упрощённый пример такого разделения на уровне конфигурации:

# Пример логики сегментации на VLAN, упрощённо
# VLAN 10 — контур управления (доступ только с bastion-хоста)
# VLAN 20 — контур обработки данных заказчика
# VLAN 30 — DMZ с публичными сервисами
# VLAN 99 — контур мониторинга и логирования

iptables -A FORWARD -i vlan20 -o vlan30 -j DROP
iptables -A FORWARD -i vlan30 -o vlan20 -j DROP
iptables -A FORWARD -i vlan10 -o vlan20 -m state --state NEW -j LOG --log-prefix "MGMT-TO-DATA: "
iptables -A FORWARD -i vlan10 -o vlan20 -m state --state NEW -j ACCEPT

На практике заказчик обычно требует не конкретную реализацию, а результат: чтобы контур обработки данных был изолирован от общей корпоративной сети, чтобы доступ администраторов шёл через контролируемую точку входа (bastion, jump-host), чтобы публичные сервисы не имели прямой сетевой видимости во внутренний контур. Как именно это реализовано — на уровне VLAN, на уровне отдельных физических серверов, на уровне security groups в облаке — обычно остаётся на усмотрение исполнителя, если иное не прописано отдельно.

Практические грабли, которые здесь чаще всего недооценивают на этапе оценки контракта:

• Мониторинг и логирование — тоже отдельный сегмент. Если система логирования имеет доступ во все остальные сегменты сразу, это часто расценивается как нарушение изоляции, а не как удобство эксплуатации.
• Резервное копирование пробивает периметр, если о нём не подумать заранее. Бэкап-сервер, которому нужен доступ ко всем сегментам для снятия копий, — источник почти гарантированного вопроса на проверке, если этот доступ не ограничен и не залогирован отдельно.
• VPN-доступ подрядчиков и удалённых сотрудников нужно закладывать в схему сегментации с самого начала, а не пристраивать сбоку после того, как архитектура уже согласована с заказчиком.

Аттестация информационной системы: когда она возникает в контракте

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

Что важно понимать про аттестацию именно в контексте планирования инфраструктуры:

• Это не разовая проверка, а процесс с подготовкой. Аттестации предшествует формирование пакета организационно-технической документации, тестирование средств защиты, иногда — привлечение стороннего лицензиата, который имеет право проводить такие работы. Сама инфраструктура должна быть готова и стабильна к моменту начала процедуры, а не находиться в процессе доработки.
• Аттестация — это срок, который редко умещается в общий план проекта «как обычно». Если в контракте есть требование об аттестации системы, закладывайте на этот этап заметно больше времени, чем кажется на старте, и не ставьте его последним пунктом перед сдачей — переделки после первой итерации проверки случаются часто.
• Не каждая система требует аттестации, даже если работает на государственных данных. Необходимость этой процедуры, её объём и то, кто её проводит — заказчик своими силами, привлечённый лицензиат или ваша компания как исполнитель — определяется конкретными характеристиками системы и условиями контракта. Не стоит полагаться на опыт «в прошлый раз у похожего заказчика было так же»: формально похожие системы могут попадать в разные требования по аттестации в зависимости от конкретной документации.

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

Как оценить контракт на этапе тендера, чтобы не недооценить объём подготовки

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

Практический чек-лист, который стоит пройти ещё до того, как вы посчитали смету и сроки:

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

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

Частые вопросы