Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек

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

Кратко

Соответствие 152-ФЗ и 323-ФЗ нельзя купить как продукт или получить как сертификат: это паттерн, типовая архитектурная схема. Проведите границу вокруг всех систем, которые касаются медданных пациентов, разместите всё, что внутри неё, в России и соблюдайте шесть правил. Каждый компонент внутри границы либо свой, либо принадлежит подрядчику, который работает по поручению на обработку (ст. 6 ч. 3 152-ФЗ) и хранит данные в РФ. Каждое соединение и каждое хранилище зашифрованы, а ключи лежат отдельно от данных. Сеть разделена на плоскости, чтобы взлом одной не означал взлома всех. Журнал событий работает как сквозной сервис и видит каждую плоскость. Медданные не попадают туда, о чём команды обычно забывают: в логи, URL, аналитику, push-уведомления. Поверх этого 323-ФЗ и приказ Минздрава 193н добавляют в ту же границу идентификацию через ЕСИА, подпись врача УКЭП и передачу документов в ЕГИСЗ, а уровень защиты задают ПП 1119 и приказ ФСТЭК № 21. Инфраструктура обходится недорого, основные расходы уходят на регулярный цикл проверок. В статье паттерн собран в одну диаграмму, через неё проведён реальный видеостек, а сама схема приложена одностраничным PDF.

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

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

Что проверяющий имеет в виду под «архитектурой»

Когда Роскомнадзор проверяет оператора персональных данных, Росздравнадзор – медицинскую деятельность, а служба безопасности клиники – вендора перед закупкой, никто не начинает с кода. Все задают вопросы об устройстве системы. Где лежат данные пациентов и в какой стране? Кто может до них добраться? Какие подрядчики с ними работают и по какому договору? Как вы узнаете, что к ним получил доступ посторонний? За каждым вопросом стоит требование закона: базы с ПДн граждан – только в России (ст. 18 ч. 5 152-ФЗ), меры защиты и учёт всех действий с данными (ст. 19), договор-поручение с каждым обработчиком (ст. 6 ч. 3), уровень защищённости и перечень лиц с доступом (ПП 1119), состав мер (приказ ФСТЭК № 21).

Сначала два определения, на которых держится всё остальное. Медданные – сведения о здоровье конкретного человека: по 152-ФЗ это специальная категория персональных данных (ст. 10), а по 323-ФЗ врачебную тайну составляет уже сам факт обращения за помощью (ст. 13). Поэтому медданные – это и диагноз с фамилией, и видеозапись консультации, и транскрипт чата, и время приёма, привязанное к аккаунту пациента. На менее очевидном инженерные команды спотыкаются чаще: метаданные – тоже медданные. IP-адрес, связанный с логином пациента, комната с именем onkologiya-povtorny-priem-petrov, строка лога «пациент 4711 был у доктора Смирновой во вторник» – каждая из этих записей связывает человека с фактом обращения за медицинской помощью, и этого достаточно.

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

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

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

Правило 1 – сначала начертите границу медданных, потом всё остальное

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

Проводите её по движению данных, а не по оргструктуре. Выпишите все виды данных, которые создаёт продукт: видео, аудио, записи, транскрипты, чат, файлы, показатели, записи о приёмах, события входа. Затем проследите, куда попадает каждый из них, включая потоки, которые никто специально не проектировал: краш-репорты, отладочные логи, события аналитики, письма с подтверждениями. Любая система, куда попадают медданные, оказывается внутри границы, хотите вы этого или нет. Получившаяся карта потоков – основа модели угроз (ст. 19 ч. 2 п. 1 152-ФЗ) и расчёта уровня защищённости по ПП 1119: при угрозах 3-го типа сведения о здоровье менее чем 100 000 пациентов дают УЗ-3, а сверх этого порога – УЗ-2. Проект нового приказа ФСТЭК взамен № 21 (июль 2026 года, на 24.09.2026 не подписан) вводит оценку ещё до начала обработки, и она тоже начинается с этой карты.

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

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

Хороший пример – имена комнат. Ссылка на консультацию вида /room/dermatologiya-biopsiya-ivanov оставляет диагноз и фамилию в истории браузера, логах прокси и в каждом аналитическом инструменте, который записывает URL, то есть в системах далеко за пределами любой границы. Ссылка /room/c7f8-44a2 ничего не раскрывает. Медданные в URL – одна из классических ошибок телемедицины, и исправляется она архитектурно, а не правкой в коде: идентификатор назначается там, где создаётся комната.

Правило 2 – компоненты бывают только трёх видов

Когда граница начерчена, каждый компонент стека должен быть ровно одним из трёх:

1. Свой – ПО, которое вы сами разворачиваете в российском облаке с аттестатом (или в собственном ЦОДе): ваш API, ваша база, SFU, который вы эксплуатируете (Selective Forwarding Unit – медиасервер, пересылающий видео между участниками), ваш TURN-сервер (резервный ретранслятор медиа на случай, когда два устройства не могут соединиться напрямую).
2. Подрядчик по поручению – управляемый сервис, провайдер которого принимает поручение на обработку с условиями ст. 6 и 19 152-ФЗ и хранит данные в России: облачное объектное хранилище, российский видео-API, сервис распознавания речи с понятными условиями хранения.
3. «Слепой» – сервис, который никогда не получает медданных, потому что вы обезличиваете или очищаете данные до отправки: продуктовая аналитика, маркетинговые рассылки, сбор краш-репортов.

Четвёртой категории нет. Довод «они же шифруют» её не создаёт: обработка по 152-ФЗ – это любое действие с персональными данными, включая хранение (ст. 3), поэтому подрядчик, у которого лежат зашифрованные медданные, всё равно участвует в обработке. Мы закладываем в архитектуру консервативную позицию: такому подрядчику нужно поручение, а его серверы должны стоять в РФ, независимо от того, может ли он прочитать данные. Команды регулярно пытаются объявить TURN-серверы, CDN или почтовый ретранслятор «просто трубой». Но сервер, через который идёт медиа консультации, – часть вашей системы, и мы держим его внутри границы.

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

Два уточнения к категориям. Аттестат облака распространяется на инфраструктуру, а не на ваш аккаунт. Российские облака аттестуют под требования к защите ПДн конкретные сегменты: у Yandex Cloud, Cloud.ru, Selectel и MWS заявлены аттестаты на УЗ-1, у VK Cloud – изолированный сегмент, параметры которого стоит уточнять. Если вы используете для медданных сервис вне аттестованного контура, отвечаете за это вы, даже при подписанном договоре. Кроме того, провайдер защищает инфраструктуру, а шифрование, политики доступа и сетевые правила внутри аккаунта настраиваете вы. Статус подрядчика со временем меняется. Крупнейшие зарубежные облака закрыли доступ корпоративным клиентам из России с 20 марта 2024 года, а с 1 июля 2025 года хранить ПДн граждан в зарубежных базах прямо запрещено (ст. 18 ч. 5). Поэтому таблица ниже составлена на уровне категорий, а условия каждого подрядчика нужно перепроверять при подписании договора (подробно – в статье о поручении и договорах с подрядчиками).

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

Правило 3 – шифруйте каждое соединение и отдельно управляйте ключами

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

При передаче. WebRTC – встроенный в браузеры механизм связи в реальном времени – шифрует медиа по стандарту, нешифрованного режима в нём нет. Медиа идёт по SRTP (RFC 3711) с ключами, согласованными через DTLS-SRTP (RFC 5764), как требует архитектура безопасности WebRTC (RFC 8827). Сигналинг и API работают по TLS 1.2 или 1.3. Если модель угроз предполагает, что угрозы в канале связи нейтрализуются криптографией, нужны средства криптозащиты (СКЗИ), сертифицированные ФСБ (приказ ФСБ № 378). Для шифрования по ГОСТ есть свои профили TLS (Р 1323565.1.020-2018 для TLS 1.2, Р 1323565.1.030-2020 для TLS 1.3), но браузерный WebRTC по ГОСТ не шифрует, и это решение нужно зафиксировать в модели угроз. Чаще всего забывают о внутренних соединениях: от SFU к серверу записи, от сервера записи к хранилищу, между сервисами. Шифровать нужно каждое соединение, в том числе внутри вашей частной сети: плоская доверенная сеть за одним TLS-терминатором – как раз то, против чего направлено правило 4. Как устроены протоколы, разобрано в разделе о стриминге: как на самом деле работает DTLS-SRTP.

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

Без правильного обращения с ключами шифрование мало что стоит. Здесь три правила. KMS логически отделён от плоскости данных: сервисы запрашивают расшифровку через него, каждый запрос попадает в лог, и никто не скачивает «файл с ключом». Доступ к ключам выдаётся по тому же принципу минимальных привилегий, что и доступ к данным: сервер записи умеет только шифровать, расшифровывать может только сервис воспроизведения, и разница сводится к двум политикам доступа. Ключи меняются по расписанию без перешифрования архива, и конвертная схема делает это дешёвым. Так же обращаются с секретами: API-токенами, паролями БД, общими секретами TURN. Секрет в репозитории или в переменной окружения CI никто не замечает, пока не случится утечка. Храните секреты в менеджере секретов с ротацией и по возможности выдавайте короткоживущие учётные данные: временные логины TURN (HMAC с ограниченным сроком жизни вместо постоянного пароля) придуманы именно для этого. Формально эти практики относятся к группам мер приказа ФСТЭК № 21: идентификация и аутентификация (ИАФ), управление доступом (УПД), защита систем связи и передачи данных (ЗИС).

Правило 4 – сегментируйте сеть на плоскости

Сегментация сети – деление инфраструктуры на зоны с контролируемыми переходами, чтобы взлом одной зоны не открывал доступ к остальным. Прямой нормы «сегментируйте» в 152-ФЗ нет: сегментация вытекает из модели угроз и мер приказа ФСТЭК № 21 по управлению доступом, защите среды виртуализации и систем связи. Для многих клиентов вопрос уже не теоретический: распоряжение Правительства от 26.02.2026 № 360-р включило информационные системы медорганизаций в перечень типовых объектов критической информационной инфраструктуры (КИИ), а об инциденте на значимом объекте КИИ нужно сообщить в НКЦКИ не позднее 3 часов (приказ ФСБ № 547).

Телемедицинский видеостек естественно делится на четыре плоскости:

• Медиа-плоскость – серверы SFU и TURN. Снаружи открыты только порты, нужные WebRTC; конфигурация усилена, обновления ставятся в срок из вашего регламента управления уязвимостями; персональных данных здесь по возможности нет. SFU расшифровывает медиа для маршрутизации, поэтому его серверы находятся внутри границы, но хранят токены, а не имена. Внутри инфраструктуры медиа-плоскость может обращаться только к конвейеру записи.
• Плоскость приложения – API, сигналинг, веб- и мобильные бэкенды. Единственная плоскость, которая обращается к ЕСИА и к провайдеру идентификации клиники; она выпускает короткоживущие токены, которым доверяют остальные.
• Плоскость данных – база, хранилище записей, транскрипты, архив журнала. Принимает соединения только от явно перечисленных сервисов плоскости приложения, публичного маршрута к ней нет. Здесь сосредоточены права доступа к KMS.
• Админ-плоскость – конвейер деплоя, бастион или шлюз удалённого доступа, консоли мониторинга. Доступна только сотрудникам со вторым фактором на управляемых устройствах. Современный подход – модель нулевого доверия, где доступ выдаётся по проверенной личности и устройству, а не по факту подключения к VPN.

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

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

Правило 5 – журнал событий как отдельный сервис

Каждая плоскость с рисунка 3 отправляет события в общий конвейер, который никто, включая ваших собственных администраторов, не может незаметно изменить. В этом и состоит правило. 152-ФЗ требует регистрации и учёта всех действий с персональными данными в информационной системе (ст. 19 ч. 2 п. 8), приказ ФСТЭК № 21 – регистрации событий безопасности (РСБ), а для электронных медицинских документов приказ 209н, по разборам, требует журналирования доступа и резервного копирования. Архитектурно это сквозной сервис. Сервисы пишут структурированные события (кто, что, когда, откуда), коллектор отправляет их в хранилище с однократной записью и hash-цепочкой, конвейер логирования работает под учётными данными, которыми рабочее приложение воспользоваться не может, а часы синхронизированы по NTP, чтобы при расследовании события SFU, API и обмена с МИС можно было выстроить в одну последовательность.

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

Правило 6 – медданных не бывает там, где им не место

Первые пять правил защищают медданные там, где им положено быть. Шестое не даёт им расползтись изнутри. В зрелых телемедицинских продуктах проверки почти никогда не находят базу, открытую в интернет; находят медданные, которые просочились в системы, никем не считавшиеся клиническими. Пути утечки настолько предсказуемы, что их можно перекрыть ещё при проектировании:

• Логи. Логгеры запросов по умолчанию пишут URL, заголовки и тела запросов, а при поиске пациентов – имена. Решение структурное: middleware, который вычищает чувствительные поля, белые списки логируемых полей, проверка логирования на код-ревью.
• Аналитика. SDK с записью сессий или автоматическим сбором событий на клиническом экране отправляет медданные вендору в первый же день, а если SDK зарубежный, это ещё и трансграничная передача спецкатегории (ст. 12) и риск нарушить требование о локализации. Решение: шлюз обезличивания из правила 1 и никаких сторонних SDK на экранах консультации.
• Push-уведомления. Текст «Готовы результаты анализа на гепатит» виден на заблокированном экране и проходит через серверы платформ за рубежом. Решение: уведомления без содержания, а само сообщение приложение загружает по TLS после аутентификации.
• Инструменты поддержки. Скриншот, вставленный в тикет, переносит имя и диагноз в хелпдеск. Решение: маскирование данных, поручение с сервисом поддержки, обучение сотрудников и ответственность за нарушения.
• Бэкапы и копии. Дамп базы на ноутбуке разработчика – незашифрованное хранилище медданных, на которое не распространяется ни одна мера защиты. Решение: бэкапы шифруются по той же схеме с KMS и хранятся в РФ, восстановление выполняется внутри границы, на тестовом стенде – только синтетические данные.

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

«Самоаудит за пять минут. Пять вопросов, которые выявляют большинство нарушений раньше проверяющего: (1) Можете ли вы назвать каждую систему, которая хранит или видит медданные, и есть ли у каждой поручение или собственная эксплуатация, а серверы – в РФ? (2) Есть ли хоть в одном URL, логе или событии аналитики идентификатор пациента? (3) Кто может расшифровать бакет с записями и регистрируется ли каждая расшифровка? (4) Если сегодня вашу офисную сеть зашифрует вымогатель, продолжатся ли консультации? (5) Сможете ли вы к вечеру выдать список всех, кто за квартал получал доступ к сессиям конкретного пациента? Каждый вопрос без ответа – задача в бэклог, по порядку важности.»

Слой 323-ФЗ: идентификация, подпись и ЕГИСЗ – тоже внутри границы

152-ФЗ отвечает на вопрос «как защищать данные». 323-ФЗ и приказ 193н добавляют в ту же схему компоненты, без которых телемедицинскую консультацию нельзя провести законно, и все они находятся внутри границы.

Идентификация через ЕСИА. Участники консультации идентифицируются через единую систему идентификации и аутентификации – «Госуслуги» (ч. 6 ст. 36.2 323-ФЗ, п. 7 193н). Архитектурно это часть плоскости приложения: только она обращается к ЕСИА. Sber ID и VK ID удобны для входа, но ЕСИА не заменяют; подробности – в статье об ЕСИА, SSO и регистрах ФРМР/ФРМО. Там же проверяется, что врач есть в ФРМР, а организация – в ФРМО (п. 9); подробно об этом – в статье о лицензии, аккредитации и рецептах.

Подпись врача. Документы консультации подписываются усиленной квалифицированной электронной подписью (УКЭП) медработника (ч. 7 ст. 36.2). Подписание выполняет отдельный сервис или клиентское средство с СКЗИ; ключ УКЭП врача не должен оказаться в вашей базе, а события подписания попадают в журнал из правила 5.

Документы и ЕГИСЗ. Материалы консультации, заключения и протоколы вносятся в электронную медкарту консультирующей организации, а сопутствующие материалы (аудио- и видеозаписи, сообщения, изображения) хранятся 1 год (193н, п. 49–51). Отдельной обязанности записывать консультации нет, но если запись сделана, её нужно хранить. Протокол телемедконсультации и запрос на неё передаются в федеральную электронную регистратуру (ФЭР) ЕГИСЗ в течение одного рабочего дня, а сведения об электронном медицинском документе – в реестр РЭМД в течение одного рабочего дня со дня его формирования. С 1 сентября 2026 года электронные медицинские документы регулирует приказ 209н: по разборам, они подписываются только УКЭП, при исправлении хранятся все версии, обязательны резервное копирование и журналирование доступа. На рисунке 1 это «мост МИС» внутри границы; варианты интеграции – в статье о HL7 FHIR, СЭМД и интеграции с МИС.

Разобранный пример: платформа на 10 000 консультаций в месяц

Проведём через паттерн реальный стек. Телемедицинский стартап проводит 10 000 видеоконсультаций в месяц (примерно 3 300 часов разговора с врачом) на собственном SFU, записывает 40% визитов, использует распознавание речи для ИИ-скрайба, интегрирован с МИС клиник и ЕГИСЗ, а на периферии у него обычный набор: аналитика, email, push, поддержка.

Сначала размещение – прямо по таблице из правила 2. Внутри границы: облачный аккаунт в аттестованном сегменте российского облака (поручение подписано, используются только сервисы аттестованного контура), обе группы медиасерверов (SFU и TURN на coturn, развёрнуты самостоятельно, работают только с токенами), плоскость приложения с входом через ЕСИА и плоскость данных с записями под конвертным шифрованием. Там же сервис распознавания речи (российский, по поручению и с удалением аудио после обработки, или on-prem), мост к МИС и ЕГИСЗ (интеграция с МИС) и конвейер журнала. Снаружи, без доступа к медданным: аналитика за шлюзом обезличивания, push без содержания, email без названия клиники. Поддержка работает по поручению, потому что скриншоты всё равно случаются.

Теперь вопрос, который задаёт каждый основатель: сколько стоит эксплуатация слоя комплаенса? Посчитаем ориентировочно, по типичным облачным тарифам; точные ставки сверяйте с прайсом своего провайдера:

• Управление ключами. Шесть мастер-ключей (база, записи, транскрипты, бэкапы, архив журнала, секреты) – порядка 85 ₽ за ключ в месяц, плюс вызовы API: 4 000 записей × 2 операции с ключами = 8 000 вызовов, ничтожная доля счёта. ≈ 600 ₽/мес.
• Неизменяемый журнал. ~60 событий на консультацию × 10 000 = 600 000 событий ≈ 0,6 ГБ/мес по ~1 КБ на событие. Хранилище с однократной записью – порядка 2 ₽ за ГБ в месяц: копейки сейчас и ≈ 85 ₽/мес даже после шести лет накопления (0,6 ГБ × 72 месяца ≈ 43 ГБ). ≈ 100 ₽/мес.
• Сетевая инфраструктура сегментации. Один NAT-шлюз, чтобы закрытые плоскости получали обновления, не открываясь наружу: порядка 2 700 ₽/мес фиксированно плюс ≈ 4 ₽/ГБ трафика, на этом масштабе возьмём ≈ 3 400 ₽/мес. Медиа консультаций через него не идёт: TURN выходит в интернет через собственный защищённый интерфейс.
• Шифрование ~1 ТБ записей в месяц: серверное шифрование хранилища, как правило, входит в цену хранения – проверьте это условие у провайдера.

Итого: 600 + 100 + 3 400 ≈ 4 100 ₽, а с запасом ≈ 4 100–8 500 ₽ в месяц на инфраструктуру паттерна. Это примерно 2–3% сверх того, что платформа и так тратит на вычисления и хранение (полный операционный бюджет – в модели стоимости). Отдельно уточните, отличается ли тариф аттестованного сегмента от обычного. Основные расходы на комплаенс – цикл проверок, регулярная работа, которую разбирает статья о требованиях к защите ПДн в 2026 году. В него входят ежегодный пентест (ориентировочно 1,3–2,6 млн ₽, то есть 110–220 тыс. ₽/мес, если распределить на год), регулярный анализ защищённости (инструменты – ориентировочно от 17 тыс. ₽/мес), оценка эффективности мер до ввода в эксплуатацию и не реже раза в три года, обновление модели угроз, внутренний контроль по ст. 18.1 и обмен пакетами документов с каждым подрядчиком. Соблюдать паттерн дёшево, а пренебрегать им дорого: утечка данных о здоровье обойдётся юрлицу в 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП). Поэтому в бюджет честно закладывают именно цикл проверок.

Порядок внедрения: как доработать существующий стек

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

1. Инвентаризация потоков данных. Две недели на то, чтобы проследить путь каждого вида медданных до каждой системы, включая логи и SDK. Результат: карта потоков, основа модели угроз.
2. Проведите границу на карте. Отметьте всё, что внутри, и отдельно – всё, что касается медданных, хотя не должно. Определите уровень защищённости по ПП 1119.
3. Распределите подрядчиков. По дереву решений получится три группы: примет поручение и хранит данные в РФ; можно «ослепить»; нужно заменить. Третья группа определяет критический путь: согласование договоров занимает недели, а замена зарубежного сервиса – месяцы.
4. Закройте пробелы в шифровании и управлении ключами. Шифрование внутри частной сети, конвертное шифрование хранилищ, KMS, перенос секретов из кода в менеджер с ротацией; СКЗИ там, где модель угроз опирается на криптографию.
5. Разделите сеть на плоскости. Разверните четыре плоскости и переносите в них сервисы с запретом по умолчанию. Медиасерверы – первыми: они доступны из интернета, и сроки установки обновлений для них самые жёсткие.
6. Запустите конвейер журнала. Сквозной коллектор, WORM-хранилище, hash-цепочка, отдельные учётные записи; загрузите туда уже накопленные логи.
7. Проверьте исходящие потоки. Пройдите по правилу 6, как по чек-листу, для каждой исходящей интеграции. Затем внесите в календарь цикл проверок (анализ защищённости, пентест, оценку эффективности, внутренний контроль) ещё до даты запуска.

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

По срокам: шаги 1–3 занимают дни и недели работы старших инженеров, шаги 4–7 – обычно от одного до трёх месяцев работы небольшой команды. Больше всего времени уходит на перестройку медиа-плоскости, если TURN и SFU раньше не изолировали. Такова реальная цена подхода «займёмся защитой потом».

Что показать проверяющему

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

Скачайте референсную архитектуру телемедицины по 152-ФЗ и 323-ФЗ (PDF) – диаграмма границы с рисунка 1 на одной странице и шесть правил паттерна в виде чек-листа рядом с ней.

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

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

Главное

• Архитектура соответствия 152-ФЗ и 323-ФЗ – паттерн: граница медданных в российской инфраструктуре плюс шесть правил.
• Каждый компонент либо свой, либо принадлежит подрядчику по поручению с серверами в РФ, либо вообще не получает медданных; хранение зашифрованных медданных – тоже обработка.
• Шифруйте каждое соединение, включая внутренние; ключи храните в KMS отдельно от данных; СКЗИ нужны там, где модель угроз опирается на криптографию.
• Разделите сеть на плоскости медиа, приложения, данных и администрирования; перечень переходов между ними – схема информационных потоков для модели угроз.
• Журнал событий – сквозной, неизменяемый, внутри границы; ЕСИА, УКЭП и мост в ЕГИСЗ – тоже внутри.
• Инфраструктура паттерна стоит ≈ 4 100–8 500 ₽/мес на 10 000 консультаций; основные расходы – цикл проверок, а не инфраструктура.

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

• Эталонная архитектура телемедицинского видео: полная картина – блок 3 накладывает эту границу на весь видеостек.
• Поручение обработки ПДн и договоры с подрядчиками – договорная сторона правила 2.
• Чек-лист готовности по 152-ФЗ и 323-ФЗ и подготовка к проверкам – итог блока: та же архитектура в виде последовательной проверки перед запуском.