Ketika Infrastruktur Berubah di Luar Pipeline: Deteksi Drift untuk Kepatuhan Kebijakan

Anda sudah menulis kebijakan. Anda sudah memiliki pemeriksaan otomatis di pipeline CI/CD. Setiap deployment melewati validasi sebelum mencapai production. Tim Anda merasa percaya diri bahwa infrastruktur mengikuti aturan.

Lalu seseorang di tim perlu melakukan debug masalah production pada jam 10 malam. Mereka login ke konsol cloud, membuka port security group ke IP rumah mereka, memperbaiki masalah, lalu tidur. Mereka lupa mengembalikan perubahan. Keesokan paginya, security group itu masih terbuka. Pipeline Anda tidak pernah tahu. Kebijakan Anda tidak pernah menangkapnya.

Skenario ini tidak jarang terjadi. Ini terjadi ketika engineer mengambil jalan pintas saat insiden, ketika tim lain membuat resource secara manual karena pipeline Anda terasa terlalu lambat, atau ketika auto-scaling meluncurkan instance baru dengan konfigurasi default yang melanggar kebijakan Anda. Semua perubahan ini terjadi di luar pipeline CI/CD Anda, sehingga pemeriksaan kebijakan yang Anda bangun dengan hati-hati di langkah plan dan apply tidak pernah melihatnya.

Apa Arti Sebenarnya Deteksi Drift

Deteksi drift adalah proses membandingkan keadaan infrastruktur aktual Anda dengan apa yang seharusnya menurut kebijakan Anda. Proses ini berjalan secara periodik—setiap jam, setiap hari, atau jadwal apa pun yang masuk akal untuk tim Anda—dan melaporkan resource mana yang menyimpang dari aturan.

Tujuannya bukan untuk mencegah perubahan. Kebijakan pipeline Anda sudah menangani itu dengan memblokir deployment yang tidak sesuai sebelum terjadi. Deteksi drift menangkap perubahan yang sudah terjadi di luar pipeline Anda. Ini adalah jaring pengaman untuk infrastruktur yang tidak bisa Anda kendalikan hanya melalui otomatisasi.

Bagaimana Deteksi Drift Bekerja dalam Praktik

Mekanismenya sederhana. Sebuah alat atau skrip memanggil API penyedia cloud Anda untuk mendaftar semua resource yang ada. Kemudian ia memeriksa setiap resource terhadap kebijakan yang Anda tetapkan satu per satu.

Berikut adalah skrip bash sederhana yang menjalankan Terraform plan dan memberi peringatan jika drift terdeteksi:

#!/bin/bash
# Skrip deteksi drift terjadwal (jalankan via cron setiap jam)
cd /path/to/terraform/project
terraform init -input=false > /dev/null 2>&1
terraform plan -detailed-exitcode -input=false -no-color > plan_output.txt 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
  echo "Drift terdeteksi pada $(date)" >> drift_alerts.log
  # Kirim notifikasi (misalnya, Slack webhook)
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"Drift terdeteksi di infrastruktur production. Periksa plan_output.txt untuk detail.\"}" \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $EXIT_CODE -eq 1 ]; then
  echo "Terraform plan gagal pada $(date)" >> drift_alerts.log
fi

Misalnya, kebijakan Anda mengatakan tidak ada security group yang boleh membuka port 22 ke 0.0.0.0/0. Deteksi drift memindai setiap security group dan menandai pelanggaran apa pun. Atau kebijakan Anda mewajibkan tag owner pada setiap resource. Deteksi drift menginventarisasi semua resource dan menandai yang tidak memiliki tag tersebut.

Hasilnya perlu disimpan di tempat yang benar-benar dilihat tim Anda. Dashboard bisa digunakan. Notifikasi Slack atau email bisa digunakan. Tiket otomatis di sistem pelacakan Anda bisa digunakan. Yang tidak berhasil adalah membuat laporan yang tidak dibaca siapa pun. Seseorang harus memiliki tanggung jawab untuk menindaklanjuti, atau deteksi drift hanya menjadi kebisingan.

Alat yang Membantu Anda Mendeteksi Drift

Beberapa alat sudah memiliki kemampuan deteksi drift. Terraform memiliki terraform plan yang dapat menunjukkan perbedaan antara file state Anda dan infrastruktur nyata. Tapi ini hanya membantu untuk resource yang dikelola melalui Terraform. Resource yang dibuat di luar Terraform memerlukan pendekatan berbeda.

Alat native cloud dapat memindai secara luas. AWS Config, Azure Policy, dan Google Cloud Asset Inventory memeriksa resource menggunakan API native mereka. Mereka memahami model resource penyedia cloud secara mendalam dan dapat memeriksa kepatuhan di seluruh akun Anda.

Opsi open source juga ada. Open Policy Agent (OPA) dapat berjalan sebagai mesin kebijakan yang Anda picu secara periodik terhadap infrastruktur Anda. Anda menulis kebijakan di Rego, dan OPA mengevaluasinya terhadap data resource yang Anda berikan.

Bagian Sulit: Apa yang Harus Dilakukan Saat Menemukan Drift

Menemukan drift hanyalah setengah dari pekerjaan. Pertanyaan yang lebih sulit adalah apa yang terjadi selanjutnya.

Laporan drift yang baik mencakup informasi yang cukup untuk memperbaiki masalah. Laporan tersebut memberi tahu Anda resource mana yang melanggar kebijakan mana dan idealnya bagaimana cara memperbaikinya. Beberapa tim melangkah lebih jauh dan menerapkan remediasi otomatis—ketika drift terdeteksi, sistem secara otomatis mengembalikan resource ke keadaan yang sesuai.

Remediasi otomatis terdengar hebat sampai berbalik merugikan Anda. Jika seorang engineer membuka port sementara saat melakukan debug insiden production, remediasi otomatis dapat menutup port tersebut saat mereka masih bekerja. Alat tersebut akan memperbaiki pelanggaran kebijakan sambil mengganggu investigasi yang sedang berlangsung. Anda perlu membedakan antara drift yang terjadi secara tidak sengaja dan drift yang terjadi dengan sengaja untuk alasan jangka pendek.

Pendekatan praktis adalah memulai dengan pemberitahuan dan remediasi manual. Biarkan tim tahu ketika drift terjadi, beri mereka detailnya, dan biarkan mereka memutuskan apakah akan memperbaikinya segera atau mendokumentasikannya sebagai pengecualian sementara. Setelah Anda memahami pola drift di lingkungan Anda, Anda dapat mempertimbangkan otomatisasi untuk kasus yang selalu salah dan tidak pernah dapat dibenarkan.

Tiga Lapisan Perlindungan

Deteksi drift melengkapi siklus penegakan kebijakan Anda. Anggap saja sebagai tiga lapisan yang saling menutupi titik buta:

Diagram di bawah mengilustrasikan bagaimana ketiga lapisan ini berinteraksi:

1. Pemeriksaan kebijakan saat plan - Mencegah pelanggaran sebelum mencapai production
2. Pemeriksaan kebijakan saat apply - Menangkap apa pun yang lolos dari perencanaan
3. Deteksi drift periodik - Menemukan perubahan yang terjadi di luar pipeline

Tidak ada satu lapisan pun yang cukup. Pemeriksaan pipeline tidak dapat menangkap perubahan manual di konsol. Deteksi drift tidak dapat mencegah pelanggaran terjadi sejak awal. Bersama-sama, mereka memberi Anda cakupan yang menjaga infrastruktur Anda tetap selaras dengan kebijakan Anda bahkan ketika hal-hal berubah di luar alur kerja otomatis Anda.

Daftar Periksa Praktis

• Pilih jadwal pemindaian drift berdasarkan seberapa cepat infrastruktur Anda berubah
• Pilih alat yang mencakup resource terkelola dan tidak terkelola di lingkungan Anda
• Kirim laporan drift ke saluran yang benar-benar dipantau tim Anda
• Tetapkan kepemilikan untuk menindaklanjuti temuan drift
• Mulai dengan remediasi manual sebelum mempertimbangkan otomatisasi
• Dokumentasikan pengecualian sementara sehingga tim Anda tahu drift mana yang disengaja

Apa Artinya Ini Bagi Tim Anda

Kebijakan Anda hanya sekuat kemampuan Anda untuk menegakkannya di mana pun infrastruktur berubah. Pemeriksaan pipeline menangani perubahan yang Anda kendalikan. Deteksi drift menangani perubahan yang tidak Anda kendalikan. Tanpa keduanya, kebijakan Anda hanyalah dokumen yang menjelaskan apa yang seharusnya benar, bukan mekanisme yang menjaganya tetap benar. Bangun deteksi drift ke dalam operasi Anda, dan infrastruktur Anda akan tetap patuh bahkan ketika hal yang tidak terduga terjadi.