Introduction
La prevención de incidentes de seguridad es menos costosa y menos perjudicial que responder a ellos. Al proteger de forma proactiva el entorno en GitHub, reduce la exposición a amenazas como credenciales explotadas, acceso no autorizado y ataques de cadena de suministro.
Esta guía se centra principalmente en las medidas de protección que puede aplicar en todas las organizaciones que forman parte de una empresa en GitHub Enterprise Cloud. Para probar GitHub Enterprise Cloud, consulte Configuración de una versión de prueba de GitHub Enterprise Cloud.
Muchas de las características de GitHubseguridad mencionadas aquí, como configuraciones de seguridad, conjuntos de reglas de rama y controles de acceso, se pueden configurar en el nivel de organización o en el nivel empresarial.
Acciones inmediatas
Estas son acciones de alto impacto que puede realizar ahora mismo para establecer una base de referencia de seguridad en toda una organización.
- Establecimiento de cobertura de seguridad
- Apriete los controles
- Revisión y restricción del acceso
- Ejecución de una evaluación de riesgos secreta
Establecimiento de cobertura de seguridad
Asegúrese de que las herramientas de GitHub están GitHub Advanced Security activas en todos los repositorios. En lugar de habilitar las herramientas una por una, puede crear y aplicar una configuración de seguridad, que es una colección de opciones de seguridad que se pueden aplicar a repositorios de toda la organización o empresa en una sola acción.
Una configuración segura puede incluir:
Secret scanning
** y **protección de envío** para detectar secretos que ya se han confirmado en tu código base y evitar que se envíen nuevos secretos. Las credenciales filtradas son una de las causas más comunes de las infracciones de seguridad.
Code scanning
** para identificar vulnerabilidades y errores de codificación en el código fuente antes de llegar a producción.
Dependabot alerts
** y **Dependabot security updates** para notificarle las vulnerabilidades conocidas y el malware en las dependencias y abrir automáticamente las solicitudes de incorporación de cambios para actualizar las dependencias vulnerables.
Consulta Creación de una configuración de seguridad personalizada (organizaciones) y Creación de una configuración de seguridad personalizada para su empresa (empresas).
Apriete los controles
GitHub proporciona una serie de controles que rigen lo que puede suceder en los repositorios y la organización. Asegurarse de que estos controles están configurados correctamente es esencial para reducir el riesgo.
Proteger ramas críticas con conjuntos de reglas
Los conjuntos de reglas permiten definir reglas de protección para ramas y etiquetas en uno o varios repositorios. Úselos para aplicar requisitos como revisiones de solicitudes de incorporación de cambios y comprobaciones de estado (como exámenes de seguridad automatizados). Esto puede ayudar a evitar que los cambios no autorizados lleguen al código de producción, incluidos los cambios de las cuentas en peligro.
Consulta Creación de conjuntos de reglas para repositorios de la organización (organizaciones) y Imposición de la gobernanza del código en la empresa con conjuntos de reglas (empresas).
Controlar quién puede omitir la protección de empuje
Al habilitar la protección de inserción, los colaboradores que intentan insertar un secreto detectado se bloquean, pero, de forma predeterminada, tienen la opción de omitir el bloque. La omisión delegada requiere que las solicitudes de omisión pasen por un ciclo de revisión y aprobación, por lo que no se puede producir ninguna omisión sin una decisión explícita y auditada.
Consulte Habilitación de la omisión delegada para la protección de inserción.
Aplicación de la revisión de dependencias en las solicitudes de incorporación de cambios
La acción de revisión de dependencias permite detectar dependencias vulnerables antes de fusionarlas, resaltando vulnerabilidades conocidas en los cambios de dependencias de una solicitud de incorporación de cambios. Al igual que la protección contra el envío de secretos, actúa como una puerta en lugar de una alerta retrospectiva. Puede aplicar la revisión de dependencias en las solicitudes de incorporación de cambios en toda la organización.
Consulte Acerca de la revisión de dependencias y Aplicación de la revisión de dependencias en una organización.
Revisión y restricción del acceso
El acceso que era apropiado cuando se otorgó puede que ya no sea necesario. Revisar periódicamente quién y qué tiene acceso a una organización reducen el riesgo de acciones no autorizadas.
Auditar el acceso de los miembros y seguir el principio de privilegios mínimos
Asegúrese de que los miembros de las organizaciones solo tienen el acceso que necesitan. Quite los miembros que ya no necesiten acceso, reduzca el nivel de los roles en los que los permisos más amplios no estén justificados y revise el acceso de colaboradores externos. El acceso excesivamente permisivo aumenta el radio de explosión de cualquier cuenta comprometida.
Si los roles predeterminados son más permisivos que los que requiere una organización, puede crear roles personalizados que solo concedan los permisos específicos que necesita cada equipo. Esto es especialmente útil para las organizaciones que adoptan un modelo de seguridad de confianza cero.
Consulte Identificación de los roles requeridos por la empresa.
Revisión de las aplicaciones autorizadas
OAuth apps y GitHub Apps que están instalados en una organización pueden acceder a los datos. Revise la lista de aplicaciones autorizadas y quite las que ya no sean necesarias o que ya no sean de confianza. Las integraciones obsoletas representan una superficie expuesta a ataques que a menudo se pasa por alto.
Consulte Revisión y modificación de aplicaciones de GitHub instaladas y Acerca de las restricciones de acceso a aplicaciones OAuth.
Restricción del acceso a la red con listas de direcciones IP permitidas
En el caso de las organizaciones en GitHub Enterprise Cloud, si su organización opera desde intervalos de red conocidos, configure una lista de direcciones IP permitidas para restringir el acceso a los recursos de GitHub solo desde esos intervalos. Esto agrega una capa de defensa contra las credenciales en peligro que se usan desde ubicaciones inesperadas.
Consulte Administrar las direcciones IP permitidas en tu organización y Restricción del tráfico de red a la empresa con una lista de direcciones IP permitidas.
Acciones a corto plazo
Estas acciones también son importantes para su posición de seguridad, pero puede requerir más preparación y coordinación antes de poder implementarlas.
- Reforzar la autenticación
- Fortalece tus GitHub Actions flujos de trabajo
- Preparación para un incidente de seguridad
Reforzar la autenticación
La autenticación débil o comprometida es una de las causas más comunes de la adquisición de cuentas. Requerir una autenticación sólida en toda la organización reduce significativamente este riesgo.
Requerir autenticación en dos fases (2FA) para todos los miembros, lo que garantiza que una contraseña en peligro por sí sola no sea suficiente para acceder a una cuenta. Antes de aplicar el requisito, comunique con su organización para que los miembros tengan tiempo para configurar 2FA.
GitHub Enterprise Cloud En las organizaciones pueden avanzar aplicando el inicio de sesión único (SSO), que centraliza la autenticación a través del proveedor de identidades.
Consulte Requerir autenticación en dos fases en la organización y Acerca de la administración de identidades y acceso con el inicio de sesión único de SAML.
Refuerce sus GitHub Actions flujos de trabajo
GitHub Actions Los flujos de trabajo suelen tener acceso a secretos, credenciales de implementación y permisos de escritura en el repositorio. Sin una configuración cuidadosa, una acción comprometida o malintencionada puede filtrar datos o insertar código malintencionado.
Declarar explícitamente permisos de flujo de trabajo
De forma predeterminada, los flujos de trabajo pueden recibir permisos amplios a través de GITHUB_TOKEN. Declare explícitamente los permisos mínimos que necesita cada flujo de trabajo utilizando la clave permissions en los archivos de flujo de trabajo. Esto limita el daño que puede causar un paso de flujo de trabajo comprometido.
Anclar acciones de terceros para confirmar shAs
Al hacer referencia a una acción de terceros por etiqueta (por ejemplo, v1), la etiqueta se puede mover para que apunte a código diferente. Anclar acciones a una confirmación completa SHA garantiza que siempre ejecute el código exacto que ha revisado y aprobado. Esto protege contra los ataques de la cadena de suministro en los que se secuestra una etiqueta.
Restringir qué acciones se pueden ejecutar
Configure directivas en el nivel de organización o de empresa para controlar qué acciones se pueden ejecutar. Puede limitar las acciones a las creadas por GitHub, las acciones de creadores comprobados o una lista de permitidos específica.
Para obtener más información sobre todas estas prácticas, así como prácticas de uso seguras adicionales para GitHub Actions específicamente, consulte Referencia de uso seguro.
Prácticas de seguridad en curso
Estas prácticas deben formar parte del ritmo operativo normal.
- Supervisa tu postura de seguridad con visión general de seguridad
- Ejecutar campañas de seguridad periódicas para reducir la deuda de seguridad
- Continuar auditando el acceso y los permisos
- Mantener actualizadas las dependencias
- Rotación de secretos y aplicación de la expiración
Monitorea tu postura de seguridad con el resumen de seguridad
La información general de seguridad proporciona una vista centralizada del panorama de seguridad de una organización y de la empresa. Úselo para realizar un seguimiento de qué repositorios tienen habilitadas las características de seguridad e identificar repositorios con alertas abiertas, de modo que los riesgos emergentes no pasen desapercibidos.
Consulte Información general sobre seguridad.
Ejecutar campañas de seguridad periódicas para reducir la deuda de seguridad
Con el tiempo, las alertas de seguridad se pueden acumular. Las campañas de seguridad permiten organizar y priorizar los esfuerzos de corrección, asignar grupos de alertas a los desarrolladores (con la ayuda de Copilotcorrecciones generadas) o asignar alertas directamente a Copilot.
Las campañas de seguridad están disponibles para las organizaciones en GitHub Team o GitHub Enterprise Cloud con GitHub Advanced Security habilitado. Consulte Creación y administración de campañas de seguridad.
Continuar auditando el acceso y los permisos
A medida que las personas se unen a una organización y dejan una organización, y a medida que evolucionan los proyectos, cambian los requisitos de acceso. Programar revisiones periódicas de:
- Pertenencia y roles de la organización.
- Acceso de colaborador externo.
- Permisos de nivel de repositorio y asignaciones de equipo.
- OAuth autorizado y GitHub Apps.
Esto garantiza que el acceso permanezca alineado con el principio de privilegios mínimos, incluso a medida que cambia la organización.
Mantener actualizadas las dependencias
Las dependencias vulnerables son un punto de entrada común para los atacantes. Dependabot puede abrir automáticamente solicitudes de incorporación de cambios para actualizar las dependencias con vulnerabilidades conocidas, pero esas solicitudes de incorporación de cambios aún deben revisarse y combinarse rápidamente.
Establezca un proceso para gestionar y combinar pull requests Dependabot para que las actualizaciones de seguridad no se detengan.
Consulte Acerca de Evaluación de prioridades automática de Dependabot y Administrar las solicitudes de extracción para las actualizaciones de dependencia.
Rotar secretos e imponer expiración
Cuanto más tiempo exista una credencial, más oportunidad hay para que se exponga o lo roben. Siempre que sea posible:
- Establezca fechas de expiración en personal access tokens.
- Rotación de secretos según una programación normal.
Para obtener información sobre cómo administrar tokens, consulte Administración de tokens de acceso personal y Vencimiento y revocación de tokens.
Pasos siguientes
- Incluso con controles preventivos fuertes en su lugar, los incidentes de seguridad todavía pueden producirse. Hay varias herramientas críticas y procesos de respuesta que debe asegurarse de que están configurados de antemano. Consulte Preparación de un incidente de seguridad.