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

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

Кратко

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

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

Шифрование – редкая мера защиты, которая окупается дважды. Оно закрывает требование ст. 19 152-ФЗ и может превратить украденный ноутбук или потерянный бэкап из утечки медданных со штрафом 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП) в инцидент, где вы способны доказать, что доступа к данным никто не получил. В телемедицине данные пациента хранятся и передаются в гораздо большем числе мест, а российские нормы добавляют вопрос, которого нет в зарубежных руководствах: чем шифровать – штатными средствами или сертифицированными СКЗИ. Статья написана для основателя, продакт-менеджера и ИТ-руководителя клиники, которым нужно точно ответить на пять вопросов: что шифровать при передаче, что при хранении, когда действительно нужно сквозное шифрование, кто держит ключи и где модель угроз потребует ГОСТ. К статье прилагаются ссылки на нормы, расчёты и одностраничный чек-лист для команды.

Три вопроса и ещё два

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

При передаче вопрос такой: пока данные идут между двумя машинами (от приложения пациента к серверу, от сервера к врачу, от сервиса к сервису), может ли кто-то посередине их прочитать? Защищает от этого транспортное шифрование: данные запечатываются на каждом отрезке пути и распечатываются на каждой доверенной остановке, как курьерский пакет, который возят между офисами, и в каждом офисе есть ключ.

При хранении вопрос другой: пока данные лежат на диске (в бакете записей, в базе, на носителе с бэкапом, на ноутбуке), может ли их прочитать тот, кто унёс диск? Защищает шифрование хранилища: файл зашифрован на самом носителе, и владение железом не даёт доступа к данным.

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

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

Пятый вопрос чисто российский: чем шифруют? Браузеры, операционные системы и облака используют международные алгоритмы, прежде всего AES. Там, где модель угроз полагается на криптографию, нормы требуют сертифицированных средств на ГОСТ-алгоритмах. Это не замена первым четырём вопросам, а ещё одно измерение, и в каждом разделе ниже мы возвращаемся к нему вместе с вопросом о ключах.

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

Что российские нормы на самом деле говорят о шифровании

Сведения о здоровье пациента – специальная категория персональных данных (ст. 10 152-ФЗ) и одновременно врачебная тайна (ст. 13 323-ФЗ). Вся система требований разобрана в базовой статье о 152-ФЗ и врачебной тайне, здесь нужны только места, где речь заходит о шифровании.

Статья 19 152-ФЗ слова «шифрование» не употребляет. Она требует определить угрозы безопасности данных (ч. 2 п. 1), то есть составить модель угроз; применять организационные и технические меры с учётом уровней защищённости (п. 2); использовать средства защиты информации, прошедшие в установленном порядке оценку соответствия (п. 3); вести учёт машинных носителей (п. 5). Уровень защищённости, от УЗ-4 до самого строгого УЗ-1, задаёт ПП 1119. Для сведений о здоровье при угрозах 3-го типа это УЗ-3, если пациентов меньше 100 000, и УЗ-2, если больше; при угрозах 2-го и 1-го типа уровень выше.

Приказ ФСТЭК № 21 делит меры на 15 групп, и к шифрованию ближе всего две: «защита информационной системы, её средств, систем связи и передачи данных» (ЗИС), то есть канал, и «защита машинных носителей информации» (ЗНИ), то есть хранение. Но в самом начале приказ оговаривает, что меры, связанные с применением шифровальных (криптографических) средств, он не рассматривает (п. 1). Их задаёт ФСБ приказом № 378, где расписаны организационные и технические меры с использованием СКЗИ для каждого из четырёх уровней защищённости. Отсюда российская схема: ФСТЭК отвечает на вопрос «что защищать», ФСБ – на вопрос «чем шифровать, если вы защищаете шифрованием».

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

Заметьте, чего в этих актах нет: алгоритма для штатного шифрования, длины ключа, версии TLS. Требования технологически нейтральны, с одним важным исключением: там, где модель угроз полагается на криптографию, средство должно быть сертифицированным СКЗИ. Сертифицированные СКЗИ реализуют российские стандарты: блочные шифры «Кузнечик» и «Магма» с режимами работы (ГОСТ 34.12-2018 и 34.13-2018 – межгосударственные версии ГОСТ Р 34.12/34.13-2015), подпись и хэш (ГОСТ Р 34.10-2012 и 34.11-2012), а для TLS – рекомендации по стандартизации Р 1323565.1.020-2018 (TLS 1.2) и Р 1323565.1.030-2020 (TLS 1.3).

Шифрование связано и с документами. В уведомлении Роскомнадзору об обработке персональных данных оператор указывает сведения о наличии шифровальных (криптографических) средств и их наименования (ст. 22 ч. 3 п. 7). То, что записано в модели угроз, должно совпадать с тем, что сообщено регулятору, и с тем, что реально работает в продакшене.

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

Шифрование и утечка: исключения нет, но разница огромна

Порядок действий при утечке задаёт ч. 3.1 ст. 21 152-ФЗ. Если установлен факт неправомерной или случайной передачи (предоставления, распространения, доступа) персональных данных, повлёкшей нарушение прав пациентов, оператор уведомляет Роскомнадзор дважды: в течение 24 часов – о самом инциденте, предполагаемых причинах, вреде и принятых мерах, в течение 72 часов – о результатах внутреннего расследования. Порядок подачи задаёт приказ Роскомнадзора № 187, уведомление подаётся через портал персональных данных. Отдельного исключения «зашифрованные данные – не утечка» в законе нет.

Но обратите внимание на конструкцию нормы: обязанность возникает при передаче или доступе к данным, повлёкших нарушение прав. Если пропал диск, зашифрованный при хранении, а ключ от него никогда на нём не лежал и не утёк, разговор о том, был ли доступ к данным, пойдёт совсем иначе, чем после открытого бакета с записями. Как квалифицировать конкретный случай, решает юрист. Консервативная инженерная позиция: исходить из того, что 24-часовое уведомление подавать придётся, и сразу готовить к 72-часовому отчёту доказательства: чем были зашифрованы данные, где лежали ключи, что в журнале нет обращений к ним.

Довод «доступа к данным не было» работает, только если выполнены условия:

• Шифрование выбрано и задокументировано в модели угроз: механизм и алгоритм, а там, где модель требует СКЗИ, – сертифицированное средство, установленное и эксплуатируемое по его документации.
• Ключ не скомпрометирован и хранился отдельно от данных. Зашифрованный диск с ключом на том же диске – это открытые данные с одним лишним шагом.
• Остались следы: журнал обращений к ключам, учёт машинных носителей (ст. 19 ч. 2 п. 5), документ об уничтожении носителя или о криптографическом стирании.
• Второй путь – уничтожение. Носитель, выведенный из эксплуатации с уничтожением данных и документом об этом, уже не может «утечь» позже. Это важно при списании дисков хранилища записей.

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

Сколько стоит потерянный диск

Разберём сценарий с цифрами. Допустим, пропал диск с бэкапом записей о 20 000 пациентов.

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

Путь Б: не зашифровано. Это утечка медданных в чистом виде: уведомление за 24 часа, отчёт за 72 часа и ч. 16 ст. 13.11 КоАП (утечка специальных категорий, включая сведения о здоровье) – 10–15 млн ₽ для юрлица. Поделим на число пациентов:

«10 000 000 ₽ ÷ 20 000 = 500 ₽ на пациента; 15 000 000 ₽ ÷ 20 000 = 750 ₽ на пациента.»

И это только штраф, без расходов на расследование, юристов, письма пациентам и потерянных клиник-заказчиков. Для небольшого инцидента расчёт ещё жёстче: вилка ч. 16 не зависит от числа затронутых, и для 1 000 пациентов те же 10–15 млн ₽ дают 10 000–15 000 ₽ на человека. Повторная утечка обойдётся в 1–3% выручки, но не менее 25 млн и не более 500 млн ₽ (ч. 18). Неуведомление Роскомнадзора – ещё 1–3 млн ₽ (ч. 11).

Сравните цену двух путей. Путь А требует включённого шифрования и дисциплины в работе с ключами, что, как мы посчитаем ниже, стоит порядка сотен рублей в месяц, плюс лицензии СКЗИ там, где их требует модель угроз. Цена пути Б – восьмизначная сумма. Шифрование – самая дешёвая страховка в медицинском софте, но только если ключи хранятся отдельно от данных; поэтому управлению ключами посвящён отдельный раздел.

При передаче: звонок уже защищён, остальное доделайте сами

Хорошая новость: сам видеоприём на правильно собранном WebRTC уже зашифрован, и отключить это нельзя.

WebRTC – движок связи в реальном времени, встроенный во все крупные браузеры и большинство телемед-приложений, – требует шифрования на уровне стандартов. Архитектура безопасности WebRTC от IETF (RFC 8827) предписывает передавать всё медиа по SRTP, Secure Real-time Transport Protocol (RFC 3711), с ключами, согласованными через DTLS-SRTP (RFC 5764), – рукопожатие из того же семейства TLS, которое защищает сайты. Режима открытого медиа в совместимом WebRTC-стеке нет. Аудио- и видеопакеты покидают устройство пациента зашифрованными AES и в зашифрованном виде доходят до следующего узла, а сигналинг (служебные сообщения для установки звонка) и ваши REST API идут по обычному HTTPS/TLS. Механика протоколов разобрана в разделе Video Streaming: безопасность WebRTC: DTLS и SRTP; здесь мы остаёмся на уровне комплаенса.

Ответственному за комплаенс нужно знать, как устроено это шифрование: оно защищает отдельные участки пути, а не весь путь целиком. Консультация на двоих может идти напрямую (peer-to-peer) с шифрованием от устройства до устройства. Но как только в продукте появляется медиасервер SFU (Selective Forwarding Unit), стандартный компонент, который принимает поток каждого участника и пересылает его остальным, DTLS-рукопожатие выполняет сам SFU. Он расшифровывает каждый входящий поток, держит его в памяти в открытом виде и заново шифрует для каждого получателя. То есть ваш сервер может читать медиа. Это не дефект: именно так работают запись, транскрипция и групповые звонки. Но SFU должен находиться строго внутри границы медданных: ему нужны те же меры защиты и журнал событий, размещение в России, а если его эксплуатирует подрядчик – поручение оператора на обработку ПДн (ст. 6 ч. 3 152-ФЗ), без которого подрядчик не вправе касаться данных пациентов. TURN-реле устроено иначе. Это резервный сервер, который пересылает пакеты, когда домашние и больничные сети блокируют прямой путь; медиарукопожатие он не завершает, пересылает пакеты в зашифрованном виде и прочитать их не может. На карте потоков это нужно отразить: два сервера несут разный риск, хотя по консервативной практике оба держат в России и под поручением.

Где здесь ГОСТ

Браузерный WebRTC шифрует не по ГОСТ: DTLS и SRTP в браузерах работают на международных наборах шифров, а сам браузер сертифицированным СКЗИ не является. Значит, модель угроз должна решить вопрос для каждого участка канала одним из двух способов. Либо обосновать, почему угроза перехвата на этом участке нейтрализуется без криптографии или неактуальна; тогда штатные DTLS-SRTP и TLS остаются просто хорошей инженерной практикой сверх требований. Либо закрыть участок сертифицированными СКЗИ.

Второй вариант реалистичен на каналах между организациями и площадками: ГОСТ-VPN между вашим контуром и МИС клиники, ГОСТ-TLS на шлюзе API для интеграций. В браузере пациента он почти недостижим: ГОСТ-TLS работает там только при установленном сертифицированном криптопровайдере, а обычный пациент его ставить не будет. Поэтому типичная архитектура такая: штатное шифрование на «последней миле» до пациента с обоснованием в модели угроз и ГОСТ на межорганизационных каналах. Заказчик (клиника или госучреждение) вправе выдвинуть собственное требование, поэтому узнайте его до проектирования архитектуры, а не после. Как фиксируют такое решение, рассказано в статье о моделировании угроз телемед-платформы.

Три слабых места

Транспортное шифрование в телемед-проектах ломается в трёх местах, и ни одно из них не звонок.

Шифрование обрывается на балансировщике. TLS от браузера пациента терминируется на балансировщике, а дальше трафик идёт между сервисами в открытом виде: «это же наша приватная сеть». Если модель угроз считает внутреннюю сеть облака доверенной, это нужно обосновать, и грамотный проверяющий спросит, на чём держится доверие. Шифруйте связи между сервисами (TLS или mTLS) либо документируйте компенсирующую меру, в которую верите сами.

Устаревшие версии TLS. IETF вывел TLS 1.0 и 1.1 из употребления (RFC 8996, 2021). Разумный минимум – TLS 1.2 с современными наборами шифров, предпочтительно 1.3. Телемед-платформы, которые всё ещё принимают 1.0/1.1, проваливают анализ защищённости и опросники клиник. Для ГОСТ-участков есть свои профили TLS 1.2 и 1.3 по рекомендациям Р 1323565.1.020-2018 и Р 1323565.1.030-2020.

Побочные каналы. Приём зашифрован, а SMS-напоминание, письмо с итогами визита и вебхук в аналитику – нет или не под вашим контролем. Обычные SMS и почта не шифруются сквозным образом; это одна из причин, почему для коммуникаций с пациентом действуют собственные правила согласия. А push-уведомление проходит через инфраструктуру производителя операционной системы, вне вашего контура, так что медданным в его тексте не место.

При хранении: где телемед-продукты на самом деле проваливаются

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

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

Технически шифрование хранилища – самая дешёвая из мер защиты. Современные процессоры аппаратно шифруют AES со скоростью в гигабайты в секунду на ядро, а объектные хранилища и управляемые базы крупных облаков, как правило, включают серверное шифрование одной настройкой; проверьте, что у вашего провайдера оно включено по умолчанию. Прикинем для средней платформы: 1 000 записанных консультаций в день по 20 минут при 1,5 Мбит/с.

«20 × 60 с × 1,5 Мбит/с = 1 800 Мбит ≈ 225 МБ на консультацию 1 000 × 225 МБ = 225 ГБ новых записей в день, около 6,75 ТБ в месяц»

Серверное шифрование всего этого объёма ключом из облачного KMS обойдётся ориентировочно в сотню рублей в месяц за ключ плюс операции с ключом, порядка нескольких рублей за 10 000 запросов (сверяйте с прайсом провайдера). Итого сотни рублей в месяц при счёте за хранение в десятки тысяч. Довод «шифрование слишком дорого» давно устарел; дорого обходится только дисциплина вокруг него.

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

Формальное шифрование хранилища от настоящей защиты отличают три вещи.

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

Ноутбук – тоже хранилище. Для устройств, которые действительно теряют (ноутбуков, телефонов, флешек), нужно полнодисковое шифрование с управляемыми ключами: FileVault или BitLocker, а там, где этого требует модель угроз, – сертифицированное средство. Включать его должна политика MDM (mobile device management, централизованное управление устройствами), а не просьба к сотрудникам. Приказ № 21 выделяет защиту машинных носителей в отдельную группу мер (ЗНИ), а ст. 19 требует их учёта: разрыв между политикой на бумаге и её принудительным применением – классический путь к утечке.

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

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

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

Теперь о том, что маркетинговые страницы запутывают сильнее всего. Каждая серьёзная телемед-платформа шифрует данные при передаче и при хранении. Сквозное шифрование – другое, более строгое свойство: сама платформа не может читать медиа. Ключи создаются и хранятся только на устройствах участников, SFU пересылает непрозрачные кадры (в современном WebRTC – через API encoded transforms со схемой вроде SFrame, RFC 9605), а ваши серверы, облако и даже взломанная инфраструктура видят только шифротекст.

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

Главное следствие: E2EE и серверные функции несовместимы в принципе. Сервер, который не читает медиа, не может записывать его в медкарту, транскрибировать, делать субтитры для доступности, запускать ИИ-ассистента для документирования, склеивать групповую запись и показывать сессию супервизору. Поэтому любой E2EE-дизайн в телемедицине либо отказывается от этих функций, либо переносит их на устройства (запись на клиенте со своими проблемами хранения ключей), либо сознательно оставляет бреши («бот записи – молчаливый участник E2EE с ключами»). Такие бреши нужно честно документировать, потому что недокументированную брешь найдёт проверяющий. В некоторых направлениях такой компромисс оправдан; типичный пример – особо чувствительные психиатрия и психотерапия, где запись не нужна. Полная схема решения, включая групповые ключи через MLS (RFC 9420), – в статье сквозное шифрование в телемедицине: когда нужно и чего стоит. Выбирайте E2EE, если ваша модель угроз выводит оператора платформы за границу доверия, и никогда потому, что кто-то сказал, будто его требует закон.

Управление ключами: от него зависят три предыдущих слоя

Все слои выше в итоге упираются в то, кто контролирует ключи. Довод «доступа к данным не было» в расследовании утечки строится на ключах. Транспортное шифрование отличается от E2EE тем, у кого ключи. Зашифрованный бакет отличается от защищённого тем, кто может воспользоваться ключом. Для СКЗИ к этому добавляется формальная сторона: с ключевыми носителями обращаются по документации на средство, а приказ ФСБ № 378 для всех уровней защищённости требует сохранности носителей, исключения неконтролируемого доступа посторонних в помещения и утверждённого перечня лиц, допущенных к данным.

Используйте конвертное шифрование: эту схему поддерживает любой облачный KMS. Сервис управления ключами (KMS) – отдельный защищённый сервис с журналированием, корневые ключи которого не покидают защищённое хранилище. Каждая запись или строка получает собственный ключ данных. Ключ данных шифрует объект, а корневой ключ KMS шифрует ключ данных, который хранится рядом с шифротекстом, как запечатанный конверт, открыть который может только KMS. Для расшифровки нужен авторизованный вызов KMS, и каждый такой вызов попадает в журнал. Так доступ к ключам сам создаёт журнал событий безопасности, которого требует группа мер РСБ приказа № 21, а если отозвать у роли право на KMS, она сразу теряет доступ ко всем объектам, которые иначе могла бы скачать.

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

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

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

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

Вся карта на одной странице

Таблица 1. Четыре слоя шифрования и нормы, на которые они опираются.

Строки таблицы – независимые меры против разных угроз. Довод «доступа к данным не было» работает, только если выполнены и строка шифрования, и строка ключей. А единственную строку, которой нормы не требуют, рекламируют громче всех.

Ошибки, которые мы встречаем постоянно

Несколько типичных провалов из ревью телемед-платформ. В каждом верное утверждение («мы используем шифрование») скрывает ложное («значит, данные защищены»).

Зашифрованный бакет с бессрочной ссылкой. Записи зашифрованы на стороне сервера, но раздаются через подписанные ссылки без срока жизни, которые вставлены в тикеты поддержки и заметки в МИС. Шифрование ничего не дало: ссылка сама работает как ключ и лежит в открытом виде повсюду. Решение: ссылки со сроком жизни в несколько минут и запись в журнале о каждом скачивании.

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

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

«Это зашифровано» как исчерпывающий ответ. Видеосервис безупречно шифрует, но его серверы за рубежом и поручения нет. Аналитический SDK по идеальному TLS отправляет медданные компании, которая не вправе их получать, и это ещё и трансграничная передача (ст. 12 152-ФЗ). Шифрование отвечает на вопрос «прочитают ли данные посторонние в пути или на диске?», но никогда не отвечает на вопрос «имела ли эта сторона право получить данные?».

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

Неуправляемый ноутбук. На сервере всё идеально, но врач выгружает запись для разбора случая на личный компьютер без шифрования диска. Нужно полнодисковое шифрование через MDM на каждом устройстве, которое может получить доступ к медданным; политика, которую никто не применяет принудительно, мерой не является.

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

Фора Софт делает видеософт с 2005 года: телемедицину, видеоконференции, стриминг, видеонаблюдение, e-learning. В архитектуре шифрования наша работа с требованиями к защите данных встречается с опытом в WebRTC. В наших телемед-проектах меры из этой статьи – исходные требования к дизайну, а не доработки. Это медиаплоскости на DTLS-SRTP с TLS на всех внутренних связях, конвейеры записи, которые шифруют данные по конвертной схеме ещё до записи в хранилище, схемы KMS с раздельным и журналируемым контролем над ключами с первого дня и место под ГОСТ-шифрование на тех участках, где его требует модель угроз. E2EE мы применяем только там, где его действительно требует модель угроз продукта, и честно разбираем последствия для записи и ИИ до первой строки кода. Если вы проектируете платформу или готовите существующую к проверке либо к требованиям клиники-заказчика, поговорите с нашей телемед-командой.

Главное

• Нормы технологически нейтральны: шифрование следует из модели угроз (ст. 19 152-ФЗ, ПП 1119, приказ ФСТЭК № 21), а компенсирующие меры требуют обоснования, поэтому проектируйте так, будто шифрование обязательно.
• Где модель угроз полагается на криптографию, нужны сертифицированные СКЗИ по приказу ФСБ № 378 на ГОСТ-алгоритмах; браузерный WebRTC и облачный AES ими не являются.
• Исключения «зашифровано – не утечка» в ст. 21 нет, но шифрование с отдельно хранящимися ключами – главный довод в расследовании; утечка медданных стоит 10–15 млн ₽.
• WebRTC шифрует звонок по умолчанию (DTLS-SRTP, RFC 8827), но SFU читает медиа; реальные утечки происходят из хранилищ: записей, бэкапов, ноутбуков.
• E2EE нормы не требуют, вопрос о СКЗИ оно не решает и исключает запись, транскрипцию и ИИ; выбирайте его по модели угроз.
• Всё решает контроль над ключами: конвертная схема, разные домены отказа, осознанный выбор владельца корневого ключа, ротация, криптографическое стирание.

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

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