Практический чеклист IT-аудита, когда документации нет

Правило первого прохода: сначала наблюдать

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

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

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

Красная находка не даёт автоматического разрешения на исправление. Срочные меры согласуются отдельно, с резервной копией и планом отката.

Нулевая стадия: понять бизнес-контекст

Начните с владельцев процессов, а не с портов коммутатора. Какие операции нельзя остановить, когда проходят расчёты и отчётность, какие площадки работают вне обычных часов, где хранятся договоры и кто принимает решение при аварии? Ответы задают приоритет дальнейшей проверки.

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

• Критичные услуги и их бизнес-владельцы.
• Допустимые окна работ и сезонные ограничения.
• Площадки, удалённые сотрудники и внешние интеграции.
• Текущие поставщики, договоры, гарантии и каналы эскалации.
• Известные инциденты, риски и планируемые изменения.
• Требования к хранению и доступу, установленные самой организацией.

Соберите инвентаризацию из нескольких источников

Ни один источник не даёт полный список. Сопоставьте данные каталогов идентификации, DHCP и DNS, ARP-таблицы, консоли виртуализации и облака, средства управления устройствами, мониторинг, резервное копирование, закупочные документы и физический осмотр. Расхождения сами по себе являются находками.

Для актива фиксируйте не только модель и адрес. Нужны назначение, владелец, местоположение, версия ПО, состояние поддержки, критичность, зависимости, способ администрирования и наличие копии конфигурации. Неизвестные поля оставляйте явно пустыми, а не заполняйте предположениями.

Активное обнаружение проводите только в утверждённых диапазонах и с безопасными настройками. Старые принтеры, промышленные контроллеры и сетевые устройства могут нестабильно реагировать на интенсивное сканирование. Если риск неясен, начните с журналов и таблиц сетевого оборудования.

Проверьте идентификацию и привилегии

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

Проверьте многофакторную аутентификацию для привилегированных и удалённых входов, разделение повседневных и административных учётных записей, аварийный доступ и процесс кадровых изменений. Наличие MFA не означает защищённость, если устаревший протокол или исключённая группа позволяет обойти её.

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

1. Экспортировать роли и группы привилегированного доступа.
2. Сопоставить активные аккаунты со списком сотрудников и подрядчиков.
3. Найти общие, неиспользуемые и не имеющие владельца учётные записи.
4. Проверить MFA, исключения и устаревшие способы входа.
5. Выявить сервисные зависимости и места хранения секретов.
6. Проверить аварийный доступ контролируемым способом.
7. Сформировать план отзыва и минимизации прав без немедленного обрыва служб.

Разберите сеть и внешнюю поверхность

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

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

Внутри сети оцените разделение пользовательских устройств, серверов, гостевого Wi‑Fi, управления и специализированного оборудования. Сегментация — не самоцель: она должна ограничивать путь атаки и сохранять необходимые потоки. До изменения правил соберите наблюдаемые соединения и согласуйте зависимости.

• Два направления интернета и фактическая проверка переключения, если резерв заявлен.
• Экспорт конфигураций маршрутизаторов, коммутаторов и межсетевых экранов.
• Список VPN-пользователей, устройств и методов аутентификации.
• Инвентаризация публичных DNS-записей, IP-адресов и сертификатов.
• Изоляция гостевых, пользовательских, серверных и управляющих сетей.
• Централизованное время и отправка значимых журналов.

Докажите восстанавливаемость, а не наличие копий

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

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

Выберите несколько сценариев и восстановите данные в безопасное место. Владелец приложения должен подтвердить, что результат открывается и содержит ожидаемые данные. Измеренное время сравните с потребностями бизнеса, но не объявляйте формальные RTO и RPO без согласования владельцев.

Оцените конфигурации, обновления и наблюдаемость

Сравните версии операционных систем, гипервизоров, сетевого ПО и приложений с поддерживаемыми ветками производителей. Не сводите результат к списку CVE: учитывайте внешнюю доступность, привилегии, наличие эксплуатации, компенсирующие меры и критичность актива. Это позволяет приоритизировать, а не просто подсчитать уязвимости.

Проверьте процесс обновлений: тестирование, окна, резервирование, перезагрузки, исключения и подтверждение результата. Устаревшая система может требовать миграции, а не рискованного «последнего патча». Для неподдерживаемых компонентов нужны владелец риска, временные ограничения и план вывода.

Оцените мониторинг как цепочку от события до действия. Какие услуги и ресурсы наблюдаются, куда приходит предупреждение, кто дежурит, как создаётся обращение и где хранится результат? Тысячи непросмотренных оповещений не обеспечивают обнаружение. Проверьте срок сертификатов, заполнение дисков, ошибки копий и ключевые события аутентификации.

• Поддерживаемость версий и дата окончания поддержки.
• Покрытие централизованным управлением обновлений.
• Исключения с владельцем и обоснованием.
• Защита рабочих станций и серверов, актуальность политик.
• Полнота и синхронизация журналов.
• Маршрутизация оповещений и фактическая обработка.

Превратите находки в исполнимый план

Каждая находка должна содержать наблюдаемое условие, доказательство, затронутые активы, возможное последствие и рекомендуемое действие. Не пишите «безопасность слабая». Напишите, какая роль выдана, кому, почему это избыточно и какой контроль снизит риск.

Оценивайте риск по сочетанию вероятности и влияния, отдельно отмечая уверенность в данных. Критичная неизвестность — тоже результат: например, отсутствие подтверждения восстановления важной базы. Не присваивайте ей ложную точность; назначьте действие для получения свидетельства.

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

1. Проверить факты и удалить дублирующие симптомы одной причины.
2. Связать находки с активами, услугами и бизнес-владельцами.
3. Оценить влияние, вероятность и уверенность в свидетельствах.
4. Предложить минимальную меру, целевое состояние и способ проверки.
5. Назначить владельца, зависимости и реалистичную последовательность.
6. Согласовать исключения и дату повторной оценки.
7. После изменений проверить результат и отсутствие побочных эффектов.

Минимальный комплект результатов аудита

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

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

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

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