Procedimientos recomendados para proteger las cuentas

Acerca de esta guía

En esta guía se describen los cambios de mayor impacto que puede realizar para mejorar la seguridad de la cuenta. Cada sección detalla un cambio que puede realizar en los procesos para mejorar la seguridad. Los cambios de mayor impacto se enumeran primero.

¿Cuál es el riesgo?

La seguridad de la cuenta es fundamental para la seguridad de la cadena de suministro. Si un atacante puede tomar el control de su cuenta en GitHub Enterprise Server, puede realizar cambios malintencionados en el código o el proceso de compilación. Por lo tanto, su primer objetivo debe ser dificultar que alguien tome el control de su cuenta y de las cuentas de otros usuarios de la instancia.

Centralizar la autenticación

Si es el administrador del sitio de la instancia, puede simplificar la experiencia de inicio de sesión para los usuarios si elige un método de autenticación que se conecte con el proveedor de identidades (IdP) existente, como CAS, SAML o LDAP. Esto significa que ya no necesitan recordar una contraseña adicional para GitHub.

Algunos métodos de autenticación también admiten la comunicación de información adicional con GitHub Enterprise Server, por ejemplo, especificar de qué grupos es miembro el usuario o la sincronización de claves criptográficas para el usuario. Esta es una excelente manera de simplificar la administración a medida que la organización crece.

Para más información sobre los métodos de autenticación disponibles para GitHub Enterprise Server, consulta Acerca de la administración de identidad y de acceso.

Configurar la autenticación en dos fases

La mejor manera de mejorar la seguridad de su cuenta personal o su instancia consiste en configurar la autenticación en dos fases (2FA). Las contraseñas por sí mismas pueden verse expuestas si son fáciles de adivinar, al reutilizarse en otro sitio que se haya visto expuesto o por ingeniería social, como el phishing. La autenticación en dos fases hace que sea mucho más difícil que las cuentas se vean expuestas, incluso si un atacante tiene su contraseña.

Como procedimiento recomendado, para garantizar la seguridad y el acceso fiable a su cuenta, siempre debe tener al menos dos credenciales de segundo factor registradas en su cuenta. Las credenciales adicionales garantizan que, incluso si pierde el acceso a una credencial, no se bloqueará la cuenta.

Si es el administrador del sitio de su instancia, puede configurar la autenticación en dos fases para todos los usuarios de la instancia. La disponibilidad de la autenticación en dos fases en GitHub Enterprise Server depende del método de autenticación que use. Para obtener más información, consulta Centralizar la autenticación.

Si es propietario de la organización, puede ser capaz de exigir que todos los miembros de la organización habiliten la autenticación en dos fases.

Para obtener más información sobre cómo habilitar 2FA en tu propia cuenta, consulta Configurar la autenticación de dos factores. Para obtener más información sobre la necesidad de 2FA en tu organización, consulta Requerir autenticación en dos fases en la organización.

Configurar su cuenta de empresa

Los propietarios de empresas pueden exigir el uso de la autenticación en dos fases para todos losusuarios de la instancia. La disponibilidad de las directivas de autenticación en dos fases en GitHub Enterprise Server depende de cómo losusuarios se autentican para acceder a los recursos de su instancia.

Si inicia sesión en GitHub Enterprise Server a través de un IdP externo mediante el inicio de sesión único de CAS o SAML, no podrá configurar la autenticación en dos fases en GitHub Enterprise Server. Alguien con acceso administrativo a su proveedor de identidades debe configurar la autenticación en dos fases para el proveedor.
Si inicia sesión en GitHub Enterprise Server a través de un directorio LDAP externo, puede exigir la autenticación en dos fases para su empresa en GitHub Enterprise Server. Si permite la autenticación integrada para los usuarios fuera del directorio, los usuarios individuales podrán habilitar la autenticación en dos fases, pero no podrán exigirla en su empresa.

Para más información, consulta Requerir las políticas para los ajustes de seguridad en tu empresa.

Configurar su cuenta personal

Note

En función del método de autenticación que haya configurado un administrador de sitios, es posible que no puedas habilitar la autenticación en dos fases en tu cuenta personal.

GitHub Enterprise Server admite varias opciones de autenticación en dos fases y, aunque cualquiera de ellas es mejor que nada, la opción más segura es la credencial WebAuthn. WebAuthn requiere un autenticador como una clave de seguridad de hardware FIDO2, un autenticador de plataforma como Windows Hello, un teléfono Apple o Google o un administrador de contraseñas. Es posible, aunque difícil, suplantar otras formas de autenticación en dos fases (por ejemplo, alguien que le pida que lea su contraseña puntual de 6 dígitos). Sin embargo, WebAuthn es mucho más resistente a la suplantación de identidad ya que el alcance del dominio está integrado en el protocolo, lo que impide que se usen credenciales de un sitio web que traten de suplantar la página de inicio de sesión en GitHub Enterprise Server.

Al configurar la autenticación en dos fases, siempre debe descargar los códigos de recuperación y configurar más de una credencial de autenticación en dos fases. Esto garantiza que el acceso a su cuenta no dependa de un único dispositivo. Para más información, consulta Configurar la autenticación de dos factores y Configurar la autenticación de dos factores mediante métodos de recuperación.

Configurar la cuenta de la organización

Note

En función del método de autenticación que haya configurado un administrador de sitios, es posible que no puedas exigir la autenticación en dos fases en tu organización.

Si es propietario de la organización, puede ver qué usuarios no tienen habilitada la autenticación en dos fases, ayudarles a configurarla y, a continuación, exigirla en su organización. Para guiarle a través de ese proceso, consulte:

Conectarse a GitHub Enterprise Server mediante claves de SSH

Hay otras maneras de interactuar con los datos GitHub Enterprise Server además de iniciar sesión en el sitio web. Muchas personas autorizan el código que insertan en GitHub con una clave privada de SSH. Para más información, consulta Acerca de SSH.

Al igual que la contraseña de la cuenta, si un atacante pudo obtener la clave privada de SSH, podría suplantar su identidad e insertar código malintencionado en cualquier repositorio para el que tenga acceso de escritura. Si almacena la clave privada de SSH en una unidad de disco, es recomendable protegerla con una frase de contraseña. Para más información, consulta Trabajar con contraseñas de clave SSH.

Otra opción es generar claves de SSH una clave de seguridad de hardware. Puede usar la misma clave que está usando para la autenticación en dos fases. Las claves de seguridad de hardware son muy difíciles de exponer de forma remota, ya que la clave de SSH privada permanece en el hardware y no es accesible directamente desde el software. Para más información, consulta Generación de una nueva clave SSH y adición al agente SSH.

Las claves de SSH respaldadas por hardware son bastante seguras, pero es posible que el requisito de hardware no funcione para algunas organizaciones. Un enfoque alternativo consiste en usar claves de SSH que solo sean válidas durante un breve período de tiempo, por lo que aunque la clave privada esté en peligro, no se podrá usar durante mucho tiempo. Este es el concepto que respalda la ejecución de su propia entidad de certificación de SSH. Aunque este enfoque proporciona un gran control sobre cómo se autentican los usuarios, también viene con la responsabilidad de mantener una entidad de certificación de SSH por su cuenta. Para más información, consulta Acerca de las autoridades de certificación de SSH.