Ketika Infrastruktur Berubah di Luar Pipeline: Drift, Kebijakan, dan Tata Kelola Praktis

Bayangkan ini: kamu sedang on-call jam 2 pagi. Sebuah insiden produksi sedang terjadi, dan seseorang di tim perlu membuka port security group sementara untuk melakukan debug masalah konektivitas. Mereka login ke konsol cloud, melakukan perubahan, dan insiden pun teratasi. Semua orang lega.

Tiga minggu kemudian, saat audit keamanan rutin, kamu menemukan bahwa port itu masih terbuka ke seluruh internet. Tidak ada yang ingat untuk menutupnya. Tidak ada yang mendokumentasikan perubahan itu. Dan pipeline infrastructure-as-code kamu masih menganggap security group itu terkunci.

Inilah yang disebut infrastruktur drift. Ini terjadi di setiap organisasi yang menjalankan sistem nyata. Pertanyaannya bukan apakah ini akan terjadi, tetapi bagaimana kamu menanganinya saat terjadi.

Mengapa Melarang Perubahan Manual Tidak Berhasil

Jawaban yang tampak jelas adalah: larang saja semua perubahan manual. Semuanya harus melalui pipeline. Tanpa pengecualian.

Dalam praktiknya, pendekatan ini gagal karena tiga alasan.

Pertama, keadaan darurat terjadi. Ketika sistem produksi down, menunggu pipeline yang membutuhkan waktu 15 menit tidak bisa diterima. Engineer akan mencari cara untuk melakukan perubahan secara langsung, dan mereka seharusnya bisa melakukannya.

Kedua, tidak semua perubahan sama. Menambahkan tag ke resource atau memperbarui deskripsi sangat berbeda dengan memodifikasi security group database. Memperlakukan keduanya sama menciptakan gesekan yang tidak perlu untuk perubahan berisiko rendah.

Ketiga, penegakan aturan itu sulit. Kamu tidak bisa secara fisik mencegah seseorang yang memiliki akses konsol cloud untuk mengklik tombol. Dan jika kamu menghapus akses konsol sepenuhnya, kamu menciptakan hambatan untuk troubleshooting yang sah.

Pendekatan yang lebih baik bukanlah melarang perubahan manual, tetapi mengaturnya.

Policy as Code: Aturan yang Benar-Benar Menegakkan Dirinya Sendiri

Sebagian besar organisasi memiliki kebijakan tentang perubahan infrastruktur. Biasanya tertulis di suatu dokumen: "Semua perubahan ke produksi harus melalui proses manajemen perubahan." Tapi dokumen tidak menegakkan apa pun. Mereka hanya ada di sana.

Policy as code mengubah ini. Alat seperti Open Policy Agent (OPA) atau HashiCorp Sentinel memungkinkanmu menulis aturan dalam kode dan menempelkannya ke titik-titik penegakan. Ketika seseorang mencoba memodifikasi resource melalui konsol cloud, atau ketika panggilan API masuk secara langsung, mesin kebijakan mengevaluasi permintaan terhadap aturanmu sebelum mengizinkannya.

Berikut contoh konkretnya. Kamu menulis kebijakan yang mengatakan: "Tidak ada security group yang boleh membuka port 22 ke 0.0.0.0/0 kecuali perubahan datang melalui pipeline yang disetujui." Ketika seorang engineer, panik saat insiden, mencoba membuka SSH ke dunia dari konsol AWS, kebijakan memblokir perubahan tersebut. Atau setidaknya, mencatat percobaan dan memerlukan persetujuan tambahan.

Sebagai contoh, berikut adalah kebijakan HashiCorp Sentinel yang mewajibkan setiap resource memiliki tag managed-by, memastikan perubahan di luar pipeline dapat dilacak:

# Mewajibkan semua resource memiliki tag "managed-by"
import "tfplan/v2" as tfplan

# Ambil semua resource yang akan dibuat atau diperbarui
all_resources = tfplan.resource_changes.all

# Aturan: setiap resource harus memiliki tag "managed-by"
mandatory_tag = "managed-by"

main = rule {
  all all_resources as _, rc {
    rc.applied.tags[mandatory_tag] else null != null
  }
}

Kebijakan ini terintegrasi ke dalam pipeline CI/CD-mu sebagai pengaman. Jika resource di-deploy tanpa tag, pipeline gagal, mencegah perubahan yang tidak terlacak mencapai produksi.

Pendekatan ini memberimu dua hal. Pertama, batasan yang jelas yang tidak bergantung pada disiplin manusia. Kedua, jejak audit otomatis. Setiap keputusan kebijakan dicatat: siapa yang mencoba mengubah apa, kapan, dari mana, dan apakah diizinkan atau ditolak.

Mendesain Kebijakan yang Tidak Gagal Saat Tekanan

Kesalahan umum adalah membuat kebijakan terlalu kaku. Jika kebijakanmu memblokir setiap perubahan manual tanpa pengecualian, kamu akan menciptakan situasi di mana engineer mencari cara untuk menghindarinya sama sekali. Atau lebih buruk lagi, mereka akan takut bertindak saat keadaan darurat nyata.

Solusinya adalah mendesain kebijakan dengan mempertimbangkan realitas operasional.

Satu pola adalah mekanisme break-glass. Dalam situasi darurat tertentu yang telah ditentukan, seorang engineer dapat mengesampingkan kebijakan. Pengesampingan dicatat dengan alasan, dan setelah insiden, tim meninjau apakah perubahan tersebut harus diadopsi ke dalam IaC atau di-rollback. Ini memberimu keamanan tanpa kelumpuhan.

Pola lainnya adalah mengklasifikasikan perubahan berdasarkan risiko. Perubahan berisiko rendah seperti menambahkan tag, memperbarui deskripsi, atau memodifikasi konfigurasi non-kritis dapat diizinkan dengan bebas. Perubahan berisiko tinggi seperti memodifikasi akses jaringan, kebijakan keamanan, atau konfigurasi database harus melalui pipeline. Mesin kebijakan menegakkan perbedaan ini secara otomatis, sehingga kamu tidak perlu manusia untuk memutuskan setiap saat.

Menghubungkan Kebijakan dengan Deteksi Drift

Kebijakan dan deteksi drift bekerja paling baik ketika terhubung. Berikut alurnya dalam praktik.

Pemindai drift-mu berjalan secara teratur dan menemukan perbedaan antara definisi IaC dan infrastruktur aktual. Alih-alih menandai setiap perbedaan sebagai masalah, sistem memeriksa setiap perbedaan terhadap kebijakanmu.

Diagram berikut mengilustrasikan bagaimana penegakan kebijakan dan deteksi drift berinteraksi dalam loop tata kelola yang berkelanjutan.

flowchart TD A[IaC Pipeline] -->|Deploy| B[Infrastruktur] C[Perubahan Manual] -->|Darurat atau aksi langsung| B B -->|Pemindai Drift| D{Drift Terdeteksi?} D -->|Ya| E[Mesin Kebijakan] D -->|Tidak| F[Tidak Ada Tindakan] E --> G{Pemeriksaan Kebijakan} G -->|Pengecualian Disetujui| H[Tandai sebagai Diketahui & Diizinkan] G -->|Pelanggaran| I[Tandai untuk Perbaikan] G -->|Tidak Cocok| J[Antre untuk Tinjauan Manual] H --> K[Tinjauan Pasca-Insiden] I --> K J --> K K -->|Adopsi ke IaC| A K -->|Rollback| B

Jika perubahan dilakukan melalui pengecualian kebijakan yang disetujui, itu ditandai sebagai "diketahui dan diizinkan". Jika perubahan melanggar kebijakan, itu ditandai untuk perbaikan segera. Jika perubahan tidak cocok dengan aturan kebijakan mana pun, itu masuk ke antrean untuk tinjauan manual.

Ini mengubah cara timmu melihat drift. Drift tidak lagi sekadar kesalahan yang harus diperbaiki. Itu adalah sinyal yang harus diinterpretasikan. Apakah ini perubahan darurat yang sah yang belum diadopsi ke dalam kode? Apakah ini pelanggaran kebijakan? Apakah ini perubahan yang seharusnya melalui pipeline tetapi tidak?

Dengan kebijakan dan tata kelola yang ada, kamu dapat membedakan kasus-kasus ini tanpa menyelidiki masing-masing secara manual. Dan karena kebijakan ditulis sebagai kode, mereka dapat ditinjau, diberi versi, dan diuji seperti kode lainnya. Mereka bukan dokumen berdebu di folder bersama.

Daftar Periksa Praktis untuk Tata Kelola Berbasis Kebijakan

Jika kamu menyiapkan kebijakan dan tata kelola untuk perubahan infrastruktur, berikut daftar periksa singkat untuk dikerjakan:

  • Identifikasi jenis perubahan yang paling berisiko di lingkunganmu (security group, konfigurasi database, peran IAM)
  • Tulis kebijakan yang memblokir perubahan tersebut di luar pipeline, dengan jalur pengecualian yang jelas
  • Terapkan mekanisme break-glass untuk keadaan darurat, dengan tinjauan pasca-insiden yang wajib
  • Hubungkan mesin kebijakanmu ke alat deteksi drift
  • Klasifikasikan perubahan berdasarkan tingkat risiko dan terapkan aturan yang berbeda sesuai
  • Siapkan pencatatan audit otomatis untuk setiap keputusan kebijakan
  • Tinjau pengecualian kebijakan secara teratur dan adopsi ke dalam IaC atau rollback

Intisari

Infrastruktur drift bukanlah masalah yang kamu selesaikan sekali. Ini adalah kondisi yang kamu kelola secara berkelanjutan. Tujuannya bukan untuk menghilangkan semua perubahan manual, tetapi untuk mengetahuinya, mengaturnya, dan memutuskan mana yang harus menjadi bagian permanen dari infrastrukturmu.

Policy as code memberimu cara untuk menegakkan batasan tanpa menghalangi pekerjaan yang sah. Deteksi drift memberimu visibilitas ke apa yang sebenarnya terjadi. Bersama-sama, mereka mengubah manajemen infrastruktur dari pertarungan reaktif menjadi sistem yang dapat kamu percayai, bahkan ketika sesuatu berjalan salah pada jam 2 pagi.