Secret terlanjur masuk Git? Rotasi kunci harus dilakukan sebelum menghapus riwayat

Jika token, kata sandi, atau kunci API terlanjur masuk Git, cabut atau rotasi kredensial itu sebelum menulis ulang riwayat. Panduan GitHub tentang data sensitif menjelaskan bahwa kredensial yang sudah dicabut tidak lagi dapat dipakai untuk akses; mengubah commit saja tidak memberi perlindungan tersebut.

Jika data tetap perlu dihapus dari repositori, gunakan git-filter-repo pada clone baru. Hapus seluruh berkas apabila semua revisinya harus hilang, atau ganti nilai sensitif apabila bagian lain dari berkas perlu dipertahankan. Periksa hasilnya sebelum force push, lalu tangani clone, fork, dan referensi yang masih menyimpan riwayat lama.

Cabut akses dan hentikan push sementara

Nonaktifkan kredensial melalui layanan yang menerbitkannya, buat pengganti, lalu perbarui aplikasi dan pekerjaan otomatis yang menggunakan nilai lama. Menghapus satu baris pada commit terbaru hanya mengubah berkas saat ini: nilai sebelumnya tetap ada pada commit lama dan mungkin telah disalin. Setelah kredensial dicabut, pertimbangkan apakah penulisan ulang masih diperlukan, terutama bila riwayat juga memuat data sensitif lain yang tidak bisa dirotasi.

Minta kolaborator berhenti mengirim perubahan sampai pembersihan repositori pusat selesai. Catat cabang, tag, pull request, dan fork yang mungkin merujuk commit terdampak; selamatkan pula pekerjaan lokal yang belum dikirim. Penulisan ulang mengubah identitas commit terdampak dan commit setelahnya. Jika seseorang terus mengembangkan cabang lama, pekerjaannya dapat tertimpa saat force push atau memaksa pembersihan diulang.

Pilih filter berdasarkan letak secret

Kerjakan penulisan ulang pada clone baru agar perubahan lokal yang belum dikirim tidak ikut terbuang. Manual git-filter-repo menerangkan bahwa --sensitive-data-removal mengumpulkan informasi untuk membersihkan salinan lain, sementara pilihan filter bergantung pada apakah rahasia memenuhi seluruh berkas atau hanya sebagian isinya.

• Untuk berkas yang seluruh revisinya harus dibuang, contoh bersyaratnya ialah git filter-repo --sensitive-data-removal --invert-paths --path config/credentials.env. Ganti jalur contoh dengan jalur relatif terhadap akar repositori. Tambahkan argumen --path untuk setiap nama atau lokasi lama, sebab filter jalur tidak otomatis mengikuti pergantian nama berkas.
• Untuk nilai rahasia di dalam berkas yang masih dibutuhkan, simpan nilai lama dalam berkas ekspresi di luar repositori, lalu jalankan git filter-repo --sensitive-data-removal --replace-text ../nilai-rahasia.txt. Setiap baris ekspresi secara bawaan dicocokkan sebagai teks literal dan diganti dengan penanda penghapusan. Batasi akses ke berkas ekspresi itu dan hapus setelah selesai karena isinya sendiri merupakan salinan secret.

Penggantian teks bekerja pada isi berkas nonbiner. Jika nilai juga muncul dalam pesan commit atau tag, periksa bagian tersebut secara terpisah; git-filter-repo menyediakan --replace-message untuk pesan. Pilihan filter harus mengikuti semua tempat data muncul, bukan hanya lokasi kebocoran yang pertama ditemukan.

Periksa hasil sebelum force push

Keberhasilan perintah filter belum membuktikan seluruh riwayat bersih. Untuk berkas yang dibuang, jalankan git log --all --name-status -- JALUR_BERKAS dan pastikan jalur terdampak tidak lagi muncul pada referensi yang diperiksa. Untuk nilai teks, pemeriksaan yang didokumentasikan adalah git log -S"NILAI_LAMA" --all -p --. Gunakan hanya nilai yang sudah dicabut dan jangan bagikan keluaran terminal yang mungkin masih menampilkannya.

Buka .git/filter-repo/changed-refs untuk melihat referensi yang berubah, termasuk referensi pull request bila ada. Cocokkan cakupannya dengan cabang dan tag yang telah dicatat, lalu periksa laporan tentang commit pertama yang berubah dan objek Git LFS yang menjadi yatim. Jika pencarian masih menemukan rahasia, perbaiki cakupan filter dan ulangi pemeriksaan pada clone tersebut sebelum mengubah repositori pusat.

Sebelum push, pastikan semua kolaborator masih menahan perubahan dan seluruh referensi yang relevan sudah masuk dalam penulisan ulang. Tinjau juga dampaknya pada pull request, tanda tangan commit atau tag, serta perlindungan cabang yang membatasi force push. Jika proses dijalankan tanpa mengambil semua referensi, mirror push berisiko menghapus referensi di server yang tidak ada pada clone lokal.

Perbarui repositori pusat dan referensi yang tersisa

Setelah hasil lokal bersih, periksa git remote -v. git-filter-repo dapat menghapus remote origin; tambahkan kembali alamat repositori yang benar bila perlu. Untuk mengganti referensi yang dapat didorong, prosedurnya menggunakan git push --force --mirror origin. Perintah ini menimpa riwayat bersama dan dapat membuang perubahan yang dikirim orang lain selama pembersihan.

Pada GitHub, push tidak dapat menimpa referensi refs/pull/ yang bersifat hanya baca. Commit lama juga dapat bertahan dalam tampilan cache, pull request, atau fork. Bila kasus data sensitif memenuhi syarat bantuan GitHub Support, siapkan nama repositori, jumlah pull request terdampak, identitas commit pertama yang berubah, serta laporan objek LFS yatim bila ada. Pemilik fork perlu membersihkan atau menghapus salinannya sendiri; perubahan pada repositori pusat tidak mengubah fork mereka.

Cegah clone lama mengembalikan riwayat tercemar

Setelah repositori pusat diperbarui, cara paling sederhana bagi kolaborator adalah menyimpan pekerjaan sah yang belum dikirim secara terpisah, membuang clone lama, lalu membuat clone baru. Jangan melakukan git pull di clone lama kemudian langsung git push: alur itu dapat membawa kembali commit yang memuat secret. Jangan pula menjalankan filter yang sama secara terpisah pada setiap clone, karena hasil penulisan ulang dapat menghasilkan identitas commit baru yang berbeda.

Jika sebuah clone lama harus dipertahankan, hapus tag lamanya terlebih dahulu, lalu jalankan git fetch --prune --tags. Rebase pekerjaan yang masih diperlukan ke riwayat baru; merge dari cabang lama dapat mengembalikan commit tercemar. Sesudah tidak ada referensi lama yang diperlukan, jalankan git reflog expire --expire=now --all dan git gc --prune=now. Langkah tersebut juga membuang riwayat pemulihan lokal, termasuk entri stash, sehingga pekerjaan yang diperlukan harus diamankan lebih dahulu.

Periksa setiap commit pertama yang berubah dengan git cat-file -t HASH_COMMIT_LAMA. Jika hasilnya commit, objek lama masih ada dan referensi, reflog, atau tag yang menahannya perlu ditangani. Kesalahan bahwa objek tidak ditemukan menunjukkan commit itu sudah hilang dari clone yang diperiksa. Untuk mencegah kebocoran berikutnya, masukkan berkas rahasia yang tidak boleh dilacak ke .gitignore dan simpan kredensial aktif dalam pengelola secret atau variabel lingkungan.

Baca juga:

• ASCII smuggling menembus filter email—normalisasi harus dilakukan lebih awal
• Menghapus Google My Activity tidak otomatis membersihkan semua riwayat
• Menghapus My Activity tidak menghapus riwayat browser—ini langkah lengkapnya