В августе 2023 года злоумышленники позвонили в сервис-деск Clorox — международного производителя бытовой химии и товаров для дома. Представившись сотрудниками компании, они убедили службу поддержки "восстановить" доступ к корпоративным системам.
Последствия быстро вышли за пределы ИТ. Компания столкнулась с нарушением отгрузок и снижением продаж. К концу 2023 года расходы Clorox на расследование и восстановление после атаки достигли примерно $49 млн.
Это не уникальная история. За последние годы крупные компании не раз несли серьёзные потери из-за сбоев у подрядчиков, неудачных обновлений, неподготовленного восстановления и даже нехватки места на сервере.
В статье разберём пять повторяющихся управленческих просчётов, проявившихся в крупных инцидентах 2022–2025 годов, и посмотрим, как проверить наличие таких рисков в собственной ИТ-службе.
Ошибка №1. Недооценивать роль сервис-деска в управлении доступом
Сервис-деск часто воспринимают как вспомогательную функцию: восстановить пароль, разблокировать учётную запись, зарегистрировать новое устройство. Но на практике он участвует в управлении доступом к корпоративным системам. Ошибка в такой процедуре может не просто создать неудобство пользователю, а открыть постороннему доступ к критичной инфраструктуре.
Clorox: доступ восстановили без проверки личности
В августе 2023 года Clorox обнаружил несанкционированную активность в своих системах. Атака нарушила производство и отгрузки, привела к дефициту некоторых товаров и заметно повлияла на финансовые результаты.
К концу декабря компания признала около $49 млн расходов, связанных с реагированием, восстановлением и привлечением внешних специалистов. Впоследствии Clorox предъявила претензии подрядчику Cognizant, обслуживавшему сервис-деск. Компания утверждала, что злоумышленники смогли получать учётные данные, просто обращаясь в поддержку и представляясь сотрудниками.
Подобные случаи
Похожая схема использовалась при атаках на операторов казино MGM Resorts и Caesars Entertainment. Атака привела MGM примерно к $100 млн потерь, а Caesars заплатила около $15 млн выкупа.
В чём управленческая ошибка
Проблема не в том, что оператор поверил убедительному собеседнику. Опасность возникает, когда процедура позволяет одному сотруднику восстановить критичный доступ на основании сведений, которые можно найти в открытых источниках или получить из предыдущих утечек.
Поэтому обучение персонала само по себе недостаточно. Для операций с повышенным риском процесс должен предусматривать независимую проверку личности и ограничивать полномочия одного оператора.
Что проверить
Проверьте, как сервис-деск восстанавливает доступ к критичным учётным записям:
Как подтверждается личность пользователя. Восстанавливать критичный доступ нельзя только на основании данных, которые злоумышленник может найти в интернете или получить из утечек. Для критичных операций нужен независимый канал подтверждения — например, обратный звонок на заранее зарегистрированный номер.
Может ли один оператор полностью сбросить MFA. Изменение многофакторной аутентификации для администратора или руководителя не должно зависеть от решения одного сотрудника поддержки.
Проверяется ли процесс на практике. Контролируемые попытки социальной инженерии позволяют понять, можно ли обойти процедуру, сославшись на срочность, статус или техническую проблему.
Контрольный вопрос: может ли ваш сервис-деск по одному звонку восстановить доступ администратору, финансовому директору или владельцу критичной системы?
Ошибка №2. Полагать, что вместе с подрядчиком передан и риск
Подрядчику можно передать эксплуатацию системы, поддержку, облачную инфраструктуру или обработку данных. Но нельзя передать последствия остановки бизнеса.
Change Healthcare: один поставщик остановил отраслевую цепочку
В феврале 2024 года программа-вымогатель нарушила работу Change Healthcare — одного из ключевых поставщиков систем медицинского биллинга, обработки страховых требований и платежей в США.
Последствия вышли далеко за пределы самой компании. В течение месяца были нарушены расчёты с врачами и медицинскими организациями по всей стране. Особенно сильно сбой затронул небольшие медицинские центры, обслуживающие более 30 млн малоимущих и незастрахованных пациентов. Часть организаций не могла своевременно направлять страховые требования и получать оплату, а сотрудники были вынуждены возвращаться к бумажному оформлению документов.
Финансовый масштаб также оказался значительным. Уже в первом квартале UnitedHealth признала $872 млн расходов, связанных с атакой, а ожидаемое влияние на результаты 2024 года оценивала в сумму до $1,6 млрд.
Подобные случаи
В мае 2024 года австралийский пенсионный фонд UniSuper столкнулся с многодневной недоступностью своих цифровых сервисов. Причиной стала ошибка при развертывании частного облака Google Cloud: один из параметров внутреннего инструмента Google остался пустым, из-за чего среде автоматически назначили срок существования в один год. Когда этот срок истёк, частное облако было удалено без предварительного уведомления клиента.
UniSuper использовал дублирование инфраструктуры в двух географических зонах, но удаление подписки затронуло обе зоны сразу. Восстановление заняло несколько дней и потребовало круглосуточной работы команд UniSuper и Google Cloud: пришлось заново поднимать сеть и настройки безопасности, восстанавливать приложения, базы данных и сотни виртуальных машин. Сократить потерю данных и ускорить возврат сервисов удалось благодаря резервным копиям, которые хранились отдельно и не были затронуты удалением облачной среды.
Эти случаи показывают, что поставщик может быть не просто контрагентом, а инфраструктурным элементом всей отраслевой цепочки.
Почему SLA не решает проблему
SLA описывает обязательства поставщика: доступность сервиса, время реакции, сроки восстановления и компенсации. Но он почти ничего не говорит о том, что будет делать бизнес во время простоя.
Даже если подрядчик формально выполнил SLA, компания может несколько часов или дней не производить продукцию, не принимать платежи или не обслуживать клиентов. Договорная компенсация обычно несопоставима с такими потерями.
Поэтому для критичных сервисов нужно проверять не только SLA, но и готовность компании работать без поставщика.
Что проверить
Для каждого критичного поставщика нужно оценивать не только условия договора, но и последствия его полного отказа для бизнеса.
Какие процессы зависят от поставщика. Нужно заранее определить, какие операции остановятся при его недоступности: продажи, производство, расчёты, логистика или обслуживание клиентов.
Есть ли резервный способ работы. Следует заранее определить, какие операции можно выполнять вручную, через другой канал или в сокращённом режиме.
Существует ли реальный план выхода. Нужно понимать, сколько времени займёт переход к другому решению, какие данные и интеграции потребуется перенести и кто будет отвечать за этот процесс.
Контрольный вопрос: какие операции остановятся, если один из ваших SaaS-поставщиков исчезнет на семь дней?
Ошибка №3. Путать резервную копию с возможностью восстановления
Успешный статус задания резервного копирования ещё не означает, что бизнес можно вернуть к работе.
British Library: восстановление оказалось отдельным проектом
В конце октября 2023 года British Library подверглась атаке программы-вымогателя. Злоумышленники зашифровали и частично уничтожили серверную инфраструктуру, похитили около 600 ГБ данных, а после отказа библиотеки платить выкуп опубликовали значительную часть украденной информации в даркнете.
Последствия затронули практически все цифровые сервисы. На несколько месяцев стали недоступны сайт, электронный каталог, цифровые коллекции, регистрация читателей, компьютеры в читальных залах и онлайн-заказ материалов. Библиотека продолжала работать, но многие операции пришлось выполнять вручную, а часть услуг оставалась недоступной или сильно ограниченной. Основной каталог удалось вернуть только в январе 2024 года — сначала в режиме чтения, без полноценного оформления заказов.
Стоимость восстановления оценивалась примерно в £6–7 млн — около 40% финансовых резервов библиотеки. При этом восстановление не сводилось к возврату данных из резервных копий: из-за повреждения серверной инфраструктуры и устаревания части систем библиотеке пришлось заново выстраивать значительную часть цифровой среды.
Подобные случаи
В России похожую зависимость бизнеса от восстановления всей технологической цепочки показал сбой СДЭК в мае 2024 года. Компания официально подтвердила недоступность сайта и приложения. Размер ущерба не раскрывался. Инцидент показал, насколько работа физической логистической сети зависит от доступности единой информационной системы: работающие пункты сами по себе не гарантируют возможность принимать и выдавать отправления в обычном режиме.
Почему копия может не помочь
Наличие резервной копии ещё не означает, что систему удастся быстро вернуть в работу. Копия может быть заражена, удалена вместе с основной средой или просто оказаться неполной. Даже корректно восстановленная база данных не гарантирует запуск сервиса: могут не работать аутентификация, интеграции, сертификаты, печать, сетевые маршруты и рабочие места пользователей.
Поэтому проверять нужно не сам факт восстановления данных, а возможность выполнить завершённую бизнес-операцию. Например, недостаточно поднять базу 1С — пользователь должен войти в систему, провести документ, отправить его во внешнюю систему и получить ожидаемый результат.
Что проверить
Проверять нужно способность вернуть бизнес-сервис к полноценной работе с помощью резервных копий.
Изолированы ли резервные копии от основной инфраструктуры. Резервные данные должны храниться отдельно от основной инфраструктуры, чтобы их нельзя было удалить или повредить вместе с рабочей системой.
Восстанавливается ли сервис целиком. Тест должен включать приложение, базу данных, права доступа, интеграции, сертификаты, печать и рабочие места пользователей.
Чем заканчивается тест. Успешным результатом следует считать не запуск сервера, а завершённую бизнес-операцию: проведённый документ, принятый заказ, выполненный платёж или оформленную отгрузку.
Контрольный вопрос: когда вы последний раз восстанавливали не файл или виртуальную машину, а весь бизнес-сервис?
Ошибка №4. Исключать обновления поставщиков из управления изменениями
Обновления внешних поставщиков часто воспринимают как изменения, которые находятся вне контроля внутренней ИТ-службы. Но если такое обновление одновременно затрагивает тысячи устройств, его последствия становятся проблемой самой компании.
Delta Air Lines: обновление поставщика остановило операции
В июле 2024 года дефектное обновление CrowdStrike вывело из строя более 8 млн компьютеров Windows. Многие компании восстановились сравнительно быстро, но Delta Air Lines продолжала массово отменять рейсы ещё несколько дней. Авиакомпания отменила более 6 тыс. рейсов, что затронуло свыше 500 тыс. пассажиров. Генеральный директор Delta оценил финансовый эффект примерно в $500 млн.
Позднее Delta и CrowdStrike публично спорили о том, почему восстановление заняло так много времени. Первопричина находилась у поставщика, но масштаб последствий определялся уже внутренней архитектурой Delta: количеством одновременно затронутых устройств, зависимостью планирования рейсов от недоступных систем, возможностью удалённого восстановления и готовностью ручных процессов.
Подобные случаи
В марте 2024 года изменение конфигурации у внешнего технологического поставщика нарушило работу McDonald’s в нескольких странах. Часть ресторанов временно закрывалась, переходила только на наличные или не могла принимать цифровые заказы. Компания отдельно подчёркивала, что причиной была не кибератака, а изменение конфигурации у подрядчика.
Вывод простой: стороннее обновление может стать причиной инцидента, но продолжительность простоя зависит от того, насколько компания подготовлена к массовому отказу собственной инфраструктуры.
Что проверить
Обновления внешних поставщиков нужно контролировать так же, как изменения, которые выполняет собственная ИТ-служба. Важно заранее понимать не только кто устанавливает обновление, но и как ограничить его распространение, если что-то пойдёт не так.
Развёртываются ли обновления поэтапно. Сначала изменение следует устанавливать на небольшую группу некритичных устройств. Только после проверки их работоспособности обновление можно распространять дальше.
Можно ли быстро остановить обновление. У ИТ-службы должна быть возможность приостановить автоматическое развёртывание при первых признаках сбоя, не дожидаясь решения поставщика.
Есть ли план массового восстановления. Следует определить, какие системы и рабочие места нужно возвращать в первую очередь, сколько специалистов для этого потребуется и как восстанавливать сотни или тысячи устройств одновременно.
Контрольный вопрос: какие внешние поставщики могут массово обновить ваши устройства без контроля со стороны ИТ-службы?
Ошибка №5. Не переводить технологический долг в финансовый риск
Устаревшая система может годами работать без серьёзных сбоев и создавать ощущение, что модернизацию можно отложить. Но чем выше зависимость бизнеса от такой системы, тем дороже обходится даже обычная техническая проблема.
Toyota: заполненный диск остановил 14 заводов
В августе 2023 года Toyota остановила все 14 сборочных заводов в Японии. Причиной была не кибератака. Во время технических работ на сервере закончилось дисковое пространство, из-за чего перестала работать система заказа комплектующих. По данным Reuters, однодневная остановка могла соответствовать примерно $356 млн выручки.
Сама по себе нехватка дискового пространства — обычная техническая проблема. В управленческий риск она превратилась потому, что затронула критичную систему, контроль ёмкости оказался недостаточным, отказ распространился на значительную часть инфраструктуры, резервная среда зависела от основной, а устойчивого альтернативного процесса у бизнеса не было.
Подобные случаи
Другой масштабный пример — операционный кризис Southwest Airlines в декабре 2022 года. Авиакомпания отменила 16,9 тыс. рейсов и затронула около 2 млн пассажиров. Последовавшее урегулирование с Министерством транспорта США составило $140 млн, а компания объявила о крупных вложениях в модернизацию операций и повышение устойчивости.
Что проверить
Технологический долг нужно описывать не возрастом системы, а возможными последствиями её отказа для бизнеса.
Сколько стоит час простоя. Оцените потери производства, продаж, обслуживания клиентов и затраты на восстановление.
Сколько времени займёт возврат системы в работу. Учитывайте не только запуск сервера, но и восстановление данных, интеграций и рабочих мест.
Кто отвечает за принятый риск. Решение отложить модернизацию должно приниматься осознанно, с пониманием возможных потерь и назначенным владельцем риска.
Вместо формулировки:
Система устарела, желательно обновить.
лучше использовать:
Система поддерживается одним специалистом, не имеет тестовой среды и может восстанавливаться до трёх суток. Стоимость часа простоя — 5 млн рублей. Максимальный операционный ущерб одного отказа составляет 360 млн рублей.
Так модернизация становится не техническим пожеланием ИТ-службы, а инструментом управления финансовым риском.
Вместо вывода
Все рассмотренные инциденты начинались по-разному: с телефонного звонка в сервис-деск, отказа подрядчика, дефектного обновления, сложного восстановления или переполненного диска. Но крупные потери возникали по одной причине: компания считала риск контролируемым, хотя этот контроль ни разу не проверялся в условиях реального сбоя.
SLA описывал ответственность поставщика, но не гарантировал продолжение работы бизнеса. Резервные копии сохраняли данные, но не обеспечивали восстановление сервиса. Автоматические обновления упрощали эксплуатацию, но могли одновременно вывести из строя тысячи устройств. Устаревшая система продолжала работать, пока обычная техническая проблема не остановила критичный процесс.
Поэтому готовность ИТ-службы следует оценивать не по количеству регламентов, договоров и резервных копий, а по результатам практических проверок. Можно ли получить критичный доступ по одному звонку? Что произойдёт при недельном отказе поставщика? Сколько времени действительно занимает восстановление сервиса? Можно ли остановить неудачное обновление? Во сколько бизнесу обойдётся отказ устаревшей системы?
Самыми дорогими становятся не обязательно те инциденты, которые невозможно было предсказать. Чаще это сбои, к которым организация считала себя готовой, но ни разу не проверила эту готовность на практике.
