«Выбор baseline, это не технический процесс, это поиск точки равновесия между безопасностью, бизнесом и здравым смыслом. Многие ошибочно начинают с шаблона, но правильно начать с ответа на один вопрос: «За что нас реально оштрафуют, и что мы физически готовы поддерживать?»»
Что такое baseline в мире 152-ФЗ и ФСТЭК
Baseline (базовая линия безопасности, базовый уровень), это формализованный набор требований и настроек, которые система должна удовлетворять «по умолчанию». В контексте российского регулятора это не абстрактный «уровень защиты», а конкретный список проверяемых параметров.
ФСТЭК не выдаёт универсальных baseline’ов. Вместо этого регулятор публикует профили защиты (для СВТ — средств вычислительной техники) и требования руководящих документов (РД). Baseline для вашей организации, это производная от этих документов, адаптированная под ваш технологический стек, процессы и допустимый уровень риска.
Ключевое заблуждение — воспринимать baseline как статичный чек-лист, который можно «установить и забыть». На самом деле это динамичный каркас, требующий регулярного пересмотра. В нём зашита базовая гипотеза о том, какие угрозы для вас актуальны.
Зачем он нужен: не только для проверяющих
Формальная причина создания baseline — соответствие требованиям 152-ФЗ и приказов ФСТЭК, что является обязательным условием для легальной обработки персональных данных или работы с государственной информацией.
Однако практическая ценность глубже:
- Измеримость безопасности. Baseline превращает абстрактную «защищённость» в бинарное состояние: «соответствует / не соответствует». Это позволяет объективно оценивать риски при вводе новых систем.
- Ускорение процессов. Наличие утверждённого baseline позволяет ИБ-службе не тратить время на обсуждение каждого параметра для каждого сервера. Инженеры разворачивают системы по готовому шаблону.
- Доказательная база. При проверке вы показываете не просто кучу разрозненных политик, а единый системный подход к построению защищÿнной среды.
- Основа для автоматизации. Базовый уровень, это исходные данные для средств контроля конфигурации (например, Chef, Ansible, собственные скрипты), систем мониторинга целостности и сканеров уязвимостей.
С чего начать: отправные точки вместо шаблонов
Начинать с поиска «готового baseline под ФСТЭК» — тупиковый путь. Такой документ либо не существует, либо будет настолько общим, что его применение потребует таких же трудозатрат, как и разработка с нуля.
Правильная последовательность действий:
1. Определите перечень нормативных документов
Ответьте на вопрос: под действие каких именно требований вы попадаете? Это зависит от типа обрабатываемой информации и используемых систем. Основные источники:
- Для СВТ: Профили защиты ФСТЭК России. Определите, каким профилям соответствуют ваши серверы, рабочие станции, МФУ, сетевые устройства.
- Для ПО: Требования к защите информации, не содержащей сведения, составляющие государственную тайну (серия РД ФСТЭК). Например, РД ФСТЭК, устанавливающие требования к межсетевым экранам, СКЗИ, операционным системам.
- Для ПДн: Приказы ФСТЭК России № 21, 31, 17 и др., устанавливающие уровни защищённости и соответствующие меры.
Составьте таблицу соответствия: «Наш актив — применимый документ ФСТЭК — класс/уровень». Это основа основ.
2. Инвентаризация и классификация активов
Baseline нельзя строить в отрыве от реальной инфраструктуры. Необходимо чётко понимать:
- Какие у вас есть типы систем (веб-серверы, СУБД, файловые хранилища, рабочие станции бухгалтерии, рабочие станции разработчиков)?
- Какую информацию они обрабатывают (персональные данные, коммерческая тайна, общедоступные данные)?
- Каков их жизненный цикл (виртуальная машина, железный сервер, контейнер)?
Грубая ошибка — пытаться применить один baseline ко всему. Baseline для внешнего веб-сервера и для внутреннего контроллера домена будут радикально отличаться.
3. Оценка реализуемости и рисков
Возьмите требования из профилей защиты и РД. Каждое требование необходимо оценить с двух сторон:
| Требование из РД | Техническая реализуемость в нашей среде | Бизнес-риск неприменения | Решение |
|---|---|---|---|
| «Минимальная длина пароля — 12 символов» | Реализуемо технически, но вызовет шквал обращений в службу поддержки из-за сброса паролей. | Риск нарушения доступности, рост нагрузки на службу ИТ. Риск применения санкций ФСТЭК минимален, если в системе нет ПДн высокого УЗ. | Для систем с ПДн высокого УЗ — применяем. Для остальных — оставляем 8 символов, но добавляем требование к сложности и регулярной смене. |
| «Автоматическое блокирование учётной записи после 3 неверных попыток входа» | Реализуемо везде. Для внешних систем может привести к само-DoS при атаке подбора. | Высокий риск недоступности для легитимных пользователей. | Применяем, но с увеличенным счётчиком (10 попыток) для внешних систем и настройкой автоматической разблокировки через 15 минут. |
Этот этап — искусство компромисса. Цель — не слепо выполнить все 100% требований, а осознанно принять решение о выполнении, модификации или отказе от каждого, задокументировав обоснование.
Как структурировать документ baseline
Baseline, это рабочий документ, а не отчёт для галочки. Его структура должна быть ориентирована на практическое применение инженерами и администраторами.
- Раздел 1: Область действия и классификация систем. Чёткое описание, к каким типам систем (Windows Server 2022, Астрав Линукс, 1С-сервер) применяется данный baseline.
- Раздел 2: Общие требования. Политики, единые для всех систем: управление учётными записями (создание, блокировка, удаление), правила парольной защиты, порядок аудита и логирования.
- Раздел 3: Специфические требования по типам систем. Самая объёмная часть. Разбивается на подразделы:
- Базовые настройки ОС: Конфигурация реестра Windows, параметры sysctl в Linux, настройки локальных политик безопасности.
- Сетевая безопасность: Настройка и конфигурация встроенного или стороннего межсетевого экрана, отключение неиспользуемых сетевых служб и портов.
- Защита от вредоносного ПО: Требования к установке и настройке антивирусных средств, порядок обновления сигнатур.
- Резервное копирование и восстановление: Политики для встроенных или сторонних средств бэкапа (частота, глубина хранения, тестирование).
- Раздел 4: Процедуры: Порядок развёртывания новой системы в соответствии с baseline, процедура регулярной проверки соответствия, процесс внесения изменений в сам baseline.
- Приложения: Конкретные скрипты для проверки (PowerShell, Bash), конфигурационные файлы для Ansible, ссылки на шаблоны Group Policy Objects.
Инструменты для поддержания и проверки baseline
Бумажный baseline бесполезен. Его сила — в автоматизированном контроле. Рассмотрите следующие инструменты и подходы:
- Средства контроля конфигурации: Ansible, Chef, Puppet. Они не только приводят систему в соответствие с baseline при развёртывании, но и могут регулярно проводить «дрейф-анализ», выявляя несанкционированные изменения.
- Сканеры уязвимостей и проверки соответствия: Многие сканеры (например, MaxPatrol) имеют встроенные политики проверки, основанные на требованиях ФСТЭК. Их можно адаптировать под свой baseline.
- Скрипты собственной разработки: Для специфичных проверок, не охваченных стандартными средствами. Например, скрипт, проверяющий наличие и актуальность конкретного СОК на сервере приложений.
- Система управления конфигурациями (CMDB): Она должна хранить атрибут «Требуемый baseline» для каждого актива, что позволяет автоматически назначать задачи на проверку и строить сводные отчёты.
Важно не просто выбрать инструмент, а настроить процесс: кто и как часто запускает проверки, куда поступают результаты, кто и в какие сроки устраняет отклонения.
Типичные ошибки при выборе и внедрении
- Создание baseline «на все случаи жизни». Один документ пытается покрыть и промышленный сервер, и смартфон сотрудника. В итоге он становится настолько общим, что его невозможно применить.
- Копирование baseline другой организации без адаптации. Их технологический стек, аппетиты к риску и трактовка требований регулятора могут кардинально отличаться от ваших.
- Фокус только на технических системах. Baseline должен распространяться и на организационные меры: порядок выдачи учётных записей, проведение инструктажей, физическую защиту носителей.
- «Установил и забыл». Появление новых угроз, выход обновлений ОС, изменение бизнес-процессов — всё это требует пересмотра baseline. Установите регулярный пересмотр документа (рекомендуется не реже раза в год).
- Отсутствие пилотного проекта. Не стоит сразу внедрять baseline на все 500 серверов. Выберите один тип системы (например, группу файловых серверов), отработайте на нём все процедуры — от применения до проверки и устранения замечаний. Это выявит скрытые проблемы до массового внедрения.
Итог: Baseline как процесс, а не проект
Выбор и внедрение baseline, это не разовая задача, которую можно закрыть за месяц. Это начало циклического процесса управления конфигурацией безопасности.
Успешный baseline, это документ, который живёт. Его обсуждают на планерках архитекторы, его используют инженеры при развёртывании, его проверяют автоматические скрипты, а его устаревшие положения регулярно пересматриваются. Он служит точкой отсчёта, которая позволяет двигаться от базового соответствия регулятору к построению зрелой, управляемой системы безопасности, адекватной реальным рискам вашего бизнеса.
Начните не с шаблона, а с инвентаризации и анализа. Ответьте на вопрос «что мы защищаем и от чего» в терминах конкретных требований ФСТЭК, и тогда baseline станет не бюрократической нагрузкой, а основным рабочим инструментом вашей ИБ-службы.