Memindahkan password dari kode ke file
.env mengubah tempat penyimpanannya. Setelah aplikasi membacanya, nilai yang sama masih dapat ikut tercetak ke log, terbawa ke artefak build, atau tersalin bersama berkas proyek.Saya ingin mengikuti perjalanan secret sepanjang sistem, bukan berhenti pada nama file. Sebagai contoh, saya memakai aplikasi web yang membutuhkan kredensial database dan token layanan pengiriman email. Tujuannya membatasi siapa yang menerima nilai tersebut, untuk apa, dan sampai kapan.
Peta singkat
Tahap | Pertanyaan pemeriksaan |
File lokal | Siapa yang dapat membaca secret dan bagaimana aplikasi memuatnya? |
Git | Apakah nilainya pernah masuk commit atau salinan repository? |
Build | Apakah secret hanya tersedia saat diperlukan atau ikut menjadi artefak? |
Log | Apakah jalur normal maupun error mencatat nilai rahasia? |
Runtime | Layanan mana yang mendapat akses, dengan hak apa? |
Rotasi | Bagaimana kredensial diganti dan akses lama dicabut? |
1. Pahami apa yang dilakukan loader .env
Perilaku itu membantu memisahkan konfigurasi dari kode. Namun, memuat variabel lingkungan tidak dengan sendirinya mengenkripsi berkas atau menetapkan siapa yang boleh membacanya.
Nama variabel cukup disimpan di
.env.example tanpa nilai rahasia, sedangkan nilai nyata diberikan lewat jalur konfigurasi yang aksesnya dibatasi. Periksa juga apakah file .env bisa ikut disajikan web server atau tersalin ke direktori publik.Contoh konfigurasi kosongnya cukup seperti ini:
DATABASE_URL=
MAIL_API_TOKEN=Pemisahan ini memudahkan pembaca proyek mengenali kebutuhan konfigurasi tanpa mendapatkan kredensialnya. File contoh tetap perlu ditinjau agar tidak berubah menjadi salinan konfigurasi produksi.
2. .gitignore tidak menghapus riwayat
Dokumentasi Git 2.37.3 menyatakan bahwa aturan ignore tidak memengaruhi file yang sudah dilacak Git.
Karena itu, menambahkan
.env ke .gitignore setelah commit tidak cukup. git rm --cached dapat menghapus path dari index sambil mempertahankan file kerja, sebagaimana dijelaskan dalam dokumentasi git-rm versi yang sama. Tindakan tersebut bukan penghapusan seluruh commit terdahulu.Jika token email sudah masuk repository dan dibagikan, anggap token itu sudah disalin: cabut atau ganti token, perbarui pemakai yang sah, lalu tangani riwayat dan salinan yang dapat dikendalikan.
Pembersihan riwayat perlu dikoordinasikan dengan pemilik repository dan pemakai clone. Proses itu bukan alasan untuk menunda pencabutan token yang sudah terpapar.
3. Pisahkan secret build dari hasil build
Bayangkan proses build membutuhkan akses ke dependency privat. Kebutuhan sementara itu tidak berarti kredensialnya perlu berada di aplikasi hasil build.
Dokumentasi BuildKit v0.10.4 menyediakan
RUN --mount=type=secret untuk memberi proses build akses ke berkas sensitif tanpa memasukkannya sebagai berkas image melalui mekanisme mount tersebut.Cara ini lebih aman daripada menyalin file kredensial ke artefak. Namun, proses yang membaca mount masih dapat menyalin nilainya ke tempat lain atau mencetaknya ke output. Karena itu, penggunaan secret mount tetap membutuhkan peninjauan perintah build dan hasilnya.
Untuk aplikasi contoh, pemeriksaannya mencakup artefak akhir, output build, cache yang dikelola, dan berkas sementara. Paket aplikasi yang dikirim ke browser juga tidak boleh memuat token email server: nilai yang sudah disertakan ke client harus dianggap tersedia bagi penerimanya.
4. Catat kejadian tanpa mencatat kredensial
OWASP ASVS 4.0.3 bagian Error Handling and Logging meminta aplikasi menghindari pencatatan kredensial dan melindungi log dari akses yang tidak berwenang.
Dari log, yang dibutuhkan adalah informasi bahwa pengiriman email gagal, kapan terjadi, dan permintaan mana yang terkait. Token API lengkap tidak diperlukan untuk menjawab pertanyaan itu.
Tinjau pencatatan konfigurasi, header autentikasi, serta objek error dari library. Menyaring satu field di jalur normal belum membuktikan jalur kegagalan aman.
Untuk mengujinya, gunakan token palsu yang mudah dikenali di lingkungan uji. Jalankan jalur berhasil dan gagal, lalu cari apakah penanda itu muncul pada log atau artefak yang seharusnya tidak menerimanya. Hasil pencarian kosong hanya membuktikan jalur yang diuji; jalur lain tetap perlu ditinjau sesuai risikonya.
5. Berikan akses sesuai kebutuhan layanan
Pada contoh tadi, worker pengiriman email membutuhkan token email. Proses yang hanya mengubah ukuran gambar belum tentu membutuhkannya.
Pisahkan kredensial berdasarkan layanan dan lingkungan. Akun database aplikasi diberi hak untuk pekerjaan aplikasinya; kebutuhan migrasi diperiksa sebagai peran tersendiri. Daftar inventaris mencatat pemilik, pemakai, cakupan akses, lokasi pemberian nilai, serta prosedur penggantiannya.
Salah satu pilihan implementasi adalah secret manager. Dokumentasi database secrets engine Vault v1.11.3 menjelaskan kredensial dinamis berdasarkan role, lease, serta mekanisme pencabutan. Ini dapat mengurangi ketergantungan pada satu password bersama yang berumur panjang.
Pemilihan alat tetap mengikuti kebutuhan operasional. Pertanyaan yang tetap harus dijawab: bagaimana aplikasi memperoleh akses awal ke secret manager, apa yang terjadi ketika layanan itu tidak tersedia, dan bagaimana aksesnya diaudit. Memindahkan penyimpanan tidak menghilangkan kebutuhan untuk mengatur batas kepercayaan.
6. Latih rotasi sampai akses lama berhenti
Mengganti nilai di tempat penyimpanan belum membuktikan seluruh pemakai telah beralih. Urutan rotasi yang bisa dilatih:
- Buat kredensial pengganti dengan hak yang diperlukan.
- Perbarui layanan yang berhak menerimanya.
- Pastikan proses dan worker benar-benar memakai nilai baru.
- Cabut kredensial lama sesuai mekanisme penyedia.
- Periksa bahwa layanan tetap bekerja dan kredensial lama ditolak.
- Catat hasil tanpa menyimpan nilainya.
Kemampuan menerima dua kredensial sementara bergantung pada penyedia. Jika tidak tersedia, prosedur harus memperhitungkan pergantian yang membutuhkan penghentian terencana.
Untuk kebocoran yang sedang berlangsung, waktu pencabutan mengikuti risiko; jangan mempertahankan akses penyerang hanya demi urutan rotasi normal. Penilaian dampak dan pemeriksaan aktivitas dilakukan bersama penggantian kredensial.
7. Jadikan pemeriksaan bagian dari rilis
Bagian Configuration di ASVS yang sama menekankan build dan deployment yang aman serta dapat diulang, termasuk menonaktifkan fasilitas debug produksi.
Pemeriksaan file konfigurasi, hasil build, output error, dan rotasi layak masuk daftar verifikasi rilis. Pemindaian secret menjadi salah satu lapisan pemeriksaan, dengan pemahaman bahwa pola yang tidak dikenal dapat terlewat.
Daftar itu juga mencakup salinan backup dan akses operator. Setiap salinan tambahan perlu mempunyai alasan, pemilik, serta batas akses yang jelas.
Penutup
Mulailah dengan satu secret. Petakan dari mana nilainya berasal, proses mana yang membacanya, ke mana ia mungkin tersalin, dan bagaimana aksesnya dicabut.
Jika ada satu tempat dalam perjalanan itu yang tidak bisa dijawab, di situlah secret paling mungkin bocor.