Ketika Aturan Keamanan Hidup di Dokumen, Mereka Diabaikan

Sebuah tim keamanan menghabiskan waktu berminggu-minggu untuk menyusun kebijakan pemindaian image kontainer. Mereka mengirimkannya melalui email, mengumumkannya dalam rapat全体, dan menyimpannya di wiki perusahaan. Tiga bulan kemudian, seseorang memeriksa pipeline produksi dan menemukan bahwa pemindaian tidak pernah diaktifkan. Konfigurasi tersebut hilang di satu proyek, dan tidak ada yang menyadarinya.

Ini bukan cerita tentang niat buruk. Ini adalah cerita tentang bagaimana aturan menjadi rusak ketika mereka hidup di luar pipeline.

Masalah dengan Aturan sebagai Dokumen

Kebijakan tertulis memiliki kelemahan mendasar: mereka bergantung pada manusia untuk membaca, mengingat, dan menerapkannya dengan benar. Setiap tim menafsirkan aturan yang sama secara berbeda. Setiap proyek memiliki keanehan konfigurasi sendiri. Ketika sebuah aturan berubah, seseorang harus memperbarui secara manual setiap tempat di mana aturan itu berlaku, dan orang lain harus memverifikasi bahwa pembaruan benar-benar terjadi.

Hasilnya bisa ditebak. Beberapa tim mengikuti aturan. Beberapa tim mengikuti versi yang sedikit berbeda. Beberapa tim lupa sama sekali. Dan tidak ada yang tahu situasi mana yang terjadi sampai sesuatu berjalan salah.

Perbedaan antara kedua pendekatan ini menjadi jelas ketika Anda memetakan alurnya:

flowchart TD subgraph Berbasis Dokumen A[Tim Keamanan] -->|Menulis kebijakan| B[Wiki/PDF] B -->|Dibaca manusia| C[Tim Dev] C -->|Menafsirkan| D[Konfigurasi Manual] D -->|Diterapkan ke| E[Pipeline] E -->|Mungkin atau tidak| F[Penegakan] end subgraph Kebijakan sebagai Kode G[Tim Keamanan] -->|Menulis aturan| H[File Kebijakan di Repo] H -->|PR direview| I[Version Control] I -->|CI mengambil| J[Policy Engine] J -->|Mengevaluasi| K[Pipeline] K -->|Secara otomatis| L[Penegakan] end

Ini bukan masalah orang. Ini adalah masalah pengiriman. Aturan-aturan tersebut bukan bagian dari sistem yang mengirimkan perangkat lunak. Mereka ada di luar sistem, sebagai teks yang membutuhkan penerjemahan manusia menjadi tindakan.

Menulis Aturan sebagai Kode

Policy as code mengubah model pengiriman untuk aturan. Alih-alih menulis kebijakan dalam dokumen, Anda menulisnya dalam format yang dapat dibaca mesin, menyimpannya di repositori, dan menjalankannya sebagai bagian dari pipeline. Alur kerja yang sama yang menangani kode aplikasi sekarang menangani aturan keamanan dan kepatuhan Anda.

Formatnya bervariasi. Beberapa tim menggunakan Rego dari Open Policy Agent. Beberapa menggunakan YAML dengan skema yang ditentukan. Beberapa menggunakan kerangka kerja kebijakan bawaan dari alat pemindaian yang sudah ada. Bahasanya tidak terlalu penting dibandingkan prinsipnya: aturan ditulis, diberi versi, direview, dan dijalankan secara otomatis.

Pertimbangkan aturan sederhana: kontainer tidak boleh berjalan sebagai root. Dalam policy as code, ini menjadi pernyataan yang jelas yang dapat dievaluasi oleh policy engine. Pipeline menjalankan engine terhadap setiap image kontainer sebelum deployment. Jika image berjalan sebagai root, pipeline berhenti. Jika aturan perlu diubah, seseorang mengedit file kebijakan, membuka pull request, dan menunggu review. Perubahan tersebut melalui proses yang sama seperti perubahan kode lainnya.

Apa yang Berubah Ketika Aturan Menjadi Kode

Manfaat pertama adalah konsistensi. Aturan yang sama dijalankan terhadap setiap proyek, setiap pipeline, setiap deployment. Tidak ada celah karena seseorang lupa mengaktifkan pemindaian atau karena dua tim mengonfigurasi alat yang sama secara berbeda. Ketika aturan baru ditambahkan, setiap pipeline mengambilnya secara otomatis.

Manfaat kedua adalah testabilitas. Sebelum policy as code, bagaimana Anda tahu bahwa aturan baru itu benar? Anda mungkin mengujinya di pipeline produksi, yang berisiko. Atau Anda mungkin melewatkan pengujian sama sekali dan berharap yang terbaik. Dengan policy as code, Anda menulis tes untuk aturan Anda. Anda membuat kasus uji di mana kontainer dengan pengguna root gagal dalam kebijakan, dan kasus lain di mana kontainer non-root lulus. Tes-tes ini berjalan di CI, seperti unit test. Jika seseorang mengubah aturan dan merusak logika, tes akan menangkapnya sebelum aturan mencapai produksi.

Manfaat ketiga adalah auditabilitas. Setiap perubahan aturan dicatat dalam version control. Anda dapat melihat siapa yang mengubah apa, kapan, dan mengapa. Anda dapat memutar kembali perubahan aturan yang buruk dengan cara yang sama seperti Anda memutar kembali perubahan kode yang buruk. Ketika seorang auditor bertanya apakah kontainer Anda berjalan sebagai root, Anda menunjuk ke file kebijakan dan log pipeline, bukan dokumen yang mungkin sudah usang.

Anda Tidak Perlu Menulis Semuanya dari Awal

Kesalahpahaman umum adalah bahwa policy as code berarti menulis setiap aturan sendiri. Dalam praktiknya, sebagian besar aturan berasal dari kerangka kerja yang sudah ada. Alat keamanan dilengkapi dengan kebijakan untuk benchmark CIS, kerangka kerja regulasi, dan pola keamanan umum. Anda mengaktifkan yang sesuai dengan organisasi Anda dan menyesuaikan ambang batas agar sesuai dengan toleransi risiko Anda.

Apa yang Anda tulis dari awal biasanya spesifik untuk organisasi Anda. Mungkin perusahaan Anda melarang deployment ke region cloud tertentu. Mungkin setiap sumber daya harus memiliki seperangkat label tertentu. Mungkin deployment produksi memerlukan tanda tangan kedua. Ini adalah aturan yang tidak dicakup oleh kerangka kerja yang ada, dan ini adalah aturan yang paling diuntungkan dengan ditulis sebagai kode.

Pergeseran Praktis

Policy as code mengubah hubungan antara tim keamanan dan tim engineering. Keamanan tidak lagi mengirim aturan melewati tembok dan berharap aturan tersebut diimplementasikan. Keamanan menulis aturan sebagai kode, mengirimkannya melalui proses review yang sama dengan kode aplikasi, dan melihat hasilnya di setiap proses pipeline.

Tim engineering tidak lagi menebak-nebak apakah mereka mengikuti aturan. Pipeline memberi tahu mereka segera. Jika sebuah perubahan melanggar kebijakan, build gagal dengan pesan yang jelas. Tim memperbaiki masalah sebelum mencapai produksi, bukan setelah audit menemukannya enam bulan kemudian.

Daftar Periksa Singkat untuk Memulai

  • Pilih satu aturan yang saat ini didokumentasikan tetapi sering dilanggar.
  • Tulis aturan tersebut sebagai kode menggunakan kerangka kerja kebijakan alat keamanan yang sudah ada.
  • Tambahkan pemeriksaan kebijakan ke pipeline CI Anda.
  • Tulis tes yang membuktikan bahwa aturan menangkap pelanggaran.
  • Tulis tes lain yang membuktikan bahwa aturan mengizinkan perubahan yang sesuai.
  • Hapus dokumen lama dan arahkan orang ke file kebijakan sebagai gantinya.

Mulailah dengan satu aturan. Buktikan bahwa alur kerja berfungsi. Kemudian perluas.

Kesimpulan

Aturan yang hidup di dokumen adalah aturan yang diabaikan. Aturan yang hidup di pipeline adalah aturan yang ditegakkan. Policy as code bukan tentang menulis lebih banyak aturan. Ini tentang membuat aturan yang sudah Anda miliki benar-benar berfungsi, setiap saat, untuk setiap perubahan, tanpa bergantung pada seseorang yang ingat untuk membaca email.