Блог

• Под веса модели нужно примерно 2 ГБ на каждый миллиард параметров в FP16, 1 ГБ – в FP8 или INT8 и около 0,6 ГБ – в INT4.
• Сверху добавляется KV-кэш: у моделей класса Llama 3.1 это от 1 до 2,5 ГБ на каждый одновременный запрос с контекстом 8K токенов. И еще 10–20% служебного запаса.
• Для 20 одновременных запросов модели 8B хватает одной карты на 48 ГБ, модели 70B в FP8 нужны две карты по 80 ГБ. С запасом на рост сервер берут со свободными слотами под дополнительные ускорители: например, в YADRO G4208P G3 можно начать с двух карт и по мере роста нагрузки дойти до восьми.
• Полное дообучение требует около 16 байт на параметр, поэтому для большинства задач выбирают LoRA, QLoRA или RAG без дообучения.

От чего зависят требования к железу

Потребность в видеопамяти определяют четыре вещи:

• Размер модели. Число параметров – те самые 7B, 32B или 70B в названии, где B означает миллиарды.
• Точность весов. Одна и та же модель в FP16 занимает примерно в 3,5–4 раза больше памяти, чем после квантизации до 4 бит.
• Длина контекста. Чем длиннее запрос с документами и историей диалога, тем больше памяти занимает служебный KV-кэш.
• Число одновременных запросов. KV-кэш нужен каждому запросу отдельно, поэтому 20 пользователей требуют в 20 раз больше памяти под контекст, чем один.

Еще один фактор – задача: работа готовой модели (инференс) и ее дообучение отличаются по требованиям в разы.

Как посчитать видеопамять для работы модели

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

Память = веса модели + KV-кэш + служебный запас

Веса модели

Размер весов – это число параметров, умноженное на размер одного параметра в байтах. В форматах FP16 и BF16 параметр занимает 2 байта, в FP8 и INT8 – 1 байт, в INT4 – полбайта. Модель на 70 миллиардов параметров в FP16 занимает около 140 ГБ – только веса, без контекста.

У 4-битных моделей реальный размер на 10–15% больше расчетного: к весам добавляются коэффициенты масштаба, а часть слоев остается в повышенной точности. Квантизация экономит память, но немного снижает качество ответов. Для рабочих задач часто выбирают FP8 или INT8, а 4 бита оставляют для случаев, когда модель иначе не помещается в железо.

Модели со смесью экспертов (MoE). В таких моделях на каждый токен работает только часть параметров, но в памяти должны лежать все. У DeepSeek-V3 671 миллиард параметров, из них на каждый токен активируется 37 миллиардов. Памяти ей нужно как модели на 671B – около 670 ГБ под веса в FP8, больше, чем есть у восьми карт по 80 ГБ. А скорость генерации для одного пользователя ближе к модели на 37B: на каждом шаге читается только активная часть весов.

KV-кэш: память под контекст

Чтобы не пересчитывать весь текст на каждом шаге, модель хранит промежуточные значения для каждого токена в памяти видеокарты. Это и есть KV-кэш. Его размер на один токен считается так:

Байт на токен = 2 × число слоев × число KV-голов × размер головы × байт на элемент

Двойка в начале – это две матрицы, K и V. Параметры архитектуры есть в файле конфигурации любой открытой модели. Затем размер на токен умножаем на длину контекста и на число одновременных запросов.

Пример для двух распространенных архитектур с KV-кэшем в FP16:

Отсюда главный вывод: на длинном контексте и с несколькими пользователями KV-кэш легко сравнивается с весами модели, а то и превышает их. Современные серверы инференса умеют хранить кэш в FP8 – это вдвое меньше памяти при небольшой потере точности.

Сильнее всего на размер кэша влияет число KV-голов. Современные модели используют групповое внимание (GQA): несколько голов запроса делят одну пару K и V. У Llama 2 7B такого механизма нет, и ее кэш занимает 512 КБ на токен – в четыре раза больше, чем у Llama 3.1 8B, хотя модели почти одного размера. Поэтому перед расчетом проверьте параметр num_key_value_heads в файле config.json модели.

Служебный запас

Часть видеопамяти всегда уходит не на модель, а на систему, буферы вычислений, активации и фрагментацию – в сумме 10–20% объема. Серверы инференса заранее оставляют резерв: например, vLLM по умолчанию отводит под веса, активации и KV-кэш 90% памяти каждой видеокарты, а 10% оставляет системе. Считать впритык нельзя: модель, которой нужно 95% памяти, либо не запустится, либо сможет обслуживать одного-двух пользователей.

Инференс и дообучение: почему разница в разы

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

Практический вывод: полное дообучение большой модели – задача для кластера из нескольких серверов. Большинству компаний достаточно LoRA или QLoRA: обучается небольшая добавка к модели, а основные веса не меняются. QLoRA позволяет дообучать модель 70B на одной карте с 80 ГБ памяти. А если модель должна лишь отвечать по внутренним документам, дообучение часто не нужно вовсе: хватает поиска по базе знаний (RAG), а железо считается как для инференса.

Одна видеокарта или несколько

Если модель с кэшем не помещается в одну карту, ее делят между несколькими. Способов два:

• Тензорный параллелизм. Каждый слой делится между картами, и они обмениваются данными на каждом шаге. Нужна быстрая связь между GPU внутри сервера, иначе карты больше ждут друг друга, чем считают.
• Конвейерный параллелизм. Карты получают разные группы слоев и передают результат по цепочке. К скорости связи менее требователен, но увеличивает задержку ответа.

Внутри одного сервера обычно используют тензорный параллелизм, между серверами – конвейерный. Для тензорного параллелизма важна связь между картами: шина PCIe 5.0 x16 дает около 64 ГБ/с в каждую сторону, а специализированные межкарточные интерфейсы – в разы больше. Поэтому при выборе сервера смотрите не только на число карт, но и на то, как они соединены между собой.

Как оценить скорость ответа

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

Токенов в секунду на один поток ≈ пропускная способность памяти / размер весов

Например, модель на 70 ГБ в INT8 на карте с пропускной способностью около 3 ТБ/с даст не больше 40 токенов в секунду на одного пользователя, на практике – меньше. Зато при одновременной работе нескольких пользователей веса читаются один раз на весь батч, поэтому при небольшой нагрузке скорость на каждого падает незначительно, пока хватает памяти под KV-кэш. Для многопользовательского сервиса объем памяти под кэш часто важнее вычислительной мощности карты.

Из формулы следует и другое: у ускорителей с памятью HBM пропускная способность обычно 2–5 ТБ/с, у карт с GDDR – примерно 1–1,8 ТБ/с. Поэтому при одинаковом объеме памяти карты с HBM генерируют текст заметно быстрее. А время до первого токена зависит уже от вычислительной мощности: перед ответом модель обрабатывает весь входной текст. Поэтому в RAG, где в запрос попадают длинные фрагменты документов, пользователь дольше ждет начала ответа, даже если сама генерация идет быстро.

Что еще нужно серверу, кроме GPU

✔ Оперативная память. При загрузке и конвертации модели веса часто проходят через ОЗУ. Рабочее правило – оперативной памяти сервера не меньше суммарной видеопамяти. Для дообучения с выгрузкой состояний оптимизатора в ОЗУ нужно заметно больше.

✔ Процессоры. При инференсе они редко становятся узким местом, но на подготовке данных для обучения и индексации документов для RAG загрузка процессоров высокая. Важно и число линий PCIe: каждой карте нужен полноценный слот PCIe x16.

✔ Локальные диски. От них зависит, как быстро модель запускается после перезагрузки или смены версии. Веса на 140 ГБ с NVMe-диска на 3 ГБ/с загрузятся примерно за минуту, а по сети 10 Гбит/с – около двух минут.

✔ Хранилище для данных и чекпоинтов. При дообучении система регулярно сохраняет состояние модели. Чекпоинт полного дообучения с состояниями оптимизатора занимает почти столько же, сколько память под обучение: для модели 70B это около терабайта за одно сохранение. Пока чекпоинт пишется, видеокарты простаивают, поэтому скорость записи хранилища напрямую влияет на время обучения. Для таких задач используют all-flash СХД на NVMe – например, TATLIN.AFA.

✔ Сеть между серверами. Пока модель работает в пределах одного сервера, достаточно обычной сети для доступа пользователей и хранилища. Когда обучение идет на нескольких серверах, между ними нужен канал на сотни гигабит в секунду с поддержкой RDMA, иначе карты большую часть времени ждут данные.

Пример расчета: корпоративный ассистент на 20 одновременных запросов

Задача: ассистент отвечает на вопросы сотрудников по внутренним документам через RAG. Одновременно до 20 запросов, в каждом до 8 тысяч токенов – вопрос и найденные фрагменты документов.

Вариант 1: модель 70B в FP8.

С кэшем в FP16 двадцать запросов помещаются, но запас – всего четыре запроса, и двадцать пятый пользователь уже встанет в очередь. С кэшем в FP8 те же две карты обслужат почти 50 одновременных запросов. Если планируется контекст 32K или рост числа пользователей, закладывайте четыре карты.

Вариант 2: модель 8B в FP16. 

Веса 16 ГБ, активации и буферы около 3 ГБ, KV-кэш на те же 20 запросов – около 21 ГБ. Итого около 40 ГБ при 43 доступных на карте на 48 ГБ – одной карты хватает. Для поиска по документам и простых ответов модели такого размера часто достаточно, а железо обходится в разы дешевле.

Расчет на бумаге стоит проверить пилотом: запустить выбранную модель на реальных запросах и замерить потребление памяти и скорость ответа при расчетной нагрузке.

Как перевести расчет в конфигурацию сервера

Когда потребность в памяти посчитана, ее нужно превратить в требования к серверу. Именно на этом шаге чаще всего ошибаются.

Что подготовить для подбора сервера

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

С этими данными можно сразу рассчитать конфигурацию. Под такие задачи мы собираем сервер для ИИ YADRO G4208P G3: подбираем число ускорителей, память и диски под вашу модель и нагрузку.

Частые ошибки при расчете

• Считают только веса. Модель запускается, но падает или тормозит, как только приходят несколько пользователей с длинными запросами.
• Включают максимальный контекст «на всякий случай». 128K токенов на запрос для модели 70B – это 40 ГБ кэша на одного пользователя. Ограничьте контекст реальными сценариями.
• Планируют полное дообучение там, где хватит RAG или LoRA. Разница в железе – в разы.
• Забывают про хранилище. При дообучении медленная запись чекпоинтов останавливает дорогие видеокарты.
• Не закладывают рост. Пилот на пять человек через полгода превращается в сервис на сотню, а свободных слотов под карты в сервере нет.

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

1. Какой сервер нужен для нейросети? 

Зависит от размера модели и числа пользователей. Для моделей до 8B и небольшой команды хватает сервера с одной картой на 48 ГБ. Для моделей 70B и десятков одновременных запросов нужен сервер на несколько ускорителей по 80 ГБ с быстрой связью между ними, ОЗУ не меньше суммарной видеопамяти и NVMe-дисками под веса. Для дообучения к этому добавляются быстрое хранилище и сеть между серверами.

2. Сколько видеопамяти нужно для модели 7B? 

Около 14 ГБ под веса в FP16 или 7 ГБ в INT8, плюс примерно 1 ГБ на каждый одновременный запрос с контекстом 8K у моделей с GQA. Для одного-двух пользователей хватает карты на 24 ГБ.

3. Можно ли запустить модель 70B на одной видеокарте?

В INT4 веса занимают около 40 ГБ, так что модель помещается в карту на 48 или 80 ГБ. Но на 48 ГБ почти не остается места под KV-кэш, а качество ответов в 4 битах ниже. Для сервиса на несколько пользователей обычно берут две карты по 80 ГБ и FP8.

4. Что такое KV-кэш?

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

5. Чем INT4 отличается от FP16 на практике?

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

6. Сколько памяти нужно для дообучения?

При полном дообучении – около 16 байт на параметр без учета активаций, то есть от 130 ГБ для модели 8B. LoRA снижает потребность примерно до размера весов с небольшим запасом, а QLoRA позволяет дообучить модель 70B на одной карте на 80 ГБ.

7. Нужна ли видеокарта для RAG?

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

✔ Создайте собственную ИТ-площадку на территории предприятия без переоборудования помещений под серверную – с нашим готовым решением «Модульный ЦОД на 10 стоек».

Контейнерный и модульный ЦОД: почему термины пересекаются

В предложениях поставщиков слова «контейнерный» и «модульный» могут обозначать один комплекс. Это объясняется тем, что они описывают разные свойства.

Контейнерный ЦОД обычно является одним из исполнений модульного решения. При этом модульный комплекс может объединять несколько машинных залов, отдельные блоки питания и охлаждения. Готовые инженерные модули могут использоваться и в обычном здании. Отраслевые материалы разделяют функциональное назначение блоков, конструктивное исполнение и конфигурацию комплекса.

Здесь под капитальным ЦОД понимаем дата-центр в здании. Это обозначение формата сравнения, а не заключение о юридическом статусе конкретного объекта.

Сравнивать нужно полезную ИТ-мощность

Количество стоек показывает вместимость. Для выбора инфраструктуры необходимо знать, сколько электроэнергии потребляет оборудование и сколько тепла потребуется отвести.

Условный пример для 10 стоек:

Это арифметические сценарии, а не универсальная классификация стоек. Допустимый способ охлаждения определяется требованиями ИТ-оборудования и инженерным расчетом. Высокоплотные системы могут требовать жидкостного охлаждения; одного увеличения количества кондиционеров недостаточно, если проблема находится на уровне отвода тепла от компонентов.

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

Почему мощность оборудования не равна доступной мощности ЦОД

Резервирование уменьшает нагрузку, которую можно обслуживать при предусмотренном отказе.

Предположим, система питания содержит четыре одинаковых силовых модуля по 50 кВт:

• суммарная установленная мощность – 200 кВт;
• после отказа одного модуля остаются три;
• их суммарная мощность – 150 кВт.

Если требуется сохранить нагрузку при отказе любого одного модуля, в этом упрощенном примере расчетная нагрузка не должна превышать 150 кВт. Дополнительный запас и ограничения остальных компонентов рассматриваются отдельно.

Поэтому в предложении должны быть указаны и установленная мощность, и доступная нагрузка при выбранной схеме резервирования. Обозначение N+1 само по себе не описывает надежность всех соединений, распределительных устройств и путей питания.

Также нельзя автоматически приравнивать кВА к кВт. Полная и активная мощность – разные параметры; допустимую нагрузку ИБП проверяют по характеристикам конкретной модели и подключаемого оборудования.

Потребление всего дата-центра включает и инженерные системы: охлаждение, потери преобразования, заряд аккумуляторов, освещение и другие потребители. Суммарная ИТ-нагрузка не заменяет расчет внешнего электроснабжения.

Контейнерный ЦОД: сильные стороны и реальные ограничения

Главное преимущество контейнерного исполнения – возможность получить отдельную площадку без переоборудования помещений внутри основного здания. Значительная часть сборки инженерных систем может выполняться до доставки.

Однако «контейнер» не означает одинаковую конструкцию. Стандартный транспортный ISO-контейнер и специально изготовленный блок-контейнер отличаются по габаритам, внутреннему пространству и возможностям компоновки.

Преимущества

Высокая заводская готовность. При соответствующем составе поставки внутренние инженерные системы собирают и проверяют заранее.

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

Параллельное выполнение работ. Изготовление комплекса можно совмещать с подготовкой территории и внешних подключений.

Возможность переноса некоторых исполнений. Она полезна для отдельных сценариев, но должна подтверждаться конструкцией и условиями транспортировки.

Ограничение №1: обслуживание внутри корпуса

Вместимость следует оценивать вместе с проходами и сервисными зонами. Нужно проверить:

• открывание дверей стоек;
• извлечение серверов и тяжелых компонентов;
• доступ к задним подключениям;
• замену ИБП, аккумуляторов и оборудования охлаждения;

• маршрут перемещения оборудования от входа до места установки.

   

Геометрический пример: при полезной ширине корпуса 2,4 м и глубине стойки 1,2 м на передний и задний проходы вместе остается 1,2 м – еще до учета выступающих элементов, кабелей и других ограничений. Это не оценка конкретного продукта, а способ проверить компоновку.

ASHRAE отдельно обращает внимание на пространство для обслуживания: чрезмерная плотность инженерного оборудования может повышать риск нарушения работы соседних систем во время ремонта.

Ограничение №2: площадка остается частью проекта

Для наружного комплекса необходимо определить основание, отвод поверхностной воды, внешние подключения, подъезд и обслуживание в местных климатических условиях. Заводская готовность не устраняет эти задачи.

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

Ограничение №3: перенос требует нового проекта размещения

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

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

Модульный комплекс: масштабирование нужно проектировать заранее

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

Но модульность оборудования и масштабируемость всей площадки – разные свойства.

Преимущества

Поэтапные вложения. Часть оборудования следующей очереди можно закупать позже.

Повторяемость решений. Согласованные блоки упрощают развитие инфраструктуры и работу с однотипными системами.

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

Главное ограничение: расширение упирается в общие ресурсы

Допустим, первая очередь рассчитана на 80 кВт ИТ-нагрузки. Планируется добавить аналогичный машинный зал и довести нагрузку до 160 кВт.

Поставить второй блок недостаточно. Необходимо проверить:

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

Заранее полезно определить, что закупается сразу с запасом, что добавляется позже и какие работы потребуются при каждом расширении. Иначе заявленная поэтапность может превратиться в повторную реконструкцию.

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

ЦОД в здании: свобода планировки и цена строительных ограничений

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

Использование существующего здания может сократить строительную часть, если объект подходит. Но наличие свободного помещения еще не подтверждает его пригодность.

Преимущества

Индивидуальная компоновка. Можно предусмотреть несколько залов, разделение зон и удобные маршруты обслуживания.

Развитая эксплуатационная инфраструктура. В проекте можно выделить помещения для персонала, приемки оборудования, ремонта и хранения ЗИП.

Возможность адаптации существующего объекта. При подходящих условиях компания использует имеющуюся недвижимость.

Основные ограничения

Строительные конструкции. Проверяют нагрузки на перекрытия, высоту, возможности размещения инженерного оборудования.

Маршрут доставки. Серверный шкаф или ИБП должен пройти через ворота, двери, коридоры и подъемные устройства.

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

Развитие площадки. Существующее здание может ограничивать следующий зал, даже если первоначальная очередь размещается без проблем.

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

ЦОД в здании стоит рассматривать, когда нужны индивидуальная планировка и развитые сервисные зоны либо имеется помещение, пригодность которого подтверждена обследованием.

Что действительно определяет срок запуска

Модульный комплекс может сократить работы на площадке благодаря предварительной сборке. Изготовление модулей и подготовка места установки могут выполняться параллельно – это один из источников выигрыша по срокам.

Однако дата поставки комплекса и дата готовности ЦОД к эксплуатации могут существенно различаться.

Если блок уже изготовлен, но внешнее питание не готово, его заводская готовность не ускорит ввод.

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

Надежность: проверять пути и сценарии, а не количество оборудования

Наличие двух ИБП или нескольких кондиционеров не подтверждает отсутствие единичных точек отказа.

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

В проекте необходимо отдельно ответить на два вопроса:

• Какие отказы инфраструктура должна выдержать при согласованной нагрузке?
• Какие элементы можно обслуживать без остановки критичного оборудования?

N+1 и 2N описывают резервирование, но не заменяют анализ всей топологии. Uptime Institute отдельно рассматривает различия между количеством резервных компонентов, путями распределения и требованиями Tier.

При заявлении сертификации также следует уточнить, что именно подтверждено: типовое решение, проектная документация или построенный объект. Программа TIER-Ready относится к проверке проектных решений для модульных ЦОД; проверка реализованной площадки – отдельный результат.

Как сравнить стоимость без скрытых исключений

Сравнение цены корпуса с бюджетом полностью построенного ЦОД не показывает экономику вариантов. У предложений должна быть одинаковая граница поставки и одинаковые требования к нагрузке и резервированию.

Например, на странице модульного ЦОД СИНТО на 10 стоек прямо указано, что ДГУ, ИТ-оборудование, подготовка площадки и внешние подключения учитываются отдельными позициями проекта. Это важно при сопоставлении бюджета с другими предложениями.

Эксплуатационные расходы требуют отдельного расчета

Даже небольшая постоянная разница в энергопотреблении накапливается за годы работы.

Расчетный пример: 1 кВт дополнительного постоянного потребления за 365 дней составляет:

1 × 24 × 365 = 8 760 кВт·ч в год

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

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

Что проверять при приемке

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

Следует разделять:

FAT – предусмотренные программой заводские приемочные испытания;

SAT и интеграционные испытания на площадке – проверку после установки, подключения и настройки взаимодействия систем.

Такое разделение используется производителями модульных решений. Состав испытаний необходимо закреплять в проекте и условиях поставки.

В согласованной программе приемки полезно предусмотреть:

Методику, нагрузку, длительность и критерии успешного прохождения определяют заранее. Включение оборудования без ошибок еще не является проверкой готовности ЦОД к расчетной эксплуатации.

Когда каждый формат оправдан

Для ИИ и GPU-кластеров формат корпуса остается частью решения. Возможности питания, способ охлаждения и обслуживание определяются требованиями оборудования. Подробнее – в услуге «Строительство ЦОД для ИИ под ключ».

Что зафиксировать до выбора поставщика

Для предметного сравнения проектов подготовьте единый набор требований:

• стартовую и перспективную ИТ-нагрузку;
• количество стоек и распределение мощности между ними;
• требования оборудования к питанию, охлаждению и размещению;
• допустимые перерывы и сценарии отказа;
• условия обслуживания и резервной работы;
• сведения о помещении или территории и доступных подключениях;
• последовательность расширения;
• границы поставки и критерии приемки.

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

Определить подходящий формат ЦОД вместе с СИНТО

Для отдельной площадки на территории предприятия можно рассмотреть модульный ЦОД на 10 стоек. Для индивидуальной архитектуры и выбора способа реализации – проектирование и строительство ЦОД.

Направьте состав ИТ-оборудования, сведения о площадке и план роста нагрузки. СИНТО поможет определить ограничения, сопоставить варианты и подготовить предварительный расчет проекта.

Обсудить формат и требования к ЦОД

СИНТО проектирует и внедряет системы на базе RuBackup и Киберпротект. Обсудите с нами пилот восстановления критичных систем при недоступности основного ЦОД: согласуем объекты проверки, требования бизнеса и критерии приемки.

Если дата-центр недоступен: почему бэкапов может оказаться недостаточно

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

Например, копии находятся на отдельном сервере, но в том же здании. Или удаленное хранилище доступно только через оборудование основного ЦОД. Авария может затронуть и рабочие системы, и возможность воспользоваться бэкапами.

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

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

Какие требования к восстановлению должен определить руководитель

Начинать проект стоит с процессов, остановка которых создает наибольший ущерб.

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

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

Руководителю совместно с ИТ-командой нужно согласовать три решения:

1. Какие процессы восстанавливаются первыми. Это определяет приоритеты и состав защищаемых систем.
2. Сколько времени допускается на восстановление. Это целевой RTO – допустимый срок восстановления сервиса.
3. За какой период допускается потеря данных. Это целевой RPO – допустимый период потери данных перед сбоем.

Например, требования «восстановить учетную систему за четыре часа» и «потерять не более часа изменений» задают основу для выбора конфигурации RuBackup или Киберпротект, расчета инфраструктуры и проведения испытаний.

RuBackup и «Кибер Бэкап»: что сравнивать для восстановления при недоступности ЦОД

RuBackup и «Кибер Бэкап» можно рассматривать для защиты критичных систем. Выбор зависит от совместимости с инфраструктурой, схемы хранения копий и результатов испытания на резервной площадке.

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

Решающий критерий для бизнеса – восстановление выбранного сервиса в пределах согласованных RPO и RTO. Автоматические проверки дополняют испытание, в котором подтверждают доступ пользователей к приложению и выполнение критичных операций.

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

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

Что должен показать тест восстановления в резервном ЦОД

Проверку проводят в изолированной среде. Условия испытания должны воспроизводить ситуацию, в которой ресурсы основной площадки недоступны для восстановления.

Для выбранного сервиса проверяют:

1. Доступ к удаленным копиям и средствам восстановления.
2. Пригодность точки восстановления и состояние данных.
3. Восстановление необходимых компонентов и порядок их запуска.
4. Доступ пользователей к приложению.
5. Выполнение согласованных бизнес-операций.
6. Время до готовности сервиса к работе.

Условный пример. Компания допускает потерю не более часа изменений в учетной системе и требует восстановить ее за четыре часа.

В этом примере копии существуют, но требования бизнеса не выполнены.

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

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

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

Как обосновать бюджет на резервное копирование

Стоимость проекта сопоставляют с последствиями остановки конкретных процессов.

Для оценки рассматривают:

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

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

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

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

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

 

Когда проверку стоит провести в первую очередь

Проверка особенно необходима, если:

• все рабочие системы и копии сосредоточены в одном ЦОД;
• восстановление на другой площадке еще не испытывали;
• компания переходит на российскую виртуализацию, СУБД или систему резервного копирования;
• вырос объем данных или появились новые критичные сервисы;
• передача удаленных копий выполняется с задержками;
• изменились требования бизнеса к допустимому простою;
• инструкции по восстановлению зависят от знаний одного сотрудника;
• для хранения копий используется та же СХД, что и для рабочих данных, либо нет защищенного выделенного хранилища. В этом случае стоит рассмотреть YADRO TATLIN.BACKUP — выделенную СХД для резервных копий с защитой от удаления и шифрования.

Базовые принципы хранения копий разобраны в статье «Резервное копирование для бизнеса с нуля: правило 3-2-1, типы бэкапов и российское решение Кибер Бэкап». Следующий практический шаг – проверить восстановление собственных критичных систем.

Какой результат получить от проекта с СИНТО

При обсуждении внедрения RuBackup или «Кибер Бэкап» стоит согласовать следующие результаты:

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

Точный состав работ и документов закрепляется в техническом задании.

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

Подобрать DLP и рассчитать внедрение →

Для чего нужна DLP-система

Основная функция DLP – контролировать использование и передачу защищаемой информации. В зависимости от возможностей продукта система помогает:

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

Контроль может распространяться на три состояния данных:

Такое разделение используется в определении DLP. Однако конкретный продукт не обязательно контролирует все три состояния в базовой поставке. Для поиска информации в хранилищах могут потребоваться отдельные модули.

Как работает DLP-система

Принцип работы DLP основан на политиках безопасности. Они определяют, какие сведения защищаются, какие действия разрешены и как реагировать на нарушение.

Обычно обработка включает несколько этапов:

1. Получение информации. Агент, почтовый коннектор или другой подключенный компонент получает сведения о контролируемой операции.
2. Анализ содержимого. Система извлекает доступные данные из поддерживаемых сообщений и файлов, ищет признаки конфиденциальной информации.
3. Проверка условий. Учитываются пользователь, получатель, канал, содержание и другие параметры правила.
4. Реагирование. Система фиксирует событие, уведомляет специалиста или ограничивает операцию.
5. Разбор результата. Специалист проверяет обстоятельства и определяет, требуется ли расследование или корректировка политики.

Пример политики DLP

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

Для такой задачи недостаточно правила «блокировать все таблицы». Нужно определить:

• по каким признакам распознавать клиентские данные;
• какие пользователи работают с ними;
• каким получателям разрешена передача;
• какие каналы допустимы;
• когда требуется уведомление, а когда – блокировка.

Например, передача согласованной выгрузки уполномоченному подрядчику может быть разрешена, а отправка того же файла на личный адрес – запрещена. Правила DLP могут учитывать содержимое, отправителя, получателя и исключения.

Срабатывание правила еще не доказывает утечку. Оно означает, что операция совпала с заданными условиями. Причину и последствия проверяют при разборе события.

Как DLP распознает конфиденциальную информацию

DLP анализирует содержимое с помощью разных технологий. Их состав зависит от выбранного решения.

Такие методы представлены в российских DLP-продуктах, но реализуются по-разному и могут требовать дополнительных модулей или подготовки эталонов.

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

Какие каналы передачи данных контролирует DLP

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

Поддержку проверяют для конкретных ОС, приложений и версий. Для каждого канала также уточняют доступный режим: обнаружение, уведомление или блокировка.

Передача данных в ИИ-сервисы

Отдельный сценарий – загрузка рабочих документов в публичные ИИ-сервисы. Сотрудник может отправить договор для анализа или вставить внутреннюю переписку в запрос.

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

Из чего состоит DLP и что такое DLP-сервер

В архитектуре DLP могут использоваться следующие компоненты:

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

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

Не весь анализ обязательно выполняется на центральном сервере. В некоторых архитектурах агенты могут анализировать данные и реагировать непосредственно на рабочих станциях. Такой подход, например, описан для Zecurion DLP.

Для расчета инфраструктуры стоит заранее собрать число контролируемых устройств, ожидаемый объем событий и файлов, используемые способы анализа и планируемый срок хранения архива. Затем сопоставить эти данные с техническими требованиями продукта и результатами пилота.

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

Наблюдение и блокировка: в чем разница

Режим наблюдения

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

Если DLP получает только копию трафика, ее анализ сам по себе не останавливает исходную передачу. Результат проверки копии не влияет на доставку объекта получателю.

Режим предотвращения

При поддерживаемом способе подключения DLP может ограничивать операцию до ее завершения: например, блокировать копирование или отправку письма. В почтовом канале также может использоваться карантин для последующего разбора сообщения.

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

Ограничения DLP

Зашифрованный трафик и защищенные файлы

Для анализа содержимого системе нужен доступ к нему в читаемом виде. Контроль HTTPS может выполняться через поддерживаемый механизм на рабочей станции или интеграцию с компонентом, который предоставляет расшифрованные данные. Само наличие DLP не означает возможности прочитать любой зашифрованный поток.

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

«Не удалось проверить» и «конфиденциальных данных не обнаружено» – разные результаты. Их необходимо различать при настройке правил и разборе событий.

Ошибки распознавания

Возможны два вида ошибок:

• Ложное срабатывание – система относит разрешенную операцию или незапрещенные данные к нарушению.
• Пропуск – правило не обнаруживает передачу, которую должно было выявить в контролируемом канале.

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

Неполный охват

Нельзя автоматически считать защищенными личные компьютеры, неподключенные устройства и неподдерживаемые приложения.

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

Поэтому отсутствие событий оценивают вместе с охватом: какие компоненты работают, какие каналы подключены и какие правила действуют.

Эти средства могут дополнять друг друга. Например, антивирус сообщает о вредоносном файле, DLP – о подозрительной передаче данных, а SIEM сопоставляет их с другими событиями.

При этом обычный документ с клиентской базой может не содержать вредоносного кода. Для оценки допустимости его отправки нужны правила работы с данными.

Как проверить, что DLP работает правильно

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

Ниже – примеры сценариев для пилота. Их выполняют на подготовленных тестовых данных и с заранее согласованными правилами.

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

До расширения контроля полезно определить:

• кто разбирает события;
• как согласуются исключения;
• кто меняет правила;
• какие материалы сохраняются;
• кому доступен архив.

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

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

Можно ли использовать DLP без агентов?

Да, для отдельных задач – например, контроля корпоративной почты через коннектор. Но такой вариант не обеспечивает автоматически контроль локального копирования на носители и других действий на компьютере. Для них требуется предусмотренный продуктом механизм контроля.

Работает ли DLP на Linux?

У ряда российских продуктов есть Linux-агенты. Проверять нужно конкретный дистрибутив, версию и доступные функции. Наличие агента не означает одинаковых возможностей для Linux и Windows.

Достаточно ли DLP для выполнения требований 152-ФЗ?

Нет. DLP может решать часть задач контроля передачи персональных данных. Закон № 152-ФЗ предусматривает правовые, организационные и технические меры. Внедрение одного продукта не подтверждает выполнение всех требований.

Внедрение DLP в вашей инфраструктуре

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

В СИНТО можно заказать внедрение DLP-систем: подбор лицензий, проверку политик на пилотной группе, настройку правил и подключение согласованного контура.

Ответьте на вопросы о вашей ИС и действующей защите – подготовим предварительные рекомендации по подбору СЗИ, настройке и доработке установленных средств. Начать подбор СЗИ.

Кого касается приказ ФСТЭК № 117

Приказ ФСТЭК России от 11 апреля 2025 года № 117 устанавливает требования к защите информации в следующих системах:

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

Для частной организации требования не распространяются автоматически на все ее ИС. Однако при получении информации ограниченного доступа из ГИС необходимо учитывать положения пункта 2 и требования к защите передаваемой информации.

Исключения перечислены в пункте 12. Среди них – ИС Администрации Президента, аппарата Совета Безопасности, Федерального Собрания, Аппарата Правительства, Конституционного и Верховного судов, органов разведки и контрразведки, а также системы управления вооружением, военной и специальной техникой.

Когда приказ вступил в силу и какую редакцию учитывать

Приказ № 117 действует с 1 марта 2026 года. С этой даты приказ № 17 утратил силу. Дата принятия нового документа – 11 апреля 2025 года.

При проверке необходимо учитывать изменения, внесенные приказом ФСТЭК № 137 от 8 мая 2026 года. Основная часть изменений применяется с 1 сентября 2026 года. Для новой редакции пункта 32 установлена отдельная дата вступления в силу – 1 марта 2027 года.

С чего начать выполнение требований приказа № 117

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

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

Затем сопоставьте документы с фактическим состоянием инфраструктуры. Полезно разделять три ситуации:

Такой порядок помогает обосновать дальнейшие работы и закупки: для каждого действия должна быть понятна проблема, которую оно устраняет.

Что проверить в информационной системе

Для предварительной проверки рекомендуем пройти следующие направления. Это отправная точка для обследования; состав проверок уточняется по конкретной ИС.

Границы системы и документация

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

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

Уязвимости и обновления

Проверьте охват сканирования, доступность активов и обработку результатов. Если сервер недоступен для проверки, отсутствие находок не подтверждает его защищенность.

Для найденной уязвимости проследите дальнейшие действия: кому передана задача, какое исправление согласовано и проведена ли повторная проверка. Отдельно учитывайте проблемы, по которым пока действует временная мера.

Учетные записи и удаленный доступ

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

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

События безопасности и реагирование

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

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

Резервное копирование и восстановление

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

Успешное завершение задания резервного копирования и восстановление работающей системы – разные результаты. При обследовании важно установить, какой из них подтвержден.

Получить рабочий чек-лист по приказу № 117

Для самостоятельной проверки используйте заполняемый шаблон Excel. В нем можно связать проверяемое требование с подтверждающими материалами, отметить выявленный пробел и назначить дальнейшее действие.

В шаблоне предусмотрены:

• проверяемая позиция и ссылка на соответствующий пункт требований;
• документы и технические материалы для подтверждения;
• статус выполнения и комментарий;
• необходимое действие, ответственный и срок.

Чек-лист поможет подготовить исходные данные для обследования и собрать задачи ИБ- и ИТ-команд в одной таблице.

Оставьте рабочий email, чтобы получить чек-лист.

Какие сроки установлены для устранения уязвимостей

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

Для среднего и низкого уровней порядок и сроки определяются с учетом особенностей работы ИС.

Чтобы выстроить процесс, заранее определите, кто принимает решение об исправлении, кто согласует изменение и как проверяется результат. Если обновление пока невозможно, необходимо отдельно рассмотреть компенсирующую меру и дальнейшее устранение проблемы.

Для этой задачи используем решение «Управление уязвимостями с инженерными исправлениями»: проверяем согласованный контур, выполняем утвержденные изменения на серверах и в сети, затем проводим повторный контроль.

Как подобрать СЗИ под требования приказа № 117

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

Ниже – направления подбора. Необходимость отдельного средства определяется по результатам обследования.

Например, MaxPatrol VM помогает организовать процесс управления уязвимостями, а RedCheck применяется для анализа защищенности, включая поиск уязвимостей и проверку настроек. Выбор зависит от задач дальнейшего контроля.

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

Чем подтверждать выполнение требований

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

Примеры для предварительного обследования:

Приказ также предусматривает оценку защищенности Кзи и уровня зрелости Узи по методическим документам ФСТЭК. Эти оценки охватывают более широкий круг вопросов, чем результаты одного сканирования.

Для значимых объектов КИИ отдельно рассматривайте применимые требования. Подробный материал по этому направлению – «Подготовка значимых объектов КИИ к требованиям ФСТЭК 2027».

Экспресс-аудит вашей ИС: определить пробелы и необходимые работы

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

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

По результатам составим:

• перечень выявленных пробелов с основаниями выводов;
• план исправлений и очередность работ;
• задачи по настройке действующих средств защиты;
• предложения по недостающим функциям и подбору СЗИ.

Лицензии, внедрение и инженерные исправления рассчитаем отдельно. Объем обследования согласуем до начала работ.

Стоимость зависит от числа ИС, состава документации и глубины технических проверок.

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

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

Нужно ли заново аттестовывать ГИС после вступления приказа № 117 в силу?

Приказ сохраняет действительность аттестатов, выданных до его вступления в силу. Необходимость дополнительных работ оценивается с учетом изменений ИС и условий ее эксплуатации.

Экспресс-аудит подтверждает соответствие приказу № 117?

Экспресс-аудит помогает выявить основные пробелы в согласованном объеме и определить дальнейшие действия. Он не заменяет аттестацию или полный комплекс работ по подтверждению соответствия.

Можно начать с действующих СЗИ и не покупать новые лицензии?

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

Правила безопасности при работе с электронной почтой

1. Проверяйте полный адрес отправителя. Сверяйте домен, содержание запроса и предыдущие договоренности. Отображаемое имя, логотип и подпись могут быть скопированы.

2. Входите в сервисы через известный адрес. Открывайте почту, банк и ЭДО через закладки или самостоятельно набранный адрес. HTTPS подтверждает шифрование соединения, но не добросовестность сайта.

3. Подтверждайте смену реквизитов отдельно. Свяжитесь с контрагентом по ранее известному номеру. Контакты из письма с новыми реквизитами также могут принадлежать мошенникам.

4. Проверяйте неожиданные вложения. Если файл требует включить макросы, установить программу или отключить защиту, передайте запрос ИТ- или ИБ-команде.

5. Не передавайте пароли и коды подтверждения. Не одобряйте вход, который вы не инициировали. Для рабочих аккаунтов используйте уникальные пароли.

6. Сверяйте получателей и документы перед отправкой. Проверяйте автоподставленные адреса, список копий и содержание вложений.

7. Сообщайте о подозрительных письмах. Используйте установленный канал обращения в ИТ или ИБ. Сохраняйте оригинал сообщения по внутренней инструкции.

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

Как защитить платежи и переписку с контрагентами

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

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

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

Средства защиты электронной почты

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

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

Почему SPF, DKIM и DMARC недостаточно для проверки содержимого

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

DMARC сопоставляет домен в видимом поле «От кого» с доменом успешной проверки SPF или DKIM. Политика домена сообщает принимающей стороне, как предлагается обрабатывать письма, не прошедшие проверку.

Успешная проверка DMARC не подтверждает безопасность вложения, ссылки или запроса на оплату. Протокол также не предназначен для выявления визуально похожих доменов и подмены отображаемого имени. 

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

Как обрабатывать архивы, PDF и QR-коды

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

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

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

Как защищать учетные записи

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

Если платформа поддерживает FIDO2, рассмотрите этот способ входа: он обеспечивает устойчивость к фишинговой подмене сервиса.

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

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

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

Необычный вход требует проверки обстоятельств. Неизвестная пересылка или правило удаления писем может указывать на захват аккаунта – такие изменения необходимо расследовать.

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

Отдельно проверяйте восстановление почтовых данных. Резервные копии необходимо защищать от одновременного уничтожения с рабочими системами.

Что делать, если сотрудник уже взаимодействовал с подозрительным письмом

Сразу сообщите ИТ- или ИБ-команде, какие действия выполнены: переход по ссылке, ввод пароля, запуск файла, подтверждение входа или платеж. Укажите время и сохраните исходное сообщение по внутренней инструкции.

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

При захвате ящика ИТ-команде необходимо проверить активные сессии, подключенные приложения, способы восстановления, пересылку и почтовые правила. Одной смены пароля может быть недостаточно для восстановления контроля; действия зависят от платформы.

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

Какие меры безопасности необходимы при работе с электронной почтой?

Проверка отправителей и важных запросов, защита входа, анализ ссылок и вложений, контроль доступа и настроек. Для сотрудников нужен понятный порядок сообщения о подозрительных письмах и действий после ошибки.

Можно ли доверять письму от знакомого отправителя?

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

Нужна ли дополнительная защита облачной почты?

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

Когда требуется усиление защиты корпоративной почты

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

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

Если требования для объекта уже определены и требуется техническая реализация, СИНТО выполняет проектирование и внедрение системы оповещения при угрозе совершения или совершении террористического акта с учетом типа объекта, его категории и применимых нормативных требований.

Какие требования действуют для разных объектов

Основные нормативные документы и требования к оповещению можно свести к следующей схеме.

Таблица дает общую ориентацию. Для конкретного объекта дополнительно учитываются результаты обследования и категорирования, паспорт безопасности, проектная документация и другие распространяющиеся на него обязательные требования.

Школы, детские сады и колледжи

Для объектов Министерства просвещения России и объектов, относящихся к сфере его деятельности, действует Постановление Правительства РФ №1006.

Оно предусматривает оборудование объектов системами оповещения и управления эвакуацией либо автономными системами или средствами экстренного оповещения работников, обучающихся и других находящихся на объекте лиц. Эти требования распространяются на объекты всех четырех категорий через положения пунктов 24-27.

К самой системе предъявляются конкретные требования:

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

Можно ли использовать пожарную СОУЭ в школе

В 2026 году здесь произошло важное изменение.

СП 3.13130.2026 разрешил применять технические средства пожарной СОУЭ для передачи сообщений об угрозе совершения террористического акта и об антитеррористических мерах.

Минпросвещения отдельно разъяснило это в письме от 8 июня 2026 года №АБ-2160/14. Ведомство указывает, что после принятия нового СП изменился подход к использованию технических средств пожарного оповещения для антитеррористических задач.

При этом само ПП №1006 продолжает содержать требования к автономности и бесперебойному питанию. Поэтому наличие пожарной СОУЭ еще не означает, что объект автоматически выполнил все требования к антитеррористическому оповещению.

Вузы и другие объекты в сфере Минобрнауки

Для объектов Министерства науки и высшего образования и относящихся к его сфере организаций действует отдельное Постановление Правительства РФ №1421.

В актуальной редакции пункт 34 требует, чтобы СОУЭ обеспечивала оперативное информирование работников, обучающихся и других лиц о необходимости эвакуации и дальнейших действиях.

Система должна иметь источник бесперебойного питания.

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

Поэтому школы и вузы нельзя объединять в один нормативный режим: требования установлены разными постановлениями.

Торговые центры, рынки и магазины

Для торговых объектов действует Постановление Правительства РФ №1273. В 2026 году документ был изменен Постановлением Правительства РФ от 4 марта 2026 года №229.

Торговый объект независимо от категории должен быть оборудован:

• системой видеонаблюдения;
• системой оповещения и управления эвакуацией;
• системой освещения.

Система оповещения должна обеспечивать оперативное информирование людей об угрозе или совершении террористического акта.

Количество оповещателей и их мощность должны обеспечивать необходимую слышимость на всей территории торгового объекта.

Для крупного торгового центра это означает, что при оценке системы нельзя ориентироваться только на торговые залы. Требование относится ко всей территории объекта в пределах действия постановления.

Места массового пребывания людей

Для мест массового пребывания людей действует Постановление Правительства РФ №272.

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

Такие места независимо от категории оборудуются системой оповещения и управления эвакуацией. Система должна обеспечивать оперативное информирование людей об угрозе или совершении террористического акта.

Здесь есть особенно важное требование:

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

Кроме того, количество оповещателей и их мощность должны обеспечивать необходимую слышимость на всей территории места массового пребывания людей.

Это один из примеров, почему новое разрешение СП 3.13130.2026 на использование технических средств пожарной СОУЭ нельзя трактовать как универсальное разрешение объединять системы на любом объекте.

Стадионы и другие объекты спорта

Для объектов спорта действует Постановление Правительства РФ №202 в редакции от 25 марта 2025 года.

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

Отдельно постановление устанавливает:

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

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

Театры, музеи и другие объекты культуры

Для объектов в сфере культуры действует Постановление Правительства РФ №176 в редакции от 8 мая 2025 года.

Документ предусматривает своевременное оповещение работников и других находящихся на объекте лиц и обеспечение безопасной эвакуации.

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

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

Гостиницы и другие средства размещения

Для гостиниц и иных средств размещения действует Постановление Правительства РФ №447 в редакции от 3 сентября 2025 года.

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

Она должна обеспечивать информирование работников и посетителей:

• об угрозе и возникновении чрезвычайных ситуаций;
• об угрозе или совершении террористического акта;
• о правилах поведения;
• о необходимых действиях.

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

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

При этом у ПП №447 есть собственная область применения и исключения, поэтому сначала необходимо проверить, подпадает ли конкретный объект размещения именно под этот нормативный режим.

Медицинские организации

Для объектов Министерства здравоохранения и объектов, относящихся к сфере его деятельности, действует Постановление Правительства РФ №8 в редакции от 15 августа 2025 года.

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

При этом из ПП №8 нельзя сделать вывод, что каждая медицинская организация только на основании этого постановления обязана установить отдельную СО при УСТА определенного типа.

Для больницы, поликлиники или медицинского центра необходимо совместно проверить:

• требования ПП №8;
• категорию объекта;
• паспорт безопасности;
• требования пожарной безопасности и СОУЭ;

• другие нормы, распространяющиеся на конкретное здание и его назначение.

   

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

Религиозные объекты

Для объектов религиозных организаций действует Постановление Правительства РФ №1165.

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

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

Поэтому требования ПП №272 для мест массового пребывания людей или ПП №1273 для торговых объектов нельзя автоматически переносить на религиозный объект.

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

Что изменилось в 2026 году: можно ли использовать пожарную СОУЭ

С 1 июня 2026 года действует новый СП 3.13130.2026 «Системы противопожарной защиты. Система оповещения и управления эвакуацией людей при пожаре. Требования пожарной безопасности».

Пункт 6.13.1 прямо допускает применение технических средств пожарной СОУЭ для:

• фонового озвучивания;
• передачи объявлений;
• передачи иной экстренной информации;
• передачи сообщений об угрозе совершения террористического акта и антитеррористических мерах.

Однако это разрешение, а не универсальное требование объединять системы.

При таком использовании необходимо выполнять требования пунктов 6.13.2 и 6.13.3, в том числе по приоритетам передачи сообщений и сохранению работоспособности пожарной СОУЭ.

Кроме того, необходимо учитывать отраслевое постановление для конкретного объекта.

Например:

• для вузов возможность использования речевых пожарных оповещателей прямо закреплена ПП №1421;
• для образовательных объектов Минпросвещения в 2026 году отдельно разъяснило возможность применения средств пожарной СОУЭ для антитеррористических сообщений;
• для мест массового пребывания людей ПП №272 продолжает устанавливать требование об автономности системы и запрещает ее совмещение с ретрансляционными технологическими системами.

Поэтому ответ на вопрос «можно ли использовать одну систему для пожара и угрозы теракта?» зависит от нормативного режима конкретного объекта.

Как применяется ГОСТ Р 71934-2025

ГОСТ Р 71934-2025 введен в действие 1 марта 2025 года.

Он распространяется на вновь разрабатываемые и модернизируемые СО при УСТА, предназначенные для информирования людей:

• об угрозе или совершении террористического акта;
• о характере угрозы;
• о действиях, необходимых для защиты жизни и здоровья.

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

Важно правильно понимать роль стандарта.

ГОСТ Р 71934-2025 сам по себе не заменяет отраслевые требования к антитеррористической защищенности объекта.

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

Поэтому ссылка только на ГОСТ без анализа ПП №1006, №1273, №272, №202 или другого профильного постановления недостаточна.

Где можно устанавливать систему оповещения

СО при УСТА может охватывать как помещения здания, так и открытые участки территории объекта. Оповещение должно быть слышно во всех местах, где люди находятся постоянно или временно.

В зависимости от назначения и планировки объекта оповещатели могут размещаться:

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

При этом универсального требования устанавливать отдельный громкоговоритель в каждом помещении нет. Важен результат – необходимая слышимость и разборчивость речевых сообщений во всех предусмотренных проектом зонах.

Количество, тип, мощность и расположение оповещателей определяют с учетом планировки объекта, площади помещений, фонового шума, акустических особенностей и требований, которые распространяются на конкретный объект.

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

Как определить требования для своего объекта

Практический порядок проверки можно выстроить следующим образом.

1. Определить назначение объекта.
   Школа, вуз, магазин, гостиница, объект спорта, культуры, здравоохранения и другие объекты регулируются разными актами.
2. Определить нормативный акт.
   Необходимо установить, какое постановление Правительства распространяется именно на этот объект.

3. Проверить категорирование.

   Часть требований зависит от присвоенной объекту категории.

4. Проверить акт обследования и паспорт безопасности.
   В них могут быть определены конкретные мероприятия для объекта.
5. Определить требования к оповещению.
   Важно установить, нужна ли отдельная система, СОУЭ, автономные средства экстренного оповещения или иной вариант.
6. Проверить существующую инфраструктуру.
   Необходимо оценить пожарную СОУЭ, линии связи, громкоговорители, питание, зоны оповещения и возможности управления.
7. Проверить возможность совместного использования систем.
   СП 3.13130.2026 допускает использование пожарной СОУЭ для антитеррористических сообщений, но решение должно соответствовать требованиям конкретного объекта.
8. При модернизации проверить применимость ГОСТ Р 71934-2025.

Когда действующую систему стоит проверить

Систему стоит повторно проверить, если:

• изменилось назначение здания;
• проведена реконструкция или перепланировка;
• добавлены новые корпуса или территории;
• изменилось количество одновременно находящихся людей;
• проведено новое категорирование объекта;
• изменились требования паспорта безопасности;
• модернизируется существующая система оповещения;
• сообщения плохо слышны в отдельных зонах;
• отсутствует необходимое резервное питание;
• требуется интеграция с пожарной СОУЭ или другими системами;
• фактическая схема системы больше не соответствует проектной документации.

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

А что с вокзалами, аэропортами и другими объектами транспорта

Объекты транспортной инфраструктуры нельзя автоматически относить к режиму ПП №272 только потому, что на них одновременно находится большое количество людей.

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

Поэтому вокзал, аэропорт, метрополитен или иной объект транспортной инфраструктуры необходимо рассматривать отдельно. Требования к нему нельзя определять только по приведенной выше таблице.

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

Для всех ли объектов обязательна отдельная СО при УСТА?

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

Можно ли использовать пожарную СОУЭ для антитеррористических сообщений?

В ряде случаев – да. СП 3.13130.2026 прямо разрешает применять технические средства пожарной СОУЭ для передачи сообщений об угрозе теракта при соблюдении установленных условий. Но необходимо проверить требования профильного постановления для конкретного объекта.

Какой ГОСТ действует для СО при УСТА в 2026 году?

ГОСТ Р 71934-2025. Он действует с 1 марта 2025 года и распространяется на вновь разрабатываемые и модернизируемые СО при УСТА.

Нужно ли менять старую систему из-за ГОСТ Р 71934-2025?

Сам факт введения ГОСТ Р 71934-2025 не означает автоматическую замену всех ранее установленных систем. Стандарт прямо распространяется на вновь разрабатываемые и модернизируемые СО при УСТА. Для действующего объекта необходимо отдельно определить основания и объем предполагаемой модернизации.

Обязательна ли система оповещения в торговом центре?

Для торговых объектов, подпадающих под ПП РФ №1273, – да. Они независимо от категории оборудуются системой оповещения и управления эвакуацией. Система должна обеспечивать информирование об угрозе или совершении террористического акта и необходимую слышимость на всей территории.

Какие требования действуют для школ?

Для объектов в сфере Минпросвещения действует ПП РФ №1006. Оно предусматривает СОУЭ либо автономные средства экстренного оповещения, а для СОУЭ устанавливает требования к автономности, бесперебойному питанию, громкости и разборчивости речи.

Требуется ли отдельная СО при УСТА в медицинской организации?

ПП РФ №8 требует своевременного оповещения работников и посетителей и обеспечения технической возможности эвакуации, но не дает основания утверждать, что на каждом медицинском объекте должна устанавливаться отдельная СО при УСТА одного типа. Необходимо учитывать категорию объекта и весь комплекс применимых требований.

Что важно учитывать в 2026 году

Универсальной схемы антитеррористического оповещения для всех объектов нет.

Требования определяются последовательно:

тип объекта → профильный нормативный акт → категория → паспорт безопасности → требования к оповещению → существующие системы → техническое решение

Главное изменение 2026 года связано с СП 3.13130.2026: теперь технические средства пожарной СОУЭ прямо разрешено использовать для передачи антитеррористических сообщений при соблюдении условий свода правил. Но это не отменяет специальных требований, установленных для отдельных видов объектов.

При разработке новой или модернизации существующей СО при УСТА также учитывается ГОСТ Р 71934-2025 и требования, распространяющиеся на конкретный объект.

Кзи: нормированное значение равно 1

Методика оценки показателя защищенности утверждена ФСТЭК России 11 ноября 2025 года.

Нормированное значение:

Кзи = 1

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

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

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

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

Если в область оценки входят несколько информационных систем

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

В таком случае методика предусматривает использование минимального значения соответствующего частного показателя при расчете Кзи.

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

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

Кзи может потребоваться пересчитать раньше чем через полгода

Периодичность раз в шесть месяцев – минимальная.

Методика предусматривает внеочередную оценку Кзи, в частности:

• после значимого инцидента информационной безопасности;
• после изменения архитектуры информационных систем;
• по запросу руководителя организации;
• по запросу ФСТЭК России.

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

Подтверждающие материалы становятся частью оценки

Методика Кзи содержит перечень документов и материалов, которые могут использоваться для подтверждения частных показателей.

До начала обязательного регулярного расчета Кзи стоит проверить цепочку:

требование → реализованная мера → подтверждение → фактическое выполнение

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

При этом часть результатов не обязательно получать заново. Методика позволяет использовать сведения, полученные в ходе:

• внутреннего контроля;
• внешнего аудита;
• мониторинга информационной безопасности;
• оценки защищенности;
• аттестации;
• других мероприятий по контролю уровня защиты.

Это позволяет использовать уже накопленную доказательную базу, если она актуальна и относится к оцениваемому объекту.

Узи: какие уровни зрелости предусмотрены

Методика оценки уровня зрелости утверждена ФСТЭК России 7 августа 2026 года.

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

Это именно рекомендуемые значения методики.

Узи оценивает не наличие отдельного межсетевого экрана, SIEM или другого продукта, а зрелость самой деятельности по обеспечению безопасности.

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

Внутренняя или внешняя оценка Узи

Методика допускает два варианта оценки.

Внутренняя оценка проводится силами организации.

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

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

При этом обязательного требования всегда привлекать внешнюю организацию для расчета Узи нет.

Особое внимание – подрядчикам с доступом к значимому объекту

Одно из наиболее существенных изменений касается сторонних организаций.

Если подрядчику предоставляется доступ к значимому объекту КИИ при:

• обработке или хранении информации;
• создании объекта;
• развитии;
• эксплуатации;
• обеспечении безопасности,

субъект КИИ должен установить для такой организации требование по расчету и оценке Узи.

Оценка проводится до предоставления доступа. Затем не реже одного раза в три года.

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

Поэтому подготовка к 2027 году касается не только настроек VPN или учетных записей подрядчиков.

Нужно понимать:

кто получает доступ → к каким компонентам → для каких работ → на какой срок → какие требования к зрелости установлены

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

Что проверить до 1 марта 2027 года

Подготовку удобно разделить на пять этапов.

1. Определить область оценки

Нужно актуализировать:

• перечень значимых объектов КИИ;
• входящие в область оценки информационные системы;
• архитектуру;
• состав программных и технических средств;
• средства защиты;
• сетевые взаимодействия;
• подрядчиков, имеющих доступ к объекту.

Без этого невозможно корректно определить, что именно должно оцениваться.

2. Собрать доказательную базу

По каждой реализованной мере нужно понимать:

что сделано → как реализовано → чем подтверждается

Стоит проверить актуальность организационных документов, результатов контроля, журналов, технических настроек и других материалов.

3. Предварительно рассчитать Кзи

Пробный расчет до вступления приказа №220 в силу позволит определить частные показатели, которые не достигают требуемых значений.

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

4. Оценить Узи

Для каждого оцениваемого направления определяются:

текущий уровень → целевой уровень → разрыв

Отдельно нужно проверить требования к подрядчикам, которым предоставляется доступ к значимым объектам.

5. Устранить выявленные несоответствия

После оценки станет понятно, какие изменения действительно необходимы.

Они могут быть:

• организационными;
• архитектурными;
• техническими;
• документальными.

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

Нужно ли покупать новые средства защиты из-за приказа №220

Сам приказ №220 не вводит список продуктов, которые необходимо приобрести к 1 марта 2027 года.

Он устанавливает требования к регулярной оценке состояния защищенности и зрелости деятельности.

Поэтому схема: новый приказ → обязательная новая закупка - некорректна.

Необходимость модернизации определяется тем, какие несоответствия выявлены при оценке.

Например, проблема может быть связана с:

• недостаточным разграничением доступа;
• отсутствием необходимых подтверждений;
• неактуальными процессами;
• недостаточной сегментацией сети;
• отсутствием требуемого контроля событий;
• недостаточной отказоустойчивостью;
• резервным копированием;
• другими техническими или организационными мерами.

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

Если необходимо устранить единичные точки отказа и обеспечить сохранение критичных сервисов при отказе серверов, СХД или сети, отдельно проектируется отказоустойчивая ИТ-инфраструктура для КИИ и критичных сервисов.

Логика подготовки должна быть обратной:

оценить → найти несоответствие → определить причину → выбрать меру → подтвердить результат

Что происходит, если Кзи ниже 1

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

После вступления приказа №220 в силу появляются конкретные сроки:

• 3 календарных дня – на информирование руководителя о несоответствии;
• 5 рабочих дней после дня расчета – на направление результата оценки Кзи во ФСТЭК России.

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

Предварительная оценка позволяет выявить их до того, как результаты потребуется направлять регулятору.

Что не стоит делать при подготовке

Нужно ли впервые рассчитать Кзи именно 1 марта 2027 года

Приказ №220 устанавливает дату вступления требований в силу – 1 марта 2027 года – и периодичность расчета Кзи не реже одного раза в шесть месяцев.

При этом отдельная календарная дата первого расчета непосредственно в приказе не установлена.

Методика предусматривает определение периодичности и порядка проведения оценки в документах организации. Поэтому до вступления приказа в силу целесообразно:

• определить внутренний график;
• назначить ответственных;
• определить порядок сбора подтверждений;
• провести предварительный расчет;
• устранить выявленные несоответствия.

Это позволит не начинать подготовку уже после возникновения обязанности регулярно оценивать показатель.

Часто задаваемые вопросы

Кого касается приказ ФСТЭК №220?

Изменения внесены в требования приказа №235 и относятся к системам безопасности значимых объектов КИИ.

Это не означает автоматического распространения новых требований на любую информационную систему любого субъекта КИИ.

Когда вступает в силу приказ №220?

1 марта 2027 года.

Приказ издан 16 июля 2026 года и зарегистрирован Минюстом России 7 сентября 2026 года под №88168.

Как часто нужно рассчитывать Кзи?

Не реже одного раза в шесть месяцев.

Методика также предусматривает случаи внеочередной оценки.

Какое значение Кзи считается нормированным?

Кзи = 1.

Оно соответствует минимально необходимому уровню защиты от типовых актуальных угроз безопасности информации.

Как часто рассчитывается Узи?

Не реже одного раза в три года.

Для подрядчика, которому предоставляется доступ к значимому объекту, оценка проводится до предоставления доступа и затем не реже одного раза в три года.

Нужно ли передавать результат Кзи во ФСТЭК?

Да.

Результат оценки направляется во ФСТЭК России не позднее пяти рабочих дней после дня проведения расчета.

Нужно ли передавать Узи во ФСТЭК в течение пяти рабочих дней?

Приказ №220 прямо устанавливает пятидневный срок для результата Кзи.

Аналогичного требования о передаче результата Узи во ФСТЭК в пунктах 36(1)–36(4) нет.

Обязательно ли привлекать стороннюю организацию для оценки Узи?

Нет.

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

Что будет, если не представить подтверждения расчета Кзи?

Если ФСТЭК запросит использованные при расчете материалы и они не будут представлены в течение 30 дней, Кзи и (или) соответствующим частным показателям может быть присвоено значение 0.

Главное

С 1 марта 2027 года для значимых объектов КИИ вводится более регулярная и измеримая модель контроля состояния безопасности.

Организации потребуется отвечать на три вопроса:

• Каково фактическое состояние защищенности? – Кзи
• Насколько зрелы процессы обеспечения безопасности? – Узи

Чем подтверждаются полученные результаты? – документами и фактическими материалами

Поэтому подготовка к новым требованиям – это не закупка оборудования «под приказ».

Практическая последовательность выглядит так:

область оценки → предварительный Кзи → Узи → подтверждающие материалы → выявленные разрывы → устранение → регулярный контроль

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

Главный принцип расчета – кластер должен выдержать отказ хоста

 

Кластер виртуализации нельзя рассчитывать только по сумме vCPU, оперативной памяти и терабайт виртуальных дисков.

 

Главная проверка начинается после расчета ресурсов: что произойдет, если один из хостов станет недоступен?

 

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

 

Поэтому расчет строится последовательно:

 

нагрузка → процессор → оперативная память → хранилище → отказ одного хоста → проверка N+1

 

---

 

Какие данные нужны перед расчетом

 

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

 

Ресурс	Что собрать
Процессор	vCPU, фактическую загрузку и пики
Оперативная память	Выделенную и реально используемую память
Хранилище	Занятое место и темп роста
Дисковая нагрузка	IOPS, пропускную способность и задержки
Виртуальные машины	Количество, критичность и ограничения размещения
Развитие	Новые ВМ и увеличение существующих ресурсов
Отказоустойчивость	Сколько отказов должен выдерживать кластер

 

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

 

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

 

---

 

 

---

 

Процессор: считать нагрузку, а не количество vCPU

 

Количество выделенных виртуальных процессоров vCPU само по себе не показывает, сколько физических процессорных ресурсов требуется кластеру.

 

Если виртуальным машинам суммарно назначено 160 vCPU, это не означает ни необходимость 160 физических ядер, ни возможность автоматически поделить это число на 2, 4 или 8.

 

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

 

Для действующей инфраструктуры нужно анализировать:

 

• фактическую загрузку процессоров;
• пиковые периоды;
• конкуренцию ВМ за процессорное время;
• наиболее нагруженные ВМ;
• ограничения NUMA.

 

Практический принцип: отношение vCPU к физическим ядрам должно определяться профилем нагрузки, а не задаваться заранее ради уменьшения количества серверов.

 

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

 

---

 

Почему важен NUMA

 

Для крупных виртуальных машин отдельно проверяют, как их процессорные ресурсы и память соотносятся с NUMA-топологией физического сервера.

 

Если ВМ выходит за пределы одного NUMA-узла, ей может потребоваться обращаться к памяти другого узла. Для чувствительных к задержкам приложений это способно снизить производительность.

 

Поэтому важно проверить не только общую мощность кластера, но и может ли самая крупная ВМ корректно разместиться на одном из физических хостов.

 

---

 

 

---

 

Оперативная память: считать состояние после отказа

 

Базовая потребность определяется как:

 

память ВМ + рост нагрузки + ресурсы самой платформы виртуализации

 

Универсального правила вроде «оставлять 32 ГБ на каждом хосте» нет.

 

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

 

Для N+1 выполняется проверка:

 

доступная память оставшихся хостов ≥ расчетная потребность ВМ

 

Если кластер состоит из трех одинаковых узлов, нужно убедиться, что после потери одного вся необходимая нагрузка помещается в два оставшихся.

 

Механизмы динамического распределения памяти могут повышать эффективность ее использования, но для критичной инфраструктуры их не стоит рассматривать как замену достаточному объему физической RAM.

 

---

 

Как рассчитать количество хостов N+1

 

Для одинаковых серверов отдельно определяют ограничение по процессору и памяти.

 

После приведения процессорной нагрузки к производительности целевых серверов:

 

NCPU = ceil(CPUрасч / CPU одного хоста)

 

По памяти:

 

NRAM = ceil(RAMрасч / RAM, доступная ВМ на одном хосте)

 

Для рабочей нагрузки принимается большее значение:

 

Nраб = max(NCPU, NRAM)

 

Для отказа одного вычислительного узла:

 

Nитого = Nраб + 1

 

Это расчет вычислительной емкости N+1, а не универсальная формула построения отказоустойчивого кластера. Требования к минимальному количеству узлов, кворуму и дополнительным компонентам зависят от конкретной платформы виртуализации.

 

Пример:

 

Параметр	Значение
Расчетная CPU-нагрузка	50 условных ядер целевого CPU
Расчетная RAM	820 ГБ
CPU одного хоста	32 ядра
RAM, доступная ВМ на одном хосте	480 ГБ

 

По процессору: ceil(50 / 32) = 2 хоста

 

По памяти: ceil(820 / 480) = 2 хоста

 

Для рабочей нагрузки достаточно двух серверов. Для N+1 требуется 3 хоста.

 

После отказа одного узла остаются 64 ядра и 960 ГБ памяти при расчетной потребности 50 ядер и 820 ГБ.

 

Но необходимо дополнительно проверить, смогут ли крупные ВМ разместиться на двух оставшихся серверах с учетом NUMA, зарезервированных ресурсов и правил размещения.

 

Комментарий инженеров СИНТО. N+1 нужно проверять моделированием потери хоста. Если после его исключения хотя бы одна критичная ВМ не может запуститься или получает недостаточно ресурсов, расчет N+1 не выполнен.

 

Для кластера из неодинаковых серверов простое правило «добавить один хост» применять нельзя. Нужно моделировать потерю наиболее значимого по ресурсам узла.

 

---

 

Хранилище: емкость и производительность считаются отдельно

 

Для дисковой подсистемы одного показателя в терабайтах недостаточно.

 

Нужно ответить на два вопроса:

 

Хватит ли полезной емкости?

Хватит ли производительности?

 

Расчет емкости

 

Учитываются:

 

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

 

Ориентироваться нужно на полезную емкость, доступную для размещения данных, а не на сумму номиналов установленных дисков.

 

Например, 40 ТБ SSD не означают 40 ТБ пространства для виртуальных машин. Итоговая полезная емкость зависит от схемы защиты данных и архитектуры хранилища.

 

Тонкое выделение дискового пространства не увеличивает физическую емкость

 

При тонком выделении виртуальным дискам можно логически назначить больше пространства, чем они занимают физически в данный момент.

 

Но реальная емкость хранилища от этого не увеличивается.

 

Поэтому необходимо контролировать:

 

фактически занято → скорость роста → реально свободно

 

Если физическое пространство закончится, виртуальные машины могут столкнуться с ошибками ввода-вывода.

 

---

 

Производительность хранилища

 

Для расчета недостаточно знать только IOPS.

 

Следует анализировать:

 

• IOPS;
• пропускную способность, МБ/с или ГБ/с;
• задержку;
• соотношение чтения и записи;
• пиковые периоды.

 

Желательно анализировать общую нагрузку на хранилище, а не просто складывать максимальные значения отдельных ВМ: пики у них могут происходить в разное время.

 

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

 

---

 

Что происходит с хранилищем при отказе хоста

 

Здесь расчет зависит от архитектуры.

 

Общая внешняя СХД

 

При отказе вычислительного сервера физическая емкость внешней СХД обычно не уменьшается.

 

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

 

• контроллеров;
• путей доступа;
• сети хранения;
• дисков;
• коммутаторов.

 

Гиперконвергентная инфраструктура

 

Если вычислительные ресурсы и хранилище находятся на одних и тех же узлах, отказ сервера одновременно уменьшает:

 

• вычислительную мощность;
• доступную емкость хранения;
• суммарную производительность дисковой подсистемы.

 

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

 

Поэтому для гиперконвергентной инфраструктуры N+1 нельзя рассчитывать только по процессору и памяти. Нужно дополнительно проверить емкость и производительность хранилища после отказа узла и во время восстановления данных.

 

---

 

Что еще может нарушить N+1

 

Достаточный запас CPU и RAM еще не гарантирует, что все ВМ смогут автоматически запуститься после отказа.

 

Нужно проверить:

 

• reservations CPU и RAM;
• affinity и anti-affinity;
• NUMA;
• локальные диски;
• PCI passthrough;
• SR-IOV;
• vGPU;
• доступность сетей и storage;
• лицензионные ограничения;
• правила самой HA-платформы.

 

Например, в актуальной документации РЕД ВИРТ для миграции ВМ прямо указано требование достаточных CPU и RAM на целевом хосте. То есть наличие хоста в кластере само по себе не означает возможность принять конкретную виртуальную машину.

 

---

 

Что еще может нарушить N+1

 

Достаточного количества процессорных ресурсов и памяти недостаточно, если отдельную ВМ нельзя разместить на оставшихся серверах.

 

Проверяют:

 

• зарезервированные процессорные ресурсы и память;
• правила совместного и раздельного размещения ВМ;
• NUMA;
• локальные диски;
• прямой проброс устройств;
• SR-IOV;
• vGPU;
• доступность сетей и хранилищ;
• лицензионные ограничения;
• правила отказоустойчивости конкретной платформы.

 

То есть:

 

«суммарных ресурсов достаточно» и «все необходимые ВМ смогут запуститься» – не всегда одно и то же.

 

---

 

Что проверить перед закупкой серверов

 

Проверка	Что должно быть известно
Процессор	Фактическая и пиковая потребность
Оперативная память	Потребность ВМ и доступная память после отказа
Крупные ВМ	Возможность размещения на оставшихся хостах
Емкость хранилища	Полезная ёмкость и прогноз роста
Производительность хранилища	IOPS, пропускная способность и задержки
N+1	Ресурсы после отказа хоста
Отказоустойчивость	Кворум и требования платформы
Сеть	Пропускная способность и резервирование
Рост	Ресурсы для будущих ВМ

 

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

Часто задаваемые вопросы

Какое отношение vCPU к физическим ядрам использовать?

Универсального значения нет. Для существующей инфраструктуры соотношение определяют по фактической нагрузке. Для нового проекта – по профилю приложений и результатам испытаний.

Значения 2:1, 4:1 или 8:1 нельзя использовать как универсальное правило.

Сколько vCPU можно выделить на одно физическое ядро?

Это зависит от нагрузки и гипервизора. Если виртуальные машины большую часть времени используют небольшую долю выделенных процессорных ресурсов, отношение vCPU к физическим ядрам может быть выше. Для постоянно нагруженных баз данных и вычислительных систем допустимое значение обычно будет ниже.

Как рассчитать N+1?

Для одинаковых хостов сначала определяют количество серверов, необходимое для рабочей нагрузки по процессору и памяти. Затем добавляют ресурс одного узла и проверяют состояние после его отказа.

Для неодинаковых серверов моделируют потерю конкретного хоста, в том числе наиболее мощного.

Нужно ли держать один сервер полностью свободным?

Нет. Нагрузка может быть распределена между всеми хостами. Главное – чтобы после отказа одного узла ресурсов оставшихся серверов хватало для необходимых ВМ.

Можно ли выделять виртуальным машинам больше памяти, чем физически установлено?

Некоторые гипервизоры поддерживают динамическое распределение и переподписку памяти.

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

Какой запас ресурсов оставлять?

Универсального процента нет. Запас определяется ростом количества ВМ, увеличением существующих нагрузок, требованиями N+1/N+2 и возможностями выбранных серверов.

Как рассчитать хранилище для кластера виртуализации?

Нужно проверить две независимые характеристики:

• полезную емкость – сколько данных реально можно разместить;
• производительность – какие IOPS, пропускную способность и задержки обеспечивает хранилище.

Для гиперконвергентной инфраструктуры обе характеристики дополнительно проверяют после отказа узла и при восстановлении данных.

Достаточно ли трех хостов для N+1?

Не всегда. Три одинаковых сервера могут обеспечить N+1 по вычислительным ресурсам, если двух оставшихся достаточно для всей расчетной нагрузки. Но требования к кворуму, хранилищу, сети и отказоустойчивости зависят от конкретной платформы.

Вывод

Для расчета кластера виртуализации недостаточно сложить vCPU, оперативную память и объем виртуальных дисков.

Нужно последовательно проверить:

процессор → оперативная память → полезная емкость хранилища → производительность хранилища → отказ хоста

Главный критерий N+1: после потери одного расчетного узла оставшаяся инфраструктура должна обеспечивать необходимую нагрузку с требуемой производительностью.

Только после такой проверки имеет смысл выбирать количество и конфигурацию физических серверов.

1. Определить расчетную нагрузку

В расчет включают оборудование, которое должно сохранять питание при нарушении внешнего электроснабжения:

• серверы и СХД;
• сетевое и телекоммуникационное оборудование;
• автоматику;
• критичные системы мониторинга;
• другие защищаемые потребители, предусмотренные проектом.

Для действующего ЦОД предпочтительны фактические измерения в характерных режимах работы. Для нового объекта используют проектные нагрузки оборудования и стоек.

Номиналы резервированных блоков питания серверов нельзя автоматически суммировать. Два PSU по 1600 Вт не означают, что сервер постоянно потребляет 3200 Вт – расчет ведут по фактическому или проектному потреблению оборудования.

СП 541.1325800.2024 предусматривает подключение к системе бесперебойного питания критичных нагрузок ИТ-оборудования, автоматики и слаботочных систем. Дополнительные нагрузки определяются заданием на проектирование.

2. Перевести кВт в кВА

Полная мощность рассчитывается через PF:

S = P / PF

Если расчетная нагрузка составляет 240 кВт, а PF = 0,95:

S = 240 / 0,95 = 252,6 кВА

Следовательно, ИБП должен обеспечивать не менее 240 кВт / 252,6 кВА.

Значение PF не следует брать автоматически равным 1. Для действующего ЦОД его лучше подтверждать измерениями, для проектируемого – определять по характеристикам нагрузки и исходным данным проекта.

СП 541.1325800.2024 не устанавливает единый PF для всех ЦОД – коэффициент мощности задается в исходных данных на проектирование.

Для нелинейной ИТ-нагрузки также не следует автоматически подменять PF значением cos φ: общий коэффициент мощности учитывает не только фазовый сдвиг, но и искажения формы тока.

3. Учесть запас на развитие

Если текущая нагрузка составляет 200 кВт, а проект предусматривает рост на 20%, расчетная перспективная нагрузка будет:

200 × 1,20 = 240 кВт

Но 20% здесь – только пример.

Универсального нормативного требования всегда добавлять к мощности ИБП 20%, 25% или 30% нет.

Запас лучше определять через реальный сценарий развития:

• сколько стоек планируется добавить;
• как изменится их мощность;
• какой будет нагрузка через несколько лет;
• можно ли расширять ИБП силовыми модулями.

Для модульного ИБП часто рациональнее предусмотреть возможность расширения, чем сразу устанавливать всю перспективную мощность.

4. Рассчитать резервирование

Запас на развитие и резервирование рассчитываются отдельно.

Для параллельной конфигурации ГОСТ IEC 62040-3-2024 использует обозначение n + r, где n – количество блоков, необходимых для питания нагрузки, а r – количество избыточных блоков.

Для N+1 сначала определяют N, затем добавляют один резервный модуль.

Пример N+1

По кВт требуется: 240 / 50 = 4,8 → 5 модулей.

По кВА: 252,6 / 50 = 5,05 → 6 модулей.

Принимаем большее значение: N = 6.

Для N+1 требуется 7 модулей. После отказа одного останется 300 кВт / 300 кВА, что выше расчетных 240 кВт / 252,6 кВА.

Если считать только по кВт, получилось бы 5+1 модулей. После отказа одного осталось бы 250 кВт / 250 кВА – по кВт достаточно, а по кВА уже нет.

Комментарий инженеров СИНТО. N+1 нужно проверять именно после исключения резервируемого элемента. Установленная мощность системы в нормальном режиме сама по себе не подтверждает, что резервирование сохранится при отказе.

Что меняется при 2N

При 2N каждый из двух независимых трактов должен самостоятельно обеспечивать всю расчетную нагрузку.

Для примера выше каждый тракт должен выдерживать минимум:

240 кВт / 252,6 кВА

При этом два ИБП еще не означают полноценные 2N. Независимость проверяют по всей цепочке:

источник → распределение → ИБП → байпас → PDU → ИТ-оборудование

Если отказ общего элемента нарушает оба тракта, он остается единой точкой отказа.

Нужно ли оставлять 20% мощности ИБП свободными

Фиксированного нормативного требования загружать ИБП максимум на 70%, 80% или другое универсальное значение нет.

Свободная мощность должна появляться как результат расчета:

• развития нагрузки;
• резервирования;
• шага мощности модулей;
• требований аварийного режима;
• характеристик выбранного оборудования.

Поэтому правильнее контролировать не условный процент загрузки, а три значения:

текущая нагрузка → перспективная нагрузка → нагрузка после отказа резервируемого элемента

Что проверить после расчета мощности

Расчетный номинал, например 300 кВт / 300 кВА, еще не означает, что подойдет любой ИБП с такими характеристиками.

Отдельно нужно учитывать, что номинал ДГУ нельзя выбирать по простому правилу «ИБП 500 кВА = ДГУ 500 кВА». Для генератора важны входные характеристики ИБП, заряд АКБ после разряда, переходные процессы и другие нагрузки на генераторной шине.

Комментарий инженеров СИНТО. При согласовании ИБП и ДГУ важно проверить не только установившийся режим, но и принятие нагрузки генератором, переключения между источниками и восстановление заряда АКБ.

Если требуется рассчитать весь энергетический тракт – ИБП, АКБ, ДГУ, АВР, PDU, шинопроводы и схему резервирования – это входит в проектирование систем бесперебойного электроснабжения для ЦОД.

АКБ рассчитывается отдельно

Мощность ИБП определяет, какую нагрузку система способна поддерживать. Емкость АКБ – как долго она сможет это делать без внешнего питания.

СП 541.1325800.2024 предусматривает для ИБП с АКБ не менее 5 минут работы при 100% нагрузке в аварийном режиме.

Фактическая автономия может быть больше – в зависимости от времени запуска ДГУ, алгоритма переключений и требований проекта.

Поэтому расчет мощности ИБП и расчет батарейной системы нельзя объединять в одну формулу.

Нормативная база

При расчете ИБП для ЦОД используются, в частности:

СП 541.1325800.2024 «Здания и сооружения центров обработки данных. Правила проектирования» – расчет нагрузок, резервирование, АКБ и внешний байпас.

ГОСТ IEC 62040-3-2024 – активная и полная мощность ИБП, PF, параллельные конфигурации, входные и выходные характеристики, методы испытаний.

ГОСТ IEC 62040-1-2024 – требования безопасности к системам бесперебойного энергоснабжения.

Часто задаваемые вопросы

Считать мощность ИБП в кВт или кВА?

В обеих величинах. ИБП должен одновременно обеспечивать расчетную активную мощность в кВт и полную мощность в кВА.

Как перевести кВт в кВА для ИБП?

По формуле:

S = P / PF

Например, 240 кВт при PF = 0,95 соответствуют 252,6 кВА.

Какой PF использовать для расчета ИБП?

PF определяется по характеристикам нагрузки, исходным данным проекта или измерениям на действующем объекте. Универсального значения PF для всех ЦОД нет.

Какой запас мощности закладывать в ИБП?

Фиксированного нормативного процента нет. Запас должен соответствовать прогнозируемому росту нагрузки и архитектуре конкретного ЦОД.

20% запаса – это N+1?

Нет. Запас учитывает рост нагрузки. N+1 означает, что после отказа одного резервируемого блока оставшаяся система способна обеспечить всю расчетную нагрузку.

Как проверить N+1?

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

Нужно ли учитывать КПД при выборе мощности ИБП?

КПД не прибавляется к требуемой выходной мощности. Он учитывается при анализе входного потребления и тепловых потерь.

Можно ли подобрать ДГУ по номиналу ИБП?

Нет. Нужно учитывать входные характеристики ИБП, заряд АКБ, переходные процессы и другие нагрузки генераторной системы.

Какое минимальное время работы от АКБ предусматривает СП 541?

Для ИБП с АКБ – не менее 5 минут при 100% нагрузке в аварийном режиме.

Главное в расчете мощности ИБП

Расчет мощности ИБП для ЦОД сводится к последовательности:

нагрузка в кВт → PF → нагрузка в кВА → запас на развитие → N → резервирование

ИБП проверяется одновременно по кВт и кВА. Запас на развитие не заменяет N+1, а N+1 считается выполненным только тогда, когда после отказа одного резервируемого элемента оставшейся мощности достаточно для всей расчетной нагрузки.

Для таких задач применяются системы контроля и управления доступом (СКУД).

Видеонаблюдение

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

Стоит проверить:

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

Подробнее – проектирование и монтаж систем видеонаблюдения.

Информационная безопасность

Работа промышленных и инфраструктурных объектов все чаще зависит от серверов, сетей связи, информационных систем и автоматизированного управления.

С технической точки зрения стоит проверить:

• сетевую инфраструктуру;
• удаленный доступ;
• учетные записи и привилегии;
• защищенность серверов и рабочих станций;
• разделение корпоративных и технологических сегментов;
• средства обнаружения инцидентов;
• защищенность промышленных сетей и АСУ;
• актуальность резервных копий.

Эти задачи относятся к отдельному направлению сетевой безопасности предприятия.

Готовность к восстановлению после отказа или инцидента

Указ отдельно называет невосстановление или несвоевременное восстановление функционирования объекта среди обстоятельств, при которых может быть введено временное управление.

При технической проверке стоит заранее определить:

• какие системы критичны для работы объекта;
• что произойдет при отказе каждой из них;
• есть ли резервирование каналов связи;
• работает ли резервное электропитание;
• проводятся ли испытания ИБП и ДГУ;
• выполняется ли резервное копирование;
• проводилось ли тестовое восстановление данных;
• сохранены ли конфигурации критичного оборудования и ПО;
• можно ли оперативно заменить отказавшее оборудование;
• доступны ли необходимые запасные части;
• актуальны ли исполнительная документация и схемы;
• проверялись ли сценарии восстановления на практике.

Такая проверка позволяет выявить единичные точки отказа и определить, какие компоненты необходимо резервировать для сохранения работы критичных сервисов.

Если требуется модернизация вычислительного контура, СИНТО проектирует отказоустойчивую ИТ-инфраструктуру для КИИ и критичных сервисов: серверный кластер, отказоустойчивое хранение, резервирование сети, проверку совместимости компонентов и испытания согласованных сценариев отказа.

Объект критической инфраструктуры и объект КИИ – не одно и то же

Эти понятия важно разделять.

187-ФЗ определяет объектами КИИ информационные системы, информационно-телекоммуникационные сети и автоматизированные системы управления субъектов критической информационной инфраструктуры.

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

Чего Указ №604 не требует

Из текста Указа не следует, что после его вступления в силу каждая организация обязана:

• установить определенное количество камер;
• заменить действующую СКУД;
• внедрить конкретную систему информационной безопасности;
• полностью перестроить существующую систему безопасности;
• применить одинаковую схему резервирования ИТ- и инженерных систем.

Указ устанавливает обстоятельства, при которых может применяться механизм временного управления. Конкретные меры безопасности определяются требованиями, действующими для конкретного объекта.

С чего начать проверку

До закупки нового оборудования стоит оценить фактическое состояние объекта:

1. Определить применимость Указа к объекту.
2. Собрать действующие требования безопасности.
3. Сопоставить их с фактически реализованными мерами.
4. Проверить работоспособность установленных систем.
5. Выявить зоны и процессы, которые остаются без необходимого контроля.
6. Проверить сценарии реагирования.
7. Проверить возможность восстановления критичных систем.
8. Зафиксировать недостатки и определить приоритетность работ.

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

Опыт СИНТО на промышленных и инфраструктурных объектах

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

Среди реализованных проектов:

• модернизация ИТ-инфраструктуры для «Зарубежнефти» и «Славнефть-ЯНОС»;
• модернизация электропитания двух ЦОД для ПАО «ОДК-Сатурн»;
• работы по СКС, СКУД, охранному телевидению, пожарной сигнализации и оповещению на производственных объектах.

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

Когда вступил в силу Указ №604?

Указ вступил в силу со дня его официального опубликования – в августе 2026 года.

Могут ли предприятие сразу передать во временное управление?

Нет. Решение принимает Правительство РФ на основании поручения Президента РФ при наличии предусмотренных Указом обстоятельств. Автоматического применения этой меры при любом нарушении документ не устанавливает.

Обязывает ли Указ установить СКУД и видеонаблюдение?

Нет. Конкретного перечня технического оборудования в Указе №604 нет.

Указ №604 – это закон о КИИ?

Нет. Безопасность критической информационной инфраструктуры регулируется отдельным Федеральным законом №187-ФЗ.

Что проверить в первую очередь?

Сначала определить требования, применимые к объекту, затем сопоставить их с фактическим состоянием систем и проверить работоспособность критичных сценариев, включая восстановление после отказа или инцидента.

Источники

• Указ Президента РФ от 24.08.2026 №604 «О мерах по обеспечению безопасности объектов критической инфраструктуры Российской Федерации».
• Федеральный закон от 26.07.2017 №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».

Материал носит информационный характер и не является юридической консультацией. Применимость Указа №604 и конкретных требований к отдельному объекту необходимо определять с учетом действующих нормативных правовых актов и решений уполномоченных органов.

Зонирование задается не только соображениями безопасности. СП 541.1325800.2024 устанавливает состав обязательных технологических зон ЦОД и требования к их взаимному расположению – это база, поверх которой строятся рубежи доступа. Поэтому схему разграничения доступа закладывают на этапе проектирования и строительства ЦОД: менять расположение зон на действующем объекте дороже, чем предусмотреть их сразу.

Защита периметра дата-центра

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

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

Защищать нужно не только линию забора. Критичные точки, которые часто выпадают из проекта: инженерные вводы, площадки энергетического оборудования, зоны разгрузки, технологические ворота.

Как связать обнаружение и верификацию

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

тревожное событие → определение зоны → вывод изображения нужных камер оператору → проверка → действие по регламенту.

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

Контроль входа и въезда на территорию ЦОД

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

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

Ключевой принцип: доступ на территорию не равен доступу ко всем помещениям внутри.

Разграничение доступа по зонам

Полный доступ ко всем помещениям дата-центра редко нужен даже тем, кто находится внутри легально. В ЦОД работают специалисты по электроснабжению, инженеры систем охлаждения, сетевые специалисты, ИТ-персонал, эксплуатационные и монтажные службы, представители владельцев оборудования.

Задачи у них разные. Инженеру по охлаждению нужен доступ к инженерному оборудованию, но не к серверным шкафам. Подрядчик, работающий в одном помещении, не должен получать право перемещаться по всему объекту.

Права строятся по формуле: кто → куда → когда → для какой задачи. Реализуются через СКУД – систему контроля и управления доступом, объединяющую считыватели, контроллеры и правила предоставления прав.

Доступ в машинный зал

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

Особого внимания требуют подрядчики: доступ выдается на конкретный период и только в нужную зону. Это уменьшает количество пользователей с постоянными избыточными правами – один из источников накопленного риска в эксплуатируемых ЦОД.

Доступ к серверной стойке

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

Это позволяет при расследовании ответить не только на вопрос «кто был в машинном зале», но и «кто получил физический доступ к конкретному оборудованию и когда».

Контроль действий подрядчиков в дата-центре

Риск для ЦОД связан не только с внешним проникновением, но и с действиями человека, который законно находится на объекте.

Типичные сценарии:

• сотруднику выданы избыточные права;
• подрядчик попал не в ту зону;
• временный пропуск остался активным после окончания работ;
• невозможно установить, кто находился возле оборудования в момент инцидента.

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

Физическая безопасность в этом смысле – не набор устройств, а система управления доступом к критической инфраструктуре.

Единая картина событий: СКУД, видеоконтроль и сигнализация

Когда СКУД, камеры, охранная сигнализация и периметральные датчики работают независимо друг от друга, при инциденте оператор вручную сопоставляет время и ищет запись.

Связанная архитектура формирует единое событие:

тревожная зона → тип события → камера → время → действия оператора;
дверь машинного зала → идентификатор → время прохода → видеозапись → журнал.

Отдельное требование – синхронизация времени между системами. Если часы камер, СКУД и сигнализации расходятся, восстановить точную последовательность становится сложно. Часть событий при необходимости передается в DCIM- или SCADA-систему диспетчеризации, которая сводит инженерные и охранные параметры объекта в один интерфейс.

Глубину архива и состав зон видеоконтроля определяют в задании на проектирование: от них напрямую зависит объем СХД. Расчет камер, архива и аналитики выполняется в рамках отдельной задачи – проектирования и монтажа систем видеонаблюдения.

От чего зависит архитектура защиты

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

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

Что определить до выбора оборудования

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

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

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

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

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

Семь типичных ошибок

1. Защищать только внешний периметр. Надежный забор не решает проблему избыточных прав внутри здания.
2. Давать персоналу доступ ко всем помещениям. Права должны соответствовать реальным обязанностям.
3. Не ограничивать временный доступ. Разрешение подрядчика не должно оставаться активным после окончания работ.
4. Использовать видеоконтроль отдельно от других событий. Связь тревоги или прохода с камерой кратно ускоряет проверку.
5. Не учитывать защиту конкретного оборудования. Для части систем уровня машинного зала недостаточно.
6. Не синхронизировать системное время. Расхождение часов осложняет расследование.
7. Выбирать оборудование до сценариев. Сначала – кого, от чего и на каком рубеже контролируем.

Нормативная база

Требования к физической безопасности российского ЦОД рассматриваются вместе с требованиями к объекту и его инженерной инфраструктуре.

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

Отдельный случай – дата-центры, где размещаются значимые объекты критической информационной инфраструктуры (ЗОКИИ). Для них предусмотрен контроль физического доступа к программно-аппаратным средствам, а конкретный набор мер зависит от категории значимости и модели угроз. Практический вывод: архитектуру физической защиты в таком ЦОД согласуют с проектом системы безопасности значимого объекта, а не проектируют изолированно.

Состав систем нельзя выбирать по названию стандарта или предполагаемому классу объекта: решения зависят от архитектуры, назначения ЦОД, требований заказчика и применимых норм.

Экспресс-проверка: где слабые места

Шесть вопросов для первичной оценки физической безопасности объекта. Каждое «да» на вопросы 1 и 6 и каждое «нет» на остальные – зона для доработки.

1. Можно ли после одного контрольного пункта попасть сразу в критическую зону?
2. Разделены ли права инженеров, ИТ-специалистов и подрядчиков?
3. Можно ли установить, кто находился возле конкретного оборудования в момент события?
4. Ограничиваются ли временные права по сроку автоматически?
5. Получает ли оператор нужную камеру при тревоге без ручного поиска?
6. Есть ли участки вне контроля – внешние инженерные зоны, служебные входы, технические ворота?

Главное

Физическая безопасность дата-центра строится не вокруг турникета, камеры или считывателя, а вокруг логики:

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

Наиболее понятная модель – последовательные рубежи: 

периметр → КПП → здание → критические помещения → машинный зал → серверная стойка. Количество уровней и состав технических средств определяются конкретным объектом.

Часто задаваемые вопросы

Сколько уровней физической безопасности должно быть в ЦОД?

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

Чем физическая безопасность ЦОД отличается от офисной?

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

Достаточно ли камер для защиты периметра дата-центра?

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

Обязательно ли использовать биометрию для входа в машинный зал?

Нет. Способ идентификации определяется требованиями конкретного объекта: применяются карты, ПИН-коды, биометрия или сочетание нескольких факторов. Выбор фиксируется в задании на проектирование вместе с правилами выдачи и отзыва прав.

Нужно ли контролировать доступ к каждой серверной стойке?

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

Зачем связывать СКУД и видеоконтроль?

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

Когда пересматривать схему физической безопасности?

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

Об авторах

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

Межсетевой экран давно перестал быть устройством, которое только разрешает или запрещает соединения по IP-адресам и портам. Современный шлюз безопасности может одновременно анализировать приложения, выявлять сетевые атаки, фильтровать веб-доступ, обслуживать VPN и проверять зашифрованный трафик.

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

Эксперт статьи – Александр Евгеньевич Кудашкин, руководитель проектов внедрения СИНТО, сертифицированный технический специалист по продуктам Ideco UTM и Ideco NGFW.

💬 «При подборе межсетевого экрана я сначала смотрю на схему прохождения трафика. Нужно понять, какие потоки пойдут через шлюз, какие функции защиты будут включены, сколько VPN-подключений требуется и что произойдет с сетью при отказе устройства. Количество пользователей и скорость интернет-канала – только часть исходных данных». - Александр Кудашкин

 

---

 

 

---

 

UTM и NGFW – в чем разница

UTM (Unified Threat Management) объединяет несколько функций сетевой безопасности в одном устройстве. NIST относит к типичным функциям UTM межсетевой экран, IPS, VPN-концентратор, шлюзовой антивирус и контентную фильтрацию. Для NGFW NIST отдельно выделяет анализ на прикладном уровне L7, DPI, TLS-дешифрование и инспекцию, а также IPS.

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

Например, актуальный Ideco NGFW Novum поддерживает stateful-фильтрацию, DPI и контроль приложений, IPS, VPN, контентную фильтрацию, TLS/SSL-инспекцию, журналирование и интеграцию с SIEM.

Что выбирать

Не стоит использовать упрощенную схему:

небольшой бизнес – UTM, крупный бизнес – NGFW.

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

 

Какие данные нужны перед подбором межсетевого экрана

До сравнения конкретных моделей стоит собрать минимум семь групп параметров.

Главная задача – получить не условное требование «NGFW на 1 Гбит/с», а профиль реальной нагрузки.

Почему нельзя выбирать NGFW только по Firewall Throughput

Это одна из наиболее частых ошибок при чтении спецификаций.

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

• Firewall Throughput;
• IPS Throughput;
• NGFW Throughput;
• максимальное число одновременных соединений;
• количество новых соединений в секунду – CPS;
• отдельные характеристики VPN.

Эти параметры описывают разные режимы работы и не являются взаимозаменяемыми.

Хорошо это видно на актуальных характеристиках Ideco EX:

Показатель	Заявленное значение
Межсетевой экран, EMIX	92 Гбит/с
IPS, EMIX	31 Гбит/с
NGFW: FW + IPS + контроль приложений + контент-фильтрация, EMIX	15,5 Гбит/с
Новых TCP-сессий в секунду	800 000
Одновременных соединений	до 21 млн

 

Это характеристики одной конкретной платформы Ideco EX, а не универсальное соотношение для всех межсетевых экранов. Производитель отдельно предупреждает, что результат тестирования по профилю EMIX может изменяться в зависимости от настроек продукта.

Но пример показывает принципиально важную вещь:

максимальная пропускная способность межсетевого экрана и производительность системы с включенными функциями NGFW – разные показатели.

💬 «Firewall Throughput я бы никогда не использовал как единственный критерий. Если в рабочем режиме будут включены IPS, контроль приложений и контентная фильтрация, смотреть нужно производительность именно с этим набором функций. Иначе устройство можно формально подобрать под канал, а после включения защитных механизмов получить узкое место». - Александр Кудашкин

 

---

 

 

---

 

Нужно учитывать весь трафик через NGFW
 

Интернет-канал – не всегда вся нагрузка.

Через межсетевой экран могут проходить:

 

• выход пользователей в интернет;
• трафик между VLAN и зонами безопасности;
• соединения между офисами и филиалами;
• VPN удаленных сотрудников;
• обращения к опубликованным сервисам;
• трафик между корпоративной сетью и ЦОД.

Особенно это важно, если NGFW используется не только на внешнем периметре, но и для сегментации внутренней сети.

Например, Ideco NGFW Novum поддерживает зональную модель межсетевого экранирования, VLAN и виртуальные контексты для разделения сетевых сегментов.

Поэтому расчет вида:

интернет 1 Гбит/с → нужен NGFW 1 Гбит/с

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

---

 

IPS, DPI и контроль приложений нужно считать в рабочем профиле

DPI позволяет анализировать трафик глубже IP-адреса и номера порта и распознавать его на прикладном уровне. IPS анализирует трафик на признаки сетевых атак и применяет заданное действие при обнаружении угрозы. Такие механизмы входят в типичный функциональный набор NGFW.

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

Например:

Firewall + IPS + контроль приложений + контентная фильтрация

– это уже другой режим нагрузки, чем только stateful firewall.

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

 

---

SSL/TLS-инспекцию нужно учитывать отдельно

Большая часть пользовательского веб-трафика передается по HTTPS. Чтобы анализировать содержимое защищенного соединения, NGFW должен выполнить TLS/SSL-инспекцию.

Ideco NGFW Novum поддерживает инспекцию и расшифровку TLS/SSL, включая TLS 1.3. После расшифровки содержимое может передаваться на проверку другим механизмам безопасности – например IPS или контентной фильтрации. Для ресурсов, которые расшифровывать не требуется, предусмотрены исключения.

При выборе оборудования поэтому нужно заранее определить:

 

• нужна ли TLS/SSL-инспекция;
• для каких сегментов и пользователей;
• какие ресурсы необходимо исключить;
• какой объем такого трафика ожидается;
• достаточно ли производительности выбранной платформы при требуемой конфигурации.

Не стоит рассчитывать производительность TLS-инспекции по характеристике обычного firewall, если производитель не заявляет такую зависимость.

💬 «Инспекцию HTTPS лучше закладывать еще до выбора платформы. Если сначала подобрать устройство по обычному трафику, а затем добавить расшифрование и глубокую проверку, рабочий профиль нагрузки изменится. Для важных проектов такой режим нужно проверять на пилоте». - Александр Кудашкин

 

---

Почему количество пользователей тоже недостаточно

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

Поэтому производители указывают не только рекомендуемое количество пользователей, но и более технические параметры:

Concurrent Connections (CC) – сколько соединений устройство способно поддерживать одновременно;

Connections per Second (CPS) – сколько новых соединений оно способно устанавливать за единицу времени.

В текущей линейке Ideco эти показатели приводятся отдельно для разных аппаратных платформ наряду с пропускной способностью.

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

 

---

VPN и филиалы – отдельная часть расчета

Для распределенной компании перед выбором NGFW нужно определить как минимум:

 

• максимальное число одновременно подключенных удаленных пользователей;
• количество Site-to-Site туннелей;
• трафик между площадками;
• какие сервисы передаются через VPN;
• какие каналы используются как основные и резервные.

Ideco NGFW поддерживает сценарии удаленного и Site-to-Site VPN, включая IPsec; в документации есть отдельные сценарии объединения офисных сетей через IPsec.

При этом наличие поддержки VPN еще не означает, что любая аппаратная конфигурация подойдет для любой нагрузки. Требования к VPN необходимо включать в sizing конкретной модели.

 

---

Когда одного межсетевого экрана недостаточно

Еще один вопрос, который нужно решить до выбора модели: что произойдет, если NGFW перестанет работать?

Если через него проходят интернет, межфилиальная связь, VPN и критичный межсегментный трафик, один физический шлюз может стать единой точкой отказа.

Ideco NGFW Novum поддерживает кластеризацию Active-Passive с синхронизацией сессий и конфигурации между узлами.

Но HA не требуется автоматически каждому объекту. Решение зависит от того, какое время недоступности допускается для конкретной сети и сервисов.

💬 «При проектировании я бы обязательно проверял сценарий отказа. Если отключение одного NGFW одновременно лишает компанию интернета, VPN и связи между ключевыми сегментами, вопрос уже не только в производительности устройства – нужно рассматривать отказоустойчивую схему». - Александр Кудашкин

 

---

Не забыть про интеграции

Межсетевой экран редко работает как изолированный шлюз.

До внедрения стоит проверить совместимость с инфраструктурой, которая уже используется в компании:

 

• каталогами пользователей;
  SIEM;
• системой мониторинга;
• многофакторной аутентификацией;
• маршрутизацией;
• другими средствами информационной безопасности.

Для Ideco NGFW документированы интеграции с Microsoft Active Directory и LDAP, а также передача событий в SIEM по Syslog; продукт поддерживает и другие корпоративные интеграции.

Но проверять нужно не наличие слова «интеграция» в спецификации, а конкретный сценарий: например, откуда NGFW получает пользователей, какие события передает в SIEM и какие политики должны зависеть от учетной записи.

 

---

Когда учитывать требования ФСТЭК

Для части российских информационных систем выбор межсетевого экрана определяется не только техническими характеристиками.

ФСТЭК России приказом № 44 от 7 марта 2023 года утвердила требования по безопасности информации к многофункциональным межсетевым экранам уровня сети.

При этом из наличия этих требований не следует, что каждой коммерческой организации необходим именно сертифицированный ФСТЭК NGFW.

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

 

---

Что проверять на пилоте

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

На пилоте стоит воспроизвести максимально близкий к рабочему набор функций:

 

• правила межсетевого экрана;
• IPS;
• контроль приложений;
• контентную фильтрацию;
• TLS/SSL-инспекцию, если она нужна;
• VPN;
• авторизацию пользователей;
• интеграцию с каталогом;
• журналирование;
• необходимую маршрутизацию;
• отказоустойчивость.

После этого оцениваются пропускная способность, загрузка ресурсов, стабильность соединений и корректность политик.

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

 

---

Семь типичных ошибок при выборе NGFW

1. Выбирать устройство только по скорости интернет-канала.
Не учитываются межсегментный трафик, VPN и другие потоки.

2. Смотреть только на максимальный Firewall Throughput.
Рабочая производительность с IPS и другими функциями может соответствовать совершенно другому показателю в спецификации.

3. Считать количество сотрудников главным параметром.
Для sizing важны также соединения, CPS и профиль нагрузки.

4. Решить вопрос с TLS-инспекцией уже после закупки.
Нужный режим лучше определить до выбора платформы.

5. Не учитывать VPN.
Удаленный доступ и межфилиальные туннели создают дополнительный профиль нагрузки.

6. Не проверить отказ одного NGFW.
Высокая производительность не устраняет единую точку отказа.

7. Не протестировать необходимые интеграции.
AD, SIEM и другие системы нужно проверять в требуемом сценарии эксплуатации.

Чек-лист перед выбором межсетевого экрана

Перед отправкой требований поставщику или интегратору соберите:

 

1. скорость и количество интернет-каналов;
2. среднюю и пиковую загрузку;
3. схему прохождения трафика через NGFW;
4. количество пользователей;
5. текущие и пиковые значения соединений, если они измеряются;
6. количество филиалов;
7. количество удаленных VPN-пользователей;
8. перечень функций – IPS, DPI, фильтрация, TLS-инспекция и другие;
9. требования к сегментации;
10. список интеграций;
11. требования к отказоустойчивости;
12. нормативные требования, если они применимы;
13. прогноз роста нагрузки.

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

 

Для проектов на Ideco NGFW и UTM ФСТЭК СИНТО подбирает аппаратную платформу и лицензии по собранным требованиям, рассчитывает стоимость поставки и внедрения. На странице решения представлены аппаратные линейки, различия редакций и состав подписки Security Update.

Экспертиза СИНТО по Ideco UTM и NGFW

Александр Евгеньевич Кудашкин успешно прошел сертификацию и получил статус технического специалиста по продуктам Ideco UTM и Ideco NGFW.

 

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

 

• схемы сети;
• фактического профиля трафика;
• требуемых механизмов защиты;
• VPN;
• производительности;
• отказоустойчивости;
• интеграции с действующей инфраструктурой;
• пилотного тестирования.

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

Главное

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

Правильная последовательность выглядит так:

архитектура сети → профиль трафика → функции безопасности → соединения и VPN → требования к отказоустойчивости → интеграции → производительность → конкретная модель.

Главный практический принцип:

NGFW нужно подбирать по производительности в предполагаемом рабочем режиме, а не по максимальной цифре Firewall Throughput.

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

Часто задаваемые вопросы

Чем UTM отличается от NGFW?
UTM объединяет несколько средств сетевой защиты в одном шлюзе. Для NGFW характерны расширенный анализ прикладного трафика, DPI, IPS и возможность анализа TLS-трафика. При этом функциональность современных продуктов пересекается, поэтому при выборе лучше сравнивать конкретные возможности и производительность.

Можно ли выбрать NGFW по скорости интернет-канала?
Только если канал действительно отражает всю нагрузку, что бывает не всегда. Нужно учитывать также трафик между сегментами, VPN и режим работы защитных функций.

Что важнее – Firewall Throughput или NGFW Throughput?
Если устройство будет работать с IPS, контролем приложений и другими механизмами, для оценки ближе показатель комплексного режима NGFW. При этом необходимо учитывать методику тестирования конкретного производителя.

Всегда ли нужна SSL/TLS-инспекция?
Нет. Ее применение определяется политикой безопасности и характером трафика. Для части ресурсов могут потребоваться исключения. Ideco предусматривает как расшифровку TLS-трафика, так и исключения из нее.

Всегда ли нужен кластер NGFW?
Нет. Он нужен, если отказ одного устройства создает недопустимую потерю доступности. Требования к HA определяются архитектурой конкретной инфраструктуры.

Если бюджет ограничен, экономичной альтернативой поэтапной модернизации может стать модульный ЦОД: заводская готовность, быстрый ввод и поэтапное масштабирование снижают капитальные затраты и сроки. Пример решения на 10 стоек.

Возраст оборудования не определяет приоритет

Предположим, на площадке есть:

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

Если строить программу только по возрасту, первым под замену попадет кондиционер. Но для надежности объекта более важными могут оказаться ИБП и контроллер.

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

1. Последствия отказа – что именно перестанет работать.
2. Фактическое состояние – есть ли повторяющиеся ошибки, отклонения и признаки деградации.
3. Резервирование – способен ли резерв принять сегодняшнюю нагрузку.
4. Ремонтопригодность – насколько быстро можно восстановить систему.
5. Влияние на развитие – блокирует ли узел утвержденное увеличение нагрузки.

Таким образом, старое оборудование и критичный технический риск – не одно и то же.

Проверять нужно реальное резервирование

Проектная схема могла предусматривать резерв, который со временем фактически исчез.

Например, четыре агрегата охлаждения изначально работали так, что для расчетной нагрузки требовались три, а четвертый оставался резервным. После увеличения ИТ-нагрузки для нормальной работы стали необходимы почти все четыре агрегата.

Физически система не изменилась, но прежнего запаса уже нет.

Такая ситуация возможна не только с охлаждением, но и с ИБП, генераторами, трансформаторами, насосами и распределением питания.

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

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

Ремонтопригодность – отдельный фактор риска

Исправное сегодня оборудование может оказаться проблемным после первого серьезного отказа.

Перед решением о его сохранении необходимо выяснить:

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

Изменившиеся цепочки поставок уже заставили российские проекты учитывать универсальность решений и уменьшать жесткую зависимость от отдельных производителей. В отраслевой аналитике также отмечалось увеличение сроков ожидания части оборудования после смены поставщиков и логистических схем.

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

Приоритет замены становится высоким, когда одновременно совпадают несколько условий:

критичный узел + нет полноценного резерва + сложно получить ЗИП + восстановление нельзя гарантировать в приемлемый срок.

Как сократить бюджет без увеличения риска

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

Не обязательно модернизировать весь машинный зал

Если новая нагрузка требуется только в одной части ЦОД, сначала нужно определить, можно ли усилить конкретную зону.

Например, ограничением могут быть:

• локальная мощность распределения;
• количество доступных подключений;
• возможности охлаждения конкретного ряда;
• свободное пространство под инженерное оборудование.

В этом случае точечная модернизация может оказаться экономичнее полной перестройки объекта.

Но локальное решение оправдано только тогда, когда соседние инженерные системы способны принять изменение. ЦОД – взаимосвязанный комплекс: дополнительная электрическая мощность неизбежно влияет на распределение, тепловыделение, охлаждение и режимы резервирования.

ЗИП вместо преждевременной замены

Иногда главным риском является не состояние всей установки, а отсутствие одного критичного компонента.

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

При этом имеет смысл учитывать:

• последствия отказа детали;
• наличие резервного пути;
• реальный срок поставки;
• историю отказов;
• возможность использовать одну запасную позицию для нескольких однотипных устройств.

ЗИП должен закрывать конкретный риск восстановления, а не превращаться в склад оборудования «на всякий случай».

Не путать экономию с отсрочкой расходов

Сокращение текущего CAPEX само по себе еще не означает снижение стоимости модернизации.

Предположим, уже известно, что через два года планируется увеличение нагрузки, а выбранное сейчас оборудование этот рост не поддерживает. Более дешевый вариант позволит сократить текущую смету, но затем потребуется повторно проектировать, закупать оборудование, выполнять монтаж и переключения.

Это не экономия, а перенос части расходов на следующий этап.

Для значимых решений поэтому имеет смысл сравнивать не только цену закупки, но и:

• срок использования решения;
• стоимость следующего расширения;
• необходимость повторных работ;
• эксплуатационные затраты;
• возможность сохранить оборудование на следующем этапе.

ГОСТ Р 70627-2023 действует с 1 марта 2023 года и устанавливает требования к составу и содержанию технической концепции инженерной инфраструктуры ЦОД. Сам подход технической концепции предполагает обоснование выбранного решения, а не только формирование перечня оборудования.

На чем экономить нельзя

✔ Резервирование

Если отказ элемента приводит к остановке критичной нагрузки, исключение резерва ради сокращения сметы просто переносит финансовый риск из CAPEX в эксплуатацию.

При этом резервирование должно соответствовать реальным требованиям конкретного объекта – максимальный уровень не является самоцелью.

✔ Подготовка переключений

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

До критичных переключений должны быть определены:

• исходное состояние;
• последовательность действий;
• контрольные параметры;
• условия прекращения операции;
• порядок возврата к исходной конфигурации.

✔ Испытания

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

ГОСТ Р 58811-2020 распространяется на инженерную инфраструктуру ЦОД в России и устанавливает стадии ее создания, этапы внутри стадий и содержание выполняемых работ.

✔ Документация

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

Поэтому актуальная рабочая и исполнительная документация – не формальность, а часть ремонтопригодности объекта.

Когда точечная модернизация перестает быть выгодной

Локальный подход работает, пока изменения можно разделить на относительно независимые задачи.

Например:

нужно добавить ИТ-мощность → требуется усилить ИБП → существующее распределение не рассчитано на новую нагрузку → увеличивается тепловыделение → нужно менять охлаждение → для инженерного оборудования не хватает места.

В такой ситуации набор небольших проектов фактически превращается в комплексную реконструкцию.

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

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

Что проверить перед утверждением бюджета

Перед формированием программы модернизации достаточно получить ответы на восемь ключевых вопросов:

1. Какие узлы могут привести к остановке критичной нагрузки?
2. Сохранилось ли резервирование при фактической нагрузке?
3. Какие повторяющиеся дефекты уже выявлены?
4. Какие критичные системы сложно быстро восстановить?
5. Для какого оборудования отсутствует необходимый ЗИП?
6. Какие узлы ограничивают утвержденное развитие?
7. Какую часть существующей инфраструктуры можно безопасно сохранить?
8. Можно ли разделить работы на законченные этапы без последующей переделки?

Если на эти вопросы нет достоверных ответов, сокращать смету преждевременно. Сначала нужно установить фактическое состояние и зависимости инженерных систем.

Главное

Модернизация ЦОД с ограниченным бюджетом – это не полная реконструкция, из которой просто убрали самые дорогие позиции.

Задача состоит в другом – получить максимальное снижение технического риска при доступном объеме инвестиций.

Оптимальная последовательность:

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

Если же изменения питания, распределения, охлаждения, автоматики и размещения начинают зависеть друг от друга, точечную модернизацию уже нужно сравнивать с комплексной реконструкцией действующего ЦОД.

Часто задаваемые вопросы

Что модернизировать в ЦОД в первую очередь?
То, отказ чего создает наибольший риск для критичной нагрузки: единые точки отказа, потерянное резервирование, выявленные критические дефекты и трудно восстанавливаемые узлы.

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

Нужно ли менять оборудование после прекращения поддержки производителя?
Не автоматически. Нужно оценивать критичность, наличие резерва, ЗИП, ремонтопригодность и последствия возможного отказа.

Можно ли модернизировать ЦОД поэтапно?
Да, если каждый этап заканчивается полноценным работоспособным состоянием и последующие работы не требуют переделывать уже выполненные решения.

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

Источники и нормативная база

• ГОСТ Р 58811-2020 «Центры обработки данных. Инженерная инфраструктура. Стадии создания» – действующий национальный стандарт, введен 1 августа 2020 года.
• ГОСТ Р 70627-2023 «Центры обработки данных. Инженерная инфраструктура. Документация. Техническая концепция. Требования к составу и содержанию» – действует с 1 марта 2023 года.
• Исследование CHINT и Аналитического центра ИКС, 2026 – опрос представителей более 50 российских компаний по состоянию и развитию систем электропитания ЦОД.
• «Российский рынок коммерческих ЦОД 2025» – исследование проведено в июле–сентябре 2025 года; использованы данные о сроках ввода площадок, финансировании и изменении цепочек поставок оборудования.

СИНТО выполняет ее в рамках направления строительства ЦОД для ИИ: от обследования и расчета нагрузок до пусконаладки и сервисной поддержки.

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

1. С какого числа действует закон об ИИ?

Федеральный закон № 243-ФЗ вступает в силу 1 сентября 2026 года. Критерии суверенных и национальных БФМ, обязанности разработчиков и ряд других прикладных положений начинают применяться с 1 марта 2027 года.

2. Обязательно ли размещать ИИ-инфраструктуру в России?

Не для любой ИИ-системы.

Для модели, претендующей на статус суверенной или национальной БФМ, подготовка ответов пользователям и хранение данных должны обеспечиваться в ЦОД на территории Российской Федерации, принадлежащем российскому юридическому лицу.

243-ФЗ не содержит общего требования размещать в России абсолютно всю вычислительную инфраструктуру любой компании, использующей ИИ.

3. Нужно ли обучать модель в России?

Прямого общего требования проводить обучение БФМ на территории России статья 6 не содержит.

Требование локализации в рассматриваемой норме относится к подготовке ответов пользователям и хранению данных.

4. Касается ли закон компании, которая использует готовые ИИ-сервисы?

Закон регулирует разработку, внедрение и применение БФМ, однако обязанности статьи 8 и критерии статусов суверенной и национальной модели относятся прежде всего к разработчикам и самим моделям.

Само использование готового сервиса не делает компанию разработчиком БФМ.

5. Обязательно ли строить собственный ЦОД?

Нет.

Из закона не следует требование обязательно владеть собственным ЦОД. Для соответствующих статусов необходимо, чтобы используемый центр обработки данных располагался в России и принадлежал российскому юридическому лицу, отвечающему критериям закона.

Поэтому возможны как собственная площадка, так и размещение в подходящем коммерческом ЦОД.

6. Какие штрафы предусмотрены 243-ФЗ?

Собственных штрафов закон не устанавливает. Статья 11 предусматривает ответственность в соответствии с действующим законодательством Российской Федерации.

Источники

• Федеральный закон от 26 июля 2026 года № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации».
• Федеральный закон от 31 июля 2020 года № 258-ФЗ «Об экспериментальных правовых режимах в сфере цифровых инноваций в Российской Федерации».