Почему рабочая заметка — это не блокнот, а досье
Я несколько лет вёл созвоны: с подрядчиками, с командой, с клиентами. И в какой-то момент понял простую вещь: мои рабочие заметки — это не список дел. Это досье. Кто что пообещал и не сделал. За сколько мы реально договорились с поставщиком. Кого в команде я считаю слабым звеном. Какие условия мы готовы уступить на переговорах, а какие нет.
Это не «пара строк по итогам встречи». Это концентрат чувствительной информации о деньгах, людях и намерениях. И почти всё это лежит в каком-нибудь облачном сервисе для заметок, о котором вы ни разу не задали себе честный вопрос: а кто вообще может это прочитать?
Мы привыкли думать про приватность заметок в терминах «есть пароль — значит, безопасно». Но пароль защищает от того, кто попытается войти как вы. Он вообще ничего не говорит о тех, кто и так уже внутри системы: у кого есть доступ к серверам, к базе, к резервным копиям. Чтобы разобраться, нужен не пароль, а модель угроз.
Модель угроз простыми словами
Модель угроз звучит страшно, а на деле это один вопрос, разложенный на несколько: от кого мы защищаемся, что он может, и что мы теряем, если он победит. Не «абстрактный хакер в капюшоне», а конкретные роли, у каждой из которых свои возможности.
Для рабочих заметок в облаке я выделяю пять таких ролей. Это не полный список из учебника по безопасности — это те, кто реально может прочитать вашу заметку о майской сделке, не взломав при этом ничего.
- Случайный сосед по устройству. Коллега, к которому вы отошли за кофе с незалоченным ноутбуком. Родственник за вашим компьютером дома.
- Внешний злоумышленник. Тот самый «хакер»: подобрал пароль, увёл сессию, попал в утёкшую базу.
- Сотрудник самого сервиса. Инженер поддержки, админ базы данных, дата-сайентист вендора. У них по работе есть доступ к инфраструктуре.
- Сам сервис как компания. Не человек, а политика: что вендор делает с вашими данными по своему пользовательскому соглашению — анализирует, обучает модели, передаёт партнёрам.
- Третья сторона по закону или через утечку. Запрос от органов, поглощение компании, взлом подрядчика, у которого лежали ваши резервные копии.
Обратите внимание: пароль и двухфакторка закрывают только первые две роли. От остальных трёх они не защищают вообще. А именно там, в этих трёх, и живёт настоящий риск для заметок о сделках и людях.
Кто читает данные в облаке на самом деле
Вот здесь ломается интуиция большинства людей. Мы представляем, что наши данные в облаке лежат в личном сейфе, ключ от которого только у нас. В большинстве обычных облачных заметочников это не так.
Когда вы пишете заметку в типичном облачном сервисе, она уходит на сервер вендора в виде, который вендор может прочитать. Да, канал до сервера зашифрован. Да, на диске данные могут быть зашифрованы «на стороне сервера». Но ключ от этого шифрования — у вендора, а не у вас. А раз ключ у него, значит, при желании или по необходимости данные может открыть и он сам, и его сотрудник с нужными правами, и тот, кто получит доступ к его инфраструктуре.
Поэтому вопрос «кто читает данные в облаке» на практике сводится к одному техническому факту: у кого ключ шифрования. Если ключ у вендора — список читателей длиннее, чем вы думали:
- инженеры и админы, которым доступ нужен для поддержки и отладки;
- автоматические системы вендора, если соглашение разрешает анализ содержимого;
- любой, кто получит доступ к резервным копиям — а их обычно несколько и хранятся они дольше, чем вы ожидаете;
- новый владелец, если компанию купят вместе с базой пользователей.
Ничего из этого не требует взлома. Это штатные, законные сценарии внутри модели «ключ у вендора». Проблема не в том, что кто-то нарушает правила. Проблема в том, что правила изначально дают доступ многим.
Почему для заметок о сделках и людях это критично
Можно возразить: да пусть читают, кому нужны мои заметки. Это рабочая логика для списка покупок. Для рабочих записей — нет.
Заметка о сделке — это рычаг. Кто знает вашу нижнюю планку на переговорах, тот выигрывает переговоры. Заметка о человеке — это репутация: ваша оценка коллеги, сказанная в сердцах, в чужих руках превращается в конфликт или в повод для иска. Заметка о клиенте почти наверняка содержит персональные данные, и за их сохранность отвечаете в том числе вы.
Важный нюанс: это не юридическая консультация, и режим записи разговоров и обработки персональных данных стоит уточнять у юриста под вашу ситуацию. Но чисто по-человечески граница простая. Одно дело, когда утекает черновик поста в блог. Другое — когда утекает то, за что вам платят, доверяют и о чём вас предупредили под запись.
Защита рабочих записей — это не паранойя, а гигиена того же порядка, что закрывать дверь офиса на ночь. Вы не ждёте вора каждый вечер. Вы просто не оставляете чужие деньги и репутацию лежать на виду.
Что реально меняет расклад
Хорошая новость: сама модель угроз подсказывает решение. Если весь риск сосредоточен вокруг вопроса «у кого ключ», то и защита ровно там же — забрать ключ себе.
Архитектурно это называют local-first и сквозным шифрованием. Заметки хранятся на вашем устройстве, в обычных файлах, которые принадлежат вам. Синхронизация между устройствами идёт в зашифрованном виде, а ключ есть только у вас — вендор передаёт зашумлённый набор байтов, который сам прочитать не может. В такой схеме роли «сотрудник сервиса», «сам сервис» и «третья сторона» разом теряют возможность читать содержимое: даже получив данные, они получают шифртекст без ключа.
Именно по этому принципу я в итоге стал вести рабочие заметки. В моём случае это Alfric — он слушает созвон и сам собирает протокол, задачи и саммари, но записи и расшифровки хранит на моём компьютере в обычных markdown-файлах, а синхронизацию шифрует ключом, который остаётся у меня. Мне это важно не из-за ярлыка «приватность», а из-за конкретной строчки в модели угроз: список тех, кто может прочитать мою заметку о майской сделке, схлопывается до меня одного.
Не обязательно брать именно этот инструмент. Обязательно — задать любому сервису, куда вы кладёте рабочие заметки, три вопроса: где физически лежат данные, у кого ключ шифрования и что написано про доступ сотрудников и анализ содержимого в пользовательском соглашении. Если на все три нет внятного ответа — вы уже знаете, в какую из пяти ролей превратился ваш сервис.