Сотрудник уходит из компании: как передать и отозвать доступы к сайту

Рассматривайте сайт вместе с сервисами, от которых он зависит

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

Начните с перечня систем: домен, хостинг, панель сайта, рабочая почта, аналитика, кабинеты поиска, CRM, сервисы форм, оплаты и доставки, хранилище исходников и резервных копий. Включайте применимые пункты, а не все возможные сервисы. Главный вопрос — где уходящий сотрудник может менять работу сайта или восстанавливать доступ к ней.

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

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

Отделите владение от права редактировать

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

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

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

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

Соберите реестр с результатом для каждого ресурса

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

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

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

Согласуйте момент передачи и отзыва прав

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

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

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

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

Проверьте общие пароли, устройства и ключи приложений

Удаление сотрудника из одной панели не отменяет автоматически все известные ему способы доступа. Проверьте общие учётные записи, сохранённые сеансы, доступ через корпоративные группы и разрешения подключённых приложений. Конкретный набор действий зависит от сервиса: универсальная кнопка «отозвать всё» может отсутствовать.

В справке Яндекс ID о безопасности отдельно описаны устройства и активность аккаунта. Это пример того, почему смену состава пользователей нужно дополнять проверкой действующих способов входа. Не переносите поведение одного сервиса на все остальные; исполнитель должен сверить официальную инструкцию каждого используемого продукта.

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

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

Подтвердите оба результата: права отозваны, работа продолжается

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

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

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

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

Оставьте незавершённые случаи видимыми

Иногда обнаруживается ресурс без известного владельца или кабинет, где перенос требует участия поставщика. Не закрывайте весь реестр формулировкой «доступы переданы», если такой пункт остаётся. Укажите конкретный ресурс, недостающее полномочие, текущий риск, ответственного и следующий срок. Это позволяет руководителю принять осознанное решение по оставшейся работе.

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

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

Для временного порядка установите дату окончания и способ контроля. Например, перенос ожидает ответа поддержки, а компания уже получила отдельную рабочую роль и канал уведомлений. Это уменьшает зависимость, но не означает завершённую передачу владения. Регулярно проверяйте именно оставшийся пункт, а не повторяйте весь процесс без причины.

Завершите передачу коротким актом и обновите учёт

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

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

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

Чтобы организовать передачу и проверку доступов к сайту, начните с владельца домена, хостинга, CMS и маршрута заявки. Затем расширьте перечень до всех применимых зависимостей. Состав дальнейшего сопровождения можно сверить с материалом о технической поддержке. Завершённая передача оставляет компании проверенный контроль и понятный список дальнейших обязанностей.