Rotasi Kredensial Otomatis: Strategi yang Tahan Audit

Setiap musim audit, pertanyaan yang sama selalu muncul di daftar periksa: kapan terakhir kali kredensial ini dirotasi, dan siapa saja yang punya akses ke sana hari ini. Kalau jawaban jujurnya adalah angkat bahu dan spreadsheet yang tidak pernah dibuka sejak onboarding, kredensial itu sebenarnya tidak benar-benar terkendali. Ia hanya diam saja.

Tulisan ini menjabarkan strategi rotasi yang dibangun di atas tiga gagasan: utamakan kredensial yang kedaluwarsa dengan sendirinya, utamakan pembuatan kredensial sesuai permintaan daripada menyimpannya, dan jangan pernah membalik rotasi dalam satu langkah atomik yang berisiko menyebabkan gangguan layanan. Kalau tiga hal itu beres, audit menjadi formalitas, bukan pemadam kebakaran.

Mengapa secret statis selalu gagal saat audit

Secret statis adalah kredensial apa pun yang dibuat sekali lalu dipakai terus sampai ada yang ingat untuk menggantinya. Kata sandi database yang diketik ke file environment, kunci API yang ditempel ke pipeline deploy bertahun-tahun lalu, kunci akun layanan yang diunduh sekali lalu terlupakan. Semuanya gagal audit karena alasan yang sama dan bisa ditebak, dan kerangka kerja seperti SOC 2 serta PCI-DSS secara eksplisit meminta bukti kadensa rotasi kredensial, bukan sekadar pernyataan kebijakan di atas kertas.

• Tidak ada yang bisa membuktikan kapan terakhir dirotasi, karena rotasi adalah langkah manual yang harus diingat dan dijalankan seseorang.
• Radius dampak kebocoran tidak terbatas waktu. Kunci yang dicuri dari backup laptop dua tahun lalu masih valid hari ini kalau tidak ada yang memaksanya kedaluwarsa.
• Mencabut satu secret statis biasanya berarti mengubah konfigurasi di banyak layanan secara manual, dan itu justru jenis perubahan yang paling tidak diinginkan siapa pun saat harus dilakukan di bawah tekanan ketika insiden sedang terjadi.

Secret berumur pendek dan dinamis mengubah kebiasaan default

Secret dinamis membalik modelnya. Alih-alih menyimpan satu kata sandi dan membagikannya ke semua konsumen, mesin secret seperti database secrets engine milik HashiCorp Vault membuat kredensial baru yang unik untuk setiap permintaan, lengkap dengan lease dan time-to-live yang sudah tertanam. Tidak ada yang perlu ingat untuk merotasinya, karena kredensial itu memang tidak dirancang untuk hidup lebih lama dari lease-nya.

# Enable the database secrets engine
vault secrets enable database

# Configure the connection with a rotating root credential
vault write database/config/orders-pg \
  plugin_name="postgresql-database-plugin" \
  connection_url="postgresql://{{username}}:{{password}}@pg-primary:5432/orders" \
  allowed_roles="orders-readwrite" \
  username="vault-admin" \
  password="initial-bootstrap-password"

# Define a role with a short TTL
vault write database/roles/orders-readwrite \
  db_name="orders-pg" \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
    VALID UNTIL '{{expiration}}'; GRANT SELECT, INSERT, UPDATE ON ALL TABLES \
    IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="4h"

# An app now requests a lease, not a password
vault read database/creds/orders-readwrite

Kredensial pada contoh di atas kedaluwarsa otomatis setelah satu jam, dan Vault langsung mencabutnya kalau lease tidak diperpanjang. Kalau bocor dari file log atau crash dump, umur kebocorannya terhitung menit, bukan bulan. Aplikasi meminta lease saat memulai satu unit kerja, bukan sekali saja saat boot, yang juga berarti kredensial yang bocor hanya memberi akses selama jendela waktu yang benar-benar dibutuhkan.

Pola dua-secret untuk cutover tanpa downtime

Bahkan di tempat secret dinamis tidak praktis diterapkan, misalnya akun layanan bersama yang dipakai puluhan worker berumur panjang, rotasi tetap bisa dilakukan dengan aman lewat pola dua-secret. AWS Secrets Manager meresmikan pola ini dengan label staging: kredensial aktif diberi label current, kredensial baru yang baru dibuat diberi label pending, dan keduanya tetap valid bersamaan selama jendela masa tenggang. Biaya menjaga dua akun tetap hidup sebentar jauh lebih murah dibanding biaya deployment yang gagal jam tiga pagi karena kata sandi dirotasi tepat saat layanan masih berjalan memakainya.

Menjalankan cutover tanpa mematahkan konsumen

Mekanisme cutover yang aman sama saja baik saat merotasi kata sandi database maupun kunci API eksternal. Ikuti urutan ini setiap kali.

1. Buat secret baru berdampingan dengan yang lama, jangan pernah menggantikannya langsung, sehingga keduanya tetap valid secara bersamaan.
2. Perbarui setiap layanan konsumen agar membaca secret baru, tetapi biarkan yang lama tetap aktif di sistem latar yang menjadi tujuan autentikasinya.
3. Pantau log autentikasi dan tingkat error selama satu siklus deployment penuh untuk memastikan setiap konsumen, termasuk pod paling lambat atau cache paling basi, sudah memakai nilai baru.
4. Baru setelah itu cabut secret lama, dan pastikan proses pencabutan itu sendiri berjalan lewat skrip serta tercatat, sehingga jejak audit menunjukkan dengan jelas kapan akses dihentikan.

Mendeteksi secret yang bocor sebelum penyerang memakainya

Strategi rotasi hanya menutup separuh lingkaran. Separuh lainnya adalah menangkap kredensial yang bocor sebelum jadwal rotasi berikutnya sempat berjalan. Secret yang ter-commit ke repositori publik, ditempel ke tiket dukungan, atau tercatat dalam bentuk teks polos oleh handler yang salah konfigurasi, harus tertangkap dalam hitungan menit, bukan menunggu rotasi terjadwal berikutnya. Repositori publik khususnya terus-menerus dipindai oleh bot otomatis yang mencari kesalahan semacam ini, sehingga jendela waktu antara sebuah commit dan eksploitasi yang benar-benar berfungsi bisa lebih singkat daripada waktu yang dibutuhkan reviewer manusia untuk menyadari pull request itu.

• Jalankan pemindai secret seperti TruffleHog secara terus-menerus di continuous integration pada setiap pull request, sehingga kredensial tidak pernah sampai masuk ke branch utama sejak awal.
• Aktifkan push protection di level platform sehingga commit yang mengandung pola kredensial yang dikenali diblokir sebelum sempat sampai ke repositori remote.
• Utamakan pemindai yang secara aktif memverifikasi temuan langsung ke API milik penyedia layanan, bukan sekadar mencocokkan pola, sehingga sebuah peringatan berarti kredensial yang benar-benar hidup, bukan gangguan sinyal palsu.
• Hubungkan langsung temuan pemindai ke kanal insiden dengan runbook pencabutan-dan-rotasi otomatis, karena nilai deteksi cepat akan hilang percuma kalau manusia masih harus menyadari peringatan itu lebih dulu.

Apa yang sebenarnya ingin dilihat auditor

Ketika strategi rotasi dirancang dengan baik, percakapan audit menjadi singkat. Auditor tidak mencari kesempurnaan, mereka mencari bukti bahwa organisasi bisa menjawab pertanyaan dasar tentang kredensial apa pun kapan saja diminta.

• Jadwal rotasi dan kebijakan TTL untuk setiap jenis secret, didukung oleh log otomasi, bukan halaman wiki yang lupa diperbarui.
• Runbook cutover yang terbukti dijalankan menunjukkan pola dua-secret benar-benar dipraktikkan, bukan sekadar didokumentasikan sebagai niat.
• Catatan setiap peringatan pemindai dari periode audit terakhir beserta jeda waktu antara deteksi dan pencabutan untuk masing-masing kasus.

Semua ini tidak memerlukan perkakas yang eksotis. Yang dibutuhkan hanyalah menjadikan kredensial berumur pendek sebagai default, memperlakukan rotasi sebagai cutover dua langkah yang terskrip alih-alih satu peralihan berisiko, dan menutup celah waktu antara terjadinya kebocoran dan saat seseorang benar-benar mencabutnya. Lakukan tiga hal itu secara konsisten, dan audit berikutnya menjadi laporan yang sudah kamu miliki, bukan proyek yang harus dimulai dari nol.