Як працює автентифікація GitHub?
У попередньому підрозділі ви дізналися про типові завдання адміністрування на рівні команди, організації та підприємства. У цій одиниці ви глибоко поринете в одне з найпоширеніших адміністративних завдань, виконаних власниками організації, яке налаштовує та контролює автентифікацію користувачів на GitHub.
Параметри автентифікації GitHub
Є кілька варіантів автентифікації за допомогою GitHub:
Ім'я користувача та пароль
Адміністратори можуть дозволити користувачам і надалі використовувати стандартний метод автентифікації імені користувача та пароля, іноді відомий як "проста" схема автентифікації HTTP. В останні роки базова автентифікація виявилася занадто ризикованою при роботі з високочутливою інформацією. Ми наполегливо радимо використовувати один (або кілька) інших варіантів, перелічених у цій одиниці.
Маркери особистого доступу
Маркери особистого доступу (PATs) – це альтернатива використанню паролів для автентифікації в GitHub під час використання API GitHub або командного рядка. Користувачі створюють маркер за допомогою параметрів GitHub і прив'язують дозволи маркера до сховища або організації. Коли користувачі взаємодіють із GitHub за допомогою інструмента командного рядка git, вони можуть вводити відомості про маркер, коли їм буде запропоновано ввести ім'я користувача та пароль.
Клавіші SSH
Як альтернатива використанню маркерів особистого доступу, користувачі можуть підключатися та автентифікувати віддалені сервери та служби за допомогою SSH-ключів. Ключі SSH усувають необхідність для користувачів вказати своє ім'я користувача та маркер особистого доступу для кожної взаємодії.
Під час налаштування SSH користувачі створюють SSH-ключ, додають його до ssh-агента, а потім додають ключ до свого облікового запису GitHub. Додавання ключа SSH до ssh-агента гарантує, що ключ SSH має парольну фразу як додатковий рівень безпеки. Користувачі можуть налаштувати локальну копію git, щоб автоматично постачати парольну фразу, або вони можуть вказати її вручну щоразу, коли використовують інструмент командного рядка git для взаємодії з GitHub.
Ви навіть можете використовувати SSH-ключі зі сховищем, що належить організації, яка використовує єдиний вхід SAML (SSO). Якщо організація надає сертифікати SSH, користувачі також можуть використовувати їх для доступу до репозиторіїв організації, не додаючи сертифікат до свого облікового запису GitHub.
Розгорнути клавіші
Ключі розгортання – це ще один тип ключа SSH у GitHub, який надає користувачу доступ до одного сховища. GitHub вкладає загальнодоступну частину ключа безпосередньо до сховища замість особистого облікового запису користувача, а приватна частина ключа залишається на сервері користувача. Клавіші розгортання за замовчуванням доступні лише для читання, але ви можете надати їм доступ до записування під час додавання їх до сховища.
Додані параметри безпеки GitHub
GitHub також пропонує такі додаткові параметри безпеки.
Двофакторна автентифікація
Двофакторна автентифікація (2FA), іноді відома як багатофакторна автентифікація (MFA), – це додатковий рівень безпеки, який використовується під час входу на веб-сайти або програми. З 2FA користувачі повинні ввійти за допомогою свого імені користувача та пароля та надати іншу форму автентифікації, до яких мають доступ лише вони.
Для GitHub друга форма автентифікації – це код, створений програмою на мобільному пристрої користувача або надісланий як текстове повідомлення (SMS). Після того, як користувач активує 2FA, GitHub створює код автентифікації в будь-який час, коли хтось намагається ввійти в свій обліковий запис GitHub. Користувачі можуть входити в свій обліковий запис, лише якщо знають свій пароль і мають доступ до коду автентифікації на своєму телефоні.
Власники організації можуть вимагати від учасників організації, зовнішніх співавторів і менеджерів з виставлення рахунків активувати 2FA для своїх особистих облікових записів. Ця дія ускладнює доступ зловмисників до репозиторіїв і настройок організації.
Власники підприємств також можуть застосовувати певні політики безпеки для всіх організацій, що належать корпоративному обліковому запису.
SAML SSO
Якщо ви централізовано керуєте ідентичностями та програмами користувачів за допомогою idP, ви можете налаштувати SSO SAML для захисту ресурсів організації на GitHub.
Цей тип автентифікації дає організації та власникам підприємства на GitHub можливість контролювати та забезпечувати доступ до ресурсів організації, як-от репозиторіїв, питань і запитів на витягування. Власники організації можуть запросити користувачів GitHub приєднатися до організації, яка використовує SSO SAML, що дає змогу цим користувачам робити внесок в організацію та зберігати свої наявні ідентичності та внески на GitHub.
Коли користувачі отримають доступ до ресурсів в організації, яка використовує SSO SAML, GitHub переспрямує їх до SAML IdP організації для автентифікації. Після успішної автентифікації за допомогою свого облікового запису в IdP idP переспрямовує до GitHub, щоб отримати доступ до ресурсів організації.
GitHub пропонує обмежену підтримку для всіх постачальників ідентичностей, які впроваджують стандарт SAML 2.0 з офіційною підтримкою для кількох популярних постачальників ідентичностей, включаючи:
- Служби об'єднання Active Directory (AD FS).
- Ідентифікатор Microsoft Entra.
- Окта.
- OneLogin.
- PingOne.
LDAP
Полегшений протокол доступу до каталогів (LDAP) – це популярний протокол програми для доступу до інформаційних служб каталогів і їх обслуговування. LDAP дає змогу автентифікувати GitHub Enterprise Server із наявними обліковими записами та централізовано керувати доступом до сховища. Це один із найпоширеніших протоколів, який використовується для інтеграції стороннього програмного забезпечення з великими каталогами користувачів компанії.
GitHub Enterprise Server інтегрується з популярними службами LDAP, такими як:
- Active Directory.
- Oracle Directory Server Enterprise Edition.
- OpenLDAP.
- Відкрийте каталог.