Saat Kebijakan Infrastruktur Menjadi Hambatan: Menangani Pengecualian Tanpa Mengorbankan Keamanan

Anda telah menghabiskan waktu berminggu-minggu untuk menyusun kebijakan infrastruktur. Setiap sumber daya harus mengikuti konvensi penamaan, menggunakan tipe instance yang disetujui, dan tidak boleh membuka port tertentu ke publik. Pipeline menerapkan aturan-aturan ini secara otomatis. Semuanya bersih, terkendali, dan aman.

Kemudian sebuah tim datang kepada Anda dengan permintaan yang melanggar tiga kebijakan sekaligus. Mereka membutuhkan instance memori besar yang biasanya dilarang karena biaya. Mereka perlu membuka port debug sementara karena masalah produksi hanya muncul di lingkungan nyata. Dan sistem lawas yang sedang mereka migrasikan memaksa mereka menggunakan nama sumber daya yang melanggar standar penamaan Anda.

Apa yang Anda lakukan?

Masalah dengan Kebijakan yang Kaku

Jika jawaban Anda adalah "kebijakan ya kebijakan, tidak ada pengecualian," Anda sedang menjebak diri sendiri. Tim akan mencari jalan pintas. Mereka diam-diam akan memodifikasi kebijakan, membuat sumber daya di luar pipeline, atau sekadar mengabaikan aturan. Kebijakan menjadi tidak berguna karena orang lebih suka bekerja di sekitar sistem daripada berdebat dengan aturan yang kaku.

Tujuannya bukan untuk menghilangkan kebijakan. Tujuannya adalah membuatnya cukup fleksibel sehingga orang tidak merasa terpaksa untuk menghindarinya. Anda membutuhkan mekanisme pengecualian yang jelas yang membuat semua orang tetap bertanggung jawab.

Tiga Hal yang Dibutuhkan Setiap Pengecualian

Sistem pengecualian yang dirancang dengan baik memiliki tiga komponen yang tidak bisa ditawar: pencatatan (logging), persetujuan (approval), dan masa berlaku (expiration).

Pencatatan (Logging)

Setiap pengecualian harus dicatat. Siapa yang memintanya, kebijakan mana yang dilanggar, sumber daya apa yang terpengaruh, mengapa pengecualian diperlukan, dan siapa yang menyetujuinya. Informasi ini tidak boleh hilang. Ini berguna untuk berbagai keperluan: jejak audit, analisis pasca-insiden, dan pengingat halus bahwa tim sedang beroperasi di luar aturan normal.

Tanpa pencatatan, pengecualian menjadi utang teknis yang tidak terlihat. Anda tidak akan tahu berapa banyak pengecualian yang ada, siapa yang memberikannya, atau apakah pengecualian tersebut masih diperlukan.

Persetujuan (Approval)

Orang yang meminta pengecualian tidak boleh menyetujuinya sendiri. Orang lain harus menandatanganinya, idealnya seseorang yang memahami risiko yang dirancang untuk dimitigasi oleh kebijakan tersebut. Jika pengecualian menyangkut keamanan, tim keamanan yang menyetujui. Jika memengaruhi biaya, tim keuangan atau manajer teknik yang menyetujui.

Persetujuan ini dapat diintegrasikan langsung ke dalam pipeline Anda sebagai gerbang (gate). Pipeline berhenti sampai orang yang berwenang meninjau dan menyetujui permintaan pengecualian. Tidak ada persetujuan, tidak ada deployment.

Masa Berlaku (Expiration)

Pengecualian tidak boleh bersifat permanen. Setiap pengecualian membutuhkan batas waktu, biasanya 7 hingga 30 hari. Setelah itu, kebijakan berlaku kembali secara otomatis. Sumber daya yang melanggar harus diperbaiki atau dihapus. Jika pengecualian masih diperlukan, tim harus mengirimkan permintaan baru dengan alasan yang diperbarui.

Mekanisme ini mencegah pengecualian menjadi kebiasaan baru. Ini memaksa tim untuk memperbaiki masalah yang mendasarinya atau memberikan alasan mengapa kebijakan perlu diubah.

Mendesain Alur Pengecualian

Proses pengecualian seharusnya sedikit merepotkan. Bukan untuk menghukum orang, tetapi untuk memastikan mereka benar-benar membutuhkan pengecualian tersebut. Jika terlalu mudah, semua orang akan menggunakan pengecualian alih-alih mengikuti kebijakan. Jika terlalu sulit, orang akan mencari celah. Titik idealnya ada di antara keduanya: cukup menjengkelkan untuk membuat orang berpikir dua kali, tetapi tidak terlalu menyakitkan hingga menghalangi pekerjaan yang sah.

Dalam praktiknya, alurnya terlihat seperti ini:

Diagram berikut mengilustrasikan proses permintaan pengecualian:

flowchart TD A[Pipeline mendeteksi pelanggaran kebijakan] --> B{Pilih tindakan} B -->|Batalkan| C[Perubahan diblokir] B -->|Minta pengecualian| D[Kirim permintaan pengecualian] D --> E[Catat detail permintaan] E --> F[Beritahu penyetuju] F --> G{Disetujui?} G -->|Tidak| H[Perubahan diblokir] G -->|Ya| I[Pipeline lanjut dengan status pengecualian] I --> J[Tetapkan tanggal kedaluwarsa] J --> K[Kirim pengingat sebelum kedaluwarsa] K --> L{Kedaluwarsa?} L -->|Tidak| M[Sumber daya dalam pengecualian] L -->|Ya| N[Jalankan ulang pemeriksaan kebijakan] N --> O{Patuh?} O -->|Ya| P[Pengecualian ditutup] O -->|Tidak| Q[Terapkan kebijakan / perbaiki sumber daya]
  1. Pipeline menjalankan pemeriksaan kebijakan selama tahap plan atau apply.
  2. Pelanggaran terdeteksi. Pipeline menawarkan dua opsi: batalkan perubahan, atau kirim permintaan pengecualian.
  3. Jika tim mengirimkan pengecualian, pipeline membuat tiket atau notifikasi untuk penyetuju yang berwenang.
  4. Setelah disetujui, pipeline melanjutkan, tetapi menandai sumber daya sebagai dalam status pengecualian.
  5. Sistem mengirimkan pengingat sebelum pengecualian kedaluwarsa. Setelah kedaluwarsa, sistem secara otomatis menjalankan ulang pemeriksaan kebijakan.

Apa yang Tidak Boleh Dilakukan

Jangan pernah membuat pengecualian tanpa tanggal kedaluwarsa atau persetujuan. Itu sama saja dengan tidak memiliki kebijakan sama sekali. Pengecualian yang tidak pernah kedaluwarsa hanyalah kebijakan yang ditulis ulang secara diam-diam.

Juga, jangan gunakan pengecualian sebagai alasan untuk menghindari perbaikan kebijakan Anda. Jika jenis pengecualian yang sama terus muncul, kebijakan Anda mungkin terlalu ketat. Mungkin Anda membutuhkan kategori sumber daya baru, atau aturan asli sudah tidak relevan lagi. Pengecualian yang sering terjadi adalah sinyal bahwa kebijakan Anda perlu dievaluasi, bukan sekadar dicari jalan pintasnya.

Daftar Periksa Praktis untuk Penanganan Pengecualian

  • Setiap pengecualian dicatat dengan pemohon, kebijakan yang dilanggar, sumber daya yang terpengaruh, alasan, dan penyetuju
  • Pengecualian memerlukan persetujuan dari seseorang yang memahami risiko kebijakan
  • Semua pengecualian memiliki tanggal kedaluwarsa yang eksplisit (disarankan 7-30 hari)
  • Pipeline memblokir deployment hingga pengecualian disetujui
  • Pengingat otomatis dikirim sebelum pengecualian kedaluwarsa
  • Pengecualian yang kedaluwarsa memicu pemeriksaan ulang kebijakan secara otomatis
  • Frekuensi pengecualian ditinjau setiap kuartal untuk mengidentifikasi perbaikan kebijakan

Intisari

Kebijakan tanpa mekanisme pengecualian menciptakan sistem bayangan. Tim akan bekerja di sekitarnya, dan Anda kehilangan visibilitas terhadap apa yang sebenarnya berjalan di infrastruktur Anda. Alur pengecualian yang dirancang dengan baik tidak melemahkan kebijakan Anda. Ini memperkuatnya dengan membuatnya cukup realistis sehingga orang benar-benar mengikutinya. Kuncinya adalah pencatatan, persetujuan, dan masa berlaku. Tanpa ketiganya, Anda tidak memiliki proses pengecualian. Anda memiliki kebijakan yang sudah rusak.