Ketika Kata Sandi Database Hanya Hidup Beberapa Menit, Bukan Berbulan-Bulan

Tim Anda mungkin sudah rutin merotasi kata sandi database setiap tiga bulan. Anda merasa lebih aman dibanding tim yang tidak pernah merotasi sama sekali. Tapi inilah pertanyaan yang tidak nyaman: bagaimana jika kata sandi bocor dua hari setelah rotasi? Rahasia itu masih valid selama 88 hari ke depan. Siapa pun yang menemukannya bisa mengakses database produksi Anda selama hampir tiga bulan sebelum rotasi berikutnya mematikannya.

Celah itu bukan sekadar teori. Rahasia bocor melalui file log, CI runner yang dikompromikan, laptop developer, atau backup yang salah konfigurasi. Rahasia statis dengan masa hidup panjang memberi penyerang jendela waktu yang lebar. Semakin lama sebuah rahasia hidup, semakin besar kerusakan yang bisa ditimbulkan oleh satu kebocoran.

Di sinilah konsep rahasia berumur pendek (short-lived secrets) mengubah permainan. Alih-alih menyimpan kata sandi yang berlaku berbulan-bulan, Anda membuat kredensial sesuai permintaan, menggunakannya untuk tepat satu tugas, dan membiarkannya mati segera setelah selesai.

Apa yang Membuat Rahasia Menjadi Dinamis

Rahasia dinamis bukanlah nilai yang disimpan. Ia adalah kredensial yang dibuat saat seseorang membutuhkannya, dengan masa hidup yang diukur dalam menit atau detik. Ketika tugas selesai, kredensial itu lenyap. Tidak ada yang bisa menggunakannya lagi nanti.

Bayangkan skenario ini: pipeline CI Anda perlu menjalankan migrasi terhadap database PostgreSQL. Dengan rahasia statis, pipeline membaca kata sandi yang tersimpan dari vault, terhubung ke database, menjalankan migrasi, lalu memutuskan koneksi. Kata sandi itu tetap valid untuk penggunaan di masa depan. Jika seseorang mengekstraknya dari log pipeline, mereka bisa terhubung ke database kapan saja hingga rotasi berikutnya.

Diagram urutan berikut menunjukkan bagaimana alur ini bekerja:

sequenceDiagram participant CI as CI Pipeline participant V as Vault participant DB as Database CI->>V: Request DB access for migration V->>DB: Create temp user + password DB-->>V: Credentials V-->>CI: Return temp credentials CI->>DB: Run migration DB-->>CI: Migration done CI->>V: Signal task complete V->>DB: Revoke temp user DB-->>V: Confirmed

Dengan rahasia dinamis, pipeline mengirim permintaan ke vault: "Saya butuh akses database untuk migrasi ini." Vault membuat nama pengguna dan kata sandi baru, memberikan izin baca-tulis pada skema migrasi, lalu mengembalikan kredensial ke pipeline. Pipeline menggunakannya, menyelesaikan migrasi, dan vault secara otomatis mencabut kredensial tersebut. Nama pengguna dan kata sandi yang ada selama jendela lima menit itu kini mati. Bahkan jika log pipeline bocor, kredensial itu tidak berguna.

Berikut adalah tampilan permintaan vault tersebut dalam praktik:

# Request a dynamic database credential from Vault
VAULT_RESPONSE=$(vault read -format=json database/creds/migration-role)

# Extract the temporary username and password
DB_USER=$(echo "$VAULT_RESPONSE" | jq -r '.data.username')
DB_PASS=$(echo "$VAULT_RESPONSE" | jq -r '.data.password')

# Use the credential for the migration
psql "postgresql://${DB_USER}:${DB_PASS}@db.example.com:5432/production" \
  -f ./migrations/001_initial.sql

# The credential expires automatically after its TTL (e.g., 5 minutes)
# No manual revocation needed

Perbedaan Inti: Masa Hidup

Rahasia statis memiliki masa hidup panjang. Anda menyimpannya, merotasinya secara periodik, dan berharap tidak bocor di antara rotasi. Risikonya sebanding dengan masa hidup. Kata sandi yang dirotasi setiap 90 hari memberi penyerang potensi jendela 90 hari.

Rahasia dinamis memiliki masa hidup pendek. Mereka dibuat untuk tujuan spesifik dan dihancurkan saat tujuan itu selesai. Jendela eksploitasi menyusut dari berbulan-bulan menjadi hitungan menit. Jika kredensial bocor, ia sudah kedaluwarsa saat ditemukan.

Pergeseran ini mengubah cara Anda berpikir tentang manajemen rahasia. Alih-alih bertanya "siapa yang bisa membaca rahasia ini?" Anda bertanya "siapa yang bisa meminta rahasia baru?" Vault mengurus sisanya.

Bagaimana Rahasia Dinamis Mengubah Kontrol Akses

Rahasia statis memaksa Anda mengelola akses ke nilai yang disimpan. Anda mengonfigurasi siapa yang bisa membaca kata sandi tertentu, dan berharap kata sandi itu tidak disalin atau dibagikan. Jika seorang developer membutuhkan akses baca-saja ke database, Anda harus membuat kredensial statis terpisah atau memberikan kredensial yang sama dengan yang digunakan orang lain.

Rahasia dinamis memungkinkan Anda mendefinisikan kebijakan akses di tingkat permintaan. Ketika pipeline membutuhkan akses database, vault membuat kredensial dengan izin yang tepat sesuai kebutuhan pipeline tersebut. Pipeline baca-saja mendapat kredensial baca-saja. Pipeline migrasi mendapat akses tulis ke tabel tertentu. Pipeline analitik mendapat select-only pada skema tertentu.

Granularitas ini membuat audit menjadi mudah. Setiap kredensial terikat pada permintaan spesifik, pipeline spesifik, dan jendela waktu spesifik. Anda bisa melacak persis apa yang terjadi, kapan, dan dengan izin apa.

Kapan Rahasia Dinamis Tidak Cocok

Rahasia dinamis sangat kuat, tetapi bukan pengganti universal untuk rahasia statis. Beberapa situasi masih membutuhkan kredensial berumur panjang.

Aplikasi yang mempertahankan koneksi database persisten tidak bisa menggunakan kredensial yang kedaluwarsa dalam hitungan menit. Server web yang menjaga kumpulan koneksi (connection pool) tetap terbuka membutuhkan kredensial yang tetap valid selama koneksi hidup. Dalam kasus ini, Anda mungkin menggunakan rahasia statis dengan periode rotasi lebih pendek, atau menerapkan connection pooling yang bisa menyegarkan kredensial tanpa memutus koneksi aktif.

Sistem eksternal yang tidak mendukung pembuatan kredensial otomatis juga menjadi masalah. Jika Anda perlu mengautentikasi terhadap API pihak ketiga yang mengeluarkan token melalui proses registrasi manual, Anda tidak bisa menghasilkan kredensial dinamis untuknya. Anda terjebak dengan token statis, dan harus mengelola rotasinya dengan hati-hati.

Beberapa sistem lawas tidak memiliki API yang diperlukan untuk penyediaan kredensial dinamis. Jika database Anda tidak mendukung pembuatan pengguna secara terprogram, atau jika penyedia cloud Anda memerlukan pembuatan peran IAM manual, rahasia dinamis bukanlah pilihan.

Alat yang Menangani Rahasia Dinamis

HashiCorp Vault adalah alat paling umum untuk manajemen rahasia dinamis. Ia mendukung pembuatan kredensial untuk PostgreSQL, MySQL, MongoDB, AWS, GCP, dan banyak sistem lainnya. Ketika klien meminta kredensial, Vault membuatnya, menetapkan sewa (lease) dengan waktu hidup, dan secara otomatis mencabutnya saat sewa kedaluwarsa.

Alat lain seperti CyberArk Conjur dan AWS Secrets Manager juga menawarkan kemampuan rahasia dinamis, meskipun implementasinya bervariasi. Fitur utama yang harus dicari adalah pembuatan dan pencabutan kredensial otomatis tanpa intervensi manual.

Daftar Periksa Praktis Sebelum Mengadopsi Rahasia Dinamis

Sebelum Anda mengganti semua rahasia statis dengan yang dinamis, jalankan daftar periksa ini:

  • Apakah sistem target mendukung pembuatan kredensial terprogram? Periksa apakah database atau penyedia cloud Anda memiliki API untuk membuat pengguna atau peran sementara.
  • Bisakah aplikasi Anda menangani kedaluwarsa kredensial? Jika aplikasi Anda mempertahankan koneksi berumur panjang, Anda perlu strategi untuk menyegarkan kredensial tanpa memutus koneksi.
  • Apakah pipeline Anda meminta kredensial sesuai permintaan? Rahasia dinamis bekerja paling baik ketika setiap eksekusi pipeline meminta kredensialnya sendiri, bukan menggunakan kembali yang sudah di-cache.
  • Apakah infrastruktur vault Anda andal? Jika vault mati, tidak ada yang bisa meminta kredensial baru. Rencanakan ketersediaan tinggi (high availability).
  • Sudahkah Anda mengaudit pipeline mana yang benar-benar membutuhkan rahasia dinamis? Beberapa pipeline berjalan sangat jarang sehingga rahasia statis dengan periode rotasi pendek lebih sederhana dikelola.

Kesimpulan Konkret

Rahasia statis dengan masa hidup panjang menciptakan celah keamanan yang membesar setiap hari di antara rotasi. Rahasia dinamis menutup celah itu dengan membuat kredensial hanya valid selama durasi satu tugas. Imbalannya adalah kompleksitas: Anda membutuhkan vault yang mendukung penyediaan dinamis, aplikasi yang menangani kredensial berumur pendek, dan sistem yang bisa membuat pengguna sesuai permintaan. Namun untuk kredensial apa pun yang digunakan dalam pipeline otomatis atau proses berumur pendek, rahasia dinamis adalah perbedaan antara kebocoran yang berarti dan kebocoran yang tidak berarti.