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 хвилин. Далі — аудит і модель управління.

← До розділу експертизи