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

С одной стороны, программные ЦОДы значительно ускоряют бизнес-процессы и упрощают управление инфраструктурой. С другой стороны, российские регуляторы (ФСТЭК России, ФСБ и Росстандарт) предъявляют жесткие требования к обеспечению безопасности, надежности и соответствия национальным стандартам, особенно в сферах, затрагивающих критическую информационную инфраструктуру и обработку персональных данных.

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

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

1. Программно-определяемый ЦОД и российское законодательство

Что такое программно-определяемый ЦОД: краткий экскурс в технологию

Программно-определяемый ЦОД (Software-Defined Data Center, SDDC) — это инфраструктурный подход, при котором все элементы центра обработки данных, включая вычислительные ресурсы, сети, хранилища данных и безопасность, управляются программными средствами. Такой подход позволяет добиться гибкости, масштабируемости и высокого уровня автоматизации, существенно упрощая управление сложными инфраструктурами.

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

Место программно-определяемых ЦОДов в нормативном регулировании

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

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

Ключевые отличия программных ЦОДов от традиционных ЦОДов с точки зрения регулятора

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

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

• Применение сертифицированных программных компонентов (гипервизоры, системы виртуализации сети, СХД и средства защиты информации).

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

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

2. Нормативная база

Чтобы понять, каким образом государство регулирует эксплуатацию программно-определяемых ЦОДов, необходимо обратиться к ключевым документам ФСТЭК России. Именно они определяют, какие системы необходимо аттестовывать и  какие требования применяются к средствам защиты информации в системах

Приказ 55 ФСТЭК России задает правовую основу и правила функционирования системы сертификации средств защиты информации. В нем описаны состав участников системы (ФСТЭК как федеральный орган, органы по сертификации, испытательные лаборатории, заявители-производители), порядок подачи заявок, проведения испытаний, выдачи сертификатов соответствия, категории СЗИ подлежащих сертификации. Важно понимать, что этот приказ не регулирует аттестацию информационных систем — он про сертификацию средств защиты. То есть важен с точки зрения выбора продуктов, которые потом будут использоваться в системе защиты.

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

239 приказ ФСТЭК]] России устанавливает требования безопасности объектов критической информационной инфраструктурой (КИИ): банки, энергетические компании, операторы связи, транспортная инфраструктура и другие организации, чья деятельность связана с высокой степенью риска для государственной безопасности или общественной стабильности.

21 приказ ФСТЭК России устанавливает требования безопасности к информационных системам обработки персональных данных ( в том числе большого объема или особых категорий (например, медицинская информация или биометрические данные граждан).

17 приказ ФСТЭК России (117 приказ ФСТЭК России с 1 марта 2026 года), устанавливает требования к информационным системам государственных структур, ведомств и предприятий с государственным участием.

Модели угроз

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

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

Во-вторых, наличие модели угроз закреплено в нормативных требованиях ФСТЭК России: для государственных информационных систем, информационных систем персональных данных и объектов критической информационной инфраструктуры ее разработка — обязательное условие.

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

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

Типовая и индивидуальная модель угроз: в чем разница

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

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

3. Когда аттестация не нужна?

Когда аттестация не нужна и как это определить

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

Если система не подпадает под эти категории, прохождение аттестации не требуется. Например, корпоративные сервисы, которые используются исключительно для внутренних задач и не содержат критичных данных, могут работать без аттестата. То же самое касается сайтов, где не ведется обработка персональных данных, или тестовых контуров, предназначенных только для отработки функций без использования реальной информации. В случае, когда обрабатываются данные минимального уровня защищенности (УЗ-4), закон допускает ограничиться организационными и техническими мерами защиты без прохождения аттестации.

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

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

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

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

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

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

Ограничения и риски отсутствия аттестата

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

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

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

• В случае изменения бизнес-модели, необходимость аттестации неизбежно возникнет только в случае работы с ГИС.

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

4. Модель угроз для программно-определяемого ЦОДа

Программно-определяемый дата-центр (SDDC) принципиально меняет картину рисков по сравнению с классическим ЦОДом. Здесь все управление — от вычислений и сетей до систем хранения — вынесено в программный слой и централизовано через контроллеры и оркестраторы. Это удобно для автоматизации, но одновременно создает новые точки уязвимости.

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

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

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

Защита программно-определяемого ЦОДа

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

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

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

Безусловно необходимо регулярное обновление гипервизоров, SDN- и SDS-компонентов. Уязвимости в этих продуктах часто становятся целью атак, и задержка с патчами напрямую увеличивает риск компрометации. В совокупности такие меры позволяют не только выполнить формальные требования регуляторов, но и реально снизить вероятность критических инцидентов в программно-определенном дата-центре.

5. Процедура получения аттестата для программно-определяемого ЦОДа

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

Сначала организация определяет, что именно нужно аттестовать: границы информационной системы, состав компонентов, каналы взаимодействия. Для SDDC этот шаг особенно важен, потому что инфраструктура может быть распределенной и динамичной. Например, в границы объекта включаются гипервизоры, управляющие контроллеры (SDN, SDS, оркестраторы), подсистемы хранения и виртуальные сети.

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

Следующий этап — внедрение мер защиты. В SDDC это обычно включает установку сертифицированных средств защиты (межсетевые экраны, СЗИ НСД, криптосредства), настройку микросегментации внутри виртуальной сети, внедрение систем контроля целостности гипервизоров и администрируемых образов. После этого проводится предварительное тестирование: проверяется соответствие реализованных мер документации и требованиям ФСТЭК России.

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

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

Этапы аттестации программно-определяемого ЦОДа

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

Этап 1. Определение границ системы
Формулируется объект аттестации: какие элементы входят в SDDC (гипервизоры, SDN-контроллеры, подсистемы хранения, виртуальные сети, управляющие сервисы).

Этап 2. Разработка модели угроз и нарушителя
Фиксируются актуальные риски именно для виртуализированной среды: атаки на гипервизор, компрометация API, обход микросегментации, внедрение вредоносных шаблонов ВМ и контейнеров.

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

Этап 4. Реализация и настройка СЗИ
Внедряются сертифицированные средства защиты, настраивается микросегментация трафика, вводится контроль целостности гипервизоров и шаблонов образов, обеспечивается защищенный доступ к API.

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

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

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

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

Кто и как проверяет соответствие нормативам?

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

Проверка включает в себя:

• Анализ технической документации;

• Инструментальные испытания (тестирование функционала и безопасности);

• Аудит инфраструктуры (включая визиты экспертов и обследование объекта).

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

6. То есть все компоненты программно-определяемого ЦОД должны быть сертифицированы?

Не обязательно все компоненты для аттестации программно-определяемого ЦОДа должны быть сертифицированы. Более того, даже не все программно-определяемые ЦОДы должны быть аттестованы. Здесь важно напомнить про два разных процесса: сертификация и аттестация.

Сертификация касается только средств защиты информации (СЗИ) и некоторых видов программного обеспечения, которые прямо регулируются ФСТЭК России (например, ОС, средства виртуализации, межсетевые экраны, криптосредства). Сертификация проводится в аккредитованной лаборатории, и продукт после этого заносится в официальный реестр ФСТЭК России. Сертификат подтверждает, что средство может использоваться для защиты информации определенного уровня. Но при каждом изменении следует оповестить ФСТЭК России. Для серийного производства, срок сертификата – 5 лет.

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

Таким образом, сертифицировать все подряд в SDDC не нужно. Сертификаты требуются только для средств защиты информации, входящих в систему. А вся остальная инфраструктура — серверы, хранилища, СDN-компоненты — должна быть правильно описана в границах аттестуемого объекта и защищена этими средствами.

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

1. Аттестация всего комплекса целиком.
   Полная аттестация самого ЦОДа как комплексного решения — редкий и сложный случай, чаще применяемый в государственных структурах и организациях КИИ высокого уровня значимости. В этом случае проверке подлежит абсолютно вся инфраструктура, включая оборудование, гипервизоры, платформу управления (CMP), средства виртуализации и сетевые компоненты.

2. Аттестация отдельных элементов инфраструктуры.
   Чаще всего компании выбирают конкретные критически важные компоненты инфраструктуры (например, виртуализацию), которые имеют сертификат ФСТЭК России.

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

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

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

Что это значит на практике?

• Если ваша компания разрабатывает собственную платформу виртуализации или CMP и планирует активно продвигать ее на рынок, ориентируясь на государственные компании и КИИ, то ее сертификация по линии ФСТЭК становится значимым конкурентным преимуществом.

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

• Важно понимать, что ФСТЭК России требует четкой логики и прозрачности защищаемых контуров. Даже если CMP и платформа виртуализации не сертифицированы напрямую, должно быть ясно, как именно реализована безопасность инфраструктуры и как исключаются риски компрометации данных.

Заключение

Программно-определяемый ЦОД сам по себе не является проблемой для регулятора — ФСТЭК России оценивает не технологию как таковую, а то, насколько корректно она встроена в контур защиты. Аттестуется всегда система целиком, и ключевое требование здесь одно: использовать сертифицированные средства защиты и выстроить прозрачную модель безопасности.

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

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