«У нас Linux — нам антивірус не потрібен». Які системи справді не потребують антивірусного захисту?

06.08.2026

Сучасні безпекові аудити вимагають від команд ІБ відійти від застарілих стереотипів. Переконання, що всі операційні системи (ОС) за замовчуванням захищені від шкідливого коду, більше не є аргументом під час перевірок. Без офіційного підтвердження будь-яка система вважається потенційно вразливою до зловмисного ПЗ.

Річ у тім, що стандарти безпеки оцінюють не внутрішні переконання компанії чи її досвід, а лише підтверджені факти. Без офіційної аргументації від розробника антивірусне ПЗ необхідно встановлювати навіть там, де воно здається зайвим. Водночас спроби розгорнути антивірусний агент на вузькоспеціалізованих платформах, де він не підтримується, можуть порушити їхню стабільну роботу.

З’ясуймо, чому Unix-подібні ОС не є захищеними від шкідливого ПЗ за замовчуванням, які з них можна залишити без антивірусу та як обґрунтувати це рішення перед аудиторами.

Чому багато хто досі вважає Unix-подібні ОС невразливими — і чому це не відповідає дійсності?

Причина, через яку компанії потрапляють у пастку під час аудиту, криється в застарілих уявленнях про ризики. Переконання, що Linux, Android, iOS чи macOS не потребують антивірусного захисту, сформувалося в часи, коли основною мішенню кіберзлочинців була Windows. Тоді й виник спрощений стереотип: «Windows — більш вразлива, а Unix-подібні ОС — безпечні за замовчуванням».

Сьогодні межа проходить між системами, щодо яких організація документально обґрунтувала відсутність актуального ризику зараження, і всіма іншими. Для Linux чи macOS створюють менше зловмисного ПЗ, але «менше» не означає «жодного». Щороку в них виявляють сотні нових вразливостей, які потрапляють до каталогу CVE — міжнародної бази знань про виявлені вразливості.

Суттєво змінився і вектор атак. Linux-сервери, які тримають на собі корпоративні вебсервіси та бази даних, стали вкрай привабливою мішенню для зловмисників. Будь-яка інформаційна система, доступна з мережі Інтернет, перебуває під постійним скануванням незалежно від встановленої платформи. Саме тому аудитори вважають аргумент «наш Linux захищений від зловмисного ПЗ» безпідставним.

Винятки існують, але вони поодинокі. До них належать повністю ізольовані системи, які фізично не мають з’єднань із зовнішніми мережами, а також спеціалізовані апаратні-програмні платформи. Для решти систем назва та походження ОС не гарантують захисту — рівень безпеки доведеться обґрунтовувати документально.

Аргументація для аудитора: які джерела підтверджують безпеку систем

Для організацій, які обробляють або зберігають дані платіжних карток, вимоги до захисту системних компонентів у відповідному середовищі визначає PCI DSS (Payment Card Industry Data Security Standard) — міжнародний стандарт безпеки даних платіжних карток.

З виходом версії 4.0 вимоги до захисту суттєво посилилися. Якщо раніше (v3.2.1) антивірус був вимогою лише для систем, які «поширено вражаються» шкідливим ПЗ (commonly affected), то тепер оцінюється кожна окрема система на відсутність ризику зараження взагалі (not at risk).

Згідно з чинною версією PCI DSS 4.0.1, антивірусний захист має бути встановлений на всіх ОС, крім тих, щодо яких офіційно підтверджено статус not at risk (вимога 5.2.3). Для таких винятків компанія зобов’язана вести документований перелік і регулярно відстежувати загрози. 

При цьому висновок про безпеку має спиратися виключно на офіційні джерела: документацію вендора, бюлетені безпеки розробника ОС або матеріали профільних організацій, як-от NIST. Без документального підтвердження аудитор зобов’яже компанію розгорнути антивірус на Unix-подібних системах.

Періодичність перегляду таких систем організація визначає самостійно через цільовий аналіз ризиків (Targeted Risk Analysis, TRA) відповідно до вимоги 12.3.1 — стандарт не встановлює фіксованого інтервалу переоцінки. На практиці аудитори та профільні організації з інформаційної безпеки рекомендують проводити переоцінку щонайменше раз на пів року, а для систем із підвищеним ризиком — щомісяця або щокварталу. Важливо, що з 1 квітня 2025 року вимога 5.2.3.1 щодо обов’язкового проведення TRA для таких систем стала обов’язковою, тоді як раніше вона була рекомендованою практикою.

Цей підхід універсальний для всієї галузі кібербезпеки: жоден фаховий аудит не спирається на запевнення без документальних доказів. Проте в інфраструктурі є рішення, де відсутність загрози закладена на рівні архітектури, а встановлення сторонніх агентів офіційно не підтримується виробниками та може порушити стабільність платформи.

Чому VMware ESXi та IBM QRadar не потребують агентів захисту?

Спеціалізована та закрита архітектура є найвагомішим аргументом для виконання вимоги 5.2.3 стандарту PCI DSS 4.0.1, оскільки вона мінімізує штатні способи встановлення стороннього коду. У таких рішеннях немає звичного механізму для інсталяції сторонньої програми — ні шкідливої, ні антивірусної. Еталонними прикладами подібних компонентів для аудиторів є гіпервізор VMware ESXi та SIEM-платформа IBM QRadar.

VMware ESXi — гіпервізор без підтримки сторонніх агентів

Це рішення належить до спеціалізованого програмного забезпечення для управління віртуальними машинами. VMware ESXi не є операційною системою загального призначення (як Windows або стандартний дистрибутив Linux), а працює як вузькоспеціалізоване середовище.

Технічний захист ESXi спирається на суворі контролі:

● Увесь виконуваний код має бути підписаний розробником, а ядро блокує непідписані модулі за принципом default-deny.
● Система обмежує виконання непідписаних бінарних файлів, хоча внутрішні інтерпретатори (як-от Python) вимагають додаткового контролю прав доступу.
● Встановлення оновлень чи драйверів можливе лише у форматі підписаних пакетів VIB (vSphere Installation Bundle) від сертифікованих партнерів. Цілісність коду під час завантаження додатково перевіряє технологія Secure Boot.

Broadcom (VMware) не дозволяє встановлювати традиційні антивіруси, EDR або інших сторонні агенти на хости ESXi та vCenter. Захист платформи забезпечується конфігураціями (Lockdown Mode, execInstalledOnly), мережевою сегментацією, обмеженням адміністративного доступу та контролем цілісності за допомогою Secure Boot і апаратних модулів TPM (Trusted Platform Module).

IBM QRadar — спеціалізоване рішення із жорстким контролем оновлень

Схожа концепція реалізована в IBM QRadar — SIEM-платформі (Security Information and Event Management), призначеній для збору та аналізу подій безпеки. Вона постачається у форматі фізичного чи віртуального appliance (або програмної інсталяції) на базі дистрибутива RHEL (Red Hat Enterprise Linux).

Хоча рішення базується на Linux, QRadar не призначений для використання як сервер загального призначення:

● Підключення стандартних репозиторіїв RHEL і самостійне встановлення сторонніх пакетів не передбачені.
● Усі виправлення безпеки постачаються виключно IBM через офіційні пакети оновлень.
● Систему захищено вбудованими правилами фільтрації трафіку та вимогами до посилення безпеки конфігурації (hardening). 

Згідно з документацією IBM, QRadar не потребує встановлення сторонніх антивірусних агентів і не підтримує їх. Офіційна позиція розробника є вагомим доказом під час аудиту, проте визначення статусу not at risk все одно потребує документованого цільового аналізу ризиків (TRA) відповідно до вимог PCI DSS.

Обидва рішення демонструють: закрита архітектура суттєво знижує ризик зараження шкідливим ПЗ, але унеможливлює розгортання традиційного антивірусу. Однак це не означає, що кіберризики відсутні, тому захист потребує окремого підходу.

Зловмиснику не завжди потрібно щось встановлювати, щоб зламати

Закрита архітектура надійно блокує виконання сторонніх виконуваних файлів, але не робить систему абсолютно недосяжною для кіберзлочинців. Кіберзлочинцям зазвичай і не потрібно інсталювати стороннє ПЗ: для компрометування інфраструктури вони використовують вбудовані можливості самої платформи. Отримавши доступ через вразливості зовнішніх інтерфейсів або викрадені облікові дані, вони закріплюються в системі за допомогою штатних механізмів, як-от SSH або віддаленої консолі. 

Яскравим прикладом такого сценарію є вразливість CVE-2024-37085 у VMware ESXi. Нападникам із вимагацьких угруповань Akira та Black Basta було достатньо створити в Active Directory доменну групу ESX Admins — і система автоматично надавала їм повні адміністративні права на хості. Для цього етапу атаки безпосередньо на ESXi їм не довелося розгортати окремий шкідливий агент, хоча компрометація Active Directory відбувалася із застосуванням шкідливого ПЗ.

За даними кейсів компанії Huntress, частка гіпервізорів серед уражених шифрувальниками систем зросла з ~3% у першій половині 2025 року до 25% у другій. Зловмисники змістили фокус зі сканування зовнішніх мереж на горизонтальне переміщення всередині корпоративного периметра, адже отримання контролю над гіпервізором дає змогу одночасно заблокувати десятки віртуальних машин.

Гіпервізори приваблюють зловмисників масштабом потенційної шкоди: один компрометований хост відкриває доступ до багатьох віртуальних машин. Відсутність традиційних EDR-агентів додатково створює прогалини у видимості для команди безпеки.

Тому неможливість розгорнути антивірус компенсують іншими контролями:

● Secure Boot для перевірки цілісності завантажувальних модулів та TPM для атестації хоста.
● Обмеженням виконання непідписаних бінарних файлів (режим execInstalledOnly) та обмеженням прямого адміністративного доступу (Lockdown Mode).
● Мережевою сегментацією інтерфейсів управління та передаванням подій до зовнішньої SIEM-системи.

Варто враховувати, що більшість із цих механізмів вимагають свідомого налаштування. Наприклад, у vSphere 7 застосування execInstalledOnly доводилося активувати вручну та підкріплювати Secure Boot.

Статус not at risk звільняє компанію лише від вимоги щодо розгортання антивірусних агентів, але не скасовує вимог щодо загального захисту. Оцінка загрози вимагає постійного моніторингу та регулярного перегляду ризиків.

Чекліст перед аудитом: як довести захищеність систем без антивірусу

Стандарт PCI DSS 4.0.1 розглядає статус not at risk не як разове рішення, а як безперервний процес управління ризиками. Щоб аудитор визнав виняток правомірним, в організації мають діяти 4 обов’язкові елементи: 

● Документований реєстр системних компонентів. Офіційний перелік усіх систем, що не потребують антивірусного захисту. У реєстрі зазначають назву системи, її роль в інфраструктурі, аргументацію винятку, посилання на офіційне джерело вендора, а також дату та результати останнього перегляду.  
● Докази з офіційних джерел. Аргументація має спиратися виключно на документацію розробника (наприклад, бази знань Broadcom чи IBM) або рекомендації профільних організацій, як-от NIST. Без офіційного підтвердження система підлягає обов’язковому захисту. 
● Регулярний цільовий аналіз ризиків (Targeted Risk Analysis). Інтервал оцінки за вимогою 12.3.1 компанія визначає та фіксує самостійно, проте аудитори та профільні організації з ІБ зазвичай радять переглядати винятки щонайменше раз на пів року. 
● Безперервний моніторинг загроз. Виявлення нової вразливості чи зміна тактики нападників може повернути систему до категорії вразливих. Компанія зобов’язана стежити за безпековими бюлетенями вендорів (зокрема через сервіси сповіщень типу IBM My Notifications або сповіщення Broadcom) та оновленнями документації щодо підтримки антивірусів. 

Додатково варто заздалегідь розробити регламент переходу системи зі статусу not at risk до загального контуру антивірусного захисту на випадок появи нових загроз. Разом ці заходи перетворюють статус винятку на прозору та обґрунтовану позицію, яку легко захистити під час будь-якої перевірки.

Підготовка до аудиту PCI DSS 4.0.1 разом із фахівцями IT Specialist

Завчасно сформована доказова база заощаджує час на перевірки, оптимізує витрати на ліцензії та зменшує час на їхню подальшу підтримку. Проте точна класифікація систем і трактування технічної документації вендорів вимагають фахового аудиторського досвіду. 

Команда IT Specialist супроводжує проєкти з відповідності стандартам кібербезпеки. Наші аудитори допомагають визначити, де дійсно не потрібно встановлювати антивірусне ПЗ, зібрати необхідну аргументацію та правильно оформити документи.  

Підготовку доказів варто проводити до початку перевірки. Необґрунтовані винятки, виявлені аудитором під час оцінки, можуть призвести до статусу non-compliant та перешкодити успішному оформленню підтвердження відповідності PCI DSS.

Щоб переконатися у захищеності ваших систем та належній підготовці доказів для аудиту, звертайтеся до фахівців IT Specialist.

Автор статті: Анатолій Журавльов (Керівник відділу сертифікації та аудиту з інформаційної безпеки)