Menurut penelitian dari GitGuardian dan CyberArk, 79% pengambil keputusan TI melaporkan pernah mengalami kebocoran rahasia, naik dari 75% pada laporan tahun sebelumnya. Pada saat yang sama, jumlah kredensial yang bocor sangat tinggi, dengan lebih dari 12,7 juta kredensial yang dikodekan dalam repositori GitHub publik saja. Salah satu aspek yang lebih meresahkan dari laporan ini adalah lebih dari 90% rahasia valid yang ditemukan dan dilaporkan tetap valid selama lebih dari 5 hari.
Menurut penelitian yang sama, rata-rata organisasi memerlukan waktu 27 hari untuk memulihkan kredensial yang bocor. Ditambah dengan fakta bahwa jumlah identitas non-manusia setidaknya 45:1 melebihi identitas manusia, maka mudah untuk melihat mengapa banyak organisasi menyadari bahwa menghentikan penyebaran rahasia berarti menemukan cara untuk menangani krisis identitas mesin ini. Sayangnya, penelitian juga menunjukkan banyak tim yang bingung siapa pemilik keamanan identitas tersebut. Ini adalah badai risiko yang sempurna.
Mengapa Rotasi Membutuhkan Waktu Lama
Jadi, mengapa kita membutuhkan waktu lama untuk merotasi kredensial padahal kita tahu bahwa kredensial adalah salah satu jalur serangan termudah bagi musuh? Salah satu faktor utama yang berkontribusi adalah kurangnya kejelasan tentang bagaimana kredensial kami diizinkan. Izin adalah hal yang memberi otorisasi pada hal tertentu yang berhasil diminta oleh suatu entitas, seperti beban kerja Kubernetes atau layanan mikro, dari layanan atau sumber data lain.
Mari kita ingat apa arti dari remediasi insiden penyebaran rahasia: Anda perlu mengganti rahasia dengan aman tanpa merusak apa pun atau memberikan izin baru yang terlalu luas, yang berpotensi menimbulkan lebih banyak risiko keamanan pada perusahaan Anda. Jika Anda sudah memiliki wawasan penuh tentang siklus hidup identitas non-manusia dan rahasia terkaitnya, ini adalah proses yang cukup mudah untuk menggantinya dengan rahasia baru dengan izin yang sama. Ini bisa memakan banyak waktu jika Anda belum memiliki wawasan tersebut, karena Anda perlu berharap pengembang yang pertama kali membuatnya masih ada dan telah mendokumentasikan apa yang telah dilakukan.
Mari kita lihat mengapa manajemen perizinan sangat menantang di lingkungan yang didominasi oleh NHI, periksa tantangan yang dihadapi pengembang dan tim keamanan dalam menyeimbangkan kontrol akses dan produktivitas, dan diskusikan bagaimana model tanggung jawab bersama dapat membantu.
Siapa Sebenarnya Pemilik Secret Sprawl?
Penyebaran rahasia umumnya mengacu pada proliferasi kunci akses, kata sandi, dan kredensial sensitif lainnya di lingkungan pengembangan, repositori, dan layanan seperti Slack atau Jira. Laporan Voice of the Practitioners terbaru dari GitGuardian menyoroti bahwa 65% responden menempatkan tanggung jawab remediasi sepenuhnya pada tim keamanan TI. Pada saat yang sama, 44% pemimpin TI melaporkan bahwa pengembang tidak mengikuti praktik terbaik dalam pengelolaan rahasia.
Penyebaran rahasia dan masalah mendasar dari izin yang berumur panjang yang berlebihan akan terus terjadi dalam kesenjangan ini sampai kita menemukan cara untuk bekerja sama dengan lebih baik dalam model tanggung jawab bersama.
Perspektif Pengembang Tentang Izin
Pengembang menghadapi tekanan besar untuk membangun dan menerapkan fitur dengan cepat. Namun, mengelola izin secara hati-hati, dengan praktik keamanan terbaik, dapat memakan banyak tenaga. Setiap proyek atau aplikasi sering kali memiliki persyaratan akses uniknya sendiri, yang memerlukan waktu untuk diteliti dan ditetapkan dengan benar, hampir terasa seperti pekerjaan penuh waktu selain pekerjaan membuat dan menerapkan aplikasinya. Praktik terbaik untuk membuat dan mengelola izin sering kali tidak diterapkan secara merata di seluruh tim, jarang didokumentasikan dengan tepat, atau dilupakan sama sekali setelah pengembang membuat aplikasi berfungsi.
Yang memperparah masalah ini adalah, dalam banyak kasus, pengembang hanya memberikan izin yang terlalu luas kepada identitas mesin ini. Satu laporan menemukan bahwa hanya 2% dari izin yang diberikan yang benar-benar digunakan. Jika kita melihat lebih dekat apa yang mereka hadapi, mudah untuk mengetahui alasannya.
Misalnya, pikirkan tentang mengelola izin dalam Amazon Web Services. Kebijakan Manajemen Identitas dan Akses (IAM) AWS dikenal karena fleksibilitasnya namun juga rumit dan membingungkan untuk dinavigasi. IAM mendukung berbagai jenis kebijakan—berbasis identitas, berbasis sumber daya, dan batasan izin—yang semuanya memerlukan konfigurasi yang tepat. AWS juga menawarkan beberapa jalur akses untuk kredensial, termasuk peran IAM dan pemberian KMS (Layanan Manajemen Kunci), yang masing-masing dilengkapi dengan konfigurasi akses uniknya sendiri. Mempelajari sistem ini bukanlah hal yang mudah.
Contoh umum lainnya dari layanan yang izinnya sulit dikelola adalah GitHub. Kunci API dapat memberikan izin ke repositori di berbagai organisasi, sehingga sulit untuk memastikan batasan akses yang sesuai. Sebuah kunci dapat secara tidak sengaja memberikan akses berlebihan di seluruh lingkungan ketika pengembang merupakan anggota dari beberapa organisasi. Tekanan terus berlanjut untuk melakukan hal yang benar, sementara waktu terus berjalan dan tumpukan simpanan semakin besar.
Mengapa Tim Keamanan Sendiri Tidak Dapat Memperbaiki Ini
Tampaknya logis untuk memberikan tanggung jawab kepada tim keamanan untuk memantau dan merotasi rahasia; lagipula, ini adalah masalah keamanan. Kenyataannya adalah tim-tim ini sering kali tidak memiliki pengetahuan terperinci di tingkat proyek yang diperlukan untuk melakukan perubahan dengan aman. Tim keamanan tidak selalu memiliki konteks untuk memahami izin spesifik apa yang penting untuk menjaga aplikasi tetap berjalan. Misalnya, perubahan izin yang tampaknya kecil dapat merusak saluran CI/CD, mengganggu produksi, atau bahkan menyebabkan kegagalan berjenjang di seluruh perusahaan jika layanan yang salah hilang.
Sifat manajemen rahasia yang tersebar di seluruh tim dan lingkungan juga meningkatkan permukaan serangan. Karena tidak ada orang yang benar-benar bertanggung jawab, menjaga konsistensi dalam kontrol akses dan jalur audit menjadi jauh lebih sulit. Fragmentasi ini sering mengakibatkan kredensial yang berlebihan atau ketinggalan jaman dan izin terkait tetap aktif terlalu lama, mungkin selamanya. Hal ini dapat menyulitkan untuk mengetahui siapa yang memiliki akses sah atau tidak sah terhadap rahasia tertentu pada waktu tertentu.
Model Tanggung Jawab Bersama Untuk Rotasi Lebih Cepat
Pengembang dan tim keamanan dapat membantu mengatasi masalah ini dengan bertemu di tengah-tengah dan membangun model tanggung jawab bersama. Dalam model seperti itu, pengembang lebih bertanggung jawab untuk mengelola izin mereka secara konsisten melalui alat yang tepat, seperti Conjur Secrets Manager CyberArk atau Vault oleh HashiCorp, sekaligus mendokumentasikan izin dan cakupan izin yang diperlukan dengan lebih baik di tingkat proyek. Tim keamanan harus membantu pengembang dengan mengotomatiskan rotasi rahasia, berinvestasi pada alat observasi yang tepat untuk mendapatkan kejelasan tentang keadaan rahasia, dan bekerja sama dengan TI untuk menghilangkan kredensial yang berumur panjang.
Jika pengembang dengan jelas mendokumentasikan izin mana yang diperlukan dalam persyaratan mereka, hal ini dapat membantu tim keamanan melakukan audit dan remediasi yang lebih cepat dan tepat. Jika tim keamanan bekerja untuk memastikan bahwa jalur keseluruhan yang termudah dan tercepat menuju penerapan rahasia identitas non-manusia yang baru juga merupakan jalur yang paling aman dan terukur, maka akan ada jauh lebih sedikit insiden yang memerlukan rotasi darurat, dan semua pihak menang.
Sasaran pengembang adalah memastikan bahwa tim keamanan dapat merotasi atau memperbarui kredensial dalam aplikasi mereka dengan percaya diri, dan mengetahui bahwa mereka tidak membahayakan produksi.
Pertanyaan Kunci untuk Dijawab seputar Perizinan
Saat memikirkan apa yang perlu didokumentasikan, berikut beberapa poin data spesifik untuk membantu upaya lintas tim ini berjalan lebih lancar:
- Siapa yang Membuat Kredensial? – Banyak organisasi merasa kesulitan melacak kepemilikan kredensial, terutama ketika kunci dibagikan atau dirotasi. Pengetahuan ini penting untuk memahami siapa yang bertanggung jawab untuk merotasi atau mencabut kredensial.
- Sumber Daya Apa yang Diakses? – Kunci API sering kali dapat mengakses berbagai layanan, mulai dari database hingga integrasi pihak ketiga, sehingga penting untuk membatasi izin hingga jumlah minimum yang diperlukan.
- Izin Apa yang Diberikannya? – Izin sangat bervariasi tergantung pada peran, kebijakan berbasis sumber daya, dan kondisi kebijakan. Misalnya, di Jenkins, pengguna dengan izin `Keseluruhan/Baca` dapat melihat informasi umum, sementara `Keseluruhan/Administer` memberikan kontrol penuh atas sistem.
- Bagaimana Kami Mencabut atau Memutarnya? – Kemudahan pencabutan bervariasi berdasarkan platform, dan dalam banyak kasus, tim harus melacak kunci dan izin di seluruh sistem secara manual, sehingga mempersulit remediasi dan memperpanjang paparan terhadap ancaman.
- Apakah Kredensialnya Aktif? – Mengetahui apakah kredensial masih digunakan sangatlah penting. Ketika NHI menggunakan kunci API yang berumur panjang, kredensial ini mungkin tetap aktif tanpa batas waktu kecuali dikelola dengan benar, sehingga menimbulkan risiko akses yang terus-menerus.
Izin Memang Menantang, Tapi Kita Bisa Mengelolanya Bersama Sebagai Satu Tim
Menurut laporan GitGuardian, meskipun 75% responden menyatakan keyakinannya terhadap kemampuan pengelolaan rahasia mereka, kenyataannya seringkali jauh berbeda. Waktu remediasi rata-rata adalah 27 hari mencerminkan kesenjangan antara kepercayaan diri dan praktik. Sekarang saatnya memikirkan kembali cara kita menerapkan dan mengomunikasikan rahasia dan izinnya sebagai sebuah organisasi.
Meskipun pengembang berupaya keras untuk menyeimbangkan keamanan dan fungsionalitas, kurangnya proses perizinan yang disederhanakan dan jalur dokumentasi yang tidak terpusat atau tidak standar hanya akan memperbesar risiko. Tim keamanan saja tidak dapat menyelesaikan masalah ini secara efektif karena terbatasnya wawasan mereka mengenai kebutuhan spesifik proyek. Mereka perlu bekerja sama dengan pengembang di setiap langkahnya.
GitGuardian sedang membangun alat keamanan rahasia generasi berikutnya, membantu tim keamanan dan TI menangani penyebaran rahasia. Mengetahui teks biasa apa, kredensial berumur panjang yang diekspos dalam kode Anda dan lingkungan lainnya adalah langkah pertama yang diperlukan untuk menghilangkan ancaman ini. Mulailah hari ini dengan GitGuardian.
