«Включите шифрование» — универсальный совет, который дают всем и который почти никто не превращает в конкретную защиту от конкретной угрозы. Между тем шифрование — это не свойство «безопасно», а механизм с очень узкой областью действия: он делает данные нечитаемыми, пока ключ недоступен. Всё остальное — про то, когда ключ недоступен, а когда доступен.
Разберём это на архиве личного ассистента, потому что там ставки выше обычного: подробный лог экрана, переписка, извлечённые факты о вас и о людях вокруг.
#Короткий ответ
Полнодисковое шифрование защищает от выключенного украденного устройства и практически ни от чего больше. Как только вы вошли в систему, диск расшифрован для всех процессов, работающих под вашей учётной записью, — включая вредоносную программу, которую вы запустили сами.
Отдельное шифрование внутри приложения защищает от того, у кого есть файл базы, но нет пароля: от постороннего с доступом к машине, от резервной копии, уехавшей в облако, от чтения базы другой программой. Оно не защищает то, что в момент чтения расшифровано в оперативной памяти.
#Таблица: угроза и защищает ли шифрование
Смотреть надо на две правые колонки вместе. Там, где полнодисковое шифрование стоит «нет», а прикладное — «да», лежит вся практическая разница между ними.
| Угроза | Полнодисковое | Шифрование внутри приложения |
|---|---|---|
| Украли выключенный ноутбук | Да | Да |
| Украли ноутбук в спящем режиме | Частично | Да |
| Посторонний сел за разблокированную машину | Нет | Да |
| Вредонос под вашей учётной записью | Нет | Только пока не введён пароль |
| Резервная копия уехала в облако | Нет | Да |
| Диск сдали в ремонт или продали | Да | Да |
| Администратор сервера читает базу | Нет | Да |
| Изъятие устройства с требованием выдать пароль | Нет | Нет |
Из таблицы следуют два вывода. Первый: полнодисковое шифрование закрывает ровно один сценарий — «устройство уехало без вас и было выключено». Второй: строка про изъятие честно стоит «нет» в обеих колонках, потому что криптография не защищает от того, кто может потребовать пароль у вас.
#Три модели хранения ключа
Стойкость алгоритма редко бывает слабым местом. Слабым местом бывает то, где лежит ключ.
Ключ выводится из вашего пароля. Пароль в приложении не хранится: из него функцией выведения ключа получается ключ шифрования. В Persona это PBKDF2-HMAC-SHA256 с 600 000 итераций и отдельной случайной солью на каждую запись, поверх — Fernet (AES-128 в режиме CBC плюс проверка целостности через HMAC-SHA256). Итерации нужны, чтобы перебор паролей стоил дорого; соль — чтобы одинаковые пароли давали разные ключи.
Свойство этой модели, которое надо принять до включения: забытый пароль означает потерю данных. Восстановления нет и не может быть — иначе существовал бы обходной путь, и защита была бы фиктивной.
Ключ привязан к устройству. Полнодисковое шифрование обычно хранит ключ в аппаратном модуле и отдаёт его после входа в систему. Удобно: пароль вводится один раз. Цена: после входа защита не действует ни на что, и ключ привязан к конкретной машине.
Ключ у поставщика услуги. Данные зашифрованы на его дисках, ключом управляет он. Защищает от кражи оборудования в его дата-центре и не защищает от него самого. Это не обман — просто другая угроза.
#Что из этого следует на практике
Шифрование диска обязательно, но недостаточно. Включите его в любом случае: BitLocker на Windows, FileVault на macOS, LUKS на Linux. Это дёшево и закрывает самый вероятный бытовой сценарий — потерянный или украденный ноутбук.
Отдельный контур под пароль — для того, что действительно чувствительно. Не вся база, а конкретные записи: пароли, реквизиты, документы. Настройка и правила отбора — в гайде про хранилище под паролем для чувствительных записей.
Шифруйте резервные копии отдельно. Копия базы — это та же база, только вне вашего контроля. Незашифрованный бэкап в облачной папке отменяет всё, что вы настроили на диске. Схемы резервирования и их риски — в разборе резервных копий и приватности, техническая сторона снятия копии — в гайде по резервному копированию и восстановлению SQLite.
Не записывайте того, что не должно быть записано. Самая надёжная защита от чтения архива — отсутствие записи в архиве. Исключения приложений и правила маскирования работают до записи и потому сильнее любого шифрования после.
#Где интуиция подводит
«У меня зашифрован диск, значит архив защищён». Пока вы работаете, он расшифрован. Любая программа, запущенная от вашего имени, читает базу так же свободно, как её читает сам ассистент.
«Пароль на вход в приложение — это шифрование». Нет. Пароль на вход проверяет право открыть интерфейс; данные при этом лежат в файле как есть, и их читает любая программа, открывшая файл напрямую. Шифрование — это про нечитаемость файла, а не про экран входа.
«Стойкий алгоритм означает стойкую защиту». Алгоритм почти никогда не является слабым местом. Слабым местом являются короткий пароль, ключ в том же каталоге, что и данные, и расшифрованная копия во временной папке.
«Зашифрую всю базу и не буду думать». Полнотекстовый и векторный индексы, кэши, временные файлы и файлы журнала базы данных живут рядом и обычно не шифруются. Полная защита требует шифровать том целиком, а не файл.
«Шифрование защитит от владельца сервера». Только то, что зашифровано ключом, которого у него нет. Всё, что приложение показывает вам в интерфейсе, оно умеет расшифровать — значит, ключ доступен серверу. Про остальные риски чужого экземпляра — в разборе честных рисков самостоятельного хостинга.
#Что здесь честно про нас
Шифрованное хранилище в Persona есть, и параметры выше — из его реализации, а не из рекламного текста. Но границы у него узкие, и лучше знать их заранее.
Ключи API и токены Telegram-ботов участников хранятся в базе в открытом виде. Хранилище подключено к секретам владельца экземпляра, а не участников. Тот, у кого есть файл базы, видит ключ участника. Пока это так, единственная защита — отдельный ключ с лимитом расходов, который не жалко отозвать.
Ключ владельца тоже не всегда шифруется. При недоступности хранилища — например, если необязательная криптографическая библиотека не установлена — значение уходит в открытую таблицу настроек. Молчаливого отказа нет, статус виден, но факт нужно знать.
Основная база не зашифрована. Захват, распознанный текст, чаты и память лежат в обычном файле SQLite. Шифруются отдельные заметки и секреты владельца, а не архив целиком. Защита архива — это шифрование диска и контроль доступа к машине, и мы не выдаём одно за другое.
Проверить эти утверждения чтением кода нельзя — репозиторий закрыт, публичной лицензии нет.
#Частые вопросы
#Стоит ли шифровать всю базу ассистента целиком?
Технически возможно, практически спорно: шифрование базы замедляет поиск, ломает часть индексных механизмов и не защищает от главной угрозы — работы под вашей же учётной записью. Разумнее комбинация: шифрование тома для случая «устройство уехало» плюс отдельный контур под паролем для самого чувствительного.
#Что будет, если я забуду пароль от зашифрованных записей?
Данные потеряны безвозвратно. Это не недоработка, а свойство схемы: ключ выводится из пароля и нигде не хранится, поэтому обходного пути нет. Если бы он был, им воспользовался бы и посторонний. Записывайте пароль в менеджер паролей до того, как зашифруете первую запись.
#Защищает ли шифрование от того, кто уже сидит за моим разблокированным компьютером?
Полнодисковое — нет, для него всё уже расшифровано. Прикладное — да, пока вы не ввели пароль в текущей сессии. Практический вывод: блокировка экрана при отходе даёт больше, чем любая настройка шифрования.
#Нужно ли шифровать резервную копию, если диск уже зашифрован?
Да, и это самая частая дыра. Шифрование диска действует на диске, а копия обычно уезжает в другое место — на внешний носитель или в облачную папку, — где никакого шифрования нет. Копия шифруется отдельно, своим паролем.
#Чем шифрование в приложении отличается от менеджера паролей?
Моделью угроз и объёмом. Менеджер паролей рассчитан на короткие секреты, имеет свою дисциплину блокировки и обычно проходил внешний аудит. Шифрование внутри ассистента рассчитано на записи и заметки. Пароли и ключи разумнее держать в менеджере, а в ассистенте — то, что менеджер хранить не предназначен.
#От каких угроз шифрование не помогает вообще?
От тех, где ключ доступен: вредонос под вашей учётной записью, посторонний за разблокированной машиной, требование выдать пароль. Полный перечень того, что локальность и шифрование не закрывают, — в разборе модели угроз локального ИИ; общая рамка приватности — в статье про приватный ИИ и локальное хранение.
#Вывод
Если вы выбираете одно действие — включите шифрование тома: оно закрывает самый вероятный сценарий и стоит десяти минут. Если готовы на второе — заведите отдельный контур под паролем для того, что действительно нельзя терять, и запишите пароль в менеджер до первой записи. И держите в голове границу: шифрование делает файл нечитаемым без ключа, а не делает вашу машину безопасной. Безопасность машины — это блокировка экрана, обновления и осторожность с тем, что вы на ней запускаете.