Свой менеджер паролей на сервере: зачем и что учесть

Пароли в команде обычно живут в трёх местах: в голове, в переписке и в файле на общем диске. Все три варианта плохи по-своему, и особенно остро это становится видно в момент, когда сотрудник уходит, а список того, к чему у него был доступ, никто не вёл.

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

Зачем своё

Хранилище доступов не уходит наружу. Для части компаний это требование, а не предпочтение. Зашифрованная база лежит на вашем сервере.

Цена не зависит от числа людей. Коммерческие сервисы считают по пользователям, свой сервер стоит столько же и на пятерых, и на пятидесяти.

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

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

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

Сколько ресурсов нужно

Это одна из самых лёгких задач для сервера. Хранилище паролей - маленькая база и редкие обращения.

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

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

Как соотносить ресурсы с задачей в целом, разобрано в статье как выбрать конфигурацию сервера.

Что критично настроить

Здесь цена ошибки выше, чем в любой другой self-hosted задаче, поэтому пунктов всего четыре и все обязательные.

HTTPS без исключений. Клиенты не должны подключаться по незашифрованному каналу, и большинство из них попросту откажется. Сертификат выпускается бесплатно, см. SSL-сертификат на VPS.

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

Бэкапы, проверенные восстановлением. Потеря этой базы означает потерю всех доступов компании разом. Копии делают регулярно, хранят вне сервера и минимум раз в квартал проверяют разворачиванием, см. резервное копирование VPS.

Ограниченный доступ к административной части. Панель администратора не должна смотреть в открытый интернет: её закрывают по адресу правилом файрвола, см. порты на сервере и файрвол на VPS.

Отдельно: обновления ставятся сразу. Это приложение, доступное из интернета и хранящее самое ценное, что есть у компании, см. обновление сервера.

Как устроена безопасность

Важно понимать принцип, потому что он определяет, что именно вы защищаете.

Данные шифруются на устройстве пользователя до отправки на сервер. Сервер хранит зашифрованный блок и не знает мастер-пароля. Это значит, что при утечке самой базы содержимое не читается без мастер-пароля.

Из этого следует два практических вывода.

Мастер-пароль восстановить нельзя. Ни вы, ни администратор сервера не сможет помочь сотруднику, который его забыл. Доступ к его личным записям теряется, и это нормальное поведение, а не поломка.

Защищать надо не только содержимое, но и доступность. Утечка зашифрованной базы неприятна, но не смертельна. Потеря базы без копии - смертельна. Поэтому бэкап важнее всего остального.

Организация доступов в команде

Инструмент работает, только если им пользуются правильно.

• Личное и общее разделяют. Личные пароли сотрудника - в его хранилище, общие доступы - в коллекциях команды.
• Коллекции по зонам ответственности. Разработке не нужны доступы бухгалтерии, и наоборот.
• Паролями не делятся вне системы. Смысл теряется, если доступ всё равно передают в переписке.
• При увольнении доступ отзывают, а общие пароли меняют. Первое делается в одном месте, второе всё равно придётся сделать руками.

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

Когда проще взять готовый сервис

Честная граница выглядит так.

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

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

Частые ошибки

Нет бэкапа. Главная и единственная по-настоящему фатальная ошибка: потеря базы означает потерю всех доступов компании.

Копия лежит на том же сервере. При отказе диска пропадает и хранилище, и копия.

Открытая регистрация. Посторонние заводят учётные записи на вашем сервере.

Работа без HTTPS. Часть клиентов просто не подключится, а остальное небезопасно.

Административная панель в открытом доступе. Прямой путь к управлению всеми учётными записями.

Откладывают обновления. Приложение с таким содержимым обновляют в первую очередь, а не в последнюю.

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

Сколько ресурсов нужно под свой менеджер паролей? Минимум: одного ядра и гигабайта памяти достаточно на команду в несколько десятков человек. База занимает мегабайты.

Видит ли администратор сервера чужие пароли? Нет. Данные шифруются на устройстве пользователя, сервер хранит зашифрованный блок и мастер-пароля не знает.

Что будет, если сотрудник забыл мастер-пароль? Восстановить его нельзя, доступ к личным записям теряется. Это следствие самой схемы шифрования, а не недоработка.

Что самое важное при самостоятельном размещении? Резервные копии вне сервера, проверенные восстановлением. Утечка зашифрованной базы неприятна, потеря базы без копии необратима.

Нужно ли менять общие пароли при увольнении? Да. Отзыв учётной записи не отменяет того, что человек мог их сохранить. Менеджер хотя бы даёт точный список того, что менять.

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

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

Нужен сервер под хранилище доступов? VPS на NVMe от 459 руб в месяц - младшего тарифа хватает с запасом, полный root-доступ и снапшоты для копий. Площадки в Москве, Казани и Амстердаме, активация за 3 минуты.