“Подготовка к проверке ФСТЭК, это не про создание кипы новых бумаг. Это про то, как превратить уже существующие рабочие процессы и артефакты в доказательную базу. Самый эффективный путь — не писать с нуля, а систематизировать и осмыслить то, что уже есть.”
Многие воспринимают подготовку к проверке по 152-ФЗ и требованиям ФСТЭК как задачу по генерации документов. Создают политики, инструкции, регламенты, которых до этого не было. Это не только трудоёмко, но и создаёт риски: новые, «бумажные» процессы начинают жить отдельно от реальных, а при проверке это быстро вскрывается.
Настоящая подготовка начинается с инвентаризации того, что уже работает. Ваша ИТ-инфраструктура, настройки, журналы, процедуры обслуживания — всё это уже содержит ответы на большинство вопросов проверяющих. Задача — правильно это оформить и представить.
Почему новые документы, это ловушка
Создание документов «под проверку» кажется логичным шагом. Нет политики разграничения доступа — пишем. Нет регламента резервного копирования — создаём. Но у этого подхода есть фундаментальные изъяны.
Во-первых, такие документы часто пишутся в отрыве от практики. Автор руководствуется шаблонами или общими формулировками, не учитывая специфику конкретных систем. В результате получается документ, который формально соответствует требованию, но не отражает реальных действий администраторов.
Во-вторых, они создают дополнительную нагрузку на поддержку. Теперь нужно не только работать, но и вести учёт в соответствии с новым, искусственно внедрённым регламентом. Часто это приводит к двойному учёту: реальные действия в тикетах или чатах, а для отчётности — заполнение дополнительных форм.
Самое главное — проверяющие из ФСТЭК или Роскомнадзора быстро отличают «живые» процессы от «бумажных». Их вопросы направлены не на зачитывание пунктов политики, а на понимание, как эти пункты реализованы технически. Если вы не можете показать настройки системы, подтверждающие выполнение вашего же документа, это считается несоответствием.
Инвентаризация как основа доказательной базы
Первый и главный этап подготовки, это не написание, а изучение. Вам нужно составить полную картину того, что уже существует. Разбейте эту работу на ключевые домены.
Учётные системы и доступы. Не начинайте с политики. Начните с инвентаризации. Какие у вас есть системы (Active Directory, доменные службы, СУБД, корпоративные порталы)? Кто и как в них учтён? Как организованы группы и роли? Экспортируйте списки пользователей, групп, назначенных прав. Это не документ для проверки, это сырая база для анализа. Часто оказывается, что доступы уже разграничены по ролям (администраторы, пользователи, гости), просто это нигде не зафиксировано в виде политики. Ваша задача — описать существующую практику.
Средства защиты информации (СЗИ). Какие средства у вас развёрнуты? Межсетевые экраны, системы обнаружения вторжений, антивирусы, DLP? Недостаточно просто перечислить названия. Соберите конфигурационные файлы, скриншоты интерфейсов с основными настройками, политики блокировок. Покажите, как настроены правила фильтрации на МСЭ или какие сигнатуры активны в СОВ. Эти артефакты — прямое техническое доказательство применения СЗИ. Процедуры и операции. Как на самом деле происходит управление? Резервное копирование, установка обновлений, реагирование на инциденты. Не пишите новый регламент с нуля. Проанализируйте историю тикетов в Service Desk, записи в календарях ответственных, скрипты автоматизации. Если копирование запускается по расписанию в cron или Планировщике задач — сохраните это расписание. Если обновления устанавливаются через WSUS или «Киберзона» — сделайте выгрузку отчётов о применённых патчах. Реальная история операций весомее любого формального описания.
Превращение артефактов в доказательства
После инвентаризации у вас есть набор разрозненных данных: конфиги, логи, выгрузки, скриншоты. Теперь нужно их систематизировать и связать с требованиями регулятора. Это и есть создание доказательной базы без написания новых документов.
Возьмите типовой перечень требований ФСТЭК или пункты из вашего частного случая. К каждому требованию подберите существующие артефакты.
| Требование регулятора | Как подтвердить существующими артефактами |
|---|---|
| Разграничение прав доступа. | Экспорт списков пользователей и групп из AD/LDAP. Скриншоты настроек ролевой модели в бизнес-приложении. |
| Обеспечение учёта событий безопасности. | Примеры конфигурационных файлов syslog/rsyslog, настройки пересылки журналов. Скриншоты интерфейса SIEM-системы с активными источниками данных. |
| Антивирусная защита. | Скриншот консоли управления с отображением статуса защиты на всех узлах. Отчёт о последней проверке из антивирусного решения. |
| Резервное копирование. | Расписание задач из ПО для бэкапов. Лог успешного выполнения последней копии. |
| Установка обновлений. | Отчёт из WSUS или системы управления обновлениями о состоянии установки патчей. История выполненных задач в системе автоматизации (Ansible, Terraform). |
Такой подход меняет парадигму. Вместо «у нас должно быть написано, что мы разграничиваем доступ» вы приходите к «вот технические механизмы, которые прямо сейчас разграничивают доступ». Проверяющий видит не намерения, а факты.
Создание «пояснительных записок» вместо политик
Иногда без текстовых документов всё же не обойтись. Но их цель — не предписывать новые правила, а объяснять существующие практики. Вместо громоздкой «Политики информационной безопасности» можно подготовить серию кратких пояснительных записок.
Например, документ «Принципы разграничения доступа в инфраструктуре» не будет содержать абстрактных формулировок. Он будет состоять из:
- Описания текущей модели: «Доступ основан на ролях в Active Directory. Выделены группы: Domain Admins, Server Operators, User_App_X».
- Приложения: В виде приложений идут экспорты этих групп, скриншоты настроек делегирования.
- Ссылки на техническую реализацию: «Настройки фильтрации доступа по группам реализованы в правилах межсетевого экрана (см. конфиг FW_01, раздел AD-Groups-Policy)».
Аналогично, вместо «Регламента резервного копирования» создаётся «Описание процедур обеспечения сохранности данных». Его ядро — расписание задач из Veeam/Bacula/ZMB и пример успешного лога. Текст лишь кратко поясняет, что, куда и как часто копируется, и кто отвечает за мониторинг.
Подготовка к диалогу с проверяющим
Финальный этап — научиться говорить на языке доказательств. Проверка, это диалог. Вас спросят: «Как вы обеспечиваете учёт событий?». Вместо зачитывания пункта из политики вы отвечаете: «Учёт настроен через централизованный сбор журналов. На критичных серверах работает агент rsyslog с конфигурацией, которая перенаправляет события безопасности на узел-коллектор. Вот пример конфигурационного файла с сервера БД. Вот скриншот интерфейса SIEM, где видны эти события за последние 24 часа». Такая подготовка требует глубокого погружения в собственную инфраструктуру. Она сложнее, чем скачивание шаблонов документов. Но она даёт неоспоримые преимущества: вы не создаёте лишней работы на будущее, ваша доказательная база неуязвима для вопросов о реализации, а в процессе вы находите и устраняете реальные, а не бумажные, inconsistencies в настройках. В итоге вы приходите на проверку не с папкой незнакомых документов, а с полным пониманием своей системы и готовностью продемонстрировать её безопасность в действии.