Как команде с несколькими аккаунтами управлять 2FA: роли аутентификатора, резервных кодов и передачи аккаунтов

Студии, которые ведут командную работу в e-commerce или соцсетях, при смене людей часто упираются в 2FA. Один из операторов уходит, а из десятка с лишним платформенных аккаунтов под его именем у половины включена двухфакторная проверка. Аутентификатор стоит на его личном телефоне: пароль можно сменить на месте, а шестизначный код для входа остаётся ждать только от его телефона.

Корень проблемы в том, что при личном использовании 2FA выглядит как выключатель безопасности: включил и забыл. В команде с несколькими аккаунтами она превращается в три вида активов, требующих постоянного управления: где стоит аутентификатор, где лежат резервные коды и как передать доступ, когда человек уходит. Если хоть один вид не организован, аккаунт застревает на этапе проверки. В худшем случае команда остаётся снаружи.

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

Когда аккаунтов много, 2FA превращается из переключателя безопасности в объект эксплуатации

Принцип 2FA объясняется одним предложением. Помимо пароля при входе нужен второй фактор проверки, который есть только у владельца аккаунта. Трудность не во включении, а в том, что при росте числа аккаунтов второй фактор расползается от личного телефона к целому набору устройств и материалов команды, и объект управления меняется. Конкретные изменения сосредоточены в трёх местах:

• Рост количества: у сотрудника с десятком записей в аутентификаторе уже не выходит разобрать, какая запись к какому аккаунту относится, и при перепривязке он перебирает их по одной.
• Разделение среды и проверки: антидетект-браузер закрепляет среду входа каждого аккаунта, Cookie, отпечаток и прокси независимы, поэтому риск-контроль редко срабатывает из-за дрейфа среды. Но второй фактор это настройка безопасности аккаунта на стороне платформы, она действует вне браузера, и изоляция среды её не заменяет.
• Текучка людей: аутентификатор уходит вместе с человеком, и увольнение превращается в вопрос передачи.

Все три изменения ведут к одному выводу: для 2FA нужен командный процесс, а не надежда на то, что каждый участник помнит, где он что привязал.

Сначала выберите схему развёртывания аутентификатора: с человеком или с аккаунтом

Популярные приложения-аутентификаторы генерируют одноразовые коды по спецификации IETF RFC 6238, известной как TOTP. После привязки аутентификатор выдаёт коды по времени и меняет их каждые 30 секунд, интернет для этого не нужен. Именно этот механизм делает аутентификатор переносимым. Заново внесите секрет на другом устройстве, и коды продолжат появляться как раньше.

Способы проверки различаются по стойкости. Американское агентство кибербезопасности CISA формулирует в своём руководстве по MFA так: любой MFA лучше, чем ничего, но методы не равноценны. Самый слабый вариант это код по SMS. Приложение-аутентификатор с сопоставлением номера надёжнее, а защита от фишинга вроде FIDO/WebAuthn самая сильная среди широко доступных схем. Командам с несколькими аккаунтами стоит как минимум избегать SMS. Смена номера или перевыпуск карты прерывают проверку, а номера с сервисов приёма SMS добавляют лишние сигналы связанности.

По развёртыванию есть всего два подхода:

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

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

Схему можно выбирать по весу аккаунта:

1. Ключевые аккаунты с выручкой: с аккаунтом. Ими пользуются разные люди, второй фактор обязан передаваться, а резервные коды ведутся отдельно.
2. Средние аккаунты и длинный хвост: допустимо с человеком, при передаче добавляется одно перепривязывание, чтобы окно риска оставалось коротким.
3. Платформы с поддержкой FIDO: сначала аппаратный ключ или Passkey, чтобы выжать всю защиту от фишинга, а при невозможности возврат к приложению-аутентификатору.

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

Резервные коды как слой восстановления: одна выдача, ведение до отзыва

Резервные коды это набор статических кодов восстановления, который платформа выдаёт один раз при включении 2FA; если аутентификатор потерян или устройство сломано, войти помогают именно они. NIST в руководстве по цифровой идентификации SP 800-63B выделяет такие заранее выданные, расходуемые по одному и отзываемые после использования секреты в отдельный класс под названием look-up secrets. С динамическими кодами это не одно и то же: в обычные дни они не нужны, а в ЧП это единственный канал восстановления. Целей управления две: код находится, когда нужен, и после утечки не открывает дверь чужаку.

Выбор места хранения удобно сверять с этой таблицей:

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

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

Передача дел в три шага: сначала перепривязка, затем материалы восстановления, в конце окружение

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

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

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

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

После трёх шагов второй фактор аккаунта действительно передан.

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

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

Состояние 2FA живёт в настройках безопасности каждой платформы; MostMate управляет окружениями и командной работой, а аутентификаторами платформенных аккаунтов не распоряжается. При увольнении попросите уходящего сотрудника перепривязать 2FA на платформе, преемник один раз входит с новым аутентификатором и подтверждает, что всё работает, и эта отметка идёт в чек-лист передачи. Проверка входами по каждому аккаунту никуда не девается, но если сделать её в день передачи, это дешевле, чем разбираться в проблемах постфактум.

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

Частые вопросы

Аутентификатор потерян: можно ли вернуть аккаунт?

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

Что делать, если резервные коды почти израсходованы?

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

При увольнении участника: сначала перепривязка 2FA или отзыв доступа?

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

Как связаны антидетект-браузер и 2FA?

Каждый слой отвечает за своё. 2FA проверяет, тот ли человек входит, а антидетект-браузер отвечает за то, в какой среде происходит вход. Изоляция среды держит Cookie, отпечаток и прокси каждого аккаунта независимыми и стабильными и снижает шанс запуска проверки риск-контролем. Пройдёт ли аккаунт второй фактор, по-прежнему решают настройки безопасности платформы, поэтому оба слоя настраиваются вместе.

Заключение

Управление 2FA сводится к трём вещам. Аутентификатор: решить, с человеком или с аккаунтом. Резервные коды: вести как слой восстановления до отзыва. Передача: по фиксированному порядку перепривязка, передача материалов, передача окружения. Ничего сложного в этом нет, трудно другое: чтобы при множестве аккаунтов кто-то всё ещё шёл по чек-листу.

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

Изоляция окружений и командные настройки в MostMate уже готовы: скачайте MostMate, создайте первую группу окружений и закрепите в ней и принадлежность аккаунтов, и место хранения второго фактора.