Компартментализация учётных данных

Базовое допущение менеджеров паролей - единый vault для всего: один мастер-пароль, единая поверхность синхронизации, единый радиус компрометации. Компартментализация учётных данных отвергает этот подход и распределяет секреты по нескольким инструментам, подобранным под конкретные задачи. Здесь сходятся два аргумента: ни один отдельный инструмент не покрывает сразу все требования (совместный доступ, работа через CLI, офлайн-режим, надёжность на мобильных устройствах, аудит-логи), а единое хранилище превращает взлом в компрометацию цифровой личности целиком.

Этот паттерн был сформулирован в marius-bitwarden-not-recommended как принцип "разделяй и властвуй" после того, как автор отказался от единой self-hosted связки из bitwarden / vaultwarden.

Правило группировки

Разделение проходит по границе того, что именно утечёт вместе с этой группой, а не по тому, какой инструмент удобнее:

Клиентская и рабочая деятельность. Важен совместный доступ. Критичны SSO, аудит-логи и браузерные расширения на управляемых корпоративных машинах. Стоит выбрать заточенный под это SaaS-менеджер паролей, смириться с проприетарным решением и жёстко ограничить его область применения.
Аккаунты с персональными данными (PII) (банки, магазины, страховые). Как ни парадоксально, базовый риск утечки здесь и так высок - сами эти сервисы регулярно теряют данные. На первое место выходят кроссплатформенность и надёжная работа в офлайне. Подойдёт второй облачный менеджер от другого вендора, с отдельным мастер-паролем и другими процедурами восстановления - чтобы взлом рабочей группы не приводил к каскадной компрометации.
Аккаунты без персональных данных (форумы, сервисы, разовые логины). Облако здесь избыточно. Достаточно локальной базы данных KeePass, синхронизируемой через Syncthing. Файл .kdbx зашифрован при хранении (at rest), поэтому уровень синхронизации сам по себе не требует безусловного доверия.
Инфраструктура (серверы, SSH, CI). Две подгруппы: личные учётные данные хранятся так же, как группа без PII, а секреты для автоматизации - в менеджере секретов (HashiCorp Vault, Infisical), где короткоживущие токены, политики и аудит-логи поддержаны нативно.
Разовые CLI-секреты (API-ключи, PAT, токены). pass (зашифрованный через GPG файл на каждый секрет внутри Git-репозитория) - в стиле Unix, легко автоматизируется скриптами, не требует демона и не имеет иной поверхности синхронизации, кроме подконтрольного вам удалённого Git-репозитория.

Почему важен радиус поражения

Утечка в любом из инструментов теперь ограничена его категорией. Взлом рабочего SaaS-хранилища не затрагивает банковские логины. Кража .kdbx-файла KeePass не даёт доступа к секретам CI. Скомпрометированный ноутбук с разблокированным pass не раскрывает данные клиентских проектов.

Сравните это со взломом единого хранилища: все пароли, все сиды TOTP и все коды восстановления достаются злоумышленнику за одну операцию расшифровки. Единственный рубеж защиты - параметры KDF и мастер-пароль.

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

Смежные идеи

ephemeral-credentials - внутри инфраструктурной группы предпочтение отдаётся учётным данным, которые сгорают сами, вместо регулярной ротации. Системное решение проблемы долгоживущих ключей.
supply-chain-security - сегментированная схема ограничивает ущерб от скомпрометированного CLI-инструмента (например, инцидент с Shai-Hulud в Bitwarden CLI) только теми учётными данными, с которыми этот инструмент непосредственно взаимодействовал.
living-off-the-land - использование атакующими легитимных инструментов; при таком классе атак компартментализация сужает периметр того, до чего злоумышленник вообще может добраться.