2FA у GitLab: як увімкнути двофакторну автентифікацію та захистити акаунт
Ще кілька років тому двофакторна автентифікація вважалася радше корисною рекомендацією, ніж обов’язковою вимогою. Сьогодні ситуація змінилася. І найкраще це видно на простому сценарії.
Розробник використовує однаковий пароль у кількох онлайн-сервісах. Один із них стає жертвою витоку даних, пароль потрапляє до відкритої бази. Далі атака типу credential stuffing автоматично перевіряє цей пароль на сотнях інших сервісів — включно з корпоративним GitLab. Якщо 2FA вимкнена, цього вже може бути достатньо, щоб зловмисник отримав доступ до облікового запису.
А GitLab для більшості компаній давно перестав бути просто сховищем коду. Тут зберігаються приватні репозиторії, конфігурації CI/CD, токени доступу до хмарної інфраструктури, секрети середовища та внутрішня технічна документація. Компрометація одного акаунта розробника інколи коштує значно дорожче, ніж втрата одного пароля.
Саме тому 2FA сьогодні входить до базових вимог захисту корпоративних GitLab-акаунтів. Її налаштування займає кілька хвилин, але суттєво знижує ризик несанкціонованого доступу — навіть якщо пароль уже скомпрометовано.
У цій статті розглянемо, які методи 2FA підтримує GitLab, чим відрізняються одноразові коди, синхронізовані Passkeys та апаратні FIDO2-ключі, як увімкнути двофакторну автентифікацію і чому для бізнесу вигідніше переходити на апаратні ключі.
Коротко: як захистити GitLab за допомогою 2FA
- увімкнути двофакторну автентифікацію в налаштуваннях акаунта GitLab;
- обрати метод підтвердження входу: TOTP, Passkey або апаратний FIDO2-ключ;
- зберегти Recovery Codes у безпечному місці;
- для команди — запровадити єдину політику 2FA;
- для критичних акаунтів — використовувати апаратні FIDO2 Security Keys.
Що таке 2FA у GitLab
Двофакторна автентифікація (Two-Factor Authentication, 2FA) — це механізм безпеки, який вимагає не лише пароль, а й додатковий спосіб підтвердження особи.
Після введення логіна та пароля GitLab може попросити підтвердити вхід одним із підтримуваних способів:
- одноразовим кодом із застосунку-автентифікатора (TOTP);
- синхронізованим Passkey на телефоні чи ноутбуці;
- апаратним Passkey — окремим FIDO2-токеном або смарт-карткою.
Таким чином, навіть якщо пароль випадково стане відомий сторонній особі, одного цього вже буде недостатньо для входу до облікового запису. На практиці це означає, що навіть успішний витік паролів або credential stuffing не завжди дозволять зловмиснику отримати доступ до репозиторію.
Які способи 2FA підтримує GitLab
GitLab підтримує кілька сучасних механізмів підтвердження входу. Усі вони значно безпечніші за використання лише пароля, але між ними є принципова різниця.
| Метод | Тип | Де зберігається приватний ключ | Стійкість до фішингу | Кому підійде |
|---|---|---|---|---|
| Authenticator App (TOTP) | Спільний секрет | У застосунку на пристрої | Немає | Особисті акаунти |
| Passkey синхронізований | FIDO2 / WebAuthn | У хмарі виробника пристрою | Так | Сучасні пристрої |
| Passkey апаратний | FIDO2 / WebAuthn | Усередині окремого токена або смарт-картки | Так, максимальна | Бізнес і корпоративні користувачі |
Саме на цьому етапі в багатьох матеріалах про 2FA виникає плутанина. Passkey, WebAuthn і FIDO2 часто подають як різні технології поруч одна з одною. Насправді це частини однієї сучасної моделі автентифікації.
TOTP, синхронізовані та апаратні Passkeys: у чому різниця
Найпоширеніший варіант — застосунок-автентифікатор, який кожні 30 секунд генерує одноразовий код. Це простий і доступний спосіб захисту, який не потребує додаткового обладнання. Але він працює на основі спільного секрету: користувач бачить код і може випадково ввести його на фішинговому сайті.
Passkey — це не окрема технологія поруч із FIDO2, а спосіб реалізації стандарту FIDO2/WebAuthn. Він складається з пари ключів: публічний зберігається на сервері, а приватний залишається у користувача і ніколи не передається під час автентифікації.
Розрізняють два основні типи Passkey:
- синхронізований Passkey — приватний ключ зберігається в хмарному сховищі виробника пристрою, наприклад iCloud Keychain або Google Password Manager, і може синхронізуватися між пристроями користувача;
- апаратний Passkey — приватний ключ генерується і залишається всередині окремого фізичного пристрою: FIDO2-токена або смарт-картки.
Обидва типи стійкі до фішингу, бо під час автентифікації перевіряють домен сайту. Різниця в тому, де саме зберігається приватний ключ. Синхронізований Passkey залежить від безпеки хмарного акаунта користувача. Апаратний ключ фізично не покидає чіп токена або смарт-картки, не експортується і не може бути скопійований навіть у разі компрометації операційної системи.
Для більшості приватних користувачів достатньо застосунку-автентифікатора або синхронізованого Passkey. Якщо ж GitLab використовується для комерційної розробки, адміністрування інфраструктури або роботи з конфіденційним кодом, апаратний FIDO2-ключ забезпечує вищий рівень захисту.
Від FIDO U2F до Passkeys: три етапи підтримки апаратних ключів у GitLab
Тут варто розрізняти не дві, а три стадії. Різниця між ними не лише в назві, а в тому, що саме вміє протокол і як він використовується під час входу.
Етап 1. FIDO U2F — лише другий фактор
GitLab додав підтримку FIDO U2F ще у версії 8.9. На той момент це було важливе рішення для захисту від фішингу. Але U2F — це протокол виключно для другого фактора.
У нього немає механізму discoverable credentials або resident keys, тобто ключ не може сам ідентифікувати користувача. Для входу завжди потрібно спершу ввести логін і пароль, а U2F-пристрій лише підтверджує другий крок. Безпарольний вхід із таким ключем неможливий через архітектуру самого протоколу.
Етап 2. Перехід на WebAuthn — усе ще другий фактор
Коли браузери почали відмовлятися від застарілого U2F JavaScript API, GitLab перевів реєстрацію ключів на стандарт WebAuthn. Це була важлива зміна транспортного рівня, але не повний перехід до passwordless.
Ключі й надалі працювали переважно як другий фактор: користувач вводив пароль, а потім підтверджував вхід апаратним пристроєм. Для безпеки це вже було дуже сильне рішення, але пароль усе ще залишався частиною процесу входу.
Етап 3. FIDO2 Passkeys — безпарольний вхід
Підтримка Passkeys відкрила можливість використовувати FIDO2 не лише як другий фактор, а й як основу для безпарольного входу. У такій моделі користувач підтверджує свою особу за допомогою пристрою, PIN-коду або біометрії, а пароль більше не є центральною точкою ризику.
Практичний висновок простий: старий U2F-ключ, який компанія купила кілька років тому, не перетвориться на повноцінний Passkey лише після оновлення GitLab. Для цього потрібен пристрій із підтримкою FIDO2/CTAP2.
Якщо команда налаштовувала 2FA у GitLab рік-два тому, варто перевірити, чи підтримують наявні ключі CTAP2. За потреби їх краще замінити на сумісні пристрої, щоб отримати доступ до безпарольного входу та сучасніших механізмів захисту.
Як увімкнути 2FA у GitLab: покрокова інструкція
Процедура налаштування займає лише кілька хвилин. Назви пунктів меню можуть трохи відрізнятися залежно від версії GitLab, але загальна логіка залишається однаковою.
Крок 1. Увійдіть до свого акаунта
Авторизуйтеся під своїм обліковим записом GitLab.
Крок 2. Перейдіть до налаштувань профілю
Натисніть на аватар у верхньому правому куті та відкрийте Edit profile.
Крок 3. Відкрийте розділ Password and authentication
У лівому меню перейдіть до Access, а потім до Password and authentication.
Крок 4. Оберіть спосіб підтвердження
GitLab запропонує зареєструвати застосунок-автентифікатор або WebAuthn/Passkey-пристрій. Це може бути як синхронізований Passkey на телефоні чи ноутбуці, так і окремий апаратний FIDO2-ключ.
Крок 5. Завершіть налаштування
Підтвердьте підключення другого фактора та обов’язково збережіть Recovery Codes.
Багато користувачів нехтують цим кроком, але саме резервні коди допомагають швидко відновити доступ після втрати телефону, токена або смарт-картки.
Чому апаратні Passkeys стійкі до фішингу
Застосунки-автентифікатори значно підвищують рівень безпеки порівняно зі звичайними паролями. Проте вони не можуть повністю захистити від сучасних фішингових атак.
Уявімо ситуацію: користувач переходить за посиланням із листа, яке веде на сайт, зовні майже ідентичний GitLab. Він вводить логін, пароль і навіть одноразовий код із телефону. Якщо атака побудована достатньо переконливо, зловмисник може використати ці дані для входу в реальному часі.
Passkeys працюють інакше. Перед підтвердженням входу пристрій перевіряє справжність домену. Якщо домен не збігається з тим, для якого зареєстровано ключ, автентифікація просто не відбудеться, навіть якщо сторінка виглядає майже ідентично оригінальній.
Апаратний FIDO2-ключ додає ще один рівень захисту: приватний ключ не лише не передається мережею, а й фізично не покидає чіп токена або смарт-картки. Це означає, що навіть шкідливе програмне забезпечення на комп’ютері користувача або компрометація хмарного акаунта не дають змоги вкрасти чи скопіювати ключ.
Саме тому для критичної інфраструктури компанії дедалі частіше обирають не одноразові коди, а апаратні FIDO2-рішення. Користувачу більше не потрібно переносити шестизначні коди з телефону: достатньо підключити токен або використати смарт-картку та підтвердити вхід.
2FA для команд і бізнесу
У великих командах питання двофакторної автентифікації виходить далеко за межі окремого користувача. Якщо GitLab використовується для комерційної розробки, доступ до репозиторіїв і CI/CD-конфігурацій має бути захищений єдиною корпоративною політикою.
Використання апаратних FIDO2-ключів дозволяє:
- мінімізувати ризик компрометації акаунтів навіть у разі витоку пароля;
- захистити репозиторії, CI/CD і секрети від фішингових атак;
- спростити вхід для співробітників;
- зменшити кількість звернень щодо втрати одноразових кодів;
- підготувати компанію до переходу на passwordless.
Важливо розуміти різницю. Пароль у парі з апаратним ключем — це вже фішингостійка конфігурація, бо ключ перевіряє домен сайту. Але пароль усе ще залишається окремою точкою ризику: його можна повторно використати, забути, зберігати в менеджері паролів або випадково ввести на сторонньому сайті.
Passwordless-вхід прибирає цю точку ризику повністю. Немає пароля, який можна викрасти або використати повторно. Для бізнесу це ще й операційна економія: менше звернень до підтримки, менше скидань паролів і менше можливостей для соціальної інженерії.
Досвід Smart Lab: власні Passkeys для власного GitLab
У Smart Lab ми не лише працюємо з апаратними FIDO2-токенами та смарт-картками. Ми самі використовуємо їх для доступу до внутрішнього GitLab.
Співробітники, які мають доступ до репозиторіїв і CI/CD-конфігурацій, автентифікуються апаратними Passkeys, а не лише паролем чи одноразовим кодом. Це те саме рішення, яке ми допомагаємо впроваджувати клієнтам.
Такий підхід дозволяє перевірити технологію на власній інфраструктурі, перш ніж рекомендувати її іншим. Для клієнта це важливо: він отримує не абстрактну консультацію, а рішення, яке вже використовується в реальному робочому середовищі.
Типові помилки під час налаштування 2FA у GitLab
Сам факт увімкнення двофакторної автентифікації ще не гарантує максимального захисту. Найчастіше проблеми виникають не через технологію, а через відсутність правил її використання.
| Помилка | Ризик | Як уникнути |
|---|---|---|
| Не збережено Recovery Codes | Втрата доступу до акаунта | Зберігати коди в безпечному місці одразу після налаштування |
| Другий фактор налаштований лише на одному пристрої | Блокування доступу після втрати телефону або токена | Мати резервний спосіб входу |
| Відсутній резервний ключ | Простій у роботі команди | Використовувати основний і резервний FIDO2-носій |
| Пароль повторно використовується на інших сервісах | Credential stuffing | Використовувати унікальні паролі або переходити на passwordless |
| Немає єдиної політики 2FA | Різний рівень захисту в межах однієї команди | Запровадити однакові правила для всіх користувачів GitLab |
Якщо GitLab використовується в компанії, бажано одразу визначити внутрішні правила. Наприклад, усі співробітники мають використовувати однаковий тип автентифікації, мати резервний ключ і зберігати його окремо від основного.
Такі прості правила допомагають уникнути неприємних ситуацій під час втрати телефону, заміни ноутбука, відрядження або звільнення співробітника.
Що вигідніше для резервування: дві смарт-картки чи два токени
Для корпоративного використання важливо думати не лише про рівень безпеки, а й про вартість масштабування рішення.
З погляду відмовостійкості обидві конфігурації можуть бути рівнозначними: у користувача є два фізично незалежні носії ключа, і втрата одного не блокує доступ. Але різниця полягає у вартості володіння та в тому, який компонент є критичним для безпеки.
Токен — це завершений пристрій, у якому в одному корпусі поєднані захищений чіп і USB- або NFC-контролер. Кожен додатковий токен для резервування — це повна вартість ще одного пристрою.
Смарт-картка — це захищений чіп у форматі ID-1 без власного інтерфейсу підключення. Зчитувач є окремим багаторазовим компонентом, який не зберігає ключів і не є критичним для безпеки.
Тому конфігурація “дві картки + один або кілька зчитувачів” часто вигідніша для команди, ніж “два токени на кожного користувача”. Особливо це помітно на масштабі: для 20 співробітників резервування на картках означає 40 карток і обмежену кількість зчитувачів, тоді як резервування на токенах потребує 40 повноцінних пристроїв.
Практична рекомендація: основну картку користувач носить із собою, резервну зберігає окремо, наприклад у сейфі або в іншому офісі, а зчитувачі розміщуються в ключових точках доступу.
Висновок
2FA для GitLab — це вже не додаткова опція, а базовий елемент захисту. Скомпрометовані паролі, credential stuffing і фішинг щодня загрожують репозиторіям, CI/CD-секретам і корпоративній інфраструктурі.
Для особистого акаунта достатнім рішенням може бути застосунок-автентифікатор або синхронізований Passkey. Для бізнесу, командної розробки та критичних репозиторіїв варто переходити на апаратні FIDO2 Security Keys.
Вони забезпечують стійкість до фішингу, зменшують залежність від паролів, спрощують вхід для команди та допомагають підготувати компанію до passwordless-автентифікації.
Потрібна допомога із захистом GitLab?
Якщо ваша команда використовує GitLab для розробки програмного забезпечення, варто подбати не лише про складні паролі, а й про сучасний другий фактор автентифікації. Smart Lab допомагає впроваджувати апаратні FIDO2 Security Keys для корпоративних середовищ. Ми підберемо сумісні токени або смарт-картки, допоможемо організувати їх використання в компанії та проконсультуємо щодо інтеграції з GitLab, Microsoft 365, Google Workspace та іншими сервісами.
Дізнатися більше про FIDO2-токениFAQ
Чи підтримує GitLab двофакторну автентифікацію?
Так. GitLab підтримує кілька сучасних способів другого фактора, включаючи застосунки-автентифікатори, WebAuthn-пристрої та Passkeys.
Чим Passkey відрізняється від FIDO2 Security Key?
Passkey — це облікові дані за стандартом FIDO2/WebAuthn. Він може бути синхронізованим або апаратним. FIDO2 Security Key — це апаратна реалізація Passkey, коли приватний ключ зберігається всередині окремого токена або смарт-картки.
Який спосіб 2FA найкращий для GitLab?
Для особистого використання підійде застосунок-автентифікатор або синхронізований Passkey. Для компаній і команд розробників краще використовувати апаратні FIDO2 Security Keys, які забезпечують максимальний захист від фішингових атак.
Що робити, якщо втрачено телефон із застосунком-автентифікатором?
Під час налаштування GitLab пропонує зберегти Recovery Codes. Саме вони дозволяють відновити доступ до акаунта без основного пристрою автентифікації.
Чи можна використовувати один FIDO2-ключ для кількох сервісів?
Так. Один і той самий FIDO2-ключ може використовуватися для GitLab, GitHub, Microsoft 365, Google Workspace та багатьох інших сервісів, що підтримують FIDO2/WebAuthn.
Чи потрібен резервний ключ?
Так, якщо GitLab використовується для роботи або адміністрування корпоративних проєктів. Резервний FIDO2-ключ або смарт-картка дозволяють швидко відновити доступ у разі втрати чи пошкодження основного пристрою.
Що вигідніше для компанії: дві смарт-картки FIDO2 чи два окремі токени?
З погляду резервування обидва варіанти можуть забезпечити надійний доступ. Але для команди конфігурація з двома смарт-картками та окремими зчитувачами часто вигідніша за два повноцінні токени на кожного користувача, особливо при масштабуванні на десятки співробітників.
