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 las cuentas de otros usuarios de your GitHub Enterprise Server instance.
Centralizar la autenticación
Si es el administrador del sitio de your GitHub Enterprise Server instance, puede simplificar la experiencia de inicio de sesión para los usuarios eligiendo un método de autenticación que se conecte con el proveedor de identidades existente (IdP), 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.
A fin de obtener más información acerca de los métodos de autenticación disponibles para GitHub Enterprise Server, consulta "Acerca de la autenticación de tu empresa".
Configurar la autenticación en dos fases
La mejor forma de mejorar la seguridad de tu cuenta personal o your GitHub Enterprise Server instance es configurar la autenticación bifactorial (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.
Si es el administrador del sitio de your GitHub Enterprise Server instance, 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, consulte "Centralizar la autenticación de usuarios".
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.
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 your GitHub Enterprise Server instance 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 your GitHub Enterprise Server instance 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 obtener más información, consulte "Aplicación de directivas de configuración de seguridad en la empresa".
Configurar su cuenta personal
Nota: Dependiendo del método de autenticación que un administrador de sitio haya configurado para your GitHub Enterprise Server instance, es posible que no pueda habilitar la autenticación en dos fases para su 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 WebAuthn. WebAuthn requiere una clave de seguridad de hardware o un dispositivo que la admita en sistemas como Windows Hello o Mac TouchID. 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, esto no pasa con WebAuthn, 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 una 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 un factor. Esto garantiza que el acceso a su cuenta no dependa de un único dispositivo. Para obtener más información, consulte "Configuración de la autenticación en dos fases", "Configuración de métodos de recuperación de autenticación en dos fases" y Claves de seguridad de hardware de GitHub en la tienda de GitHub.
Configurar la cuenta de la organización
Nota: Dependiendo del método de autenticación que un administrador de sitio haya configurado para your GitHub Enterprise Server instance, es posible que no pueda exigir la autenticación en dos fases para su 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:
- "Ver si los usuarios de la organización han habilitado la autenticación en dos fases"
- "Prepararse para requerir autenticación de dos factores en tu organización"
- "Requerir autenticación en dos fases en la organización"
Conectarse a GitHub Enterprise Server mediante claves de SSH
Hay otras maneras de interactuar con 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 obtener más información, consulte Acerca de SSH.
Al igual que sucede con la contraseña de la cuenta, si un atacante pudo obtener la clave privada de SSH, podría suplantar tu identidad e insertar código malintencionado en cualquier repositorio para el que tengas 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 obtener más información, consulte "Trabajar con frases de contraseña de clave de 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 obtener más información, consulte "Generación de una nueva clave de SSH para una clave de seguridad de hardware".
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, vea "Acerca de las entidades de certificación de SSH".