Acerca de esta guía
Esta guía describe los cambios de más alto impacto que puedes hacer para incrementar la seguridad de la cuenta. Cada sección describe un cambio que puedes hacer a tus procesos para mejorar la seguridad. Los cambios de más alto impacto se listan primero.
¿Cuál es el riesgo?
La seguridad de las cuentas es fundamental para la seguridad de tu cadena de suministro. Si un atacante puede apoderarse de tu ceunta en GitHub Enterprise Server, este puede hacer cambios malintencionados a tu código o a tu proceso de compilación. Así que tu primera meta debería ser que fuera difícil que alguien se apoderara de tu cuenta y de las cuentas de otros usuarios de tu instancia de GitHub Enterprise Server.
Centralizar la autenticación
If you're the site administrator for tu instancia de GitHub Enterprise Server, you can simplify the login experience for users by choosing an authentication method that connects with your existing identity provider (IdP), like CAS, SAML, or LDAP. This means that they no longer need to remember an extra password for GitHub.
Some authentication methods also support communicating additional information to GitHub Enterprise Server, for example, what groups the user is a member of, or synchronizing cryptographic keys for the user. This is a great way to simplify your administration as your organization grows.
For more information about the authentication methods available for GitHub Enterprise Server, see "About authentication for your enterprise."
Configure two-factor authentication
La mejor forma de mejorar la seguridad de tu cuenta personal o tu instancia de GitHub Enterprise Server es configurar la autenticación bifactorial (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 the site administrator for tu instancia de GitHub Enterprise Server, you may be able to configure 2FA for all users of your instance. The availability of 2FA on GitHub Enterprise Server depends on the authentication method that you use. For more information, see "Centralize user authentication."
If you're an organization owner, then you may be able to require that all members of the organization enable 2FA.
Configure your enterprise account
Enterprise owners may be able to require 2FA for all users on the instance. The availability of 2FA policies on GitHub Enterprise Server depends on how users authenticate to access your instance.
- If you sign into tu instancia de GitHub Enterprise Server through an external IdP using CAS or SAML SSO, you cannot configure 2FA on GitHub Enterprise Server. Someone with administrative access to your IdP must configure 2FA for the IdP.
- If you sign into tu instancia de GitHub Enterprise Server through an external LDAP directory, you can require 2FA for your enterprise on GitHub Enterprise Server. If you allow built-in authentication for users outside of your directory, individual users can enable 2FA, but you cannot require 2FA for your enterprise.
Para obtener más información, consulta las secciones "Requerir políticas para los ajustes de seguridad en tu empresa".
Configure your personal account
Nota: Dependiendo del método de autenticación que haya configurado un administrador de sitio para tu instancia de GitHub Enterprise Server, podrías no poder habilitar la 2FA para tu cuenta personal.
GitHub Enterprise Server 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 Server.
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. Para obtener más información, consulta las secciones "Configurar la autenticación bifactorial", "Configurar los métodos de recuperación de la autenticación bifactorial" y Llaves de seguridad de hardware con marca de GitHub en la tienda de GitHub.
Configure your organization account
Nota: Dependiendo del método de autenticación que haya configurado un administrador de sitio para tu instancia de GitHub Enterprise Server, podrías no poder requerir la 2FA para tu organización.
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"
Connect to GitHub Enterprise Server using SSH keys
There are other ways to interact with GitHub Enterprise Server 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. Para obtener más información, consulta la sección Acerca de las autoridades de certificados SSH".