Apa itu kebijakan sebagai kode (PaC)?

Alih-alih mengandalkan manusia untuk memeriksa kepatuhan atau mengingat aturan keamanan, aturan tersebut ada sebagai logika yang dapat dieksekusi dan dijalankan setiap kali pengembang atau sistem mengusulkan perubahan atau permintaan. Jika seseorang mengajukan perubahan, mesin kebijakan secara otomatis mengevaluasi perubahan tersebut berdasarkan aturan yang dikodekan, serta mengizinkan, menolak, atau menandainya.

Proses ini mengubah praktik manajemen kebijakan dari dokumen statis menjadi permukaan kontrol yang dinamis dan terus menerus diterapkan yang tertanam dalam delivery pipeline.

Aturan berbasis kode membantu memastikan bahwa kebijakan yang sama diterapkan di mana-mana, dengan cara yang dapat diulang dan dapat diskalakan. Mesin kebijakan dapat menjalankan pemeriksaan otomatis dalam hitungan detik selama proses pengembangan atau penerapan, memperpendek siklus masukan, dan membantu tim DevOps menghindari kejutan keamanan atau kepatuhan di tahap akhir.

PaC memungkinkan perusahaan untuk meningkatkan postur keamanan siber mereka secara keseluruhan dan mempertahankan kepatuhan terhadap standar industri dan peraturan. Selain itu, memperlakukan kebijakan seperti kode sejalan dengan transisi “everything as code” yang lebih luas, yang mengubah hal-hal seperti permintaan infrastruktur menjadi file kode yang dapat ditinjau di mana tim pengembangan dapat berkolaborasi.

Dalam istilah DevOps, kebijakan adalah aturan yang jelas dan dapat ditegakkan tentang bagaimana infrastruktur dan aplikasi TI harus dikonfigurasi, diakses, atau dijalankan. Lebih tepatnya, kebijakan menentukan tindakan apa yang diizinkan, diperlukan atau dilarang sehingga sistem tetap berjalan dalam keadaan ideal mereka. 

Sebagai contoh, “semua bucket penyimpanan harus dienkripsi” atau “tidak ada layanan publik yang dapat mengekspos port 22" adalah kebijakan, karena keduanya menentukan batasan konkret pada perilaku sistem.

Dengan PaC, kebijakan ditulis dalam bahasa pemrograman terstruktur, sehingga mesin kebijakan dan alat otomatisasi dapat mengurai dan mengevaluasinya secara deterministik. Dengan cara ini, kebijakan menjadi pengamanan yang dapat dieksekusi yang harus dipenuhi oleh sistem dan para teknisi, bukan sekadar pedoman yang mungkin ditafsirkan secara berbeda oleh setiap orang.

Kebijakan sebagai alat kode memungkinkan pengembang untuk menulis kode yang dapat dieksekusi ke dalam waktu proses dan pipeline integrasi/pengiriman berkelanjutan (CI/CD), sehingga setiap perubahan secara otomatis diperiksa kepatuhannya.

Secara teknis, sebagian besar pengaturan PaC mengikuti langkah-langkah inti yang sama:

• Pengembang menulis kebijakan dalam bentuk file kode. Mereka dapat menggunakan berbagai bahasa imperatif dan deklaratif tingkat tinggi, termasuk Python, YAML, JavaScript Object Notation (JSON) atau Rego, yang biasanya digunakan bersama Open Policy Agent (OPA), mesin kebijakan sumber terbuka. Setiap file kebijakan menyatakan input yang dipedulikannya (“resource.kind,” “metadata.labels,” misalnya) dan mengodekan kondisi—juga disebut “predikat”—dan hasil (izinkan atau tolak, tingkat keparahan, pesan).

• Kode tersebut dikirim ke sistem kontrol versi, seperti Git atau GitHub, dan melewati alur kerja yang sama seperti kode aplikasi, termasuk permintaan pull, tinjauan kode dan pengujian sintaks yang ketat.

• Mesin kebijakan membaca file kode, menguraikannya dan mengubahnya menjadi struktur dan instruksi data yang dapat dipahami secara internal. Struktur dan instruksi ini kemudian diubah menjadi format instruksi tingkat rendah yang ringkas (bytecode) untuk evaluasi cepat.

• Pemanggil— bagian kode yang meminta keputusan dari mesin kebijakan—menormalkan input data. Pemanggil memproses format input yang berbeda, termasuk file Hashicorp Configuration Language (HCL) dan templat JSON dari alat IaC, manifes YAML dari Kubernetes dan platform cloud, permintaan HTTP dari panggilan API, serta data aplikasi dan data telemetri dari lingkungan waktu proses dan produksi. Proses ini membersihkan dan membentuk kembali input mentah menjadi satu struktur standar, sehingga kebijakan dapat membaca input dengan cara yang konsisten.

• Pemanggil menyerahkan kembali data yang dinormalisasi ke mesin kebijakan, yang kemudian mulai menjalankan kode kebijakan terhadap input data tersebut.  

• Mesin kebijakan menelusuri aturan dan memeriksa predikat setiap aturan terhadap input untuk memahami predikat mana yang berlaku. Mesin kebijakan ini dapat dianggap seperti bertanya, “Apa yang dikatakan aturan ini tentang input ini?”

• Mesin kebijakan mengambil hasil dari semua aturan dan menggabungkannya menjadi satu keputusan kebijakan—proses yang disebut agregasi keputusan—dan membuat daftar pesan. Pesan memberikan detail lebih lanjut (aturan mana yang dilanggar dan objek mana yang melanggarnya) tentang kode yang gagal dan terkadang menawarkan saran tentang cara perbaikan.

• Mesin kebijakan mengembalikan keputusan, termasuk pesan, tag, dan informasi tingkat keparahan yang relevan. Jika keputusannya adalah “tolak”, mesin kebijakan akan memblokir semua permintaan pull dan penggabungan kode serta menghentikan proses penerapan hingga pengembang memperbaiki pelanggaran kebijakan. Jika keputusannya adalah “izinkan,” mesin membuat artefak build (file kode yang dikompilasi, dikemas, dan diuji) dan menerapkan kode. Jika terdapat peringatan, kode tersebut diizinkan untuk diteruskan, tetapi mesin akan menyertakan peringatan tersebut dalam file log atau komentar. 

Pemeriksaan kebijakan dapat terjadi kapan saja dalam siklus hidup pengembangan perangkat lunak (SDLC), mulai dari integrasi kode hingga produksi langsung dan pemantauan.

Karena kebijakan adalah kode, mereka juga dapat diperlakukan seperti artefak perangkat lunak lainnya.

Tim pengembang dapat menulis pengujian otomatis yang memasukkan input sampel ke dalam kebijakan dan memverifikasi keputusan yang dihasilkan untuk mempercepat siklus masukan ketika kebijakan berubah.

Ketika kebijakan dikodekan, pengembang dapat memfaktorkan logika umum ke dalam modul atau fungsi yang dapat digunakan kembali. Beberapa kebijakan tingkat tinggi kemudian dapat menggunakan kebijakan bersama alih-alih menduplikasi kondisi di mana-mana.

Pengembang juga dapat mengganti nama, merestrukturisasi, atau membagi kebijakan besar menjadi kebijakan yang lebih kecil tanpa mengubah perilaku mereka, seperti memfaktorkan ulang fungsi aplikasi besar menjadi fungsi yang lebih kecil.

Kemampuan ini memungkinkan tim untuk menerapkan praktik rekayasa perangkat lunak yang ada pada logika tata kelola , yang membantu mereka mempertahankan persyaratan keamanan dan kepatuhan seiring dengan peningkatan dan evolusi arsitektur TI.

Misalnya, Perusahaan X ingin menerapkan kebijakan “khusus HTTPS” di mana setiap layanan web harus menggunakan HTTPS, bukan HTTP biasa. Untuk mengodifikasi kebijakan, seorang teknisi platform menulis aturan sederhana yang mengatakan:

• Jika protokol layanan adalah HTTP, perubahan harus ditolak.
• Jika protokol layanan adalah HTTPS, perubahan diperbolehkan.

Insinyur menempatkan berkas kebijakan ini di dalam folder "kebijakan" di dalam repositori kode yang sama dengan aplikasi dan membuka permintaan pull untuk menambahkan kebijakan tersebut. Permintaan pull tersebut memicu pemeriksaan sintaks otomatis file kebijakan dan tinjauan kode oleh teknisi lain. Kebijakan tersebut baru akan digabungkan ke cabang utama setelah melewati pengujian yang diperlukan.

Dalam pipeline integrasi berkelanjutan (CI) , semua file kebijakan dimuat ke mesin kebijakan dari folder "kebijakan". Mesin kebijakan membaca kebijakan tersebut, mengubahnya menjadi representasi internal, dan menyusunnya menjadi bentuk yang ringkas dan tingkat rendah. Bentuk yang ringkas ini memungkinkan mesin untuk dengan cepat menjawab “izinkan atau tolak?” untuk setiap layanan yang diperiksa oleh pipeline.

Terlepas dari format file, pekerjaan CI mengambil file konfigurasi yang ada, mengekstrak bidang penting (nama, protokol, port) dan membuat deskripsi JSON sederhana untuk setiap layanan.

Pemanggil meminta keputusan dari mesin kebijakan dengan mengirimkan deskripsi layanan standar sebagai input dan menunjukkan bahwa paket kebijakan untuk “khusus HTTPS” harus diterapkan.

Mesin kebijakan kemudian mengevaluasi input terhadap aturan. Ia memeriksa bidang protokol layanan. Jika protokolnya adalah HTTP, itu berarti input cocok dengan kondisi “tolak” dalam kebijakan. Mesin menunjukkan bahwa perubahan harus ditolak dan membuat pesan yang memberi tahu pengembang bahwa layanan harus menggunakan HTTPS alih-alih HTTP. Jika layanan menggunakan HTTPS, tidak ada kondisi penolakan yang terpenuhi, dan mesin menunjukkan bahwa perubahan tersebut diizinkan.

Kemudian, mesin kebijakan merangkum evaluasi aturan ke dalam satu objek keputusan tunggal untuk layanan tersebut. Objek keputusan biasanya menentukan apakah keputusan keseluruhan adalah “izinkan” atau “tolak” dan seberapa parah masalahnya (tinggi, sedang, rendah). Mereka juga menyertakan daftar pesan yang menjelaskan mengapa input ditolak dan peringatan apa pun yang ditemukan mesin dalam proses penilaian. Jika semuanya sesuai, objek keputusan menyatakan bahwa perubahan diizinkan dan hanya disertai catatan informasi (atau tanpa pesan sama sekali).

Akhirnya, alat CI menegakkan keputusan. Jika keputusannya adalah “tolak,” perubahan gagal digabungkan ke cabang kode utama. Teknisi melihat pesan kesalahan yang mengatakan bahwa layanan harus menggunakan HTTPS dan menjalani modifikasi tertentu. Jika keputusannya adalah "izinkan", artefak tersebut dikemas dan diterapkan, dan pipeline CI berlanjut seperti biasa.

Konsep kebijakan sebagai kode tumbuh dari gerakan yang lebih luas yaitu “semuanya sebagai kode” dalam DevOps modern dan rekayasa cloud.

Awalnya, infrastruktur sebagai kode (IaC) merupakan perubahan besar. Alih-alih administrator sistem mengklik antarmuka pengguna atau mengikuti runbook, tim mendeskripsikan server, jaringan, dan sumber daya lainnya dalam file kode deklaratif. File-file ini disimpan dalam sistem kontrol versi dan diterapkan melalui pipeline otomatis.

Ketika perusahaan melihat manfaatnya, pendekatan ini menyebar ke komponen lain dari arsitektur TI. Konfigurasi aplikasi pindah menuju pendekatan berbasis kode. Pipeline CI/CD menjadi skrip yang tersimpan di repositori kode. Aturan pemantauan dan peringatan juga mulai dimasukkan dalam kode. Secara bersama-sama, praktik ini dikenal sebagai “semuanya sebagai kode.”

Gagasan utama dari “semuanya sebagai kode” adalah bahwa, jika beberapa bagian dari sistem dapat dijelaskan, itu harus digambarkan sebagai kode dan dikelola dengan cara yang sama seperti aplikasi perangkat lunak.

PaC pada dasarnya adalah penerapan filosofi tersebut pada aturan, tata kelola dan kepatuhan. Secara tradisional, kebijakan terdapat dalam PDF dan wiki atau diputuskan oleh komite, dan ditegakkan oleh manusia. Proses ini berjalan lancar ketika siklus rilis lambat dan infrastruktur relatif statis.

Ketika arsitektur cloud-native dan microservice mengambil alih, dan tim mulai menerapkan kode beberapa kali sehari, proses manual tidak mampu mengimbanginya. PaC mengatasi tantangan ini dengan mengekspresikan kebijakan dalam format yang dapat dibaca mesin, sehingga mereka dapat diberi versi di dalam Git, ditinjau seperti file kode, diuji di CI dan diterapkan secara otomatis di pipeline atau saat waktu proses.

Kebijakan sebagai kode adalah praktik untuk mengelola kebijakan TI seperti kode perangkat lunak. Infrastruktur sebagai kode (IaC) bersifat serupa, tetapi dengan fokus yang berbeda. Hal ini memungkinkan tim teknik untuk menentukan dan mengelola infrastruktur TI dengan menggunakan kode aplikasi.

Alih-alih membuat dan mengonfigurasi aset jaringan seperti mesin virtual (VM) dan penyeimbang beban secara manual, IaC memungkinkan pengembang untuk menulis kode guna mendeskripsikan keadaan yang diinginkan dari sumber daya ini. Alat IaC kemudian mengambil kode itu dan membuat atau memodifikasi sumber daya yang ditentukan.

IaC membuat penskalaan dan otomatisasi infrastruktur menjadi jauh lebih mudah. Jika sebuah tim membutuhkan lebih banyak server, mereka cukup mengubah angka dalam kode (misalnya dari enam instance menjadi sembilan). Alat otomatisasi menangani detail penyediaan sumber daya tambahan tersebut.

Pada tingkat tinggi, IaC menentukan infrastruktur apa saja yang harus ada dan bagaimana konfigurasinya, sementara PaC berfokus pada aturan dan kendala yang harus dipatuhi oleh infrastruktur tersebut. Kode IaC membuat dan mengonfigurasi sumber daya, dan kode PaC membantu memastikan bahwa sumber daya tersebut (dan cara penggunaannya) mengikuti persyaratan keamanan yang ditentukan, standar kepatuhan, dan pengamanan operasional.

Dalam banyak arsitektur TI modern dan pengaturan CI/CD, IaC dan PaC memberikan manfaat yang saling melengkapi. IaC mengotomatiskan proses penyediaan, sedangkan PaC menambahkan tata kelola otomatis sebagai pelengkapnya.

Ketika seorang pengembang mengubah file IaC, mesin PaC dapat memeriksa rencana atau konfigurasi baru. Jika semuanya sesuai dengan kebijakan yang telah ditetapkan, perubahan diizinkan untuk dilanjutkan dan infrastruktur akan diperbarui. Jika ada sesuatu yang melanggar aturan, pipeline gagal dan tidak ada yang diterapkan sampai masalah diperbaiki.

DevSecOps adalah tentang menanamkan keamanan dan kepatuhan ke dalam siklus hidup DevOps, alih-alih menambahkannya di akhir. Ini adalah pendekatan pengembangan di mana proses keamanan diprioritaskan dan dijalankan selama setiap tahap siklus hidup pengembangan perangkat lunak.

PaC mendukung praktik DevSecOps dengan:

PaC membantu tim menggeser keamanan ke kiri dengan memindahkan pemeriksaan keamanan ke tahap paling awal dari proses pengembangan, alih-alih menunggu hingga setelah penerapan untuk menjalankan pemeriksaan—saat masalah tersebut berpotensi memengaruhi pengguna. Jika seorang pengembang menerapkan konfigurasi berisiko atau pola tidak aman, kebijakan otomatis dapat membantu mendeteksi masalah dan menggagalkan proses pembangunan.

Alat PaC mengotomatiskan penegakan aturan dengan menanamkan aturan keamanan langsung ke dalam pipeline CI/CD dan sistem waktu proses, sehingga pemeriksaan terjadi secara otomatis setiap kali kode atau infrastruktur berubah. Alih-alih mengandalkan manusia untuk mengingat setiap standar keamanan dan meninjau setiap perubahan secara manual, sistem secara konsisten mengevaluasi perubahan untuk memastikan bahwa tidak ada langkah yang dilewati secara tidak sengaja.

PaC membantu pengembang mempertahankan kecepatan penerapan tanpa mengorbankan konsistensi dan keamanan. Sistem ini menjalankan definisi kebijakan yang sama di setiap lingkungan dan di setiap tahapan—pengembangan, pengujian, penyiapan, dan produksi. Fitur ini memungkinkan tim untuk sering merilis karena mereka dapat mempercayai bahwa serangkaian aturan yang sama diterapkan di mana-mana. Hal ini juga membantu mereka menghindari situasi di mana lingkungan yang berbeda saling terpisah atau menggunakan interpretasi aturan yang sedikit berbeda.

PaC memperlakukan kebijakan keamanan aplikasi seperti artefak kode lainnya yang berada dalam sistem kontrol versi. Tim pengembangan, operasi, dan keamanan dapat meninjau, mendiskusikan, dan memperbarui kebijakan melalui alur kerja yang sudah dikenal (tinjauan kode, strategi percabangan), yang membuat diskusi kebijakan lebih transparan dan lebih terintegrasi ke dalam pekerjaan pengembangan sehari-hari.

Kebijakan sebagai kode memiliki berbagai macam aplikasi untuk arsitektur TI perusahaan.

Para pengembang dan profesional keamanan sedang menjelajahi kebijakan sebagai kode (policy as code) sebagai cara untuk menciptakan model pengamanan berlapis yang mencakup seluruh siklus hidup AI atau alur kerja berbasis agen. Meskipun praktik ini masih muncul, investigasi awal telah mengungkapkan banyak kemungkinan aplikasi PaC dalam alur kerja AI.

PaC dapat membantu menetapkan pemisahan yang jelas antara penalaran AI dan sistem yang memutuskan tindakan mana yang sebenarnya diizinkan untuk dijalankan. Alat AI dapat mengusulkan tindakan atau rencana, tetapi mesin kebijakan mengevaluasi proposal tersebut terhadap aturan yang dikodifikasi sebelum sistem yang mendasarinya diubah.

Pada tahap input, PaC dapat membantu memfilter atau mengubah prompt pengguna, menyunting data sensitif, menegakkan isolasi penyewa, dan memblokir pola serangan yang diketahui. Selama perencanaan, PAC dapat meminta agen AI untuk membuat rencana terstruktur dan memvalidasi setiap langkah terhadap alat, tindakan, dan kondisi risiko yang diizinkan sebelum eksekusi diperbolehkan.

Pada waktu eksekusi, setiap pemanggilan alat atau panggilan API dapat diperiksa oleh lapisan penegakan kebijakan. Lapisan tersebut memutuskan apakah akan mengizinkan, menolak atau memodifikasi suatu tindakan atau meneruskannya ke manusia. Setelah eksekusi, kebijakan dapat mendorong pencatatan, jejak audit, aturan retensi, dan pasca-filter pada output model untuk membantu memastikan bahwa tanggapan memenuhi persyaratan yang diperlukan.

• Konsistensi. Dengan PaC, kebijakan diterapkan dengan cara yang sama di seluruh lingkungan karena kode yang sama dijalankan di mana-mana. Konsistensi ini mengurangi snowflake configuration, yaitu konfigurasi unik dan tidak terstandarisasi, serta menghindarkan tim dari keharusan mengingat proses manual yang sedikit berbeda untuk setiap lingkungan.

• Efisiensi. Ketika kebijakan dikodifikasi, kebijakan tersebut dapat diterapkan secara otomatis dalam pipeline CI/CD atau pada waktu penerapan, sehingga menghilangkan kebutuhan akan pemeriksaan dan persetujuan manual.

• Otomatisasi. PaC memungkinkan validasi otomatis dan pengujian kebijakan, yang membantu tim meminimalkan dampak kesalahan manusia, menangkap kesalahan konfigurasi, dan mengatasi kerentanan keamanan sebelum memasuki produksi.

• Visibilitas. Dengan kebijakan yang ditulis dalam kode dan disimpan secara terpusat, pemangku kepentingan dapat melihat dengan tepat aturan apa yang berlaku, alih-alih mengandalkan dokumen yang tersebar dan ingatan orang.

• Skalabilitas. Evaluasi kebijakan dilakukan secara otomatis, sehingga organisasi dapat menerapkan kebijakan dalam skala besar di banyak layanan, klaster, atau akun tanpa peningkatan jumlah karyawan yang proporsional.

• Kolaborasi. PaC menyederhanakan kolaborasi seputar kode kebijakan. Alur kerja bersama ini memecah silo, menyelaraskan keamanan dan tata kelola dengan praktik DevOps, serta membuat diskusi kebijakan lebih konkret dan dapat diuji.