Логи — это служебные журналы работы системы, и в клинике в них легко попадают телефоны, имена и поводы обращения пациентов. Но лог не предназначен для хранения персональных данных: к нему шире доступ и слабее защита, чем у основной базы. Закон о персональных данных требует минимизировать чувствительные сведения везде, включая технические журналы. Маскирование скрывает данные в логах, оставляя их полезными для отладки. Разбираем, как это работает и что требует 152-ФЗ.
Маскирование персональных данных в логах — это скрытие телефонов, имён и адресов в технических журналах системы так, чтобы по записи нельзя было опознать пациента. Вместо реального номера в лог попадает частично закрытое значение или хэш. Закон о персональных данных требует минимизировать хранение чувствительных сведений везде, включая служебные логи.
Логи нужны, чтобы находить сбои и понимать, что произошло, а не чтобы держать под рукой контакты пациентов. Как только в журнал попадают персональные данные, он превращается в дополнительную копию базы — со своими рисками.
Маскирование решает противоречие между пользой логов и требованием минимизации: инженер видит структуру события, но не видит, кому оно принадлежит.
Логи создаются для отладки и мониторинга, а не для хранения персональных данных, поэтому телефоны и ФИО в них — лишний риск. К журналам обращаются разработчики, администраторы серверов, системы мониторинга — круг шире, чем к самой базе. Открытый номер в логе утекает так же легко, как из базы, но защищён обычно слабее.
Основная база обычно шифруется и закрыта правами доступа, а логи нередко лежат обычными текстовыми файлами, которые проще скопировать и переслать. Именно эта асимметрия защиты делает открытые данные в журналах особенно опасными.
Закон о персональных данных не делает исключения для служебных журналов — телефон в логе защищается так же, как в карточке (152-ФЗ на consultant.ru).
Маскирование — это замена чувствительного значения на безопасное представление, по которому нельзя восстановить оригинал или сопоставить с человеком. Телефон превращается в +7***45, имя — в первую букву, номер карты — в хэш. Смысл в том, что лог остаётся полезным для диагностики, но перестаёт быть прямым носителем персональных данных.
Хорошее маскирование обратимо только для того, у кого есть ключ или доступ к справочнику соответствий, и необратимо для всех остальных. Для отладки этого достаточно: инженеру важна структура событий, а не личность.
Способ маскирования выбирают под задачу: где-то хватает частичного сокрытия, где-то нужен необратимый хэш или токен.
Частичное маскирование оставляет часть значения видимой для отладки, а остальное скрывает: +7 999 ***-**-45 позволяет отличить один номер от другого, не раскрывая его целиком. Обычно открытыми держат код и последние 2 цифры. Этого хватает инженеру, чтобы связать события в логе, но недостаточно, чтобы позвонить пациенту.
Частичное сокрытие — компромисс между удобством и защитой. Оно оставляет ровно столько, чтобы отличать записи, но недостаточно, чтобы использовать данные не по назначению.
Важно закрывать не только телефон, но и имя, адрес, номер полиса в тех же строках — иначе маскирование дырявое.
Хэширование превращает значение в строку фиксированной длины, из которой нельзя вычислить исходный телефон, но одинаковые номера дают одинаковый хэш. Это удобно, когда нужно понять, что события относятся к одному человеку, не зная кто это. Для защиты от перебора к значению добавляют секретную соль, иначе короткий номер подбирается за секунды.
Хэш незаменим, когда нужно связать события одного человека в аналитике, не храня его телефон. Одинаковый вход даёт одинаковый выход, поэтому корреляция работает без раскрытия.
Соль критична: без неё телефон из 10 цифр перебирается очень быстро, и хэш перестаёт защищать. С солью обратный подбор становится непрактичным.
Технические логи и медицинские данные должны жить раздельно: журнал работает с событиями системы, а диагнозы и назначения остаются в защищённой базе. В лог не должны попадать ни жалобы, ни заключения, ни результаты обследований. Если инженеру нужна отладка, ему достаточно идентификатора события, а не содержимого медицинской карты пациента.
Смешивать журналы отладки и медицинское содержание — плохая идея: у них разные цели, разный круг доступа и разные сроки хранения. Разделение упрощает и защиту, и соблюдение требований.
Кто именно должен иметь доступ к медицинской части данных, разобрано в материале про права доступа к медданным в CRM.
Голосовой робот тоже пишет логи: транскрипты разговоров, распознанные реплики, результаты звонков. Эти записи содержат имя, телефон и повод обращения, поэтому в служебных журналах они маскируются так же, как остальные персональные данные. Полная расшифровка хранится отдельно, в защищённом контуре, с ограниченным доступом, а не в общем логе приложения.
Расшифровки полезны для качества и продаж, но это чувствительные данные, поэтому доступ к полным транскриптам дают по праву, а в служебные логи они не попадают открытыми.
Как безопасно работать с расшифровками для пользы бизнеса, показано в материале про поиск по расшифровкам звонков.
Токенизация заменяет реальное значение на случайный токен, а связь «токен — оригинал» хранится в отдельном защищённом справочнике. В логах и аналитике фигурирует только токен, по которому нельзя узнать пациента без доступа к справочнику. Это удобно, когда данные нужно передавать между системами, не раскрывая сами телефоны и имена.
Токенизация особенно полезна в интеграциях: во внешнюю систему уходит токен, а реальный телефон остаётся в защищённом контуре клиники. Утечка токенов без справочника бесполезна для злоумышленника.
Справочник соответствий — самое чувствительное место схемы, поэтому его защищают строже всего и хранят отдельно от логов.
Технические логи не должны храниться вечно: чем дольше журнал лежит, тем дольше в нём живут остатки персональных данных. Разумная практика — держать оперативные логи от 7 до 30 дней, а затем удалять или архивировать в обезличенном виде. Срок хранения фиксируют в политике и соблюдают автоматически, а не вручную.
Долго живущие логи накапливают данные, о которых все забыли: старый журнал за прошлый год с открытыми телефонами — типичная находка при аудите.
Автоматическое удаление по расписанию надёжнее ручного: человек забывает, а политика хранения — нет.
Доступ к логам ограничивают так же строго, как к базе: журналы видят только те, кому это нужно для эксплуатации системы. Каждый доступ протоколируется, а сами логи хранятся в защищённом месте, а не в открытой папке на сервере. Чем уже круг лиц с доступом, тем меньше вероятность утечки через журналы.
Логи стоит хранить в защищённом хранилище с ограниченными правами, а не в папке, куда есть доступ у половины команды. Каждое обращение к журналам полезно фиксировать.
Принцип тот же, что и для базы: доступ по необходимости, а не по умолчанию всем.
Когда логи уходят в системы аналитики или мониторинга, персональные данные должны быть замаскированы ещё до отправки. Внешний сервис получает обезличенный поток: коды событий, длительности, статусы — без телефонов и имён. Маскирование на выходе важнее, чем внутри, потому что данные покидают контур клиники и попадают к третьей стороне.
Передача сырых логов во внешнюю аналитику без маскирования — частый и незаметный канал утечки, потому что данные уходят к третьей стороне под видом технической телеметрии.
Правильный подход — маскировать на выходе из контура: наружу идут только обезличенные события.
Закон о персональных данных распространяется и на логи: если журнал содержит телефон или имя, это обработка персональных данных со всеми обязанностями. Требуются законное основание, минимизация объёма и защита от несанкционированного доступа. Маскирование и короткий срок хранения — практический способ снизить объём обрабатываемых данных в служебных журналах до минимума.
Формально телефон в логе — такой же объект защиты, как телефон в карточке, поэтому все обязанности оператора распространяются и на журналы.
Юридические тонкости обработки данных в звонках разобраны в материале про 152-ФЗ и голосовые боты.
Утечки через логи происходят буднично: журнал с открытыми телефонами попадает в общий доступ, копируется на ноутбук инженера или уходит в облачный сервис мониторинга без маскирования. По разным оценкам, заметная доля инцидентов связана именно со служебными данными, а не с основной базой. Логи — недооценённый канал утечки.
Опасность логов в их незаметности: их редко воспринимают как хранилище персональных данных, поэтому защищают по остаточному принципу. По разным оценкам, до 30% утечек связаны с внутренними каналами вроде логов и выгрузок, а не с внешним взломом.
Каждый маршрут, по которому лог покидает сервер — копия на ноутбук, выгрузка в облако, пересылка коллеге — потенциальная утечка, если данные не замаскированы.
Проверка простая: откройте свежий журнал и поищите в нём телефоны, ФИО, адреса и номера документов. Если они видны открытым текстом — маскирование не работает. Отдельно проверьте логи голосового робота, вебхуков и интеграций: именно там персональные данные утекают чаще всего, потому что о них забывают при настройке маскирования.
Проверять стоит регулярно, а не однократно: новые интеграции и фичи добавляют новые логи, и маскирование про них легко забыть.
Особое внимание — логам ошибок: в стек-трейсы и дампы часто попадают полные данные запроса, включая телефон и имя.
Частые ошибки — маскировать телефон, но забыть про имя в соседнем поле, хэшировать без соли, оставлять полные данные в логах ошибок и стек-трейсах. Ещё одна беда — маскировать в приложении, но писать сырой запрос в лог базы. Маскирование работает, только если охватывает все точки, где значение попадает в журнал.
Маскирование в одной точке при открытых данных в другой не защищает — злоумышленнику достаточно одного открытого места. Схема должна быть сплошной.
Регулярный аудит логов — такая же гигиена, как обновление паролей: проводить его стоит не реже чем раз в 3 месяца, иначе маскирование деградирует по мере роста системы.
Начните с инвентаризации: какие журналы пишет система и что в них попадает. Найдите поля с телефонами, именами и медицинскими сведениями и настройте маскирование в точке записи. Задайте срок хранения, ограничьте доступ и проверьте логи интеграций. У Stexa персональные данные в логах маскируются, а сами данные хранятся в России.
Начать проще, чем кажется: закрыть очевидные поля с телефонами и именами, задать срок хранения и ограничить доступ уже снимает большую часть риска.
Дальше — регулярная ревизия при каждой новой интеграции, чтобы новые логи сразу писались замаскированными.
7 дней бесплатно, без карты. Подключение к вашему номеру за 15 минут.