Сквозное шифрование в телемедицине: когда нужно и чего стоит

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

Кратко

Сквозное шифрование (end-to-end encryption, E2EE) означает, что прочитать звонок могут только пациент и врач, а ваши собственные серверы – нет. Это более сильная гарантия, чем транспортное шифрование, которое есть в каждом звонке WebRTC по умолчанию. Российские нормы E2EE не требуют. 152-ФЗ и приказ ФСТЭК № 21 требуют защищать медданные при передаче мерами, выбранными по модели угроз, а если защита строится на криптографии – применять сертифицированные ФСБ средства криптографической защиты информации (СКЗИ). Это отдельный вопрос, и E2EE в браузере его не решает: SFrame на AES – не ГОСТ и не СКЗИ. Поэтому E2EE – осознанное инженерное усиление для узкого круга случаев: особо чувствительные сессии в психиатрии и психотерапии, инфраструктура, которой вы не до конца доверяете, требование заказчика. Цена высока: E2EE ломает запись на сервере, живую транскрипцию и ИИ-функции и заметно удорожает разработку и поддержку. В статье – разница между видами шифрования простым языком, разграничение E2EE и ГОСТ, правило выбора и паттерн «комплаенс-рекордер», который позволяет сохранить запись, не отказываясь от шифрования.

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

Если вы строите или покупаете телемед-платформу, слова «сквозное шифрование» звучат в опросниках безопасности клиник, в продающих презентациях, а иногда и на напряжённом совете директоров – обычно с большим напором, чем точностью. В России рядом с ними всегда звучат «ГОСТ» и «СКЗИ», и эти понятия путают ещё чаще. Одни команды внедряют E2EE там, где он не нужен, и незаметно лишаются ИИ-помощника врача и записей. Другие называют в маркетинге «сквозным» или «шифрованием по ГОСТ» обычное транспортное шифрование WebRTC – и это искажение заметит первый же специалист по защите информации у заказчика. Статья написана для основателей, продакт-менеджеров, CTO и ответственных за защиту ПДн, которым нужно ясно и обоснованно решить, нужен ли продукту настоящий E2EE, чем придётся пожертвовать и как честно об этом говорить. Она дополняет разбор слоёв в статье о сквозной защите видеоконвейера и обзор режимов в статье о шифровании, ГОСТ и СКЗИ.

Два вида шифрования, которые постоянно путают

Почти вся путаница вокруг шифрования в телемедицине возникает из-за смешения двух разных вещей. Если их развести, остальное становится простым.

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

Второе – сквозное шифрование (E2EE). Оно защищает данные на всём пути от отправителя до получателя, и никто посередине не может их прочитать – ни релей, ни медиасервер, ни компания, которой они принадлежат. Вместо инкассаторской машины – запертый ящик, ключи от которого есть только у пациента и врача: любое хранилище может перевезти ящик и прочитать наклейку с адресом, но открыть его не может. Ваши серверы превращаются в курьеров, которые везут шифртекст и не могут его прочитать.

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

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

Что на самом деле требуют нормы – и чего не требуют

Многие команды удивляются, но ни 152-ФЗ, ни подзаконные акты о защите персональных данных не требуют сквозного шифрования. Такого термина там нет.

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

На практике инженерную задачу закрывает обычное шифрование, встроенное в каждый современный видеозвонок. WebRTC – технология, на которой браузеры и приложения делают звонки в реальном времени, – по умолчанию шифрует всё медиа по схеме DTLS-SRTP, открытого режима у неё нет (RFC 8827). Канал между точками защищён, и E2EE поверх этого – осознанное усиление сверх необходимого, а не обязательный минимум.

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

E2EE и ГОСТ: два разных вопроса

Теперь о российской специфике – ради неё эту статью стоит дочитать. Если модель угроз показывает, что угрозу в канале нейтрализует шифрование, шифровать должны средства, прошедшие оценку соответствия (ст. 19 ч. 2 п. 3 152-ФЗ), то есть сертифицированные ФСБ СКЗИ того класса, который приказ ФСБ № 378 предусматривает для вашего уровня защищённости. Отечественные алгоритмы: шифрование – ГОСТ 34.12-2018 («Кузнечик» и «Магма»), подпись и хэш – ГОСТ Р 34.10-2012 и 34.11-2012; для TLS есть рекомендации по ГОСТ-TLS для версий 1.2 и 1.3.

E2EE отвечает на вопрос «кто может читать». ГОСТ и СКЗИ – на вопрос «чем шифруют и сертифицировано ли средство». Это две независимые оси, и комбинаций получается четыре.

Транспортное, не ГОСТ – штатный WebRTC и TLS в браузере. Так работает почти вся телемедицина; модель угроз должна обосновать, почему угроза перехвата на этом участке закрыта без СКЗИ или неактуальна. Транспортное по ГОСТ на отдельных участках – ГОСТ-VPN между площадками, ГОСТ-TLS на шлюзе API или в канале с МИС клиники. Это обычный способ выполнить требование о СКЗИ там, где его выставляет модель. E2EE, не ГОСТ – SFrame на AES в браузере: сильное инженерное свойство «даже платформа не видит», но не СКЗИ. E2EE по ГОСТ – технически реализовать «Кузнечик» в браузерном конвейере кадров можно, но самописная реализация не становится сертифицированным СКЗИ: сертификат выдаётся на конкретный продукт и условия его эксплуатации. Для массового пациента в браузере этот вариант сегодня практически недостижим. Реалистичный путь – нативное приложение со встроенным сертифицированным криптосредством, если такое есть для ваших платформ; это нужно уточнять у разработчика СКЗИ и по формуляру.

Практический вывод: требование о СКЗИ почти всегда выполняют на уровне каналов и сегментов, а не сквозным шифрованием, и одно не заменяет другое. Если заказчик просит «сквозное шифрование», уточните, что он имеет в виду: иногда под этим понимают «шифрование на всех участках» или «сертифицированные СКЗИ», а это другие требования с другой ценой.

Как сквозное шифрование работает в видеозвонке

Чтобы принять решение, реализовывать E2EE самому не нужно, но понимание устройства помогает трезво говорить о цене.

Обычный звонок WebRTC шифрует медиа для передачи, а медиасервер расшифровывает его, чтобы разослать поток каждого участника остальным. Чтобы звонок стал сквозным, добавляют второй, внутренний слой шифрования, ключа от которого у сервера нет. Приложение пациента шифрует каждый видеокадр второй раз, прежде чем тот покинет устройство, приложение врача расшифровывает его при получении. Сервер посередине пересылает кадры в двойной обёртке и читает только внешнюю маршрутную информацию, но не изображение внутри.

Браузерный механизм для этого – WebRTC Encoded Transform API (встречается и раннее название Insertable Streams). Он позволяет коду встроиться в конвейер после кодирования кадра, но до отправки, добавить шифрование и снять его на другой стороне. Формат стандартизован как SFrame (Secure Frame, RFC 9605, 2024) – схема, созданная именно для этого: медиасервер по-прежнему читает метаданные, нужные для маршрутизации группового звонка, а медиа остаётся зашифрованным. В групповых сессиях ключи раздаёт и ротирует протокол Messaging Layer Security (MLS, RFC 9420, 2023) – стандарт, который позволяет группе иметь общий секрет и остаётся надёжным, даже когда участники входят и выходят.

С поддержкой браузеров сейчас лучше, чем пару лет назад. По данным MDN, стандартный интерфейс RTCRtpScriptTransform с октября 2025 года имеет статус Baseline, то есть работает в актуальных версиях основных браузеров. Ключевое слово – «актуальных»: на старых телефонах и в устаревших браузерах пациентов его нет, а встроенные WebView в партнёрских приложениях и браузеры на рабочих станциях клиник, которые обновляются с опозданием, нужно проверять отдельно. Для потребительского продукта это значит либо запасной вариант для неподдерживаемых устройств, либо согласие с тем, что часть пациентов останется без E2EE. Это первая скрытая статья расходов.

Когда E2EE действительно нужен

E2EE уместен, когда среди угроз есть компрометация вашей собственной инфраструктуры или провайдера либо злоупотребление ими и когда данные настолько чувствительны, что проблемой становится уже сама возможность «платформа технически это видит». В телемедицине таких случаев немного.

Особо чувствительная помощь. Сеанс психотерапии, консультация психиатра или нарколога – одни из самых опасных данных при утечке. Врачебную тайну составляет уже сам факт обращения (ст. 13 323-ФЗ), а для психиатрии закон о психиатрической помощи отдельно закрепляет сохранение врачебной тайны (ст. 9 Закона РФ № 3185-1). Когда утечка обернулась бы катастрофой, а содержание разговора настолько интимно, оправданно сократить круг тех, кто может видеть медиа, до двух конечных точек. Чаще всего E2EE окупается на платформах ментального здоровья; подробнее – в статье о телемедицине ментального здоровья.

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

Требование заказчика. Крупная сеть клиник или корпоративный заказчик может вписать E2EE в техническое задание, что бы ни требовали нормы. Это коммерческое, а не регуляторное требование, но для плана развития продукта оно столь же обязательно. Проверьте формулировку, как описано выше.

Снижение риска изнутри. С E2EE недобросовестный сотрудник или взломщик, попавший на ваши серверы, всё равно не сможет смотреть консультации. Для небольшой команды без крупной службы безопасности ограничить то, что серверы вообще способны видеть, – вполне разумный способ снизить риск.

Если ни один пункт не подходит – а для большей части профилактики, наблюдения и плановых консультаций так и есть, – достаточно транспортного шифрования и хорошо охраняемой границы медданных. Лишний E2EE – не бесплатная предосторожность, а постоянный отказ от части функциональности.

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

Цена: что отнимает сквозное шифрование

Сила E2EE одновременно определяет его цену. Раз сервер не может читать медиа, перестаёт работать любая функция, которой нужно, чтобы сервер читал медиа. Это не разовые затраты на настройку, а постоянный отказ от целого набора возможностей.

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

Живая транскрипция и ИИ-функции отключаются. Субтитры, фоновый ИИ-помощник врача, который слушает приём и пишет протокол, перевод в реальном времени – все они обрабатывают звук на сервере. С E2EE они перестают работать: сервер слышит только шум. Если в планах есть ИИ-помощник из статьи об амбиентном клиническом документировании, он несовместим с полным E2EE. Узкое исключение – модель, которая целиком работает на устройстве врача, внутри шифрования, а не на вашем сервере.

Охват устройств сужается. Старые телефоны и браузеры не поддерживают Encoded Transform, поэтому E2EE для всех обычно означает запасной вариант, нативные приложения и больше платформ, которые нужно разрабатывать, тестировать и поддерживать.

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

Поддержка и проверка дорожают. Проблемы в зашифрованных звонках труднее отлаживать именно потому, что серверы не видят содержимого. Кроме того, E2EE выполняет своё обещание, только если участники сверяют ключи друг друга. Без этого шага опытный атакующий может подменить ключи, и гарантия «сквозного» незаметно ослабевает.

Таблица 1. Что сохраняется и чем приходится жертвовать. Решение определяют строки, которые при E2EE переходят в «невозможно»: всё, для чего серверу нужно читать медиа.

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

Как сохранить запись, не отказываясь от E2EE: комплаенс-рекордер

Самое частое возражение: «нам нужен E2EE, и при этом мы обязаны записывать». Кажется, что одно исключает другое, но есть три устоявшихся способа совместить их, и каждый – осознанный компромисс.

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

Назначенный «комплаенс-рекордер» как авторизованная точка. К этому варианту приходит большинство платформ. В звонок добавляют особого участника – сервис записи – и выдают ему ключ так же, как выдали бы человеку. Для схемы шифрования это ещё одна легитимная конечная точка, для продукта – рекордер. Маршрутизирующий сервер по-прежнему не может прочитать медиа, но его может прочитать один явно авторизованный рекордер с журналированием, который работает в вашем контуре в России или у обработчика по поручению. Важно, что запись не скрывают: пациенту и врачу сообщают, что сессия записывается, по правилам согласия и информирования вашей клиники (см. согласие пациента, запись и хранение). Так вы сохраняете суть обещания E2EE – общая инфраструктура медиа не видит – и решаете задачу записи через одно названное и контролируемое исключение.

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

Честная формулировка для всех трёх вариантов такая: настоящий E2EE и обычная запись на сервере действительно противоречат друг другу, и любая архитектура «у нас есть и то и другое» снимает это противоречие, назначая конкретную авторизованную точку с журналированием, которой разрешено видеть медиа. Брешь в шифровании ради записи вы так или иначе делаете. Вопрос в том, одна ли это названная, контролируемая и открыто объявленная точка или распахнутая дверь.

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

Разбор на цифрах: настоящая цена включения E2EE

Допустим, у вас телемед-продукт для профилактики и наблюдения, и крупная частная сеть клиник требует в ТЗ сквозное шифрование.

Посчитаем, во что это обойдётся. Первое – разработка: внутренний слой шифрования SFrame, раздача и ротация ключей через MLS, сверка ключей участников и запасной вариант для устаревших устройств. Это не работа на выходные, а для типичной команды несколько месяцев инженерной работы и постоянная поддержка второго, более сложного пути в коде. Второе – потеря функций: живые субтитры и ИИ-помощник врача на сервере перестают работать, их придётся переносить на устройства или отказаться от них, хотя ради помощника клиники и продлевали подписку. Третье – запись: вместо простой серверной записи нужно строить комплаенс-рекордер. Четвёртое – поддержка: отлаживать зашифрованные звонки дольше, а потеря ключа по замыслу необратима. Пятое – документы: E2EE не закрывает требование о СКЗИ, если его выставила модель угроз, поэтому ГОСТ-сегменты и их эксплуатация остаются в смете отдельной строкой.

Теперь взвесим. Если контракт достаточно крупный, чтобы окупить разработку, и вы можете перенести ИИ-помощника на устройство или обойтись без него, E2EE – разумное вложение, которое заодно усиливает защиту для всех остальных клиентов. Если это единственная сделка среднего размера, а E2EE лишил бы вас функции, на которой держится бизнес, правильным ответом может стать E2EE как отдельный тариф для клиентов, которым он нужен, транспортное шифрование по умолчанию и разница, заложенная в цену. Вопрос не в том, хорош ли E2EE, – он хорош, – а в том, стоит ли такое усиление потерянных функций и инженерных затрат именно для вашего продукта. Для рутинной помощи ответ чаще отрицательный, для узких чувствительных случаев, описанных выше, – однозначно положительный.

Типичная ошибка, которой стоит избегать

Самая разрушительная ошибка в этой теме – заявлять шифрование, которого у вас нет. Первый вариант – называть обычное транспортное шифрование DTLS-SRTP «сквозным». Это неправда: при транспортном шифровании медиасервер читает открытый текст, а E2EE как раз это и предотвращает. Специалист заказчика задаст один вопрос – «могут ли ваши серверы технически видеть медиа?», – и если ответ «да», заявление ложно. Второй вариант, чисто российский, – называть штатное шифрование WebRTC «шифрованием по ГОСТ» или «сертифицированным». Его так же быстро разоблачает другой вопрос: «какое СКЗИ, какой сертификат, какой класс?» Третий вариант тоньше: команда выпускает настоящий E2EE и ИИ-помощника и рекламирует оба, не замечая, что помощник обрабатывает звук на сервере и тем самым опровергает заявление. Решите, какое свойство вы продаёте, реализуйте его и описывайте точно. В здравоохранении заявление о шифровании, которое не выдерживает одного острого вопроса, хуже, чем отсутствие заявления.

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

Фора Софт разрабатывает видео реального времени для здравоохранения с 2005 года, и решение об E2EE мы прорабатываем с клиентами, начиная с требований: от какой угрозы вы защищаетесь, насколько чувствительны данные, что модель угроз требует по СКЗИ и какие серверные функции – запись, транскрипция, ИИ – нужны продукту. Когда E2EE оправдан, мы реализуем его на WebRTC Encoded Transform с шифрованием кадров по образцу SFrame, проектируем раздачу и ротацию ключей и строим комплаенс-рекордер, чтобы запись работала, не ломая шифрование для остальной инфраструктуры. Когда нужен ГОСТ, мы закладываем сертифицированные средства на тех участках, где их требует модель угроз, и не выдаём одно за другое. Когда E2EE не оправдан, мы так и говорим и оставляем платформу на хорошо защищённом транспортном шифровании. Юридическую оценку даёт ваш юрист; мы превращаем требования в архитектуру.

Главное

• Нормы требуют защищать медданные при передаче по модели угроз, а не сквозного шифрования; штатный WebRTC закрывает инженерную задачу защиты канала.
• E2EE означает, что даже ваши серверы не могут прочитать звонок; это осознанное усиление, а не базовый уровень.
• E2EE и ГОСТ – разные оси: SFrame на AES не является СКЗИ, а требование о СКЗИ обычно выполняют на каналах и сегментах.
• E2EE оправдывают особая чувствительность данных (психиатрия, психотерапия, наркология), недоверие к инфраструктуре или требование заказчика.
• E2EE ломает запись на сервере, транскрипцию и ИИ; чтобы записывать, допустите в звонок один названный рекордер с журналированием.
• Никогда не выдавайте транспортное шифрование за «сквозное», а штатное – за «ГОСТ»: специалист заказчика разоблачит это одним вопросом.

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

• Сквозная защита видеоконвейера телемедицины
• Шифрование для телемедицины: при передаче, при хранении, сквозное – и где нужны ГОСТ и СКЗИ
• Запись клинических сессий: когда, как и конфликт с комплаенсом