Кибербезопасность в медицине: защита данных пациентов, непрерывность медицинской помощи и устойчивость системы здравоохранения
Цифровизация медицины изменила саму природу киберриска. Электронные медицинские записи, лабораторные информационные системы, телемедицина, цифровые рецепты, медицинские устройства, облачные сервисы,…
Авторы:
Артем Гончаренко, PhD — президент International Technology Transfer Association (ITTA), эксперт по цифровой трансформации, искусственному интеллекту, технологическим инновациям и международному трансферу технологий, руководитель Института ветеранов «Архитектура устойчивости» КНУБА
Михаил Васянович, CEO SmartGT, эксперт по цифровой трансформации и AI, старший научный исследователь Национального института регионального развития, директор БО «БФ „НАМИР“», координатор ИИ-инкубатора ВКУ.
Андрей Станько, PhD, старший преподаватель кафедры компьютерно-интегрированных технологий Тернопольского национального технического университета имени Ивана Пулюя. Преподаватель Центра информационных технологий ТНТУ
Цифровизация медицины изменила саму природу киберриска. Электронные медицинские записи, лабораторные информационные системы, телемедицина, цифровые рецепты, медицинские устройства, облачные сервисы, системы страховых расчётов и национальные реестры создают значительные преимущества для пациентов, но одновременно делают информационную инфраструктуру частью процесса оказания медицинской помощи. Поэтому кибербезопасность в медицине — это уже не только вопрос конфиденциальности. Это вопрос безопасности пациента, непрерывности лечения, целостности клинических решений и устойчивости системы общественного здравоохранения. Министерство здравоохранения и социальных служб США прямо формулирует принцип: кибербезопасность — это безопасность пациентов. [1]
Статья на портале PRAVO.UA «Кибербезопасность в медицине: как защитить данные пациентов в эпоху цифровизации» акцентирует внимание на трёх базовых свойствах защищённой информации — конфиденциальности, целостности и доступности. Особую роль играют человеческий фактор, контроль доступа, обучение персонала и правовой режим медицинской информации. Для Украины эти тезисы подтверждаются Законом «О защите персональных данных», законодательством о защите информации и кибербезопасности, правилами Электронной системы здравоохранения ЭСОЗ и реформой национальной системы реагирования на киберинциденты 2025 года. [2]
Мировая практика показывает, что наиболее опасным последствием атаки на медицину часто является не кража файла как таковая, а потеря работоспособности системы. Кибератака вируса-вымогателя WannaCry в мае 2017 года привела к отмене тысяч приёмов в Национальной службе здравоохранения Великобритании. Атака на Службу здравоохранения Ирландии в 2021 году началась с фишингового письма и закончилась масштабным отключением систем.
Кибератака на компанию Change Healthcare в 2024 году нарушила потоки рецептов и платежей в значительной части американской системы здравоохранения. Атака на британскую лабораторию Synnovis привела к задержке более 11 000 амбулаторных приёмов и плановых процедур. [3]
Масштабы утечек также могут быть системными. Компания Anthem сообщила о почти 79 млн пострадавших; государственная медицинская сеть Сингапура SingHealth — о почти 1,5 млн; австралийская медицинская компания Medibank — о примерно 9,7 млн; Министерство здравоохранения и социальных служб США по состоянию на июль 2025 года зафиксировало около 192,7 млн человек, информация которых была затронута инцидентом с Change Healthcare. [4]
Регуляторная модель также меняется. В ЕС директива NIS2 (Директива ЕС о безопасности сетей и информационных систем) переводит кибербезопасность из «ИТ-функции» в сферу управленческой ответственности, требует управления рисками и многоступенчатого уведомления о значительных инцидентах. Общий регламент ЕС по защите данных (GDPR) отдельно регулирует нарушения безопасности персональных данных; регламент о Европейском пространстве данных здравоохранения (EHDS) добавляет новый уровень правил для электронных медицинских данных и систем электронных медицинских карт (EHR). [5]
В Великобритании Национальная служба здравоохранения (NHS) переходит к оценке через Инструментарий безопасности и защиты данных (DSPT), согласованный с Рамкой оценки киберзащиты (CAF) Национального центра кибербезопасности Великобритании (NCSC). [6]
США сочетают обязательные правила Закона о переносимости и подотчётности медицинского страхования (HIPAA) — Правило безопасности и Правило об уведомлении об утечках данных — с добровольными Целевыми показателями кибербезопасности для сектора здравоохранения и общественного здоровья (HPH CPGs). [7] Япония, Израиль, Австралия и Сингапур демонстрируют разные, но всё более схожие модели: секторальные правила, обязательное управление рисками, уведомление государственных органов, обучение персонала и повышенную ответственность руководства. [8]
Ключевой вывод для медицинского учреждения: невозможно выстроить достаточную киберустойчивость только антивирусом, центром операций безопасности (SOC) или политикой конфиденциальности. Необходима одновременная работа как минимум в шести плоскостях: управление, управление идентификацией и доступом, сегментация и резервирование, защита медицинских устройств и поставщиков, реагирование на инциденты / обеспечение непрерывности бизнеса и постоянное обучение людей.
Для Украины это особенно важно из-за двойного контекста: масштабной цифровизации медицинских услуг и ведения войны. CERT-UA в апреле 2026 года прямо сообщал о кластере киберугроз, среди целей которого были больницы. [9] Поэтому киберустойчивость медицинского учреждения следует рассматривать как составляющую клинической безопасности, гражданской устойчивости и национальной безопасности.
Что означает кибербезопасность в медицине и почему её риски особенные
Важно начать не с технологии, а с правового статуса медицинских данных: цифровая медицина работает с одной из наиболее чувствительных категорий информации о человеке, а значит, киберзащита должна обеспечивать реализацию права пациента на конфиденциальность. [10]
В практическом смысле кибербезопасность в медицине — это совокупность управленческих, правовых, организационных, технических, клинических и образовательных мер, обеспечивающих:
| Свойство | Что оно означает для медицины | Пример опасного нарушения |
|---|---|---|
| Конфиденциальность | Медицинскую информацию видят только уполномоченные лица | Публикация диагнозов, психиатрических или репродуктивных данных |
| Целостность | Записи, назначения, результаты исследований не были несанкционированно изменены | Изменение данных об аллергии, результата лаборатории, дозы препарата |
| Доступность | Данные и системы доступны врачу, когда нужны для оказания помощи | Программа-вымогатель блокирует электронную медицинскую карту, лабораторию или систему рецептов |
| Аутентичность | Система достоверно устанавливает, кто выполняет действие | Украденная учётная запись врача используется для доступа к электронной медицинской карте |
| Отслеживаемость | Можно установить, кто, когда и что просматривал или изменял | Отсутствие журналов делает невозможной цифровую экспертизу |
| Устойчивость | Медицинская помощь продолжается даже при потере части ИТ | Больница переходит на протестированные процедуры |
Именно доступность отличает медицину от многих других отраслей. В банке недоступность системы означает задержку платежа; в больнице она может означать невозможность быстро увидеть результаты анализа, выполнить диагностическое исследование, подтвердить группу крови, получить историю аллергий или надлежащим образом организовать операцию. Опыт Национальной службы здравоохранения Великобритании (NHS), Службы здравоохранения Ирландии (HSE), американской компании Change Healthcare (оператор обработки медицинских платежей и страховых требований) и британского поставщика лабораторных услуг Synnovis показывает, что кибератаки могут напрямую приводить к операционным нарушениям в оказании медицинской помощи. [11]
Медицинские данные имеют длинный жизненный цикл. Банковскую карту можно перевыпустить, но генетические характеристики, историю болезней, психиатрический диагноз или факт определённого лечения «заменить» невозможно. Именно поэтому европейский GDPR (Общий регламент ЕС по защите данных) относит данные о здоровье к специальным категориям персональных данных и устанавливает для их обработки повышенный правовой режим. [12]
Медицина имеет чрезвычайно широкий спектр уязвимостей. В типичной больнице одновременно работают различные медицинские информационные системы: электронная медицинская карта (EHR) и госпитальная информационная система (HIS), система архивирования медицинских изображений (PACS), специализированные системы, автоматизирующие работу лаборатории (LIS) и радиологии (RIS), аптечные системы, бухгалтерия, системы контроля доступа, электронная почта, виртуальная частная сеть (VPN), беспроводная сеть Wi-Fi, серверы, облачные сервисы, порталы пациентов, сотни или тысячи рабочих станций, а также подключённые к сети медицинские устройства. Из-за этого компрометация одного слабого компонента или подрядчика потенциально открывает путь к более критичным системам. Поэтому Министерство здравоохранения и социальных служб США (HHS) включает в свои Целевые показатели кибербезопасности в здравоохранении отдельные требования по многофакторной аутентификации, отделению привилегированных учётных записей, управлению уязвимостями, а также реагированию на риски и инциденты, связанные с третьими сторонами. [13]
Цепочка поставок является частью клинического риска. Change Healthcare и Synnovis показали, что компрометация одного сервисного узла может затрагивать большое количество независимых медицинских организаций. Change Healthcare обеспечивала критические транзакционные процессы между страховщиками, аптеками и поставщиками медицинских услуг, а Synnovis — лабораторные услуги для нескольких организаций NHS. [14]
Человеческий фактор остаётся критическим — фишинг, пароли, ошибочные действия работников и необходимость развития культуры кибербезопасности. Практика это подтверждает.
Риск для общественного здоровья отличается от риска конкретной больницы. Кибератака на реестры вакцинации, лабораторные сети, эпидемиологический надзор, системы уведомления об инфекционных заболеваниях или национальный обмен медицинскими данными может ухудшить качество данных, которыми государство пользуется для оценки угроз. Именно связь электронных данных о здоровье с вероятными угрозами здоровью и будущими пандемиями прямо заложена в логику Европейского пространства данных здравоохранения (EHDS). [17]
В Европе проблема носит системный характер. ENISA (Агентство Европейского союза по кибербезопасности), проанализировав 215 публично известных инцидентов в секторе здравоохранения за январь 2021 — март 2023 года, установило, что программы-вымогатели составляли 54% исследованных случаев; 53% инцидентов приходились на медицинских работников, а 42% — конкретно на больницы. [18] В более свежих материалах ENISA за 2024 год программы-вымогатели составляли примерно 45% инцидентов, связанных со здоровьем, а утечки данных — около 28%. [19]
Данные ENISA; показаны две крупнейшие категории, поэтому значения не следует трактовать как полное взаимоисключающее распределение всех видов инцидентов. [19]
Украинский контекст. Официальные материалы электронной системы здравоохранения ЭСОЗ описывают разделение персональных и медицинских данных, контролируемую аутентификацию и авторизацию, использование квалифицированной электронной подписи КЭП / двухфакторной аутентификации, ограничение доступа и комплексную систему защиты информации. Национальная служба здоровья Украины НСЗУ является владельцем центральной базы данных ЭСОЗ, а ГП «Электронное здоровье» обеспечивает её администрирование. [20]
После изменений 2025 года украинское законодательство дополнительно формализовало национальную систему реагирования на киберинциденты, систему обмена информацией и роль киберзащиты критической информационной инфраструктуры. [21] CERT-UA при Госспецсвязи принимает сообщения об инцидентах, проводит их расследование, помогает с ликвидацией последствий и координирует обмен информацией о киберугрозах. [9]
Это означает, что для украинской медицины модель «защитить базу пациентов» уже недостаточна. Необходимо одновременно защищать данные, процесс лечения, резервные процедуры и способность учреждения продолжать работу во время атаки.
Крупные медицинские киберинциденты: что фактически произошло и чему они научили
Наиболее ценным материалом для построения киберустойчивости является не перечень «страшных взломов», а анализ того, какие именно защитные барьеры не сработали и что произошло с клиническими процессами после компрометации.
Сводная хронология
| Инцидент | Масштаб | Метод / ключевая слабость | Последствия для медицины | Реакция регуляторов и восстановление |
|---|---|---|---|---|
| Anthem, США, 2015 г. | Почти 79 млн человек | Серия внешних кибератак. Особый акцент — на недостаточном управлении рисками и контроле | Одна из крупнейших утечек медицинских данных своего времени | В 2018 году Anthem согласилась на выплату $16 млн с планом корректирующих действий [22] |
| WannaCry, NHS Англии, 2017 г. | 80 из 236 больничных трастов были поражены/подверглись воздействию; ещё 603 учреждения первичной медицинской помощи и другие организации NHS были заражены | Программа-вымогатель использовала уязвимые системы Windows без обновлений; Национальное управление аудита Великобритании (NAO) указало, что установка обновлений и надлежащая настройка межсетевых экранов могли существенно уменьшить последствия | NHS зафиксировала 6 912 отменённых первичных приёмов и оценивала общее количество отменённых записей более чем в 19 000; в пяти местностях пациентам пришлось ехать дальше за неотложной помощью. | NAO и NHS провели масштабные проверки; подтверждённых фактов хищения данных пациентов не было. [23] |
| SingHealth, Сингапур, 2018 г. | Почти 1,5 млн пациентов; у 159 тыс. также похищены амбулаторные записи о приёме лекарств | Вероятный фишинг → скрытое перемещение по сети → компрометация учётных записей администраторов → доступ к базе через Citrix | Крупная утечка национального масштаба; отдельно целенаправленно запрашивались данные премьер-министра | Создана следственная комиссия; проведены устранение уязвимостей, отделение рабочих станций от интернета, масштабное информирование пациентов; комиссия выдала 16 системных рекомендаций. [24] |
| HSE, Ирландия, 2021 г. | Масштабная компрометация национальной службы здравоохранения; впоследствии около 90 тыс. человек были уведомлены о похищенной информации | Фишинговое письмо в марте → вредоносное программное обеспечение → программа-вымогатель Conti в мае | Отключение значительной части ИТ, ручные процессы | Выкуп не уплачен; HSE провела независимый анализ после инцидента, многолетнее криминалистическое исследование данных, усилила ИТ-защиту и обучение сотрудников. [25] |
| Medibank, Австралия, 2022 г. | Около 9,7 млн нынешних / бывших клиентов | По материалам Управления австралийского комиссара по информации (OAIC), учётные данные подрядчика попали в профиль его браузера; далее последовали несанкционированное проникновение, вывод данных и недостаточная эскалация оповещений | Опубликованы персональные данные и данные о претензиях по здоровью; риск кражи личных данных, вымогательства и психологического вреда | В 2024 году OAIC начало производство о взыскании гражданского штрафа в Федеральном суде; Федеральная полиция Австралии (AFP) и Австралийское управление радиотехнической разведки (ASD) вели уголовное расследование. [26] |
| Change Healthcare, США, 2024 г. | HHS впоследствии зафиксировало около 192,7 млн затронутых человек | Скомпрометированные учётные данные → удалённый доступ к порталу Citrix без многофакторной аутентификации → скрытое перемещение по сети → несанкционированный вывод данных → программа-вымогатель ALPHV/BlackCat | Нарушена обработка аптечных и медицинских страховых требований и платежей поставщикам; проблемы с денежным потоком у поставщиков медицинских услуг | Системы изолированы; инфраструктура в значительной мере перестроена с нуля; Управление по гражданским правам HHS (OCR) начало расследование; HHS и Центры услуг Medicare и Medicaid (CMS) ввели меры для поддержки непрерывности медицинской помощи. [27] |
| Synnovis, Великобритания, 2024 г. | Задержано более 11 000 амбулаторных / плановых приёмов | Программа-вымогатель + кража данных | Критически сократилась возможность выполнять лабораторные исследования | Данные были обнародованы преступниками; Synnovis привлекла правоохранительные органы, получила судебный запрет; услуги полностью восстановлены к декабрю 2024 года. [28] |
Anthem показала цену потери конфиденциальности. HHS OCR назвало инцидент крупнейшей на тот момент утечкой данных и в 2018 году заключило с Anthem соглашение на $16 млн, добавив масштабный план корректирующих действий. [22] Это важный прецедент: регулятор оценивает не только факт взлома, но и то, были ли надлежащими анализ рисков, управление доступом и меры контроля безопасности.
WannaCry показал цену технического долга. По выводам Национального управления аудита Великобритании, пострадавшие организации использовали системы Windows без установленных обновлений или системы, поддержка которых была прекращена; базовые меры по установке обновлений и управлению межсетевыми экранами могли предотвратить значительную часть заражений. При этом официальные органы не установили факта хищения данных пациентов — клинический риск возник прежде всего из-за недоступности систем. [23]
SingHealth показала опасность несвоевременной эскалации. Первичный доступ, вероятно, был получен ещё в августе 2017 года через фишинг. В дальнейшем нападающий месяцами перемещался по сети, компрометировал конечные устройства, серверы и учётные записи администраторов. ИТ-персонал замечал аномалии ещё в июне 2018 года, но высшее руководство и Агентство по кибербезопасности Сингапура (CSA) были проинформированы значительно позже. [29] Комиссия прямо связала проблему с недостаточной осведомлённостью в сфере кибербезопасности, нехваткой обучения и ресурсов, а также слабой эскалацией. [30]
HSE показала, насколько длительным может быть постинцидентный период. Фишинговое письмо было получено в марте 2021 года, программа-вымогатель активировалась в мае. Спустя годы после атаки HSE продолжала мониторинг и уведомление лиц, чьи документы были незаконно скопированы. [31] Реагирование на инциденты в медицине не заканчивается моментом «серверы снова работают»: далее продолжаются цифровая криминалистическая экспертиза, определение масштаба утечки данных, уведомление пациентов, судебные процессы, мониторинг, анализ извлечённых уроков и перестройка мер контроля.
Medibank показал риски цепочки поставок и защиты учётных данных. В материалах австралийского регулятора описана компрометация учётных данных, связанных с работником ИТ-подрядчика, и оповещения систем безопасности, которые не были надлежащим образом обработаны. Управление австралийского комиссара по информации (OAIC) утверждает, что Medibank не принял достаточных мер для защиты чувствительных данных 9,7 млн человек; дело было передано в Федеральный суд Австралии. [32]
Change Healthcare — возможно, наиболее наглядный урок в отношении многофакторной аутентификации. В показаниях генерального директора UnitedHealth Group перед Комитетом Сената США по финансам указано: злоумышленники использовали скомпрометированные учётные данные для входа на портал Citrix, на котором не было многофакторной аутентификации; после проникновения они перемещались по сети, эксфильтровали данные и спустя девять дней запустили программу-вымогатель. [33] Восстановление потребовало замены тысяч ноутбуков, смены учётных данных, перестройки сети центра обработки данных и ключевых сервисов. [34] К 26 апреля 2024 года UnitedHealth Group сообщала о более чем $6,5 млрд ускоренных выплат и беспроцентной помощи поставщикам медицинских услуг для поддержания их ликвидности. [35]
Synnovis показал системный риск аутсорсинга. Пострадала не отдельная больница, а поставщик лабораторных услуг. Следствие — падение лабораторных возможностей сразу в нескольких организациях Национальной службы здравоохранения Великобритании и более 11 тыс. отложенных приёмов и процедур. [36] Это аргумент в пользу того, чтобы план обеспечения непрерывности деятельности больницы включал не только собственный центр обработки данных, но и отказ критического внешнего поставщика.
Из этих кейсов вытекает принципиальная закономерность: катастрофический результат редко объясняется одним «гениальным хакерским приёмом». Чаще всего это цепочка обычных слабостей: фишинг → компрометация учётных данных → отсутствие многофакторной аутентификации → чрезмерные права → недостаточная сегментация → несвоевременная эскалация → резервная копия, которую не проверяли → отсутствие плана оказания медицинской помощи на время недоступности информационных систем.
Как организована кибербезопасность медицины в разных юрисдикциях
Для дополнительного сравнения, помимо ЕС, Великобритании, США, Японии и Израиля, выбраны Австралия и Сингапур. Австралия интересна сочетанием общего закона о защите частной жизни (Privacy Act), обязательного уведомления об утечках данных и режима защиты критической инфраструктуры; Сингапур — высоким уровнем цифровизации, централизованной киберполитикой и весьма конкретной финансовой поддержкой кибербезопасности в здравоохранении.
Европейский союз. Здесь одновременно действуют несколько уровней регулирования. GDPR защищает персональные данные, а данные о здоровье признаёт специальной категорией; статьи о безопасности обработки и уведомлении об утечках формируют уровень защиты частной жизни в кибербезопасности. В случае утечки персональных данных контролёр, как правило, уведомляет надзорный орган в течение 72 часов, если утечка может создать риск для прав и свобод лиц; при высоком риске может возникать обязанность уведомить и самих субъектов данных.
NIS2 охватывает сектор здравоохранения как сектор высокой критичности и требует мер по управлению рисками кибербезопасности. Для значительных инцидентов предусмотрена многоступенчатая модель: раннее предупреждение в течение 24 часов, уведомление об инциденте в течение 72 часов и итоговый отчёт, как правило, не позднее чем через месяц. Для существенных субъектов директива требует, чтобы максимальные административные штрафы в национальном законодательстве составляли не менее €10 млн или 2% мирового годового оборота. NIS2 применяется через национальные законы государств-членов, поэтому компетентные органы и процедурные детали различаются. [38]
Регламент 2025/327 о Европейском пространстве данных здравоохранения (EHDS) создаёт ещё один уровень: правила доступа граждан к электронным данным о здоровье, трансграничного использования через платформу MyHealth@EU, вторичного использования через органы доступа к данным о здоровье, а также требования к системам электронных медицинских карт (EHR). Регламент принят в 2025 году и вводится поэтапно, поэтому в 2026 году его правильнее воспринимать как разворачивающуюся трансформационную рамку, а не как одномоментно завершённую систему. [39]
ЕС также принял отдельный План действий по кибербезопасности больниц и учреждений здравоохранения. Европейская комиссия предусматривает специализированный центр поддержки, механизмы раннего предупреждения, обучение и возможность предоставления киберваучеров небольшим учреждениям здравоохранения. В июле 2026 года ENISA сообщило о трёхлетнем соглашении с Комиссией о взносе в размере €6 млн для поддержки реализации этого направления. [40] Более широкий Акт о киберсолидарности, вступивший в силу в 2025 году, создаёт Европейскую систему киберпредупреждения и Резерв ЕС по кибербезопасности для реагирования на крупные инциденты. [41]
Великобритания. В сфере здравоохранения Англии компетентным органом по Положениям о сетевых и информационных системах 2018 года (NIS Regulations) является Министерство здравоохранения и социального обеспечения (DHSC); официальное отраслевое руководство предусматривает обязанности по безопасности, отчётности об инцидентах и правоприменению с возможными штрафами до £17 млн. [42] Параллельно UK GDPR (британская версия Общего регламента по защите данных) требует уведомлять Управление уполномоченного по информации (ICO) об утечках данных, подлежащих уведомлению, как правило, в течение 72 часов, а при высоком риске — без неоправданной задержки уведомлять и пострадавших лиц. [43]
Особенно важна эволюция корпоративного управления в NHS. В руководстве 2026 года NHS England указывает, что организации, непосредственно оказывающие медицинскую помощь, должны проходить оценку по Инструментарию безопасности и защиты данных (DSPT), согласованному с Рамкой оценки киберзащиты (CAF) NCSC. Контроль со стороны правления и руководства должен охватывать управление киберрисками, защиту от атак и утечек данных, обнаружение угроз, минимизацию последствий, а также надлежащее использование данных и обмен ими. [6] Это смещает кибербезопасность от «ответственности ИТ-менеджера» к ответственности на уровне правления.
США. Правило безопасности HIPAA (американского закона о защите медицинской информации) требует от организаций, на которые распространяется HIPAA, и их деловых партнёров защищать электронную защищаемую медицинскую информацию (ePHI) с помощью административных, физических и технических мер и обеспечивать её конфиденциальность, целостность и доступность. [44]
Правило HIPAA об уведомлении об утечках данных использует иную модель сроков, чем GDPR. Об утечке, затрагивающей 500 или более человек, необходимо уведомить Министра здравоохранения и социальных служб без необоснованной задержки и не позднее чем через 60 календарных дней после её обнаружения; о меньших утечках допускается ежегодное сводное уведомление в установленный срок. Индивидуальные уведомления также должны направляться без необоснованной задержки и не позднее чем через 60 дней. [45]
Параллельно HHS разработало Целевые показатели кибербезопасности для сектора здравоохранения и общественного здоровья — добровольный отраслевой базовый уровень, построенный на практиках HICP (Практики кибербезопасности в здравоохранении), NIST (Национального института стандартов и технологий США) и CISA (Агентства по кибербезопасности и безопасности инфраструктуры США). Среди приоритетов: уязвимости систем, безопасность электронной почты, многофакторная аутентификация (MFA), шифрование, уникальные учётные данные, отделение привилегированных учётных записей, сегментация сети, планы реагирования на инциденты и риски третьих сторон. [13]
После инцидента с Change Healthcare федеральная дискуссия значительно усилилась, однако важно не смешивать действующие правила с предложениями реформ. Например, CISA в своих актуальных материалах по Закону об отчётности о киберинцидентах в критической инфраструктуре (CIRCIA) отмечало, что обязанности организаций, на которые он будет распространяться, начнут действовать лишь после вступления в силу окончательного правила; следовательно, предложенные CIRCIA сроки не следует автоматически трактовать как уже действующую универсальную обязанность каждой больницы. [46]
Япония. Главным регулятором в сфере защиты частной жизни является Комиссия по защите персональной информации (PPC), а базовым законом — Закон о защите персональной информации (APPI). [47] Министерство здравоохранения, труда и благосостояния (MHLW) располагает отдельной развитой системой руководств по кибербезопасности в здравоохранении. В 2026 году MHLW продолжало публиковать оповещения безопасности, чек-листы, руководства для медицинских информационных систем, учебные программы и поддерживать канал уведомления о киберинцидентах. Министерство прямо просит медицинские учреждения оперативно сообщать ему о кибератаках или подозрениях на них. [48]
Если происходит утечка или есть вероятность утечки персональных данных, в том числе данных о здоровье, возникает также обязанность отчитаться перед PPC. PPC требует оперативного первичного уведомления; если есть подозрение на злонамеренные действия, итоговый отчёт должен быть подан в течение 60 дней с момента обнаружения. Среди прямо приведённых PPC примеров событий, о которых следует уведомлять, — несанкционированный доступ и программы-вымогатели. [49]
Японская модель интересна ещё и финансированием: MHLW имеет отдельные программы оценки безопасности медицинских организаций, обучения и консультирования, а через правительственные механизмы поддержки малого и среднего бизнеса и ИТ может субсидировать внедрение определённых услуг по кибербезопасности. [50]
Израиль. Здесь защита данных о здоровье опирается на Закон о защите частной жизни и Положение о защите частной жизни (безопасность данных) 2017 года. Положение дифференцирует требования в зависимости от уровня безопасности базы данных и охватывает политику безопасности, инвентаризацию активов, оценку рисков, физическую защиту, контроль доступа, аутентификацию, журналирование, документирование инцидентов, аутсорсинг, резервные копии и аудиты. В случае серьёзного инцидента безопасности для соответствующих баз действует требование незамедлительно уведомить Регистратора баз данных. [51]
Поправка 13 к Закону о защите частной жизни вступила в силу 14 августа 2025 года и существенно расширила полномочия по правоприменению, финансовые санкции и обязанность назначать ответственного за защиту данных (DPO) для определённых категорий организаций; официальные израильские руководства прямо называют среди подобных субъектов больницы и больничные кассы. [52]
На уровне кибербезопасности государственную киберполитику координирует Национальный кибердиректорат Израиля (INCD); в 2025 году обнародована обновлённая Национальная стратегия кибербезопасности с трёхлетним горизонтом реализации. [53] В марте 2026 года Министерство здравоохранения дополнительно потребовало от медицинских организаций повысить уровень киберготовности, пересмотреть сервисы, доступные извне, и усилить мониторинг и управление рисками. [54]
Австралия. Закон о неприкосновенности частной жизни и схема обязательного уведомления об утечках данных (NDB) охватывают, в частности, частных поставщиков медицинских услуг. Если утечка вероятно причинит серьёзный вред, организация должна уведомить OAIC и пострадавших лиц; оценку предполагаемой утечки следует провести в течение 30 дней. [55]
Для критически важных больниц дополнительно применяется Закон о безопасности критической инфраструктуры (SOCI): о критическом киберинциденте со значительным влиянием на доступность необходимо уведомить Австралийское управление радиотехнической разведки / Австралийский центр кибербезопасности (ASD/ACSC) в течение 12 часов, а о другом киберинциденте с соответствующим влиянием — в течение 72 часов. [56]
Сингапур. Закон о защите персональных данных (PDPA) требует уведомлять Комиссию по защите персональных данных (PDPC) об утечке, подлежащей уведомлению, не позднее чем через три календарных дня после установления этого факта; лиц уведомляют, если утечка вероятно причинит им значительный вред. Значительной по масштабу считается, в частности, утечка, затрагивающая 500 или более человек. [58]
Закон о кибербезопасности охватывает критическую информационную инфраструктуру (CII), в частности сектор здравоохранения. [59] В 2026 году Агентство по кибербезопасности Сингапура (CSA) продолжило ужесточать Кодекс практики для CII — с большим акцентом на надзор со стороны совета директоров, рамку киберустойчивости, тестирование и поиск угроз. [60]
Министерство здравоохранения Сингапура (MOH) также обновило Базовые требования по кибербезопасности и безопасности данных для учреждений здравоохранения и организовало обучение и поддержку, ориентированные, в частности, на небольшие клиники. [61] Важно, что поддержка имеет и финансовое измерение: в 2026 году MOH сообщало о гранте NEHR Connect объёмом до $45 млн на четыре года; для малого и среднего бизнеса также предусмотрено софинансирование консультаций по кибербезопасности от сертифицированных CSA поставщиков и отдельные программы на межсетевые экраны и средства защиты от вредоносного программного обеспечения. [62]
Финансовая ответственность по PDPA тоже существенна: для организаций с годовым оборотом в Сингапуре свыше $10 млн максимальный финансовый штраф может достигать 10% соответствующего оборота; для меньших организаций действует альтернативный законодательный предел. [63]
Сравнительная таблица
Часть 1. Органы, правовая база и сроки уведомления
| Юрисдикция | Ключевые органы | Основные законы и стандарты | Уведомление об инцидентах и утечках |
|---|---|---|---|
| ЕС | ENISA, национальные органы по вопросам NIS и группы реагирования (CSIRT), органы защиты данных, органы здравоохранения | GDPR; NIS2; EHDS | NIS2: раннее предупреждение — 24 ч, уведомление — 72 ч, итоговый отчёт — ≈1 месяц; GDPR: утечка персональных данных — ≈72 ч |
| Великобритания | DHSC, NHS England, NCSC, ICO | Положения NIS; UK GDPR; DSPT / CAF NCSC | ICO — 72 ч для утечки данных, подлежащей уведомлению; отраслевые отчёты по NIS — по установленным порогам |
| США | HHS / OCR, ASPR, CISA, FBI, NIST | HIPAA: Правило безопасности и Правило уведомления об утечках; HICP; HPH CPGs; NIST CSF | ≥500 человек — HHS не позднее 60 дней; пострадавшим лицам — до 60 дней |
| Япония | PPC, MHLW, NCO / IPA / JPCERT | APPI; Руководства MHLW по безопасности медицинских информационных систем | Оперативное первичное уведомление; при злонамеренной утечке — итоговый отчёт до 60 дней; MHLW просит немедленно сообщать о киберинцидентах |
| Израиль | Орган защиты частной жизни, INCD, Министерство здравоохранения | Закон о защите частной жизни; Положение о безопасности данных; Поправка 13 | Серьёзный инцидент безопасности — немедленное уведомление регулятора в соответствующем режиме |
| Австралия | OAIC, ASD / ACSC, CISC | Закон о неприкосновенности частной жизни / схема NDB; Закон SOCI | NDB — пострадавшим лицам и OAIC; критические больницы: 12 ч — существенное влияние на доступность, 72 ч — прочие киберинциденты |
| Сингапур | PDPC, CSA, MOH | PDPA; Закон о кибербезопасности; Базовые требования MOH по кибербезопасности и безопасности данных | PDPC — до 3 календарных дней после установления того, что утечка подлежит уведомлению |
Часть 2. Санкции, стратегия, финансирование и обучение
| Юрисдикция | Потенциальные санкции | Стратегия и управление | Финансирование и поддержка | Обучение |
|---|---|---|---|---|
| ЕС | GDPR — до €20 млн / 4% оборота; NIS2 для существенных субъектов — национальные максимумы не менее €10 млн / 2% | План действий ЕС по кибербезопасности больниц; EHDS | Поддержка ENISA; взнос Еврокомиссии €6 млн; возможные киберваучеры; механизмы Акта о киберсолидарности | ENISA + национальные программы [64] |
| Великобритания | По NIS — до £17 млн; UK GDPR — отдельный режим правоприменения | Киберстратегия для здравоохранения и социальной помощи; контроль на уровне правления | Центральные киберпрограммы NHS + местные бюджеты | DSPT, руководства NCSC / NHS, учебные симуляции [65] |
| США | Гражданские штрафы и мировые соглашения по HIPAA; планы корректирующих действий | Отраслевое управление рисками HHS + экосистема CISA / NIST | Федеральные программы готовности и поддержки; бесплатные ресурсы HHS; поддержка после крупных инцидентов | HHS Cyber Gateway, HICP, обучение по CPG [66] |
| Япония | Регуляторные и уголовные механизмы APPI | Здравоохранение — сфера критической инфраструктуры | Оценка от MHLW; субсидии на ИТ и киберзащиту | Ролевые программы MHLW + служба поддержки по инцидентам [67] |
| Израиль | Усиленные денежные санкции с 2025 г. + уголовные положения | Национальная стратегия кибербезопасности 2025 | Национальные и отраслевые киберпрограммы | Рекомендации INCD / Минздрава, отраслевая готовность [68] |
| Австралия | До A$50 млн / 3× выгоды / 30% оборота — в зависимости от формулы | Рамка защиты критической инфраструктуры | Правительственные киберпрограммы; помощь ACSC | Руководства и учебные симуляции ACSC [69] |
| Сингапур | PDPA — до 10% оборота в Сингапуре для крупных организаций | Стратегия кибербезопасности 2026; управление критической информационной инфраструктурой (CII) | Грант NEHR Connect до S$45 млн на 4 года; поддержка малого и среднего бизнеса | Обучение MOH / CSA, шаблоны, консультирование [70] |
Сравнение показывает важную тенденцию: современные режимы больше не считают кибербезопасность сугубо технической проблемой. Во всех развитых моделях появляются четыре общих элемента: ответственность руководства, обязательное управление рисками, быстрое уведомление государства и проверяемая готовность к восстановлению. [71]
Практическая модель киберустойчивости медицинского учреждения
Качественная программа кибербезопасности должна начинаться не с закупки продукта, а с ответа на вопрос: какие клинические процессы не могут остановиться и от каких цифровых активов они зависят?
Типичная модель управления может выглядеть так:
Ключевой принцип: руководитель службы информационной безопасности (CISO) не может единолично отвечать за риск, который способен остановить операционную, лабораторию или отделение неотложной помощи. Владельцем такого риска должно быть руководство организации, а клиническое руководство должно участвовать в тестировании планов непрерывности деятельности и аварийного восстановления. Именно поэтому NHS в 2026 году подчёркивает контроль со стороны правления и руководства в отношении киберрисков и восстановления. [6]
Технический минимум. Первым приоритетом должна быть безопасность учётных записей: многофакторная аутентификация (MFA) для удалённого доступа, администраторов, облачных сервисов и электронной медицинской карты; отдельные привилегированные учётные записи; минимально необходимые права доступа; быстрое отключение учётных записей уволенных работников; отказ от общих учётных записей там, где это клинически возможно. Инцидент Change Healthcare — практически хрестоматийное подтверждение риска портала удалённого доступа без MFA. [33] HHS включает MFA, уникальные учётные данные и отделение привилегированных учётных записей в Целевые показатели кибербезопасности для сектора здравоохранения. [13]
Второй уровень — инвентаризация активов и управление уязвимостями. Медицинское учреждение должно знать не просто количество компьютеров, а владельца каждого критического актива, операционную систему, прошивку, версию программного обеспечения, доступность из интернета, статус поддержки поставщиком, клиническую критичность, способ резервного копирования и допустимое время простоя. Урок WannaCry состоит именно в том, что неподдерживаемые системы без обновлений превратили известную технологическую слабость в системную проблему здравоохранения. [23]
Третий — сегментация сети. Клинические системы, административная ИТ-инфраструктура, медицинский интернет вещей и операционные технологии, гостевая сеть Wi-Fi, инфраструктура резервного копирования и среда управления привилегированным доступом не должны составлять одну плоскую сеть. Это не гарантирует защиты от проникновения, но существенно затрудняет боковое перемещение по сети — этап, который был важным и в SingHealth, и в Change Healthcare. [72]
Четвёртый — резервное копирование как реальная способность, а не формальная отметка. Необходимы как минимум логически изолированные или неизменяемые копии критических данных, контроль доступа к системам резервного копирования и регулярный тест восстановления. Для электронной медицинской карты следует тестировать не только восстановление файла, но и сценарий: «Можем ли мы восстановить клиническую систему в пределах согласованного целевого времени восстановления (RTO) и целевой точки восстановления данных (RPO) и проверить целостность записей?»
Пятый — средства обнаружения и реагирования на конечных устройствах (EDR), система управления событиями безопасности (SIEM), журналирование и настройка обнаружения угроз. Журналы удалённого доступа, систем управления учётными записями, электронной медицинской карты, Active Directory, межсетевого экрана, VPN, облачных сервисов и действий привилегированных пользователей необходимо коррелировать. SingHealth демонстрирует, что отдельные технические специалисты могут видеть аномалии, но без корреляции и правильной модели эскалации организация не складывает их в единую картину атаки. [73]
Шестой — безопасность медицинских изделий. Для каждого подключённого к сети устройства необходимо знать поставщика, срок поддержки и завершения жизненного цикла, доступные обновления, сетевые зависимости, способ аутентификации, механизм удалённой поддержки и клинические последствия его недоступности. Если устройство невозможно обновить из-за сертификационных ограничений или ограничений поставщика, риск компенсируют сегментацией, списком разрешённых программ, мониторингом сети, ограниченным удалённым доступом и планом замены.
Седьмой — безопасность третьих сторон. Договор с лабораторией, облачным провайдером, поставщиком госпитальной или медицинской информационной системы, сервисом телемедицины или внешним центром операций безопасности (SOC) должен содержать не абстрактное «обеспечивает информационную безопасность», а конкретные требования: многофакторная аутентификация; шифрование; журналирование; уведомление об инцидентах; сотрудничество при криминалистическом расследовании; устранение уязвимостей; контроль субподрядчиков; резервное копирование; RTO/RPO; сохранение доказательств; право на аудит; безопасное удаление данных; план выхода из договора. Последствия инцидентов в Change Healthcare и Synnovis демонстрируют, что операционная зависимость должна рассматриваться как киберзависимость. [74]
Организационный минимум. Каждая критическая клиническая служба должна иметь письменный план работы на время простоя систем. Не «ИТ восстановит систему», а конкретно: как регистрируем нового пациента без госпитальной информационной системы; как проверяем историю приёма лекарств; как заказываем лабораторные исследования; как получаем результаты; как документируем введение препаратов; что происходит с медицинскими изображениями; как после восстановления переносим бумажные записи обратно в электронную медицинскую карту; как предотвращаем дублирование и ошибки переноса данных.
Юридический минимум. Медицинское учреждение должно иметь реестр данных и правовую карту: какие категории данных обрабатываются, кто является владельцем или распорядителем данных либо соответствующим субъектом по национальному праву, какие третьи стороны имеют доступ, на каком правовом основании, где физически и в какой юрисдикции хранятся данные, какие сроки хранения, какие требования к уведомлению об утечках и кто вправе принять решение об уведомлении регулятора и пациентов.
Для Украины важно связать это с режимом ЭСОЗ, Законом «О защите персональных данных», правилами врачебной тайны, законодательством об информационно-коммуникационных системах и новой системой реагирования на киберинциденты. [75]
Учебный минимум. Ежегодного курса по кибергигиене самого по себе недостаточно. Рекомендуется разделить обучение по ролям:
| Группа | Что необходимо отрабатывать |
|---|---|
| Все работники | Распознавание фишинга, кражи учётных данных и подозрительных запросов многофакторной аутентификации; обращение с данными пациентов; быстрое уведомление об инцидентах |
| Врачи / медсёстры | Процедуры работы во время простоя систем, безопасный доступ к электронной медицинской карте, портативные устройства, аварийные рабочие процессы |
| ИТ-специалисты | Защита конфигураций, установка обновлений, резервное копирование, сегментация, журналы, средства EDR, цифровая криминалистика |
| Системные администраторы | Управление привилегированным доступом (PAM), привилегированные учётные записи, процедуры аварийного доступа |
| Руководство | Принятие решений во время атаки программы-вымогателя, коммуникации, юридические риски, приоритизация услуг |
| Юристы / ответственный за защиту данных | Оценка утечки, уведомление регулятора и пациентов, сохранение доказательств |
| Отдел закупок | Требования к безопасности третьих сторон в договорах, соглашение об уровне обслуживания (SLA), уведомление об инцидентах, условия выхода из договора |
Такой ролевой подход соответствует направлениям, которые развивают HHS, NHS и MHLW. [76]
План действий после киберинцидента
Первые часы после атаки — это момент, когда неверное решение может увеличить и клинический, и юридический ущерб. План реагирования на инциденты медицинского учреждения должен быть заранее утверждён, протестирован и согласован с планом непрерывности деятельности.
| Временной горизонт | Основные действия |
|---|---|
| Первые минуты | Назначить руководителя реагирования на инцидент; подтвердить влияние на клинические процессы; изолировать скомпрометированные активы; не уничтожать доказательства; там, где необходимо, перейти на процедуры работы во время простоя |
| До нескольких часов | Привлечь ИТ-специалистов и службу безопасности, клиническое руководство, юристов и ответственного за защиту данных, руководство, службу коммуникаций; определить вектор атаки; заблокировать скомпрометированные учётные данные; собрать нестойкие цифровые доказательства и журналы |
| Первые 24 часа | Определить масштаб инцидента, объём раскрытых данных, пострадавшие системы и критические услуги; проверить резервные копии; уведомить CERT/CSIRT и регуляторов, если возникла такая обязанность; организовать альтернативные клинические процессы |
| 24–72 часа | Продолжить локализацию и устранение угрозы; провести юридическую оценку утечки; направить обязательные уведомления; подготовить проверенное публичное заявление; начать контролируемое восстановление |
| Последующие дни | Восстанавливать приоритетные системы в чистой среде; сменить учётные данные и ключи; усилить мониторинг; проверить целостность данных; работать с пациентами, поставщиками и правоохранительными органами |
| После стабилизации | Провести независимый анализ после инцидента и анализ первопричин; устранить недостатки мер контроля; подготовить отчёт для руководства; обновить реестр рисков; повторить настольное учение |
Опыт ЕС по NIS2 особенно хорошо показывает, почему нельзя ждать «полной криминалистической картины» перед началом отчётности: система предусматривает раннее предупреждение в течение 24 часов, затем уведомление в течение 72 часов и лишь позже — итоговый отчёт. [77] Аналогичная логика существует в Австралии для критической инфраструктуры: 12 часов для наиболее серьёзных инцидентов, влияющих на доступность. [56]
Для Украины взаимодействие с CERT-UA следует заложить в план заранее. Команда официально принимает сообщения, проводит расследование и оказывает помощь в устранении последствий. [9]
Чего не следует делать во время атаки программы-вымогателя: хаотично выключать всё оборудование без координации; удалять журналы; самостоятельно связываться со злоумышленниками с личных учётных записей; публично называть причину или масштаб до подтверждения криминалистической экспертизой; восстанавливать системы в скомпрометированной сети; подключать резервные копии к среде, где закрепление злоумышленника ещё не ликвидировано; рассматривать выплату выкупа как замену восстановлению.
Случаи HSE и Change Healthcare показывают два разных решения относительно выкупа: HSE не платила выкуп, а генеральный директор UnitedHealth Group подтвердил, что лично принял решение об оплате в Change Healthcare. [78] Из этого не следует универсального правила «никогда» или «всегда» платить. Решение зависит от позиции правоохранительных органов, санкционного режима, клинических последствий, возможности восстановления, страхования и юридической оценки. Но получение требования о выкупе не должно быть первым моментом, когда руководство обсуждает эту политику.
Краткие шаблоны политик и процедур
Шаблон политики управления доступом
Цель: обеспечить доступ к медицинской информации исключительно в соответствии с должностными и клиническими полномочиями.
Правило: все пользователи имеют персональные учётные записи. Многофакторная аутентификация (MFA) обязательна для удалённого доступа, привилегированных учётных записей и других определённых критических систем. Права предоставляются по принципам минимально необходимых прав доступа и ролевого доступа.
Пересмотр: права пересматриваются после смены должности и периодически; после прекращения трудовых/договорных отношений доступ отзывается немедленно.
Аварийный доступ: доступ в обход обычных правил («разбитие стекла») разрешается только при клинической необходимости, автоматически журналируется и подлежит последующей проверке.
Подход соответствует Целевым показателям кибербезопасности HHS (CPGs) и принципам контролируемого доступа, применяемым в ЭСОЗ. [79]
Шаблон процедуры уведомления о подозрительном инциденте
Любой работник, заметивший необычный вход в систему, фишинг, сообщение программы-вымогателя, несанкционированный доступ, утерю устройства или аномальное поведение клинической системы, не проводит самостоятельного расследования, а немедленно сообщает в службу поддержки или центр операций безопасности (SOC) через определённый канал.
Сообщение должно содержать: время, систему/устройство, краткое описание, снимок экрана (по возможности), действия пользователя перед событием.
Команда реагирования на инциденты определяет уровень серьёзности, влияние на клинические процессы и необходимость эскалации к руководству, ответственному за защиту данных, юристам, CERT или регулятору.
Проблема несвоевременной эскалации является одним из центральных уроков SingHealth. [73]
Шаблон договорного положения о безопасности третьих сторон
Поставщик применяет многофакторную аутентификацию для удалённого и привилегированного доступа, ведёт журналирование событий безопасности, поддерживает процесс управления уязвимостями, шифрует чувствительные данные при передаче и хранении, поддерживает протестированную способность резервного копирования и восстановления и уведомляет заказчика о подтверждённом или обоснованно предполагаемом инциденте безопасности не позднее X часов после его обнаружения.
Поставщик сохраняет цифровые доказательства, содействует расследованию инцидента, сообщает о привлечённых субподрядчиках и не меняет место или юрисдикцию обработки данных о здоровье без предусмотренной договором процедуры.
Срок в договоре целесообразно устанавливать более коротким, чем внешний регуляторный срок, иначе учреждение здравоохранения может физически не успеть исполнить собственную обязанность по уведомлению.
Шаблон политики резервного копирования и восстановления
Для каждой критической клинической системы устанавливаются целевое время восстановления (RTO) и целевая точка восстановления данных (RPO).
Как минимум одна резервная копия должна быть защищена от изменения или удаления с использованием рабочих учётных данных.
Тест восстановления выполняется по утверждённому графику.
Результаты теста восстановления документируются и докладываются владельцу системы.
Резервная копия считается пригодной только после подтверждённого восстановления и проверки целостности.
Шаблон процедуры работы во время простоя из-за атаки программы-вымогателя
В случае потери доступа к электронной медицинской карте ответственный клинический руководитель объявляет переход в режим работы во время простоя.
Используются заранее подготовленные бумажные/локальные формы для идентификации пациентов, введения лекарств, лабораторных заказов, медицинских изображений и клинических записей.
После восстановления данные переносятся в электронную медицинскую карту по процедуре двойного контроля, чтобы минимизировать дублирование и ошибки переноса.
Восстановление ИТ-систем и восстановление клинических процессов являются отдельными потоками работ, которые синхронизирует руководитель реагирования на инцидент.
Чек-лист готовности медицинского учреждения и стратегические выводы
Ниже — практический инструмент самооценки. Ответ «нет» не означает автоматически критического провала, но совокупность ответов «нет» в одной категории указывает на системный риск.
| Контрольный вопрос | Да / Частично / Нет |
|---|---|
| Руководитель учреждения / правление регулярно получает отчёт о киберрисках? | ☐ |
| Определены ответственные за информационную безопасность (CISO) и за защиту персональных данных (DPO)? | ☐ |
| Есть актуальный реестр всех критических ИТ-активов и медицинских изделий? | ☐ |
| Для каждой критической клинической службы определены её зависимости от ИТ? | ☐ |
| Многофакторная аутентификация (MFA) включена для VPN, удалённого доступа, облачных сервисов и привилегированных учётных записей? | ☐ |
| Администраторы используют отдельные привилегированные учётные записи? | ☐ |
| Общие учётные записи устранены или жёстко контролируются? | ☐ |
| Есть процедура отзыва доступа сразу после увольнения или смены должности? | ☐ |
| Ресурсы, доступные из интернета, регулярно сканируются на уязвимости? | ☐ |
| Для критических обновлений определён гарантированный срок установки? | ☐ |
| Неподдерживаемые системы известны и имеют план замены или сегментации? | ☐ |
| Клиническая, административная, гостевая сети, сеть медицинских изделий и сеть резервного копирования сегментированы? | ☐ |
| Средства EDR или аналогичный мониторинг конечных устройств охватывают критические серверы и ПК? | ☐ |
| Централизованное журналирование охватывает учётные записи, VPN, Active Directory, электронную медицинскую карту, межсетевой экран и облачные сервисы? | ☐ |
| Журналы защищены от удаления обычной учётной записью администратора? | ☐ |
| Есть изолированные или неизменяемые резервные копии критических систем? | ☐ |
| Реальный тест восстановления проводился в течение последних 12 месяцев? | ☐ |
| Для электронной медицинской карты, лабораторной, радиологической и госпитальной информационных систем определены и протестированы RTO/RPO? | ☐ |
| Отделение неотложной помощи может работать без электронной медицинской карты? | ☐ |
| Лаборатория имеет процедуру работы без лабораторной информационной системы? | ☐ |
| Есть бумажный / офлайн-процесс назначения и введения лекарств? | ☐ |
| Есть план сверки бумажных записей после восстановления систем? | ☐ |
| Критические поставщики обязаны быстро уведомлять об инцидентах? | ☐ |
| Договоры содержат требования по безопасности, резервному копированию, аудиту, криминалистическому расследованию и выходу из договора? | ☐ |
| Известны все субподрядчики и места хранения данных пациентов в облаке? | ☐ |
| План реагирования на инциденты обновлялся в течение года? | ☐ |
| Есть актуальные контакты CERT/CSIRT, регулятора, правоохранительных органов и страховщика? | ☐ |
| В течение года проводилось обучение по действиям при атаке программы-вымогателя? | ☐ |
| К обучению привлекали директора, клиническое руководство, юристов и службу коммуникаций? | ☐ |
| Персонал регулярно проходит обучение по фишингу и кибербезопасности? | ☐ |
| Работники знают один простой канал, куда сообщать об инциденте? | ☐ |
| Есть юридическая матрица сроков уведомления об утечках и киберинцидентах? | ☐ |
| Есть утверждённый шаблон уведомления пациентов? | ☐ |
| Есть отдельная политика принятия решений по выкупу и вымогательству? | ☐ |
| После инцидентов и ситуаций «на грани» проводится анализ извлечённых уроков? | ☐ |
Практически результат можно оценивать так: 90–100% «Да» — зрелая программа, которая всё же требует постоянного тестирования; 70–89% — приемлемая база с конкретными пробелами; 50–69% — существенная операционная уязвимость; менее 50% — приоритетом должно стать не приобретение новой технологической платформы, а формирование базового управления и способности к восстановлению. Это не регуляторная шкала, а управленческий инструмент для внутреннего анализа пробелов.
Для украинского учреждения первые инвестиции целесообразно распределить в следующем порядке: безопасность учётных записей и MFA → инвентаризация активов → резервное копирование и восстановление → управление обновлениями и уязвимостями → сегментация сети → журналирование и обнаружение угроз → реагирование на инциденты → клинические процедуры на время простоя → безопасность поставщиков → расширенные возможности центра операций безопасности (SOC). Такой порядок соответствует характеру слабостей, которые фактически проявились в WannaCry, SingHealth, HSE, Medibank и Change Healthcare. [80]
Для небольшой больницы это не означает необходимости создавать крупный собственный SOC. Часть функций можно приобретать как управляемую услугу, но риск и ответственность нельзя передать на аутсорсинг. Руководство всё равно должно знать, какие данные и системы критичны, кто может прекратить доступ злоумышленника, кто восстановит электронную медицинскую карту, сколько времени это займёт и как врачи будут работать до восстановления.
Для государственной системы здравоохранения нужен ещё один уровень: отраслевая разведка угроз, единые базовые меры защиты, сертифицированные и проверенные провайдеры, централизованная отчётность, финансирование киберзащиты малых больниц, совместные учения между учреждениями, резервные механизмы для лабораторий и электронной системы здравоохранения, а также национальная координация реагирования на инциденты. Именно в этом направлении движутся ЕС, NHS, Япония и Сингапур. [81]
Для Украины особенно перспективной была бы модель, в которой минимальный базовый уровень кибербезопасности для медицинских учреждений связан не только с защитой персональных данных, но и со способностью оказывать помощь в случае отказа цифровых систем. Фактически это означает сближение трёх традиционно отдельных дисциплин:
кибербезопасность + безопасность пациентов + непрерывность деятельности = киберустойчивость здравоохранения.
Именно это является главным уроком последнего десятилетия. Наиболее зрелые системы уже не задают вопрос: «Будет ли наша больница атакована?» Они планируют, как не допустить распространения атаки, как продолжать лечить пациентов во время инцидента и как восстановиться без потери доверия и целостности медицинских данных.
Для Украины этот подход дополнительно усиливается военным риском. CERT-UA в 2026 году уже фиксировал кампании, среди целей которых были больницы, тогда как цифровая медицина всё больше опирается на ЭСОЗ и взаимосвязанные информационные системы. [82] Следовательно, киберустойчивость медицинской системы должна рассматриваться на одном уровне с энергетической, коммуникационной и иной критической устойчивостью.
Наши проекты
Ветеранские проекты
- veterano.info — информационный проект для ветеранов и их семей от Ветеранского кластера Украины и Института ветеранов.
- veterano.media — медиа Ветеранского кластера Украины: новости, истории и практическая навигация для ветеранов и семей.
- veterano.army — кадровое агентство для бизнеса: подбираем трудоспособных ветеранов под потребности бизнеса — производство, склад, логистика, офис.
- veterano.bio — цифровое подтверждение ветеранского статуса и перевод документов: защищённый профиль, многоязычная справка.
- veterano.digital — «Единое окно» — цифровая приёмная для ветерана в образовании: обращение любым удобным способом, персональный образовательный маршрут.
Проекты-партнёры экосистемы
- Агентство восстановления Украины — ассоциация, объединяющая усилия государства, бизнеса и громад вокруг послевоенного восстановления и развития Украины.
- Национальный институт регионального развития — объединяет науку, образование, бизнес и государство, чтобы ускорить развитие регионов.
- НИИАЦ «Инновации, инвестиции, интеллект» — научно-исследовательский информационно-аналитический центр, г. Киев.
- Благотворительный фонд «Реконструкции и развития Украины» — мобильные госпитали для ВСУ.
- AGGR World / ITTA — новости экономики, обороны, бизнеса и общества.
Готовые разработки SmartGT
- Smart CMS — бесплатная и безопасная CMS со встроенным ИИ для контента, плагинами под ваши задачи и удобным блочным редактором.
- Smart LMS — обучающие платформы под ключ: курсы, тесты, задания, сертификаты и продажа доступа; каждая школа со своим доменом и брендом, все — из одной панели.
- BOT-panel — управление Telegram-ботами с AI в одной панели: рассылки, контакты, табелирование, согласование документов, оценка качества общения.
- Smart Audit — бесплатная проверка сайта за 3 минуты: безопасность, поисковая видимость, скорость, готовность к AI-агентам; без регистрации.
- Smart 360 — ERP и CRM для бизнеса: клиенты и сделки в воронке, номенклатура и прайсы, склад, документы и договоры в одной системе.
- Smart Window — единое окно руководителя — как устроен кабинет и что в нём видно.
Источники
Украина
- Ольга Данченко. «Кибербезопасность в медицине: как защитить данные пациентов в эпоху цифровизации», PRAVO.UA, 16 сентября 2026 года. [15]
- Верховная Рада Украины. Закон Украины «О защите персональных данных», действующая редакция. [83]
- Верховная Рада Украины. Закон №4336-IX от 27 марта 2025 года о защите информации и киберзащите государственных информационных ресурсов и критической информационной инфраструктуры. [21]
- ЭСОЗ / ГП «Электронное здоровье». Официальные материалы о защите персональных и медицинских данных в центральной базе ЭСОЗ. [20]
- CERT-UA [9]
Европейский союз
- European Union. Directive 2022/2555 — NIS2 Directive. [77]
- European Union. Regulation 2016/679 — General Data Protection Regulation. [12]
- European Union. Regulation 2025/327 — European Health Data Space. [39]
- ENISA. Checking-up on Health: Ransomware Accounts for 54% of Cybersecurity Threats, 2023. [18]
- ENISA. [19]
- European Commission. Cybersecurity in healthcare, 2026. [84]
- ENISA, 2026. [85]
- European Commission / EU. Cyber Solidarity Act и European Cybersecurity Reserve. [41]
Великобритания
- National Audit Office. Investigation: WannaCry cyber attack and the NHS, 2017. [23]
- NHS England. Board and executive assurance: cyber security risk, 2026. [6]
- UK Department of Health and Social Care. The Network and Information Systems Regulations 2018: guide for the health sector in England. [42]
- Information Commissioner’s Office. Guidance on personal data breach reporting under UK GDPR. [43]
- NHS England. Synnovis cyber incident. [28]
- ICO. Statement concerning the Synnovis cyber attack. [86]
США
- U.S. HHS Office for Civil Rights. HIPAA Security Rule materials. [44]
- U.S. HHS. HIPAA Breach Notification Rule, 2026 reporting instructions. [45]
- HHS Cyber Gateway. Healthcare and Public Health Cybersecurity Performance Goals. [87]
- HHS OCR. Anthem pays OCR $16 Million in record HIPAA settlement following largest health data breach in history, 2018. [22]
- HHS OCR. Change Healthcare Cybersecurity Incident Frequently Asked Questions. [88]
- Andrew Witty / UnitedHealth Group. Testimony before the U.S. Senate Finance Committee: Change Healthcare cyberattack. [89]
- UnitedHealth Group. Updates restoration Change Healthcare. [90]
- U.S. Department of Justice. ALPHV/BlackCat ransomware operations. [91]
Ирландия
- Health Service Executive. Conti cyber attack on the HSE — Independent Post Incident Review. [92]
- HSE. [31]
Япония
- Personal Information Protection Commission of Japan. APPI — laws and policies. [47]
- PPC Japan. Reporting personal-data leaks, unauthorized access ransomware. [49]
- Ministry of Health, Labour and Welfare. Portal cybersecurity measures for medical institutions, guidance, checklists, training, reporting, procedures. [48]
- MHLW. Cybersecurity support and assessment programme for medical institutions. [93]
Израиль
- Israel Privacy Protection Authority. Guidance on Privacy Protection Regulations (Data Security) 2017. [51]
- Israel Privacy Protection Authority. Amendment 13 to the Privacy Protection Law, effective from August 2025, updated guidance, 2026. [52]
- Israel National Cyber Directorate. National Cybersecurity Strategy 2025. [53]
- Israel Ministry of Health. Cybersecurity directions to health organisations, 2026. [54]
Австралия
- Office of the Australian Information Commissioner. Notifiable Data Breaches scheme guidance. [55]
- OAIC. OAIC takes civil penalty action against Medibank, 2024. [94]
- OAIC. Regulatory guidance on current maximum Privacy Act civil penalties. [57]
- Australian Cyber Security Centre / cyber.gov.au. Mandatory reporting under the Security of Critical Infrastructure Act, including critical hospital assets. [56]
- Australian Federal Police. Official investigation materials concerning the Medibank attack. [95]
Сингапур
- Personal Data Protection Commission. Data breach notification requirements. [58]
- PDPC. Updated PDPA enforcement regime and financial penalty limits. [63]
- Cyber Security Agency of Singapore. Cybersecurity Act and Critical Information Infrastructure requirements. [96]
- Singapore Ministry of Health. Healthcare Cyber Security and Data Security Essentials, training and support measures, 2026. [61]
- Singapore Ministry of Health. Funding measures including NEHR Connect Grant and cybersecurity support for providers, 2026. [62]
- Committee of Inquiry into the Cyber Attack on Singapore Health Services Patient Database. Official public report, 10 January 2019. [97]