Eliminación de datos confidenciales de un repositorio

Si confirma datos confidenciales en un repositorio de Git, puede eliminarlos del historial.

En este artículo

Acerca de eliminar datos confidenciales de un repositorio

Al modificar el historial del repositorio mediante herramientas como git filter-repo o BFG Repo-Cleaner, es fundamental comprender las implicaciones, especialmente con respecto a las solicitudes de cambios abiertas y a los datos confidenciales.

La herramienta git filter-repo y BFG Repo-Cleaner reescriben el historial del repositorio, lo que cambia los SHA para las confirmaciones existentes que se modifican y las confirmaciones dependientes. Los SHA de confirmación modificados pueden afectar a las solicitudes de incorporación de cambios abiertas en el repositorio. Se recomienda combinar o cerrar todas las solicitudes de incorporación de cambios abiertas antes de quitar archivos del repositorio.

Puede quitar el archivo de la confirmación más reciente con git rm. Para información sobre cómo quitar un archivo que se agregó con la confirmación más reciente, consulte «Acerca de los archivos grandes en GitHub».

Acerca de la exposición de datos confidenciales

En este artículo, se indica cómo realizar confirmaciones con datos confidenciales inaccesibles desde cualquier rama o etiqueta del repositorio en tu instancia de GitHub Enterprise Server. Sin embargo, esas confirmaciones pueden seguir 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.

Una vez que hayas insertado una confirmación en GitHub Enterprise Server, debes considerar cualquier dato confidencial en la confirmación comprometida. Si has confirmado una contraseña, debes cambiarla. Si has confirmado una clave, genera una nueva.

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.

Purgar un archivo del historial de tu repositorio

Puede purgar un archivo del historial del repositorio mediante la herramienta git filter-repo o la herramienta de código abierto BFG Repo-Cleaner.

Note

Si los datos confidenciales se encuentran en un archivo identificado como un archivo binario, deberás quitar el archivo del historial, ya que no puedes modificarlo para quitar o reemplazar los datos.

Usar el BFG

BFG Repo-Cleaner es una herramienta creada y mantenida por la comunidad de código abierto. Proporciona una alternativa más rápida y sencilla a git filter-repo para la eliminación de datos no deseados.

Por ejemplo, para eliminar tu archivo con datos confidenciales y dejar intacta tu última confirmación, ejecuta lo siguiente:

bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA

Para reemplazar todo el texto que aparece en passwords.txt dondequiera que se pueda encontrar en el historial del repositorio, ejecute lo siguiente:

bfg --replace-text passwords.txt

Después de que se eliminan los datos sensibles, debe subir forzadamente sus cambios a GitHub Enterprise Server. El forzar las subidas reescribirá el historial de los repositorios, lo cual eliminará los datos sensibles del historial de confirmaciones. Si hace subidas forzadas, esto podría sobreescribir las confirmaciones en las cuales otros hayan basado su trabajo.

git push --force

Vea la documentación de BFG Repo-Cleaner para obtener instrucciones completas de uso y descarga.

Utilizar 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.

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

  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. Agregue el archivo con datos confidenciales a .gitignore para asegurarse de que no vuelva a confirmarlo por accidente.

    $ echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore
$ git add .gitignore
$ git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore"
> [main 051452f] Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore
>  1 files changed, 1 insertions(+), 0 deletions(-)

  6. Vuelva a comprobar que ha quitado todo lo que quería del historial del repositorio y que todas las ramas están extraídas del repositorio.

  7. 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

  8. 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, así como todas las ramas que insertaste. 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)

  9. 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 la herramienta de BFG o git filter-repo para quitar los datos confidenciales e insertar los cambios en GitHub Enterprise Server, debe realizar algunos pasos adicionales para eliminar totalmente los datos de GitHub Enterprise Server.

  1. 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".

  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.

  3. Si utilizó git filter-repo, puede omitir este paso.

    Si utilizó la herramienta BFG, después de reescribir, puede limpiar las referencias en su repositorio local al historial antiguo para que sean desreferenciadas y recolectadas de la basura con los siguientes comandos (usando Git 1.8.5 o más reciente):

    $ git reflog expire --expire=now --all
$ git gc --prune=now
> Counting objects: 2437, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (1378/1378), done.
> Writing objects: 100% (2437/2437), done.
> Total 2437 (delta 1461), reused 1802 (delta 1048)

    Note

    También puede lograr esto si confirma el historial filtrado en un repositorio nuevo o vacío, y después crea un clon de GitHub Enterprise Server.

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

El mismo procedimiento que usa la herramienta BFG o git filter-repo se puede usar para eliminar los datos confidenciales de las bifurcaciones del repositorio. 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, consulte «Procedimientos recomendados para evitar la pérdida de datos en la organización».

Existen algunos trucos sencillos para evitar confirmar cosas que no quieres confirmar:

  • 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».

Información adicional