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 Cloud, 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 miembros de la organización o empresa.
Centralizar la autenticación
Si es propietario de una empresa u organización, puede configurar la autenticación centralizada con SAML. Puede agregar o quitar miembros manualmente, pero es más sencillo y seguro configurar el inicio de sesión único (SSO) y SCIM entre GitHub Enterprise Cloud y el proveedor de identidades de SAML (IdP). Esto también simplifica el proceso de autenticación para todos los miembros de la empresa.
Puede configurar la autenticación de SAML para una cuenta de empresa u organización. Con SAML, puede conceder acceso a las cuentas personales de los miembros de su empresa u organización en GitHub a través de su IdP, o bien puede crear y controlar las cuentas que pertenecen a su empresa mediante Enterprise Managed Users. Para más información, consulta Acerca de la administración de identidad y de acceso.
Después de configurar la autenticación de SAML, cuando los miembros soliciten acceso a los recursos, se les redirigirá al flujo de inicio de sesión único para garantizar que el IdP los reconoce. Si no se reconocen, se rechaza la solicitud.
Algunos IdP admiten un protocolo denominado SCIM, que puede aprovisionar o desaprovisionar automáticamente el acceso en los datos GitHub Enterprise Cloud al realizar cambios en el IdP. Con SCIM, puede simplificar la administración a medida que crece el equipo, y puede revocar rápidamente el acceso a las cuentas. SCIM está disponible para organizaciones individuales de GitHub Enterprise Cloud o para empresas que usan Enterprise Managed Users. Para más información, consulta Acerca de SCIM para las organizaciones.
Configurar la autenticación en dos fases
Note
A partir de marzo de 2023, GitHub exigió que todos los usuarios que contribuyan con código en GitHub.com habiliten una o varias formas de autenticación en dos fases (2FA). Si estaba en un grupo elegible, habría recibido un correo electrónico de notificación cuando ese grupo fue seleccionado para la inscripción, marcando el comienzo de un período de inscripción 2FA de 45 días, y vería banners que le pedirán que se inscribiese en 2FA en GitHub.com. Si no recibió una notificación, no formaba parte de un grupo al que se le exige que habilite 2FA, aunque se recomienda encarecidamente.
Para obtener más información sobre el lanzamiento de la inscripción 2FA, consulta esta entrada de blog.
La mejor manera de mejorar la seguridad de sus cuentas 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.
Además, es preferible elegir las claves de paso y las claves de seguridad por sobre las aplicaciones autenticadoras (denominadas aplicaciones TOTP) y evitar el uso de SMS siempre que sea posible. Las aplicaciones 2FA y TOTP basadas en SMS son vulnerables a la suplantación de identidad (phishing) y no proporcionan el mismo nivel de protección que las claves de paso y las claves de seguridad . SMS ya no se recomienda en las directrices de identidad digital NIST 800-63B.
Si las cuentas de servicio de la organización se han seleccionado para la inscripción de 2FA por GitHub, sus tokens y claves seguirán funcionando después de la fecha límite sin interrupción. Solo se bloqueará el acceso a GitHub a través de la interfaz de usuario del sitio web hasta que la cuenta haya habilitado 2FA. Se recomienda configurar TOTP como segundo factor para las cuentas de servicio y almacenar el secreto TOTP expuesto durante la instalación en el administrador de contraseñas compartidas de la empresa, con acceso a los secretos controlados mediante SSO.
Si es propietario de la empresa, puede configurar una directiva para exigir la autenticación en dos fases en todas las organizaciones que pertenezcan a su empresa.
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 losmiembros de la empresa. La disponibilidad de las directivas de autenticación en dos fases en GitHub Enterprise Cloud depende de cómo losmiembros se autentican para acceder a los recursos de su empresa.
Si la empresa usa Enterprise Managed Users o se aplica la autenticación de SAML en la empresa, no podrá configurar la autenticación en dos fases en GitHub Enterprise Cloud. Alguien con acceso administrativo a su proveedor de identidades debe configurar la autenticación en dos fases para el proveedor.
Para más información, consulta Acerca de SAML para IAM empresarial y 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 propietario de empresa, es posible que no puedas habilitar la autenticación en dos fases en tu cuenta personal.
GitHub Enterprise Cloud 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 Cloud.
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 propietario de empresa, 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:
- Ver si los usuarios en tu organización han habilitado 2FA
- 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 Cloud mediante claves de SSH
Hay otras maneras de interactuar con los datos GitHub Enterprise Cloud 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.