Preparar archivos, agregar un mensaje de confirmación, presionar. ¡No, espera! No ese archivo. Y ahora tenemos que empezar a buscar en Google.
Todos los desarrolladores han comprometido accidentalmente archivos confidenciales en el pasado. Entonces, ¿cómo arreglamos la situación y nos aseguramos de que no vuelva a suceder?
En este artículo, explicaré qué hacer cuando accidentalmente comprometes un archivo sensible e incluiré los comandos de Git necesarios para ajustar el historial.
Control de daños
De modo que accidentalmente cometió un archivo confidencial. Vamos llaman .env . Hay dos preguntas importantes que responder:
- ¿Envió la confirmación a un repositorio remoto?
- ¿Es público el repositorio remoto?
Aún no empujado
Si aún no presionó, la situación no es en absoluto crítica. Puede volver a una confirmación anterior :
git reset HEAD^ --soft Sus archivos permanecerán en la copia de trabajo para que pueda corregir el archivo / información confidencial. Si desea mantener la confirmación y simplemente eliminar el archivo sensible , haga:
git rm .env --cached git commit --amend Puede usar el --amendúnico en la última confirmación. Si logró agregar un montón de confirmaciones además de eso, use:
git rebase -i HEAD~{how many commits to go back?} Esto le permitirá corregir la confirmación defectuosa y reproducirá todas las confirmaciones restantes después de la corrección para que no las pierda.
Ya empujado
Si presionó, existe una diferencia importante entre los repositorios públicos y privados.
Si su repositorio es privado y no hay bots o personas en las que no confíe con acceso a él, puede modificar fácilmente la última confirmación usando los dos comandos anteriores.
Si colocó un montón de confirmaciones sobre la problemática, aún puede usar filter-branch o BFG repo cleaner para eliminar el archivo sensible del historial de git :
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all Pero tenga en cuenta dos aspectos importantes de estos cambios:
- En realidad estás cambiando la historia
Si hay otras personas, otras ramas, otras bifurcaciones o solicitudes de extracción abiertas que dependen del estado actual del repositorio, las romperá. En esos casos, trate el repositorio como si fuera público y evite cambiar el historial.
- Necesitas borrar la caché
Siempre debe ponerse en contacto con el soporte de su proveedor de almacenamiento de Git y pedirle que borre la caché de su repositorio. Aunque solucionó la confirmación problemática o reescribió el historial, la confirmación anterior con el archivo sensible permanece en la caché. Necesitará saber su ID para acceder a él, pero aún estará accesible hasta que borre la caché.
¿Necesito volver a generar claves si se envían a un repositorio público?
En resumen, sí. Si su repositorio es público o no cree que sea un lugar seguro por cualquier otro motivo, debe considerar que la información confidencial está comprometida.
Incluso si elimina los datos de su repositorio, no puede hacer nada acerca de los bots y otras bifurcaciones del repositorio. Así que cuales son los siguientes pasos?
- Desactivar todas las claves y / o contraseñas
Haz esto como primer paso. Una vez que desactiva las claves, la información confidencial se vuelve inútil.
- Ajustar gitignore
Agregue todos los archivos confidenciales a .gitignore para asegurarse de que git no los rastree.
- Eliminar el archivo sensible
- Confirme la corrección con una explicación significativa
No intente ocultar el error. Otros colaboradores y usted en un mes apreciarán la explicación de lo que sucedió y lo que corrige este compromiso.
Mejores prácticas al almacenar datos confidenciales en Git
Para evitar una situación como esta en el futuro, aquí hay algunos consejos sobre el almacenamiento de datos confidenciales:
Mantenga los datos confidenciales en un archivo .env (o un archivo similar en otras plataformas)
Mantenga las claves de API y otros datos confidenciales en un solo archivo .env. De esa manera, no confirmará accidentalmente una nueva clave cuando el archivo .env ya esté excluido de git.
Otro gran beneficio es que obtiene acceso a todas las claves mediante una variable de proceso global .
Utilice claves API si es posible
Las claves de API son fáciles de generar y desactivar si se ven comprometidas. Si es posible, utilícelos y evite el uso de credenciales / contraseñas.
Agregue claves API a su herramienta de compilación
Las claves de API generalmente se necesitan durante la compilación de aplicaciones. Las herramientas de compilación como Netlify le permiten agregar estas claves en las áreas seguras de su administración. Estas claves se inyectan automáticamente en su aplicación a través de la variable de proceso global .
Agregar archivo .env a gitignore
Asegúrese de que Git no rastrea archivos que contengan información confidencial.
Proporcione el archivo .env.template
El archivo de plantilla indica a otros colaboradores que agreguen las claves API necesarias sin que tengan que leer documentos extensos.
No cambie el historial en el control remoto
Utilice esto como regla general. Si siguió las reglas anteriores, no necesitará cambiar el historial.
Espero que esta información te haya ayudado a mantenerte seguro. ¿Tiene una experiencia personal sin comprometerse o quizás una buena lección aprendida ? Háblame en Twitter :-)