Сквозная защита видеоконвейера телемедицины

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

Кратко

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

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

Если вы строите или покупаете телемедицинскую платформу, видеозвонок – самая заметная её часть и при этом уже хорошо защищённая. Утечки случаются во всём остальном: бакет с записями, открытый в интернет; незашифрованное соединение между двумя вашими же серверами; API-ключ к медицинской информационной системе (МИС) в конфигурационном файле. Статья написана для основателей, продакт-менеджеров, CTO и руководителей безопасности, которым нужно понять, из чего на практике складывается защита конвейера, уверенно говорить с инженерами и проверяющими и пройти проверку безопасности без сюрпризов. Это инженерное дополнение к нормативным статьям блока 2: там – что требует норма, здесь – как конвейер это реализует.

Из чего состоит конвейер

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

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

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

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

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

Норма, которую вы реализуете: ст. 19 152-ФЗ и меры приказа ФСТЭК № 21

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

Управление доступом (УПД): к медданным получают доступ только те люди и системы, которым это нужно. Регистрация событий безопасности (РСБ): вы можете доказать, кто и что делал с данными (подробно – в статье журналы аудита и контроль доступа для клинического видео). Обеспечение целостности: данные не изменяются незаметно. Идентификация и аутентификация (ИАФ): вы проверяете, кто подключается – человек или устройство (см. аутентификация и идентификация пациентов и врачей). И защита информационной системы, её средств, систем связи и передачи данных (ЗИС): например, мера ЗИС.3 – защита персональных данных от раскрытия, модификации и навязывания при передаче. Статья в основном касается ЗИС и УПД, но затрагивает все пять групп.

Одно положение сбивает с толку почти каждую команду-новичка. Если меру технически невозможно реализовать или она экономически нецелесообразна, приказ № 21 разрешает компенсирующие меры с обоснованием (п. 10). Звучит как «можно не делать», но это не так: вы обязаны предложить равноценную защиту и письменно обосновать замену. Для медданных, которые идут по публичному интернету и лежат в облачном хранилище, убедительного аргумента против шифрования нет. На практике шифрование при передаче и хранении для видео с пациентами обязательно.

Российская специфика – в криптографии. Если модель угроз показывает, что угрозу в канале или в хранилище нейтрализует шифрование, шифровать должны средства защиты, прошедшие оценку соответствия (ст. 19 ч. 2 п. 3), то есть сертифицированные ФСБ СКЗИ того класса, который приказ ФСБ № 378 предусматривает для вашего уровня защищённости. Штатное шифрование WebRTC, TLS в браузере и AES в облачном хранилище – не ГОСТ и не сертифицированные СКЗИ. Поэтому модель угроз должна явно показать, как закрыта каждая угроза. Вариантов два. Первый – обосновать, почему на этом участке угроза нейтрализуется без криптографии или неактуальна; тогда штатное шифрование остаётся инженерной гигиеной сверх требований. Второй – закрыть участок сертифицированными СКЗИ: ГОСТ-TLS по рекомендациям Р 1323565.1.020-2018 (TLS 1.2) и Р 1323565.1.030-2020 (TLS 1.3), ГОСТ-VPN между площадками, шифрование хранилища сертифицированным средством. Как принимают это решение – в статье о шифровании, ГОСТ и СКЗИ; как его фиксируют – в статье о моделировании угроз.

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

Слой 1 – Живой звонок: WebRTC шифруется по умолчанию

Начнём с хорошей новости. Современное телемедицинское видео работает на WebRTC (Web Real-Time Communication) – открытом стандарте, на котором браузеры и мобильные приложения передают живое аудио и видео. Передавать медиа без шифрования WebRTC не позволяет: нет настройки, которая его отключает, нет режима открытого текста, нет способа сделать это случайно.

Механизм называется DTLS-SRTP, и у него две части. SRTP (Secure Real-time Transport Protocol, IETF RFC 3711) шифрует сами пакеты аудио и видео, так что тот, кто наблюдает за каналом, видит шум. DTLS (Datagram Transport Layer Security) – рукопожатие: до начала передачи медиа две стороны согласуют секретный ключ и доказывают друг другу, кто они, поэтому атакующий не может незаметно вклиниться и подменить ключ. Связка описана в RFC 5763 и RFC 5764, а архитектура безопасности WebRTC (RFC 8827) делает DTLS-SRTP единственным допустимым способом шифрования медиа. Ключи генерируются заново для каждого звонка, поэтому перехват одного звонка ничего не говорит атакующему о следующем.

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

Но есть оговорка, от которой зависит вся остальная статья: DTLS-SRTP защищает медиа между двумя точками – и только его. Он никак не защищает сигналинг, который настраивает звонок, серверы-релеи, которые пересылают пакеты, бэкенд, выдавший токен звонка, и запись, сохранённую на диск. На вестибюле отличный замок – теперь обойдём задние комнаты.

Слой 2 – Сигналинг: шифруйте настройку звонка

Сигналинг – обмен сообщениями до начала видео: кто кому звонит, какие кодеки поддерживает каждая сторона и, что важнее всего, временные учётные данные и параметры соединения, без которых устройства не найдут друг друга. WebRTC намеренно не стандартизирует сигналинг: его пишут сами, обычно поверх WebSocket – постоянного двустороннего соединения браузера с сервером.

Эта свобода несёт и риск. Модель угроз WebRTC (RFC 8826) описывает главную атаку: если канал сигналинга не зашифрован, атакующий, который может его читать, проводит атаку «человек посередине» (man-in-the-middle). Он встаёт между сторонами, перехватывает параметры соединения и временные учётные данные релея, а затем выдаёт себя за пользователя или захватывает сессию. Медиа по-прежнему зашифровано, но настройкой звонка управляет атакующий.

Решение простое и обязательное: сигналинг работает поверх WSS (WebSocket Secure) – WebSocket внутри TLS, того же шифрования, которое даёт значок замка в адресной строке. Обычный ws:// в клиническом продукте недопустим, только wss://. Здесь же пользователя аутентифицируют до выдачи любого токена звонка, чтобы посторонний не мог запросить подключение к сессии пациента. Если модель угроз требует криптозащиты по ГОСТ, на этом уровне её проще всего обеспечить для каналов между организациями, например между вашим бэкендом и МИС клиники: в браузере пациента ГОСТ-TLS работает только при установленном сертифицированном криптопровайдере. Сигналинг – небольшой участок, защитить его дёшево, и всё же это самая часто упускаемая дверь во всём конвейере.

Слой 3 – Релей и маршрутизация: учётные данные TURN и SFU внутри границы

Два устройства в открытом интернете обычно не могут соединиться напрямую: домашние и больничные сети прячут их за маршрутизаторами. WebRTC решает это с помощью вспомогательных серверов. STUN-сервер (RFC 8489) помогает устройству узнать свой публичный адрес. Если и этого мало – а в закрытых больничных сетях так бывает часто, – TURN-сервер (Traversal Using Relays around NAT, RFC 8656) пересылает медиа вместо устройств. TURN похож на почтовую переадресацию: пакет идёт через неё, когда двое не могут найти друг друга напрямую.

С точки зрения безопасности у TURN-релеев две проблемы. Во-первых, релей расходует реальный трафик, и открытым релеем охотно пользуются посторонние за ваш счёт. Во-вторых, релей стоит на пути медиа. Защищают две меры. Первая – короткоживущие учётные данные TURN: пары логин – пароль, которые генерируются на сессию и истекают примерно через час, вместо статичных общих паролей; подход опирается на расширение STUN для авторизации третьей стороной (RFC 7635). Вторая – журнал каждого запроса учётных данных, чтобы злоупотребление было видно. Статичный общий пароль TURN для всех пользователей – классическая находка при проверке безопасности.

Дальше – SFU (Selective Forwarding Unit), медиасервер, без которого не работают групповые звонки, например с врачом, пациентом и переводчиком. Именно здесь команды чаще всего ошибаются. Простой TURN-релей лишь пересылает зашифрованные пакеты, ключ ему не нужен. SFU устроен иначе: чтобы маршрутизировать поток каждого участника, он завершает соединение DTLS-SRTP, а значит, SFU видит расшифрованное клиническое видео. Вывод жёсткий: SFU обрабатывает медданные и поэтому должен находиться внутри границы – на вашей инфраструктуре в России или у подрядчика, который работает по поручению оператора и размещает медиасерверы в России. SFU стороннего сервиса без поручения – недопустимая передача медданных, даже если каждый пакет был зашифрован в пути; SFU за рубежом – ещё и трансграничная передача (ст. 12 152-ФЗ). К ловушке «зашифровано ≠ законно» мы вернёмся ниже; плюсы и минусы разных топологий – в статье P2P, SFU и MCU для клиники.

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

Слой 4 – Между сервисами: TLS и mTLS внутри периметра

Есть ошибка, которая может оставаться незамеченной годами: трафик от пациента до сервера шифруют, а свои сервисы общаются между собой открытым текстом, потому что «это всё внутри нашей сети». Соединения API с базой, API с хранилищем записей, сигналинга с контроллером SFU – если любое из них передаёт медданные без шифрования, это незашифрованная передача медданных. В облаке такой трафик идёт по сети, которую вы физически не контролируете, и модель угроз обязана это учесть; ст. 19 152-ФЗ не делает исключения для трафика между вашими серверами.

Базовое решение – TLS везде, в том числе между сервисами. Каждое внутреннее соединение, по которому могут идти медданные (связи с базой, внутренние вызовы API, очереди сообщений, кэш), использует TLS, в идеале TLS 1.3 (RFC 8446), с отключёнными устаревшими версиями и наборами шифров. Любой открытый участок с медданными считайте дефектом.

Для особо чувствительных систем сделайте следующий шаг – mTLS (взаимный TLS). Обычный TLS доказывает клиенту подлинность сервера: браузер проверяет, что сайт действительно принадлежит банку. В mTLS подлинность сертификатом подтверждают обе стороны, поэтому сервис-самозванец, каким-то образом попавший в вашу сеть, всё равно не сможет подключиться к базе: у него нет действительного сертификата. Обычный TLS похож на гостя, который проверяет удостоверение хозяина у двери; mTLS – на гостя и хозяина, которые проверяют пропуска друг у друга. В терминах приказа № 21 это практическая реализация меры ИАФ.2 – идентификации и аутентификации устройств, а не только людей.

Слой 5 – Сегментация сети: уменьшите радиус поражения

Шифрование защищает данные, а сегментация ограничивает, как далеко пройдёт атакующий, оказавшись внутри. Сегментация сети – деление инфраструктуры на изолированные зоны, чтобы взлом одной не означал взлома всех. База с медданными находится в приватной подсети без выхода в публичный интернет. Публичный API обращается к ней только по одному узкому контролируемому маршруту. Хранилище записей доступно только сервису, который пишет записи, и сервису, который их читает, – больше никому.

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

Слой 6 – Записи и хранимые данные: самая ценная комната

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

Шифрование при хранении. Каждая запись, транскрипт, фото и строка базы с медданными зашифрованы на диске. Инженерно это AES-256 средствами облака, СУБД или файловой системы; если же модель угроз опирается на криптографию, чтобы нейтрализовать угрозы хранилищу, нужны сертифицированные СКЗИ с алгоритмами по ГОСТ 34.12-2018 («Кузнечик», «Магма»). Помимо выполнения требований шифрование даёт ещё одну выгоду. В 152-ФЗ нет явной «безопасной гавани» для зашифрованных данных, и решение, считать ли инцидент утечкой и как уведомлять Роскомнадзор, принимается вместе с юристом. Но инцидент, при котором наружу ушёл шифртекст, а ключи остались в другом контуре, – совсем другая ситуация: вы можете показать, что содержание записей не было доступно, а оценка вреда – обязательная часть уведомления. Шифрование при хранении – единственная мера, способная превратить катастрофу в управляемый инцидент. Режимы шифрования подробно разобраны в статье шифрование для телемедицины.

Signed URL для доступа. Никогда не отдавайте запись по публичной ссылке и не делайте сам бакет публично доступным для чтения: неверно настроенный публичный бакет – одна из самых частых причин утечек медицинских данных. Вместо этого используйте signed URL (подписанную, или pre-signed, ссылку) – временный криптографически подписанный адрес, который даёт доступ к одному конкретному файлу на короткое время, скажем на пять минут, и затем перестаёт работать. Такие ссылки поддерживают S3-совместимые объектные хранилища, в том числе в российских облаках. Signed URL похож на ключ-карту отеля, которая открывает один номер и перестаёт работать после выезда, в отличие от мастер-ключа, который выдают всем подряд. Бэкенд проверяет, что пользователь имеет право на эту конкретную запись, и сразу выпускает короткоживущую ссылку. Через несколько минут она истекает, поэтому переслать её с пользой почти невозможно, а подобрать нельзя.

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

Слой 7 – Управление секретами: ключи от всех дверей

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

Управление секретами – хранение этих значений в выделенном зашифрованном хранилище секретов (vault), в сервисе управления ключами облака в России или в менеджере секретов, но никогда в коде, репозитории или логе. Доступ к vault сам журналируется и ограничен. С ключами шифрования нужно обращаться особенно аккуратно: их ротируют по расписанию, хранят отдельно от данных, которые они защищают (ключ рядом с шифртекстом не защищает ничего), в идеале – в аппаратном модуле безопасности (HSM); ключи СКЗИ – по правилам эксплуатации конкретного сертифицированного средства. Довод «содержимое не было доступно» работает, только если ключи не скомпрометированы, поэтому без управления секретами защита неполна. Украденный зашифрованный бэкап – управляемый инцидент; украденный зашифрованный бэкап с ключом в том же бакете – полноценная утечка.

Ловушка, на которой проваливаются проверки: «зашифровано» ≠ «законно»

Можно выполнить всё, что описано выше, и всё равно не пройти проверку, потому что шифрование отвечает не на тот вопрос, который задаёт закон. Шифрование защищает данные от посторонних. Поручение оператора определяет, кто вправе получать к ним доступ. Это разные меры, и нужны обе.

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

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

Разбор на числах: цена одного пропущенного слоя

Посчитаем, чем вы рискуете. Допустим, в бакете хранятся записи сессий 5 000 пациентов. Инженер в спешке делает бакет публичным, чтобы отладить воспроизведение, и забывает вернуть настройку. Ошибку обнаружили в понедельник в 10:00.

Если записи не были зашифрованы при хранении, это утечка специальной категории персональных данных, и отсчёт пошёл. Первичное уведомление Роскомнадзора – в течение 24 часов, то есть до 10:00 вторника; итоги внутреннего расследования – в течение 72 часов, до 10:00 четверга (ч. 3.1 ст. 21 152-ФЗ). Если вы обработчик, клинику-оператора нужно предупредить ещё раньше – в срок из поручения, иначе она не успеет уведомить регулятора сама. Штраф за утечку данных о здоровье – 10–15 млн ₽ для юрлица (ч. 16 ст. 13.11 КоАП), за повторную – 1–3% выручки, но не менее 25 млн и не более 500 млн ₽ (ч. 18). Добавьте расследование, юристов и потерю доверия клиник – и одна неверная настройка обходится в десятки миллионов рублей.

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

Проверка безопасности, которую должна пройти ваша система

Если сложить все слои, получится проверка, которую телемедицинская система должна пройти до первого пациента. Бесплатный чек-лист проверки безопасности ниже превращает каждый слой в вопрос «да/нет» с опорной нормой рядом.

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

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

Самая дорогая ловушка – считать, что сильное шифрование живого звонка защищает весь конвейер. Это не так. DTLS-SRTP защищает медиа между двумя точками и больше ничего: ни сигналинг, ни учётные данные TURN, ни связь с базой, ни запись на диске, ни SDK аналитики. Команда показывает работающий зашифрованный звонок, объявляет продукт «безопасным» и выпускает его с публичным бакетом записей и статичным паролем TURN. Замок на вестибюле настоящий, а задние двери нараспашку. Проверки безопасности почти всегда проваливаются в слоях за звонком – поэтому статья и обходит все семь.

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

Фора Софт разрабатывает видео реального времени для здравоохранения с 2005 года, и сквозная защита конвейера – основа нашего подхода к телемедицинским проектам: сначала требования (шифрование при передаче и хранении, решение о СКЗИ в модели угроз, компоненты внутри границы медданных в России), затем функции. Мы проектируем путь медиа так, чтобы SFU и хранилище записей находились внутри границы, сигналинг шёл по WSS, записи были доступны только через короткие signed URL, а секреты хранились в vault, а не в конфиге. Телемедицина – одно из нескольких направлений видео реального времени, в которых мы работаем, наряду с видеоконференцсвязью, стримингом, онлайн-обучением и видеонаблюдением, и подходы к защите переносятся между ними напрямую. Мы превращаем требования норм в архитектуру; юридическая оценка и аттестация остаются за вашими юристами и специалистами по защите информации.

Главное

• Живой звонок WebRTC зашифрован по умолчанию; риски – во всём, что вокруг.
• Шифруйте каждый участок: WSS для сигналинга, TLS/mTLS между сервисами, шифрование записей при хранении.
• Где модель угроз закрывает угрозы криптографией, нужны сертифицированные СКЗИ: штатные WebRTC, TLS и AES – не ГОСТ.
• SFU и хранилище записей видят открытые медданные – держите их внутри границы: ваши или по поручению, в России.
• Отдавайте записи только через короткие signed URL и храните ключи в vault, отдельно от данных.
• «Зашифровано» ≠ «законно»: каждому, кто может видеть медданные, нужно поручение оператора.

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

• 152-ФЗ и врачебная тайна простым языком для продуктовых команд
• Моделирование угроз телемедицинской платформы
• Сквозное шифрование в телемедицине: когда нужно и чего стоит