Киберпреступники больше не ограничиваются выведением из строя отдельных систем. Все чаще они стараются лишить компанию самой возможности восстановиться. Взломщики разбираются в работе систем резервного копирования и популярного программного обеспечения, например Microsoft и VMware (платформы для виртуализации). Под ударом оказываются учетные записи, серверы, системы управления и бэкапы. Поэтому защита требует укрепления инфраструктуры на каждом уровне — именно эту задачу решает харденинг.
Цена разрушительных инцидентов измеряется не только потерей данных, но и простоем ключевых процессов. Например, в июле 2025 года хакерская атака на «Аэрофлот» привела к сбою информационных систем, задержкам и массовой отмене рейсов. На следующий день проблемы возникли у аптечной группы «Неофарм»: часть аптек сетей «Столички» и «Неофарм» приостановили работу, клиентам стали недоступны заказ лекарств и привилегии программы лояльности. Похожий сценарий пережил бренд 12 Storeez: после атаки временно перестали работать сайт и приложение, возникли сбои на кассах, а нарушения в работе магазинов продолжались два дня. Компания оценила совокупный ущерб примерно в 48 млн руб.
Не существует универсальной технологии, которая способна предотвратить подобные риски. Антивирус и системы мониторинга помогают обнаруживать и блокировать угрозы, резервные копии дают основу для восстановления, а харденинг — процесс усиления безопасности информационных систем — сокращает поверхность атаки и ограничивает возможности злоумышленника, если ему все же удалось проникнуть внутрь инфраструктуры. Харденинг стоит рассматривать не как замену другим средствам защиты, а как один из базовых элементов киберустойчивости и непрерывности бизнеса.
Безопасность не надстраивается, а встраивается
Харденинг — это системная работа с конфигурациями, правами доступа и архитектурой ИТ-систем. Одна из распространенных ошибок — воспринимать безопасность как отдельный слой, который можно добавить поверх уже построенной инфраструктуры. Однако, если базовые архитектурные решения изначально создают лишние точки входа или дают слишком широкие полномочия, настройки безопасности не помогут.
«Харденинг — это не панацея, а только часть защиты. Если система плохо спроектирована, плохо настроена или плохо реализована, одними настройками безопасности проблему не решить. Поэтому мы всегда говорим заказчикам о том, что харденинг нужно рассматривать вместе с архитектурой. Он эффективен, если созданы условия, при которых злоумышленник, даже попав внутрь сети, не сможет быстро получить привилегированные права и нанести критический урон компании».
Антон Шипулин,
руководитель отдела комплексных проектов компании «Инфосистемы Джет»
Усиление защиты основной ИТ-инфраструктуры — часть комплексного подхода «Непрерывность 2.0» компании «Инфосистемы Джет». Задача харденинга не в том, чтобы добиться абсолютной неуязвимости, а в том, чтобы усложнить действия злоумышленника и прервать цепочку атаки, а также сделать происходящее в инфраструктуре более прозрачным для мониторинга и быстрого реагирования на события.
Для этого харденинг должен охватывать все ключевые слои — от физического оборудования, сети передачи данных, операционных систем (ОС) и служб каталогов до систем виртуализации, резервного копирования и системного ПО. Многие компании ошибочно рассматривают харденинг как задачу усиления безопасности одного конкретного компонента, который считают наиболее уязвимым, но на практике защищать нужно всю цепочку. И каждое ее звено требует специфических мер. Главное, что харденинг — не разовое мероприятие, это постоянный процесс, он должен стать нормой и правилом при эксплуатации ИТ-инфраструктуры наряду с установкой обновлений и патчей.
Харденинг платформ виртуализации
Виртуализация пронизывает практически все слои ИТ-инфраструктуры, поэтому такой среде следует уделить отдельное внимание: компрометация контура управления может открыть злоумышленнику доступ сразу ко множеству виртуальных машин и сервисов. Здесь основные риски зачастую связаны не со спецификой самой платформы виртуализации, а с тем, насколько защищен административный доступ к ней.
«Отсутствие публичных кейсов взлома российских платформ виртуализации не означает отсутствия угроз. Основные риски сегодня связаны с угоном учетных данных администраторов и атаками на гипервизоры, поэтому мы рекомендуем начинать с простых, но эффективных действий: внедрения многофакторной аутентификации (2FA), ограничения доступа к сети управления и регулярного обновления компонентов».
Дмитрий Горохов,
директор департамента виртуализации и контейнеризации компании «Инфосистемы Джет»
Эксперт предупреждает, что в первую очередь взламывают популярные решения, такие как VMware, поэтому именно они требуют наиболее тщательной настройки безопасности и регулярного аудита.

Платформа виртуализации состоит из двух основных программных слоев:
- гипервизор (исполнительный слой), на котором непосредственно запускаются виртуальные машины;
- система централизованного управления (управляющий слой), которая объединяет гипервизоры в кластеры, отвечает за интеграцию со службами каталогов, ролевую модель доступа и распространение настроек.
Компрометация любого из этих слоев означает потерю контроля над всей виртуальной инфраструктурой. Харденинг каждого слоя мешает атакующему «перепрыгнуть» с одного уровня на другой и позволяет компании сохранить контроль над виртуальной инфраструктурой.
Рекомендации по защите системы централизованного управления:
- ограничить доступ к сети управления;
- не предоставлять доступ к системе управления из сети Интернет;
- установить корпоративные сертификаты безопасности;
- интегрировать со службой каталогов по безопасному протоколу (LDAPS) или не интегрировать совсем;
- использовать двухфакторную аутентификацию;
- настроить тайм-ауты сессий;
- настроить сбор и анализ логов.
Рекомендации по защите гипервизора:
- ограничить доступ к гипервизору (настройки SSH, изоляция сети управления);
- не устанавливать сторонние пакеты;
- настроить пароль для загрузчика;
- регулярно устанавливать обновления от вендора.
Дмитрий Горохов отмечает, что платформы виртуализации — это не основной источник проблем. Чаще всего инфраструктуру ломают изнутри: злоумышленники просачиваются через службы каталогов и дальше уже шифруют данные внутри виртуальных серверов. Поэтому особенно важно предотвратить распространение зловредного кода и проникновение в другие виртуальные серверы. Для этого необходимо ограничить взаимодействие между виртуальными серверами с помощью микросегментации.
«В основе микросегментации лежит распределенный файрвол, который применяет политики безопасности непосредственно на уровне виртуального сетевого интерфейса виртуальной машины и ограничивает взаимодействие виртуальных серверов в пределах одной сети. Мы как-то строили VDI (инфраструктуру виртуальных рабочих столов) на 14 тыс. рабочих мест. Представьте себе потенциальную поверхность атаки! Без микросегментации одна зараженная ВМ моментально могла заразить остальные в пределах одного большого сетевого сегмента. Современная информационная безопасность в виртуальной инфраструктуре без микросегментации просто немыслима».
Дмитрий Горохов,
директор департамента виртуализации и контейнеризации компании «Инфосистемы Джет»
Отдельного внимания заслуживает сеть взаимодействия с системами хранения данных: например, при использовании iSCSI (протокола подключения к СХД по IP-сети) ее также необходимо сегментировать и защищать от несанкционированного доступа. Важно разделять задачи отказо- и киберустойчивости. Репликация помогает сохранить доступность сервисов при сбоях, но не защищает, если преступник контролирует административные системы.
Харденинг СРК
Системы резервного копирования сегодня под прицелом киберпреступников. Они изучают архитектуру СРК, учетные записи и политики хранения, чтобы удалить бэкапы еще до атаки. А вместе с ними — и последнюю надежду компании на восстановление ИТ-инфраструктуры.
«Когда все идет не по плану, ни отказоустойчивые кластеры, ни репликация уже не спасают — у вас остается только резервная копия. В этот момент возникает вопрос: получится ли вообще восстановиться? Мы исходим из того, что нужно заранее готовиться к сценарию, в котором часть защиты уже не сработала, а часть инфраструктуры взломана. Задача СРК — пережить этот момент, даже если домен или административные учетные записи захвачены».
Игорь Шконда,
руководитель направления систем резервного копирования компании «Инфосистемы Джет»
Главная ошибка — держать СРК в том же контуре, что и основную среду, используя те же учетные записи. Современный подход требует изоляции. На практике это выглядит как создание двух контуров СРК: рабочего (в продуктивной инфраструктуре) и максимально изолированного, который в компании «Инфосистемы Джет» называют «Бункером». Его основная задача — получить и сохранить доверенные резервные копии, даже если все вокруг разрушено.
Рекомендации по харденингу системы резервного копирования
- Внедряйте минимальные привилегии и ролевую модель
Используйте фиксированный набор ролей (например, как в «Кибербэкапе»), предусмотрев отдельную роль для специалистов ИБ с правами только на просмотр. Помните: если агент СРК на Linux работает из-под root, компрометация ОС автоматически ведет к компрометации всей системы — поэтому одновременно усиливайте и ПО СРК, и саму операционную систему.
- Изолируйте СРК от домена
Интеграция со службами каталога (например, MS AD, FreeIPA) упрощает управление, но создает риск: при компрометации домена атакующий получает доступ к компонентам СРК, в частности к ПО. Поэтому выделите второй, максимально изолированный домен с собственными учетными записями, строгой парольной политикой, полностью независимый от основной службы каталогов. Или используйте локальные учетные записи в небольших инфраструктурах!
- Используйте неизменяемые хранилища
Применяйте WORM-хранилища или Object Lock на S3 — механизмы, которые защищают резервные копии от удаления и перезаписи в течение заданного срока. Выбирайте режим в зависимости от требований: Governance (параметры срока хранения можно скорректировать специальной учетной записью) или Compliance (изменение невозможно даже с правами администратора). Сроки хранения задавайте заранее: изменить их задним числом нельзя. Для ленточных библиотек также можно использовать WORM-ленты — в таком случае их необязательно отчуждать из ленточной библиотеки.
- Шифруйте резервные копии и храните ключи отдельно
Включайте шифрование (AES) в настройках задания или через командную строку (CLI). Никогда не храните ключи ни в системе управления, ни в самих копиях: их потеря делает восстановление невозможным.
- Сегментируйте сеть и используйте безопасные протоколы
Управляющий сервер, медиасерверы и агенты резервного копирования требуют открытия портов, но открывайте только реально используемые соединения. Размещайте СРК в отдельном VLAN с жесткими правилами межсетевого экрана. Отключайте неиспользуемые порты и не используйте небезопасные протоколы (telnet, ftp и т. д.) для управления СРК и хранения резервных копий.
- Регулярно проверяйте целостность и восстанавливаемость данных
Выполняйте CRC-проверки (контрольные суммы) для подтверждения целостности данных — эту ресурсоемкую операцию выносите в отдельные планы. Для виртуальных машин проводите тестовый запуск из бэкапа с проверкой отклика (VMware Tools / Hyper-V Heartbeat).
- Включайте активную защиту от шифровальщиков
На агентах и медиасерверах активируйте встроенные модули (например, Active Protection, Ransomware Protection), которые в реальном времени отслеживают аномальную активность (массовое шифрование, нетипичную нагрузку) и могут автоматически остановить подозрительный процесс, оповестив при этом администратора СРК.
- Настройте аудит и мониторинг событий
Ведите журнал ключевых событий (запуск заданий, удаление копий, изменения конфигурации). Настройте передачу этих событий во внешние SIEM-системы через протокол syslog (в том числе в формате CEF) — это необходимо для расследования инцидентов.
Харденинг СРК — это комплексная оперативная мера, включающая сегментацию компонентов СРК, минимизацию привилегий, шифрование и неизменяемость хранилищ. Однако решающую роль играют регулярные процессы: проверки копий и тестовые восстановления. Но даже лучшие настройки не дают полной гарантии, если система остается в общем контуре. Полную устойчивость способен обеспечить только полностью изолированный «Бункер». Именно эта резервная копия становится последним «выжившим», когда основная инфраструктура скомпрометирована.
Харденинг ОС и служб каталогов
Харденинг операционных систем и служб каталогов — это последняя линия обороны. Злоумышленники проникают в системные сервисы, когда остальные рубежи уже пройдены.
«Харденинг — это подход, основанный на культуре проактивной защиты и принципе минимализма. Если компонент не нужен системе, его следует отключить. Если пользователю не требуются дополнительные права, их не нужно выдавать. Обязательным элементом является внедрение мандатного контроля доступа (например, SELinux, AppArmor или PARSEC) как дополнительного рубежа, ограничивающего действия даже привилегированных процессов и администраторов. Его настройка действительно требует времени и экспертизы, но отключать этот механизм ради упрощения администрирования — распространенная ошибка, которая заметно ослабляет защиту системы».
Антон Голощапов,
руководитель направления инфраструктурных сервисов Linux компании «Инфосистемы Джет»
Для харденинга операционных систем Linux эксперт рекомендует:
- настроить права на точки монтирования и отключать автоматическое монтирование устройств;
- включить журналирование событий;
- настроить авторизацию для однопользовательского режима;
- отключить службы и сервисы, которые не используются;
- настроить параметры сети и отключать неиспользуемые протоколы;
- настроить контроль целостности;
- регулярно обновлять версии ОС;
- настроить доступ, аутентификацию и авторизацию;
- ограничить права на основные конфигурационные файлы.
Службы каталогов — Active Directory (AD) или ее альтернативы на базе Samba и FreeIPA — требуют отдельного внимания, поскольку через них злоумышленник может получить дополнительные привилегии и перемещаться по инфраструктуре. Здесь применяются строгие парольные политики и ролевая модель, меняются административные пароли после первичной настройки, отключаются устаревшие протоколы и анонимный bind LDAP (операция аутентификации пользователя в службе каталогов), а обычный LDAP (протокол доступа к службе каталогов) заменяется на LDAPS (защищенная версия с шифрованием соединения).
При этом универсального набора настроек для всех сред не существует. Требования зависят от конкретной платформы и ее реализации. Поэтому изменения сначала проверяют на стенде, максимально близком к среде заказчика, и только после тестирования переносят в продуктив.
«Харденинг — это отчасти творческий процесс, ведь технологии взлома и техники атаки зачастую универсальны для различных операционных систем, но при этом конкретным сервисам присущи уникальные нюансы. Решение на базе Samba имеет одни недостатки, а на базе FreeIPA — совершенно другие. Поэтому мы сначала обязательно занимаемся стендированием: создаем копию среды заказчика, выдвигаем требования, отрабатываем их в тестовой среде и только потом переносим в продуктив. Если в скоуп добавляются новые ОС, мы повторяем процесс индивидуально для каждого компонента».
Антон Голощапов,
руководитель направления инфраструктурных сервисов Linux компании «Инфосистемы Джет»
Эксперт также отмечает, что на уровне оборудования и операционных систем харденинг начинается с соблюдения баланса между безопасностью и функциональностью. Если максимально закрутить «гайки» и внедрять все требования ИБ, сервисы будут хорошо защищены, но с большой вероятностью перестанут работать.
Гонка без финиша
Эксперты подчеркивают, что харденинг — это процесс, он требует постоянной работы: инфраструктура меняется, появляются новые системы и сервисы, обновляются конфигурации и права доступа. Поэтому настройки безопасности необходимо регулярно пересматривать и проверять, в том числе с помощью пентестов и тестовых стендов.
Антон Голощапов добавляет, что для системного подхода к харденингу необходимо регулярно проводить аудит и мониторинг угроз. Харденинг бесполезен, если вы не видите попыток взлома.
Отслеживать эволюцию угроз и обновлять методы защиты помогают несколько авторитетных источников:
- MITRE ATT&CK (attack.mitre.org) — глобальная база знаний, систематизирующая тактики, техники и процедуры, которые используют злоумышленники на всех этапах атаки;
- MITRE D3FEND (d3fend.mitre.org) — каталог контрмер и защитных техник для каждой атаки;
- Банк данных угроз безопасности информации ФСТЭК (bdu.fstec.ru) — российский государственный реестр угроз и уязвимостей, обязательный к применению при построении моделей угроз для государственных информационных систем, объектов КИИ и систем персональных данных;
- CIS Benchmarks (cisecurity.org) — международный стандарт безопасной конфигурации, который переводит общие принципы харденинга в конкретные, проверяемые настройки для операционных систем, СУБД, облачных платформ и сетевого оборудования.
При этом эксперты компании «Инфосистемы Джет» подчеркивают, что оценивать на уязвимости важно не отдельные компоненты, а всю возможную цепочку атаки — от этапа разведки инфраструктуры до действий по целям (к примеру, критичным системам и резервным копиям). Один из вариантов такой комплексной проверки — «Месячник харденинга», который объединяет мероприятия по защите ИТ-инфраструктуры от проникновения, развития атаки и ее возможных последствий.
Харденинг не исключает саму возможность атаки, но усложняет злоумышленнику путь внутри инфраструктуры и снижает потенциальный масштаб инцидента. В этом и заключается его роль в обеспечении непрерывности бизнеса: чем меньше систем окажется скомпрометировано, тем больше возможностей у компании сохранить критичные процессы и быстрее восстановиться.
Оперативные действия:
МЕСЯЧНИК ХАРДЕНИНГА
Для защиты от проникновения
- Поиск утечек легитимных аутентификационных данных
- Сканирование сетевого периметра на уязвимости (в том числе мисконфигурации)
- Анализ безопасности способов удаленного подключения к инфраструктуре (в том числе подрядных организаций)
- Сканирование сетевого периметра подрядчиков на уязвимости (в том числе мисконфигурации)
Для защиты от развития атаки
- Анализ сетевых доступов (ACL) на предмет широких разрешающих правил сетевого доступа
- Аудит безопасности корпоративного домена
- Анализ NTDS.dit по радужным таблицам на предмет нестойких паролей
- Анализ безопасности реализованных практик администрирования
- Поиск сетевых ресурсов с неограниченным доступом
Для защиты от возможных последствий
- Анализ безопасности контура системы резервного копирования
- Уточнение приоритета восстановления с учетом критичности бизнес-процессов
- Тестовое восстановление из резервных копий для оценки времени восстановления
- Разработка кризис-менеджмент-плана и сценариев реагирования на кризисные ситуации
- Проработка и тестирование (tabletop) плана кризисного реагирования:
- Определение профиля возможных техник, эмуляция отдельных сценариев (C2 Connects, WMI Backdoor, LSASS Dump, Recon Activity, Scheduled Task Creation и др.)
- Compromise Assessment (выявление следов компрометации инфраструктуры)
- Тестирование на проникновение (фишинг, компрометация корпоративного домена, системы резервного копирования, компрометация подрядчика)