Выделенный сервер под аттестуемый контур: почему общее облако тут неудобно

MAATRIX

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

Что такое «граница системы» и почему это не формальность

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

Проблема общего облака в том, что граница получается размытой. Формально ваш контур — это виртуальная машина. Но под ней общий гипервизор, общая сеть провайдера, общая система хранения, к которым имеет доступ персонал провайдера и, возможно, его субподрядчики. Всё это по-хорошему тоже нужно как-то отразить в документации — либо ссылкой на аттестацию самого провайдера (если она вообще есть и покрывает нужный уровень), либо через дополнительные соглашения и заверения, которые проверяющий будет читать и задавать по ним вопросы.

На выделенном сервере граница рисуется одной линией: вот стойка, вот сетевой порт, вот диски — и дальше только вы. Меньше слоёв — меньше объяснений.

Что даёт выделенный или изолированный сервер

Здесь два варианта, и они не равнозначны:

Выделенный физический сервер (bare metal) — вы арендуете конкретную железку целиком. Нет гипервизора между вами и оборудованием, нет соседей в принципе. Граница системы совпадает с границей физического устройства.

Изолированная VPS с гарантированными ресурсами — компромисс, если бюджет не тянет физику. Ключевое отличие от обычной облачной VPS — отсутствие оверселлинга (ваши vCPU и память зарезервированы, а не разделены «по среднему»), собственный VLAN без общего L2-сегмента с другими клиентами, и по возможности — отдельный физический носитель или гарантия, что диск не переиспользуется без полной очистки. Это не полная физическая изоляция, но её достаточно, чтобы закрыть большинство вопросов из списка выше.

Что это даёт на практике, помимо ответов на вопросы аудита:

• Полный контроль над стеком — вы решаете, что стоит на уровне гипервизора (или его отсутствия), какой firewall, какой мониторинг, без ограничений «политикой провайдера».
• Предсказуемая производительность — нет чужой нагрузки, которая крадёт CPU-время или забивает диск в случайный момент.
• Контроль над списанием оборудования — при выводе сервера из эксплуатации вы (или по договору провайдер) можете гарантированно затереть диски, а не полагаться на то, что провайдер «обычно» это делает при переиспользовании в облаке.
• Возможность физически указать место размещения — конкретный дата-центр, конкретная стойка — без формулировки «где-то в регионе X, может мигрировать между площадками».

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

Сеть и железо: что проще внедрить на своём сервере

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

• Собственный VLAN без общего broadcast-домена. Провайдер выдаёт транк-порт или уже настроенный тег VLAN — вы поднимаете сеть, где кроме вас никого нет:

# пример тегированного интерфейса под выделенный VLAN
ip link add link eth0 name eth0.310 type vlan id 310
ip addr add 10.20.30.2/29 dev eth0.310
ip link set eth0.310 up

• Жёсткая фильтрация на границе контура. На своём сервере вы не ограничены правилами security group облачной панели — можно поставить nftables/iptables с явным белым списком и логированием отброшенных пакетов:

nft add table inet attest
nft add chain inet attest input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet attest input ip saddr 10.20.30.0/29 tcp dport 22 accept
nft add rule inet attest input log prefix "attest-drop: " drop

• Отдельный сетевой интерфейс для управления (out-of-band). IPMI/KVM-доступ на выделенном сервере физически отделён от продуктивного трафика — для аттестации это проще объяснить, чем «мы управляем через тот же облачный API, что и данные».
• Шифрование на своём уровне. Вы сами решаете, шифровать диск на уровне ОС (LUKS) или использовать самошифрующиеся накопители, и ключ не проходит через инфраструктуру провайдера.
• Явная топология без «серых зон». Схему сети для документации можно нарисовать без сносок «часть инфраструктуры управляется провайдером, детали см. в его политике».

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

Документирование и разговор с проверяющим

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

• ссылку на сертификаты/аттестаты самого провайдера (если они есть и релевантны нужному уровню защиты);
• список субподрядчиков провайдера с доступом к инфраструктуре;
• описание модели общей ответственности — что закрывает провайдер, что вы;
• условия миграции виртуальных машин между физическими хостами и что происходит с данными при этом.

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

Кто                | Доступ            | Как контролируется
--------------------|--------------------|---------------------------
Админ А (свой)      | root по SSH-ключу | логируется, ключ у сотрудника
Админ Б (свой)      | root по SSH-ключу | логируется, ключ у сотрудника
Провайдер           | физический доступ | по договору, доступ в стойку под видеонаблюдением

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

Честно про деньги и трудозатраты

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

Цифры в таблице — ориентир, а не прайс: конкретная разница зависит от объёма ресурсов, региона и того, что уже есть в тарифе провайдера. Методика более точного расчёта стоимости владения на годы вперёд разобрана в отдельной статье про TCO выделенного сервера против облака.

Честно: если система не будет аттестовываться или обрабатывает только несущественные для контура данные (например, публичный маркетинговый сайт рядом с продуктовым бэкендом), тащить всё на выделенный сервер бессмысленно — переплата не окупится. Разделение имеет смысл именно по границе контура: сам аттестуемый кусок — на изолированный ресурс, остальное может спокойно остаться в обычном облаке. Если сомневаетесь, где именно проходит грань между «пора съезжать с VPS» и «ещё рано», есть отдельный разбор с конкретными признаками в статье «выделенный сервер против VPS: когда пора переезжать».

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