Як команді з багатьма акаунтами керувати 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 це антидетект-браузер із середовищем як одиницею: кожен акаунт має своє, і середовища не несуть дані одне одному. У команді середовища видаються учасникам через групи середовищ. У списку учасників видно групи, роль і час останнього входу кожного учасника, тож одразу видно, чого бракує тому, хто приймає. Сторінка продукту повніше пояснює цю структуру ізоляції та співпраці.

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

Сам стан 2FA зберігається в налаштуваннях безпеки кожної платформи: MostMate керує середовищами та співпрацею команди і не бере на себе керування автентифікаторами акаунтів на платформах. На інвентаризації при звільненні попроси того, хто йде, зробити переприв'язку на платформі, той, хто приймає, входить один раз із новим автентифікатором для підтвердження, а потім запиши це підтвердження в список передачі. Покрокову перевірку входами не оминути, але в день передачі вона простіша, ніж розслідування після проблеми.

У відборі прав на боці середовища ще дві дії: групи та статус учасників. Чеклист і роботу з журналами розписано покроково в Керування безпекою багатьох акаунтів: групи, журнали та слід передачі. Пройди їх один раз перед передачею, щоб нічого не пропустити.

Часті питання

Автентифікатор загублено, чи можна повернути акаунт?

Так, за умови, що резервні коди на руках. При вході обери «не можу надати код перевірки», введи будь-який дійсний резервний код і увійдеш в акаунт. Перше після входу: перегенеруй увесь набір кодів і переприв'яжи на новий автентифікатор. Якщо загублено і резервні коди, лишається лише оскарження особи на платформі, і цикл там значно довший за відновлення через коди; про захист від крадіжки акаунтів і втрати даних дивись підходи зі статті Керування активами акаунтів.

Що робити, коли резервні коди майже скінчилися?

Використав код, перегенеруй увесь набір: генерація анулює старі коди. Нова копія синхронно потрапляє в командне місце зберігання, а старі роздруківки та скриншоти знищуються разом із нею. Якщо тягнути до останніх двох кодів, вікно відновлення звужується до двох кодів.

При звільненні: спершу переприв'язка 2FA чи спершу відбір прав?

Спершу переприв'язка, потім відбір прав. Якщо забрати лише середовище та права на вхід, акаунт застрягне на двофакторній перевірці, і врешті все одно потрібно, щоб звільнений давав коди. Після зміни прив'язки на боці платформи подальші дії відбору не потребують його участі.

Який зв'язок між антидетект-браузером і 2FA?

Кожен рівень відповідає за своє. 2FA перевіряє «чи людина, що входить, є власником акаунта», а антидетект-браузер керує «в якому середовищі відбувається вхід». Ізоляція середовища тримає Cookie, відбиток і проксі кожного акаунта незалежними та стабільними, зменшуючи ймовірність ризик-перевірок. Чи пройде двофакторна перевірка, досі вирішують налаштування безпеки платформи: обидва рівні налаштовують разом.

Висновок

Керування 2FA, якщо розкласти, це три речі. Автентифікатор: визначити, з людиною чи з акаунтом. Резервні коди: вести як рівень відновлення до анулювання. Передача: фіксований порядок переприв'язка, передача, середовище. Нічого важкого; складність у тому, щоб після росту кількості акаунтів хтось усе ще йшов за списком.

Командам, які ще не мають цього процесу, варто почати з двох акаунтів. Для одного перенесіть фактор перевірки в командне зберігання, другий лишіть в особистих руках. При наступній зміні персоналу порівняйте дві передачі, і з однієї спроби стане ясно, чи працює процес.

Ізоляцію середовищ і командну конфігурацію в MostMate вже готово: після того, як завантажите MostMate, створіть першу групу середовищ і одразу закріпіть належність акаунтів та місце зберігання фактора перевірки.