Вы вводите правильный пароль, а сервис просит ещё один код. Это второй этап проверки: знание пароля само по себе больше не открывает аккаунт. Для владельца сайта есть и другой важный вопрос: кто сможет войти, если телефон с кодами потеряется или сотрудник уйдёт из компании?
В Гуси-Лебеди мы предлагаем рассматривать защиту и восстановление вместе. Разберём, что означает 2FA, чем отличаются способы подтверждения и как организовать рабочие доступы без зависимости от одного человека.
Что такое двухфакторная аутентификация и какой способ выбрать
Двухфакторная аутентификация, или 2FA, проверяет личность через два разных фактора. Пароль относится к тому, что вы знаете. Настроенное устройство или ключ подтверждает то, чем вы владеете. Биометрическая проверка относится к вашим физическим признакам. Два пароля, даже совершенно разных, остаются одной категорией. Этот принцип разобран в рекомендациях OWASP по многофакторной аутентификации.
MFA означает многофакторную аутентификацию; 2FA является её частным случаем с двумя факторами. Аутентификация отвечает на вопрос «кто входит», авторизация определяет, что вошедшему разрешено делать. Поэтому второй фактор не отменяет настройку ролей: редактору сайта по-прежнему не нужны права владельца хостинга.
Представим обычный вход в рабочую почту: сначала пароль, затем код из приложения. Если пароль стал известен постороннему, ему ещё нужно пройти вторую проверку. Однако полученный код тоже можно выманить. Например, предложить ввести его на странице, похожей на настоящую. Не стоит воспринимать любую надпись «2FA включена» как одинаковый уровень защиты.
| Способ | Как проходит подтверждение | Что учесть перед выбором |
|---|---|---|
| SMS | Код приходит на привязанный номер | Нужен доступ к номеру; возможны атаки на телефонный номер |
| Приложение-аутентификатор | Вы вводите сгенерированный одноразовый код | Продумайте перенос приложения; код нельзя передавать другому человеку |
| Push-уведомление | Вы подтверждаете запрос на устройстве | Сверяйте запрос со своим действием и отклоняйте неожиданный вход |
| Ключ доступа или совместимый аппаратный ключ | Вход подтверждается через настроенное устройство или ключ | Проверьте поддержку сервисом и запасной способ входа |
В справке Google описаны эти варианты, работа кодов приложения без мобильной сети и защита ключей доступа от фишинга. Ключ доступа может заменять пароль, поэтому экран входа не обязательно содержит два последовательных поля.
Выбор начинайте с возможностей конкретного сервиса. Что доступно сотрудникам? Можно ли подключить запасное средство? Кто управляет устройством? Подойдёт ли способ для ежедневной работы? Для административных аккаунтов отдельно оцените устойчивые к фишингу способы. Не обещайте себе «полную безопасность»: защита устройства, права участников и действующие сессии остаются отдельными задачами.
С каких аккаунтов начать и как включить защиту
Не начинайте со случайной галочки в настройках CMS. Сначала найдите доступы, через которые восстанавливаются остальные. В проекте это может быть основная почта, учётная запись владельца домена или административный аккаунт. Очерёдность зависит от ваших реальных связей между сервисами.
Вот пример зависимости, которую полезно разобрать: рекламный кабинет восстанавливается через почту сотрудника, а почта привязана к его личному номеру. Даже если второй фактор включён в кабинете, компания ещё зависит от этой цепочки восстановления. Вопрос решается проверкой владения и ролей, а не добавлением второго общего пароля.
Составьте реестр рабочих систем: домен, хостинг, сайт, почта, аналитика, рекламные кабинеты, репозиторий и нужные интеграции. Для каждой запишите владельца, ответственного и доступных участников. Реестр не должен содержать сами пароли, коды или секрет настройки приложения. Его задача: показать, кто управляет доступом и где хранится утверждённая инструкция.
Далее настройте защиту одного аккаунта и проверьте результат, прежде чем переходить к следующему:
- Убедитесь, что аккаунт принадлежит нужному владельцу и текущий вход работает.
- Откройте официальные настройки безопасности этого сервиса. Посмотрите поддерживаемые способы и условия восстановления.
- Подключите выбранное средство подтверждения и завершите проверку, которую предлагает площадка.
- Подготовьте доступный резервный вариант. Если сервис выдаёт коды восстановления, сохраните их в согласованном защищённом месте.
- Проверьте новый вход, сохраняя действующий предусмотренный сервисом путь доступа. Не удаляйте единственное средство подтверждения ради эксперимента.
Например, в аккаунте Google нужный раздел называется «Безопасность и вход», затем «Вход в Google» и «Включить двухэтапную аутентификацию». Для рабочего аккаунта доступность настройки может зависеть от администратора. Это пример для одного сервиса: переносить названия пунктов на Яндекс, хостинг или CMS нельзя.
Если сотрудники пользуются общим логином, настройка 2FA не создаст отдельные роли автоматически. Где площадка позволяет, выдавайте персональные учётные записи с нужными полномочиями. Если общего входа пока не избежать, определите владельца и порядок работы. Передавать одноразовые коды по общему чату как постоянный процесс неудобно и затрудняет контроль.
Как не потерять доступ при замене или потере телефона
Главная ошибка: планировать восстановление после того, как телефон уже недоступен. Резервный способ нужно подготовить заранее и хранить так, чтобы потеря основного устройства не уничтожила его одновременно.
Резервный код и код из приложения имеют разное назначение. Приложение выдаёт временное подтверждение для входа. Резервный код предоставляет отдельный предусмотренный сервисом путь. Условия его использования, замены и хранения читайте у площадки. Не помещайте список кодов в общедоступную таблицу и не отправляйте снимок QR-кода настройки коллегам.
Если меняете телефон, сначала изучите перенос именно вашего приложения и правила сервиса. Добавьте или перенесите средство подтверждения, проверьте вход с нового устройства. После успешной проверки завершите замену по инструкции площадки. Не рассчитывайте, что установка приложения с тем же названием автоматически вернёт все аккаунты.
Если телефон потерян, откройте официальный экран входа и найдите предложенные дополнительные варианты. Это могут быть заранее настроенный ключ, резервный код или процедура восстановления. Используйте то, что действительно подключено к вашему аккаунту. Сохранённая сессия на другом устройстве не даёт гарантии, что сервис разрешит изменить настройки без дополнительной проверки.
Если ничего не сохранилось, проверьте официальные условия восстановления и обратитесь в поддержку, когда такая процедура предусмотрена. Не покупайте обещание «снять 2FA». Например, GitHub предупреждает об ограничениях восстановления: при потере всех предусмотренных средств поддержки может быть недостаточно для возврата доступа. Это правило GitHub, а не универсальное правило каждого сайта.
Если код не приходит или не подходит, сначала уточните выбранный способ. SMS нужно ждать на привязанном номере; код приложения берётся из записи нужного аккаунта. Не вводите подряд коды от других сервисов и не подтверждайте чужие запросы. Дальше используйте инструкцию по ошибке и доступный резервный путь. Срок действия кода, лимит попыток и способы восстановления отличаются, поэтому общей команды для всех площадок нет.
В компании назначьте ответственного за процедуру восстановления и определите, кто вправе её запускать. Формулировка «коды где-то у подрядчика» не подходит для рабочего аккаунта. При передаче сайта на поддержку этот вопрос стоит разобрать вместе с доменом, хостингом и почтой.
Что проверить после настройки и при уходе сотрудника
Открытая вкладка ещё не доказывает, что новый вход защищён. Проверьте авторизацию в отдельной сессии предусмотренным сервисом способом. Убедитесь, что нужный пользователь действительно проходит выбранную проверку. Зафиксируйте дату, аккаунт и результат без паролей, одноразовых кодов и секретов настройки.
Сотруднику нужна короткая рабочая инструкция: как войти, кому сообщить о потере устройства и что делать с неожиданным запросом подтверждения. Например, уведомление о входе приходит во время встречи, когда человек не открывал сервис. Подтверждать его «чтобы перестало мешать» нельзя. Следует отклонить запрос и проверить активность через официальный аккаунт.
При уходе участника команды проверяйте не только его второй фактор. Пройдите по реестру систем, отзовите ненужные роли и приглашения, передайте владение там, где это требуется. Действующие сессии, ключи интеграций и токены учитывайте отдельно по правилам каждого сервиса. Одна смена пароля или удаление телефона не подтверждает, что закрыты все способы доступа.
Рассмотрим пример: сайт передан новому специалисту, но прежний подрядчик остаётся владельцем аккаунта хостинга. Второй фактор на телефоне нового специалиста не исправляет владение. Сначала нужно оформить передачу предусмотренным хостингом способом, затем проверить участников, защиту и восстановление.
Мы советуем принимать настройку по понятным признакам: владелец определён, новый вход проверен, резервный путь подготовлен, лишние участники удалены, инструкция доступна ответственному. Если часть пунктов не закрыта, запишите конкретную проблему и исполнителя. Так проще управлять защитой, чем хранить одну отметку «2FA есть».
Для сайта это часть контроля доступов и безопасности. В Гуси-Лебеди мы предлагаем начинать с вопроса «кто и как управляет проектом». Второй фактор помогает защитить вход; порядок владения и восстановления помогает сохранить управление, когда меняются люди и устройства.