Rotasi Secret: Kenapa, Kapan, dan Cara Melakukannya Tanpa Merusak Sistem

Secret Anda sudah aman tersimpan di vault. Pipeline Anda menyuntikkannya saat deploy. Semua terlihat kokoh. Tapi ada masalah yang mungkin belum Anda pertimbangkan: secret yang sama, digunakan berbulan-bulan atau bertahun-tahun, adalah bom waktu.

Bayangkan seorang developer tidak sengaja menyertakan API key dalam screenshot saat presentasi perusahaan. Atau file log dari enam bulan lalu masih berisi password database, dan seseorang dengan akses tidak sah menemukannya. Semakin lama sebuah secret hidup, semakin tinggi kemungkinan bocor tanpa Anda sadari. Rotasi adalah jaring pengaman Anda: jika secret bocor, masa pakainya sudah berakhir sebelum kebocoran bisa dieksploitasi.

Kenapa Harus Rotasi Secret?

Alasan paling mendasar untuk rotasi adalah memperkecil jendela kerentanan. Jika API key berlaku selama setahun dan bocor di bulan ketiga, penyerang memiliki akses selama sembilan bulan. Tapi jika Anda merotasi key itu setiap minggu, jendela kerusakan maksimal hanya tujuh hari.

Rotasi juga penting untuk kepatuhan. Standar seperti PCI DSS dan SOC 2 mewajibkan rotasi secret secara berkala. Tapi bahkan tanpa tekanan regulasi, rotasi adalah mekanisme pertahanan praktis. Ini membatasi radius ledakan, memaksa Anda memverifikasi bahwa pipeline manajemen secret benar-benar berfungsi, dan membangun memori otot operasional untuk menangani perubahan kredensial dalam kondisi tenang, bukan saat insiden.

Kapan Harus Rotasi?

Ada tiga skenario utama yang memicu rotasi.

Rotasi terjadwal. Ini adalah siklus rutin yang dapat diprediksi. Setiap 30, 60, atau 90 hari, tergantung sensitivitas secret. Password database untuk sistem produksi mungkin dirotasi setiap 30 hari. API key internal yang kurang kritis mungkin dirotasi setiap 90 hari. Jadwal harus sesuai dengan profil risiko dari apa yang dilindungi secret tersebut.

Rotasi karena insiden. Sesuatu terjadi. Mungkin Anda melihat akses mencurigakan di log audit. Mungkin secret muncul di repositori GitHub publik. Mungkin laptop seorang karyawan disusupi. Dalam kasus ini, rotasi segera. Jangan menunggu jadwal berikutnya. Kecepatan lebih penting daripada formalitas.

Perubahan personel. Ketika seseorang yang memiliki akses ke secret keluar dari tim, berganti peran, atau dipecat, rotasi semua secret yang mungkin mereka akses. Ini bukan soal kepercayaan. Ini tentang menghilangkan kemungkinan bahwa kredensial yang mereka hafal, simpan secara lokal, atau tulis di suatu tempat masih valid setelah akses mereka seharusnya berakhir.

Cara Rotasi Tanpa Merusak Aplikasi

Inilah bagian sulitnya. Jika Anda merotasi password database dan semua layanan tiba-tiba kehilangan koneksi, Anda malah memperburuk keadaan. Tujuannya adalah rotasi tanpa downtime. Strategi paling andal adalah rotasi secret ganda, juga disebut rotasi dengan masa transisi.

Rotasi Secret Ganda

Idenya sederhana: aplikasi Anda menerima dua secret yang valid secara bersamaan selama masa transisi. Berikut langkah-langkahnya:

Diagram urutan berikut mengilustrasikan proses rotasi secret ganda di vault, layanan konfigurasi, dan beberapa instance aplikasi:

Berikut cara implementasinya dengan HashiCorp Vault dan file konfigurasi JSON:

# Langkah 1: Generate versi secret baru (pertahankan yang lama)
vault kv put secret/db-password \
  old_password="$(vault kv get -field=password secret/db-password)" \
  new_password="$(openssl rand -base64 32)"

# Langkah 2: Update konfigurasi aplikasi dengan kedua secret
cat > /etc/myapp/config.json <<EOF
{
  "db": {
    "old_password": "$(vault kv get -field=old_password secret/db-password)",
    "new_password": "$(vault kv get -field=new_password secret/db-password)"
  }
}
EOF

# Langkah 3: Reload aplikasi untuk mengambil konfigurasi baru
systemctl reload myapp

# Langkah 4: Setelah semua instance menggunakan secret baru, hapus yang lama
vault kv patch secret/db-password old_password=""

# Langkah 5: Update konfigurasi hanya menggunakan secret baru
cat > /etc/myapp/config.json <<EOF
{
  "db": {
    "password": "$(vault kv get -field=new_password secret/db-password)"
  }
}
EOF
systemctl reload myapp
sequenceDiagram participant Vault participant Config participant ServiceA participant ServiceB Note over Vault,ServiceB: Langkah 1: Generate secret baru Vault->>Vault: Generate secret baru (pertahankan yang lama) Note over Vault,ServiceB: Langkah 2: Deploy secret baru ke semua layanan Vault->>Config: Berikan secret lama + baru Config->>ServiceA: Update konfigurasi (kedua secret valid) Config->>ServiceB: Update konfigurasi (kedua secret valid) Note over Vault,ServiceB: Langkah 3: Verifikasi semua layanan menggunakan secret baru ServiceA->>Vault: Koneksi menggunakan secret baru ServiceB->>Vault: Koneksi menggunakan secret baru Note over Vault,ServiceB: Langkah 4: Nonaktifkan secret lama Vault->>Config: Tandai secret lama sebagai tidak valid Config->>ServiceA: Hapus secret lama dari konfigurasi Config->>ServiceB: Hapus secret lama dari konfigurasi Note over Vault,ServiceB: Langkah 5: Hapus secret lama dari vault Vault->>Vault: Hapus secret lama
  1. Generate secret baru di vault atau penyimpanan secret Anda. Jangan hapus yang lama.
  2. Update konfigurasi aplikasi sehingga mengetahui bahwa secret lama dan baru sama-sama valid.
  3. Deploy konfigurasi yang sudah diperbarui. Semua instance yang berjalan sekarang menerima kedua secret.
  4. Tunggu hingga setiap instance mengambil konfigurasi baru dan menggunakan secret baru.
  5. Hapus secret lama dari konfigurasi dan deploy lagi.

Selama proses ini, aplikasi Anda tidak pernah kehilangan konektivitas. Jika instance belum menerima konfigurasi baru, instance tetap berfungsi dengan secret lama. Setelah menerima pembaruan, instance bisa menggunakan salah satunya. Setelah secret lama dihapus, hanya secret baru yang berfungsi.

Pendekatan ini cocok untuk secret yang dikonsumsi langsung oleh aplikasi: password database, API key, token antar-layanan. Syarat utamanya adalah kode aplikasi atau middleware Anda mendukung beberapa kredensial valid secara bersamaan. Sebagian besar driver database modern dan HTTP client bisa menangani ini.

Koordinasi Rotasi di Beberapa Layanan

Ketika sebuah secret digunakan bersama oleh banyak layanan, rotasi menjadi lebih kompleks. Bayangkan password database yang digunakan oleh sepuluh microservice. Anda tidak bisa merotasinya satu per satu tanpa koordinasi. Jika service A beralih ke password baru sementara service B masih menggunakan yang lama, dan database hanya menerima password baru, service B akan rusak.

Salah satu solusinya adalah menggunakan service mesh atau sidecar proxy yang mengelola koneksi database secara terpusat. Sidecar menangani autentikasi ke database. Layanan Anda terhubung ke sidecar, bukan langsung ke database. Saat Anda merotasi password database, Anda hanya perlu memperbarui konfigurasi sidecar. Layanan tidak perlu tahu bahwa rotasi terjadi.

Pendekatan lain adalah menggunakan sistem secret dinamis, yang akan kita bahas sebentar lagi. Tapi untuk secret statis yang digunakan bersama banyak konsumen, service mesh atau connection pooler khusus adalah pola yang paling praktis.

Hal Lain yang Penting dalam Rotasi

Rotasi bukan hanya tentang mengubah nilai. Ini adalah proses yang membutuhkan praktik pendukung.

Audit logging. Setiap rotasi harus dicatat. Siapa yang memicu, kapan, secret mana yang dirotasi, dan apa hasilnya. Ini penting untuk investigasi insiden dan audit kepatuhan.

Uji di staging terlebih dahulu. Jangan pernah merotasi secret produksi tanpa memverifikasi proses di lingkungan staging. Staging harus mencerminkan pola konsumsi secret produksi. Jika rotasi merusak sesuatu, Anda ingin itu rusak di staging, bukan produksi.

Miliki rencana rollback. Terkadang rotasi menyebabkan masalah tak terduga. Mungkin secret baru tidak menyebar dengan benar. Mungkin layanan gagal mengambil perubahan konfigurasi. Prosedur rotasi Anda harus mencakup cara untuk kembali ke secret lama dengan cepat. Ini berarti menjaga secret lama tetap valid sampai Anda yakin secret baru berfungsi di semua tempat.

Checklist Praktis untuk Rotasi Secret

  • Identifikasi secret mana yang perlu dirotasi dan tingkat risikonya
  • Tentukan jadwal rotasi berdasarkan risiko (30/60/90 hari)
  • Implementasikan dukungan secret ganda di kode aplikasi atau middleware
  • Uji prosedur rotasi di lingkungan staging
  • Dokumentasikan langkah rollback sebelum merotasi secret produksi
  • Catat setiap rotasi dengan timestamp, operator, dan hasil
  • Otomatiskan rotasi terjadwal jika memungkinkan
  • Tetapkan proses respons insiden untuk rotasi darurat

Kesimpulan

Secret yang tidak pernah berubah adalah kerentanan yang menunggu untuk dieksploitasi. Rotasi membatasi jendela kerusakan, memenuhi persyaratan kepatuhan, dan memaksa Anda menjaga praktik manajemen secret tetap tajam. Pola secret ganda memberi Anda cara aman untuk rotasi tanpa downtime. Tapi rotasi hanya sebagian dari gambaran. Pertanyaan selanjutnya adalah apakah Anda bisa beralih dari secret statis sepenuhnya, ke secret yang kedaluwarsa secara otomatis setelah sekali pakai. Di situlah secret dinamis berperan.