«У нас 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.