Sebuah perusahaan telah memindahkan password database, API key, token layanan, dan kredensial cloud ke dalam vault. Secret tidak lagi disimpan dalam source code atau file konfigurasi biasa. Setiap pengambilan juga telah tercatat dalam audit log.

Dari luar, praktik tersebut terlihat aman.

Namun, aplikasi masih menggunakan kredensial yang sama selama berbulan-bulan, bahkan bertahun-tahun. Ketika kredensial itu berhasil disalin dari memori aplikasi, log, container, pipeline, atau perangkat developer, vault tidak dapat membuat salinan tersebut berhenti bekerja.

Kondisi ini memperlihatkan satu persoalan penting dalam keamanan kredensial aplikasi. Memindahkan secret ke tempat penyimpanan yang lebih aman tidak sama dengan menghilangkan risiko dari kredensial itu sendiri.

Vault Menutup Satu Celah, Bukan Seluruh Risiko

Penggunaan vault atau secret manager tetap merupakan langkah yang tepat. Teknologi ini membantu perusahaan memusatkan penyimpanan secret, menerapkan enkripsi, membatasi akses, dan mencatat aktivitas pengambilan kredensial.

Vault juga mengurangi kebiasaan menyimpan password, API key, atau token secara langsung di dalam source code. Developer tidak perlu menuliskan informasi sensitif pada repository atau membagikannya melalui pesan internal.

Masalah muncul ketika implementasi secrets management berhenti pada pemindahan lokasi penyimpanan.

Secret yang sebelumnya tersimpan di file konfigurasi kemudian dipindahkan ke vault, tetapi masa berlakunya tidak berubah. Hak aksesnya tetap luas. Kredensial masih digunakan bersama oleh beberapa aplikasi dan proses rotasinya tetap bergantung pada pekerjaan manual.

Dalam kondisi tersebut, perusahaan memang telah memperbaiki keamanan penyimpanan. Namun, risiko penyalahgunaan setelah secret diperoleh masih tetap besar.

Keamanan kredensial tidak hanya ditentukan oleh tempat penyimpanannya. Masa berlaku, cakupan izin, mekanisme distribusi, kepemilikan, rotasi, dan kemampuan pencabutan juga menentukan seberapa besar dampak sebuah kebocoran.

Secret Akan Keluar dari Vault agar Dapat Digunakan

Vault melindungi secret ketika disimpan. Sementara itu, aplikasi tetap harus mengambil dan menggunakan secret tersebut agar dapat terhubung ke database, cloud, API, atau layanan lainnya.

Ketika proses itu terjadi, secret dapat hadir sementara di berbagai tempat, seperti:

• memory aplikasi;
• environment variable;
• container;
• CI/CD runner;
• proses deployment;
• diagnostic dump;
• command history;
• sistem logging;
• perangkat developer;
• tool observability.

Tidak semua salinan tersebut berada di bawah kendali langsung vault. Kesalahan konfigurasi logging, proses debugging, atau akses berlebihan pada environment dapat membuat kredensial terekspos setelah dikeluarkan dari penyimpanan pusat.

Studi akademik pada 2026 yang menganalisis sekitar 10 juta halaman web menemukan 1.748 kredensial API yang valid pada hampir 10.000 halaman. Penelitian tersebut juga menemukan bahwa sebagian kredensial tetap terekspos selama beberapa bulan hingga bertahun-tahun.

Temuan tersebut menunjukkan bahwa masalah secret tidak selalu berhenti pada source code. Kredensial dapat ikut terbawa dalam proses bundling, deployment, resource pihak ketiga, dan komponen aplikasi yang berjalan di lingkungan produksi.

Vault dapat mengurangi kemungkinan kebocoran pada saat penyimpanan. Namun, risiko tetap ada selama kredensial yang telah keluar dari vault masih mempunyai masa berlaku panjang.

Masa Berlaku Menentukan Besarnya Kesempatan Penyerang

Kredensial jangka panjang memberikan waktu yang lebih luas bagi penyerang untuk memanfaatkan akses.

Jika token hanya berlaku selama beberapa menit, peluang penggunaannya akan menyempit. Sebaliknya, jika sebuah API key berlaku selama satu tahun, penyerang dapat menunggu, mempelajari pola penggunaan, dan menyamarkan aktivitas agar terlihat seperti trafik normal.

Situasi menjadi lebih berbahaya ketika kredensial tidak memiliki tanggal kedaluwarsa. Selama belum ditemukan dan dicabut, kredensial tersebut dapat menjadi akses persisten menuju sistem perusahaan.

Penyerang tidak selalu langsung mengambil data dalam jumlah besar. Akses dapat digunakan secara perlahan untuk:

• memetakan resource yang tersedia;
• membaca data secara bertahap;
• membuat akses tambahan;
• meningkatkan hak akses;
• berpindah ke sistem lain;
• menunggu kesempatan yang lebih menguntungkan;
• kembali setelah aktivitas awal dianggap selesai.

Karena itu, risiko kebocoran tidak hanya ditentukan oleh apakah sebuah secret berhasil dicuri. Pertanyaan yang lebih penting adalah berapa lama secret tersebut masih dapat digunakan dan seberapa luas akses yang diberikannya.

Kredensial Lama Sering Bertahan karena Aplikasi Takut Terganggu

Banyak kredensial jangka panjang tetap aktif bukan karena perusahaan menganggapnya aman, melainkan karena kredensial tersebut telah terhubung dengan terlalu banyak sistem.

Satu password database mungkin digunakan oleh beberapa aplikasi. Satu API key dapat dipakai oleh pipeline, proses integrasi, dan script operasional. Sementara itu, satu service account mungkin digunakan oleh sejumlah workload yang sebenarnya memiliki kebutuhan berbeda.

Tim akhirnya enggan melakukan rotasi karena tidak mengetahui seluruh ketergantungannya. Pergantian kredensial dikhawatirkan menyebabkan aplikasi berhenti, integrasi gagal, atau proses bisnis terganggu.

Akibatnya, kredensial terus digunakan meskipun pemilik awalnya telah berpindah tugas, aplikasinya sudah dimodifikasi, atau kebutuhan aksesnya telah berubah.

Kondisi tersebut juga menciptakan secret sprawl. Salinan kredensial dapat tersebar di berbagai environment, backup, pipeline, container image, atau konfigurasi lama yang tidak lagi terpantau.

Semakin lama sebuah kredensial digunakan, semakin sulit memastikan seluruh salinannya masih berada di lokasi yang aman.

Rotasi Berkala Belum Tentu Menjadikan Kredensial Aman

Rotasi kredensial sering dipandang sebagai jawaban utama atas risiko kredensial jangka panjang. Langkah ini memang penting, tetapi efektivitasnya bergantung pada cara rotasi dilakukan.

Mengganti password setiap enam bulan masih meninggalkan jendela penyalahgunaan yang panjang. Rotasi juga tidak banyak membantu jika kredensial baru kembali disalin ke banyak sistem atau digunakan bersama oleh beberapa aplikasi.

Masalah lain muncul ketika kredensial lama tidak benar-benar dicabut. Perusahaan dapat berhasil menerbitkan secret baru, tetapi secret sebelumnya masih aktif karena proses migrasi belum selesai atau tim khawatir terdapat aplikasi yang masih menggunakannya.

Rotasi yang hanya mengganti nilai tanpa memperbaiki arsitektur akan mengulang risiko yang sama.

Perusahaan perlu membedakan tiga fungsi yang sering dianggap serupa:

• Vault melindungi penyimpanan dan distribusi secret.
• Rotasi mengganti kredensial lama dengan kredensial baru.
• Kredensial dinamis membatasi masa berlaku dan menghasilkan akses berdasarkan kebutuhan.

Ketiganya saling melengkapi, tetapi tidak dapat sepenuhnya menggantikan satu sama lain.

Kredensial Bersama Menghilangkan Jejak Identitas

Penggunaan satu kredensial oleh beberapa aplikasi menimbulkan masalah yang lebih besar daripada sekadar kesulitan rotasi.

Ketika terjadi aktivitas mencurigakan, audit log hanya menunjukkan akun atau API key yang digunakan. Tim keamanan tidak dapat dengan mudah menentukan aplikasi, workload, pipeline, atau proses mana yang melakukan tindakan tersebut.

Situasi ini memperlambat investigasi dan meningkatkan dampak pencabutan. Menonaktifkan satu kredensial dapat menghentikan beberapa layanan sekaligus karena semuanya bergantung pada akses yang sama.

Hak akses juga cenderung menjadi terlalu luas. Kredensial bersama harus memiliki izin yang cukup untuk memenuhi kebutuhan seluruh penggunanya. Akibatnya, aplikasi dengan kebutuhan sederhana dapat memperoleh akses yang sebenarnya tidak diperlukan.

Setiap aplikasi, pipeline, dan workload sebaiknya memiliki identitasnya sendiri. Pemisahan tersebut memungkinkan perusahaan menetapkan izin yang lebih spesifik, memantau aktivitas dengan lebih jelas, serta mencabut satu akses tanpa mengganggu layanan lainnya.

Dynamic Secrets Mempersempit Jendela Penyalahgunaan

Dynamic secrets menawarkan pendekatan yang berbeda dari kredensial statis.

Alih-alih memberikan satu password yang digunakan terus-menerus, sistem dapat menghasilkan kredensial baru ketika aplikasi membutuhkan akses. Kredensial tersebut memiliki masa berlaku atau lease tertentu dan akan kedaluwarsa secara otomatis.

Pendekatan ini memberikan beberapa keuntungan.

Pertama, kredensial yang bocor hanya dapat digunakan dalam waktu terbatas. Penyerang tidak memperoleh akses permanen hanya dengan mencuri satu secret.

Kedua, setiap kredensial dapat diterbitkan untuk aplikasi atau sesi tertentu. Aktivitas menjadi lebih mudah dikaitkan dengan workload yang menggunakannya.

Ketiga, akses dapat dicabut tanpa harus mengganti kredensial yang digunakan seluruh sistem. Dampak operasional menjadi lebih terkontrol.

Dynamic secrets dapat diterapkan pada akses database, cloud infrastructure, CI/CD pipeline, serta berbagai layanan internal yang mendukung penerbitan kredensial sementara.

Namun, penerapannya tetap memerlukan perencanaan. Aplikasi harus mampu meminta kredensial baru, menangani masa kedaluwarsa, dan memperbarui koneksi tanpa menyebabkan downtime.

Tujuannya Bukan Sekadar Mengelola Kunci dengan Lebih Baik

Dalam arsitektur yang lebih modern, perusahaan dapat mengurangi ketergantungan pada secret permanen melalui workload identity, managed identity, atau identity federation.

Model lama mengharuskan aplikasi membawa sebuah kunci untuk membuktikan bahwa ia berhak memperoleh akses. Siapa pun yang memiliki kunci tersebut dapat dianggap sebagai aplikasi yang sah.

Model berbasis identitas bekerja dengan cara berbeda. Workload membuktikan identitasnya kepada platform, kemudian menerima token sementara dengan izin dan masa berlaku yang terbatas.

Perubahan ini menggeser fokus dari kepemilikan secret menuju pembuktian identitas.

Aplikasi tidak lagi menyimpan API key permanen hanya untuk mengakses layanan cloud. Pipeline juga tidak harus menyimpan access key jangka panjang jika dapat menggunakan federasi identitas untuk memperoleh token sementara.

Pendekatan tersebut tidak sepenuhnya menghilangkan kebutuhan secrets management. Namun, jumlah secret permanen yang harus disimpan, didistribusikan, dan dirotasi dapat dikurangi secara signifikan.

CI/CD Menjadi Titik Risiko yang Sering Terlewatkan

Pipeline membutuhkan akses untuk mengambil source code, membuat artifact, mengirim image, menjalankan deployment, dan memperbarui infrastruktur. Karena itu, CI/CD sering menyimpan banyak kredensial dengan hak akses tinggi.

Masalahnya, pipeline juga menerima input dari berbagai sumber. Script, dependency, pull request, build configuration, dan tools pihak ketiga dapat memengaruhi proses yang berjalan di dalamnya.

Jika pipeline menggunakan kredensial jangka panjang, satu proses yang berhasil disusupi dapat memberikan akses berkelanjutan ke repository, registry, cloud, atau server produksi.

Serangan pada software supply chain telah memperlihatkan bagaimana token developer dan kredensial otomatisasi menjadi sasaran bernilai tinggi. Kredensial tersebut dapat digunakan untuk mengubah package, menyisipkan kode berbahaya, atau menyebarkan serangan ke pengguna lain.

Karena itu, pipeline sebaiknya menggunakan identitas terpisah untuk setiap environment. Kredensial juga perlu diterbitkan hanya ketika proses berjalan dan kedaluwarsa setelah pekerjaan selesai.

Vault Dapat Menjadi Fondasi untuk Akses Dinamis

Kritik terhadap kredensial jangka panjang tidak berarti vault tidak lagi diperlukan. Justru vault dapat menjadi fondasi untuk membangun pengelolaan kredensial yang lebih matang.

Perusahaan dapat menggunakan vault untuk:

• menghasilkan dynamic secrets;
• menetapkan masa berlaku kredensial;
• mengelola lease;
• mencabut akses secara otomatis;
• menerapkan kebijakan akses;
• memisahkan identitas aplikasi;
• mencatat setiap penerbitan kredensial;
• mengotomatisasi rotasi.

Peran vault perlu diperluas dari sekadar tempat penyimpanan menjadi pengelola siklus hidup kredensial.

Dengan pendekatan tersebut, vault tidak hanya menjawab pertanyaan tentang tempat menyimpan secret. Vault juga membantu menentukan siapa yang boleh mendapatkannya, untuk keperluan apa, dengan izin apa, dan sampai kapan akses tersebut berlaku.

Kredensial Jangka Panjang Tidak Selalu Dapat Langsung Dihapus

Tidak semua perusahaan dapat langsung beralih ke dynamic secrets atau workload identity.

Aplikasi legacy, perangkat jaringan lama, database tertentu, dan layanan milik vendor mungkin belum mendukung mekanisme autentikasi modern. Beberapa integrasi masih mengharuskan penggunaan API key atau password statis.

Dalam keadaan tersebut, perusahaan perlu menerapkan kontrol tambahan.

Setiap aplikasi sebaiknya menggunakan kredensial berbeda. Hak akses harus dipersempit sesuai kebutuhan. Masa berlaku perlu ditetapkan dan rotasi harus diotomatisasi sejauh mungkin.

Penggunaan kredensial juga perlu dibatasi berdasarkan jaringan, environment, atau sumber permintaan. Aktivitasnya harus dipantau agar penyalahgunaan dapat terdeteksi lebih cepat.

Perusahaan juga perlu mengetahui pemilik dan ketergantungan setiap kredensial. Informasi ini dibutuhkan agar pencabutan dapat dilakukan dengan cepat tanpa menimbulkan gangguan yang tidak terencana.

Audit Tidak Boleh Hanya Mencari Secret di Source Code

Pemindaian source code memang penting untuk menemukan password, token, atau API key yang tersimpan secara tidak sengaja. Namun, pengujian keamanan perlu melihat lebih jauh.

Audit perlu memeriksa kredensial yang tetap aktif meskipun sudah tidak digunakan. Service account tanpa pemilik, akun bersama, API key tanpa masa kedaluwarsa, dan hak akses berlebihan juga perlu menjadi perhatian.

Pengujian juga harus melihat bagaimana aplikasi mengambil secret, tempat kredensial hadir saat runtime, mekanisme rotasi, serta langkah yang dilakukan ketika terjadi kebocoran.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Dalam sejumlah lingkungan, secret memang tidak lagi ditemukan di dalam source code. Namun, aplikasi masih menggunakan kredensial permanen dengan izin luas dan proses pencabutan yang belum pernah diuji.

Keamanan terlihat lebih baik dari sisi penyimpanan, tetapi risiko operasionalnya belum benar-benar berkurang.

Mengurangi Ketergantungan pada Kredensial Permanen

Perbaikan tidak harus dilakukan secara sekaligus. Perusahaan dapat memulainya dengan membuat inventaris seluruh kredensial aplikasi.

Inventaris tersebut setidaknya mencakup API key, password database, access token, sertifikat, service account, pemilik, sistem pengguna, hak akses, dan masa berlaku.

Kredensial dengan hak akses tinggi, akses produksi, penggunaan bersama, atau masa berlaku tidak terbatas harus menjadi prioritas.

Setelah itu, identitas perlu dipisahkan berdasarkan aplikasi, workload, pipeline, dan environment. Langkah ini membuat proses rotasi dan pencabutan lebih aman karena dampaknya tidak menyebar ke banyak sistem.

Perusahaan kemudian dapat memperpendek masa berlaku secara bertahap. Kredensial yang berlaku selama bertahun-tahun dapat diubah menjadi beberapa bulan, kemudian beberapa hari atau jam jika teknologi pendukungnya tersedia.

Pada sistem yang mendukung, kredensial statis dapat digantikan dengan dynamic secrets, managed identity, atau workload identity. Sementara itu, aplikasi legacy tetap dilindungi melalui kontrol tambahan dan rencana modernisasi yang jelas.

Secrets Management Harus Menjadi Bagian dari Secure SDLC

Pengelolaan secret tidak seharusnya baru dibahas setelah aplikasi masuk ke produksi.

Sejak tahap perancangan, tim perlu menentukan bagaimana aplikasi membuktikan identitasnya, resource apa yang dapat diakses, serta berapa lama akses tersebut berlaku.

Pipeline pengembangan perlu mencegah hardcoded credentials. Proses deployment harus dapat mengambil kredensial secara aman. Aplikasi juga harus mampu menangani rotasi tanpa gangguan layanan.

Pada tahap pengujian, tim keamanan perlu menilai kemungkinan pengambilan secret, penyalahgunaan service account, eskalasi hak akses, dan penggunaan kembali kredensial yang telah bocor.

Pendekatan ini membuat secrets management menjadi bagian dari Secure SDLC, bukan sekadar konfigurasi tambahan menjelang deployment.

Brankas yang Baik Tetap Membutuhkan Kunci yang Dapat Kedaluwarsa

Vault merupakan langkah penting untuk meningkatkan keamanan kredensial aplikasi. Namun, keberadaan vault tidak boleh menciptakan rasa aman yang keliru.

Secret yang terenkripsi dan tersimpan dengan rapi tetap dapat menimbulkan risiko apabila berlaku terlalu lama. Setelah kredensial keluar dari vault dan digunakan oleh aplikasi, masa berlaku serta cakupan izinnya menentukan besarnya dampak kebocoran.

Perusahaan perlu bergerak dari sekadar menyimpan secret menuju pengelolaan siklus hidup kredensial. Setiap akses harus memiliki pemilik, tujuan, batas izin, masa berlaku, dan mekanisme pencabutan yang jelas.

Tujuan akhirnya bukan menyimpan satu secret dengan aman untuk selamanya. Tujuannya adalah memastikan aplikasi hanya memperoleh akses yang diperlukan, pada saat diperlukan, dan selama masih diperlukan.

Fourtrezz membantu perusahaan mengevaluasi keamanan aplikasi dan infrastruktur melalui layanan vulnerability assessment dan penetration testing. Pengujian dapat membantu menemukan kelemahan pada autentikasi, hak akses, konfigurasi, service account, serta pengelolaan kredensial sebelum dimanfaatkan oleh pihak yang tidak bertanggung jawab.

Untuk mendiskusikan kebutuhan pengujian keamanan dan peluang kerjasama, silakan menghubungi Fourtrezz.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]