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

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

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

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

Статический анализ исходного кода SAST
Статический анализ исходного кода SAST
Облачный сервис для защиты приложений на этапе разработки исходного кода
Двухфакторная аутентификация MFA
Двухфакторная аутентификация MFA
Удаленный доступ – легко и безопасно. Сервис MFA подходит для любого типа инфраструктуры
Облачная защита WAF + AntiDDoS
Облачная защита WAF + AntiDDoS
Многоуровневая защита интернет-ресурсов и веб-приложений с минимальными вложениями
Межсетевой экран нового поколения 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 и постоянного обучения персонала), а также квалифицированные ИБ-эксперты. 

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

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

Или напишите нам info@linx.ru
Нажимая кнопку «Отправить», вы соглашаетесь с Политикой обработки персональных данных ООО «Связь ВСД»
Читать также
«Санофи Россия» внедрила частное геораспределенное облако на базе Linx Cloud
«Санофи Россия» внедрила частное геораспределенное облако на базе Linx Cloud
Новость
23.09.2026 2 минуты чтения 2 мин
Linx Cloud помог «Южной телематической компании» отразить DDoS-атаку и возобновить работу
Linx Cloud помог «Южной телематической компании» отразить DDoS-атаку и возобновить работу
Новость
21.09.2026 1 минута чтения 1 мин
Linx Cloud — партнер главного ИТ-события для ритейла
Linx Cloud — партнер главного ИТ-события для ритейла
Новость
20.08.2026 2 минуты чтения 2 мин
Когда бизнес дозревает до частного облака: интервью с экспертом Linx Cloud
Когда бизнес дозревает до частного облака: интервью с экспертом Linx Cloud
Статья
22.07.2026 5 минут чтения 5 мин
Linx Cloud запустил страхование бизнес-рисков для клиентов облачной инфраструктуры
Linx Cloud запустил страхование бизнес-рисков для клиентов облачной инфраструктуры
Новость
15.07.2026
Аварийное восстановление до аварии: как настроить DRaaS, пока ничего не упало
Аварийное восстановление до аварии: как настроить DRaaS, пока ничего не упало
Статья
09.07.2026 10 минут чтения 10 мин
VPS или облачный IaaS в 2026: когда дешёвый сервер перестаёт справляться
VPS или облачный IaaS в 2026: когда дешёвый сервер перестаёт справляться
Статья
09.07.2026 10 минут чтения 10 мин
Зачем инфраструктуре сервис S3 в 2026 году
Зачем инфраструктуре сервис S3 в 2026 году
Статья
19.06.2026 5 минут чтения 5 мин
MFA — многофакторная аутентификация
MFA — многофакторная аутентификация
Статья
10.06.2026 3 минуты чтения 3 мин
Linx на ИТ-Полигоне 2026
Linx на ИТ-Полигоне 2026
Новость
29.05.2026