Облачная платформа

К разделу «Облачная платформа

Облачные ресурсы IaaS
Облачные ресурсы IaaS
Облачная платформа на базе собственных дата-центров уровня TIER III
Ускоренные вычисления на базе NVIDIA GPU
Ускоренные вычисления на базе NVIDIA GPU
Для сложных вычислений, машинного обучения и обработки видео/3D-графики
Частное облако
Частное облако
Защищенное частное облако (УЗ-1, К-1, лицензии ФСБ и ФСТЭК)
Кластеры Kubernetes
Кластеры Kubernetes
Развертывание, масштабирование, репликация и мониторинг контейнерных приложений
Защищенное облако 152-ФЗ
Защищенное облако 152-ФЗ
Размещение конфиденциальных данных в защищенной инфраструктуре и аудит работы с персональными данными
Резервное копирование для бизнеса
Резервное копирование для бизнеса
Автоматизированное управление резервными копиями виртуальных машин и баз данных
База данных в облаке
База данных в облаке
Управляемые СУБД с масштабированием по мере необходимости и высоким SLA
Миграция в облако Linx Cloud
Миграция в облако Linx Cloud
Перенос IT-инфраструктуры в облако Linx Cloud из других платформ
Объектное хранилище S3
Объектное хранилище S3
Защищенное объектное хранилище S3 по стандартам 152-ФЗ на платформе Linx Cloud
Облако для ВУЗов
Облако для ВУЗов
25% скидка на облачные сервисы от цены прайса на год!
Безопасность

К разделу «Безопасность

Статический анализ исходного кода SAST
Статический анализ исходного кода SAST
Облачный сервис для защиты приложений на этапе разработки исходного кода
Двухфакторная аутентификация MFA
Двухфакторная аутентификация MFA
Удаленный доступ – легко и безопасно. Сервис MFA подходит для любого типа инфраструктуры
Облачная защита WAF + AntiDDoS
Облачная защита WAF + AntiDDoS
Многоуровневая защита интернет-ресурсов и веб-приложений с минимальными вложениями
Аварийное восстановление в AWS
Аварийное восстановление в AWS
Быстрое и экономичное восстановление данных и приложений. RPO — секунды, RTO — минуты
DRaaS — аварийное восстановление
DRaaS — аварийное восстановление
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Межсетевой экран нового поколения NGFW
Межсетевой экран нового поколения NGFW
Виртуальный межсетевой экран нового поколения для комплексной защиты ресурсов в облаке
Антивирус
Антивирус
Защита инфраструктуры от вирусов и шифровальщиков
Сканирование на уязвимости
Сканирование на уязвимости
Мониторинг и оценка уязвимостей ИТ-инфраструктуры
Security Operations Center (SOC)
Security Operations Center (SOC)
Центр противодействия кибератакам на любом этапе инцидента
ГОСТ-VPN
ГОСТ-VPN
Защищенный канал связи для ИСПДн
Межсетевой экран
Межсетевой экран
Защита сети компании от несанкционированного доступа извне
Аттестация частного облака для ГИС
Аттестация частного облака для ГИС
Размещение госинформационных систем «под ключ» с соблюдением К1 и УЗ-1 (ИСПДн)
Security Awareness
Security Awareness
Обучение сотрудников навыкам информационной безопасности на базе онлайн-платформы
Тарифы База знаний
Облако
Назад к публикациям

Киберсхватка: как действовать во время атаки вируса-шифровальщика

Статья
05.03.2025 3 минуты чтения
Киберсхватка: как действовать во время атаки вируса-шифровальщика

Число атак с использованием программ-шифровальщиков не снижается – риск столкнуться с вымогателями есть у всех компаний независимо от размера и отрасли. Как избежать ошибок при реагировании на такие инциденты, рассказывает Виталий Гололобов, архитектор решений облачного провайдера Linx Cloud.

Программы-шифровальщики – не новый вид вредоносного программного обеспечения (ВПО), но особенно часто их стали использовать в последние несколько лет. Так, в 2024 году число атак шифровальщиков в России выросло на 44%. В 10% случаев целью атаки было не получение выкупа, а нанесение урона жертве.  


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

Немного о поведении шифровальщиков

Задача атакующего, который использует программу-вымогатель, заставить жертву заплатить выкуп. Это значит, что ему нужно не просто зашифровать инфраструктуру или ее чувствительные сегменты, но и максимально усложнить компании самостоятельное устранение проблемы. Для этого злоумышленник будет стараться:

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

Важно помнить, что злоумышленники активно эксплуатируют фактор стрессовой ситуации, чтобы побудить жертву на необдуманные решения. Понимая цели и механику действий хакеров, стоит выстраивать защиту и составлять план действий на случай атаки. 

Ошибка №1: недостаточная глубина хранения бэкапов

По нашим оценкам, около половины компаний пренебрегают правилами работы с бэкапами, в том числе золотым правилом бэкапирования «3-2-1», касающимся форматов и площадок хранения бэкапов.  


На сегодняшний день бэкап во многих компаниях из-за экономии ресурсов выглядит как ежедневные инкременты и фулл-копии, создаваемые раз в неделю, с глубиной хранения одна-две недели. При такой политике шанс восстановить незараженную инфраструктуру крайне мал – организация буквально пытается восстановиться из уже зашифрованной копии. 


По нашему опыту, рекомендуемый срок бэкапа должен составлять не менее 30 дней. Это коррелирует со средним временем, которое атакующие тратят на анализ и закрепление внутри инфраструктуры компании до начала процесса шифрования. 

Ошибка №2: упование на disaster recovery

Многие компании используют резервные площадки, которые дублируют их основную ИТ-инфраструктуру или ее наиболее критичные компоненты. 


Это помогает в случае инцидента с основным ЦОД, но очень редко работает в случае атаки с применением шифровальщика – компании стремятся минимизировать время выполнения заданий репликации, чтобы снизить RPO при наступлении инцидента.  


Существует большой риск, что синхронизация между площадками произойдет, когда основная уже заражена, а присутствие шифровальщика еще не обнаружено. В результате зараженными и зашифрованными окажутся сразу обе площадки. Также вероятна ситуация, когда на резервную площадку в процессе синхронизации попадут уже зашифрованные данные. 


Disaster recovery защитит вас от катастрофы (отключение электричества, пожар, наводнение, выход из строя оборудования на одной из площадок), но не от вредоносного воздействия на уровне ПО. 

Ошибка №3: поспешное развертывание бэкапов

Кибермошенники часто стараются найти бэкап и удалить либо заразить его. В случае, когда злоумышленники не добрались до данных, которые хранятся у облачного провайдера, компания стремится как можно быстрее вернуть работоспособность сервиса и часто начинает восстанавливаться прежде, чем будут окончательно локализованы момент и путь заражения. 


Это может закончиться повторным шифрованием, поскольку последние резервные копии данных уже были заражены или путь хакера в компанию еще не устранен – он по-прежнему имеет доступ к инфраструктуре и может доставить ВПО. Это достаточно очевидный кейс, но в моменте сотрудники компании, находясь в состоянии стресса, забывают о такой вероятности и о необходимости проверить, какие бэкапы можно использовать и ликвидирована ли угроза.  


Удостоверьтесь, что вы восстанавливаетесь в нескомпрометированную инфраструктуру. 

Ошибка №4: превалирование технических мер над организационными

Многие ошибки имеют в корне одну причину – это спешка и стресс. Чтобы нивелировать эти факторы, важно иметь заранее разработанный сценарий реагирования на инцидент с использованием шифровальщика, в том числе с указанием людей, которые будут принимать конечные решения. 


На уровне организационных мер важно выполнить две основные задачи: 

  • убедиться, что резервная версия не подвержена тем же уязвимостям, что и основная, либо принять компенсирующие меры; 
  • по возможности отследить путь злоумышленника и перекрыть ему доступ к инфраструктуре организации. 

Возможна ситуация, когда в критический момент оказывается, что нет ответственного за действия компании во время атаки. Например, назначенный сотрудник недавно уволился, а другого назначить забыли. Поэтому роль ответственного лучше закреплять не за конкретным человеком, а за должностью, не забывая снабжать занимающего ее специалиста подробной инструкцией. В ней (хотя бы на базовом уровне) должны быть прописаны параметры, согласно которым сотрудник принимает те или иные решения. 


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


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


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


*** 


Все вышеперечисленное является не «серебряной пулей», а лишь гигиеническим минимумом, на уровне «мойте руки перед едой». Для обеспечения полноценной безопасности инфраструктуры необходимы специальные средства защиты периметра (от антивируса и песочницы до статического анализа кода, WAF и постоянного обучения персонала), а также квалифицированные ИБ-эксперты. 

Виталий Гололобов
Автор статьи
Виталий Гололобов

Архитектор решений облачного провайдера Linx Cloud

Остались вопросы?

Опишите вашу задачу, и мы поможем вам ее решить

Или напишите нам info@linxdatacenter.com
Нажимая кнопку «Отправить», вы соглашаетесь с Политикой обработки персональных данных ООО «Связь ВСД»
Читать также
Linx Cloud модернизировал сеть дата-центра в Москве: скорость передачи данных выросла в 10 раз
Linx Cloud модернизировал сеть дата-центра в Москве: скорость передачи данных выросла в 10 раз
Новость
03.09.2025 3 мин минуты чтения 3 мин мин
Kubernetes на базе Deckhouse в облаке Linx Cloud: встроенный мониторинг, безопасность и управление сертификатами
Kubernetes на базе Deckhouse в облаке Linx Cloud: встроенный мониторинг, безопасность и управление сертификатами
Статья
16.07.2025 5 мин. минут чтения 5 мин. мин
Linx Cloud запускает облако на OpenStack в опытно-промышленную эксплуатацию
Linx Cloud запускает облако на OpenStack в опытно-промышленную эксплуатацию
Новость
11.07.2025 3 мин. минуты чтения 3 мин. мин
Linx Cloud вошел в топ-10 провайдеров в рейтинге IaaS Enterprise
Linx Cloud вошел в топ-10 провайдеров в рейтинге IaaS Enterprise
Новость
04.07.2025 3 мин. минуты чтения 3 мин. мин
Частные облака от Linx Cloud вошли в топ-5 рейтинга по версии "Компьютерры"
Частные облака от Linx Cloud вошли в топ-5 рейтинга по версии "Компьютерры"
Новость
06.06.2025 1 мин. минута чтения 1 мин. мин
Linx Cloud на ИТ-Полигоне 2025
Linx Cloud на ИТ-Полигоне 2025
Новость
28.05.2025
Комплексная защита приложений на базе SAST и облачного WAF
Комплексная защита приложений на базе SAST и облачного WAF
Новость
27.05.2025 1 минута чтения 1 мин
Linx Cloud показал 81% рост за 2024 год
Linx Cloud показал 81% рост за 2024 год
Новость
30.04.2025
Кибератаки 2025: кто в зоне риска и чем поможет WAF
Кибератаки 2025: кто в зоне риска и чем поможет WAF
Статья
28.04.2025 3 минуты чтения 3 мин
Сильная облачность: что еще ждет рынок IT-инфраструктуры в 2025 году
Сильная облачность: что еще ждет рынок IT-инфраструктуры в 2025 году
Статья
03.04.2025 5 минут чтения 5 мин