Procedimientos recomendados para evitar la pérdida de datos en la organización

Acerca de esta guía

Como propietario de la organización, evitar la exposición de datos privados o confidenciales debe ser una prioridad máxima. Ya sea intencionada o accidental, la pérdida de datos puede representar un riesgo considerable para las partes implicadas. Aunque GitHub toma medidas para ayudarle a protegerse frente a pérdidas de datos, también es responsable de administrar la organización para proteger la seguridad.

Hay varios componentes clave en lo que respecta a la defensa frente a la pérdida de datos:

• Adopción de un enfoque proactivo hacia la prevención
• Detección temprana de posibles pérdidas
• Mantenimiento de un plan de mitigación cuando se produce un incidente

El mejor enfoque dependerá del tipo de organización que administra. Por ejemplo, una organización que se centra en el desarrollo de código abierto podría requerir controles más flexibles que una organización totalmente comercial, para permitir la colaboración externa. En este artículo se proporciona orientación de alto nivel sobre las características y la GitHub configuración que se deben tener en cuenta, las cuales debe implementar según sus necesidades.

Cuentas seguras

Protege los repositorios y la configuración de la organización mediante la implementación de procedimientos recomendados de seguridad, incluida la habilitación de 2FA y su obligatoriedad para todos los miembros, y el establecimiento de directrices de contraseña seguras.

• Requerir a los miembros de la organización, colaboradores externos y administradores de facturación que habiliten 2FA para sus cuentas personales, lo que dificulta que los actores malintencionados accedan a los repositorios y la configuración de una organización. Para más información, consulta Requerir autenticación en dos fases en la organización.

• Animar a los usuarios a crear contraseñas seguras y protegerlas adecuadamente siguiendo GitHublas instrucciones recomendadas de contraseña. Para obtener más información, consulte Crear una contraseña segura.

• Anima a los usuarios a mantener habilitada la protección de inserción para usuarios en las configuraciones de sus cuentas personales de modo que, independientemente del repositorio público de inserción, estén protegidos. Para obtener más información, consulte Gestión de la protección de notificaciones para los usuarios.

• Establecer una directiva de seguridad interna en GitHub, para que los usuarios conozcan los pasos adecuados que deben realizarse y quién ponerse en contacto si se sospecha un incidente. Para más información, consulta Agregar una política de seguridad a tu repositorio.

Para obtener información más detallada sobre la protección de cuentas, consulte Procedimientos recomendados para proteger las cuentas.

Impedir las pérdidas de datos

Como propietario de una organización, debes limitar y revisar el acceso según corresponda para el tipo de organización. Ten en cuenta la siguiente configuración para un control más estricto:

Recomendación	Información adicional
Deshabilita la capacidad de bifurcar repositorios.

          [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository)

Deshabilita el cambio de la visibilidad del repositorio. | Restringir cambios en la visibilidad de los repositorios en tu organización Restringe la creación de repositorios a privada o interna. |
Restringir la creación de repositorios en tu organización Deshabilita la eliminación y transferencia de repositorios. | Configurar permisos para eliminar o transferir repositorios en tu organización | | Ámbito personal access tokenpara los permisos mínimos necesarios. | Ninguno Protege el código mediante la conversión de repositorios públicos en privados siempre que corresponda. Puede alertar a los propietarios del repositorio de este cambio automáticamente mediante .GitHub App | Prevent-Public-Repos en GitHub Marketplace Confirma la identidad de tu organización mediante la comprobación del dominio y la restricción de las notificaciones por correo electrónico solo a dominios de correo electrónico comprobados. | Verificar o aprobar un dominio para tu organización Asegúrese de que su organización se ha actualizado al GitHub Contrato de cliente en lugar de usar los Términos de servicio estándar. | Actualización al contrato de cliente de GitHub Evita que los colaboradores realicen confirmaciones accidentales. | Eliminación de datos confidenciales de un repositorio

Detección de pérdida de datos

Independientemente de lo bien que fortalezca su organización para evitar fugas de datos, algunas aún pueden ocurrir y puede responder utilizando secret scanning, el registro de auditoría y las normas de protección de ramas.

Utilice secret scanning

          Secret scanning ayuda a proteger el código y mantener los secretos seguros en todas las organizaciones y repositorios escaneando y detectando secretos que se han comprometido accidentalmente en el historial completo de Git de cada rama en los repositorios de GitHub. Cualquier cadena que coincida con los patrones proporcionados por los asociados de análisis de secretos , por otros proveedores de servicios o definidos por usted o su organización, se notifican como alertas en la pestaña **Seguridad** de los repositorios.

Hay dos formas de secret scanning disponibles: Alertas de escaneo de secretos para socios y Alertas de escaneo de secretos para usuarios.

•         Alertas de escaneo de secretos para socios: se habilitan de forma predeterminada y se ejecutan automáticamente en todos los repositorios públicos y paquetes npm públicos.
  

•         Alertas de escaneo de secretos para usuarios: Para obtener capacidades de escaneo adicionales para su organización, debe habilitar alertas de escaneo de secretos para usuarios.
  

  Cuando está habilitada, alertas de escaneo de secretos para usuarios se puede detectar en los siguientes tipos de repositorio:

  • Repositorios públicos propiedad de cuentas personales en GitHub.com
  • Repositorios públicos que poseen las organizaciones
  • Repositorios privados e internos que pertenecen a organizaciones que usan GitHub Team o GitHub Enterprise Cloud, con una licencia para GitHub Code Security

Para obtener más información sobre secret scanning, consulta Acerca del examen de secretos.

          También puede habilitar secret scanning como protección de inserción para un repositorio o una organización. Al habilitar esta característica, secret scanning impide que los colaboradores inserten código con un secreto detectado. Para obtener más información, consulte [AUTOTITLE](/code-security/secret-scanning/protecting-pushes-with-secret-scanning). Por último, también puedes ampliar la detección para incluir estructuras de cadena secreta personalizadas. Para más información, consulta [AUTOTITLE](/code-security/secret-scanning/using-advanced-secret-scanning-and-push-protection-features/custom-patterns/defining-custom-patterns-for-secret-scanning).

Revisión del registro de auditoría de la organización

También puedes proteger la IP de forma proactiva y mantener el cumplimiento de tu organización gracias al aprovechamiento del registro de auditoría de la misma, junto con GraphQL Audit Log API. Para más información, consulta Revisar el registro de auditoría de tu organización y Interfaces.

Configuración de las reglas de protección de ramas

Para asegurarte de que todo el código se revisa correctamente antes de combinarse en la rama predeterminada, puedes habilitar la protección de ramas. Al establecer reglas de protección de ramas, puedes aplicar determinados flujos de trabajo o requisitos antes de que un colaborador pueda enviar cambios. Para más información, consulta Acerca de las ramas protegidas.

Como alternativa a las reglas de protección de ramas, puede crear conjuntos de reglas. Los conjuntos de reglas tienen algunas ventajas sobre las reglas de protección de ramas, como estados, y una mejor detectabilidad sin necesidad de acceso de administrador. Puedes aplicar igualmente varios conjuntos de reglas al mismo tiempo. Para más información, consulta Acerca de los conjuntos de reglas.

Mitigación de la pérdida de datos

Si un usuario inserta datos confidenciales, pídale que los quite mediante la herramienta git filter-repo. Para más información, consulta Eliminación de datos confidenciales de un repositorio. Además, si aún no se han insertado los datos confidenciales, puede deshacer esos cambios localmente; para obtener más información, consulte the GitHub Blog (pero tenga en cuenta que git revert no es una manera válida de deshacer la adición de datos confidenciales, ya que deja la confirmación confidencial original en el historial de Git).

Si no puedes coordinarte directamente con el propietario del repositorio para quitar los datos que estás seguro de poseer, puedes rellenar un formulario de aviso de eliminación de DMCA e informar al soporte técnico de GitHub al respecto. Asegúrese de incluir los hashes de confirmación problemáticos. Para obtener más información, consulta Aviso de eliminación de DMCA.

Revocar tokens expuestos

Si las credenciales se han expuesto en un GitHub repositorio, GitHubsecret scanning se pueden usar para notificar y revocar las credenciales. Para más información, consulta Resolución de alertas del análisis de secretos.

También puede revocar las credenciales expuestas que no posee y que se han expuesto fuera de los GitHub repositorios. Al hacerlo, contribuye a la seguridad general de la GitHub comunidad y puede limitar rápidamente el impacto de estas credenciales. La API admite la revocación de:

•         Personal access tokens (classic) con el `ghp_` prefijo
  

•         Fine-grained personal access tokens con el `github_pat_` prefijo
  

•         OAuth app tokens con el prefijo `gho_`
  

•         GitHub App tokens de usuario-servidor con el prefijo `ghu_`
  

•         GitHub App reemplazo de tokens con el prefijo `ghr_`
  

Si encuentra algún token expuesto en GitHub o en otro lugar, puede enviar una solicitud de revocación mediante la API REST. Consulte Revocación para obtener la lista completa y autoritativa de los tipos de credenciales admitidos.

Pasos siguientes

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)