Рекомендации по защите учетных записей

Об этом руководстве

В этом руководстве описываются самые важные изменения, которые можно внести для повышения безопасности учетной записи. В каждом разделе описаны изменения, которые можно внести в процессы для повышения безопасности. Сначала указаны изменения с самым высоким влиянием.

В чем заключаются риски?

Безопасность учетных записей имеет важное значение для обеспечения безопасности цепочки поставок. Если злоумышленники перехватят контроль над вашей учетной записью GitHub Enterprise Server, они затем смогут внести вредоносные изменения в ваш код или процесс сборки. Поэтому ваша первая цель должна заключаться в том, чтобы кто-то затруднил управление вашей учетной записью и учетными записями других пользователей экземпляр GitHub Enterprise Server.

Централизованная проверка подлинности

Если вы являетесь администратором сайта экземпляр GitHub Enterprise Server, вы можете упростить процесс входа для пользователей, выбрав метод проверки подлинности, который подключается к существующему поставщику удостоверений (IdP), например CAS, SAML или LDAP. Это означает, что им больше не придется запоминать дополнительный пароль для GitHub.

Некоторые методы проверки подлинности также поддерживают передачу дополнительных сведений в GitHub Enterprise Server, например, о членстве пользователя в группе или о синхронизации криптографических ключей для пользователя. Это отличный способ упростить администрирование по мере роста организации.

Дополнительные сведения о методах проверки подлинности, доступных для GitHub Enterprise Server, см. в разделе Сведения о проверке подлинности для вашей организации.

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

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

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

Если вы являетесь администратором сайта экземпляр GitHub Enterprise Server, вы можете настроить 2FA для всех пользователей вашего экземпляра. Доступность двухфакторной проверки подлинности в GitHub Enterprise Server зависит от используемого вами способа проверки подлинности. Дополнительные сведения см. в разделе Централизация проверки подлинности пользователей.

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

Дополнительные сведения о включении 2FA для собственной учетной записи см. в разделе Настройка двухфакторной проверки подлинности. Дополнительные сведения о требованиях 2FA в организации см. в разделе Обязательная двухфакторная проверка подлинности в вашей организации.

Настройка корпоративной учетной записи

Владельцы предприятия имеют возможность требовать двухфакторную проверку подлинности для всех пользователей в экземпляра. Доступность политик двухфакторной проверки подлинности в GitHub Enterprise Server зависит от того, как выполняется проверка подлинности пользователей для доступа к вашему экземпляру.

При входе в экземпляр GitHub Enterprise Server через внешний поставщик удостоверений с помощью CAS или SAML SSO вы не сможете настроить 2FA в GitHub Enterprise Server. Пользователь с административным доступом к вашему поставщику удостоверений должен настроить двухфакторную проверку подлинности для этого поставщика удостоверений.

Если вы входите в экземпляр GitHub Enterprise Server через внешний каталог LDAP, вы можете потребовать 2FA для предприятия в GitHub Enterprise Server. Если вы разрешаете встроенную проверку подлинности для пользователей за пределами каталога, отдельные пользователи могут включить двухфакторную проверку подлинности, но ее нельзя включить для всего вашего предприятия.

Дополнительные сведения см. в разделах "Применение политик для параметров безопасности в вашем предприятии".

Настройка личной учетной записи

Примечание. В зависимости от метода проверки подлинности, настроенного администратором сайта для экземпляр GitHub Enterprise Server, вы не сможете включить 2FA для личная учетная запись.

GitHub Enterprise Server поддерживает несколько вариантов двухфакторной проверки подлинности, и хотя любой из них лучше, чем ничего, наиболее безопасным является WebAuthn. Для WebAuthn требуется аппаратный ключ безопасности или устройство, которое поддерживает его через такие приложения, как Windows Hello или Mac TouchID. Фишинг других форм двухфакторной проверки подлинности (например, кто-то просит вас прочитать 6 цифр одноразового пароля) возможен, хотя и затруднителен. Но WebAuthn не поддается фишингу, поскольку в протокол встроен контроль области домена, что предотвращает использование учетных данных с веб-сайта, выдающего себя за страницу входа, в GitHub Enterprise Server.

При настройке двухфакторной проверки подлинности следует всегда скачивать коды восстановления и настраивать несколько факторов. Это гарантирует, что доступ к учетной записи не будет зависеть от одного устройства. Дополнительные сведения см. в разделах Настройка двухфакторной проверки подлинности и Настройка методов восстановления для двухфакторной проверки подлинности.

Настройка учетной записи организации

Примечание. В зависимости от метода проверки подлинности, который администратор сайта настроил для экземпляр GitHub Enterprise Server, вы не сможете требовать 2FA для вашей организации.

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

Подключение к GitHub Enterprise Server с помощью ключей SSH

Существуют и другие способы взаимодействия с GitHub Enterprise Server помимо входа на веб-сайт. Многие пользователи авторизуют код, который они отправляют в GitHub, с помощью закрытого ключа SSH. Дополнительные сведения см. в разделе Сведения о протоколе SSH.

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

Другой вариант — создать ключи SSH в аппаратном ключе безопасности. Вы можете использовать тот же ключ, что и для двухфакторной проверки подлинности. Аппаратные ключи безопасности очень трудно скомпрометировать удаленно, так как закрытый ключ SSH остается на оборудовании и недоступен напрямую из программного обеспечения. Дополнительные сведения см. в разделе Создание нового ключа SSH и его добавление в ssh-agent.

Аппаратные ключи SSH довольно безопасны, но требования к оборудованию могут не работать для некоторых организаций. Альтернативный подход заключается в использовании ключей SSH, которые действительны только в течение короткого периода времени, поэтому даже если закрытый ключ скомпрометирован, его не получится использовать очень долго. Эта концепция лежит в основе запуска собственного центра сертификации SSH. Хотя этот подход обеспечивает широкий контроль над проверкой подлинности пользователей, вам также придется самостоятельно обслуживать центр сертификации SSH. Дополнительные сведения см. в разделе Сведения о центрах сертификации SSH.