Kenapa Password Database Tidak Boleh Disimpan di File Konfigurasi

Kamu sedang membangun aplikasi baru. Di awal, semua data variabel kamu taruh dalam satu file: nama database, alamat server, URL API. File itu masuk ke Git, didorong ke repositori, lalu di-deploy ke server. Semua ada di satu tempat, dan rasanya praktis. Kemudian kamu menambahkan password database ke file yang sama. Lalu token API. Lalu encryption key. Tiba-tiba, file konfigurasi tunggal itu berubah menjadi risiko keamanan yang bisa meruntuhkan seluruh sistem kamu.

Inilah momen ketika kamu menyadari bahwa tidak semua data konfigurasi itu sama. Beberapa data, jika terekspos, memberikan kunci kerajaanmu kepada orang lain. Data seperti itu disebut secret. Dan memperlakukan secret seperti konfigurasi biasa adalah salah satu kesalahan paling umum dan berbahaya yang dilakukan tim.

Perbedaan Antara Konfigurasi dan Secret

Data konfigurasi biasa mencakup hal-hal seperti nama server, port aplikasi, atau feature flag. Jika seseorang di luar tim kamu tahu bahwa aplikasi kamu berjalan di port 8080, itu bukan bencana. Mereka tidak bisa login ke database kamu hanya karena tahu nomor port.

Secret berbeda. Password database, token API, atau encryption key bisa digunakan oleh penyerang untuk menyamar sebagai sistem kamu, mengakses data kamu, atau menghancurkan infrastruktur kamu. Dampak dari secret yang bocor sangat langsung dan parah.

Namun banyak tim masih memperlakukan secret seolah-olah itu konfigurasi biasa. Mereka menaruh password di file .env dan commit ke Git. Mereka menyimpan token API di file konfigurasi aplikasi dan push ke repositori. Mereka menyimpan SSH key di dalam folder proyek dan backup semuanya ke cloud. Ini bukan karena tim ceroboh. Biasanya karena mereka belum pernah mengalami konsekuensinya.

Apa yang Terjadi Saat Secret Bocor

Pada tahun 2022, beberapa insiden besar melibatkan token AWS yang tertinggal di repositori publik. Penyerang menggunakan token tersebut untuk memutar instance penambangan cryptocurrency. Tagihannya mencapai puluhan ribu dolar dalam hitungan jam. Di kasus lain, password database yang bocor menyebabkan data pelanggan diunduh dan dijual di dark web.

Insiden-insiden ini tidak dimulai dengan serangan canggih. Mereka dimulai dengan kesalahan sederhana: memperlakukan secret seperti file konfigurasi. Secret itu ada di sana, terlihat oleh siapa pun yang bisa mengakses repositori. Begitu repositori menjadi publik, secret itu juga publik.

Riwayat Git membuat ini lebih buruk. Bahkan jika kamu menghapus file yang berisi secret, secret itu tetap ada di riwayat commit. Siapa pun yang melakukan clone repositori bisa menjalankan git log dan menemukan password yang kamu kira sudah dihapus. Tidak ada cara mudah untuk membersihkan riwayat Git sepenuhnya, terutama jika repositori sudah dibagikan atau di-fork.

Bagaimana Konfigurasi dan Secret Berbeda dalam Praktik

Perbedaan antara konfigurasi dan secret memengaruhi cara kamu menanganinya dalam pekerjaan sehari-hari dan di pipeline CI/CD.

Siapa yang bisa melihatnya: Konfigurasi bisa terlihat oleh semua developer di tim. Secret seharusnya hanya terlihat oleh orang atau sistem yang benar-benar membutuhkannya. Tidak semua developer perlu tahu password database produksi.

Di mana mereka disimpan: Konfigurasi bisa tinggal di Git. Secret tidak boleh pernah disimpan di Git. Mereka milik sistem penyimpanan secret khusus yang mengenkripsinya saat diam dan dalam perjalanan.

Bagaimana mereka dirotasi: Konfigurasi jarang perlu dirotasi. Kamu mengganti nama server saat migrasi infrastruktur, dan selesai. Secret perlu rotasi rutin. Kamu harus merotasi password database setiap beberapa bulan, dan segera rotasi jika ada indikasi kebocoran.

Bagaimana pipeline menanganinya: Di pipeline CI/CD, konfigurasi bisa dibaca langsung dari file di repositori. Pipeline mengambil file dan menggunakannya. Secret memerlukan pendekatan berbeda. Pipeline harus mengambilnya dari sistem penyimpanan aman, menyuntikkannya ke proses build atau deploy, dan memastikan mereka tidak pernah muncul di log, artefak, atau file yang di-deploy.

Konsekuensi Praktis dari Mencampuradukkan Keduanya

Ketika kamu memperlakukan secret seperti konfigurasi, kamu menciptakan rangkaian masalah yang sulit diurungkan.

Pertama, kamu kehilangan kendali atas siapa yang memiliki akses. Jika secret ada di Git, siapa pun dengan akses repositori memiliki secret itu. Itu termasuk kontraktor, mantan karyawan yang masih memiliki akses, dan berpotensi penyerang jika repositori publik.

Kedua, kamu membuat rotasi menjadi sulit. Jika secret tersebar di banyak file konfigurasi, branch, dan lingkungan deployment, merotasinya berarti menemukan setiap salinan dan memperbaruinya. Kamu pasti akan melewatkan satu, dan password lama itu akan tetap valid di suatu tempat.

Ketiga, kamu merusak jejak audit. Jika secret bocor, kamu perlu tahu siapa yang memiliki akses dan kapan. Jika secret ada di Git, jawabannya adalah "semua orang yang pernah memiliki akses repositori." Itu bukan jejak audit yang berguna.

Cara Sederhana untuk Membedakan

Sebelum kamu memasukkan data apa pun ke file konfigurasi, tanyakan satu pertanyaan pada diri sendiri: "Jika seseorang di luar tim saya melihat ini, bisakah mereka menggunakannya untuk mengakses sistem saya?"

Jika jawabannya tidak, itu mungkin konfigurasi. Nama server, nomor port, feature flag, dan log level adalah konfigurasi.

Jika jawabannya ya, itu adalah secret. Password database, token API, SSH key, encryption key, dan kredensial akun layanan adalah secret.

Tes sederhana ini akan mencegah sebagian besar kesalahan umum yang dilakukan tim.

Daftar Periksa Praktis untuk Menangani Secret

Saat kamu menyiapkan proyek berikutnya atau meninjau proyek saat ini, jalankan daftar periksa ini:

• Apakah semua secret disimpan di luar Git? Gunakan secret manager atau vault khusus.
• Apakah secret disuntikkan saat runtime, bukan dibake ke dalam image atau artefak?
• Apakah pipeline CI/CD kamu mengambil secret dari sumber yang aman, bukan dari file repositori?
• Apakah secret dikecualikan dari log, pesan error, dan output debug?
• Apakah kamu memiliki jadwal rotasi untuk setiap jenis secret?
• Apakah ada proses untuk merotasi secret segera saat kebocoran dicurigai?
• Bisakah kamu mencabut akses ke secret untuk orang atau sistem tertentu tanpa memengaruhi yang lain?

Kesimpulan

Jika sepotong data bisa digunakan oleh orang lain untuk menyamar sebagai kamu atau sistem kamu, itu bukan konfigurasi. Itu adalah secret. Perlakukan secara berbeda. Simpan secara terpisah. Rotasi secara teratur. Dan jangan pernah, sekali pun, commit ke Git. Biaya belajar pelajaran ini dengan cara yang sulit jauh lebih tinggi daripada upaya melakukannya dengan benar sejak awal.