2026-02-16 · IT-Service

Аудит IT-инфраструктуры предприятия: что проверяем и зачем

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

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

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

Когда предприятию нужен аудит IT-инфраструктуры

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

Смена IT-руководства. Новый CTO, технический директор или IT-менеджер нуждается в объективной картине состояния систем. Без аудита он наследует все скрытые риски предшественника.

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

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

Переход от «админа-на-все-руки» к управляемой модели. Когда бизнес дорастает до 30–50+ рабочих мест, одного системного администратора уже недостаточно. Нужна модель с чёткими зонами ответственности, SLA и регламентами.

Подготовка к внешнему аудиту или сертификации. ISO 27001, требования заказчиков или регуляторов — всё начинается с понимания текущего состояния.

Если вы узнали хотя бы один из этих сценариев — аудит не просто желателен, а необходим.

Пять зон аудита IT-инфраструктуры

Мы структурируем аудит по пяти зонам. Каждая из них — это отдельный уровень, где могут накапливаться риски.

1. Серверные сервисы

Это ядро корпоративной инфраструктуры. Если здесь есть проблемы — они каскадом влияют на всё остальное.

Active Directory и доменная структура. Проверяем здоровье контроллеров домена: репликацию, FSMO-роли, состояние SYSVOL и NETLOGON. Анализируем структуру OU, делегирование прав, наличие устаревших или «забытых» учётных записей с привилегированным доступом. Отдельно смотрим на групповые политики (GPO): нет ли конфликтующих политик, есть ли документация к критичным GPO, работает ли фильтрация корректно.

DNS. Проверяем зоны прямого и обратного просмотра, наличие scavenging для устаревших записей, правильность настройки forwarders и conditional forwarders. Некорректный DNS — одна из самых распространённых причин «странных» проблем с доступом к ресурсам.

DFS. Если используется DFS-Namespaces или DFS-Replication — проверяем состояние репликации, backlog, наличие конфликтов. В крупных средах DFS-R-проблемы могут неделями оставаться незамеченными.

RDS и терминальные сервисы. Для компаний, где сотрудники работают через Remote Desktop Services: проверяем лицензирование (CAL), состояние Session Host и Connection Broker, настройки тайм-аутов сессий, профили пользователей.

SQL Server. Проверяем версию и уровень патчей, планы обслуживания баз данных (maintenance plans), состояние индексов, настройки tempdb, размер и рост логов транзакций. Оцениваем, достаточно ли ресурсов для текущей нагрузки.

2. Виртуализация

Большинство современных инфраструктур построено на виртуализации. Здесь критически важно понимать реальное состояние ресурсов.

Инвентаризация хостов. Сколько физических серверов, какая версия гипервизора (ESXi, Hyper-V), состояние обновлений, hardware health (диски, память, контроллеры).

Распределение ресурсов. Проверяем overcommit по CPU и RAM. Overcommit — не всегда проблема, но без контроля он превращается в бомбу замедленного действия. Смотрим на balloon driver, swap, ready time.

Хранилища. Состояние datastore, latency, thin vs thick provisioning, наличие orphaned файлов и устаревших snapshot-ов. Snapshot, существующий более 72 часов в production — это красный флаг.

High Availability. Если используется VMware HA, vMotion или Hyper-V Failover Clustering — проверяем конфигурацию, тестируем failover (или анализируем, когда в последний раз его тестировали).

3. Сетевой уровень

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

Сегментация. Разделены ли серверный сегмент, рабочие станции, гостевая сеть и IoT-устройства? В идеале — VLAN с межсетевым экранированием между сегментами. На практике мы часто видим плоскую сеть, где принтер находится в одном сегменте с контроллером домена.

Firewall и правила доступа. Проверяем конфигурацию, наличие чрезмерно широких правил (any-to-any), дату последнего review. Особое внимание — правилам для VPN и внешних подключений.

VPN-туннели. Состояние site-to-site и client VPN, используемые протоколы (IKEv2, WireGuard, OpenVPN), наличие split tunneling и его безопасность.

Точки отказа. Есть ли единая точка отказа на уровне сети? Один маршрутизатор, один канал связи, один DNS-сервер? Для бизнес-критичной инфраструктуры это недопустимо.

4. Безопасность

Безопасность — это не отдельный продукт, а характеристика всей инфраструктуры. Мы проверяем её сквозным образом.

Управление доступами. Кто имеет привилегированный доступ к серверам, AD, сетевому оборудованию? Сколько человек знают пароль Domain Admin? Есть ли отдельные административные учётные записи? Настроен ли LAPS для локальных админов?

Парольные политики. Минимальная длина, сложность, срок действия, блокировка при попытках подбора. Выполняется ли эта политика фактически, а не только на бумаге?

Обновления и патчинг. Состояние обновлений операционных систем серверов и рабочих станций. Есть ли WSUS или другая система централизованного управления обновлениями? Когда последний раз обновлялись серверы?

Антивирусная защита. Наличие, централизованное управление, актуальность баз, покрытие (все ли endpoints под защитой?). Для серверов — настроены ли исключения, не компрометирующие защиту?

Шифрование. BitLocker на рабочих станциях и серверах, шифрование резервных копий, TLS для внутренних сервисов.

5. Резервное копирование и восстановление после катастрофы (DR)

Это зона, где мы чаще всего находим критические проблемы. Бекап — это не то, что вы настроили, а то, из чего вы смогли восстановиться.

Наличие и полнота. Все ли критичные системы бекапятся? AD, SQL-базы, файловые серверы, конфигурации сетевого оборудования, сервисы виртуализации? Мы регулярно встречаем ситуации, когда «всё бекапится», а конфигурация firewall или DNS-зоны — нет.

RPO и RTO. Каковы фактические показатели Recovery Point Objective (сколько данных теряется) и Recovery Time Objective (за сколько времени восстанавливаемся)? Соответствуют ли они ожиданиям бизнеса?

Правило 3-2-1. Три копии данных, на двух разных носителях, одна — за пределами основной площадки. Это минимальный стандарт. Как это реализовано у вас?

Тестирование восстановления. Ключевой вопрос: когда в последний раз вы успешно восстановили сервер или базу данных из бекапа? Не «проверили, что файл бекапа существует», а реально подняли систему? Если ответ — «никогда» или «не помню» — это самый большой риск в вашей инфраструктуре.

DR-план. Существует ли задокументированный план действий на случай полной потери основной площадки? Кто ответственный? Где хранятся пароли и документация для восстановления?

Чек-лист: 25 пунктов для самопроверки

Этот чек-лист не заменяет полноценный аудит, но позволяет быстро оценить критические зоны. Если вы ответили «нет» на 5 и более пунктов — вашей инфраструктуре нужно внимание специалистов.

Серверные сервисы

  1. Все контроллеры домена здоровы, репликация работает без ошибок
  2. Количество учётных записей с правами Domain Admin — менее 5
  3. Групповые политики задокументированы и пересматриваются регулярно
  4. DNS scavenging включён, устаревшие записи удаляются автоматически
  5. RDS-лицензирование соответствует фактическому количеству подключений

Виртуализация

  1. Версия гипервизора актуальна и поддерживается вендором
  2. Overcommit по RAM не превышает 120% ни на одном хосте
  3. Ни один snapshot в production не существует дольше 72 часов
  4. Hardware health серверов мониторится (диски, память, температура)
  5. High Availability тестировался в течение последних 6 месяцев

Сеть

  1. Серверный сегмент изолирован от рабочих станций через VLAN
  2. Firewall-правила пересматривались в течение последнего года
  3. Нет правил типа any-to-any
  4. VPN использует современные протоколы (IKEv2, WireGuard)
  5. Есть резервный канал связи с интернетом

Безопасность

  1. Привилегированные учётные записи отделены от повседневных
  2. Парольная политика требует минимум 12 символов
  3. Серверы обновлялись в течение последних 30 дней
  4. Антивирус централизованно управляется и покрывает 100% endpoints
  5. LAPS настроен для локальных административных аккаунтов

Резервное копирование и DR

  1. Все критичные системы имеют актуальный бекап
  2. Бекапы хранятся по правилу 3-2-1
  3. Восстановление из бекапа тестировалось в течение последних 90 дней
  4. RPO и RTO определены и соответствуют потребностям бизнеса
  5. Существует задокументированный DR-план с определёнными ответственными

Что делать с результатами аудита

Аудит без действий — это просто бумага. Мы структурируем результаты по трём уровням приоритета:

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

Средние риски — то, что создаёт уязвимость или снижает управляемость. Исправляется в течение 30–60 дней: плоская сетевая структура, отсутствие мониторинга, незадокументированные GPO.

Улучшения — то, что повышает зрелость инфраструктуры. Планируется в roadmap на квартал: внедрение LAPS, переход на современные протоколы VPN, автоматизация тестирования бекапов.

После приоритизации формируется модель управления: кто за что отвечает, какие изменения проходят через регламент, какие метрики контролируются в рамках SLA.

Как мы проводим аудит

Наш процесс состоит из четырёх шагов:

Шаг 1. Короткий созвон (15–20 минут). Выясняем масштаб инфраструктуры, критичные сервисы, текущие боли. Определяем, подходим ли мы друг другу.

Шаг 2. Доступ и сбор данных (1–2 дня). Получаем ограниченный доступ к среде. Собираем инвентаризацию, конфигурации, состояние сервисов. Используем стандартизированные скрипты и инструменты, ничего не меняем.

Шаг 3. Анализ и отчёт (2–3 дня). Формируем отчёт с детальным описанием состояния каждой зоны, выявленными рисками и приоритизированными рекомендациями. Отчёт написан понятным языком — его можно показать руководству.

Шаг 4. Модель управления и SLA. На основе аудита предлагаем модель дальнейшего управления инфраструктурой: зоны ответственности, регламенты изменений, SLA на реакцию и решение инцидентов.

Итог

Аудит IT-инфраструктуры — это не разовая акция, а отправная точка для перехода от хаотичного «тушения пожаров» к управляемой модели. Вы получаете полную картину состояния, понимаете риски и имеете план действий.

Если вы узнали свою ситуацию в описанных сценариях или ответили «нет» на несколько пунктов чек-листа — давайте поговорим.

Начинаем с короткого созвона на 15–20 минут. Дальше — аудит и модель управления.

← К разделу экспертизы