Lima Kebijakan Infrastruktur yang Mencegah Cloud Anda Boros Biaya dan Rawan Keamanan

Seorang pengembang perlu akses SSH ke server produksi untuk sesi debugging cepat. Mereka membuka port 22 ke 0.0.0.0/0 agar bisa terhubung dari IP rumah. Debugging selesai, tiket ditutup, dan aturan security group itu tetap terbuka selama tiga bulan. Tidak ada yang menyadari sampai tagihan cloud datang dengan kejutan: seseorang membuat instance m5.24xlarge di akun dev, berjalan 24/7, tanpa tag, bernama test123.

Ini bukan skenario hipotetis. Pola ini terulang di berbagai tim setiap kuartal. Solusinya bukanlah review manual yang lebih ketat atau kontrol akses yang lebih keras. Solusinya adalah kebijakan yang ditulis sebagai kode, diperiksa secara otomatis sebelum resource apa pun dibuat.

Kebijakan infrastruktur terbagi dalam lima kategori. Masing-masing memecahkan masalah spesifik. Memahami kelimanya membantu Anda memutuskan mana yang perlu diprioritaskan di pipeline Anda.

Keamanan: Baseline yang Tidak Bisa Ditawar

Kebijakan keamanan adalah yang paling kritis karena pelanggarannya memiliki konsekuensi langsung dan terlihat. Contoh klasiknya adalah memblokir aturan security group yang membuka port SSH atau database ke 0.0.0.0/0. Pengembang sering membukanya untuk akses sementara dan lupa menutupnya. Kebijakan yang menolak aturan semacam itu pada saat pipeline mencegah resource produksi secara tidak sengaja terekspos ke internet.

Kebijakan keamanan umum lainnya meliputi:

  • Mewajibkan enkripsi saat diam (encryption at rest) untuk S3 bucket dan EBS volume
  • Memblokir versi TLS usang di load balancer
  • Menerapkan traffic HTTPS saja di semua endpoint publik
  • Mewajibkan VPC flow logs untuk lingkungan produksi
  • Mewajibkan peran IAM, bukan access key berumur panjang

Kebijakan keamanan biasanya memiliki perilaku hard fail: jika pemeriksaan gagal, pipeline berhenti dan resource tidak dibuat. Tidak ada mode peringatan untuk port yang terbuka ke seluruh internet.

Biaya: Mencegah Jebakan Biaya Tak Terduga

Resource cloud sangat mahal jika tidak diawasi. Seorang pengembang saja bisa secara tidak sengaja menyediakan tipe instance yang biayanya setara dengan gaji bulanan anggota tim. Kebijakan biaya memasang pagar pembatas (guardrails) di sekitar pengeluaran tanpa perlu persetujuan manual untuk setiap resource.

Kebijakan biaya tipikal meliputi:

  • Memblokir tipe instance mahal (seperti m5.24xlarge atau r5.metal) di lingkungan non-produksi
  • Membatasi jumlah EBS volume atau GPU per akun
  • Mewajibkan spot instance untuk beban kerja yang toleran terhadap kegagalan
  • Menetapkan ukuran penyimpanan maksimum untuk database
  • Menerapkan jadwal auto-stop untuk lingkungan pengembangan

Kebijakan biaya membantu tim tetap sadar anggaran, terutama ketika banyak pengembang memiliki akses cloud. Tanpa kebijakan ini, kenyamanan satu orang bisa menjadi tagihan kejutan bagi tim.

Tagging: Metadata yang Menjaga Operasional Tetap Berjalan

Tagging terdengar membosankan sampai Anda perlu mencari tahu siapa pemilik resource yang sudah berjalan selama enam bulan. Tag seperti owner, environment, cost-center, dan project sangat penting untuk melacak biaya, mengotomatiskan pembersihan, dan debugging insiden.

Kebijakan tagging memastikan setiap resource memiliki tag yang diperlukan saat dibuat. Contohnya:

  • Setiap resource harus memiliki tag owner dengan alamat email yang valid
  • Setiap resource harus memiliki tag environment: dev, staging, atau production
  • Setiap resource harus memiliki tag cost-center yang sesuai dengan kode anggaran tim

Ketika sebuah resource gagal dalam kebijakan tagging, pipeline bisa menolaknya atau membuatnya dengan peringatan dan jadwal pembersihan. Yang terpenting adalah resource yang tidak diberi tag tidak menumpuk secara diam-diam. Kebijakan tagging mencegah masalah "resource yatim piatu" di mana tim billing menemukan resource misterius yang berjalan selama berbulan-bulan tanpa pemilik yang jelas.

Penamaan: Konsistensi untuk Manusia dan Otomatisasi

Nama resource lebih penting dari yang disadari kebanyakan tim. Bucket bernama test123 dan bucket lain bernama data-barang sulit dicari, sulit diotomatisasi, dan sulit di-troubleshoot. Kebijakan penamaan menerapkan pola yang konsisten sehingga tim operasional dan alat otomatisasi dapat menemukan resource dengan cepat.

Kebijakan penamaan umum meliputi:

  • Semua S3 bucket harus diawali dengan nama proyek
  • Semua security group harus memiliki prefiks yang menunjukkan lingkungan
  • Semua instance RDS harus mengikuti pola {project}-{env}-{function}
  • Semua peran IAM harus menyertakan nama layanan dan tingkat izin

Kebijakan penamaan sering digabungkan dengan kebijakan tagging. Bersama-sama, keduanya memastikan setiap resource dapat diidentifikasi, dicari, dan dikelola dalam skala besar. Tanpa keduanya, akun cloud Anda akan terlihat seperti laci sampah.

Kepatuhan: Menerjemahkan Aturan Eksternal ke Dalam Kode

Kebijakan kepatuhan menangani persyaratan dari regulasi eksternal seperti PCI DSS, HIPAA, SOC 2, atau GDPR. Ini tidak opsional. Kebijakan ini menerjemahkan persyaratan hukum dan regulasi menjadi pemeriksaan otomatis yang berjalan sebelum resource apa pun digunakan.

Contoh kebijakan kepatuhan:

  • Semua database produksi harus menggunakan enkripsi saat diam
  • Semua akses ke resource produksi harus dicatat dalam jejak audit terpusat
  • Semua data harus disimpan di region geografis yang disetujui
  • Semua backup harus dienkripsi dan disimpan di akun terpisah
  • Semua akses API harus menggunakan autentikasi multi-faktor

Kebijakan kepatuhan seringkali paling sulit dinegosiasikan karena berasal dari luar tim engineering. Namun, mengkodekannya sebagai kode membuatnya konsisten, dapat diaudit, dan jauh lebih mudah ditegakkan daripada daftar periksa manual.

Bagaimana Kebijakan-Kebijakan Ini Berinteraksi

Kelima kategori ini tidak beroperasi sendiri-sendiri. Sebuah instance EC2 tunggal akan diperiksa terhadap beberapa kebijakan sekaligus: aturan security group, tipe instance, tag, pola penamaan, dan persyaratan kepatuhan. Pipeline yang baik menjalankan semua pemeriksaan ini sebelum resource dibuat, bukan setelahnya.

Diagram berikut menunjukkan bagaimana kelima kategori kebijakan saling berhubungan dan dengan pipeline deployment:

flowchart TD A[Pipeline Trigger] --> B{Security & Compliance} B -->|Pass| C{Cost} B -->|Fail| D[Reject Resource] C -->|Pass| E{Tagging} C -->|Fail| D E -->|Pass| F{Naming} E -->|Fail| G[Warn or Reject] F -->|Pass| H[Create Resource] F -->|Fail| G D --> I[Alert Team] G --> I

Urutan juga penting. Pemeriksaan keamanan dan kepatuhan harus dijalankan terlebih dahulu karena pelanggaran di kategori tersebut tidak bisa ditawar. Pemeriksaan biaya dan tagging bisa menyusul. Pemeriksaan penamaan biasanya paling tidak kritis, tetapi tetap layak ditegakkan demi kewarasan operasional.

Daftar Periksa Praktis untuk Memulai

Jika Anda baru mengenal kebijakan infrastruktur, mulailah dari yang kecil. Pilih satu kategori dan otomatiskan satu pemeriksaan. Berikut adalah urutan yang berhasil untuk sebagian besar tim:

  • Minggu pertama: Tambahkan kebijakan keamanan yang memblokir akses SSH publik. Buat pipeline gagal total (hard fail).
  • Minggu kedua: Tambahkan kebijakan tagging yang mewajibkan tag owner dan environment. Mulai dengan peringatan, lalu beralih ke hard fail setelah dua minggu.
  • Minggu ketiga: Tambahkan kebijakan biaya yang memblokir tipe instance mahal di akun dev. Beri peringatan saat terjadi pelanggaran, eskalasi ke pimpinan tim.
  • Minggu keempat: Tambahkan konvensi penamaan untuk tipe resource yang paling umum di akun Anda.
  • Bulan kedua: Tinjau persyaratan kepatuhan dan kodekan tiga persyaratan teratas sebagai pemeriksaan otomatis.

Tujuannya bukan menulis semua kebijakan sekaligus. Tujuannya adalah membangun momentum dengan menyelesaikan masalah yang paling menyakitkan terlebih dahulu.

Yang Paling Penting

Kebijakan keamanan dan kepatuhan melindungi Anda dari ancaman eksternal dan risiko hukum. Kebijakan biaya melindungi anggaran Anda. Kebijakan tagging dan penamaan melindungi kewarasan operasional Anda. Kelima kategori bekerja sama untuk mengubah manajemen infrastruktur dari proses manual yang rawan kesalahan menjadi proses otomatis yang konsisten.

Mulailah dengan kebijakan yang paling menyakitkan hari ini. Bagi sebagian besar tim, itu adalah security group yang terbuka lebar ke internet atau resource misterius yang menaikkan tagihan. Otomatiskan pemeriksaan itu, lalu lanjutkan ke yang berikutnya. Seiring waktu, pipeline Anda menjadi jaring pengaman yang menangkap kesalahan sebelum menjadi insiden.