Аттестация информационной системы глазами админа: по шагам и без тумана

MAATRIX

Если руководство сообщило, что систему нужно «аттестовать», а вы администрируете инфраструктуру, первая реакция обычно — тревога пополам с недоумением: какие бумаги, зачем, что конкретно от меня хотят. Это нормально: аттестация — процесс, придуманный не для админов, а описанный на языке, который админам читать неудобно. В этой статье — взгляд с другой стороны: что реально происходит по шагам, какая часть работы падает на инфраструктуру и что стоит подготовить заранее, чтобы не тонуть в переписке с интегратором вечер за вечером. Сразу оговорка, которая держит всю статью: конкретные требования — какие меры защиты нужны именно вашей системе, какой класс или уровень защищённости она получит, какие документы и по какому регламенту оформляются — определяет не админ и не эта статья, а специалист по защите информации или лицензированная организация, которая проводит аттестацию для вашего конкретного случая. Здесь — только общая механика процесса и то, что происходит на стороне инфраструктуры.

Что вообще происходит и зачем в этом участвует админ

Аттестация — это подтверждение того, что информационная система соответствует установленным для неё требованиям по защите информации. Провести её самостоятельно, «на глаз», нельзя: нужна организация, имеющая право на такую деятельность, и формальная процедура с документами на выходе.

Но аттестуется не абстракция — аттестуется конкретная система, которая работает на конкретных серверах, за конкретным firewall, с конкретными пользователями и правами. Юрист или ИБ-консультант знает, что должно быть, но не знает, как в вашей инфраструктуре на самом деле настроен sudo, где лежат бэкапы и кто последний раз трогал iptables. Эту часть знает администратор. Поэтому на практике аттестация — это всегда диалог: специалист по защите формулирует требования, админ показывает и, если нужно, донастраивает реальность под них.

Важно понимать масштаб заранее: это не разовая правка конфига за вечер. Это проект, который растягивается на недели и месяцы и требует от инфраструктурной команды регулярного, а не разового участия.

Этап 1: обследование системы — здесь у вас спросят почти всё

Первый этап — обследование (иногда говорят «предпроектное обследование» или просто «аудит текущего состояния»). Специалист по защите информации должен понять, что вообще из себя представляет система: сколько серверов, где они физически или юридически размещены, какие данные обрабатываются, кто имеет доступ, какие есть внешние подключения.

С точки зрения админа это выглядит как серия вопросов и запросов на доступ. Готовьтесь предоставить:

• Схему сети — хотя бы актуальную, даже если она нарисована от руки: сегменты, VLAN, где стоит firewall, где DMZ, куда идут внешние подключения (VPN, публичные IP, API).
• Список серверов и их ролей — что на чём крутится: БД, веб, почта, файловое хранилище, резервное копирование.
• Список учётных записей и прав — кто имеет доступ к каждой системе, с какими правами (обычный пользователь, sudo, root), как выдаются и отзываются доступы.
• Доступ на чтение к конфигурациям ключевых узлов — обычно на этом этапе достаточно посмотреть, а не отдавать пароли; договоритесь заранее о формате: временный аккаунт с ограниченными правами, сессия по вашему приглашению или просто выгрузка конфигов.

Практический совет: не ждите, пока попросят — соберите базовую схему и список активов заранее, до старта проекта. Это ускоряет обследование в разы и снимает половину нервотрёпки, потому что вы отвечаете на вопросы по своей же документации, а не вспоминаете на ходу.

Если у вас ещё нет привычки готовить инфраструктуру к внешним проверкам, полезно заранее пройтись по общему чек-листу безопасности нового сервера — многое из него совпадает с тем, что спросят на обследовании.

Этап 2: определение требований и выбор мер защиты — здесь решает не админ

По итогам обследования специалист определяет, какие требования применимы к вашей системе и какие меры защиты нужны — организационные (регламенты, приказы, ответственные лица) и технические (конкретные механизмы: разграничение доступа, защита от несанкционированного доступа, антивирусная защита, криптографическая защита каналов и так далее — конкретный набор всегда определяется под задачу).

Это зона ответственности лицензированного специалиста, а не админа: неверно выбранные меры — это либо избыточные траты, либо системы, которая не проходит аттестацию. Роль админа здесь — консультативная: вас могут спросить, реализуемо ли конкретное требование в вашей инфраструктуре технически, сколько это займёт, что для этого нужно (лицензии, оборудование, изменение архитектуры).

Хороший момент честно обозначить ограничения: если предлагаемая мера плохо ложится на вашу архитектуру (например, требует сегментации сети, которую сложно сделать без простоя, или конкретного класса оборудования, которого сейчас нет), лучше сказать это сразу, а не после того, как план защиты утверждён и деньги на закупку выделены.

Этап 3: внедрение технических средств — основная нагрузка на инфраструктуру

Дальше начинается самая объёмная для админа часть — внедрение того, что определено на предыдущем этапе. Здесь конкретика зависит от требований к вашей системе, но типовой набор задач, который встречается почти всегда:

# Пример типовых задач внедрения (иллюстративно, не рецепт)
- настройка разграничения доступа (роли, группы, минимально необходимые права)
- централизация и хранение журналов событий
- настройка сетевой защиты (firewall-правила, сегментация)
- защита каналов передачи данных (шифрование трафика)
- антивирусная защита на серверах и рабочих станциях
- регламент резервного копирования и восстановления
- политика паролей и, где требуется, многофакторная аутентификация

Это не готовый чек-лист требований — это иллюстрация того, какого рода задачи обычно ложатся на плечи инфраструктурной команды. Точный состав определяет специалист по защите информации для вашей системы.

На практике этот этап — самый долгий и самый «ваш». Вы:

• настраиваете и документируете правила доступа;
• разворачиваете или донастраиваете сбор и хранение логов так, чтобы их можно было предъявить и они хранились нужный срок;
• закрываете сетевые дыры, о которых, возможно, знали давно, но руки не доходили;
• согласовываете простои для изменений, которые нельзя внести на живую систему без риска.

Если система обрабатывает персональные данные, полезно заранее свериться с материалом про где законно держать сервер с персональными данными — размещение инфраструктуры часто оказывается частью требований, а не только технические настройки.

Этап 4: испытания — проверка того, что внедрили

После внедрения проводятся испытания (проверка соответствия принятых мер установленным требованиям). Это может делать та же организация, что вела проект, или отдельная — это уже вопрос организационной схемы конкретного проекта.

С точки зрения админа испытания выглядят как контролируемая проверка: специалисты смотрят, что настроено, пытаются убедиться, что заявленные меры работают на практике, а не только на бумаге. Здесь пригодится то же, что и на этапе обследования — доступ для проверки, актуальные конфигурации, но уже с фокусом на конкретные внедрённые механизмы.

Типичный запрос на этом этапе — показать журналы за период, подтвердить, что правила firewall реально применяются (а не просто лежат в конфиге, отключённые для отладки и забытые), продемонстрировать процесс отзыва доступа для уволенного сотрудника. Если у вас есть черновик собственной документации по обновлениям безопасности и патч-менеджменту — она тоже может пригодиться; общие принципы разобраны в статье про настройку автообновлений безопасности на сервере.

Если на испытаниях находят несоответствия — это нормальная часть процесса, а не провал. Обычно это означает доработку и повторную проверку конкретного пункта, а не запуск всего проекта заново.

Этап 5: оформление документов — административная часть, но и она касается админа

Финальный этап — оформление аттестата и сопутствующей документации: описания системы, реализованных мер, результатов испытаний. Это преимущественно бумажная работа, которую ведёт организация, проводящая аттестацию, но точность этих документов напрямую зависит от того, насколько верно описана реальная инфраструктура.

Здесь роль админа — сверить, что в итоговых документах система описана так, как она реально устроена: те же серверы, те же сети, те же меры защиты, что были фактически внедрены и проверены. Расхождение между документом и реальностью — не абстрактный риск: оно всплывает при следующей проверке или инциденте, и разбираться с ним придётся тому же админу, только позже и в более нервной обстановке.

Полезная привычка на этом этапе — сохранить копию итоговой документации (схемы, перечни мер, конфигурации на момент аттестации) в собственном архиве инфраструктурной команды, а не полагаться только на архив у интегратора.

Сколько это реально занимает и как распределить нагрузку

Точные сроки зависят от масштаба системы, готовности инфраструктуры и загрузки исполнителя — здесь нельзя дать универсальное число, и любая цифра без контекста конкретной системы будет ориентировочной. Но по общей структуре проекта можно обозначить пропорции нагрузки на админа:

Из этого распределения следует практический вывод: если вы администратор и вас привлекают к проекту аттестации, худший сценарий — узнать об этапе внедрения в последний момент и пытаться закрыть все технические задачи в короткий срок параллельно с текущей работой. Лучше сразу договориться о сроках с запасом и, если возможно, о выделенном окне на изменения инфраструктуры, а не встраивать это в обычный рабочий поток «между делом».

Отдельно: сама аттестация — не разовое событие навсегда. Система меняется, требования могут пересматриваться, и переаттестация или подтверждение соответствия может понадобиться повторно. Держать документацию и конфигурации в порядке — это инвестиция, которая окупается при следующем цикле.

Частые вопросы