Таблица базовых мер не перечисляет инструменты. Она описывает архитектурные границы доверия, где каждый плюс или цифра меняет топологию контура, а пустая ячейка становится зоной для моделирования угроз. https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-12-aprelya-2026-g
Меходический документ открывают три типа специалистов. Архитектор ищет каркас для проектных решений. Аудитор проверяет соответствие ячеек классу. Руководитель не открывает файл, потому что матрица символов выглядит как бюрократический атлас. Разница между этими взглядами исчезает, когда инженер понимает механику таблицы. Три символа в каждой ячейке описывают разные уровни архитектурной проработки. Плюс означает обязательное выполнение. Цифра рядом с плюсом указывает на усиление, перечисленное в подразделе требований. Пустая ячейка не отменяет меру. Она переводит её в зону адаптации или компенсирующих мер. Регулятор вправе включить любую пустую меру в перечень обязательных, когда модель угроз подтверждает конкретный вектор компрометации.
Количество цифр в усилении прямо отражает сложность реализации. Идентификация пользователей везде стоит с одним плюсом. Базовая логика не меняется от класса к классу. Контроль целостности контейнерных сред для первого класса требует шести уровней усиления. Шесть уровней означают контроль хоста, проверку параметров оркестратора, сверку цифровых сигнатур в реестре, блокировку запуска повреждённых образов и непрерывный мониторинг. Контейнеры оказались самым усиливаемым разделом нормативки. Понимание этой механики позволяет проецировать таблицу на реальные контуры без потери смысла.
Идентификация пользователей и разграничение прав доступа
Идентификация пользователей обязательна для всех трёх классов. Аутентификация пользователей также включена в базовый набор везде. Первый класс требует усиления. Практика переводит этот пункт в строгую аутентификацию с аппаратными ключами и криптографическими сертификатами. Идентификация устройств и аутентификация устройств остаются пустыми для всех классов. Привязка сессии к аппаратному идентификатору появляется только при адаптации. Инженер включает эти меры, когда моделирование угроз выявляет вектор компрометации через чужое устройство с валидными учётными данными.
Управление доступом строится на моделях дискреционного, ролевого, мандатного или атрибутного контроля. Реализация модели управления доступом требуется для всех классов. Разграничение прав доступа подлежит усилению на высших классах. Управление учётными записями также требует усиления для второго и первого классов. Ограничение неуспешных попыток доступа включено в базовый набор везде. Усиление необходимо для высших классов. Умные системы анализируют источник запроса, время суток и поведенческие паттерны перед применением блокировки. Жёсткий счётчик ошибок создаёт вектор для отказа в обслуживании легитимных пользователей.
Ограничение параллельных сеансов отсутствует в базовом наборе для третьего класса. Мера появляется для второго класса и требует усиления первого уровня для первого класса. Блокирование сеанса при неактивности обязательна для всех трёх классов. Контроль действий до идентификации и аутентификации включён везде. Защита публичных интерфейсов требует регистрации анонимных запросов и базовой фильтрации. Настройка таймаутов параллельных сессий исключает риск утечки через забытые окна.
Предупреждение пользователя при доступе и оповещение о предыдущем входе отсутствуют в базовом наборе для всех классов. Банковские приложения показывают время последнего входа как норму. В государственных информационных системах базовый набор этого не требует. Эти меры попадают в адаптированный набор при моделировании угроз, связанных с компрометацией учётных данных через фишинг или кражу паролей.
Регистрация событий безопасности без перегрузки инфраструктуры
Определение событий для регистрации включено в базовый набор для всех классов. Усиление требуется для всех трёх классов, но в разном объёме. Третий класс требует одного уровня усиления. Второй класс требует двух уровней. Первый класс требует трёх уровней. На практике третий уровень означает запись привилегированных команд, централизованный мониторинг всех сегментов и передачу событий в агрегатор с контролем полноты потока. Инженер не просто собирает логи. Архитектура должна гарантировать невозможность пропустить событие с привилегированным доступом.
Анализ событий и реагирование обязательны везде. Генерация временных меток, требования к сбору и хранению, реагирование на сбои включены в базовый набор без дополнительных усилений. Синхронизация времени всех узлов с доверенным источником исключает разрыв в метках. Протокол точного времени с криптографической аутентификацией пакетов защищает от подмены. Сбор и хранение данных о событиях защищаются шифрованием на этапе записи. Логи сохраняются на выделенном носителе с ограниченным доступом. Изменение записей блокируется на уровне файловой системы или базы данных. Первый класс требует подписи журналов электронной подписью уполномоченного компонента. Проверка целостности выполняется автоматически при каждом запросе аналитика.
Реагирование на сбои при регистрации реализуется через дублирующие каналы. Локальные буферы продолжают накопление при потере связи с центральным агрегатором. Данные передаются после восстановления соединения с проверкой контрольных сумм. Корреляция разнородных источников превращает набор сигналов в цепочку инцидента. Порядок реализации в проекте должен следовать зависимости от определения событий к их хранению. Команда потратит месяц на настройку хранилища, если сначала не определила, что именно фиксировать.
Виртуализация и контейнерные среды на уровне архитектуры
Доверенная загрузка средств виртуализации включена в базовый набор для всех классов. Усиление требуется для второго и первого классов. Контроль целостности средств виртуализации и виртуальных машин обязателен везде. Усиление требуется для высших классов. Регистрация событий безопасности в среде виртуализации, управление доступом, резервное копирование включены в базовый набор без усилений. Ограничение программной среды требует усиления только для первого класса. Защита памяти, идентификация и аутентификация в среде виртуализации обязательны для всех классов. Управление виртуальными машинами отсутствует в базовом наборе для третьего класса. Мера появляется для второго и первого классов. Практика означает, что в системе третьего класса нет требования документировать жизненный цикл машин. Виртуальные машины могут накапливаться и создавать непрозрачный периметр. Для высших классов оператор обязан вести реестр и контролировать состояние каждой машины.
Контроль целостности в контейнерных средах включён в базовый набор для всех классов. Усиление для третьего класса отсутствует. Второй класс требует двух уровней усиления. Первый класс требует шести уровней усиления. Блокировка запуска образов с нарушенной целостностью становится обязательной на высших классах. Регистрация событий безопасности, управление доступом, резервное копирование обязательны везде без усилений. Изоляция контейнеров обязательна для всех классов. Усиление требуется для второго и первого классов. Управление образами и выявление уязвимостей включены в базовый набор. Усиление уязвимостей требуется для высших классов. Сканеры образов интегрируются в конвейер поставки до публикации в реестр. Пространства имён ядра обеспечивают базовую изоляцию. Микровиртуализация добавляет аппаратный уровень защиты для первого класса. Ядро при этом уже не является общим ресурсом между контейнерами. Уязвимость в escape через ядро перестаёт быть применимой.
Шесть уровней усиления контроля целостности контейнеров охватывают проверку хоста, параметров среды запуска, контроль целостности образов на уровне реестра, проверку цифровых подписей перед развёртыванием, блокировку запуска повреждённых контейнеров и непрерывный мониторинг. Организация использует оркестратор в системе первого класса и не реализовала все шесть уровней. Формально соответствие отсутствует по одной из ключевых мер. Проекты часто недооценивают этот раздел, потому что контейнеры воспринимаются как лёгкая технология.
Сетевое экранирование, сегментация и устойчивость к отказам
Сегментация сети включена в базовый набор для всех классов. Усиление требуется только для первого класса. Организация демилитаризованной зоны, контроль сетевого доступа и фильтрация трафика обязательны везде без усилений. Маскирование системы и создание ложных систем отсутствуют в базовом наборе для всех классов. Технологии honeypot и deception рассматриваются как активные методы. Они применяются при адаптации, когда моделирование угроз показывает высокую вероятность целенаправленных атак с разведкой инфраструктуры.
Обнаружение и предотвращение вторжений в сегментах обязательно для всех трёх классов без усилений. Обнаружение на периметре для второго и первого классов требует усиления. Логика разделяет внутренние аномалии и периметровый контроль. IDS/IPS в сегментах выявляет аномалии внутри уже скомпрометированной сети. Периметровый контроль для высших классов должен уметь коррелировать события с другими источниками. Защита от атак на отказ в обслуживании при доступе внешних пользователей к прикладным сервисам включена в базовый набор для всех классов. Контроль и фильтрация входящего трафика требуют усиления только для первого класса. Мониторинг состояния сервисов и ограничение нагрузки обязательны везде. Балансировка нагрузки и поддержка резерва пропускной способности отсутствуют в базовом наборе для третьего класса. Мера появляется для второго и первого классов.
Защита каналов связи и сетевого взаимодействия включает защиту данных при передаче, контроль атрибутов безопасности, контроль доступа к внешним ресурсам. Все эти меры обязательны для всех классов. Контекстная проверка исходящего трафика в базовом наборе отсутствует для всех классов. Глубокий анализ пакетов с анализом содержимого не входит в базовый набор. Организации закрывают вектор утечки данных через скрытые каналы через механизм адаптации, а не через базовые требования.
Веб-интерфейсы, API и сервисы электронной почты
Защита пользовательских данных в веб-приложениях, регистрация событий безопасности, проверка файлов на вредоносное ПО обязательны для всех классов без усилений. Управление доступом пользователей требует усиления для второго и первого классов. Контроль и фильтрация трафика веб-приложений требуют усиления только для первого класса. Практика означает переход от базовой фильтрации к анализу полезной нагрузки пользовательских запросов. Защита данных API требует усиления для второго и первого классов. Управление доступом пользователей и приложений, проверка на соответствие спецификации API обязательны для всех классов. Усиление проверки спецификации требуется только для первого класса.
Защита ящиков и сообщений электронной почты, управление доступом, защита от вредоносных вложений, защита от спама, защита метаданных обязательны для всех классов. Защита от фишинга требует усиления для второго и первого классов. Анализ вложений через замкнутые среды исполнения снижает риск выполнения скрытых скриптов. Блокирование заархивированных с паролями вложений до их проверки на наличие вредоносного кода становится стандартом для высших классов. Ретроспективный анализ ранее поступивших сообщений на наличие вредоносного программного обеспечения интегрируется в конвейер обработки почты.
Конечные узлы, мобильные устройства и интернет вещей
Управление доступом к конечным устройствам, обеспечение целостности программного обеспечения обязательны для всех классов без усилений. Антивирусная защита и обнаружение вторжений на конечных устройствах включены в базовый набор. Усиление требуется для второго и первого классов. Мониторинг процессов и состояния устройства обязателен везде. Контроль и фильтрация трафика на конечном устройстве отсутствует в базовом наборе для всех классов. Анализ и реагирование на события безопасности включены в базовый набор. Усиление требуется для высших классов. Host-based firewall, который в корпоративных сетях является частью стандартной конфигурации агента защиты, в базовом наборе не присутствует ни на одном классе. Меры появляются при адаптации.
Идентификация и аутентификация пользователей мобильных устройств включена в базовый набор. Усиление требуется для второго и первого классов. Управление доступом, антивирусная защита, контроль приложений, ограничение функциональности обязательны для всех классов без усилений. Обеспечение целостности мобильных устройств требует усиления для высших классов. Первый класс требует двух уровней усиления. Защита данных требует усиления только для первого класса. Регистрация, анализ и реагирование на события безопасности требуют усиления для второго и первого классов. Определение и контроль геопозиции отсутствуют в базовом наборе. Регулятор перекладывает решение о геофенсинге на организацию через механизм адаптации.
Идентификация и аутентификация устройств интернета вещей, управление доступом, контроль целостности обязательны для всех классов без усилений. Защита данных требует усиления для второго и первого классов. Регистрация, анализ и реагирование на события безопасности требуют усиления для высших классов. Сегментация сетей IoT от корпоративных контуров снижает риск бокового перемещения. Блокировка портов управления и отключение неиспользуемых протоколов уменьшают поверхность атаки. Идентификация и аутентификация точек беспроводного доступа включена в базовый набор. Усиление требуется только для первого класса. Управление доступом, защита пользовательских данных, контроль целостности, ограничение уровней сигналов обязательны для всех классов без усилений. Регистрация, анализ и реагирование на события безопасности требуют усиления для второго и первого классов.
Антивирусный контроль и адаптация базового набора
Антивирусная защита устройств, электронной почты и сетевого трафика обязательна для всех трёх классов без усилений. Применение замкнутой среды предварительного выполнения программ отсутствует в базовом наборе для всех классов. Инструмент, который команды безопасности считают стандартом для анализа вложений и подозрительных файлов, в нормативке является компенсирующей или адаптированной мерой. Регулятор не запрещает применять песочницу. Норматив не требует её внедрения в базовый набор.
Нормативный перечень задаёт минимальный уровень защиты. Реальная инфраструктура требует уточнения базового набора под архитектуру и бизнес-процессы. Усиление мер применяется там, где типовые средства не покрывают векторы угроз. Замена программного токена на аппаратный ключ снижает риск клонирования учётных данных. Введение дополнительных уровней журналирования оправдано в сегментах с персональными данными. Компенсирующие меры разрабатываются при невозможности прямого выполнения требования. Отказ от установки агента мониторинга на устаревшую систему компенсируется сетевым контролем трафика и изоляцией узла в отдельном сегменте. Проверка соответствия класса защищённости проводится до ввода системы в эксплуатацию. Тестирование включает проверку работоспособности механизмов аутентификации, корректности журналирования и устойчивости к типовым атакам. Настройка политик доступа проходит через несколько итераций. Изначально правила применяются в режиме наблюдения для сбора статистики. После анализа ложных срабатываний политики переводятся в блокирующий режим. Документация отражает фактическую конфигурацию. Схема сети, перечень узлов, правила фильтрации и маршруты резервирования обновляются при каждом изменении инфраструктуры.
Чек-листы архитектурных изменений при смене класса
Распространённое заблуждение состоит в том, что переход с третьего класса на второй сводится к добавлению нескольких мер к уже существующей системе. Усиления в ряде разделов требуют перепроектирования компонентов, а не их донастройки.
[√] Переход аутентификации к многофакторной схеме
[√] Реализация второго уровня усиления управления доступом
[√] Введение ограничения параллельных сеансов
[√] Расширение перечня регистрируемых событий до второго уровня
[√] Усиление контроля целостности гипервизора
[√] Добавление двух уровней усиления контроля целостности контейнерных образов
[ ] Реализация усиленной антивирусной защиты и IDS на конечных устройствах
[ ] Усиление IDS на периметре
[ ] Введение балансировки нагрузки и резерва пропускной способности
Ни один из пунктов не реализуется изменением конфигурационного файла. Реализация второго уровня усиления управления доступом требует пересмотра модели. Дискреционная модель уступает место атрибутному контролю для чувствительных объектов. Изменение затрагивает архитектуру авторизации целиком.
[√] Переход к строгой аутентификации с аппаратными носителями
[√] Реализация третьего уровня усиления записи событий с передачей в агрегатор
[√] Подпись журналов безопасности электронной подписью уполномоченного компонента
[√] Переход к доверенной загрузке гипервизора через аппаратный модуль
[√] Микровиртуализация или VM-изоляция контейнеров
[√] Выполнение всех шести уровней усиления контроля целостности контейнеров
[ ] Переход к режиму замкнутой программной среды в гипервизоре
[ ] Усиление сегментации сети
[ ] Расширенная фильтрация входящего трафика
[ ] Усиленная проверка API-запросов и веб-трафика
Усиление доверенной загрузки для первого класса до второго уровня предполагает аппаратный корень доверия. Модуль безопасности в составе сертифицированного средства становится обязательным. Без аппаратного модуля цепочка доверия к гипервизору разрывается при компрометации первичного загрузчика. Третий и второй класс допускают программную реализацию. Первый класс требует аппаратной поддержки.
Почему пустая ячейка важнее, чем кажется
Регулятор при аттестации вправе включить любую меру из пустых ячеек в перечень обязательных, когда модель угроз обосновывает включение. Организации, которые читают таблицу только как перечень обязательных действий, рискуют получить предписание на этапе проверки. Доработка обходится в несколько раз дороже изначального проектирования. Рабочий подход требует прохода по пустым ячейкам явно. Фиксация причины невключения меры в адаптированный набор формирует документированную позицию. Идентификация устройств пуста, потому что вектор через чужое устройство отсутствует в модели угроз. Такое решение фиксируется в документации. Применение песочницы пуста, потому что вложения от внешних отправителей не поступают в систему. Регулятор при проверке видит обоснованное решение. Разница принципиальная.
Методический документ описывает мероприятия и меры, привязанные к классам. Логика их применения сместилась в сторону процессного подхода. Ячейки новой таблицы напрямую наследуют логику старой версии. Сообщество аттестаторов продолжает уточнять трактовки. Методические разъяснения ожидаются в течение текущего года. Инженерная реализация превращает формальные пункты в работающие механизмы защиты. Архитектура системы должна выдерживать проверку временем, нагрузкой и изменяющимися условиями эксплуатации. Следующий шаг включает инвентаризацию текущих средств защиты, сопоставление их возможностей с требуемыми уровнями усиления и планирование поэтапной модернизации критичных контуров.