Рабочий ответ на вопрос «где хранить пароли компании» звучит скучно: в менеджере паролей с общими сейфами по ролям и журналом открытий, развёрнутом на своём сервере или взятом по лицензии у российского поставщика. Ключи интеграций при этом в менеджер паролей не попадают вообще — они живут в хранилище секретов приложения, и ни один человек в компании не должен видеть их значение в обычной работе.
Проблема не в том, что этого не знают. Проблема в том, что пароли всё равно оказываются в закреплённом сообщении рабочего чата, в таблице на общем диске и в письме с темой «доступы». Так происходит не от беспечности, а потому что в момент, когда пароль нужен срочно, переписка — самый короткий путь. Любой регламент, который делает правильный путь длиннее короткого, проигрывает; поэтому переход на хранилище — это не приказ, а неделя работы, после которой правильный путь становится быстрее.
Дальше — разбор по классам секретов, пять критериев выбора хранилища без рейтинга продуктов, план миграции на неделю с расчётом для компании на 40 человек и девять систем, правила ротации и порядок действий в первый день после увольнения администратора. Ставки в расчётах: системный администратор 1 200 ₽/ч, сотрудник 900 ₽/ч.
Почему переписка — худшее хранилище из возможных
Дело не в том, что мессенджер плохо шифрует канал — с этим у современных мессенджеров всё в порядке. Дело в свойствах переписки как хранилища: у неё нет ни одного свойства, которое требуется от места, где лежат ключи.
- Из переписки нельзя отозвать доступ. Сообщение с паролем прочитано, скопировано, переслано дальше — и с этого момента вы не знаете круг тех, кто его видел. Удаление сообщения через полгода ничего не меняет: оно давно синхронизировано на устройства.
- Она уезжает на личные устройства. Рабочий чат стоит на личном телефоне сотрудника, который потом теряется, продаётся или отдаётся ребёнку. Пароль от панели хостинга едет вместе с ним, и об этом никто не вспоминает.
- Она отлично ищется. Поиск по словам «пароль», «доступ», «логин» в истории переписки за три года выдаёт готовый список ключей от всей компании. Тому, кто получил доступ к аккаунту одного сотрудника, дальше не нужно ничего взламывать.
- У неё нет журнала открытий. На вопрос «кто видел этот пароль» ответить нечем. А именно с этого вопроса начинается любой разбор инцидента — и именно на нём он и заканчивается, если секреты жили в чате.
- Она переживает увольнение. Уволенный сотрудник теряет доступ к корпоративным системам, но экспорт переписки, сделанный за неделю до ухода, остаётся у него. Это не гипотеза, а стандартный сценарий, который закрывается только тем, что паролей в переписке нет в принципе.
Таблица на общем диске лучше переписки ровно в одном: её можно закрыть правами. Всё остальное так же плохо — нет журнала, нет ротации, нет разделения по ролям, а файл при этом легко копируется на флешку целиком. Промежуточных решений здесь нет: либо есть хранилище, спроектированное под секреты, либо секреты лежат где придётся.
Сравнительная таблица-схема из трёх колонок: «Переписка», «Таблица на общем диске», «Менеджер паролей». Пять строк-свойств с отметками: «отзыв доступа», «журнал: кто открывал», «разделение по ролям», «ротация по расписанию», «не уезжает на личные устройства». У переписки все пять отметок отрицательные, у таблицы положительная только строка «разделение по ролям», у менеджера паролей — все пять положительные. Внизу подпись: «поиск по слову „пароль“ в истории за три года выдаёт ключи от всей компании». Чертёжный стиль, подписи по-русски.
Три класса секретов и три разных правила
Главная ошибка при наведении порядка — сложить всё в один сейф и раздать доступ команде. Секреты делятся на три класса, у которых разный круг допущенных, разная частота смены и разные последствия компрометации. Складывать их вместе так же неудобно, как хранить ключи от кассы вместе с ключами от подсобки.
| Класс | Что это | Где хранится | Кто видит значение | Когда меняется |
|---|---|---|---|---|
| Пароли людей | Вход в CRM, 1С, почту, панель хостинга, кабинеты сервисов | Менеджер паролей, общие сейфы по ролям (продажи, бухгалтерия, ИТ) | Сам сотрудник и администратор хранилища | При уходе сотрудника, при подозрении, планово раз в год |
| Ключи интеграций | Токены API, вебхуки, пароли к базе данных, доступ к SMTP | Хранилище секретов приложения или переменные окружения на сервере | Никто в обычной работе; администратор — только в момент выпуска | Раз в 6–12 месяцев и при каждой смене подрядчика |
| Подпись и платежи | КЭП, машиночитаемая доверенность, ключи банк-клиента, боевые ключи эквайринга | Вне общего хранилища: носитель в сейфе, отдельный компьютер, узкий круг | Руководитель, главный бухгалтер — поимённо | По сроку сертификата и по регламенту банка |
Отдельный от менеджера паролей механизм, из которого программа получает ключи в момент запуска: специализированный сервис секретов или, в простом случае, переменные окружения на сервере с ограниченным доступом к нему. Ключевое свойство — значение ключа не проходит через человека: администратор кладёт его один раз, приложение читает само, а в интерфейсах и в переписке ключ не появляется никогда. Именно поэтому строка «пароль от базы» не должна существовать ни в одном чате.
Третий класс стоит отдельно не из-за технологий, а из-за последствий. Квалифицированная подпись — это юридическое действие от имени компании, а ключ банк-клиента — прямая возможность распорядиться деньгами. Ни то, ни другое не передаётся подрядчику ни при каких обстоятельствах и не хранится в общем сейфе, даже если сейф хороший. Это же правило мы разбирали в опорной статье про доступы подрядчику: платёжный контур и подпись в красной зоне.
Карта из трёх зон. Зона «Пароли людей» — блок «менеджер паролей» с тремя сейфами по ролям (продажи, бухгалтерия, ИТ), от них стрелки к фигуркам сотрудников. Зона «Ключи интеграций» — блок «хранилище секретов приложения», стрелка идёт к серверу и приложению, а к фигуркам людей стрелки нет, вместо неё пометка «люди значение не видят». Зона «Подпись и платежи» — блок «сейф, отдельный компьютер», стрелки только к двум фигуркам с подписями «руководитель», «главный бухгалтер», рядом пометка «подрядчику не передаётся». Чертёжный стиль, подписи по-русски.
Как выбрать хранилище: пять критериев вместо рейтинга
Рейтинги менеджеров паролей устаревают быстрее, чем пишутся, а список доступных в России продуктов за последние годы менялся не раз. Поэтому полезнее не название, а критерии, по которым вы проверите любой вариант сами — включая тот, который появится через год.
- 1Где физически лежат данные. Для компании, у которой в сейфах пароли к системам с персональными данными клиентов, ответ должен быть «на серверах в России» — либо на вашем собственном. Статус продукта в едином реестре российского ПО проверяется на дату закупки, а не по статье в интернете: реестр меняется.
- 2Что происходит при недоступности сервиса. Облачное хранилище недоступно — вы можете попасть в свои системы? У рабочего решения есть офлайн-копия базы у администратора или локальный кэш у сотрудников. Аварийный доступ проверяется до внедрения, а не в день аварии.
- 3Роли и общие сейфы. Нужны не «папки», а именно раздача по группам: бухгалтерия видит свой сейф, отдел продаж — свой, ИТ — все. Один общий сейф на компанию воспроизводит проблему переписки, только с красивым интерфейсом.
- 4Журнал открытий. Хранилище должно отвечать на вопрос «кто и когда открывал эту запись». Без журнала оно решает задачу удобства, но не решает задачу расследования — а именно ради второго всё и затевается.
- 5Экспорт в открытом формате. Возможность выгрузить все записи и уйти. Это страховка не от плохого продукта, а от смены его условий: перенести 400 записей вручную — это неделя работы, которую вы оплатите дважды.
Практических вариантов на сентябрь 2026 года четыре. Первый — офлайн-файл в формате KeePass и совместимых программах: бесплатно, работает без интернета, но журнала открытий нет, а совместная работа сводится к передаче файла, что для команды больше десяти человек мучительно. Второй — серверный менеджер паролей с открытым кодом, развёрнутый на своём сервере в России: есть роли и журнал, требуется администратор и резервное копирование. Третий — российский коммерческий продукт с установкой на свой сервер или по лицензии, например Passwork; здесь появляется поддержка, а статус в реестре проверяется при закупке. Четвёртый касается только ключей интеграций: отдельное хранилище секретов или переменные окружения на сервере, куда людям доступ не нужен вовсе.
Сколько действий делает сотрудник, чтобы вставить пароль в форму входа. Если больше трёх, через месяц половина компании вернётся в переписку, и никакой регламент этого не остановит. Расширение для браузера и приложение на телефоне — не украшение, а условие того, что хранилищем будут пользоваться. Проверяйте это на живом сотруднике до закупки, а не на демонстрации у поставщика.
Миграция за неделю: пять шагов и 58 800 ₽
Переход на хранилище проваливается по одной причине: его начинают с закупки, а не с инвентаризации. В результате в новый красивый интерфейс переезжает половина секретов, вторая половина остаётся в чатах, и через месяц компания живёт в двух местах сразу — то есть хуже, чем до начала. Порядок шагов важнее выбора продукта.
- 1День 1–2. Инвентаризация
Выписываются все системы и все места, где сейчас лежат ключи: чаты, таблицы, заметки, стикеры, головы конкретных людей. Считается не «примерно», а поштучно — в компании на 40 человек и девять систем обычно набирается 250–400 записей, из которых треть дублируется, а десятая часть относится к сервисам, которыми давно не пользуются.
- 2День 2. Разбор по трём классам
Каждая запись помечается: пароль человека, ключ интеграции или подпись и платежи. Ключи интеграций сразу откладываются в отдельный список — они пойдут не в менеджер паролей, а в хранилище секретов, и по каждому надо будет понять, какое приложение его читает.
- 3День 3. Разворачивание хранилища и структура сейфов
Сервер или лицензия, резервное копирование базы хранилища, аварийный доступ администратора. Сейфы заводятся по отделам, а не по системам: сотруднику проще искать в «своём» сейфе, чем вспоминать, в какой папке лежит панель хостинга.
- 4День 3–4. Импорт и раздача доступа
Записи переносятся, дубли схлопываются, мёртвые сервисы отбрасываются. На этом же шаге у каждой записи появляется владелец — человек, который отвечает за её актуальность. Записи без владельца не переносятся: если за паролем никто не стоит, скорее всего, он уже не нужен.
- 5День 5. Инструктаж и зачистка
Получасовой разбор для сотрудников: как войти, как вставить пароль в форму, как добавить новую запись, куда писать, если не получается. Сразу после — удаление старых копий: закреплённые сообщения, таблица на диске, файл «доступы.docx». Незачищенные старые копии — самая частая причина, по которой миграция не считается состоявшейся.
Ориентир по лицензии — 250–600 ₽ на человека в месяц при годовой оплате, то есть 10 000–24 000 ₽/мес на 40 человек; конкретную цену смотрите у поставщика на день закупки, этот рынок двигается. Вариант с самостоятельным размещением обнуляет эту строку целиком, но добавляет обязанность обновлять и бэкапить хранилище — то есть примерно час работы администратора в месяц. Компаниям без своего администратора честнее платить за лицензию, чем заводить сервер, за которым потом никто не следит.
Горизонтальная лента на пять дней. День 1–2 «Инвентаризация» — под ним «250–400 записей, треть дублей»; день 2 «Разбор по трём классам»; день 3 «Хранилище и структура сейфов»; день 3–4 «Импорт и владельцы записей»; день 5 «Инструктаж и зачистка» — выделен, с пометкой «без него компания живёт в двух местах сразу». Справа от ленты итоговая плашка «58 800 ₽ разово, лицензия 10 000–24 000 ₽/мес на 40 человек». Чертёжный стиль, подписи по-русски.
Ротация: что меняется по расписанию, а что по событию
Требование «менять пароли каждые 90 дней» перекочевало в регламенты из старых стандартов и в компании до 300 человек приносит больше вреда, чем пользы: сотрудники начинают дописывать к паролю номер месяца. Работающее правило другое — плановая смена редкая, а событийная обязательная и немедленная.
| Секрет | Когда меняется | Что ломается при смене | Как менять без простоя |
|---|---|---|---|
| Пароль сотрудника к CRM или 1С | При уходе или переводе, при подозрении; планово раз в год | Ничего | Сменить и сообщить владельцу через хранилище, а не в чат |
| Ключ API интеграции | Раз в 6–12 месяцев и при каждой смене подрядчика | Обмен встанет молча, обнаружится на потерянных заявках | Выпустить второй ключ, перевести обмен, убедиться, что он идёт, отозвать первый |
| Пароль к базе данных | При уходе администратора, после инцидента | Приложения потеряют доступ разом | Окно 20–30 минут: смена, правка конфигурации, перезапуск, проверка |
| Пароль SMTP для уведомлений | Раз в год, при подозрении на рассылку от вашего имени | Письма перестанут уходить, и об этом никто не узнает | Проверить отправку с новым паролем до отзыва старого |
| Панель хостинга, регистратор домена | При уходе администратора, немедленно | Ничего, если второй фактор перенастроен заранее | Сменить пароль, перевыпустить резервные коды, проверить вход вдвоём |
| КЭП и машиночитаемая доверенность | По сроку сертификата, обычно 12–15 месяцев | Подписание в ЭДО остановится в день окончания | Выпуск за две недели до окончания срока, проверка обмена на новом |
Ключ интеграции нельзя менять «одним движением»: пока новый не прописан в обеих системах, обмен встанет — и встанет тихо, без ошибки на экране у людей. Правильный порядок — выпустить второй действующий ключ, перевести на него обмен, дождаться успешной синхронизации и только после этого отозвать первый. Если система не поддерживает два одновременных ключа, смена планируется окном в нерабочее время с проверкой обмена сразу после.
Схема-лента из четырёх шагов с обозначением времени: «Выпустить второй ключ» → «Прописать его в обеих системах» → «Дождаться успешного обмена» → «Отозвать первый ключ». Над шагами 1–3 полоса с подписью «оба ключа действуют — окно перекрытия». Снизу альтернативная ветка для систем, где второй ключ невозможен: «окно 20–30 минут в нерабочее время, проверка обмена сразу после». Сбоку красная пометка «смена одним движением = тихая остановка обмена». Чертёжный стиль, подписи по-русски.
Ключ подрядчику — отдельный, с датой и с урезанными правами
Когда подрядчику нужен доступ к системе через API, соблазн один — отдать существующий ключ, которым уже пользуется ваш обмен. Так делать нельзя по трём причинам, и все три проявляются позже, а не сразу.
- Общий ключ нельзя отозвать выборочно. Закончился проект — либо оставляете подрядчику работающий доступ, либо ломаете собственную интеграцию. Именно на этой развилке рождается большинство забытых доступов.
- По общему ключу не видно, чьи это действия. В журнале системы все обращения выглядят одинаково, и вопрос «кто выгрузил справочник контрагентов в среду ночью» остаётся без ответа.
- Права общего ключа обычно шире нужного. Ключ основного обмена умеет читать и писать всё, что нужно обмену, — а подрядчику на отладку хватает чтения двух справочников.
Правильная схема: отдельный ключ на проект, с минимальным набором методов, с ограничением по адресу подключения там, где это поддерживается, и с датой отзыва в журнале доступов. Само значение ключа передаётся через хранилище — общим сейфом на время проекта или разовой ссылкой, которая открывается один раз и умирает. Пересылать ключ сообщением не нужно даже как исключение: разовая ссылка занимает столько же времени.
Увольнение администратора: что делают в первый день
Уход системного администратора — единственное кадровое событие, которое требует технической реакции в тот же день. Не потому, что человек обязательно навредит, а потому, что он единственный, кто знает всё, и после его ухода вы больше не контролируете круг допущенных. Список действий составляется заранее и лежит рядом со списком систем.
- 1Отключить его именную учётную запись во всех системах и убрать из групп администраторов. Отключить, а не удалить: удаление уносит с собой историю действий, которая ещё может понадобиться.
- 2Сменить пароли всех общих и служебных учётных записей, к которым у него был доступ, — начиная с панели хостинга, регистратора домена и почтового администратора.
- 3Перевыпустить ключи интеграций с перекрытием, по порядку из таблицы выше, начиная с тех, что дают доступ к данным клиентов.
- 4Перевыпустить резервные коды двухфакторной аутентификации на критичных сервисах и убедиться, что второй фактор привязан не к его личному телефону.
- 5Проверить, не осталось ли его SSH-ключей на серверах и его адреса в списках получателей служебных уведомлений и оповещений о входе.
- 6Передать администрирование хранилища секретов второму человеку и убедиться, что аварийный доступ работает не только у уходящего.
Часть секретов при этом может не иметь письменного следа вообще и жить только в памяти уходящего — обнаруживается это через две недели, когда что-то перестаёт работать. Поэтому список систем и владельцев записей ведётся с первого дня, а не в момент увольнения.
Когда менеджер паролей не нужен
Есть ситуации, в которых внедрение хранилища — лишняя работа, и честнее это признать, чем поставить продукт, которым не будут пользоваться.
- Компания до пяти человек с тремя системами. Здесь работает бесплатный офлайн-файл в формате KeePass на общем диске с резервной копией и один разговор о том, что пароли не пересылаются в чат. Полноценное серверное хранилище с ролями решает проблему, которой ещё нет.
- Все системы — облачные, с единым входом. Если вход в CRM, почту и таблицы идёт через один корпоративный аккаунт с двухфакторной аутентификацией, количество отдельных паролей стремится к нулю. Тогда усилия правильнее направить на защиту этого одного входа, а не на хранилище для пяти записей.
- Нет никого, кто будет вести хранилище. Заброшенное хранилище хуже отсутствующего: часть секретов там, часть в чатах, актуальность неизвестна. Если ответственного нет и не появится, начните с малого — с зачистки паролей из переписки и списка систем с владельцами.
Во всех остальных случаях цена вопроса известна заранее: неделя работы и 58 800 ₽ на компанию в 40 человек, из которых почти треть — инструктаж сотрудников. Это не проект по безопасности в корпоративном смысле: ни отдела, ни консультантов он не требует.
Пароль, который можно найти поиском в переписке, уже не секрет — он просто ещё не понадобился чужому.
