Психотерапевт ведёт заметки о клиентах: своя база вместо чужого сервиса

MAATRIX

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

Почему заметки терапевта — это особая категория данных

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

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

Где решение «одно удобное приложение» даёт трещину

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

• Синхронизация в неизвестный дата-центр. Вы не выбираете, в какой стране физически лежат ваши записи, и не всегда можете это узнать.
• Условия использования разрешают анализ контента. Формулировки вроде «для улучшения сервиса» или «для работы функций ИИ» на практике означают, что текст могут читать автоматические системы, а иногда и люди — например, в рамках модерации или поддержки.
• Утечка у провайдера — это не утечка одного человека. Если базу данных сервиса взломают, в дамп попадут заметки сразу тысяч специалистов и десятков тысяч их клиентов одновременно. Это резко повышает интерес атакующих и цену инцидента.
• Право на удаление — не то же самое, что удаление. Даже если вы стёрли заметку, она может оставаться в бэкапах провайдера ещё долго, и проверить это со стороны невозможно.
• Сервис может закрыться, сменить владельца или политику — и тогда вопрос, что происходит с данными клиентов, решает не терапевт, а корпоративный юрист компании.
• Автоматическая синхронизация «незаметно» тянет данные и на личные устройства — если у вас установлено приложение на общем семейном компьютере или на телефоне без пароля, риск возрастает без вашего явного решения.

Ни один из этих пунктов не означает, что конкретный сервис поступает недобросовестно. Это просто следствие того, что вы отдаёте контроль над крайне чувствительными данными третьей стороне, чья бизнес-модель не строилась вокруг вашей профессиональной ответственности.

Что даёт перенос заметок на свой сервер

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

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

Как устроена приватная база заметок

Рабочая схема опирается на четыре простых принципа, без экзотики:

1. Данные лежат в зашифрованном виде на диске сервера. Даже если кто-то получит физический или административный доступ к диску, без ключа он видит только нечитаемый набор байт.
2. Сервер не принимает подключения из открытого интернета. Единственный способ достучаться до заметок — поднять зашифрованный VPN-туннель с вашего устройства.
3. Заметки — обычные текстовые файлы, организованные в папки, а не запись в закрытой базе проприетарного формата. Это даёт мгновенный полнотекстовый поиск и полную переносимость: вы всегда можете забрать архив на другой сервер за пять минут.
4. Клиенты обозначены кодами, а не именами. Отдельная, ещё более защищённая таблица соответствий «код → имя» хранится отдельно от содержания сессий — так утечка одной части архива без другой почти бесполезна для постороннего.

Структура каталогов может выглядеть так:

/srv/notes/
├── clients/
│   ├── c-0142/
│   │   ├── 2026-08-05.md
│   │   ├── 2026-08-19.md
│   │   └── intake.md
│   ├── c-0143/
│   │   └── 2026-08-12.md
│   └── ...
└── index/
    └── mapping.md.enc   # отдельно зашифрованная таблица код → клиент

Поиск по всему архиву при такой структуре — это одна команда через SSH:

grep -ril "панические атаки" /srv/notes/clients/

Она находит все файлы, где встречается нужная формулировка, за доли секунды, даже если заметок накопилось несколько тысяч.

Пошаговая настройка сервера

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

1. Арендуйте VPS. Для этой задачи не нужны большие мощности — достаточно младшей конфигурации с SSD-диском. Юрисдикция размещения имеет значение: если ваши клиенты находятся в России, часть их персональных данных подпадает под требования 152-ФЗ о локализации — этот момент стоит уточнить отдельно, подробный разбор есть в статье про законное размещение сервера с персональными данными. Если работаете преимущественно с клиентами вне РФ или это требование к вам не применимо, можно выбрать любую удобную площадку, например в Великобритании.

2. Закройте сервер от внешнего мира и поднимите WireGuard.

apt update && apt install wireguard -y
wg genkey | tee server_private.key | wg pubkey > server_public.key

Минимальный конфиг сервера /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server_private.key>
Address = 10.20.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <публичный ключ вашего телефона или ноутбука>
AllowedIPs = 10.20.0.2/32

Дальше — брандмауэр, который пропускает только SSH и WireGuard:

ufw default deny incoming
ufw allow 51820/udp
ufw allow OpenSSH
ufw enable

3. Создайте зашифрованный раздел для заметок. Проще всего через файловое шифрование поверх обычной файловой системы:

apt install gocryptfs -y
mkdir -p /srv/notes_enc /srv/notes
gocryptfs -init /srv/notes_enc
gocryptfs /srv/notes_enc /srv/notes

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

4. Настройте автоматическое «закрытие» раздела при простое. Простой systemd-таймер размонтирует раздел, если к нему давно не обращались, — это подстраховка на случай, если вы забыли закрыть сессию вручную.

5. Подключайтесь с телефона и ноутбука через WireGuard-клиент, а к самим файлам — через любой SFTP- или WebDAV-клиент с поддержкой markdown, туннелированный внутри VPN. Снаружи туннеля этот трафик просто не существует для внешнего наблюдателя.

Бэкапы, утеря устройства и уход из профессии

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

apt install restic -y
restic -r /mnt/backup-disk init
restic -r /mnt/backup-disk backup /srv/notes

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

Если телефон или ноутбук с доступом к серверу потерян или украден — первое действие до всего остального: удалить соответствующий ключ из списка [Peer] на сервере и перезапустить WireGuard. Устройство без действующего ключа не сможет подключиться, даже если у того, кто его нашёл, есть пароль от телефона.

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

Если вы уходите из практики или меняете сервер, зашифрованный архив переносится копированием одной директории — без экспорта в чужой формат и без риска, что часть заметок «не переехала».

Частые вопросы