Увольнение сотрудника: как закрыть доступ, не потеряв аккаунты
Как агентствам и командам закрывать доступ сотрудникам и подрядчикам без потери рекламных кабинетов, соцсетей и доступов — чек-лист и типичные ошибки.
Сотрудник увольняется, фрилансер заканчивает проект, подрядчик меняет агентство — и в этот момент выясняется, что доступ к десяткам рекламных кабинетов, соцсетей и личных кабинетов маркетплейсов завязан на его телефон, его почту для 2FA и его личный Chrome-профиль. Формально договор расторгнут, но фактически аккаунты всё ещё у него в руках.
Это не редкий случай. В медиабаинге, SMM-агентствах и e-commerce команды растут и меняются быстрее, чем выстраиваются процессы доступа. Пока сотрудник на месте, никто не задумывается, кто именно держит пароли и коды. Проблема вскрывается только в момент расставания — и часто уже поздно.
Почему это системная проблема, а не исключение
Классическая схема выдачи доступа выглядит так: таблица с логинами и паролями в Google Docs, 2FA на личный номер сотрудника, рабочие аккаунты открыты в его личном браузере на его ноутбуке. Это работает, пока отношения ровные. Но как только возникает конфликт — задержка зарплаты, спор о KPI, обида на увольнение — у бывшего сотрудника остаётся физический контроль над активами компании:
- он может сменить пароль раньше, чем вы успеете среагировать;
- 2FA привязана к его телефону — без него вы не зайдёте даже с правильным паролем;
- cookies и сессии живут в его личном браузере, и формальный «доступ закрыт» ничего не меняет, пока сессия активна;
- если аккаунты вели через его личные прокси или с его устройства, смена пароля не защищает от того, что он просто продолжит пользоваться сессией.
При этом есть и обратная сторона: если доступ отзывают резко и без процедуры, можно случайно заблокировать рабочие аккаунты собственными руками — слишком частая смена паролей и IP с точки зрения площадки выглядит как компрометация аккаунта, и его замораживают для проверки.
Правильный оффбординг — это не «нажать одну кнопку», а последовательность шагов, продуманная заранее, желательно ещё на этапе онбординга.
Готовиться нужно заранее, а не в день увольнения
Безопасный выход сотрудника возможен только тогда, когда доступ изначально выдавался правильно. Если с первого дня все рабочие аккаунты велись из профилей с ролями и ограничением прав, а не из личного браузера сотрудника, закрытие доступа — вопрос пары минут. Если же человек сам заводил аккаунты «как ему удобно», в своём браузере, на свой номер — распутывать это придётся вручную, иногда неделями.
Поэтому первый практический совет звучит не как часть чек-листа на день увольнения, а как требование к архитектуре работы в принципе: профили клиентов и рекламных кабинетов должны жить в общем пространстве команды, а не в личных браузерах сотрудников. Подробно о том, как выстроить роли, лимиты и процедуру передачи профилей между сотрудниками, разобрано в статье о командной работе с профилями, ролях и лимитах.
- lev открыл Airdrop zkSync 07
- artem закрыл FB · US · BM-14
- maya смотрит браузер artem
- lev передал TikTok Shop 03
Чек-лист: что проверять в день, когда сотрудник уходит
Ниже — последовательность действий, которую стоит пройти целиком, даже если кажется, что часть пунктов не нужна в конкретном случае. Пропущенный шаг обычно всплывает через месяц в виде «а почему у нас аккаунт заблокирован» или «а кто вообще имеет доступ к этому кабинету».
| Шаг | Что делать | Почему это важно |
|---|---|---|
| 1. Фиксация объёма доступа | Выгрузить список всех профилей, кабинетов и сервисов, к которым у человека был доступ | Без полного списка часть доступов останется незамеченной |
| 2. Отзыв роли в системе | Снять роль и права в общем пуле профилей | Человек теряет возможность открыть профили сразу, без ожидания |
| 3. Передача владения профилями | Переназначить профили на другого сотрудника или общий пул | Профили не исчезают вместе с увольнением |
| 4. Смена паролей профилей | Сменить пароль там, где он был известен уходящему | Старые сохранённые данные не дают доступа после смены |
| 5. Ротация 2FA | Перепривязать двухфакторную аутентификацию на рабочий номер/почту | Самый частый способ, которым бывший сотрудник сохраняет контроль |
| 6. Проверка сессий и cookies | Выйти из активных сессий, при необходимости — сбросить cookies | Активная сессия не требует пароля вообще |
| 7. Проверка расширений и API-ключей | Отозвать токены автоматизации, проверить установленные расширения | Автоматизация могла работать на личных ключах сотрудника |
| 8. Проверка прокси | Отключить прокси, которые покупались или настраивались лично сотрудником | Он может видеть трафик или сохранить доступ к панели прокси-провайдера |
| 9. Просмотр журнала активности | Проверить последние действия перед увольнением | Выявляет попытки скачать базы, сменить email или привязать новый номер |
| 10. Фиксация в документации | Обновить список ответственных за кабинеты | Чтобы следующий оффбординг не начинался с нуля |
Это универсальная последовательность, но вес каждого пункта разный в зависимости от того, кто уходит — штатный сотрудник, фрилансер или подрядное агентство.
Штатный сотрудник, фрилансер и подрядчик — разная логика риска
Штатный сотрудник обычно работает с корпоративными инструментами, у него есть рабочая почта и, скорее всего, подписанные NDA. Риск здесь не столько в злом умысле, сколько в инерции: он может просто забыть, что всё ещё залогинен в десяти кабинетах с личного телефона, если 2FA была привязана к нему. Здесь оффбординг — в первую очередь гигиена: отозвать, перепривязать, проверить.
Фрилансер — более рискованная категория, потому что у него часто нет единой точки входа: он мог заводить отдельные аккаунты под проект, использовать свои прокси, вести переписку с подрядчиками площадки от своего имени. При окончании сотрудничества важно не просто забрать пароль, а убедиться, что сам аккаунт зарегистрирован на данные компании или клиента, а не на почту фрилансера — иначе он формально остаётся владельцем даже после смены пароля и может восстановить доступ через поддержку площадки.
Подрядное агентство, которое вело клиентские кабинеты, — отдельная история: здесь оффбординг происходит не внутри одной команды, а между двумя юрлицами. Если агентство использовало общий пул профилей и доступов, по окончании контракта все профили клиента должны быть переданы заказчику или новому подрядчику целиком, со сменой паролей, 2FA и ревизией прокси. Если профили клиента крутились в личных браузерах сотрудников агентства, передача превращается в болезненную миграцию: нужно заново прогревать аккаунты, восстанавливать cookies, настраивать окружение с нуля. Проблемы такого рода и способы восстановления доступа, когда аккаунт уже «просел», разобраны в статье про диагностику и восстановление спалившегося профиля — многие из описанных там симптомов возникают именно после неаккуратной передачи доступов.
Передача профиля без раскрытия пароля
Главная техническая проблема оффбординга — как передать рабочий аккаунт новому ответственному, не разглашая пароль человеку, который до этого им не пользовался, и не теряя при этом прогретую сессию, cookies и историю.
Если профили организованы как изолированные окружения с управляемым отпечатком, а не как записи в таблице, задача решается без драмы: профиль просто переназначается другому члену команды внутри общего пула, вместе с cookies, историей и привязанным прокси. Новый ответственный получает рабочее окружение таким, какое оно есть, без необходимости заново логиниться и рисковать подозрительным входом с нового устройства или IP — для площадки это выглядит как продолжение той же сессии, а не как смена пользователя.
Это особенно полезно в переходный период: пока новый сотрудник не до конца освоился, можно наблюдать за его работой в профиле в режиме живого просмотра, а при необходимости — подключиться и подправить настройки удалённо, не прося его передавать пароль обратно.
Отдельная тема — ключи двухфакторной аутентификации. Если коды 2FA хранятся не в личном приложении сотрудника, а в хранилище, привязанном к самому профилю, ротация доступа не требует судорожной переустановки Google Authenticator на новый телефон и подтверждения через службу поддержки площадки. Код просто становится доступен тому, кому назначен профиль.
Подробнее о том, как устроено шифрование профильных данных и хранилище 2FA, и почему сервер не может прочитать содержимое профиля даже теоретически, — в статье про шифрование и хранилище 2FA профилей. Для оффбординга это значит простую вещь: даже если бывший сотрудник каким-то образом получит доступ к серверу (что по архитектуре и так исключено), расшифровать данные профиля без пароля аккаунта компании он не сможет.
Типичные ошибки при закрытии доступа
Удалить пользователя, не тронув профили. Если роль сотрудника отозвана, но пароли и 2FA остались прежними, а сессии — активными, формальный «отзыв доступа» ничего не меняет на уровне самих площадок. Человек может продолжать пользоваться открытой сессией в своём браузере сколько угодно.
Сменить всё одновременно и резко. Массовая смена паролей, выход из всех сессий и смена IP в один момент для десятков аккаунтов выглядит для площадок подозрительно и может спровоцировать блокировки для проверки безопасности — именно тех аккаунтов, которые вы пытаетесь защитить. Разумнее проводить ротацию пакетами, растянутыми на день-два, особенно для аккаунтов с историей и репутацией.
Забыть про привязанную почту. Если восстановление доступа к рекламному кабинету или соцсети идёт через email, а этот email тоже вёл уходящий сотрудник (или зарегистрирован на его имя), смена пароля в самом кабинете ничего не решает — он восстановит доступ через почту за пять минут.
Не проверить автоматизацию. Если сотрудник настраивал скрипты через Puppeteer или Playwright для прогрева или рутинных действий, у него могли остаться локальные API-токены или сохранённые сессии в коде. Разбор того, как устроена локальная автоматизация профилей и на что обращать внимание при передаче скриптов, — в материале про автоматизацию профилей через Puppeteer и Playwright.
Полагаться на устную договорённость. «Он обещал удалить все данные» — не процедура. Нужна фиксация: кто, когда и что именно проверил при закрытии доступа, желательно с привязкой к журналу активности, а не к памяти менеджера.
Журнал активности как инструмент, а не формальность
Отдельно стоит сказать про логи. Многие команды включают журнал активности формально, «на всякий случай», и никогда в него не заглядывают. При оффбординге это первое, что стоит открыть: кто и когда последний раз заходил в профиль, менял настройки, экспортировал cookies, подключал новое расширение. Если за день до официального увольнения сотрудник внезапно выгрузил cookies десятка клиентских аккаунтов — это повод не просто сменить пароли, а разобрать ситуацию детальнее, возможно, с привлечением юриста, если речь о клиентских данных агентства.
Журнал также полезен для разграничения ответственности, когда аккаунт блокируют уже после ухода человека: можно проверить, не было ли подозрительных действий именно в последние дни его работы, вместо того чтобы винить случайность.
Масштаб проблемы растёт вместе с командой
Для фрилансера с пятью профилями оффбординг — вопрос получаса. Для агентства с десятками сотрудников и сотнями профилей клиентов без процедуры и ролевой модели это превращается в хаос при каждой кадровой перестановке. Если команда уже выросла до такого масштаба, имеет смысл сначала навести порядок в самой структуре пула профилей — как это сделать, подробно разобрано в статье про организацию сотен профилей без хаоса. Без базовой структуры — групп, тегов, назначенных ответственных — закрытие доступа одному человеку превращается в археологические раскопки по всей базе.
В GetAntik для этого есть ролевая модель с лимитами на уровне участника команды, журнал активности, передача профилей между сотрудниками без раскрытия пароля и шифрование данных на устройстве паролем аккаунта — то есть сама архитектура не позволяет уходящему сотруднику «унести» профиль с собой, даже если он скопирует файлы локально. Полный список возможностей команды можно посмотреть на странице командной работы, а детали шифрования и безопасности — на странице безопасности профилей.
FAQ
Нужно ли менять прокси при оффбординге, если сотрудник их не покупал сам? Если прокси были закреплены за профилем централизованно, через общий менеджер команды, трогать их не обязательно — смена IP без причины может насторожить площадку. Менять стоит только те прокси, к панели которых у уходящего был личный доступ.
Что делать, если аккаунт зарегистрирован на личную почту сотрудника, а не компании? Это нужно исправлять до увольнения, а не после: сменить привязанный email на корпоративный заранее, пока сотрудник ещё лоялен и готов подтвердить смену через свою почту. После ухода сделать это будет либо невозможно, либо потребует обращения в поддержку площадки с доказательствами владения бизнесом.
Сколько времени должна занимать полная процедура оффбординга? Для одного сотрудника с десятком-двумя профилей — обычно час-два на сам процесс плюс день-два на растянутую ротацию паролей и 2FA, чтобы не спровоцировать блокировки по подозрению в компрометации.
Стоит ли уведомлять площадку о смене ответственного за кабинет? Для рекламных кабинетов и бизнес-аккаунтов многих платформ это прямо предусмотрено правилами — лучше оформить смену администратора официально, через встроенные настройки доступа площадки, а не просто сменить пароль с её же стороны.
Как часто пересматривать список доступов, если команда не меняется месяцами? Раз в квартал полезно сверять список ответственных за ключевые кабинеты с фактическим составом команды — часто обнаруживается, что доступ остался у человека, который давно сменил роль внутри компании, хотя формально не увольнялся.