Для объектов I-II категории нет единого списка мер — он индивидуален для каждой ИС и определяется разработчиком модели угроз из сотен возможных требований ФСТЭК. Ключ — правильно выбрать из общего перечня и адаптировать под риски, а не пытаться закрыть все пункты подряд. https://seberd.ru/5393
От категории — к реальным действиям
Определение категории значимости объекта информатизации — лишь первый шаг. Главный вопрос, возникающий после присвоения категории I или II, — что делать дальше? Приказ ФСТЭК России № 31 устанавливает не единый для всех список обязательных мер, а систему, основанную на выборности и глубоком анализе. Требования сгруппированы в 15 групп — от управления доступом до процедур восстановления. Но для каждой информационной системы разработчик модели угроз выбирает только те требования, которые необходимы и достаточны для нейтрализации конкретных угроз безопасности информации.
Главный принцип — не количество, а адресность
Распространённое заблуждение: присвоена высокая категория — значит, нужно выполнять все возможные требования, что максимально трудоёмко и дорого. Подход ФСТЭК иной. Меры защиты выбираются на основании сопоставления состава актуальных угроз, выявленных в модели, с возможностями, которые предоставляет то или иное требование для их парирования. Таким образом, набор мер для двух разных систем, даже одной категории, может существенно отличаться в зависимости от их архитектуры, обрабатываемых данных и условий эксплуатации.
Например, для системы, работающей в изолированном сегменте без выхода в сеть общего пользования, требования к межсетевым экранам или системам обнаружения вторжений будут менее приоритетны, чем для веб-сервиса, доступного извне. Адресный подход позволяет создать эффективную защиту без избыточных затрат.
Базовые группы требований для I и II категорий
Несмотря на выборность, некоторые группы требований становятся де-факто обязательными для объектов I-II категорий из-за типичности угроз.
Идентификация, аутентификация и управление доступом
Это ядро любой системы защиты. Практически для всех систем высоких категорий потребуется реализация строгих правил учёта пользователей, применения стойких механизмов аутентификации (например, двухфакторной для привилегированных учётных записей) и детального разграничения прав доступа по принципу минимальных привилегий.
Регистрация событий безопасности и расследование инцидентов
Без качественного журналирования невозможно ни обнаружить атаку, ни расследовать инцидент. Требования к системам сбора, хранения и анализа журналов для I-II категорий обычно включают централизованное ведение логов, защиту их от модификации, хранение в течение значительного срока (от 6 месяцев до нескольких лет) и регулярный анализ.
Защита среды виртуализации и технических средств
Если система работает в виртуальной среде, что стало стандартом для российских ЦОД, к ней применяется отдельный блок требований. Он направлен на предотвращение угроз, специфичных для виртуализации: компрометации уровня гипервизора, утечки данных между виртуальными машинами или захвата ресурсов.
Для физических серверов и сетевого оборудования акцент смещается на контроль конфигураций (запрет несанкционированных изменений параметров безопасности), управление аппаратными ключами и защиту от несанкционированного доступа к оборудованию.
Защита информации при её передаче по каналам связи
Передача данных, особенно за пределы контролируемой зоны, требует применения криптографических средств. Для высоких категорий это не просто рекомендация, а часто обязательное требование. Использование VPN, настройка TLS для веб-трафика с использованием российских алгоритмов — типичные примерами реализации.
От требований к практической реализации: ключевые сложности
Проблема перехода от текста требований к работающей инфраструктуре — основная для многих организаций.
Интеграция в существующие процессы
Многие меры — не просто «поставить софт». Усиление аутентификации требует интеграции с Active Directory или другими каталогами. Внедрение SIEM-системы — настройки источников событий и правил корреляции. Построение отказоустойчивой архитектуры — перепроектирования схемы сети и системы хранения данных. Фактически, выполнение требований становится проектом по модернизации ИТ-ландшафта.
Подбор средств защиты информации (СЗИ)
Рынок российских СЗИ разнообразен. Для каждой задачи (например, межсетевого экранирования или обнаружения вторжений) есть несколько продуктов, которые могут соответствовать требованиям ФСТЭК. Выбор зависит не только от функциональности, но и от возможности интеграции с другими системами, качества поддержки, требований к производительности и бюджета. Важно, чтобы средство имело все необходимые документы (сертификаты соответствия, заключения по безопасности) для применения в ИС соответствующей категории.
Документальное оформление
Каждая реализованная мера должна быть подтверждена документально. Это не только сами настройки оборудования или скриншоты интерфейсов. Это — внутренние распорядительные документы (положения, регламенты), технические проекты, отчёты о тестировании и акты ввода в эксплуатацию. Комплект документов доказывает, что меры не только внедрены, но и приняты в эксплуатацию, то есть работают и управляются. Это критически важно при проверках.
Не только технические меры: организационные требования
Защита объекта I-II категории не ограничивается техникой. Значительную часть составляют организационные меры, закреплённые внутренними документами.
- Регламентация работы с персоналом: порядок приёма и увольнения, обучение по информационной безопасности, правила работы с коммерческой тайной, анкетирование.
- Планирование и обеспечение непрерывности: для систем I-II категории обязательно наличие плана восстановления после сбоев и атак, регулярное резервное копирование и тестирование процедур восстановления.
- Управление конфигурациями и изменениями: строгий процесс внесения любых изменений в защищаемую систему, ведение реестра конфигураций, предотвращение несанкционированных правок.
Без отлаженных организационных процессов даже самые современные технические средства не обеспечат требуемого уровня безопасности.
Подход при проверке
Специалист, проводящий проверку выполнения требований, будет смотреть не на формальное наличие того или иного программного средства. Его задача — оценить систему защиты в комплексе. Он проверит:
- Обоснованность выбора: как выбранные меры связаны с угрозами из утверждённой модели.
- Корректность реализации: настроено ли средство защиты в соответствии с его документацией и рекомендациями ФСТЭК.
- Эффективность работы: ведутся ли журналы, срабатывают ли правила, проводятся ли регулярные оценки.
- Полноту документирования: можно ли по документам восстановить картину действующей системы защиты.
Поэтому подготовка к проверке, это не создание «липовой» отчётности, а системная работа по приведению защиты в соответствие с выбранными требованиями и грамотному фиксированию этого соответствия.
Итог: адаптировать, а не копировать
Работа с объектами I и II категории значимости требует отказа от поиска универсального шаблона. Конечный набор мер защиты всегда индивидуален. Успех зависит от корректно разработанной модели угроз, грамотного выбора и адаптации требований из приказа № 31 под специфику конкретной информационной системы, а затем — от качественной инженерной реализации и организационного сопровождения процесса. Эта работа сложнее, чем формальное «выполнение всех пунктов», но именно она приводит к созданию реально работающей, а не виртуальной системы защиты.