Пароли сотрудников: как навести порядок без боли
Общий файл «пароли.xlsx» в сетевой папке, стикер под клавиатурой бухгалтера, единый пароль от админки, который знают все и который не менялся с момента запуска сайта. Это не карикатура, а типичная картина в компании до тридцати человек. Хорошая новость: приводится в порядок это за неделю и почти бесплатно.
Почему требования старой школы не работают
Требование «восемь символов, цифра, спецсимвол, менять каждые 90 дней» породило известный результат: Password1!, затем Password2!, затем стикер на мониторе. Современные рекомендации, включая обновлённые стандарты NIST, развернулись на 180 градусов: длина важнее сложности, принудительная ротация без признаков компрометации вредна, а главное — проверка пароля по базам известных утечек. Пароль из четырёх случайных слов длиной 20+ символов запоминается легче и перебирается на порядки дольше, чем Qw3rty!2.
Менеджер паролей: основа порядка
Одно решение закрывает большую часть проблемы. Сотрудник помнит единственный мастер-пароль, всё остальное генерируется случайно и хранится зашифрованным. Побочный эффект важнее основного: менеджер не подставит сохранённые данные на фишинговом сайте, потому что домен не совпадёт. Человек ошибётся, программа — нет. Корпоративные версии дают общие сейфы для отделов, аудит использования и мгновенный отзыв доступа при увольнении.
Порядок внедрения за пять шагов
- Инвентаризация: выпишите все сервисы, где у компании есть учётные записи. Список обычно оказывается вдвое длиннее ожидаемого.
- Определите владельца каждого сервиса — конкретного человека, а не отдел.
- Разверните менеджер паролей и заведите общие сейфы по отделам.
- Смените пароли на критичных сервисах на сгенерированные, начиная с почты, домена и хостинга.
- Включите двухфакторную аутентификацию везде, где она доступна — подробный разбор здесь.
Отдельная боль: общие аккаунты
Один аккаунт администратора на пятерых — это не только риск, но и невозможность расследования: журнал покажет, что действие совершил «admin», и на этом всё закончится. Правильное решение — персональные учётные записи с разными уровнями прав. Там, где сервис технически не поддерживает несколько пользователей (а такое встречается у старых систем), общий пароль хранится в сейфе с журналом обращений и меняется при каждом изменении состава команды. Проектируя SaaS-платформы, мы закладываем персональные аккаунты с ролями с первого дня — доработать это потом стоит в разы дороже.
Что делать с сервисными паролями
Пароли баз данных, ключи API и токены интеграций живут не в головах людей, а в конфигурации. Главное правило: они не попадают в репозиторий кода никогда — даже в приватный, даже «временно». Один раз попавший в историю git секрет считается публичным навсегда, и удаление коммита не помогает. Хранилище секретов или зашифрованные переменные окружения — минимальный стандарт. Про безопасное хранение учётных данных в браузерных приложениях полезно почитать в документации MDN.
Политика, которую реально соблюдают
- Минимальная длина 12 символов, без обязательных спецсимволов — длина важнее набора.
- Проверка нового пароля по базам утечек при установке.
- Смена только при подозрении на компрометацию, а не по календарю.
- Обязательный второй фактор для почты, финансов и административных панелей.
- Отключение всех доступов в день увольнения по единому чек-листу.
На практике весь переход занимает 5–7 рабочих дней вместе с обучением, а стоимость корпоративного менеджера паролей — порядка 300–600 рублей на сотрудника в месяц. Сравните с 3 млн рублей минимального штрафа за утечку. Если нужна помощь с аудитом доступов и внедрением — напишите или посмотрите, как мы ведём инфраструктуру клиентов в сопровождении.