Мы рассматриваем реальный публичный инцидент не как перепечатку новости, а через вопрос: «как бы вы защитились от этого?» Это разбор, основанный на публичных материалах (официальном отчете комиссии по расследованию инцидента и публикациях в СМИ). Источники перечислены в конце; мы не приводим инструкций для атак и персональных данных. Названия подрядчиков и поставщиков не являются главным, поэтому мы описываем их по роли, а не по имени.
- Цель
- Osaka General Medical Center (Осакская префектурная организация больниц). Системы больницы, включая EMR
- Обнаружение
- Ранним утром 31 октября 2022 года (сбой в системе подрядчика, затем отказ EMR в больнице)
- Вход (по отчету)
- VPN-устройство для удаленного обслуживания на сервере компании, поставлявшей питание: не было пропатчено и было доступно с утекшими учетными данными. Поскольку больница и подрядчик были постоянно соединены, злоумышленники через подрядчика попали в больницу
- Почему распространилось (по отчету)
- Общие пароли для серверов и ПК, широкие права администратора, отсутствие антивируса на серверах EMR, слабая сегментация и убеждение, что «закрытая сеть безопасна»
- Последствия
- EMR не работала; амбулаторная помощь, плановые операции и прием экстренных пациентов были ограничены. Полное восстановление заняло более двух месяцев. По сообщениям, больница не платила выкуп
- Основные меры
- Инвентаризация подключений подрядчиков и патчи VPN, доступных из интернета / прекращение повторного использования учетных данных и принцип наименьших привилегий / сегментация / EDR и мониторинг / медицинский BCP (бумажные процедуры, офлайн-резервные копии, отработанное восстановление)
Что произошло (простым языком)
Программа-вымогатель шифрует системы, делая их непригодными для использования, и требует платы за восстановление. В данном случае первой была взломана не сама больница, а связь подрядчика. На сервере компании, поставлявшей пациентам питание, находилось VPN-устройство для удаленного обслуживания. По отчету комиссии, это устройство не было пропатчено, и войти в него можно было с ранее утекшими учетными данными.
Система EMR больницы и система подрядчика были постоянно соединены для обмена данными, например о количестве порций. Поэтому, если подрядчик был взломан, злоумышленник мог попасть внутрь больницы. Слабость подрядчика стала слабостью больницы. Отчет объясняет, почему ущерб распространился по всей EMR: учетные данные были общими, многие пользователи имели права администратора, на критически важных серверах не было антивируса, а сеть не была должным образом сегментирована. Как только злоумышленники получили доступ в одной точке, внутри почти ничто не остановило распространение, и шифрование быстро расширилось. Амбулаторная помощь прекратилась, плановые операции отменили, прием экстренных пациентов ограничили, а полное восстановление EMR заняло более двух месяцев.
«Закрытая сеть безопасна» — ложное представление; связь с подрядчиком — часть вашей поверхности атаки
Ключевым выводом стало убеждение, что сеть, отрезанная от внешнего мира, по своей природе безопасна. На деле всегда есть соединения закрытой сети с внешним миром: VPN для обслуживания, постоянные связи с подрядчиками, удаленная поддержка. Даже с одним таким соединением и без внутренней сегментации злоумышленник, проникший однажды, может добраться до всего. Соединение подрядчика или обслуживающей организации на бумаге может принадлежать другой компании, но с точки зрения безопасности оно является частью вашей поверхности атаки и должно учитываться как таковое.
Этапы атаки и способы ее остановить
И здесь цепочка имела точку остановки на каждом этапе. Читайте ее не как шаги атаки, а как места, где ее можно было прервать.
① Вход через непропатченный VPN подрядчика для обслуживания + утекшие учетные данные
VPN для обслуживания, доступный из интернета, не был пропатчен и был доступен с ранее утекшими учетными данными.
⊘ Стоп: быстро патчить VPN, доступные из интернета; инвентаризировать подключения подрядчиков; MFA; отзывать утекшие учетные данные
② Больница и подрядчик постоянно соединены → доступ к внутренней сети
Постоянная связь для данных о питании означала, что взлом у подрядчика достиг внутренней сети больницы.
⊘ Стоп: изолировать связь с подрядчиком в отдельном сегменте; минимизировать трафик между сегментами; контролировать границу
③ Общие пароли, все админы, слабая сегментация → распространение на все серверы
Общие учетные данные и широкие права позволили шифрованию быстро дойти до серверов EMR.
⊘ Стоп: прекратить повторное использование учетных данных; принцип наименьших привилегий; сегментировать сеть; мониторинг входов и блокировка
④ Слабые антивирус/EDR и недостаточная подготовка к восстановлению → EMR долго не работает
На критически важных серверах защита была слабой, а восстановление заняло время, поэтому помощь ограничивалась на протяжении недель.
⊘ Стоп: EDR/антивирус; офлайн-резервные копии и отработанное восстановление; медицинский BCP (бумажные процедуры)
Хронология по опубликованным данным
31.10.2022
Ранним утром сбой в системе подрядчика, затем отказ EMR в больнице. Подтверждена программа-вымогатель; системы отключили, чтобы остановить распространение.11.2022
Амбулаторная помощь в основном прекратилась, плановые операции отменили, прием экстренных пациентов ограничили тяжелыми случаями. Помощь оказывалась на бумажных носителях.12.2022
Основные системы запускали поэтапно; амбулаторная помощь постепенно возобновлялась.11.01.2023
Системы, включая EMR, в основном были полностью восстановлены: более двух месяцев до полного восстановления.28.03.2023
Комиссия по расследованию инцидентов информационной безопасности опубликовала отчет, указав путь проникновения, факторы распространения и убеждение, что «закрытая сеть безопасна».
Коренная причина: не только точка входа, но и контроль над подрядчиками и распространение ущерба
Считать, что «взломали VPN больницы», значит упустить главное. Злоумышленники проникли через подрядчика, но ущерб по всей EMR распространила внутренняя организация: общие учетные данные, избыточные права, слабая сегментация. Настоящий вопрос в том, можно ли было ограничить ущерб, как только кто-то получил доступ.
Слабые места, выявленные в отчете (на момент инцидента)
- Вход через непропатченный VPN для обслуживания подрядчика + утекшие учетные данные
- Больница и подрядчик постоянно соединены, поэтому слабость подрядчика достигла внутренней сети
- Общие пароли на серверах и ПК и широкие права администратора у пользователей
- Отсутствие антивируса на критически важных серверах EMR; слабая сегментация
- Убеждение, что «закрытая сеть безопасна», которое ослабило защиту
Защищенная конфигурация (профилактика)
- Инвентаризация подключений подрядчиков; быстрые патчи VPN, доступных из интернета; MFA
- Сегментация соединения с подрядчиком и минимизация его трафика
- Прекращение повторного использования учетных данных; принцип наименьших привилегий; мониторинг входов и блокировка
- EDR/антивирус на критически важных серверах; сегментация сети
- Медицинский BCP: бумажные процедуры, офлайн-резервные копии, отработанное восстановление
Медицинский BCP: даже если системы остановлены, помощь должна продолжаться
Для обычной компании «сервис недоступен» может быть концом истории; для больницы главный вопрос — непрерывность оказания помощи. Поэтому медицинский BCP должен исходить из того, что EMR может долго не работать, и в обычное время готовить бумажные процедуры, позволяющие продолжать лечение пациентов, альтернативные порядки для анализов, назначения лекарств и выставления счетов, а также офлайн-резервные копии с версионированием и отработанное восстановление. Выплата выкупа не гарантирует ни восстановления, ни того, что данные не утекут. Опирайтесь на сегментацию, резервные копии и заранее подготовленный BCP. (Связанные случаи: инцидент с Capcom, где точкой входа стало старое VPN- или сетевое устройство; и инцидент с KADOKAWA, где слабая сегментация распространила ущерб на всю компанию.)
Как не допустить повторения в вашей среде
Это применимо далеко не только к больницам, а к любой организации с подключениями подрядчиков или обслуживающих организаций. По порядку приоритетов:
Учитывайте подключения подрядчиков и обслуживающих организаций как собственную поверхность атаки
Фиксируйте, кто, какое устройство и по какому пути подключен к вашей сети. Держите VPN-устройства, доступные из интернета, пропатченными в первую очередь и закрывайте неиспользуемые соединения. Требуйте такого же стандарта обновлений и аутентификации от подрядчиков, как в договоре, так и на практике.
Прекратите повторное использование учетных данных; переходите к принципу наименьших привилегий
Откажитесь от общих паролей на серверах и ПК, разделите учетные записи и отмените повсеместные права администратора в пользу принципа наименьших привилегий. Где возможно, применяйте многофакторную аутентификацию, добавьте блокировку входа и мониторинг, а также отзывайте утекшие учетные данные.
Сегментируйте сеть по важности
Разместите подключения подрядчиков, EMR и офисные системы в отдельных сегментах и минимизируйте трафик между ними. Закрытая сеть не является безопасной автоматически, поэтому сегментируйте и внутри закрытой сети. Включите это в вашу базовую линию информационной безопасности организации.
Защищайте критически важные серверы и создайте медицинский BCP и план восстановления
Установите EDR или антивирус на критически важные серверы, такие как EMR. В обычное время определите, как вы будете продолжать лечение пациентов и работу, если основные системы долго не работают, — с бумажными процедурами, офлайн-резервными копиями и отработанным восстановлением. Готовьтесь так, будто оплата не вернет вам работоспособность.
Где это пересекается с принципами проектирования этого сайта
Вывод в том, что защита не заканчивается на границах вашей организации: подключение подрядчика или обслуживающей организации становится частью вашей поверхности атаки. Это противоположно принципам этого сайта: ограничивать распространение ущерба, если нарушена одна часть системы, изолировать важное и держать соединения и привилегии минимальными. Убеждение, что «закрытая сеть безопасна», несет ту же опасность, что и один общий пароль, открывающий доступ ко всем серверам, или единая точка отказа. Учитывайте, что подключено к вам, прекращайте повторное использование учетных данных, сегментируйте по важности и готовьтесь продолжать работу, когда что-то останавливается. Эти меры может внедрить любая организация независимо от размера и сферы деятельности.
Источники (публичные материалы)
Факты в этом тексте основаны на перечисленных ниже публичных сведениях. Мы не приводим инструкций для атак, персональных данных или названий подрядчиков и поставщиков, а только выводы для защиты.
- Осакская префектурная организация больниц, Osaka General Medical Center: «Отчет комиссии по расследованию инцидента информационной безопасности» (опубликован 28 марта 2023 года) — gh.opho.jp
- Публикации в СМИ (вход через VPN подрядчика для обслуживания, общие пароли, убеждение «закрытая сеть безопасна», восстановление, 2022–2023 годы) — на основе официального отчета комиссии
Читайте дальше
- Больницы в 2026 году: нарушения оказания помощи из-за кибератак (США, Бельгия, Япония) и процедуры работы в аварийном режиме
- Когда точкой входа становится VPN: VPN-устройства — самый частый путь проникновения: защита удаленного доступа после взлома Цифрового агентства
- Глоссарий: что такое программа-вымогатель (как она работает и как не платить) / что такое EDR (обнаружение на конечных точках и серверах)
- Практика: основы резервного копирования (правило 3-2-1) / базовая линия безопасности организации (сегментация, принцип наименьших привилегий)
- Случаи: программа-вымогатель в больнице Ханда (2021) (непропатченная уязвимость VPN CVE и изоляция резервных копий) / программа-вымогатель в KADOKAWA (2024) (слабая сегментация распространила атаку на всю компанию) / программа-вымогатель в Capcom (2020) (точкой входа стало старое VPN-устройство) / атака на цепочку поставок Codecov (2021) (злоупотребление доверенным каналом)