Об этом руководстве
В этом руководстве описываются самые важные изменения, которые можно внести для повышения безопасности учетной записи. В каждом разделе описаны изменения, которые можно внести в процессы для повышения безопасности. Сначала указаны изменения с самым высоким влиянием.
В чем заключаются риски?
Безопасность учетных записей имеет важное значение для обеспечения безопасности цепочки поставок. Если злоумышленник может взять на себя учетную запись на GitHub, он может внести вредоносные изменения в код или процесс сборки. Поэтому ваша первая цель заключается в том, чтобы затруднить кого-то взять на себя учетную запись и учетные записи других members ваша организация или предприятие.
Централизованная проверка подлинности
Если вы являетесь владельцем предприятия или организации, можно настроить централизованную проверку подлинности с помощью SAML. Хотя вы можете добавить или удалить участников вручную, проще и безопаснее настроить единый вход (SSO) и SCIM между переменными данных.product.github %} и поставщиком удостоверений SAML (IdP). Это также упрощает процесс проверки подлинности для всех участников вашего предприятия.
Вы можете настроить проверку подлинности SAML для учетной записи предприятия или организации. С помощью SAML вы можете предоставить доступ к личная учетная запись членам вашей организации или организации на GitHub с помощью поставщика удостоверений или управлять учетными записями, принадлежащими вашей организации, с помощью Enterprise Managed Users. Дополнительные сведения см. в разделе Основы управления идентификацией и доступом.
Когда вы настроите проверку подлинности SAML, участники, запрашивающие доступ к вашим ресурсам, будут направляться в поток единого входа для проверки, распознаются ли они поставщиком удостоверений. Если они не распознаются, запрос отклоняется.
Некоторые поставщики удостоверений поддерживают протокол SCIM, который может автоматически подготавливать или отменять доступ к GitHub при внесении изменений в поставщик удостоверений. С помощью SCIM вы можете упростить администрирование по мере роста команды, а также быстро отзывать доступ к учетным записям. SCIM доступен для отдельных организаций в GitHub Enterpriseили для предприятий, использующих Enterprise Managed Users. Дополнительные сведения см. в разделе Сведения о SCIM для организаций.
Настройка двухфакторной проверки подлинности
Примечание.
Дополнительные сведения о выпуске регистрации 2FA см . в этой записи блога.
Лучший способ повысить безопасность ваши учетные записи — настроить двухфакторную проверку подлинности (2FA). Пароли сами по себе могут быть скомпрометированы путем угадывания, в результате повторного использования на другом сайте, который был скомпрометирован, или с помощью методов социотехники, например фишинга. Двухфакторная проверка подлинности значительно усложняет компрометацию учетных записей, даже если у злоумышленника есть пароль.
Для обеспечения безопасности и надежного доступа к вашей учетной записи всегда должно быть не менее двух учетных данных второго фактора, зарегистрированных в вашей учетной записи. Дополнительные учетные данные гарантируют, что даже если вы потеряете доступ к одному учетным данным, вы не будете заблокированы из учетной записи.
Кроме того, следует предпочесть ключи доступа и ключи безопасности для приложений authenticator (называемых приложениями TOTP) и по возможности избегать использования SMS. Приложения на основе SMS на основе 2FA и TOTP уязвимы для фишинга и не обеспечивают одинаковый уровень защиты, как ключи доступа и ключи безопасности. SMS больше не рекомендуется в соответствии с рекомендациями по цифровым удостоверениям NIST 800-63B .
Если учетные записи служб в вашей организации были выбраны для регистрации 2FA с помощью GitHub, их маркеры и ключи будут продолжать работать после крайнего срока без прерывания. Доступ только к GitHub через пользовательский интерфейс веб-сайта будет заблокирован, пока учетная запись не включила 2FA. Мы рекомендуем настроить TOTP в качестве второго фактора для учетных записей служб и сохранить секрет TOTP, предоставляемый во время установки в диспетчере общих паролей вашей компании, с доступом к секретам, контролируемым через единый вход.
Если вы являетесь владельцем предприятия, вы можете настроить политику, требующую обязательной двухфакторной проверки подлинности во всех организациях, принадлежащих вашему предприятию.
Если вы являетесь владельцем организации, то имеете возможность потребовать, чтобы все члены организации включили двухфакторную проверку подлинности.
Дополнительные сведения о включении 2FA в собственной учетной записи см. в разделе Настройка двухфакторной проверки подлинности. Дополнительные сведения о необходимости 2FA в организации см. в разделе Обязательная двухфакторная проверка подлинности в вашей организации.
Настройка корпоративной учетной записи
Владельцы предприятия имеют возможность требовать двухфакторную проверку подлинности для всех членов предприятия. Доступность политик 2FA на GitHub зависит от того, как members пройти проверку подлинности для доступа к корпоративные ресурсы.
если ваше предприятие использует Enterprise Managed Users или проверку подлинности SAML для вашего предприятия, то не удается настроить 2FA на GitHub. Пользователь с административным доступом к вашему поставщику удостоверений должен настроить двухфакторную проверку подлинности для этого поставщика удостоверений.
Дополнительные сведения см. в разделе [AUTOTITLE и Сведения о SAML для корпоративной системы IAM](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise#requiring-two-factor-authentication-for-organizations-in-your-enterprise).
Настройка личной учетной записи
Примечание.
В зависимости от метода проверки подлинности, настроенного владелец предприятия, возможно, не удается включить 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 для вашей организации.
Если вы являетесь владельцем организации, то можете видеть, у каких пользователей не включена двухфакторная проверка подлинности. Помогите им ее настроить, а затем можете требовать использование двухфакторной проверки подлинности в вашей организации. Инструкции по выполнению этого процесса см. в следующих разделах.
-
[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/viewing-whether-users-in-your-organization-have-2fa-enabled) -
[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/preparing-to-require-two-factor-authentication-in-your-organization) -
[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)
Подключение к GitHub с помощью ключей SSH
Существуют другие способы взаимодействия с GitHub после входа на веб-сайт. Многие пользователи авторизуют код, который они передают в GitHub с закрытым ключом SSH. Дополнительные сведения см. в разделе Сведения о протоколе SSH.
Как и в случае с паролем учетной записи, если злоумышленник получит ваш закрытый ключ SSH, он может выдать себя за вас и отправить вредоносный код в любой репозиторий, в котором у вас есть доступ на запись. Если вы храните закрытый ключ SSH на диске, рекомендуется защитить его с помощью парольной фразы. Дополнительные сведения см. в разделе Работа с парольными фразами ключа SSH.
Другой вариант — создать ключи SSH в аппаратном ключе безопасности. Вы можете использовать тот же ключ, что и для двухфакторной проверки подлинности. Аппаратные ключи безопасности очень трудно скомпрометировать удаленно, так как закрытый ключ SSH остается на оборудовании и недоступен напрямую из программного обеспечения. Дополнительные сведения см. в разделе Создание нового ключа SSH и его добавление в ssh-agent.
Аппаратные ключи SSH являются довольно безопасными, но требования к оборудованию могут не работать для некоторых организаций. Альтернативный подход заключается в использовании ключей SSH, которые действительны только в течение короткого периода времени, поэтому даже если закрытый ключ скомпрометирован, его не получится использовать очень долго. Эта концепция лежит в основе запуска собственного центра сертификации SSH. Хотя этот подход обеспечивает широкий контроль над проверкой подлинности пользователей, вам также придется самостоятельно обслуживать центр сертификации SSH. Дополнительные сведения см. в разделе Сведения о центрах сертификации SSH.
Дальнейшие шаги
-
[AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview) -
[AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code) -
[AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds) -
[AUTOTITLE](/code-security/getting-started/best-practices-for-preventing-data-leaks-in-your-organization)