Об этом руководстве
В этом руководстве описываются самые важные изменения, которые можно внести для повышения безопасности учетной записи. В каждом разделе описаны изменения, которые можно внести в процессы для повышения безопасности. Сначала указаны изменения с самым высоким влиянием.
В чем заключаются риски?
Безопасность учетных записей имеет важное значение для обеспечения безопасности цепочки поставок. Если злоумышленник может взять на себя учетную запись GitHub, он может внести вредоносные изменения в код или процесс сборки. Поэтому ваша первая цель заключается в том, чтобы кто-то затруднил вашей учетной записи и учетные записи других пользователей вашей вашего экземпляра.
Централизованная проверка подлинности
Если вы являетесь администратором сайта для вашего экземпляра, вы можете упростить процесс входа для пользователей, выбрав метод проверки подлинности, который подключается к существующему поставщику удостоверений (IdP), например CAS, SAML или LDAP. Это означает, что им больше не нужно запоминать дополнительный пароль.GitHub
Некоторые методы проверки подлинности также поддерживают передачу дополнительных сведений GitHub, например о группах пользователя или синхронизации криптографических ключей для пользователя. Это отличный способ упростить администрирование по мере роста организации.
Дополнительные сведения о методах проверки подлинности, доступных для GitHub, см. в разделе Основы управления идентификацией и доступом.
Настройка двухфакторной проверки подлинности
Лучший способ повысить безопасность вашей личной учетной или экземпляра записей — настроить двухфакторную проверку подлинности (2FA). Пароли сами по себе могут быть скомпрометированы путем угадывания, в результате повторного использования на другом сайте, который был скомпрометирован, или с помощью методов социотехники, например фишинга. Двухфакторная проверка подлинности значительно усложняет компрометацию учетных записей, даже если у злоумышленника есть пароль.
Для обеспечения безопасности и надежного доступа к вашей учетной записи всегда должно быть не менее двух учетных данных второго фактора, зарегистрированных в вашей учетной записи. Дополнительные учетные данные гарантируют, что даже если вы потеряете доступ к одному учетным данным, вы не будете заблокированы из учетной записи.
Если вы являетесь администратором сайта для вашего экземпляра, вы можете настроить 2FA для всех пользователей вашего экземпляра. Доступность 2FA зависит от используемого метода проверки подлинности. Дополнительные сведения см. в разделе "Централизация проверки подлинности".
Если вы являетесь владельцем организации, вы иметь возможность требовать, чтобы все члены организации могли включить 2FA.
Дополнительные сведения о включении 2FA в собственной учетной записи см. в разделе Настройка двухфакторной проверки подлинности. Дополнительные сведения о необходимости 2FA в организации см. в разделе Обязательная двухфакторная проверка подлинности в вашей организации.
Настройка корпоративной учетной записи
Владельцы предприятия могут иметь возможность требовать 2FA для всех пользователей напредприятия. Доступность политик GitHub 2FA зависит от того, как пользователи проходят проверку подлинности для доступа к ресурсам экземпляра
Настройка личной учетной записи
Примечание.
В зависимости от метода проверки подлинности, настроенного предприятия администратором сайта, возможно, не удается включить 2FA для вашей личной учетной записи.
GitHub поддерживает несколько вариантов для 2FA, и хотя любой из них лучше, чем ничего, самый безопасный вариант — это учетные данные WebAuthn. Для WebAuthn требуется средство проверки подлинности, например ключ безопасности оборудования FIDO2, средство проверки подлинности платформы, например Windows Hello, телефон Apple или Google или диспетчер паролей. Фишинг других форм двухфакторной проверки подлинности (например, кто-то просит вас прочитать 6 цифр одноразового пароля) возможен, хотя и затруднителен. Однако WebAuthn гораздо более устойчив к фишингу, так как область домена встроена в протокол, что предотвращает использование GitHubучетных данных веб-сайта, в котором используется страница входа.
При настройке 2FA всегда следует скачать код восстановления и настроить несколько учетных данных 2FA. Это гарантирует, что доступ к учетной записи не будет зависеть от одного устройства. Дополнительные сведения см. в разделе [AUTOTITLE и Настройка двухфакторной проверки подлинности](/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods).
Настройка учетной записи организации
Примечание.
В зависимости от метода проверки подлинности, настроенного предприятия администратором сайта, может потребоваться 2FA для вашей организации.
Если вы являетесь владельцем организации, то можете видеть, у каких пользователей не включена двухфакторная проверка подлинности. Помогите им ее настроить, а затем можете требовать использование двухфакторной проверки подлинности в вашей организации. Инструкции по выполнению этого процесса см. в следующих разделах.
- Проверка включения двухфакторной проверки у пользователей организации
- Подготовка к включению обязательной двухфакторной проверки подлинности в организации
- Обязательная двухфакторная проверка подлинности в вашей организации
Подключение к GitHub использованию ключей SSH
Существуют другие способы взаимодействия с GitHub выходом на веб-сайт. Многие пользователи авторизуют код, который GitHub они передают с помощью закрытого ключа SSH. Дополнительные сведения см. в разделе Сведения о протоколе SSH.
Как и в случае с паролем учетной записи, если злоумышленник получит ваш закрытый ключ SSH, он может выдать себя за вас и отправить вредоносный код в любой репозиторий, в котором у вас есть доступ на запись. Если вы храните закрытый ключ SSH на диске, рекомендуется защитить его с помощью парольной фразы. Дополнительные сведения см. в разделе Работа с парольными фразами ключа SSH.
Другой вариант — создать ключи SSH в аппаратном ключе безопасности. Вы можете использовать тот же ключ, что и для двухфакторной проверки подлинности. Аппаратные ключи безопасности очень трудно скомпрометировать удаленно, так как закрытый ключ SSH остается на оборудовании и недоступен напрямую из программного обеспечения. Дополнительные сведения см. в разделе Создание нового ключа SSH и его добавление в ssh-agent.
Аппаратные ключи SSH являются довольно безопасными, но требования к оборудованию могут не работать для некоторых организаций. Альтернативный подход заключается в использовании ключей SSH, которые действительны только в течение короткого периода времени, поэтому даже если закрытый ключ скомпрометирован, его не получится использовать очень долго. Эта концепция лежит в основе запуска собственного центра сертификации SSH. Хотя этот подход обеспечивает широкий контроль над проверкой подлинности пользователей, вам также придется самостоятельно обслуживать центр сертификации SSH. Дополнительные сведения см. в разделе Сведения о центрах сертификации SSH.