Що таке MFA/2FA і чому одного пароля вже замало

Зачіпка

MFA/2FA — це додатковий доказ при вході. Пароль каже “я знаю секрет”, а другий фактор додає “у мене є мій пристрій, ключ або підтверджений спосіб входу”.

Один пароль уже замало, бо його можна вкрасти, повторно використати, підглянути, витягнути з витоку або ввести на фішинговій сторінці. MFA не робить акаунт невразливим, але різко піднімає ціну атаки.

Проблема / Контекст

Більшість зламів починається не з кіношного “зламали сервер”, а з простішої історії: людина використала пароль вдруге, пароль потрапив у витік, хтось відкрив фішинговий лист або токен залишився в старому пристрої. Якщо акаунт захищений тільки паролем, атакувальнику достатньо отримати один секрет.

MFA змінює цю схему. Навіть якщо пароль відомий, для входу потрібен ще один фактор: код з authenticator app, passkey, security key, підтвердження на довіреному пристрої або інший механізм. Це особливо важливо для email, GitHub, cloud-панелей, хостингу, доменів, password manager, CI/CD і адмінських акаунтів.

2FA зазвичай означає два фактори: пароль плюс другий доказ. MFA ширше: факторів може бути більше, а правила можуть залежати від ролі, ризику або типу пристрою. Для початківця різниця не критична. Практична думка така: важливий акаунт не має триматися тільки на паролі.

Чому це важливо

Email часто є головним ключем до всього. Через нього скидають паролі від хостингу, GitHub, банкінгу, соцмереж і сервісів. Якщо email без MFA, захист інших акаунтів слабшає.

У розробці ризик ще більший. Один GitHub-акаунт може мати доступ до приватного коду, deploy keys, Actions secrets, package registry і production pipeline. Один cloud-акаунт може створити ресурси на гроші, прочитати дані або вимкнути сервіс. Один доменний акаунт може перенаправити сайт на чужу інфраструктуру.

MFA дає час і шум. Атакувальник може знати пароль, але застрягнути на другому факторі. Користувач може побачити дивний запит. Команда може отримати alert. Це не абсолютна гарантія, але дуже сильний базовий шар захисту.

Водночас MFA треба налаштовувати з головою. Якщо є тільки один телефон і жодних recovery codes, втрата телефону стає операційним інцидентом. Якщо всі користуються одним admin-акаунтом, MFA перетворюється на незручний ритуал без нормальної відповідальності. Якщо вибрати SMS там, де доступні passkey або security key, захист буде слабшим, ніж міг би бути.

Схема в голові

Уяви вхід у сервіс як двері з двома різними перевірками. Пароль — це те, що ти знаєш. Другий фактор — це те, що маєш або підтверджуєш: телефон із кодом, passkey на пристрої, security key у кишені.

Здорова схема для команди виглядає так:

• кожна людина має свій акаунт, а не спільний логін;
• MFA обов’язковий для admin-ролей;
• для критичних акаунтів використовуються passkey, security key або authenticator app;
• recovery codes зберігаються окремо від основного пристрою;
• доступ для automation робиться через service accounts, scoped tokens і rotation;
• команда має коротку процедуру, що робити при втраті пристрою.

Головне: MFA — це не тільки кнопка “увімкнути”. Це маленький процес навколо входу, відновлення і відкликання доступу.

Як це зробити

1. Почни з найважливіших акаунтів

Не треба в перший день ідеально закрити все. Почни з акаунтів, через які можна відновити або зламати інші:

• основний email;
• password manager;
• GitHub або інша git-платформа;
• cloud і hosting;
• реєстратор доменів і DNS;
• CI/CD;
• адмінки production-сервісів.

Якщо часу мало, email і password manager йдуть першими. Вони часто є коренем доступу.

2. Вибери правильний метод

SMS краще, ніж нічого, але це слабкий варіант. Номер можна перенести через SIM swap, повідомлення можуть затримуватися, а телефонний канал не створювався як security-механізм.

Authenticator app зазвичай кращий старт: працює без мобільного зв’язку, генерує одноразові коди й підтримується майже всюди. Для критичних акаунтів ще краще використовувати passkey або security key. Вони краще протистоять фішингу, бо прив’язані до реального сайту, а не просто до коду, який людина може ввести куди завгодно.

Push-підтвердження зручне, але його треба використовувати обережно. Якщо сервіс просто питає “підтвердити вхід” без числа, місця і контексту, є ризик push fatigue. Людина може натиснути “так”, бо втомилася від запитів.

3. Збережи recovery codes

Recovery codes потрібні до того, як сталася проблема. Їх не можна тримати тільки на телефоні, який і є другим фактором. Нормальні варіанти:

• password manager;
• роздрукований аркуш у безпечному місці;
• зашифроване сховище для команди;
• два admin-и з окремими способами відновлення.

Після увімкнення MFA перевір, чи recovery codes справді згенеровані, збережені й зрозуміло, хто має право ними користуватися. Для команди це варто записати в короткий runbook.

4. Не плутай людські акаунти й automation

MFA добре працює для людей. Для скриптів, CI/CD і service accounts потрібна інша модель: короткоживучі токени, вузький scope, secret scanning, rotation і audit log.

Погана схема — взяти людський admin-акаунт, створити для нього довгий токен і засунути в pipeline. Краще мати окремий service account із мінімальними правами й зрозумілим власником.

5. Увімкни політики для команди

Якщо сервіс підтримує organization policy, увімкни вимогу MFA для всіх учасників або хоча б для ролей з write/admin-доступом. Інакше безпечний акаунт однієї людини не врятує, якщо інший admin лишився тільки з паролем.

Також перевір старі акаунти, підрядників і запрошення. MFA не допоможе, якщо в організації висить давній користувач із зайвими правами.

6. Протестуй втрату пристрою

Найкращий момент перевірити recovery — коли все спокійно. Вибери один некритичний акаунт або тестовий сценарій і пройди шлях: що робимо, якщо телефон втрачено, security key зламався або людина звільнилася.

Мета не в тому, щоб створити складну бюрократію. Мета — не шукати recovery codes у паніці.

Антипатерни

• вмикати MFA тільки для “головного” admin-а, але лишати інших із write-доступом без захисту;
• використовувати спільний admin-акаунт для всієї команди;
• зберігати recovery codes на тому самому телефоні, який є другим фактором;
• вважати SMS достатнім для cloud, доменів або password manager;
• підтверджувати push-запити, які користувач сам не починав;
• використовувати людський акаунт як service account у CI/CD;
• не мати процедури, що робити при втраті пристрою або звільненні людини;
• не перевіряти, чи MFA справді примусово увімкнений для організації.

Висновок / План дій

MFA/2FA — це базова гігієна доступу. Вона не замінює унікальні паролі, password manager, scoped tokens і нормальні права, але без неї важливі акаунти надто легко падають після одного витоку.

Почни з практичного мінімуму:

1. увімкни MFA для email і password manager;
2. закрий GitHub, hosting, cloud, DNS і CI/CD;
3. вибери authenticator app, passkey або security key замість SMS;
4. збережи recovery codes окремо;
5. прибери спільні admin-акаунти;
6. перевір service accounts і токени;
7. запиши короткий recovery-план.

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

Офіційні джерела:

• https://www.cisa.gov/MFA
• https://pages.nist.gov/800-63-3/sp800-63b.html
• https://developers.google.com/identity/passkeys
• https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa