Рабочие доступы не должны принадлежать сотруднику
Домен, аналитика, реклама и облака должны переживать смену сотрудников без экстренного восстановления.
Правильный владелец
У сервиса должен быть контролируемый рабочий владелец, а сотрудникам выдаются отдельные роли или приглашения. Если сервис не поддерживает роли, зафиксируйте владельца и аварийный доступ отдельно.
При увольнении
- отозвать персональные сессии;
- удалить или сменить роль;
- проверить API-ключи и токены;
- убедиться, что почта восстановления не личная.
Особенно проверьте домены: домен на личном аккаунте сотрудника создаёт зависимость, которую обычные рабочие роли не решают.
Проверьте это на своей системе
Цель — не просто включить нужную настройку, а убедиться, что она реально работает в сценарии потери доступа, смены устройства или передачи управления.
Критичные сервисы должны быть привязаны к рабочей почте или управляемой корпоративной учётной записи.
Где возможно, используйте приглашения и роли, чтобы видеть владельца каждого действия.
Минимум один контролируемый администратор должен оставаться независимо от конкретного сотрудника.
Порядок действий
- Откройте настройки, связанные с темой «Рабочие доступы не должны принадлежать сотруднику», на доверенном устройстве и сначала зафиксируйте текущее состояние.
- Пройдите три проверки выше без отключения рабочего доступа: рабочая идентичность, роли вместо общих паролей и резерв администратора.
- Если обнаружили зависимость от одного телефона, адреса, сотрудника или устройства, сначала добавьте независимую замену и подтвердите её.
- После изменения выполните контрольный вход или восстановление из второго браузера/устройства, не закрывая последнюю рабочую сессию.
Где чаще всего возникает проблема
- Сотрудник является единственным владельцем домена, аналитики или облака через личный аккаунт.
- Команда использует один общий пароль, поэтому невозможно точечно отозвать доступ.