# Langkah menangani API key atau token yang bocor

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Cabut API key yang terbuka, atur penggantian pada layanan terkait, periksa penggunaannya, dan pastikan kredensial lama tidak lagi berlaku.

URL kanonis: https://kompli.id/panduan/keamanan/api-key-bocor/
Sumber diakses: 2026-09-29
Diperbarui: 2026-09-30
Penulis: Kompli
Sumber diperiksa: 2026-09-30


## Anggap kredensial yang terbuka perlu segera ditangani

API key, token, atau kata sandi layanan dapat terbuka melalui repositori, log, percakapan, atau berkas yang dibagikan. Menghapus pesan atau membuat repositori privat belum membatalkan kredensial yang sudah tersalin.

Laporkan kepada pemilik layanan dengan menyebut lokasi paparan dan pengenal kredensial yang aman, bukan menyalin nilainya. Jangan mencoba kunci yang ditemukan pada sistem milik pihak lain. Panduan ini untuk petugas yang berwenang menangani akses organisasinya.

## Cabut dan ganti dengan koordinasi yang jelas

Cabut kredensial terpapar secepatnya melalui layanan penerbit, lalu gunakan pengganti yang disimpan secara aman. Koordinasikan pembaruan aplikasi yang bergantung padanya. Catat waktu pencabutan dan periksa apakah kredensial lama benar-benar tidak berlaku.

Pembersihan repositori atau log dilakukan dengan menjaga bukti yang diperlukan. Perubahan riwayat repositori perlu dikoordinasikan karena dapat memengaruhi salinan dan referensi tim. Jangan menunda pencabutan sampai seluruh salinan berhasil dibersihkan.

## Petakan dampak perubahan pada layanan

Contoh pertanyaan operasional berikut membantu pemilik sistem mengatur pekerjaan. Jawab dengan pengenal internal; jangan masukkan nilai secret ke tiket.

| Pertanyaan | Keputusan yang perlu dicatat |
| --- | --- |
| Kunci ini memberi akses ke apa? | Layanan, lingkungan, hak akses, dan data yang dapat dijangkau. |
| Siapa yang masih memakainya? | Aplikasi, pekerjaan terjadwal, integrasi, serta petugas pengganti konfigurasi. |
| Apakah layanan bisa dibatasi sementara? | Fungsi yang dihentikan, dampak pengguna, dan pihak yang menyetujui. |
| Bagaimana memastikan pengganti bekerja? | Uji transaksi atau proses yang aman, hasil, dan penanggung jawab. |
| Apakah jalur pemulihan memakai kunci lama? | Konfigurasi cadangan atau rilis lama yang harus diperbarui sebelum digunakan. |

Gunakan [lembar rotasi kredensial](/template/rotasi-kredensial-insiden/) untuk melacak setiap dependensi. Jangan mengaktifkan kembali kunci bocor hanya karena penggantinya membuat suatu pekerjaan gagal; perbaiki konfigurasi atau gunakan akses baru yang disetujui.

## Periksa penggunaan dan akses lanjutan

Tetapkan rentang waktu pemeriksaan dari bukti yang tersedia. Bedakan waktu pertama terpapar, pertama ditemukan, dan dicabut. Periksa aktivitas kredensial serta perubahan yang dapat ditimbulkannya, termasuk akses tambahan atau data yang diambil. Jaga bukti dengan akses terbatas.

Tidak adanya kejadian pada log belum membuktikan kunci tidak pernah dipakai. Catat jika periode log tidak lengkap atau jenis aktivitas tertentu tidak tercatat. Bila akses memungkinkan pengambilan data, lanjutkan [pemeriksaan ekspor mencurigakan](/panduan/keamanan/ekspor-data-mencurigakan/) dan nilai dampak data pribadi.

## Selesaikan dengan bukti hasil penggantian

Contoh fiktif: token sinkronisasi pesanan masuk ke repositori publik. Tim mencabutnya, mengganti konfigurasi aplikasi, dan berhasil menguji pesanan baru. Namun, tugas malam masih memakai token lama. Baris tugas malam tetap terbuka pada lembar rotasi sampai konfigurasinya diperbaiki dan hasilnya diuji.

Penutupan mencakup pencabutan akses lama, hasil uji layanan, pemeriksaan cakupan, serta perbaikan sumber paparan. Untuk pencegahan berikutnya, gunakan [panduan pengelolaan kunci dan data uji](/panduan/keamanan/enkripsi-kunci-dan-data-uji/). Penilaian [insiden data pribadi](/panduan/keamanan/penanganan-insiden-data-pribadi/) berjalan paralel jika relevan; rotasi bukan bukti bahwa tidak ada data yang terdampak.

## Panduan penerapan terkait

Setelah penanganan selesai, gunakan [panduan akun layanan dan identitas workload](/panduan/keamanan/akun-layanan-dan-identitas-workload/) untuk memperbaiki kepemilikan, izin, masa berlaku, serta penghentian kredensial rutin.
## Sumber rujukan

- [NIST SP 800-61 Rev. 3 — Incident Response Recommendations](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf) — RS.AN-03/06/07/08: analisis dan bukti; RS.MI: pembatasan dan penanganan penyebab; RC.RP: pemeriksaan pemulihan. Rujukan teknis, bukan aturan Indonesia.
- [OWASP — Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) — Bagian 9: pencabutan, rotasi, pembersihan dan audit setelah paparan secret.

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Enkripsi, kunci, secret, dan data uji: pembagian tanggung jawab](https://kompli.id/panduan/keamanan/enkripsi-kunci-dan-data-uji/)
- [Lembar rotasi kredensial setelah insiden](https://kompli.id/template/rotasi-kredensial-insiden/)
- [Template catatan dan contoh laporan insiden keamanan](https://kompli.id/template/catatan-insiden-keamanan/)