Может привести к избыточным или недостаточным мерам Позволяет оптимально выбирать средства защиты Использование Подходит для типовых ИС и начального этапа Применяется для критически важных и сложных систем 3. Когда аттестация не нужна? Когда аттестация не нужна и как это определить Аттестация — это не универсальное требование для любой информационной системы, а строго регламентированная процедура, применяемая лишь в определенных случаях. Она обязательна для государственных информационных систем. Если система не подпадает под эти категории, прохождение аттестации не требуется. Например, корпоративные сервисы, которые используются исключительно для внутренних задач и не содержат критичных данных, могут работать без аттестата. То же самое касается сайтов, где не ведется обработка персональных данных, или тестовых контуров, предназначенных только для отработки функций без использования реальной информации. В случае, когда обрабатываются данные минимального уровня защищенности (УЗ-4), закон допускает ограничиться организационными и техническими мерами защиты без прохождения аттестации. Чтобы быстро определить необходимость аттестации, достаточно ответить на три вопроса. Обрабатываются ли в системе персональные данные — и если да, то к какому уровню они относятся? Является ли система государственной или объектом критической инфраструктуры? Содержит ли она сведения, отнесенные к государственной, служебной или иной охраняемой законом тайне? Если хотя бы на один вопрос ответ положительный, аттестация потребуется. Если же все ответы отрицательные, то формальной обязанности проходить ее нет. Типовые сценарии, при которых аттестация не обязательна Рассмотрим конкретные примеры, когда можно спокойно обойтись без прохождения аттестации: Компания разрабатывает программное обеспечение и использует программный ЦОД только для внутренних нужд и тестовых сред, при этом не собирая и не обрабатывая персональные данные. Малое или среднее предприятие использует собственный программно-определяемый ЦОД для работы с общими бизнес-данными, не попадающими под требования по защите информации от регуляторов (например, учетные и складские системы, внутренние CRM-системы). Облачный провайдер, предлагающий публичные услуги на коммерческой основе (например, виртуальные машины или веб-хостинг), не ориентированный на предоставление услуг организациям из категорий с обязательной сертификацией. Ограничения и риски отсутствия аттестата Тем не менее, даже в ситуациях, когда аттестация не обязательна, компании стоит использовать сертифицированные средства защиты и выстраивать базовые процессы кибербезопасности. Это не только снижает реальные риски инцидентов, но и повышает доверие клиентов и партнеров, что в современных условиях становится серьезным конкурентным преимуществом. Есть ряд рисков и ограничений, о которых следует помнить: Компания, выбравшая путь без сертификации, ограничивает себя в возможности работы с крупными корпоративными клиентами или госструктурами. В случае изменения бизнес-модели, необходимость аттестации неизбежно возникнет только в случае работы с ГИС. Отсутствие аттестата может осложнить взаимодействие с некоторыми крупными заказчиками или партнерами, которые по собственной инициативе или внутренним регламентам требуют наличие сертифицированных компонентов инфраструктуры даже там, где это не предписано законом. 4. Модель угроз для программно-определяемого ЦОДа Программно-определяемый дата-центр (SDDC) принципиально меняет картину рисков по сравнению с классическим ЦОДом. Здесь все управление — от вычислений и сетей до систем хранения — вынесено в программный слой и централизовано через контроллеры и оркестраторы. Это удобно для автоматизации, но одновременно создает новые точки уязвимости. Пример схемы технологических (архитектурных) уровней 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-компоненты — должна быть правильно описана в границах аттестуемого объекта и защищена этими средствами. Регулятор ориентируется в первую очередь на защищенность объекта в целом. При этом аттестация может проводиться в нескольких режимах: Аттестация всего комплекса целиком. Полная аттестация самого ЦОДа как комплексного решения — редкий и сложный случай, чаще применяемый в государственных структурах и организациях КИИ высокого уровня значимости. В этом случае проверке подлежит абсолютно вся инфраструктура, включая оборудование, гипервизоры, платформу управления (CMP), средства виртуализации и сетевые компоненты. Аттестация отдельных элементов инфраструктуры. Чаще всего компании выбирают конкретные критически важные компоненты инфраструктуры (например, виртуализацию), которые имеют сертификат ФСТЭК России. В этом подходе сертификация конкретных элементов позволяет подтвердить соответствие нормативам без необходимости сертифицировать весь комплекс инфраструктуры целиком. Использование наложенных сертифицированных средств защиты. В практике наиболее распространен и удобен именно такой подход. В этом случае сертификации по линии ФСТЭК подвергаются только наложенные средства защиты, которые обеспечивают выполнение требований регулятора по безопасности информации Если инфраструктура ЦОДа не подвергается отдельной сертификации, то применение наложенных сертифицированных средств защиты позволяет обеспечить соответствие требованиям регулятора без сертифицированной платформы виртуализации и CMP непосредственно. Что это значит на практике? Если ваша компания разрабатывает собственную платформу виртуализации или CMP и планирует активно продвигать ее на рынок, ориентируясь на государственные компании и КИИ, то ее сертификация по линии ФСТЭК становится значимым конкурентным преимуществом. Если же вы используете сторонние решения, то, как правило, гораздо проще и быстрее закрыть требования регуляторов путем использования уже сертифицированных наложенных средств защиты. Важно понимать, что ФСТЭК России требует четкой логики и прозрачности защищаемых контуров. Даже если CMP и платформа виртуализации не сертифицированы напрямую, должно быть ясно, как именно реализована безопасность инфраструктуры и как исключаются риски компрометации данных. Заключение Программно-определяемый ЦОД сам по себе не является проблемой для регулятора — ФСТЭК России оценивает не технологию как таковую, а то, насколько корректно она встроена в контур защиты. Аттестуется всегда система целиком, и ключевое требование здесь одно: использовать сертифицированные средства защиты и выстроить прозрачную модель безопасности. На практике это означает, что при выборе платформы виртуализации и систем управления облачной инфраструктурой важно опираться на решения, которые уже учитывают специфику российского регулирования. Такой подход позволяет ускорить подготовку к аттестации, снизить затраты и при этом сохранить все преимущества программно-определяемого ЦОДа. В этом смысле готовые пакеты решений, где виртуализация, CMP и средства защиты интегрированы между собой, дают компаниям серьезное конкурентное преимущество. Они не только закрывают технологические задачи, но и помогают пройти аттестацию без лишних рисков и бюрократических издержек. Теги: Source: https://habr.com/ru/companies/orion_soft/articles/965688/