Masalah Rahasia yang Tersebar

Penyebaran rahasia adalah penyebaran kredensial sensitif yang tidak terkendali di seluruh organisasi. Rahasia adalah apa pun yang memberikan akses: kunci API, kata sandi basis data, token OAuth, kunci privat TLS, kunci SSH, dan kunci enkripsi.

Penyebaran terjadi ketika rahasia-rahasia ini tersebar di tempat yang seharusnya tidak pernah menyimpannya:

• Kode sumber dan berkas konfigurasi
• Alur CI/CD dan variabel lingkungan
• Citra kontainer dan infrastruktur sebagai kode
• Pesan obrolan, wiki, dan sistem tiket

Setelah sebuah rahasia ada di banyak tempat, Anda kehilangan kemampuan untuk melacak, mengganti, atau mencabutnya secara andal.

Akar masalah yang paling umum adalah secret yang ditulis langsung, yaitu kredensial yang dituliskan langsung ke dalam kode sumber. Hal ini terasa praktis selama pengembangan, tetapi kemudian menjadi beban permanen.

Berikut tampilan kata sandi basis data yang ditulis langsung dalam kode aplikasi:

Siapa pun yang memiliki akses baca ke berkas ini kini memiliki kata sandi produksi. Itu mencakup setiap pengembang, setiap pelaksana integrasi berkelanjutan, dan siapa pun yang nantinya menggandakan repositori tersebut.

Salah satu bahaya kritis dari secret yang ditulis langsung adalah riwayat kendali versi. Meskipun Anda menghapus secret dalam komit berikutnya, secret tersebut tetap tersimpan secara permanen dalam riwayat Git di setiap salinan repositori.

Anda dapat memulihkan secret yang bocor dari riwayat kapan saja:

Karena itu, menghapus secret dari komit terbaru tidak memperbaiki kebocoran. Secret tersebut harus dianggap telah disusupi dan segera dirotasi.

Ketika repositori yang berisi secret yang ditulis langsung didorong ke layanan publik seperti GitHub, bot otomatis akan memindainya dalam hitungan detik hingga menit.

Konsekuensi di dunia nyata meliputi:

• Ledakan tagihan komputasi awan kunci AWS yang bocor digunakan untuk menjalankan armada penambangan kripto, sehingga menghasilkan tagihan puluhan ribu dolar dalam semalam.
• Kebocoran data kredensial basis data yang terekspos menyebabkan seluruh data diekstraksi.
• Pergerakan lateral satu kredensial akses yang bocor digunakan untuk berpindah lebih jauh ke dalam infrastruktur.

Penyedia komputasi awan dan GitHub kini menjalankan pemindaian secret yang mendeteksi secara otomatis dan terkadang mencabut kunci yang bocor secara otomatis, tetapi Anda tidak dapat mengandalkannya sebagai jaring pengaman.

Kontainer memperkenalkan jalur penyebaran yang sulit terlihat. Secret yang ditanamkan ke dalam citra selama pembangunan disimpan dalam lapisan citra dan dikirim ke setiap registri serta host yang mengambil citra tersebut.

Kesalahan umum adalah menyalin berkas secret ke dalam citra, lalu menghapusnya pada lapisan berikutnya secret tersebut tetap ada pada lapisan sebelumnya:

Siapa pun yang mengambil citra itu dapat mengekstrak lapisan tersebut dan membaca kuncinya. Gunakan secret pembangunan atau penyisipan saat runtime sebagai gantinya.

Memindahkan secret keluar dari kode ke dalam variabel lingkungan merupakan langkah yang lebih baik, tetapi bukan solusi lengkap. Variabel lingkungan mengatasi penulisan langsung, tetapi memperkenalkan jalur paparan baru:

• Bocor dalam dump kerusakan dan jejak tumpukan kesalahan
• Dapat dilihat oleh proses lain melalui /proc/<pid>/environ di Linux
• Dicatat oleh alat penelusuran kesalahan yang mencetak seluruh lingkungan
• Disimpan dalam berkas .env teks biasa yang tidak sengaja dikomit

Variabel lingkungan dapat diterima untuk konfigurasi dengan sensitivitas rendah, tetapi secret bernilai tinggi harus disimpan dalam pengelola secret khusus dengan kontrol akses dan audit.

Penyebaran secret membuat respons insiden hampir mustahil dilakukan. Ketika sebuah secret ada di mana-mana, dua pertanyaan menjadi tidak dapat dijawab:

• Di mana secret itu? Anda tidak dapat merotasi sesuatu yang tidak dapat ditemukan.
• Siapa yang menggunakannya? Tanpa catatan akses terpusat, Anda tidak dapat menentukan cakupan pelanggaran.

Radius dampak dari satu kredensial yang bocor bertambah seiring penyebarannya. Satu kata sandi bersama yang digunakan ulang di sepuluh layanan berarti satu kebocoran membahayakan semuanya. Sentralisasi serta secret unik yang berumur pendek secara drastis memperkecil radius ini.

Tempat termurah untuk menghentikan kebocoran adalah sebelum secret masuk ke kendali versi. Pemindai secret pra-komit memeriksa perubahan yang telah disiapkan dan memblokir komit yang berisi pola kredensial.

Alat sumber terbuka yang populer mencakup gitleaks, trufflehog, dan detect-secrets. Pengait pra-komit biasanya berjalan secara lokal:

Padukan ini dengan pemindaian di sisi server dalam integrasi berkelanjutan agar pengembang yang melewati pengait lokal tetap terdeteksi.

Jika sebuah secret sampai ke tempat yang tidak semestinya, ikuti urutan ini. Rotasi harus didahulukan; pembersihan riwayat adalah langkah sekunder karena salinannya mungkin sudah ada di tempat lain.

• 1. Rotasi cabut secret yang bocor dan terbitkan secret baru segera.
• 2. Audit tinjau catatan akses untuk menemukan penggunaan yang tidak sah selama periode paparan.
• 3. Bersihkan hapus secret dari riwayat (misalnya git filter-repo) dan lakukan pengiriman paksa.
• 4. Cegah tambahkan pemindaian dan pindahkan secret ke dalam pengelola agar hal ini tidak terulang.

Jangan pernah melewati langkah 1. Secret yang pernah muncul di ruang publik telah disusupi, tanpa pengecualian.

Penyebaran secret semakin parah ketika secret diberi hak akses berlebihan dan dibagikan secara berlebihan. Menerapkan hak akses minimum membatasi kerusakan ketika kebocoran benar-benar terjadi:

• Berikan setiap layanan kredensialnya sendiri, jangan pernah menggunakan kredensial bersama.
• Batasi setiap secret pada izin minimum yang dibutuhkannya (hanya baca dibandingkan administrator).
• Utamakan kredensial berumur pendek yang kedaluwarsa secara otomatis.
• Pisahkan secret untuk setiap lingkungan; kunci pengembangan tidak boleh memberikan akses produksi.

Kebiasaan ini mengubah pelanggaran besar yang membawa bencana menjadi insiden yang terkendali dan dapat dipulihkan.

Alat saja tidak menyelesaikan penyebaran secret; budaya yang menyelesaikannya. Organisasi yang matang memperlakukan pengelolaan secret sebagai disiplin berkelanjutan:

• Sikap bawaan: tidak boleh ada secret dalam kode sumber.
• Pusatkan penyimpanan dalam brankas terkelola dengan kontrol akses dan catatan audit.
• Otomatiskan pemindaian di setiap tahap: pra-komit, integrasi berkelanjutan, dan registri.
• Jadikan rotasi sebagai rutinitas, bukan kejadian yang hanya dilakukan saat darurat.
• Latih setiap insinyur untuk mengenali dan melaporkan paparan tanpa saling menyalahkan.

Tujuannya adalah sistem yang membuat secret sulit bocor dan mudah dipulihkan ketika hal itu terjadi.

Uji pemahaman Anda tentang alasan menghapus secret yang bocor saja tidak cukup.

Anda telah mempelajari mengapa secret yang tersebar dan ditulis langsung menjadi salah satu kelemahan keamanan yang paling umum dan paling merusak.

• Penyebaran secret adalah penyebaran kredensial yang tidak terkendali di berbagai kode, alur kerja, citra, dan percakapan.
• Secret yang ditulis langsung tersimpan selamanya dalam riwayat Git; menghapusnya tidak memperbaiki kebocoran.
• Repositori publik dipindai dalam hitungan menit, yang dapat menyebabkan ledakan tagihan komputasi awan dan pelanggaran keamanan.
• Variabel lingkungan dan lapisan citra adalah wadah yang mudah membocorkan secret, bukan penyimpanan yang aman.
• Penyebaran secret memperbesar radius dampak dan membuat rotasi serta respons insiden mustahil dilakukan.
• Solusinya: lakukan pemindaian sebelum komit, utamakan rotasi saat terjadi kebocoran, pusatkan secret dalam brankas, dan terapkan hak akses minimum.

Selanjutnya, kita akan memusatkan secret dengan benar menggunakan brankas dan penyimpanan secret.