This guide describes the highest impact changes you can make to increase account security. Each section outlines a change you can make to your processes to improve the security. The highest impact changes are listed first.
Account security is fundamental to the security of your supply chain. If an attacker can take over your account on GitHub Enterprise Cloud, they can then make malicious changes to your code or build process. So your first goal should be to make it difficult for someone to take over your account and the accounts of other members of your organization or enterprise.
If you're an enterprise or organization owner, you can configure centralized authentication with SAML. While you can add or remove members manually, it's simpler and more secure to set up single sign-on (SSO) and SCIM between GitHub Enterprise Cloud and your SAML identity provider (IdP). This also simplifies the authentication process for all members of your enterprise.
You can configure SAML authentication for an enterprise or organization account. With SAML, you can grant access to the personal accounts of members of your enterprise or organization on GitHub.com through your IdP, or you can create and control the accounts that belong to your enterprise by using Enterprise Managed Users. For more information, see "About authentication for your enterprise."
After you configure SAML authentication, when members request access to your resources, they'll be directed to your SSO flow to ensure they are still recognized by your IdP. If they are unrecognized, their request is declined.
Some IdPs support a protocol called SCIM, which can automatically provision or deprovision access on GitHub Enterprise Cloud when you make changes on your IdP. With SCIM, you can simplify administration as your team grows, and you can quickly revoke access to accounts. SCIM is available for individual organizations on GitHub Enterprise Cloud, or for enterprises that use Enterprise Managed Users. For more information, see "About SCIM for organizations."
The best way to improve the security of your accounts is to configure two-factor authentication (2FA). Passwords by themselves can be compromised by being guessable, by being reused on another site that's been compromised, or by social engineering, like phishing. 2FA makes it much more difficult for your accounts to be compromised, even if an attacker has your password.
If you're an enterprise owner, you may be able to configure a policy to require 2FA for all organizations owned by your enterprise.
If you're an organization owner, then you may be able to require that all members of the organization enable 2FA.
Enterprise owners may be able to require 2FA for all members of the enterprise. The availability of 2FA policies on GitHub Enterprise Cloud depends on how members authenticate to access your enterprise's resources.
If your enterprise uses Enterprise Managed Users or SAML authentication is enforced for your enterprise, you cannot configure 2FA on GitHub Enterprise Cloud. Someone with administrative access to your IdP must configure 2FA for the IdP.
For more information, see "About identity and access management for your enterprise" and "Enforcing policies for security settings in your enterprise."
Note: Depending on the authentication method that an enterprise owner has configured for your enterprise on GitHub.com, you may not be able to enable 2FA for your personal account.
GitHub Enterprise Cloud supports several options for 2FA, and while any of them is better than nothing, the most secure option is WebAuthn. WebAuthn requires either a hardware security key or a device that supports it through things like Windows Hello or Mac TouchID. It's possible, although difficult, to phish other forms of 2FA (for example, someone asking you to read them your 6 digit one-time password). However WebAuthn isn't phishable, because domain scoping is built into the protocol, which prevents credentials from a website impersonating a login page from being used on GitHub Enterprise Cloud.
When you set up 2FA, you should always download the recovery codes and set up more than one factor. This ensures that access to your account doesn't depend on a single device. For more information, see "Configuring two-factor authentication," "Configuring two-factor authentication recovery methods," and GitHub Branded hardware security keys in the GitHub shop.
Note: Depending on the authentication method that an enterprise owner has configured for your enterprise on GitHub.com, you may not be able to require 2FA for your organization.
If you're an organization owner, you can see which users don't have 2FA enabled, help them get set up, and then require 2FA for your organization. To guide you through that process, see:
- "Viewing whether users in your organization have 2FA enabled"
- "Preparing to require two-factor authentication in your organization"
- "Requiring two-factor authentication in your organization"
There are other ways to interact with GitHub Enterprise Cloud beyond signing into the website. Many people authorize the code they push to GitHub with an SSH private key. For more information, see "About SSH."
Just like your account password, if an attacker were able to get your SSH private key, they could impersonate you and push malicious code to any repository you have write access for. If you store your SSH private key on a disk drive, it's a good idea to protect it with a passphrase. For more information, see "Working with SSH key passphrases."
Another option is to generate SSH keys on a hardware security key. You could use the same key you're using for 2FA. Hardware security keys are very difficult to compromise remotely, because the private SSH key remains on the hardware, and is not directly accessible from software. For more information, see "Generating a new SSH key for a hardware security key."
Hardware-backed SSH keys are quite secure, but the hardware requirement might not work for some organizations. An alternative approach is to use SSH keys that are only valid for a short period of time, so even if the private key is compromised it can't be exploited for very long. This is the concept behind running your own SSH certificate authority. While this approach gives you a lot of control over how users authenticate, it also comes with the responsibility of maintaining an SSH certificate authority yourself. For more information, see "About SSH certificate authorities."