Eliminación de datos confidenciales de un repositorio

Acerca de eliminar datos confidenciales de un repositorio

Al modificar el historial del repositorio mediante herramientas como git filter-repo, es fundamental comprender las implicaciones. La reescritura del historial requiere una coordinación cuidadosa con los colaboradores para ejecutarse correctamente y conlleva una serie de efectos secundarios que se deben administrar.

Es importante tener en cuenta que si la información confidencial que necesitas quitar es un secreto (por ejemplo, contraseña, token o credencial), como suele ser el caso, como primer paso debes revocar o rotar ese secreto. Una vez revocado o rotado el secreto, ya no se puede usar para el acceso y puede que esta acción sea suficiente para resolver el problema. Es posible que no esté justificado dar los pasos adicionales para reescribir el historial y quitar el secreto.

Efectos secundarios de la reescritura del historial

Hay muchos efectos secundarios que se derivan de la reescritura del historial, entre los que se incluyen los siguientes:

• Alto riesgo de volver a contaminarlo: desafortunadamente, es fácil volver a insertar los datos confidenciales en el repositorio y que el desastre sea mayor. Si un desarrollador asociado tiene un clon antes de la reescritura y, después de la reescritura, solo ejecuta git pull seguido de git push, se devolverán los datos confidenciales. Deben descartar su clon y volverlo a clonar, o bien seguir con atención varios pasos para limpiar primero su clon.
• Riesgo de perder el trabajo de otros desarrolladores: si otros desarrolladores siguen actualizando ramas que contienen los datos confidenciales mientras intentas limpiar, se te obligará a rehacer la limpieza o a descartar su trabajo.
• Hashes de confirmación modificados: la reescritura del historial cambiará los hashes de las confirmaciones que introdujeron los datos confidenciales y todas las confirmaciones posteriores. Cualquier herramienta o automatización que dependa de los hashes de confirmación que no cambie se interrumpirá o tendrá problemas.
• Desafíos de protección de rama: si tienes protecciones de rama que impidan inserciones forzadas, esas protecciones tendrán que desactivarse (al menos temporalmente) para que se quiten los datos confidenciales.
• Vista de diferencias interrumpida para las solicitudes de incorporación de cambios cerradas: la eliminación de los datos confidenciales requerirá quitar las referencias internas usadas para mostrar la vista de diferencias en las solicitudes de incorporación de cambios, por lo que ya no podrás ver estas diferencias. Esto es cierto no solo para la solicitud de incorporación de cambios que introdujo los datos confidenciales, sino para cualquier solicitud de incorporación de cambios que se basa en una versión del historial posterior a la combinación de la solicitud de incorporación de cambios de datos confidenciales (incluso si esas solicitudes de incorporación de cambios posteriores no agregaron ni modificaron ningún archivo con datos confidenciales).
• Mala interacción con las solicitudes de incorporación de cambios abiertas: los SHA de confirmación modificadas darán lugar a una diferencia de solicitud de cambios diferente y los comentarios sobre la antigua diferencia de solicitud de cambios se pueden invalidar y perder, lo que puede provocar confusión para los autores y revisores. Se recomienda combinar o cerrar todas las solicitudes de incorporación de cambios abiertas antes de quitar archivos del repositorio.
• Firmas perdidas en confirmaciones y etiquetas: las firmas para confirmaciones o etiquetas dependen de hashes de confirmación; dado que los hash de confirmación se modifican mediante reescrituras del historial, las firmas ya no serían válidas y muchas herramientas de reescritura del historial (incluidas git filter-repo) simplemente quitarán las firmas. De hecho, git filter-repo también quitará las firmas de confirmación y las firmas de etiquetas para las confirmaciones anteriores a la eliminación de datos confidenciales. (Técnicamente, se puede solucionar con la opción --refs de git filter-repo si es necesario, pero deberás tener cuidado de asegurarte de especificar todas las referencias que tengan datos confidenciales en su historial y que incluyan las confirmaciones que introdujeron los datos confidenciales en el intervalo).
• Dirigir a otros usuarios directamente a los datos confidenciales: Git se diseñó con comprobaciones criptográficas integradas en identificadores de confirmación para que las personas malvadas no pudieran entrar en un servidor y modificar el historial sin que se note. Esto resulta útil desde una perspectiva de seguridad, pero desde una perspectiva de datos confidenciales significa que la supresión de datos confidenciales es un proceso de coordinación muy complejo; además, significa que cuando se modifica el historial, los usuarios astutos con un clon existente observarán la divergencia del historial y pueden usarlo para encontrar rápidamente y fácilmente los datos confidenciales todavía en su clon que quitaste del repositorio central.

Acerca de la exposición de datos confidenciales

La eliminación de datos confidenciales de un repositorio implica cuatro pasos generales:

• Volver a escribir el repositorio localmente mediante git-filter-repo.
• Actualizar el repositorio en GitHub mediante el historial reescrito localmente.
• Coordinarte con compañeros para limpiar otros clones que existan
• Evitar repeticiones y futuros desbordamientos de datos confidenciales.

Si solo reescribes el historial y fuerzas su inserción, es posible que las confirmaciones con datos confidenciales sigan siendo accesibles en otro lugar:

• En los clones o bifurcaciones de su repositorio
• Directamente a través de sus hash SHA-1 en vistas almacenadas en caché en GitHub
• A través de las solicitudes de cambios que hacen referencia a ellas

No puedes eliminar los datos sensibles desde los clones de tu repositorio que tengan otros usuarios, pero puedes eliminar las vistas almacenadas en caché permanentemente, así como las referencias a los datos confidenciales de las solicitudes de cambios en GitHub poniéndote en contacto con con nosotros a través del Soporte técnico de GitHub.

Si la confirmación que introdujo los datos confidenciales existe en cualquier bifurcación, seguirá siendo accesible allí. Deberá coordinarse con los propietarios de las bifurcaciones, pidiéndoles que eliminen los datos confidenciales o eliminen la bifurcación por completo. GitHub no puede proporcionar información de contacto de estos propietarios.

Considera estas limitaciones y dificultades a la hora de tomar la decisión de reescribir el historial de tu repositorio.

Purga de un archivo del historial del repositorio mediante git-filter-repo

Para ilustrar cómo funciona git filter-repo, le mostraremos cómo quitar el archivo con datos confidenciales del historial del repositorio y cómo agregarlo a .gitignore para asegurarse de que no se vuelva a confirmar accidentalmente.

1. Instale la versión más reciente de la herramienta git filter-repo. Puede instalar git-filter-repo manualmente o mediante un administrador de paquetes. Por ejemplo, para instalar la herramienta con HomeBrew, use el comando brew install.

   brew install git-filter-repo
   

   Para más información, vea INSTALL.md en el repositorio newren/git-filter-repo.

2. Si aún no tiene una copia local del repositorio con datos confidenciales en su historial, clone el repositorio en el equipo local.

   $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
   > Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/
   > remote: Counting objects: 1301, done.
   > remote: Compressing objects: 100% (769/769), done.
   > remote: Total 1301 (delta 724), reused 910 (delta 522)
   > Receiving objects: 100% (1301/1301), 164.39 KiB, done.
   > Resolving deltas: 100% (724/724), done.
   

3. Vaya al directorio de trabajo del repositorio.

   cd YOUR-REPOSITORY
   

4. Ejecute el comando siguiente y reemplace PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA por la ruta al archivo que quiere quitar, no solo su nombre de archivo. Estos argumentos harán lo siguiente:

   • Forzar a Git a procesar, sin extraer del repositorio, todo el historial de cada rama y etiqueta.

   • Quitar el archivo especificado, así como las confirmaciones vacías generadas como resultado.

   • Quite algunas configuraciones, como la dirección URL remota, almacenadas en el archivo .git/config. Es posible que quiera hacer una copia de seguridad de este archivo de antemano para una posterior restauración.

   • Sobrescribir las etiquetas existentes.

       $ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
       Parsed 197 commits
       New history written in 0.11 seconds; now repacking/cleaning...
       Repacking your repo and cleaning out old unneeded objects
       Enumerating objects: 210, done.
       Counting objects: 100% (210/210), done.
       Delta compression using up to 12 threads
       Compressing objects: 100% (127/127), done.
       Writing objects: 100% (210/210), done.
       Building bitmaps: 100% (48/48), done.
       Total 210 (delta 98), reused 144 (delta 75), pack-reused 0
       Completely finished after 0.64 seconds.
     

     Important

     Si el archivo con datos confidenciales existiera en cualquier otra ruta de acceso (porque se movió o se cambió el nombre), debe ejecutar este comando también en esas rutas de acceso.

5. Comprueba que has quitado todo lo que querías del historial del repositorio.

6. La herramienta git filter-repo quitará automáticamente los remotos configurados. Use el comando git remote set-url para restaurar los remotos al remplazar OWNER y REPO por los detalles del repositorio. Para más información, consulta Administrar repositorios remotos.

   git remote add origin https://github.com/OWNER/REPOSITORY.git
   

7. Una vez que estés satisfecho con el estado de tu repositorio y hayas configurado la comunicación remota adecuada, haz un envío forzado de los cambios locales para sobrescribir tu repositorio en GitHub.com. Se requiere una subida forzada para eliminar los datos sensibles de tu historial de confirmaciones.

   $ git push origin --force --all
   > Counting objects: 1074, done.
   > Delta compression using 2 threads.
   > Compressing objects: 100% (677/677), done.
   > Writing objects: 100% (1058/1058), 148.85 KiB, done.
   > Total 1058 (delta 590), reused 602 (delta 378)
   > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
   >  + 48dc599...051452f main -> main (forced update)
   

8. Para quitar el archivo confidencial de las versiones etiquetadas, también deberá forzar la inserción en las etiquetas de Git:

   $ git push origin --force --tags
   > Counting objects: 321, done.
   > Delta compression using up to 8 threads.
   > Compressing objects: 100% (166/166), done.
   > Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done.
   > Total 321 (delta 124), reused 269 (delta 108)
   > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
   >  + 48dc599...051452f main -> main (forced update)
   

Eliminar los datos de GitHub

por completo

Después de usar git filter-repo para quitar los datos confidenciales e insertar los cambios en GitHub, debes realizar algunos pasos adicionales para eliminar totalmente los datos de GitHub.

1. Póngase en contacto con con nosotros a través del Soporte técnico de GitHub para solicitar la eliminación de las vistas almacenadas en caché y referencias a los datos confidenciales en las solicitudes de extracción en GitHub. Proporciona el nombre del repositorio o un vínculo a la confirmación que necesitas eliminar.

   Important

   Soporte de GitHub no quitará datos no confidenciales y solo ayudará a eliminar datos confidenciales en los casos en los que determinemos que el riesgo no se puede mitigar rotando las credenciales afectadas.

2. Indique a los colaboradores que fusionen mediante cambio de base, no que combinen, las ramas que hayan creado fuera del historial de repositorios antiguos (contaminado). Una confirmación de fusión podría volver a introducir algo o todo el historial contaminado sobre el que acabas de tomarte el trabajo de purgar.

Evitar confirmaciones accidentales en el futuro

Impedir que los colaboradores realicen confirmaciones accidentales puede ayudarte a evitar que se exponga información confidencial. Para obtener más información, consulta Procedimientos recomendados para evitar la pérdida de datos en la organización.

Hay algunas cosas que puedes hacer para evitar la confirmación o la inserción de cosas que no deben compartirse:

• Si es probable que los datos confidenciales se encuentren en un archivo al que Git no debe realizar el seguimiento, agrega ese nombre de archivo a .gitignore (y asegúrate de confirmar e insertar ese cambio en .gitignore para que otros desarrolladores estén protegidos).
• Evita secretos codificados de forma rígida en el código. Usa variables de entorno o servicios de administración de secretos como Azure Key Vault, AWS Secrets Manager o HashiCorp Vault para administrar e insertar secretos en tiempo de ejecución.
• Crea un enlace de confirmación previa para comprobar si hay datos confidenciales antes de confirmarlos o insertarlos en cualquier lugar, o bien usa una herramienta conocida en un enlace de confirmación previa, como git-secrets o githunter. (Asegúrate de pedir a cada colaborador que configure el enlace de confirmación previa que has elegido).
• Use un programa visual como GitHub Desktop o gitk para confirmar los cambios. Los programas visuales suelen hacer que sea más sencillo ver exactamente qué archivos se agregarán, eliminarán y modificarán con cada confirmación.
• Evite los comandos generales git add . y git commit -a en la línea de comandos; en su lugar use git add filename y git rm filename para agregar al "stage" los archivos de manera individual.
• Use git add --interactive para revisar y agregar al "stage" los cambios en cada archivo.
• Use git diff --cached a fin de revisar los cambios que ha agregado al "stage" para la confirmación. Esta es la diferencia exacta que producirá git commit siempre que no use la marca -a.
• Habilita la protección de inserción para que el repositorio detecte e impida que las inserciones que contienen secretos codificados de forma rígida se confirmen en el código base. Para más información, consulta Acerca de la protección de inserción.

Información adicional

• Página man de git filter-repo
• Pro Git: Herramientas de Git - Reescritura del historial
• Acerca del examen de secretos