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 Enterprise Server
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 Enterprise Server poniéndote en contacto con el administrador del sitio.

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.

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

Warning

Si ejecuta git filter-repo después del guardado provisional de cambios, no podrá recuperar los cambios con otros comandos de stash. Antes de ejecutar git filter-repo, se recomienda no modificar los cambios realizados. Para deshacer el último conjunto de cambios que ha guardado de forma provisional, ejecute git stash show -p | git apply -R. Para más información, vea Herramientas de Git: Almacenamiento provisional y limpieza.

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.

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.

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://HOSTNAME/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.

Vaya al directorio de trabajo del repositorio.
```
cd YOUR-REPOSITORY
```
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.
Comprueba que has quitado todo lo que querías del historial del repositorio.
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 obtener más información, vea «Administrar repositorios remotos».
```
git remote add origin https://github.com/OWNER/REPOSITORY.git
```

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 tu instancia de GitHub Enterprise Server. 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://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

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://HOSTNAME/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 Enterprise Server, debes realizar algunos pasos adicionales para eliminar totalmente los datos de GitHub Enterprise Server.

Póngase en contacto con el administrador del sitio 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 Enterprise Server. Proporcione el nombre del repositorio o un vínculo a la confirmación que necesita eliminar. Para obtener más información sobre cómo los administradores del sitio pueden eliminar objetos de Git inaccesibles, consulte "Utilidades de la ea de comandos". Para obtener más información sobre cómo los administradores del sitio pueden identificar confirmaciones accesibles, consulte "Identificación de confirmaciones accesibles".
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.

Identificación de confirmaciones accesibles

Para eliminar completamente datos no deseados o confidenciales de un repositorio, la confirmación que introdujo primero los datos no debe tener ninguna referencia en ramas, etiquetas, solicitudes de cambios y bifurcaciones. Una sola referencia en cualquier lugar impedirá que la recolección de elementos no utilizados pueda purgar completamente los datos.

Puede comprobar si hay referencias existentes mediante los siguientes comandos cuando se conecta al dispositivo a través de SSH. Necesitará el SHA de la confirmación que introdujo originalmente los datos confidenciales.

ghe-repo OWNER/REPOSITORY -c 'git ref-contains COMMIT_SHA_NUMBER'
ghe-repo OWNER/REPOSITORY -c 'cd ../network.git && git ref-contains COMMIT_SHA_NUMBER'

Si alguno de esos comandos devuelve resultados, deberá eliminar esas referencias para que la confirmación se pueda recopilar correctamente. El segundo comando identificará las referencias que existen en bifurcaciones del repositorio (si el repositorio no tiene bifurcaciones, puede omitir su ejecución).

Los resultados que comienzan por refs/heads/ o refs/tags/ indican ramas y etiquetas, respectivamente, que todavía contienen referencias a la confirmación infractora, lo que sugiere que la confirmación no se ha eliminado por completo del repositorio modificado o que no se ha insertado a la fuerza.
Los resultados que comienzan por refs/pull/ o refs/__gh__/pull indican solicitudes de cambios que hacen referencia a la confirmación infractora. Estas solicitudes de cambios deben eliminarse para permitir que la recolección de elementos no utilizados recopile la confirmación. Una solicitud de cambios se puede eliminar en el panel de administración del sitio en https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY/PULL_REQUESTS/<PULL-REQUEST-NUMBER>; <PULL-REQUEST-NUMBER> se debe reemplazar por el número de solicitud de cambios.

Si las referencias se encuentran en cualquier bifurcación, los resultados tendrán un aspecto similar, pero comenzarán por refs/remotes/NWO/. Para identificar la bifurcación por nombre, puede ejecutar el siguiente comando.

ghe-nwo NWO

Los datos confidenciales se pueden quitar de las bifurcaciones de un repositorio; para ello, ve a un clon de uno, captura del repositorio limpiado y cambia de base todas las ramas y etiquetas que contienen los datos confidenciales sobre la rama o etiqueta pertinentes del repositorio limpiado. Como alternativa, las bifurcaciones se pueden eliminar por completo y, si es necesario, el repositorio se puede volver a bifurcar una vez completada la limpieza del repositorio raíz.

Una vez que haya eliminado las referencias de la confirmación, vuelva a ejecutar los comandos para comprobarlo.

Si no hay resultados de ninguno de los comandos ref-contains, puede ejecutar la recolección de elementos no utilizados con la marca --prune para eliminar las confirmaciones sin referencia ejecutando el comando siguiente.

ghe-repo-gc -v --prune OWNER/REPOSITORY

Una vez que la recolección de elementos no utilizados haya eliminado correctamente la confirmación, vaya al panel de administración del sitio del repositorio en https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY, seleccione Red y, a continuación, haga clic en Invalidar caché de Git para eliminar los datos almacenados en caché.

Evitar confirmaciones accidentales en el futuro

Impedir que los colaboradores realicen confirmaciones accidentales puede ayudarte a evitar que se exponga información confidencial. Para 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 obtener más información, vea «Acerca de la protección de inserción».