Siapa Pemilik Produksi? Mengapa Batasan Hak Akses Antar Lingkungan Itu Penting

Seorang developer di tim Anda melakukan perubahan kecil pada file konfigurasi. Maksudnya ingin memperbarui lingkungan staging, tetapi tanpa sengaja perintah tersebut dijalankan terhadap production. Lima menit kemudian, pengguna mulai melaporkan error. Tim panik mencari tahu apa yang terjadi, siapa yang melakukan perubahan, dan bagaimana cara mengembalikannya. Sementara itu, developer yang menyebabkan masalah tidak yakin apakah dirinya memang memiliki izin untuk menyentuh production.

Skenario ini lebih sering terjadi daripada yang diakui kebanyakan tim. Ini bukan tentang niat buruk atau engineer yang tidak kompeten. Ini tentang tidak adanya batasan antar lingkungan. Ketika semua orang memiliki akses yang sama ke development, staging, dan production, sistem tidak memiliki cara untuk membedakan antara perubahan yang disengaja dan kesalahan.

Masalah dengan Akses Universal

Banyak tim memulai dengan pengaturan sederhana: semua orang mendapatkan akses ke semuanya. Developer dapat memodifikasi staging, production, atau bahkan lingkungan development tim lain. Ini terasa praktis pada awalnya. Tidak ada yang perlu menunggu izin. Tidak ada yang perlu meminta bantuan untuk men-deploy perbaikan.

Namun pendekatan ini menciptakan dua masalah. Pertama, akuntabilitas menjadi kabur. Ketika sesuatu rusak di production dan semua orang memiliki akses, menemukan akar penyebabnya memakan waktu lebih lama. Anda harus memeriksa siapa yang menjalankan perintah apa, dari mesin mana, pada jam berapa. Kedua, radius ledakan dari sebuah kesalahan menjadi lebih besar. Seorang developer yang mengerjakan fitur cabang dapat secara tidak sengaja memicu deployment production. Sebuah salah ketik di file konfigurasi dapat menghentikan layanan yang digunakan ratusan pengguna.

Solusinya bukanlah mengunci semuanya dengan sangat ketat sehingga tidak ada yang bisa bekerja. Solusinya adalah menciptakan batasan hak akses yang jelas antar lingkungan.

Apa Itu Privilege Boundary?

Privilege boundary adalah pemisahan yang jelas tentang siapa yang dapat melakukan apa di setiap lingkungan. Ini bukan hanya tentang izin di sebuah alat. Ini tentang bagaimana Anda menyusun state backend, repositori, dan konfigurasi pipeline Anda.

Misalnya, file state untuk production harus berada di lokasi yang berbeda dari file state untuk development. Jika Anda menggunakan Terraform, state backend production bisa berupa bucket S3 terpisah dengan kebijakan IAM yang lebih ketat. Hanya beberapa orang di tim yang memiliki akses ke bucket tersebut. State backend development mungkin berada di bucket bersama yang dapat dibaca dan ditulis oleh semua orang di tim.

Prinsip di sini adalah hak akses paling rendah (least privilege). Setiap orang atau sistem hanya mendapatkan akses yang mereka butuhkan untuk melakukan pekerjaan mereka. Seorang developer mungkin memerlukan akses penuh ke lingkungan development. Mereka mungkin memerlukan akses read-only ke state production untuk memahami apa yang sedang berjalan. Tetapi jika mereka perlu melakukan perubahan di production, perubahan itu harus melalui proses yang lebih formal: pull request yang ditinjau oleh anggota tim lain, atau pipeline yang memerlukan persetujuan.

Kepemilikan Membuat Batasan Menjadi Konkret

Privilege boundary bekerja paling baik ketika setiap lingkungan memiliki pemilik yang jelas. Pemilik adalah orang atau tim yang bertanggung jawab ketika sesuatu salah di lingkungan itu. Kepemilikan bukan tentang kontrol. Ini tentang akuntabilitas.

Dalam praktiknya, kepemilikan sering terlihat seperti ini:

• Tim platform engineering memiliki production. Mereka bertanggung jawab atas stabilitas, kinerja, dan keamanannya.
• Tim pengembangan aplikasi memiliki staging. Mereka menggunakannya untuk memvalidasi perubahan mereka sebelum meminta deployment production.
• Developer individu memiliki lingkungan development pribadi mereka. Mereka dapat merusaknya, membangunnya kembali, dan bereksperimen dengan bebas.

Pembagian ini tidak berarti developer tidak boleh menyentuh production. Ini berarti bahwa ketika mereka melakukannya, mereka mengikuti proses yang melibatkan pemilik production. Pemilik meninjau perubahan, memahami risikonya, dan menyetujui atau menolak deployment.

Cara Menerapkan Privilege Boundary dalam Praktik

Privilege boundary muncul di tiga tempat: struktur repositori Anda, konfigurasi pipeline Anda, dan state backend Anda.

Struktur Repositori

Cara paling sederhana untuk menegakkan batasan adalah melalui struktur direktori dan perlindungan cabang. Konfigurasi production dapat berada di direktori terpisah atau bahkan repositori terpisah. Jika berada di repositori yang sama, direktori production harus dilindungi. Hanya anggota tim tertentu yang dapat mendorong perubahan ke dalamnya. Pull request yang memodifikasi konfigurasi production memerlukan persetujuan dari pemilik production.

Diagram alur berikut menunjukkan bagaimana permintaan perubahan mengalir melalui batasan hak akses berdasarkan siapa yang membuat perubahan dan lingkungan mana yang menjadi target.

Konfigurasi Pipeline

Pipeline CI/CD Anda adalah tempat batasan menjadi operasional. Pipeline untuk production seharusnya hanya berjalan ketika kondisi tertentu terpenuhi. Misalnya, pipeline mungkin hanya dipicu dari cabang yang dilindungi. Pipeline mungkin memerlukan persetujuan manual dari orang yang ditunjuk. Pipeline mungkin menjalankan langkah validasi tambahan yang dilewati oleh pipeline development.

Beberapa tim melangkah lebih jauh. Mereka mengonfigurasi pipeline production untuk hanya berjalan dari runner CI/CD tertentu yang memiliki akses ke state backend production. Developer tidak dapat menjalankan pipeline production dari laptop mereka karena mesin lokal mereka tidak memiliki kredensial yang diperlukan.

State Backend

State backend adalah tempat alat infrastructure-as-code menyimpan status terkini dari lingkungan Anda. Jika Anda menggunakan Terraform, file state untuk production harus berada di backend terpisah dengan kontrol akses yang ketat. Kebijakan IAM untuk backend itu seharusnya hanya mengizinkan operasi dari pipeline production, bukan dari akun developer individu.

Misalnya, Anda dapat mengonfigurasi state backend production dengan kebijakan yang menyatakan: "Hanya akun layanan CI/CD yang dapat menulis ke file state ini. Semua orang lain hanya dapat membacanya." Dengan cara ini, bahkan jika seorang developer secara tidak sengaja menjalankan perintah Terraform terhadap production, perintah tersebut akan gagal karena mereka tidak dapat memperoleh kunci state.

Berikut adalah kebijakan IAM Terraform yang menegakkan batasan ini dengan mengizinkan akses tulis hanya ke file state dev sambil menolak akses tulis ke file state prod:

data "aws_iam_policy_document" "state_access" {
  statement {
    sid    = "AllowDevWrite"
    effect = "Allow"
    actions = [
      "s3:PutObject",
      "s3:GetObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/dev/*"
    ]
  }

  statement {
    sid    = "DenyProdWrite"
    effect = "Deny"
    actions = [
      "s3:PutObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/prod/*"
    ]
  }
}

Batasan Bukan Tentang Ketidakpercayaan

Beberapa tim menolak privilege boundary karena mereka merasa itu seperti tanda ketidakpercayaan. "Kami mempekerjakan orang pintar. Mengapa kami tidak bisa mempercayai mereka dengan akses production?"

Pembingkaian ini meleset dari inti permasalahan. Privilege boundary bukan tentang kepercayaan. Ini tentang kejelasan dan akuntabilitas. Ketika semua orang memiliki akses ke segalanya, tidak ada yang tahu siapa yang harus dihubungi ketika sesuatu rusak. Ketika batasan jelas, tim tahu persis siapa yang memiliki setiap lingkungan dan proses apa yang harus diikuti.

Batasan juga melindungi orang yang membuat kesalahan. Seorang developer yang secara tidak sengaja merusak production karena mereka memiliki akses tidak terbatas akan merasa sangat buruk. Mereka juga membuang waktu tim saat semua orang menyelidiki insiden tersebut. Dengan batasan yang jelas, developer yang sama akan dihentikan sebelum perubahan mencapai production. Sistem yang menangkap kesalahan, bukan orangnya.

Daftar Periksa Singkat untuk Menyiapkan Privilege Boundary

Jika Anda meninjau pengaturan saat ini, berikut adalah beberapa hal yang perlu diperiksa:

• Apakah state backend production terpisah dari development dan staging?
• Dapatkah developer menulis ke state production dari laptop mereka?
• Apakah pipeline production memerlukan persetujuan manual?
• Apakah ada pemilik yang jelas untuk setiap lingkungan?
• Apakah perubahan pada konfigurasi production ditinjau oleh pemilik sebelum deployment?

Pemeriksaan ini tidak lengkap, tetapi mencakup celah paling umum yang menyebabkan insiden production.

Apa Selanjutnya

Setelah Anda memiliki privilege boundary dan kepemilikan, tantangan berikutnya adalah menjaga keakuratan state infrastruktur Anda. Terkadang perubahan terjadi di luar alat infrastructure-as-code Anda. Seseorang memodifikasi konfigurasi server secara langsung dari konsol cloud. Seorang anggota tim menerapkan hotfix secara manual selama insiden. Perubahan ini menciptakan penyimpangan (drift) antara state Anda dan kenyataan. Drift merusak keandalan infrastruktur Anda dan membuat perubahan di masa depan menjadi tidak dapat diprediksi. Itu adalah topik yang layak dibahas secara terpisah, tetapi untuk saat ini, langkah pentingnya adalah menetapkan batasan yang jelas terlebih dahulu. Tanpa itu, deteksi dan perbaikan drift menjadi jauh lebih sulit untuk dikelola.