Моделирование угроз телемедицинской платформы

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Моделирование угроз – это взгляд на телемедицинский продукт глазами атакующего ещё до запуска: слабые места находят и закрывают, пока это дёшево. Работа отвечает на три вопроса по порядку: что стоит красть, как до этого можно добраться и как закрыть каждый путь. Для телемед-проекта в России это обязательная работа: определение угроз – первая мера защиты персональных данных в ст. 19 152-ФЗ, а модель угроз – документ, из которого следуют тип актуальных угроз и уровень защищённости по ПП 1119, уточнённый набор мер по приказу ФСТЭК № 21 и решение о том, где нужны сертифицированные средства криптографической защиты информации (СКЗИ). В статье – повторяемый инженерный метод (STRIDE), его связь с методикой ФСТЭК 2021 года, поверхность атаки, характерная для телемедицины, и рабочий лист, который можно заполнить уже на этой неделе.

Зачем это читать

Если вы строите или покупаете телемед-платформу, вы отвечаете за самые чувствительные данные человека – сведения о его здоровье, которые 152-ФЗ относит к специальной категории персональных данных, а 323-ФЗ – к врачебной тайне. Цена ошибки задана законом: утечка таких данных стоит юрлицу 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), повторная – до 500 млн ₽, а здравоохранение относится к сферам критической информационной инфраструктуры. Моделирование угроз – самая дешёвая работа по безопасности: одна сессия у доски избавляет от переделки архитектуры. Статья написана для основателей, продакт-менеджеров и техлидов, которым нужно провести такую сессию, говорить на одном языке со специалистами по защите информации и понимать, какие угрозы в телемедицине реальны.

Что такое моделирование угроз

Моделирование угроз – это структурированный разговор о том, как можно атаковать вашу систему. Вы рисуете, как данные движутся через продукт, а затем идёте по этой схеме и на каждом шаге спрашиваете: «что здесь может пойти не так?». Результат – список угроз, упорядоченный по приоритету, и решение по каждой: снизить риск, передать, принять или избежать.

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

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

В здравоохранении важно ещё одно различие. Большинство текстов о безопасности посвящены угрозам безопасности – кто-то взламывает систему. У телемедицины есть и угрозы приватности: данные технически защищены, но собраны с избытком, переданы лишним сторонам или их можно связать с пациентом, который рассчитывал на конфиденциальность. В России это особенно важно, потому что врачебную тайну составляет уже сам факт обращения за медицинской помощью (ст. 13 323-ФЗ). Если приложение отправляет в стороннюю аналитику событие «пользователь открыл страницу психиатра», это проблема, даже если каждый байт зашифрован. Хорошая модель угроз в телемедицине учитывает оба класса.

Почему телемед-команде без этого не обойтись

В России моделирование угроз из полезной практики превращается в обязанность. Статья 19 152-ФЗ перечисляет, чем обеспечивается безопасность персональных данных, и первым пунктом ч. 2 стоит «определение угроз безопасности персональных данных при их обработке в информационных системах персональных данных». Документ, в котором фиксируется это определение, называется моделью угроз. Без него нечем обосновать ни уровень защищённости, ни состав мер, ни отказ от СКЗИ на каком-то участке, а значит, нечем защищаться ни на проверке, ни при разборе инцидента.

Модель угроз – исходные данные для трёх решений, которых требует регулирование. Тип актуальных угроз. ПП 1119 различает три типа: угрозы 1-го типа связаны с недокументированными (недекларированными) возможностями системного ПО, 2-го – прикладного ПО, 3-го с такими возможностями не связаны; тип определяет оператор с учётом оценки возможного вреда (п. 6–7). Уровень защищённости. Тип угроз, категория данных и число субъектов, чьи данные обрабатываются, дают уровень от УЗ-1 до УЗ-4 (п. 8–12). Состав мер. Приказ ФСТЭК № 21 задаёт для каждого уровня базовый набор мер; оператор адаптирует его под свою систему, затем уточняет так, чтобы нейтрализовать все актуальные угрозы, и дополняет требованиями других актов (п. 9). Без модели угроз этап уточнения выполнить просто не на чем.

Пример для медданных, то есть специальной категории. Платформа на 60 000 пациентов, актуальны угрозы 3-го типа: специальная категория и менее 100 000 человек, не являющихся сотрудниками оператора, дают УЗ-3 (п. 11 ПП 1119). Платформа выросла до 150 000 пациентов: порог 100 000 пройден, получается УЗ-2 (п. 10), и добавляются требования, например доступ к содержанию электронного журнала сообщений только для должностных лиц, которым он нужен по работе (п. 15). Если же модель признала актуальными угрозы 2-го типа, та же база в 150 000 человек даёт уже УЗ-1 (п. 9). Один абзац модели угроз сдвигает весь проект на уровень вверх или вниз.

Четвёртое решение касается криптографии. Если по модели какие-то угрозы (например, перехват в канале за пределами контролируемой зоны) нейтрализуются шифрованием, шифровать должны СКЗИ, прошедшие оценку соответствия. Для каждого уровня защищённости приказ ФСБ № 378 предусматривает СКЗИ соответствующего класса. Браузерный WebRTC шифрует медиа не по ГОСТ, поэтому решение о том, где нужны СКЗИ, а где угроза закрыта иначе, принимается и обосновывается в модели угроз. Подробно – в статьях о шифровании, ГОСТ и СКЗИ и о сквозном шифровании.

Формальную модель составляют по «Методике оценки угроз безопасности информации», утверждённой ФСТЭК России 5 февраля 2021 года; методика 2008 года для персональных данных больше не применяется (п. 1.8). Оценка идёт в три этапа: негативные последствия → объекты воздействия → возможность реализации угроз и их актуальность через нарушителей, способы реализации и сценарии (п. 2.15). Перечень угроз берут из банка данных угроз ФСТЭК, bdu.fstec.ru (п. 2.3); угрозы самим средствам криптозащиты методика не рассматривает (п. 1.4) – это предмет документов ФСБ. Методика задаёт структуру и язык документа, а STRIDE и диаграмма потоков данных – инженерный способ наполнить его содержанием для вашей архитектуры. Без инженерной проработки модель превращается в переписанный каталог угроз, не связанный с вашим видеостеком.

Требования при этом ужесточаются. С 1 марта 2026 года для ГИС и систем госучреждений, включая медицинские информационные системы (МИС) госбольниц, действует приказ ФСТЭК № 117 с риск-ориентированным выбором мер. Для коммерческих систем в июле 2026 года опубликован проект замены приказа № 21 с оценкой защищённости после каждого инцидента; на 24 сентября 2026 года он не подписан. Выполняйте действующий приказ № 21, но учитывайте, куда движется регулирование, – подробности в статье о требованиях к защите ПДн в 2026 году.

Шаг 1. Опишите систему: нарисуйте диаграмму потоков данных

Нельзя защитить систему, которую вы не видите. Первый шаг – диаграмма потоков данных (data flow diagram, DFD): простая схема того, как данные пациента проходят через продукт. В ней всего четыре вида элементов. Внешние сущности – люди и внешние системы, которые взаимодействуют с платформой: пациент, врач, МИС клиники, с которой вы интегрируетесь. Процессы – части вашей системы, которые что-то делают: сервер сигналинга, API, медиасервер. Хранилища данных – места, где данные хранятся: база пациентов, бакет записей, журнал событий. Потоки данных – стрелки между ними; у каждой подписано, что передаётся и как это защищено.

Затем проведите самую важную линию – границу доверия (trust boundary). Она отделяет то, что вы контролируете и защищаете, от всего остального. В телемедицине граница доверия почти совпадает с границей медданных: всё внутри должно быть либо построено и размещено вами, либо находиться у лица, обрабатывающего данные по поручению оператора, – с договором-поручением по ст. 6 152-ФЗ и базами данных в России (ч. 5 ст. 18). Каждая стрелка, пересекающая границу, – место, где может вклиниться атакующий. Отметьте их: именно там окажется большинство угроз, а прямоугольники диаграммы станут объектами воздействия в терминах методики. Как провести такую границу для всего видеостека, разобрано в статье об архитектуре соответствия 152-ФЗ и 323-ФЗ.

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

Поверхность атаки телемедицины: что можно украсть и как до этого добраться

Прежде чем искать угрозы, определите, что ценно для атакующего. В телемед-платформе это три вещи: медданные (карты, паспортные данные, СНИЛС, полисы ОМС и ДМС – их можно сразу продать или использовать для мошенничества), записи и транскрипты клинических сессий (особо чувствительные, особенно в психиатрии и психотерапии) и учётные данные (логин врача открывает доступ к данным многих пациентов). Зная, что ценно, проще понять, какие пути атаки опаснее всего.

Поверхность атаки – совокупность всех таких путей: каждое место, где данные поступают в систему, хранятся или покидают её. У платформы клинического видео шесть таких зон.

Нажмите, чтобы увеличить

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

Живой звонок (WebRTC). Аудио и видео в реальном времени. WebRTC шифрует сам медиапоток по DTLS-SRTP (связка протоколов, шифрующая поток между конечными точками), так что канал по умолчанию защищён хорошо. Уязвимо то, что вокруг: канал сигналинга, через который устанавливается звонок, и серверы TURN/SFU, которые ретранслируют и маршрутизируют медиа. Типовая задокументированная атака – перехват сигналинга посредником (MitM): атакующий читает незащищённый канал, получает временные учётные данные TURN и ретранслирует трафик от имени вашего пользователя. Меры конкретны: шифрованный сигналинг (WSS, а не незащищённый WebSocket), учётные данные TURN со сроком жизни около часа и журнал каждого их запроса. Медиасервер (SFU) – особый случай: чтобы маршрутизировать многосторонний звонок, он расшифровывает потоки, то есть видит открытое клиническое видео, и поэтому обязан находиться внутри границы медданных: на вашей инфраструктуре в России или у обработчика по поручению. Устройство протокола разобрано в статье WebRTC для телемедицины, защита – в статье о сквозной защите видеоконвейера; о транспортной безопасности – в статье «Безопасность WebRTC: DTLS-SRTP» курса Video Streaming.

Сигналинг и API приложения. Ядро системы: вход, расписание, эндпоинты, которые выдают токены звонка и читают карты. Это классическая веб-поверхность атаки: ошибки аутентификации, ошибки контроля доступа (пациент получает чужую карту, поменяв ID в URL), инъекции. Здесь же происходит большинство реальных утечек: чтобы вытащить медкарты через плохо защищённый API, экзотическая атака не нужна.

Записи и хранилище данных. Здесь хранятся медданные: база пациентов, бакет с записями сессий, транскрипты, загруженные фото. Угрозы: неверно настроенный публичный бакет, резервные копии без шифрования, скопированные неизвестно куда, слишком широкие права доступа у роли. Если консультация записана, аудио и видео хранятся год (193н, п. 49–51), и всё это время хранилище записей остаётся самой ценной целью в системе.

Интеграции с МИС и партнёрами. Связи с МИС клиники, ЕГИСЗ, электронными рецептами, лабораториями, платёжным шлюзом и онлайн-кассой. Каждая интеграция – стрелка, которая пересекает границу доверия и ведёт в чужую систему, а её безопасность определяется договором и учётными данными, на которых она построена. Утёкший API-ключ к МИС означает утечку всех записей, к которым у него есть доступ.

Сторонний код внутри вашего приложения. Аналитика, отчёты о сбоях, чат-виджеты, рекламные SDK, ИИ-функции. Это самая частая и самая незаметная ошибка в телемедицине: трекинг-скрипт или SDK аналитики тихо отправляет медданные сервису, с которым у оператора нет поручения. А если серверы сервиса за рубежом, это ещё и трансграничная передача (ст. 12 152-ФЗ) и нарушение запрета на зарубежные базы (ч. 5 ст. 18). Шифрование канала здесь не спасает: законной такая передача от этого не становится, данные всё равно ушли тому, кому их передавать было нельзя. Каталог таких ошибок – в статье о типичных ошибках защиты медданных.

Шаг 2. Ищите угрозы с помощью STRIDE

Если просто смотреть на диаграмму и спрашивать «что может пойти не так?», это работает у экспертов, но не у остальных: вы находите только те угрозы, которые уже знаете. STRIDE решает эту проблему, давая шесть подсказок для каждого элемента. Метод предложили инженеры Microsoft в 1999 году, и он распространён потому, что это чек-лист, с которым справится и неспециалист. STRIDE расшифровывается как Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Каждая буква соответствует нарушению одного из свойств безопасности, поэтому список полон: любая угроза – это конкретный способ нарушить одну из гарантий.

Пройдите по каждому элементу диаграммы со всеми шестью категориями. Категории и примеры из телемедицины:

Эти свойства совпадают с тем, от чего велит защищать 152-ФЗ. Статья 19 требует защищать персональные данные «от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения». Доступ, копирование и распространение – это конфиденциальность, изменение – целостность, уничтожение и блокирование – доступность. Группы мер приказа ФСТЭК № 21 закрывают те же буквы: идентификация и аутентификация (S), обеспечение целостности (T), регистрация событий безопасности (R), управление доступом и защита систем связи и передачи данных (I), обеспечение доступности (D), управление доступом (E). STRIDE нужен не ради отчётности, а чтобы получить перечень угроз, которого требует закон; итоговый список сверьте с БДУ ФСТЭК.

Нажмите, чтобы увеличить

Для угроз приватности есть родственный чек-лист LINDDUN. Он устроен так же, но задаёт вопросы о приватности: можно ли связать данные разных сессий, можно ли идентифицировать пациента, можно ли обнаружить сам факт пользования сервисом, не собираем ли мы больше, чем человек осознаёт. В первый день он не нужен, но для психиатрии, психотерапии, наркологии, репродуктивного здоровья – любого сервиса, где чувствителен сам факт визита, – применяйте LINDDUN вместе со STRIDE. Вопрос «можно ли обнаружить факт обращения» в России – прямой вопрос о врачебной тайне.

Шаг 3. Ранжируйте риски, чтобы начать с главного

Пятьдесят угроз без приоритетов – это список задач, который никто не закроет. Ранжирование нужно, чтобы команда тратила ограниченное время на действительно важные угрозы. Самый простой надёжный способ – экспертная оценка по двум факторам: насколько вероятна угроза и насколько велик ущерб, если она реализуется. Нанесите каждую угрозу на сетку «вероятность × ущерб»: правый верхний угол, вероятные и разрушительные угрозы, – это работа на текущий квартал.

Нажмите, чтобы увеличить

Разберём расчёт на примере: ранжирование должно быть объяснимым, а не интуитивным. Распространённая схема – оценить вероятность и ущерб по шкале от 1 (низко) до 5 (высоко) и перемножить их, получив риск-балл от 1 до 25.

Возьмём угрозу «SDK аналитики сливает медданные сервису без поручения». Вероятность высокая – это одна из самых частых находок в телемедицине, и появляется она случайно: ставим 5. Ущерб высокий – утечка специальной категории, потенциально по всем пользователям: уведомление Роскомнадзора в течение 24 часов, штраф 10–15 млн ₽ по ч. 16 ст. 13.11 КоАП, а при повторной утечке – оборотный штраф: ставим 5. Риск-балл = 5 × 5 = 25. Это «чинить сейчас», верх списка.

Теперь угроза «у врача физически украли выключенный ноутбук с зашифрованным диском». Ущерб умеренный – диск зашифрован, данные почти недоступны: скажем, 2. Вероятность низкая: скажем, 2. Риск-балл = 2 × 2 = 4. Риск реален, но подождёт, пока не закрыты угрозы с баллом 25. Числа здесь не точная наука: они заставляют команду обсудить каждую угрозу и позволяют обосновать порядок приоритетов перед заказчиком и проверяющим.

Методика ФСТЭК отвечает на другой вопрос – актуальна ли угроза; матрица показывает, что исправлять первым. Нужно и то и другое: актуальные угрозы определяют меры, баллы задают очерёдность задач, а ось «ущерб» удобно заполнять по перечню негативных последствий – первому этапу методики. Если нужна детализация, модель DREAD добавляет измерения, но большинству команд хватает схемы «вероятность × ущерб».

Шаг 4. Снижайте риски и проверяйте меры

Для каждого высокого риска выберите одну из четырёх реакций и запишите её. Снизить – добавить меру, которая уменьшает риск: зашифровать бакет, включить второй фактор для персонала, оформить поручение с подрядчиком. Передать – отдать часть риска тому, кто готов взять его по договору: облаку с аттестатом под нужный уровень защищённости или видеоплатформе, работающей по поручению, вместо собственных медиасерверов. Помните, что перед пациентом за обработчика всё равно отвечает оператор (ч. 5 ст. 6 152-ФЗ): передаётся работа, но не ответственность. Принять – для низкого риска задокументировать, что вы сознательно на него идёте, и почему. Избежать – отказаться от функции, которая создаёт риск (например, не записывать сессии, запись которых не нужна).

Затем убедитесь, что мера действительно работает: непроверенная мера не считается мерой. Здесь нужны анализ защищённости, тестирование на проникновение, ревью кода и журналы. О журналах стоит сказать отдельно: это единственная защита от «R» в STRIDE, и закон требует их напрямую. Пункт 8 ч. 2 ст. 19 152-ФЗ говорит о регистрации и учёте всех действий с персональными данными в информационной системе, а приказ № 21 выделяет регистрацию событий безопасности в отдельную группу мер. Подробнее – в статье о журналах аудита и контроле доступа для клинического видео.

Моделирование угроз – процесс циклический. Методика ФСТЭК прямо требует поддерживать модель угроз в актуальном состоянии (п. 2.14), а проект замены приказа № 21 добавляет оценку защищённости после каждого инцидента. Это правильно и с инженерной точки зрения: каждая новая интеграция, каждая ИИ-функция, каждое новое хранилище требуют вернуться к диаграмме. Обновляйте модель, когда меняется система, а не когда звонит проверяющий.

«Типичная ошибка: модель угроз как разовый документ, а не рабочая привычка. Чаще всего подводит модель угроз, написанная один раз перед запуском, подшитая в папку и больше не открытая. Через полгода в продукте появляются ИИ-помощник врача, две новые интеграции с МИС и мобильное приложение, которых не было на исходной диаграмме. Устаревшая модель создаёт ложное чувство безопасности, а после утечки становится слабым аргументом и перед Роскомнадзором, и перед клиникой, которой вы обещали защиту в поручении. Встройте модель в процесс изменений: ни одна крупная функция не выходит без пятиминутной проверки «затрагивает ли это диаграмму?».»

Разбор на одном потоке

Сведём всё вместе на примере одного потока: пациент подключается к видеоприёму. Нарисуйте его: приложение пациента → сервер сигналинга → SFU (медиа) → конвейер записи → хранилище записей; и приложение пациента → API → база пациентов → мост в МИС → МИС клиники и ЕГИСЗ. Обведите границей медданных всё, что вы размещаете в России, плюс обработчиков по поручению.

Теперь пройдите STRIDE по пути записи. Spoofing: может ли кто-то войти в звонок под видом врача? Мера: второй фактор и токены на сессию. Tampering: можно ли изменить запись задним числом? Мера: хранилище без возможности перезаписи и хеши целостности. Information disclosure: бакет записей приватный, зашифрованный, находится в России и под поручением? Это риск с баллом 25 – проверяйте его первым. Denial of service: если рекордер упадёт, продолжится ли приём? Спроектируйте систему так, чтобы сбой записи никогда не блокировал оказание помощи. Elevation of privilege: может ли инженер поддержки получить сырые записи? Мера: роли с минимальными правами и журналирование доступа. За десять минут вы получили ранжированный фрагмент модели угроз; повторите то же упражнение для каждого потока.

Где здесь Фора Софт

Фора Софт с 2005 года разрабатывает продукты видео реального времени – телемедицину, видеоконференции, стриминг, видеонаблюдение, онлайн-обучение, – и в здравоохранении мы составляем модель угроз до проектирования архитектуры. Клинический проект начинается с того, что мы проводим границу медданных и проходим STRIDE по каждому потоку данных. Так шифрование, поручения, решение о СКЗИ, контроль доступа и журналирование закладываются в проект с самого начала, а не добавляются перед проверкой: сначала требования, потом функции. Формальный документ по методике ФСТЭК утверждает оператор со своими специалистами по защите информации. Если вы прорабатываете телемед-продукт, сессия моделирования угроз – самый недорогой час работы, от которого зависит всё остальное.

Главное

• Моделирование угроз позволяет найти и закрыть слабые места на бумаге – раньше, чем их найдут атакующие и проверяющие.
• В России это обязательная часть защиты ПДн: определение угроз – первая мера ст. 19 152-ФЗ, а из модели следуют тип угроз и УЗ по ПП 1119, уточнение мер по приказу ФСТЭК № 21 и решение о СКЗИ.
• Формальный документ строят по методике ФСТЭК 2021 года и БДУ; STRIDE – инженерный способ наполнить его содержанием.
• Цикл из четырёх шагов: опишите систему, найдите угрозы по STRIDE, ранжируйте по схеме «вероятность × ущерб», снизьте риски и проверьте меры.
• У поверхности атаки телемедицины шесть зон; хранилище записей и непроверенные сторонние SDK – самый высокий риск, а зашифрованное ≠ законное.
• Пересматривайте модель при каждом изменении системы: этого требуют и методика, и здравый смысл.

Что читать дальше

• 152-ФЗ и врачебная тайна простым языком для продуктовых команд
• Требования к защите ПДн в 2026 году: ПП 1119, приказы ФСТЭК и что это значит для видео
• Сквозная защита видеоконвейера телемедицины