Secrets Management: Pelajaran dari Key yang Hampir Ngebocorin Semua Password Production

Gue masih inget banget malam itu. Jam udah nunjukin setengah dua pagi, mata gue udah perih kayak abis kebanyakan scroll, dan gue lagi ngejar deadline fitur yang katanya "harus keluar besok pagi". Production udah mulai error karena perubahan skema database, dan gue butuh API key buat ngetes langsung ke environment asli. Buru-buru, gue buka file konfigurasi, salin key production, tempel ke file .env lokal, terus gue commit semua perubahan sekaligus.

Iya. Gue commit. Satu commit besar yang nyampur kode fitur, perubahan konfigurasi, dan file .env yang isinya segudang credential production. Semua dalam satu tarikan napas, tanpa mikir dua kali. Untungnya repo itu masih privat waktu itu, jadi gak ada yang lihat. Tapi kejadian itu ninggalin rasa yang gak enak di perut gue. Gue sempet mikir, gimana kalau repo ini gak sengaja ke-publish? Gimana kalau besoknya gue pindahin repo ini ke public biar bisa nunjukin portfolio ke rekruter? Semua password, semua token, semua key production bakal jadi milik siapa aja yang mau lihat.

Malam itu gue gak bisa tidur. Bukan karena deadline, tapi karena sadar kalau gue udah main-main sama satu hal yang paling sensitif di seluruh infrastruktur: rahasia. Dan dari malam itu, gue mulai belajar serius tentang apa yang di dunia DevOps dan security disebut sebagai secrets management. Ini bukan cerita yang nyenengin buat diceritain, tapi gue yakin banyak dari kalian yang pernah ngalamin hal yang mirip, atau lagi jalan di jurang yang sama tanpa sadar.

Kenapa Secrets Itu Beda dari Kode Biasa

Hal pertama yang gue pahamin setelah kejadian itu adalah kenapa credential gak boleh diperlakukan kayak kode biasa. Kode punya bug, kode bisa di-refactor, kode bisa diperbaiki kalau ada yang salah. Tapi kalau sebuah secret bocor, dia gak bisa diperbaiki. Dia cuma bisa di-revoke, di-rotate, dan diganti. Dan proses penggantian itu bukan cuma soal bikin token baru, tapi juga nyebarin token baru itu ke semua tempat yang butuh, nyatetin tempat lama yang masih nyimpen token lama, dan berharap gak ada yang nangkep token lama di antara celah waktu itu.

Coba bayangin bedanya. Kalau gue nemu bug di kode login, gue bisa patch dan deploy, selesai. Tapi kalau gue nemu API key yang ke-publish di GitHub, gue harus mikirin: siapa yang udah ngeliat key ini? Ada bot yang nge-scan GitHub 24 jam nonstop buat nyari key yang bocor kayak gini. Begitu key ke-publish, hitungannya bukan jam, tapi menit — bahkan detik — sebelum ada yang nyobain. Dan kalau key itu punya akses ke production, malapetaka.

Di malam yang gak bisa tidur itu, gue baru sadar kalau selama ini gue nganggep secret sebagai hal yang sepele. .env file? Ah, itu cuma file konfigurasi. Token? Itu cuma string panjang yang gue tempel-tempel di kode. Padahal, string panjang itu adalah kunci ke seluruh kingdom. Tanpa sadar, gue udah bikin sistem yang keamanannya bergantung pada seberapa sering gue lupa nge-push file .env. Itu bukan keamanan, itu cuma harapan.

Malam Pertama Gue Kenalan Sama Secret Sprawl

Setelah kejadian itu, gue mulai audit semua tempat di mana secret gue tinggal. Dan hasilnya bikin gue makin gak enak tidur. Secret gue ada di mana-mana. Ada yang nyangkut di file .env lokal, ada yang di-hardcode di dalam kode, ada yang numpang lewat di command history, ada yang ke-commit ke git history (walaupun udah dihapus dari file terbaru, sejarahnya tetap ada), ada yang nyangkut di chat tim, ada yang ke-tempel di Notion, bahkan ada yang gue simpen di file teks polos di desktop.

Fenomena ini punya nama: secret sprawl. Semakin banyak tempat secret tinggal, semakin besar permukaan serangan, dan semakin sulit buat ngelacak siapa yang punya akses ke apa. Ini kayak nyimpen kunci rumah di bawah keset, di dalam pot bunga, di saku jaket lama, di dompet yang udah gak kepake, dan di dalam buku yang gak pernah dibuka. Kalau ada satu aja yang ketemu orang lain, dia bisa masuk ke rumah tanpa perlu nyobain pintu.

Yang bikin secret sprawl makin bahaya adalah cara kerja tim yang buru-buru. Orang selalu milih jalan tercepat. Kalau butuh database password, yang gampang adalah nempel password itu di file konfigurasi yang ikut ke repo. Kalau butuh API key buat ngetes, yang gampang adalah nulis langsung di kode. Kalau butuh akses server, yang gampang adalah kirim password lewat chat. Semua pilihan yang "gampang" ini adalah bibit dari bencana. Dan gue pernah jadi bagian dari semua itu.

Bukan Sekadar Masalah Alat

Waktu gue mulai riset cara ngatasin ini, gue kira jawabannya tinggal beli atau pasang satu alat aja, terus beres. Ternyata gue salah besar. Secrets management itu bukan soal alat, tapi soal pola pikir dan kebiasaan. Alat cuma bantu, tapi kalau manusianya masih punya kebiasaan nempel token di kode, alat secanggih apa pun bakal kewalahan.

Gue pernah baca cerita tentang sebuah perusahaan yang udah pasang HashiCorp Vault, alat yang terkenal banget buat nyimpen dan ngelola secret secara terpusat. Semua orang di tim udah dilatih, udah ada SOP, udah ada integration ke aplikasi. Tapi pas di-audit, mereka nemu ratusan secret yang masih nyangkut di file konfigurasi lama, di skrip yang udah gak kepake, dan di chat internal. Vault-nya jalan, tapi orang-orangnya masih nyimpen secret di tempat lama karena itu yang udah kebiasaan.

Dari situ gue belajar satu hal penting: keamanan secret itu 20 persen soal alat, 80 persen soal budaya. Kalau tim masih ngerasa nyaman nyimpen password di tempat yang gampang, semua investasi di alat mahal bakal sia-sia. Kebiasaan nyimpen secret dengan benar harus dibangun dari bawah, dari cara orang nulis kode, cara orang nge-deploy, dan cara orang ngomongin akses di dalam tim.

Perjalanan Gue Nyusun Ulang Cara Nyimpen Secret

Setelah audit itu, gue mulai pelan-pelan ngerombak cara gue dan tim gue nyimpen secret. Gak sekaligus, karena gue percaya perubahan yang keburu-buru cuma bikin chaos baru. Tapi step by step, dan setiap step gue dokumentasikan supaya gak ada yang bingung.

Langkah pertama yang paling mendasar adalah ngeluarin semua secret dari repo. Gak ada alasan buat sebuah API key atau password tinggal di dalam file yang ikut ke git. File .env boleh ada di lokal, tapi dia harus masuk ke .gitignore sejak hari pertama, dan semua orang harus paham kenapa. Bukan cuma "jangan push file ini", tapi "file ini isinya kunci ke sistem kita, dan kunci gak pernah ikut ke dalam kotak yang bisa dilihat orang banyak".

Langkah kedua, gue mulai pindahin secret ke tempat yang terpusat. Untuk proyek kecil, gue pakai secret manager bawaan dari platform tempat aplikasi jalan. Kalau di cloud, gue pakai layanan secret manager yang disediakan penyedia cloud. Kalau di server pribadi, gue mulai belajar Vault. Konsepnya sama: secret disimpen di satu tempat yang aman, di-encrypt, dan aplikasi minta akses ke secret itu pas dia butuh, bukan nyimpen salinan di file.

Langkah ketiga, gue mulai ngurusin akses. Dulu, satu password dipakai semua orang, semua aplikasi, semua environment. Sekarang gue belajar bedain: development punya secret sendiri, staging punya sendiri, production punya sendiri. Secret production cuma bisa diakses oleh aplikasi yang emang butuh, bukan oleh semua developer yang lagi ngoding. Ini terasa ribet di awal, tapi efeknya gede banget. Kalau secret development bocor, gak ada yang kebakar. Kalau secret production bocor, dampaknya ke sistem beneran.

Langkah keempat, yang paling gue remehin sebelumnya, adalah rotasi. Secret gak boleh abadi. Kalau sebuah key dipakai bertahun-tahun tanpa diganti, dia kayak kunci rumah yang gak pernah diganti padahal udah banyak orang yang pernah pegang. Rotasi itu bukan cuma soal "ganti password tiap 90 hari", tapi soal punya proses yang jelas: gimana ganti secret tanpa ngebuat aplikasi down, gimana mastiin semua sistem yang butuh tau soal pergantian, dan gimana ngasih tau kalau ada yang lupa.

Cerita Bocor yang Beneran

Sebelum gue keburu sok bijak, gue mau cerita satu hal yang bikin gue makin yakin sama pentingnya semua ini. Beberapa bulan setelah gue mulai ngerombak, ada satu kejadian di salah satu proyek yang gue kelola. Seorang anggota tim baru, yang semangat banget pengen nunjukin kerjaannya, bikin repo baru buat nge-share script yang dia bikin. Tanpa sengaja, script itu nyertain token akses ke salah satu layanan yang dia pakai buat ngetes. Repo itu dia publish biar bisa nunjukin ke temennya.

Untungnya, waktu itu kami udah punya kebiasaan nyimpen token dengan sistem yang jelas, dan token yang bocor itu bukan token production. Dia token development dengan scope terbatas. Kami bisa deteksi karena ada alert yang ngasih tau kalau ada token yang ke-scan di GitHub, dan kami bisa cabut token itu dalam hitungan jam sebelum dipakai siapa-siapa. Kalau ini kejadian sebelum gue belajar, token production dengan akses penuh bisa aja yang ke-publish, dan kami bakal ngehabisin waktu berhari-hari buat bersihin kekacauan.

Kejadian itu ngajarin gue bahwa keamanan itu soal lapisan. Bukan satu tembok yang tinggi, tapi banyak lapisan pelindung yang masing-masing bisa ngebeliin waktu. Token yang jarang ke-rotate itu satu lapisan yang gak ada. Token yang punya akses ke semua environment itu satu lapisan yang bolong. Token yang gampang ketauan ke-scan itu peringatan dini. Makin banyak lapisan, makin besar kemungkinan kita bisa ngehentiin masalah sebelum jadi bencana.

Alat yang Beneran Kepake

Oke, sekarang gue mau cerita dikit soal alat-alat yang menurut gue beneran kepake, bukan yang cuma bagus di atas kertas. Ini bukan checklist, tapi cerita pengalaman gue nyobain hal-hal ini satu per satu.

Yang pertama, GitHub Secret Scanning. Ini fitur bawaan yang otomatis nge-scan semua repo buat nyari pola token yang umum dipakai banyak layanan. Dia bukan cuma buat repo public, tapi juga repo privat. Yang gue suka, dia bisa nyari pola token dari ratusan penyedia, dari AWS, Google Cloud, sampai layanan kecil yang jarang orang denger. Waktu ada yang ke-scan ketauan, GitHub ngasih notifikasi, dan biasanya langsung bisa di-revoke dari dashboard penyedianya. Ini kayak alarm kebakaran yang mati-matian ngingetin sebelum api ngebesar.

Yang kedua, pre-commit hook. Ini adalah script yang jalan otomatis sebelum commit dibuat, dan dia bisa nge-scan file yang mau di-commit buat mastiin gak ada secret yang keikutan. Bayangin, sebelum gue sempet bikin commit yang nyangkutin token, hook ini udah ngeblok duluan. Ada alat kayak git-secrets dan trufflehog yang bisa dipasang buat ngecek pola-pola secret umum. Pas gue pasang, awalnya agak ganggu karena sering ngeblok file yang sebenernya aman, tapi makin lama gue bisa ngatur supaya cuma ngeblok yang beneran bahaya.

Yang ketiga, Vault. Ini yang gue bilang paling powerful tapi juga paling makan waktu buat dipelajari. Vault bisa nyimpen secret secara terpusat, di-encrypt dengan master key, dan kasih akses berbasis kebijakan. Yang bikin Vault beda, dia bisa bikin secret yang dinamis, yang di-generate on demand dan punya umur sendiri. Misal, database password gak harus disimpen permanen, tapi bisa di-generate tiap aplikasi butuh, terus mati sendiri setelah dipakai. Ini konsep yang gue rasa canggih banget, dan walaupun gue baru bisa terapin di sebagian kecil sistem, gue ngerasa ini masa depan secrets management.

Yang keempat, jangan lupa yang paling sederhana: password manager buat manusia. Buat secret yang emang harus dipegang orang, kayak password akun admin atau kunci recovery, jangan pernah simpen di Notion atau chat. Pakai password manager yang proper, yang di-encrypt, yang bisa dikasih akses per orang, dan yang punya audit trail. Ini kayak brankas kecil di kantor. Mungkin keliatan lebay, tapi pas gue butuh ngasih akses ke server ke orang baru, gue tinggal share lewat password manager, dan gue bisa liat siapa yang ngeliat apa.

Kebiasaan yang Harus Dibangun dari Awal

Satu hal yang gue rasa kurang dibahas orang adalah kebiasaan. Semua orang sibuk bahas alat, tapi jarang bahas gimana bikin kebiasaan nyimpen secret yang bener itu nempel di tim. Padahal, alat tanpa kebiasaan itu cuma hiasan.

Kebiasaan pertama yang gue coba tanemin adalah "jangan pernah taruh secret di kode". Ini aturan yang paling simpel, tapi paling sering dilanggar. Setiap kali ada yang mau nulis password di dalam kode, gue selalu tanya: kenapa gak pindahin ke tempat yang aman? Seringnya jawabannya cuma "biar cepet" atau "nih cuma buat sementara". Dua alasan ini yang bikin secret bocor.

Kebiasaan kedua, "jangan pernah share secret lewat chat". Chat itu gampang ke-forward, gampang ke-screenshot, gampang ke-cari. Begitu sebuah secret masuk chat, dia udah ada di tempat yang gak bisa dikontrol lagi. Kalau butuh ngasih akses, selalu lewat jalur yang aman, dan kalau gak ada jalur aman, itu tanda sistemnya yang harus dibenerin, bukan alasan buat nyimpen secret di chat.

Kebiasaan ketiga, "kalau ragu, anggap bocor". Waktu gue nanya ke senior gue soal satu key yang gue gak yakin udah kepakai di mana aja, dia bilang: kalau lo ragu apakah sebuah secret udah bocor, anggap aja bocor, langsung rotate. Gak ada kata "mudah-mudahan aman". Karena kalau gak yakin dan ternyata emang bocor, biayanya jauh lebih gede daripada sekadar nge-rotate key yang gak apa-apa.

Kebiasaan keempat, "dokumentasi itu bagian dari keamanan". Dulu gue mikir dokumentasi itu buat orang lain, buat yang baru masuk tim. Padahal, dokumentasi yang jelas soal di mana secret disimpen, gimana ngakses, dan gimana nge-rotate itu bagian penting dari keamanan. Kalau cuma satu orang yang tau gimana sistem secret bekerja, dan orang itu lagi cuti pas ada insiden, tim bakal panik dan bikin keputusan buru-buru yang justru ngebuat masalah makin gede.

Yang Gue Ubah di Proyek Sendiri

Setelah semua pembelajaran itu, gue mulai terapin ke proyek-proyek yang gue pegang sendiri. Awalnya gue pikir ini bakal ribet banget, tapi ternyata gak sesulit yang gue bayangin, asal dilakuin bertahap.

Gue mulai dari hal paling sederhana: mastiin semua repo punya .gitignore yang bener, dan file .env gak pernah ke-commit. Kemudian gue pasang pre-commit hook di repo yang paling sering dipakai, supaya ada jaring pengaman otomatis. Lalu gue pindahin secret yang paling sering kepake ke secret manager, dan aplikasi baca dari situ, bukan dari file. Terakhir, gue bikin jadwal rotasi, dan gue catat di kalender, supaya gak ada secret yang diam-diam umurnya nembus satu tahun.

Yang paling berasa dampaknya adalah waktu gue bisa ngilangin semua credential dari kode. Aplikasi jadi lebih bersih, onboarding anggota baru jadi lebih gampang karena gak perlu nanya-nanya "passwordnya apa?" ke sana kemari, dan yang paling penting, gue tidur lebih nyenyak. Mungkin kedengeran lebay, tapi serius, perasaan aman karena gak ada secret yang nyangkut di tempat yang gak jelas itu nilainya gede banget.

Gagal Itu Bagian dari Belajar

Gue gak mau ngegambarin perjalanan ini mulus-mulus aja. Ada banyak gagalnya. Ada waktu di mana gue nemu token yang nyangkut di git history, dan harus ngubek-ubek riwayat commit buat mastiin gak ada yang ngeliat. Ada waktu di mana gue salah konfigurasi Vault, dan aplikasi malah error karena gak bisa akses secret. Ada waktu di mana gue lupa nge-rotate key, dan harus begadang ngelakuinnya pas tau ada audit.

Tapi dari semua kegagalan itu, gue belajar satu pola yang sama: kebanyakan masalah secret muncul dari kebiasaan buru-buru dan kurangnya kesadaran. Bukan dari niat jahat, bukan dari alat yang jelek, tapi dari orang yang gak sadar kalau yang dia lakuin itu bahaya. Makanya gue rasa, bagian paling penting dari secrets management itu bukan teknologinya, tapi kesadaran orang-orang yang megang sistem.

Refleksi di Ujung Malam

Kalau gue balik lagi ke malam di mana gue hampir nge-commit semua password production, sekarang gue bisa ketawa-ketiwi ngeliat kelakuan gue waktu itu. Tapi di balik ketawa itu, ada rasa syukur karena gak terjadi apa-apa, dan ada tekad buat gak ngulangin kesalahan yang sama.

Gue percaya, setiap orang yang kerja di bidang teknologi bakal ngalamin momen kayak gini, atau minimal bakal diingetin oleh orang lain. Pertanyaannya bukan "apakah lo bakal ngalamin", tapi "apa yang lo lakuin pas ngeliat momen itu". Apakah lo bakal cuek dan berharap gak ada yang liat? Atau lo bakal jadikan momen itu titik balik buat ngerombak cara lo nyimpen rahasia?

Buat gue, jawabannya udah jelas. Gue milih buat berubah, buat belajar, dan buat ngebangun kebiasaan yang bener. Dan kalau lo lagi ada di posisi yang sama kayak gue dulu, gue cuma mau bilang: ini bukan soal jadi sempurna, ini soal mulai. Mulai dari hal kecil, mulai dari satu repo, mulai dari satu secret yang lo pindahin ke tempat yang aman. Selebihnya bakal ngikut.

Semoga catatan gue ini bisa ngebantu lo yang lagi belajar, atau minimal ngebikin lo berpikir dua kali sebelum nge-commit file .env ke repo public. Karena di dunia yang makin terhubung ini, secret yang bocor bukan cuma masalah pribadi, tapi bisa jadi masalah buat semua orang yang pake sistem yang sama. Jaga rahasia kalian, jaga sistem kalian, dan jangan pernah anggap sepele string panjang yang kelihatan gak penting itu. Dia bisa jadi kunci ke seluruh dunia digital lo.