Как отозвать доступы сотрудника или подрядчика к сервисам интернет-магазина

Сотрудник или подрядчик ушёл: как отозвать доступы ко всем сервисам интернет-магазина

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

Практический порядок такой:

1. определить, к каким сервисам и каким способом человек имел доступ;
2. в первую очередь закрыть доступы, через которые можно влиять на другие аккаунты или критичные процессы;
3. удалить персональные учётные записи, роли и представительские права;
4. закрыть доступ к корпоративному хранилищу учётных данных;
5. сменить общие пароли, которые человек мог сохранить;
6. проверить второй фактор и восстановление аккаунтов;
7. отозвать или перевыпустить API-ключи, токены и другие учетные данные;
8. отдельно завершить активные сессии, если сервис это позволяет;
9. проверить доступ агентств, внешних приложений и партнёрских аккаунтов;
10. убедиться, что все критичные системы снова полностью контролируются компанией.

Главное — не искать одну кнопку "отозвать доступ сотрудника". Пароль, пользователь, токен, второй фактор, активная сессия и доступ агентства — разные сущности, и отключаются они по-разному.

Сначала определите, что нужно закрыть в первую очередь

Начинать отзыв доступов удобнее не с длинного перечня всех сервисов, а с вопроса:

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

Обычно особого внимания требуют:

• корпоративная почта;
• менеджер паролей;
• домен и DNS;
• хостинг и другая критичная инфраструктура;
• платёжные и финансовые сервисы;
• административный доступ к CMS и CRM;
• маркетплейсы;
• рекламные кабинеты.

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

Ищите не только сервисы, но и способы доступа

У одного человека может быть одновременно несколько независимых способов попасть в одну и ту же систему.

Например, разработчик мог иметь:

• отдельного администратора в CMS;
• общий пароль от хостинга;
• API-токен интеграции;
• сохранённую активную сессию;
• доступ к корпоративной почте;
• запись с учётными данными в менеджере паролей.

Удаление администратора CMS в такой ситуации закрывает только один из этих каналов.

Полезно пройти каждый сервис по простой матрице:

Эта проверка важнее формального списка «CMS — CRM — маркетплейс — реклама». В каждом из этих сервисов могут использоваться разные механизмы авторизации.

Удалите персональные учётные записи и роли

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

Это может означать разные действия:

• удалить пользователя;
• заблокировать аккаунт;
• снять права администратора;
• убрать доступ к отдельному разделу;
• удалить представителя.

Не стоит считать эти действия взаимозаменяемыми.

Если использовался общий аккаунт — проверьте пароль отдельно

С персональными пользователями всё относительно просто: доступ конкретного человека можно удалить, не затрагивая остальных.

С общими аккаунтами иначе.

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

Поэтому:

удаление человека из менеджера паролей не делает уже известный ему пароль недействительным.

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

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

Микро-пример: подрядчика удалили из рабочего чата и закрыли ему корпоративное хранилище. Через месяц выяснилось, что административный пароль старой CMS никто не менял. Формально подрядчика в инфраструктуре компании уже нет, но известный ему пароль продолжает работать.

Проверьте 2FA и восстановление аккаунтов

Второй фактор нельзя сводить к пункту «проверить 2FA». Нужно понять, какой именно фактор был связан с человеком.

Персональный второй фактор

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

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

Общий TOTP

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

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

Резервные коды

Резервные коды нужно считать отдельными ключами доступа.

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

Способы восстановления

Отдельно проверьте:

• номер телефона;
• резервную электронную почту;
• контрольные или дополнительные способы восстановления;
• зарегистрированные аппаратные ключи;
• другие методы, которые предлагает конкретный сервис.

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

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

Отдельно отзывайте API-ключи и токены

Для разработчиков, интеграторов и технических подрядчиков обычные пользовательские аккаунты — только часть картины.

Проверьте:

• API-ключи;
• персональные и сервисные токены;
• токены доступа (access tokens);
• пароли приложений (app passwords);
• ключи интеграций;
• OAuth-подключения сторонних приложений.

Удаление человека из CMS или маркетплейса не следует считать автоматическим отзывом таких ключей.

Если токен используется только ушедшим подрядчиком — его можно отозвать.

Сложнее, если один и тот же ключ используется одновременно действующей интеграцией и бывшим разработчиком. Тогда немедленное удаление может остановить рабочую систему. В таком случае обычно требуется:

1. создать новый токен;
2. заменить его в действующей интеграции;
3. проверить работу;
4. отозвать старую.

Не забудьте OAuth-подключения

Некоторые сторонние сервисы работают не через вручную переданный токен, а через OAuth.

Такой доступ тоже нужно проверять отдельно.

Поэтому проверка только списка вручную созданных API-токенов может быть неполной.

Смена пароля и завершение сессий — не одно действие

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

Нельзя исходить из универсального правила «сменили пароль — все устройства автоматически вышли». Поведение зависит от конкретного сервиса.

Если сервис показывает активные устройства или позволяет выполнить "Выйти везде", используйте этот механизм как отдельный этап отзыва доступов.

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

Поэтому вопрос при увольнении должен звучать не только "сменили ли пароль?", но и:

"что произошло с уже открытыми сессиями?"

Проверьте представителей, агентства и другие внешние связи

Доступ может принадлежать не конкретному сотруднику магазина, а внешней организации или другому аккаунту.

Типовые варианты:

• рекламное агентство;
• представитель;
• управляющий аккаунт;
• партнёрский кабинет;
• внешнее приложение;
• подрядная организация.

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

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

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

Как проверить, что доступ действительно закрыт

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

Для каждого критичного сервиса ответьте на следующие вопросы:

• Есть ли бывший сотрудник среди активных пользователей?
• Остались ли у него роли администратора или другие права?
• Закрыты ли представительские и агентские связи?
• Изменены ли общие пароли, которые он мог сохранить и дальнейшее использование которых создаёт риск?
• Удалены ли связанные с ним факторы 2FA?
• Перевыпущены ли резервные коды, если это требовалось?
• Контролирует ли компания телефон и почту восстановления?
• Отозваны ли ненужные API-ключи и токены?
• Проверены ли OAuth и другие подключённые приложения?
• Завершены ли активные сессии там, где это необходимо и возможно?
• Есть ли у компании действующий администратор или владелец аккаунта вместо ушедшего человека?

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

Хороший результат отзыва доступов выглядит не как "мы убрали сотрудника из списка", а как:

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

Практический чек-лист отзыва цифровых доступов

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

• Собрать перечень сервисов, с которыми работал человек.
• Для каждого сервиса определить способ доступа: пользователь, роль, общий пароль, 2FA, токен, сессия, представитель, интеграция.
• Выделить критичные системы и те, через которые восстанавливается доступ к другим аккаунтам.
• Удалить, заблокировать или отключить персональные учётные записи.
• Отозвать ненужные административные и делегированные роли.
• Удалить человека из корпоративного менеджера паролей.
• Сменить общие пароли, которые он мог сохранить и дальнейшее использование которых создаёт риск.
• Проверить персональные факторы 2FA, общий TOTP, резервные коды и восстановление.
• Найти и отозвать или перевыпустить API-ключи, токены и другие ключи доступа.
• Проверить OAuth и подключённые сторонние приложения.
• Просмотреть и при необходимости завершить активные сессии.
• Отозвать агентский, представительский и партнёрский доступ.
• Убедиться, что почта, телефон и другие способы восстановления критичных аккаунтов принадлежат компании или контролируются ею.
• Проверить, что у каждого критичного сервиса остался действующий ответственный.
• Зафиксировать, кто провёл проверку и какие действия выполнены.

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

Почему хаотичное хранение паролей особенно мешает при увольнении

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

Приходится восстанавливать историю по перепискам:

• отправляли ли разработчику пароль от CMS;
• получало ли агентство общий вход в аналитику;
• был ли у сотрудника пароль от хостинга;
• какие доступы менялись после этого;
• какие значения всё ещё актуальны.

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

Как Кейра помогает при отзыве доступов

Кейра решает именно ту часть задачи, которая связана с корпоративными учётными данными и общими аккаунтами.

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

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

Но здесь важно ограничение:

удаление человека из Кейра само по себе не завершает отзыв доступов.

Оно не заменяет:

• удаление пользователя в CMS, CRM или маркетплейсе;
• отзыв представительского доступа;
• смену уже известного общего пароля;
• отзыв API-токена;
• изменение способов восстановления;
• отключение внешней интеграции;
• завершение активных сессий стороннего сервиса.

Поэтому Кейра стоит рассматривать не как универсальную кнопку "отключить сотрудника везде", а как инструмент, который делает работу с корпоративными учётными данными и общими аккаунтами предсказуемой.

Итог: отключение сотрудника — это отзыв способов доступа, а не удаление человека из одного списка

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

Нужно проверить, какие способы доступа человек мог сохранить:

пользователь → роль → общий пароль → второй фактор → восстановление → токен → сессия → интеграция → представительский доступ.

Каждый из них закрывается своим способом.

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

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

Если такая проблема есть и у вас, ознакомьтесь с Кейра — решением для централизованной работы с корпоративными учётными данными и общими аккаунтами. Это поможет сделать выдачу и последующий отзыв доступа к рабочим паролям более управляемыми и не восстанавливать историю доступов по старым перепискам при каждом увольнении или смене подрядчика.