9.300 Kunci AWS yang Bocor Masih Aktif Bertahun-tahun

Sebuah kunci yang muncul di repositori publik belum tentu masih menjadi ancaman aktif. Risikonya menjadi serius ketika kunci itu belum dicabut, masih dapat digunakan untuk masuk, dan tetap memiliki izin yang berarti. Dalam investigasi ini, ketiga kondisi tersebut kerap ditemukan bersamaan.

768 kunci dapat memberi kendali penuh atas akun perusahaan

Dari kunci aktif yang dapat dikaitkan dengan akun perusahaan, 817 di antaranya terhubung dengan organisasi bisnis. Rinciannya meliputi:

• 526 kunci akun root AWS
• 242 kunci pengguna IAM yang terkait dengan kebijakan AdministratorAccess
• 768 kunci secara keseluruhan yang memberikan kendali administratif penuh atas akun AWS perusahaan

Kredensial root merupakan tingkat akses tertinggi bagi pelanggan AWS. Sementara itu, identitas IAM dengan kebijakan AdministratorAccess dapat menjalankan operasi dengan izin luas di berbagai layanan AWS.

Jika masih valid, kunci dengan tingkat hak akses tersebut dapat membuka jalan menuju pengambilalihan akun, akses data tanpa izin, pembuatan infrastruktur, hingga penyalahgunaan tagihan cloud.

Temuan ini menunjukkan bahwa masalahnya bukan sekadar kebersihan source code, melainkan juga pengelolaan izin dan siklus hidup kredensial. Menghapus kunci dari file yang terlihat publik tidak cukup untuk melindungi akun jika kredensial itu sudah disalin. Kunci harus dicabut atau dirotasi.

Hugging Face menjadi sumber terbesar

Hugging Face tercatat sebagai sumber individual terbesar, dengan 8.482 eksposur kredensial AWS. Truffle Security melaporkan bahwa 17,9% kredensial AWS tersebut merupakan kredensial root.

Temuan ini sejalan dengan pemindaian Truffle Security yang lebih luas terhadap data publik di Hugging Face. Perusahaan tersebut mengatakan telah memeriksa 7,6 petabita dataset publik dan menemukan kredensial aktif di ribuan dataset. Hal ini menunjukkan bahwa rahasia digital dapat bertahan di luar repositori perangkat lunak konvensional dan ikut tersebar melalui data yang dipublikasikan.

Bagi tim keamanan, pesannya jelas: pemindaian repositori kode yang sedang digunakan saja tidak cukup. Riwayat Git, artefak build, image container, registry, dataset publik, serta keluaran CI dapat tetap menyimpan kredensial meski pengembang merasa sudah menghapusnya.

Banyak kunci berusia bertahun-tahun dan jarang dirotasi

Usia median kredensial yang dilaporkan mencapai sekitar 1.831 hari, atau kira-kira lima tahun. Kunci tertua berusia 17,4 tahun. Hanya 13,7% entri yang memiliki kunci baru terkait, yang mengindikasikan bahwa sebagian besar tidak pernah diganti melalui proses rotasi normal.

Kunci akses yang berumur panjang memperbesar waktu yang tersedia untuk penyalahgunaan dan menyulitkan organisasi melacak siapa pemiliknya. Kredensial semacam ini juga dapat tetap aktif setelah pergantian pegawai, migrasi aplikasi, pembersihan repositori, atau perubahan tanggung jawab operasional.

Karena itu, usia kredensial perlu diperlakukan sebagai sinyal risiko. Kunci yang terekspos dan telah berusia beberapa tahun tidak boleh langsung dianggap sudah kedaluwarsa. Organisasi perlu memverifikasi statusnya, mencabutnya, dan menyelidiki kemungkinan penyalahgunaan—kecuali pemiliknya dapat membuktikan bahwa kunci tersebut memang sudah tidak valid.

Hanya sedikit akun yang memiliki pemantauan anggaran

Truffle Security dapat membaca informasi akun untuk 2.754 akun, tetapi hanya 262 yang mengaktifkan peringatan anggaran AWS.

Peringatan anggaran tidak menggantikan pencabutan kredensial atau deteksi ancaman. Namun, fitur ini dapat menjadi alarm awal ketika kredensial yang bocor digunakan untuk membuat sumber daya mahal, misalnya untuk penambangan mata uang kripto atau bentuk penyalahgunaan cloud lainnya.

Tanpa notifikasi yang sampai kepada orang yang dapat segera bertindak, lonjakan biaya bisa terus berlangsung setelah akun berhasil disusupi.

Apa yang dapat dan tidak dapat diselesaikan oleh notifikasi AWS?

Laporan tersebut menjelaskan bahwa perlindungan AWS untuk kunci yang terungkap dapat mendeteksi kredensial yang bocor, memberi tahu pelanggan yang terdampak, dan menerapkan pembatasan atau langkah karantina. Namun, banyaknya kunci yang masih valid saat diuji menunjukkan bahwa deteksi atau notifikasi tidak selalu diikuti pencabutan dan rotasi oleh pelanggan secara cepat.

Deteksi hanyalah langkah pertama dalam menangani kebocoran kredensial. Respons yang lengkap perlu:

1. Mengidentifikasi pemilik kredensial.
2. Menentukan layanan dan sumber daya yang dapat diakses.
3. Memeriksa kemungkinan penyalahgunaan.
4. Menonaktifkan atau mengganti kunci.

Truffle Security menyatakan bahwa validasinya bersifat read-only. Artinya, peneliti memeriksa apakah kredensial dapat digunakan untuk autentikasi serta menilai metadata akun atau izin, bukan mengubah sumber daya pelanggan. Detail operasional metodologi tersebut merupakan penjelasan dari Truffle Security dan tidak seluruhnya dapat diverifikasi secara independen dari sumber yang tersedia.

Langkah yang perlu dilakukan setelah kunci AWS bocor

1. Cabut atau rotasi kunci segera

Hapus atau nonaktifkan kredensial yang terekspos, lalu buat pengganti hanya jika akses tersebut masih diperlukan. Menghapus rahasia dari repositori, menghilangkan file, atau menulis ulang riwayat Git tidak membatalkan salinan yang mungkin sudah dimiliki pihak lain.

2. Hapus kunci akses root

Kunci akses pengguna root AWS tidak seharusnya digunakan untuk akses programatik sehari-hari. Hapus kunci root dan pindahkan beban kerja ke identitas terkontrol dengan izin yang dibatasi secara ketat.

3. Periksa izin dan kepemilikan

Tentukan akun, pengguna, layanan, dan sumber daya yang terkait dengan kredensial tersebut. Prioritaskan kunci dengan hak root, AdministratorAccess, akses data luas, atau kewenangan untuk membuat infrastruktur.

4. Selidiki aktivitas sebelum dan sesudah pencabutan

Tinjau aktivitas autentikasi, catatan CloudTrail, perubahan IAM, sumber daya baru, serta tagihan untuk mencari perilaku mencurigakan. Pencabutan menghentikan penggunaan kunci yang terekspos berikutnya, tetapi tidak membuktikan apakah kunci itu sudah disalahgunakan sebelumnya.

5. Ganti kunci permanen dengan identitas berumur pendek

Jika memungkinkan, gunakan IAM role berumur pendek dan workload identity, bukan kunci akses permanen. Prinsip least privilege atau hak akses minimum juga membatasi dampak jika kredensial kembali bocor.

6. Aktifkan peringatan anggaran dan jalur respons

Atur peringatan AWS Budgets dan pemantauan anomali biaya. Pastikan notifikasi diteruskan kepada kontak yang memiliki kewenangan untuk bertindak cepat. Pemantauan finansial adalah lapisan pengaman tambahan, bukan pengganti pemindaian rahasia, rotasi kredensial, dan peninjauan akses.

Pelajaran keamanan yang lebih luas

Temuan terpenting dari investigasi ini bukan hanya jumlah rahasia yang ditemukan, melainkan gabungan antara eksposur publik, status yang masih aktif, hak akses tinggi, usia ekstrem, dan pemantauan yang lemah.

Penyimpanan data publik dapat mempertahankan kredensial jauh setelah organisasi lupa di mana kredensial itu pernah digunakan. Sementara itu, kunci yang sudah disalin dapat tetap berguna sampai pemiliknya benar-benar mencabutnya.

Bagi tim cloud, asumsi operasional yang paling aman adalah sederhana: perlakukan setiap kredensial AWS yang terekspos sebagai kredensial yang telah disusupi, periksa jangkauan aksesnya, cabut atau rotasi segera, lalu gantikan kunci berumur panjang dengan identitas berumur pendek dan izin minimum.