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

MAATRIX

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

Почему записи психолога — это не «просто файлы»

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

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

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

Почему публичное облако — рискованная точка хранения

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

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

Есть и обратный миф — что свой сервер автоматически безопаснее просто по факту, что он «свой». Это не так: без базовой гигиены (шифрование, обновления, разграничение доступа) свой VPS может быть уязвимее хорошо защищённого облачного гиганта. Мы разбирали это подробно в статье «Миф: свой сервер безопаснее облака» — там честный разбор, когда это правда, а когда нет. Ключевое отличие своего сервера не в «магической безопасности из коробки», а в том, что решения о хранении данных клиента принимаете вы, а не чужой юридический отдел — и эти решения можно настроить именно под требования вашей практики.

Что даёт полный контроль на практике

«Полный контроль» — это не лозунг, а конкретный список того, что вы получаете, когда данные лежат на вашем собственном сервере, а не в чужом сервисе:

• Вы знаете физическую локацию данных. Сервер стоит в конкретном дата-центре конкретной страны, которую вы выбрали сами — а не «где-то в инфраструктуре провайдера, распределённой по нескольким юрисдикциям».
• Список доступа — это ваш список. Только те SSH-ключи, которые вы сами добавили. Никакого «сотрудника поддержки облачного сервиса», у которого технически есть возможность заглянуть в ваши файлы для диагностики проблемы.
• Вы решаете, что происходит с резервными копиями. Не автоматическая политика вендора, а бэкап, зашифрованный вашим собственным ключом, который лежит там, где вы указали.
• Вы решаете, когда данные удаляются насовсем. Не «через 30 дней после запроса на удаление, согласно нашей внутренней процедуре», а сразу и без посредников.
• Никто не анализирует содержимое ваших файлов автоматическими системами. На вашем сервере не работают алгоритмы модерации контента или рекомендательные системы, которым нужно «прочитать» файл, чтобы что-то предложить.

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

Где физически хранить заметки и записи сессий

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

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

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

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

Шифрование и разграничение доступа — минимальная гигиена

Сервер сам по себе не защищает данные — защищает то, как он настроен. Для архива с материалами такой чувствительности разумный базовый набор выглядит так:

# Шифрование диска на уровне LUKS — данные нечитаемы без ключа,
# даже если физический носитель окажется не в тех руках
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 clients_data

# Доступ по SSH только по ключу, пароль отключён полностью
# в /etc/ssh/sshd_config:
PasswordAuthentication no
PermitRootLogin no

# Базовый firewall — закрыто всё, что не нужно явно
ufw default deny incoming
ufw allow OpenSSH
ufw enable

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

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

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

Сколько хранить и когда удалять

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

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

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

С чего начать, если вы не системный администратор

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

1. Арендовать VPS в подходящей юрисдикции — если часть клиентов из Европы или вам важна определённая правовая среда для инфраструктуры, локация в Великобритании часто оказывается удобным вариантом.
2. Сразу зашифровать раздел с данными — это делается один раз при первичной настройке сервера, до того как там появятся первые файлы клиентов.
3. Поставить Nextcloud или аналог для заметок — интерфейс похож на привычные облачные сервисы, но данные не покидают вашу инфраструктуру.
4. Настроить зашифрованный бэкап на отдельное хранилище, ключ — отдельно от сервера и от бэкапа.
5. Закрыть лишние точки входа — пароль по SSH выключить, оставить только вход по ключу, поставить базовый firewall.

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

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