Сотрудник ушёл, а доступ к банк-клиенту, CRM или почте компании остался у него на телефоне: это самая частая причина внепланового «давайте сменим все пароли за один день». Разбираем, что на самом деле нужно сделать при увольнении, и почему это не одно действие, а два разных.
Если пароль от банк-клиента хранится в файле, который просто открывают все нужные сотрудники, «отозвать доступ» одному конкретному человеку невозможно в принципе: придётся менять пароль для всех и рассылать новый заново, потому что файл не различает, кому какой доступ дать, а у кого его забрать. С менеджером паролей, где к сейфу выдан доступ конкретным аккаунтам, задача сводится к одному действию: убрать конкретного человека из списка участников, не трогая остальных.
Первое, что нужно сделать в момент увольнения, это убрать сотрудника из организации или лишить его доступа к конкретному сейфу. Это действие мгновенное: как только участник исключён, все его последующие запросы к API проверяются заново и получают отказ, потому что роль и членство в организации нигде не кэшируются на стороне сервера, а читаются из базы при каждом обращении. Практически это значит, что уже открытая на его телефоне вкладка кабинета перестаёт получать доступ к данным организации сразу же после исключения, без ожидания истечения сессии.
Здесь важна честность: само по себе исключение из списка участников не меняет ключ шифрования сейфа. Если у уволенного сотрудника была возможность заранее скопировать зашифрованные данные сейфа вместе со своей копией ключа (например, экспортировав их или просто имея офлайн-копию на устройстве до момента увольнения), исключение из организации не отменяет того, что технически он уже успел получить. Для полной уверенности в таких случаях владелец сейфа может выполнить отдельную операцию, ротацию ключа: сейф перешифровывается новым ключом, а новые envelope-доступа выпускаются заново только для тех, кто должен видеть содержимое сейчас. Это более тяжёлая операция, чем исключение участника: она требует явного действия владельца сейфа и пересчёта всех записей, но именно она даёт гарантию, что старый ключ больше ничего не открывает, даже если он у кого-то остался.
Если речь о рутинном увольнении без подозрений (плановый уход, доступ отозван вовремя, никаких признаков того, что данные копировались заранее), обычно достаточно исключить участника. Ротация ключа больше подходит для ситуаций, где есть основания не доверять: конфликтное увольнение, подозрение на утечку, или просто регулярная практика для сейфов с особенно чувствительными данными вроде банк-клиента. Чек-лист получается таким: убирать из организации сразу в день увольнения нужно всегда, а ротацию ключа сейфов, к которым у уволенного был доступ, стоит выполнять, когда есть хоть какие-то сомнения или сейф критичный.
Помимо самого доступа к сейфам, стоит закрыть API-ключи, которые сотрудник мог выпустить на своё имя для интеграций, и проверить журнал действий организации: не осталось ли гостевых ссылок, которые он создавал и не отозвал. Оба пункта находятся на отдельных экранах в организации и не требуют менять пароли остальной команде.
Оставьте контакты: перезвоним в течение 15 минут и подберём решение под вашу задачу.
© 2026 Сэйфком. ИП Михайлов А.И. Все права защищены.