28-3 · Bab 28 · 5 menit baca

Mengapa Aturan Infrastruktur Harus Ditulis Sebagai Kode

Pelajari mengapa kebijakan infrastruktur seperti larangan SSH ke internet harus ditulis sebagai kode, bukan dokumen. Panduan praktis dengan OPA dan Sentinel untuk CI/CD.

Mengapa Aturan Infrastruktur Harus Ditulis Sebagai Kode

Tim Anda punya kebijakan: tidak ada security group yang boleh membuka SSH (port 22) ke seluruh internet. Semua setuju. Sudah ada di dokumentasi. Bahkan ada yang mencetaknya dan menempelkannya di dinding.

Lalu, suatu Jumat sore, seorang developer membuat security group baru untuk pengujian cepat. Mereka mengatur CIDR block ke 0.0.0.0/0 pada port 22 karena hanya ingin menguji sesuatu dengan cepat. Perubahan itu lolos. Tidak ada yang menyadarinya sampai Senin pagi ketika tim keamanan mengirimkan peringatan tentang port SSH yang terekspos.

Skenario ini terulang di berbagai tim setiap minggu. Bukan karena orang-orang ceroboh, tetapi karena penegakan kebijakan manual tidak bisa diskalakan. Ketika perubahan infrastruktur terjadi berkali-kali dalam sehari, mengandalkan ingatan manusia atau aturan berbasis dokumen adalah resep untuk celah keamanan.

Masalah dengan Kebijakan Berbasis Dokumen

Sebagian besar tim memulai dengan kebijakan yang disimpan dalam dokumen. Google Doc, halaman Confluence, atau PDF yang ada di drive bersama. Dokumen-dokumen ini menjelaskan apa yang boleh dan tidak boleh terjadi: "Semua bucket S3 harus dienkripsi," "Hanya AMI yang disetujui yang boleh digunakan," "Setiap resource harus memiliki tag cost center."

Masalahnya, dokumen tidak menegakkan apa pun. Mereka menjelaskan niat, tetapi tidak mengeksekusi. Ketika seseorang membuat perubahan yang melanggar kebijakan, dokumen tidak menghentikannya. Dokumen hanya diam saja, menunggu seseorang ingat untuk memeriksanya.

Dokumen juga bisa melenceng. Seseorang memperbarui kebijakan, tetapi versi lama tetap tersimpan di bookmark seseorang. Atau tim bertambah, dan anggota baru tidak tahu dokumen itu ada. Seiring waktu, kesenjangan antara apa yang didokumentasikan dan apa yang benar-benar digunakan semakin melebar.

Arti Menulis Kebijakan sebagai Kode

Policy as code berarti mengambil aturan-aturan tersebut dan menulisnya dalam format yang bisa dibaca dan dieksekusi oleh mesin. Alih-alih dokumen yang mengatakan "jangan buka SSH ke publik," Anda menulis aturan yang secara otomatis memeriksa setiap perubahan infrastruktur terhadap batasan tersebut.

Kebijakan hidup dalam sebuah file, sama seperti kode aplikasi Anda. File tersebut melalui version control. Direview dalam pull request. Bisa diuji, diperbarui, dan di-rollback. Ketika seseorang mengusulkan perubahan yang melanggar kebijakan, pipeline akan menangkapnya sebelum resource dibuat.

Pergeseran dari dokumen ke kode ini mengubah cara tim berinteraksi dengan aturan. Kebijakan menjadi bagian dari alur kerja engineering, bukan sesuatu yang dipikirkan belakangan saat audit.

Contoh Konkret dengan Open Policy Agent

Mari kita buat ini lebih nyata. Open Policy Agent (OPA) adalah alat populer untuk menulis policy as code. OPA menggunakan bahasa bernama Rego. Berikut adalah contoh kebijakan sederhana yang memblokir akses SSH dari mana saja:

deny if {
    input.resource.type == "aws_security_group_rule"
    "0.0.0.0/0" in input.resource.cidr_blocks
    input.resource.port == 22
}

Aturan ini mengatakan: jika seseorang mencoba membuat security group rule yang membuka port 22 ke semua alamat IP, tandai sebagai ditolak. File kebijakan berada di repositori Anda. Ketika ada pull request yang menambahkan security group rule, pipeline CI menjalankan OPA terhadap perubahan yang diusulkan. Jika aturan cocok, pipeline gagal, dan developer mendapatkan umpan balik langsung.

Anda juga bisa menulis kebalikannya: aturan yang hanya mengizinkan CIDR block tertentu untuk akses SSH:

allow if {
    input.resource.type == "aws_security_group_rule"
    input.resource.cidr_blocks[_] != "0.0.0.0/0"
}

Sintaksis persisnya tergantung pada alat dan bahasa kebijakan Anda, tetapi polanya sama: aturan adalah kode, dan kode berjalan secara otomatis.

Pendekatan Lain: Sentinel untuk Pengguna Terraform

Jika tim Anda banyak menggunakan Terraform, Sentinel dari HashiCorp menawarkan integrasi yang lebih erat. Kebijakan Sentinel ditulis khusus untuk konteks eksekusi Terraform. Berikut adalah pembatasan SSH yang sama dalam Sentinel:

import "tfplan"

allowed_cidrs = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]

main = rule {
    all tfplan.resource_changes as _, change {
        change.type is "aws_security_group_rule" implies
        change.change.after.cidr_blocks all allowed_cidrs
    }
}

Kebijakan ini memeriksa bahwa setiap security group rule hanya menggunakan rentang IP privat. Jika seseorang mencoba menggunakan CIDR block publik, kebijakan akan memblokir perubahan tersebut.

Perbedaan antara OPA dan Sentinel sebagian besar terletak pada ekosistem. OPA bersifat general-purpose dan bekerja dengan banyak alat selain Terraform. Sentinel terintegrasi secara mendalam dengan produk HashiCorp, yang membuat pengaturannya lebih sederhana jika Anda sudah berada di ekosistem tersebut. Namun, ide intinya identik: kebijakan adalah kode yang berjalan di pipeline Anda.

Di Mana Menyimpan File Kebijakan Anda

Ada dua opsi utama untuk menyimpan file kebijakan:

Di repositori yang sama dengan kode infrastruktur Anda. Ini menjaga kebijakan tetap dekat dengan resource yang diaturnya. Ketika seseorang memodifikasi infrastruktur, mereka melihat kebijakan yang relevan di pull request yang sama. Ini cocok untuk kebijakan khusus tim.

Di repositori kebijakan khusus. Ini memusatkan semua kebijakan di seluruh organisasi. Tim platform memelihara repositori tersebut, dan beberapa repositori infrastruktur mengambil kebijakan darinya. Ini lebih baik untuk aturan kepatuhan di tingkat organisasi yang tidak boleh berbeda antar tim.

Kedua pendekatan valid. Mulailah dengan pendekatan repositori yang sama jika Anda baru mengenal policy as code. Beralihlah ke repositori khusus ketika Anda perlu menegakkan kebijakan secara konsisten di beberapa tim.

Daftar Periksa Praktis untuk Memulai

Sebelum Anda mulai menulis kebijakan, jalankan daftar periksa singkat ini:

Identifikasi tiga kebijakan yang paling sering dilanggar. Jangan mencoba mengkodifikasi semuanya sekaligus. Pilih aturan yang paling banyak menyebabkan masalah atau risiko.
Pilih satu alat. Mulailah dengan OPA jika Anda menginginkan fleksibilitas di berbagai alat. Mulailah dengan Sentinel jika Anda sudah sangat bergantung pada Terraform.
Tulis satu kebijakan dan uji secara manual. Jalankan terhadap pelanggaran yang diketahui untuk memastikan kebijakan tersebut menangkap masalah.
Tambahkan pemeriksaan kebijakan ke pipeline CI Anda. Buat agar pemeriksaan tersebut memblokir build, bukan hanya memberi peringatan. Peringatan sering diabaikan.
Tinjau dan ulangi. Setelah seminggu, periksa apakah kebijakan menangkap sesuatu yang tidak terduga. Sesuaikan false positive.

Nilai Sebenarnya Ada pada Alur Kerja

Alat yang Anda pilih tidak terlalu penting dibandingkan alur kerja yang Anda adopsi. Ketika kebijakan adalah kode, kebijakan mendapat perlakuan yang sama seperti kode aplikasi. Kebijakan direview, diuji, diberi versi, dan ditingkatkan seiring waktu. Ketika sebuah kebijakan menyebabkan false positive, seseorang membuka pull request untuk memperbaikinya. Ketika persyaratan kepatuhan baru masuk, seseorang menulis aturan baru dan mengirimkannya melalui pipeline yang sama.

Alur kerja ini menghilangkan kesenjangan antara niat kebijakan dan penegakan yang sebenarnya. Aturan yang mengatakan "jangan buka SSH ke publik" tidak lagi menjadi dokumen yang mungkin terlupa untuk diperiksa. Aturan itu adalah baris kode yang berjalan setiap kali infrastruktur berubah. Itulah perbedaan antara berharap tim Anda mengikuti aturan dan mengetahui bahwa mereka benar-benar melakukannya.