Как работает проверка подлинности GitHub?

  • 6 мин

В предыдущем уроке вы узнали о типичных задачах администрирования на уровне команды, организации и предприятия. В этом уроке вы изучите одну из наиболее распространенных административных задач, выполняемых владельцами организации, которая настраивает проверку подлинности пользователей на GitHub и управляет ими.

Параметры проверки подлинности на GitHub

Существует несколько вариантов проверки подлинности с помощью GitHub.

Имя пользователя и пароль

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

Замечание

GitHub больше не поддерживает проверку подлинности паролей для операций Git или использования API. Настоятельно рекомендуется использовать один (или несколько) других параметров, перечисленных в этом уроке.

Личные маркеры доступа

Снимок экрана: экран личного маркера доступа.

Личные маркеры доступа (PAT) — это альтернатива использованию паролей для проверки подлинности на GitHub при использовании API GitHub или командной строки. Пользователи создают маркер с помощью параметров GitHub и привязывают разрешения маркера к репозиторию или организации. Когда пользователи взаимодействуют с GitHub с помощью средства командной строки Git, они могут ввести сведения о маркере, когда они запрашивают имя пользователя и пароль.

Ключи SSH

В качестве альтернативы использованию персональных маркеров доступа пользователи могут подключаться и проходить проверку подлинности на удаленных серверах и службах через SSH с помощью ключей SSH. Ключи SSH устраняют необходимость предоставления пользователям имени пользователя и личного маркера доступа для каждого взаимодействия.

При настройке SSH пользователи создают ключ SSH, добавляют его в агент SSH, а затем добавляют ключ в учетную запись GitHub. Добавление ключа SSH в агент SSH гарантирует, что ключ SSH имеет парольную фразу в качестве дополнительного уровня безопасности. Пользователи могут настроить локальную копию Git для автоматической передачи парольной фразы или указывать ее вручную при каждом использовании программы командной строки git для взаимодействия с GitHub.

Вы даже можете использовать ключи SSH с репозиторием, принадлежащим организации, использующей единый вход SAML. Если организация предоставляет сертификаты SSH, пользователи также могут использовать их для доступа к репозиториям организации, не добавляя сертификат в учетную запись GitHub.

Ключи развертывания

Развертывание ключей — это другой тип ключа SSH в GitHub, который предоставляет пользователю доступ к одному репозиторию. GitHub присоединяет открытую часть ключа непосредственно к репозиторию, а не к личной учетной записи пользователя, а закрытая часть ключа остается на сервере пользователя. Ключи развертывания по умолчанию доступны только для чтения, но вы можете предоставить им доступ для записи при добавлении их в репозиторий.

Чтобы настроить параметры вилки, выполните следующие действия.

  1. Перейдите к параметрам репозитория.
  2. В левой боковой панели в разделе "Безопасность" нажмите кнопку "Развернуть ключи".
  3. Найдите параметр "Добавить ключ развертывания" , чтобы создать новый ключ.

Снимок экрана, показывающий добавление ключа развертывания в опции

Дополнительные параметры безопасности GitHub

GitHub предоставляет ряд параметров безопасности для защиты учетных записей и ресурсов организации.

Двухфакторная проверка подлинности

Снимок экрана: экран двухфакторной проверки подлинности.

Двухфакторная проверка подлинности (2FA), иногда называемая многофакторной проверкой подлинности (MFA), добавляет дополнительный уровень защиты к учетной записи GitHub. С помощью 2FA пользователи входят, используя имя пользователя и пароль, а затем предоставляют вторую форму аутентификации.

GitHub поддерживает несколько вариантов второго фактора:

  • Программы для аутентификации (например, Microsoft Authenticator, Google Authenticator или Authy), которые генерируют одноразовые коды с привязкой ко времени.
  • Аппаратные ключи безопасности (например, YubiKey или Titan Security Key), поддерживающие FIDO2/WebAuthn.
  • Ключи доступа для аутентификации без паролей, защищающие от фишинга.
  • Коды на основе SMS, которые поддерживаются, но считаются менее безопасными, чем другие варианты, и не рекомендуется в качестве основного метода.

Принудительное применение 2FA:

  • Для организаций в GitHub Team и GitHub Enterprise Cloud владельцы организаций могут требовать от участников, внешних сотрудников и менеджеров по выставлению счетов включения двухфакторной аутентификации (2FA) для их личных учетных записей.
  • Корпоративные управляемые пользователи (EMUs) и GitHub Enterprise Server (GHE.com): администраторам может потребоваться только 2FA для учетных записей, управляемых предприятием, но не может применять 2FA к личным GitHub.com учетным записям пользователей.

Применение 2FA помогает защитить организации от несанкционированного доступа и укрепить безопасность репозиториев и конфиденциальных данных.

Единый вход SAML

Если вы централизованно управляете удостоверениями пользователей с помощью поставщика удостоверений (IdP), вы можете настроить единый вход SAML для защиты ресурсов вашей организации на GitHub. Единый вход SAML позволяет организациям и владельцам крупных предприятий контролировать и защищать доступ к репозиториям, задачам, запросам на вытягивание и т. д. При доступе к ресурсам GitHub перенаправляет пользователей на проверку подлинности с помощью поставщика удостоверений организации.

GitHub поддерживает все поставщики удостоверений, реализующие стандарт SAML 2.0, с официальной поддержкой нескольких популярных поставщиков, в том числе:

  • Служба федерации Active Directory (AD FS).
  • Идентификатор Microsoft Entra.
  • Okta.
  • OneLogin.
  • PingOne.

LDAP (GitHub Enterprise Server)

LDAP (протокол упрощенного доступа к каталогу) — это широко используемый протокол для доступа к сведениям каталога пользователей и управления ими. Интеграция LDAP на GitHub Enterprise Server позволяет выполнять проверку подлинности пользователей в существующем каталоге компании и централизованно управлять доступом к репозиторию.

GitHub Enterprise Server интегрируется с основными службами LDAP, такими как:

GitHub Enterprise Server интегрируется с популярными службами LDAP, такими как:

  • Active Directory.
  • Сервер каталогов Oracle выпуск Enterprise.
  • OpenLDAP.
  • Откройте каталог.