Менеджер паролей для команд: что оценивать

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

Эта статья — чек-лист оценки, а также описание модели OpenKey, если вы хотите общие коллекции на инфраструктуре, которой владеете.

Требования, которые действительно различаются

1. Общие хранилища с настоящим контролем доступа

«Могу делиться с командой» — это исходный минимум. Важно другое: выдаётся ли доступ на уровне коллекции или на уровне человека, можно ли поделиться подмножеством, не раскрывая всего, и может ли подрядчик видеть ровно один сервис.

• Доступ «всё или ничего» ломается быстро: он не масштабируется дальше пяти человек.
• Доступ на уровне коллекции — минимально полезная модель.
• Доступ на основе ролей (admin / member и, в идеале, read-only) нужен, как только появляются рецензенты и согласующие.

2. Увольнение, которое действительно снимает доступ

Именно это требование отделяет потребительские инструменты от командных, и именно его чаще всего нет.

Когда кто-то уходит, вам нужно знать:

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

Инструмент, который не может ответить на это, — это риск для комплаенса, одетый в оболочку функции продуктивности.

3. Автоматизация и доступ машин

Люди в интерфейсе — это половина проблемы. Вторая половина:

• CLI для CI и скриптов
• API для подготовки аккаунтов и внутренних инструментов
• Сервисные аккаунты, которые не истекают вместе с уходом человека
• Массовый импорт из каталога или таблицы с устаревшими общими учётными данными

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

4. Нулевое разглашение и что оно значит коммерчески

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

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

5. Журнал аудита

«Могу ли я доказать, кто имел доступ к паролю от боевой базы данных 3 марта?» — для этого нужен журнал доступа с определённым сроком хранения, который можно выгрузить для аудитора.

Честно отметьте ограничение: в системе с нулевым разглашением администратор видит факт обращения к записи, а не её содержимое. Это правильное поведение, но одновременно и ограничение на то, что ваш аудит способен доказать.

6. Своя инфраструктура

В какой-то момент проверка безопасности спросит, покидают ли общие учётные данные вашу сеть. Вариантов три: инфраструктура вендора с договорным DPA, частное облако или self-hosting. Self-hosting — единственный из них, который вы можете проверить сами, и единственный, в котором вы можете показать, что сервер хранит шифротекст.

7. Модель цены, выдерживающая численность

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

• Цену места с доступом только для чтения
• Бесплатны ли сервисные аккаунты
• Считаются ли деактивированные пользователи
• Есть ли бесплатный тариф для оценки

Оценочный лист для команд

Критерий	Вес	Почему это важно
Увольнение и отзыв доступа	×3	Требование, которому большинство инструментов не соответствует
Контроль доступа по коллекциям	×3	Не даёт одному подрядчику увидеть всё
Доступ к CLI и API	×3	Машины — половина ваших пользователей
Проверяемое нулевое разглашение	×3	Комплаенс и подверженность утечкам
Сервисные аккаунты	×2	Долгоживущий доступ нечеловеческих сущностей
Журнал аудита со сроком хранения	×2	Доказать исторический доступ
Наличие self-hosting	×2	Учётные данные остаются внутри вашей сети
Экстренный доступ	×1	Аварийный доступ, когда администратор недоступен
Инструменты массовой миграции	×1	Сойти с общей таблицы

Как OpenKey работает с командным доступом

Модель общего доступа в OpenKey построена под это, и в нескольких местах она намеренно необычна — стоит понять их до того, как вы построите на ней процесс.

Организации и общие коллекции

Общий доступ требует Pro и настроенного self-hosted сервера, причём все должны быть на одном и том же URL сервера. Модель:

1. Публикуйте ключи идентичности, чтобы коллеги могли обернуть ключи для вас. В OpenKey это делается из браузерного расширения в standalone-режиме (server) — на странице приложения Settings → Data этого действия нет.
2. Создайте организацию и общие коллекции внутри неё. Клиент шифрует название организации и оборачивает ключ организации для вас как владельца.
3. Пригласите участников по email (они должны уже существовать на сервере) с ролью admin или member. Ваш клиент оборачивает ключ организации под их опубликованный ключ идентичности и отправляет приглашение.
4. Они принимают приглашение в разделе Pending invites и синхронизируются; общие коллекции появляются.

Сервер хранит названия организаций, общие полезные нагрузки и ключи идентичности как непрозрачный шифротекст. Он никогда не разворачивает ключ организации.

Полномочия администратора: отзывать ожидающие приглашения, менять роли, удалять участников. Одно ограничение, вокруг которого нужно строить план, — владелец не может покинуть организацию, а передача владения не является отдельным путём восстановления. Назначьте второго владельца заранее, а не ради галочки.

Доступы к отдельным элементам — снимки, а не живые документы

Это самая важная операционная деталь во всей модели. Когда вы открываете доступ к одной записи или коллекции другому человеку:

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

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

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

Чего OpenKey не делает

Стоит сказать прямо, потому что это влияет на выбор:

• Нет движка политик с принуждением от администратора на клиенте. На сервере нет правила, которое задало бы минимальную длину пароля для всей команды.
• Нет автоматической привязки к увольнению. Удаление участника — ручное действие: отзыв или удаление в организации, а затем разбор уже принятых доступов к записям.
• Нет SCIM и синхронизации с каталогом. Состав участников управляется через API организации и общего доступа.
• Нет серверного журнала аудита обращений к записям. Сервер не видит открытый текст, поэтому не может логировать, что именно прочитали.
• Синхронизация — это last-write-wins по revision, а не CRDT. Параллельные правки могут перезаписать друг друга; когда это важно, правьте на одном устройстве за раз.

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

Развёртывание в команде

1. Сначала запустите сервер. Настройка сервера, усиленная по чек-листу защиты.
2. Создайте собственный аккаунт и опубликуйте ключи идентичности из расширения.
3. Создайте организацию, затем по одной общей коллекции на каждый сервис или границу команды. Начните с общих аккаунтов инфраструктуры — именно они наносят больше всего вреда, когда ошибаются.
4. Опубликуйте ключи идентичности для всех, кого приглашаете, иначе шаг обёртывания их не найдёт.
5. Приглашайте небольшими группами и проверяйте, что участник действительно может открыть общую коллекцию, прежде чем добавлять следующую партию.
6. Перенесите общую таблицу. Каждая учётная запись, которая сейчас лежит в командной таблице, — ваш импорт с наивысшим приоритетом.
7. Опишите процедуру увольнения до того, как она понадобится. Два шага, записанные на бумаге: удалить из организации; пересмотреть и отозвать доступы к записям.

Версия за минуту

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

Следующие шаги

• Общий доступ и организации — полный разбор
• Self-hosted менеджер паролей — запуск сервера
• Менеджер паролей для семьи — версия для домохозяйства
• Безопасность — что сервер может и чего не может видеть