Журналы аудита и контроль доступа для клинического видео

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

Кратко

Российское требование к журналам и доступу умещается в одну фразу 152-ФЗ: оператор устанавливает правила доступа к персональным данным и обеспечивает регистрацию и учёт всех действий с ними (ст. 19 ч. 2 п. 8). Ни событий, ни полей, ни формата, ни срока хранения журнала закон не называет. Конкретика – в подзаконных актах: меры приказа ФСТЭК № 21 по идентификации и аутентификации (ИАФ), управлению доступом (УПД) и регистрации событий безопасности (РСБ), требования ПП 1119 к журналу для уровней защищённости УЗ-2 и УЗ-1, журналирование доступа к электронным медицинским документам по приказу Минздрава 209н, обязательная идентификация участников консультации через ЕСИА и подпись врача УКЭП (ст. 36.2 323-ФЗ, приказ 193н). С телемедицинским видео этих правил приходится выполнять больше: одна консультация порождает события в зале ожидания, в самом звонке, в конвейере записи, в транскрипте и при передаче документов в МИС, а сам журнал становится хранилищем медданных. Без журнала не выполнить даже базовую обязанность после утечки – за 72 часа сообщить Роскомнадзору итоги расследования и сведения о виновных. Поэтому цикл должен быть замкнутым: доступ по ролям, вход только под личной учётной записью, запись событий без возможности правки и разбор по графику, который можно показать проверяющему.

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

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

Журнал посетителей, или две половины задачи

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

152-ФЗ «О персональных данных» закрепляет оба механизма в одном пункте: среди обязательных мер защиты он называет установление правил доступа к персональным данным в информационной системе и обеспечение регистрации и учёта всех действий, совершаемых с ними (ст. 19 ч. 2 п. 8). Сведения о здоровье – специальная категория персональных данных (ст. 10), а сам факт обращения за медицинской помощью – врачебная тайна (ст. 13 323-ФЗ). Общие требования обоих законов разобраны в статье 152-ФЗ и врачебная тайна простым языком для продуктовых команд. Здесь речь об одной паре мер – той, от которой зависит, ответите ли вы на главный вопрос после инцидента: кто, что и когда сделал.

В телемедицине ответить на него сложнее, чем в любой другой медицинской системе. Видеоконсультация – не одна строка в одной базе, а допуск из зала ожидания, звонок с двумя и более участниками в разных ролях, запись и транскрипт (если их ведут), чат, переданные файлы и обратная передача данных в медицинскую информационную систему (МИС) и электронную медицинскую карту (ЭМК). Каждый шаг – событие доступа, которое может понадобиться восстановить: по жалобе пациента, при расследовании утечки, в суде или на проверке Роскомнадзора. Если проектировать журналирование после запуска, окажется, что самые важные события так и не попали в журнал.

Что требуют нормы: четыре обязанности

Требования сводятся к четырём обязанностям, остальное в статье – инженерные решения для них. Меры для каждой берутся из приказа ФСТЭК № 21: базовый набор для вашего уровня защищённости, который затем адаптируют, уточняют под актуальные угрозы и дополняют (п. 9). Заменить меру можно только компенсирующей, обосновав это при разработке системы защиты (п. 10).

Обязанность 1 – контролировать доступ (152-ФЗ ст. 19 ч. 2 п. 8; приказ ФСТЭК № 21, группа УПД). Закон требует правил доступа, а приказ раскладывает их на конкретные меры: управление учётными записями – заведение, активация, блокирование и уничтожение (УПД.1); разделение полномочий (ролей) пользователей, администраторов и тех, кто обеспечивает работу системы (УПД.4); назначение минимально необходимых прав и привилегий (УПД.5); ограничение неуспешных попыток входа (УПД.6); блокирование сеанса после установленного времени бездействия (УПД.10). Общих логинов быть не должно: запись в журнале вида clinic-cart-3 указывает на тележку с компьютером, а не на человека. Шифрованию посвящена отдельная статья о шифровании, ГОСТ и СКЗИ.

Обязанность 2 – проверять личность (приказ № 21, группа ИАФ; ст. 36.2 323-ФЗ). Права доступа ничего не стоят, если любой может войти под чужим именем. Приказ требует идентифицировать и аутентифицировать работников оператора (ИАФ.1) и внешних пользователей – в телемедицине это пациенты (ИАФ.6), управлять идентификаторами и средствами аутентификации (ИАФ.3, ИАФ.4) и защищать обратную связь при вводе пароля (ИАФ.5). У телемедицины есть и отраслевые требования: участники консультации идентифицируются через ЕСИА (ч. 6 ст. 36.2, п. 7 193н), врач должен быть в регистре медработников ФРМР (п. 9 193н), а документы оформляются с усиленной квалифицированной электронной подписью (УКЭП) медработника (ч. 7 ст. 36.2). Число факторов приказ № 21 не задаёт, но второй фактор для персонала и администраторов – стандарт де-факто, и мы рекомендуем включать его сразу. Сценарии идентификации разобраны в статьях Кто в кабинете: роли, идентификация и согласие и Идентификация через ЕСИА, SSO и регистры ФРМР/ФРМО.

Обязанность 3 – записывать действия (ст. 19 ч. 2 п. 8; приказ № 21, группа РСБ). Закон говорит о регистрации и учёте всех действий, совершаемых с персональными данными в информационной системе. Приказ раскладывает это на семь мер: определить события, подлежащие регистрации, и сроки их хранения (РСБ.1); определить состав и содержание информации о событиях (РСБ.2); собирать, записывать и хранить её в течение установленного срока (РСБ.3); реагировать на сбои регистрации (РСБ.4); вести мониторинг – просмотр и анализ – и реагировать на его результаты (РСБ.5); генерировать временные метки и синхронизировать время (РСБ.6); защищать информацию о событиях (РСБ.7). Требования сознательно не привязаны к технологиям: ни списка событий, ни схемы полей, ни формата. Лазейкой это не считается: решать, что именно записывать, приказ оставляет вам – в модели угроз и в документе по РСБ.1. Если в журнале нет скачиваний записей, довод «в приказе не было списка» проверяющий не примет.

Обязанность 4 – разбирать записанное (РСБ.5; ст. 19 ч. 2 п. 6 и 9; ст. 18.1). Закон требует обнаруживать факты несанкционированного доступа и реагировать на компьютерные инциденты (ст. 19 ч. 2 п. 6), контролировать принятые меры (п. 9) и вести внутренний контроль (ст. 18.1). ПП 1119 добавляет контроль выполнения требований не реже раза в три года (п. 17), приказ № 21 – оценку эффективности мер с той же периодичностью (п. 6). Журнал, который никто не разбирает, соответствия не обеспечивает – он лишь копит улики против вас самих.

Эти четыре обязанности дополняют ещё две группы норм. Минимизация: объём обрабатываемых данных не должен быть избыточным по отношению к целям (ст. 5 152-ФЗ), а тем, кто узнал врачебную тайну по работе, разглашать её запрещено (ст. 13 ч. 2 323-ФЗ). Для инженеров это означает ролевую модель доступа. Требования к журналу по уровням защищённости из ПП 1119: уже на УЗ-4 – утверждённый перечень лиц, допущенных к данным (п. 13); на УЗ-2 – доступ к содержанию электронного журнала сообщений только у тех, кому он нужен для работы (п. 15); на УЗ-1 – автоматическая регистрация в электронном журнале безопасности изменения полномочий сотрудников (п. 16 «а»).

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

Откуда берётся конкретика, раз закон её не называет

Пробелы ст. 19 восполняют несколько источников – перечислим их по убыванию обязательности.

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

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

Международный словарь полей. Схемы аудит-события нет ни в одном российском акте, зато она есть в международном стандарте обмена медицинскими данными HL7 FHIR. Ресурс AuditEvent описывает, кто действовал (агент), что сделал (действие и его тип), когда, откуда (источник и сетевой адрес), с каким объектом (пациент, документ, сессия) и с каким результатом. Когда специалист по безопасности клиники или интегратор спросит, что лежит в ваших событиях, он будет ждать ответа именно в этих терминах. Есть и российский ориентир по полям: требования Роскомнадзора к подтверждению уничтожения персональных данных (приказ № 179) признают доказательством выгрузку из журнала регистрации событий. В ней должны быть сведения, позволяющие идентифицировать субъекта, перечень категорий уничтоженных данных, название информационной системы, причина и дата уничтожения. Если в журнале этих полей нет, их придётся вписывать в акт вручную.

Ваша модель угроз юридически определяет охват мер (ст. 19 ч. 2 п. 1). В ней вы фиксируете, какие системы работают с медданными, в том числе те, о которых телемедицинские команды часто забывают: SFU (selective forwarding unit – медиасервер, маршрутизирующий потоки звонка), конвейер записи, сервис транскрибации, инструменты поддержки с входом «от имени пользователя». Если система видит медданные, её действия должны попадать в журнал.

Таксономия аудит-событий телемедицины: что обязана фиксировать платформа клинического видео

Общие статьи про 152-ФЗ советуют «регистрировать действия с персональными данными». Чтобы журнал клинического видео был полезен, нужно пройти весь жизненный цикл консультации и назвать события на каждом этапе. С этого списка стоит начинать любой телемедицинский продукт. На нём построен чек-лист для скачивания в конце статьи, и он же – готовый ответ на вопрос РСБ.1 «какие события регистрируем».

Вход и учётные записи. Успешные и неудачные входы (с методом: пароль, ЕСИА, SSO, второй фактор), привязка и сброс второго фактора, смена пароля, создание учётной записи, назначение и смена роли, выдача прав, решения при пересмотре доступа, блокирование и, что особенно важно, каждый вход сотрудника поддержки «от имени пользователя». Неудачные входы важны не меньше успешных: их ограничение – отдельная мера УПД.6, а всплеск отказов – первый признак подбора пароля.

Расписание и подготовка к приёму. Приём создан, перенесён, отменён; анкета открыта или отредактирована; полис ДМС или документ, удостоверяющий личность, загружен и просмотрен. Сам факт, что человек записан к психиатру, уже составляет врачебную тайну, так что доступ к расписанию – это доступ к медданным.

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

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

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

Клинические данные. Медкарта открыта во время консультации; заключение или протокол создан, исправлен, подписан УКЭП; ЭМД зарегистрирован в РЭМД (сведения о документе передаются туда в течение одного рабочего дня, и журнал должен подтвердить, что передача состоялась); сформирован рецепт; назначен анализ; выполнена синхронизация с МИС (что передано, куда, под какой интеграционной учётной записью).

Администрирование платформы. Изменения конфигурации (настройки записи по умолчанию, сроки хранения, тексты согласий), смена подрядчика, затрагивающая цепочку поручений, настройки шифрования, изменения конфигурации самого журнала и сбои регистрации (отдельная мера РСБ.4), выгрузки данных, массовые отчёты, использование экстренного доступа.

Так выглядит правильно устроенное аудит-событие. Обратите внимание: оно ссылается на медданные, но не содержит их.

{
  "event_id": "evt_8f2c41d0",
  "timestamp": "2026-06-11T14:32:07.412Z",
  "event_type": "recording.downloaded",
  "actor": { "user_id": "u_5102", "role": "provider", "auth_method": "sso+otp" },
  "patient_ref": "pt_88421",
  "resource": { "type": "recording", "id": "rec_3377", "session_id": "ses_9120" },
  "context": { "ip": "203.0.113.40", "user_agent": "Chrome/126", "reason": null },
  "outcome": "success",
  "prev_event_hash": "sha256:9b1f..."
}

«Классическая ошибка: медданные в журналах. Инженер журналирует то, что под рукой, а под рукой в телемедицине диагноз, сообщение чата, подписанная ссылка на запись. Записывайте в журнал ссылки на данные, а не сами данные: идентификаторы пациентов и ресурсов вместо ФИО, типы событий вместо текста сообщений, ID ресурсов вместо подписанных ссылок, которые откроют запись любому, кто читает журнал. И учтите следствие: даже журнал из одних идентификаторов связывает конкретных людей с клиническими событиями, а значит, аудит-журнал сам содержит медданные. Его нужно шифровать, хранить в России, открывать только тем, кому он нужен по работе (для УЗ-2 и выше этого прямо требует п. 15 ПП 1119), оформлять с подрядчиком журнала поручение на обработку, а обращения к самому журналу тоже записывать (РСБ.7).»

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

Контроль доступа на практике: роли, минимизация и экстренный доступ

Минимизация и врачебная тайна на практике сводятся к одному документу – матрице «роль × право». Определите роли, которые реально есть в продукте, и дайте каждой минимальный объём медданных, нужный для работы. Матрица ниже – отправная точка из наших телемедицинских проектов; под вашу специализацию её придётся доработать.

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

Привязывайте доступ не только к роли, но и к лечебному отношению. Ролевая модель доступа (role-based access control, RBAC), где права назначены ролям, а роли – людям, – это основа, и именно её описывают меры УПД.4 и УПД.5: разделение ролей и минимально необходимые права. Но роль «врач» не должна означать «может открыть медкарту любого пациента». Рабочее правило – роль плюс отношение: врач видит тех пациентов, которых лечит. Чистый RBAC этого не выражает, поверх него нужна атрибутная модель доступа (attribute-based access control, ABAC), где атрибутом служит активное лечебное отношение, назначенная сессия или открытый случай обслуживания. Нагляднее всего это на переводчиках: их доступ должен быть ограничен сессией – выдаваться при допуске в консультацию и истекать вместе с ней, чтобы потом нечего было отзывать.

Поддержке – временный доступ с указанием причины, а не постоянный. Инженер поддержки, который может открыть любую сессию «для отладки», – самое частое нарушение минимизации в телемедицинских продуктах. Схема, которая выдерживает проверки: доступ поддержки выдаётся под номер тикета и с указанием причины на фиксированный срок (30–60 минут), записывается как вход «от имени пользователя» и отправляет уведомление роли безопасности. Именно постоянный административный доступ позволяет одной учётной записи, украденной фишингом, обернуться утечкой масштаба всей компании. А инженер поддержки, увидевший имя пациента, – лицо, которому врачебная тайна стала известна при исполнении обязанностей (ст. 13 ч. 2 323-ФЗ), поэтому обязательство о неразглашении – условие его допуска.

Продумайте экстренный доступ заранее. Отдельной процедуры экстренного доступа (break-glass, «разбить стекло») закон не предусматривает, но без неё в клинике не обойтись: дежурному врачу ночью нужна медкарта пациента в критическом состоянии, а экстренную телемедицинскую консультацию 193н требует провести в срок от 30 минут до 2 часов (п. 19). Общий «экстренный» аккаунт – неверное решение: он лишает смысла уникальную идентификацию (ИАФ.1, ИАФ.3). Верное: любой аутентифицированный врач может запросить экстренный доступ к данным конкретного пациента, обязательно указав причину текстом; событие сразу поднимает по тревоге роль безопасности; каждое использование break-glass разбирает человек в течение одного рабочего дня. Тихий break-glass неотличим от взлома, а громкий сам служит защитой.

Остальные механизмы приказ называет прямо. Блокирование сеанса при бездействии (УПД.10) настраивайте по типу рабочего места: общий компьютер на посту – 2–5 минут простоя, личное устройство – 15. Второй фактор включите уже сейчас для всех рабочих учётных записей персонала и администраторов. Увольнение свяжите с вашим провайдером идентификации, чтобы блокирование учётной записи (УПД.1) и уничтожение идентификатора (ИАФ.3) происходили в последний рабочий день. Учётная запись уволенного сотрудника, которая месяцами остаётся активной, – классический случай, который трудно объяснить: журнал покажет, что вход был, но не объяснит, почему он был возможен. На УЗ-1 каждое изменение полномочий должно к тому же автоматически попадать в журнал безопасности (п. 16 «а» ПП 1119).

Неизменяемость и сроки хранения: журнал, который можно править, – не доказательство

Аудит-журнал чего-то стоит, только если его не может переписать никто: ни ваши администраторы, ни злоумышленник с их правами. Приказ № 21 выделяет защиту информации о событиях безопасности в отдельную меру (РСБ.7). Журнал одновременно хранит медданные и доказывает всё остальное, поэтому его целостность нужно защищать строже всего в системе.

Инженерное решение состоит из четырёх частей. Хранилище с однократной записью. Отправляйте пакеты событий в S3-совместимое объектное хранилище с блокировкой версий объектов – в режиме WORM (write once, read many: записать один раз, читать многократно). Например, в Yandex Object Storage строгую блокировку (compliance-mode) до окончания срока нельзя обойти, сократить или снять, администратор может только продлить срок; такой же режим Object Lock есть в open-source MinIO для собственной инфраструктуры. У других провайдеров уточняйте, есть ли такой режим и входит ли сервис в аттестованный сегмент. Цепочка хэшей. Каждое событие содержит хэш предыдущего (поле prev_event_hash выше), поэтому удаление или правка любой записи заметно разрывает цепочку – на той же идее держится защита бухгалтерской книги от подчисток. Отдельный домен безопасности. Конвейер журналирования работает под учётными данными, к которым у продакшен-приложения нет доступа: наблюдаемые системы не должны иметь возможности заглушить наблюдателя. Синхронизированное время. Каждый сервис ставит метки времени по NTP (это прямо мера РСБ.6): если расследование не может выстроить по порядку события SFU, API и синхронизации с МИС, оно не установит, что произошло.

Теперь о сроках – о них часто спорят, поэтому скажем прямо: конкретного срока хранения журнала регистрации событий ни 152-ФЗ, ни ПП 1119, ни приказ ФСТЭК № 21 не называют. Приказ требует определить сроки (РСБ.1) и хранить информацию в течение установленного времени (РСБ.3), то есть срок выбираете вы сами – письменно и с обоснованием. Единственная прямая цифра, касающаяся журнала, взята из другой области: акт об уничтожении персональных данных и выгрузку из журнала регистрации событий, подтверждающие уничтожение, хранят 3 года с момента уничтожения (приказ Роскомнадзора № 179). Остальное – инженерные доводы, то есть наши рекомендации, а не норма. Контроль выполнения требований и оценку эффективности мер проводят не реже раза в три года (п. 17 ПП 1119, п. 6 приказа № 21). Проверяющему нужна история за этот период, так что журнал событий безопасности разумно хранить не меньше трёх лет. Журнал доступа к ЭМД логично хранить не меньше самого документа: по 209н срок хранения ЭМД не меньше срока бумажного аналога и задан по видам документов в федеральном справочнике НСИ. А события, связанные с записью консультации, должны храниться дольше самой записи, которую по 193н хранят как сопутствующий материал 1 год (п. 49–51): кто её смотрел и когда её удалили, вы должны уметь показать и после удаления. Зафиксируйте выбранные сроки в документе по РСБ.1 – его попросят первым.

Какой бы срок вы ни выбрали, экономить на хранении журнала бессмысленно. Посчитаем. Платформа среднего размера проводит 200 консультаций в день, каждая порождает около 40 аудит-событий примерно по 1 КБ: 200 × 40 × 1 КБ = 8 МБ в день, около 2,9 ГБ в год. История за десять лет с полным поиском – примерно 29 ГБ. При ориентировочной цене стандартного объектного хранилища около 2 ₽ за ГБ в месяц (сверяйте с прайсом провайдера и тарифом аттестованного сегмента) это 29 × 2 ≈ 58 ₽ в месяц, дешевле чашки кофе, за данные, от которых зависит, удастся ли восстановить картину инцидента. Оправдать урезанные журналы нечем. Настоящие расходы – в следующем разделе.

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

Цикл разбора: что значит «регулярно разбирать» и сколько стоит это пропустить

Во что обходится журнал, в который никто не смотрит, лучше всего видно после утечки. Ст. 21 ч. 3.1 152-ФЗ даёт оператору 24 часа на первичное уведомление Роскомнадзора с предполагаемыми причинами и вредом и 72 часа на результаты внутреннего расследования и сведения о виновных. Отсчёт идёт с момента выявления, в том числе сторонним лицом. Каждый пункт этого отчёта – запрос к журналу: откуда был доступ, какие записи затронуты, чьими учётными данными воспользовались. Если в журнал полгода никто не заглядывал, 72 часа уйдут на гадание.

Теперь о штрафах. Утечка специальных категорий данных, включая данные о здоровье, обойдётся юрлицу в 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), повторная – в 1–3% выручки, но не менее 25 млн и не более 500 млн ₽ (ч. 18). За неуведомление Роскомнадзора – ещё 1–3 млн ₽ (ч. 11). Если система медорганизации – значимый объект критической информационной инфраструктуры (КИИ), об инциденте сообщают в НКЦКИ не позднее 3 часов (приказ ФСБ № 547). За три часа не успеть «поднять логи и посмотреть» – можно только прочитать сработавший алерт.

Числового определения слова «регулярно» в законе нет. Значит, задайте периодичность сами, письменно и такую, которую сможете выдерживать, и сохраняйте подтверждения, что разборы действительно проходят. Базовый график для телемедицины:

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

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

Что меняется: проект замены приказа № 21, приказ № 117 и КИИ

Нормы, на которых построена статья, долго не менялись: ПП 1119 действует с 2012 года, приказ № 21 – с 2013-го. Но 24 июля 2026 года ФСТЭК опубликовала проект нового приказа о мерах защиты персональных данных (regulation.gov.ru, ID 169583). По данным отраслевых обзоров, на 24 сентября 2026 года он не подписан, так что, прежде чем опираться на любое его положение, проверьте статус. Все изменения разобраны в статье о требованиях к защите ПДн в 2026 году. К теме этой статьи прямо относятся такие положения:

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

Для государственных клиник уже действует приказ ФСТЭК № 117: риск-ориентированный выбор мер, показатели защищённости и зрелости, классы К1–К3; ранее выданные аттестаты сохраняют силу. Кроме того, здравоохранение – сфера КИИ: распоряжение Правительства № 360-р от 26 февраля 2026 года включило в перечень типовых отраслевых объектов информационные системы медорганизаций, лабораторные системы и сегменты ЕГИСЗ.

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

Где хранить журналы: российский контур и поручение

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

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

«Типичные ошибки. Общие логины на тележках и в регистратуре (уникальной идентификации больше нет). Тексты чатов, диагнозы и подписанные ссылки в строках журнала (медданные в логах). Продакшен-приложение с правами на запись в конвейер журнала (наблюдаемый может заглушить наблюдателя). Скачивания записей не журналируются, потому что «туда заходят только сотрудники». Поддержка с постоянным правом смотреть любые сессии. Логи уходят в зарубежный сервис аналитики или отслеживания ошибок. Срок хранения «по умолчанию» – 30 дней, о которых узнают во время расследования. Нет документа по РСБ.1 с перечнем событий и сроков. Break-glass, который никто не разбирает. Разборы, которые проводятся, но не оставляют следа: чего нет на бумаге, того для проверяющего не существует. Полный список – в статье Частые ошибки в защите медданных при разработке телемед-продуктов.»

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

Фора Софт разрабатывает видеопродукты с 2005 года: телемедицина, видеоконференции, стриминг, видеонаблюдение, e-learning. Аудит-журналы мы проектируем до первого спринта: если достраивать таксономию событий к уже выпущенному продукту, самая важная история так и останется незаписанной. В наших телемедицинских проектах решения из этой статьи работают по умолчанию: доступ по модели «роль плюс отношение», роли в рамках сессии для переводчиков и наблюдателей, доступ поддержки с ограничением по времени и указанием причины, конвейеры событий только на добавление с WORM-хранилищем в российской инфраструктуре и панели разбора, благодаря которым мера РСБ.5 из строчки в локальном акте превращается в еженедельную привычку. Если вы проектируете платформу или заполняете анкету безопасности клиники и видите в ней пробелы, поговорите с нашей телемедицинской командой.

Главное

• 152-ФЗ одной фразой требует правил доступа и учёта всех действий с ПДн (ст. 19 ч. 2 п. 8). Состав мер задаёт приказ ФСТЭК № 21 (ИАФ, УПД, РСБ), а охват – ваша модель угроз, и видео в него входит.
• Контроль доступа и аудит неразделимы, как считыватель пропусков и журнал посетителей. Оба держатся на уникальной идентификации: участники консультации входят через ЕСИА, врач подписывает документы УКЭП.
• Журналируйте весь цикл консультации (зал ожидания, входы, доступ к записям, транскрипт, МИС и РЭМД) ссылками на медданные, но не самими данными.
• Аудит-журнал сам содержит медданные: шифруйте его, храните в России, ограничивайте доступ, оформляйте поручение подрядчику и журналируйте доступ к нему.
• Срока хранения журнала закон не называет, его определяет оператор (РСБ.1); подтверждение уничтожения ПДн хранят 3 года, а само хранение журнала стоит копейки.
• Если журналы не разбирать, 72 часа на расследование уйдут на гадание. Планируйте разборы, документируйте их и настройте тревогу на каждый break-glass.

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

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