Shared Responsibility #

Salah satu sumber kesalahpahaman dan kegagalan keamanan terbesar ketika organisasi bermigrasi ke cloud computing adalah asumsi bahwa “karena semuanya sudah berada di server cloud, maka semua masalah keamanan dan operasional sudah menjadi tanggung jawab provider”. Asumsi ini sangat keliru dan berbahaya. Di dunia cloud, keamanan adalah upaya kolaboratif yang diatur dalam sebuah kerangka kerja formal yang disebut Shared Responsibility Model (Model Tanggung Jawab Bersama). Memahami pembagian tanggung jawab ini secara presisi bukan hanya penting untuk melindungi data sensitif bisnis kita dari kebocoran, melainkan juga menentukan bagaimana kita merancang arsitektur sistem, memilih jenis layanan cloud yang tepat, mengalokasikan beban kerja tim engineering, serta merespons insiden keamanan secara taktis di dunia nyata.

Apa itu Shared Responsibility Model? #

Shared Responsibility Model adalah matriks pembagian tugas dan batas tanggung jawab hukum serta operasional antara penyedia layanan cloud (cloud provider) dan kita sebagai pengguna (customer). Untuk mempermudah pemahaman arsitekturnya, model ini membagi ranah keamanan menjadi dua pilar utama: Keamanan “OF” the Cloud (Keamanan dari infrastruktur cloud itu sendiri) dan Keamanan “IN” the Cloud (Keamanan dari segala sesuatu yang kita taruh dan operasikan di dalam cloud tersebut).

flowchart TD
    subgraph IN["Keamanan 'IN' the Cloud (Tanggung Jawab Pengguna / Kita)"]
        D["Data & Konten (Enkripsi, Klasifikasi, Backup)"]
        A["Aplikasi (Kode, API, Dependensi Pihak Ketiga)"]
        I["IAM (Autentikasi, Hak Akses Terbatas, MFA)"]
        N["Konfigurasi Jaringan (Security Groups, Firewall, Routing)"]
    end
    
    subgraph OF["Keamanan 'OF' the Cloud (Tanggung Jawab Cloud Provider)"]
        H["Hypervisor & Sistem Operasi Host"]
        N_Phys["Jaringan Fisik (Serat Optik, Router Backbone)"]
        S_Phys["Infrastruktur Server Fisik & Storage Array"]
        P["Keamanan Fisik Data Center (Gedung, Listrik, Pendingin)"]
    end

Keamanan “OF” the Cloud (Tanggung Jawab Provider) #

Cloud provider bertanggung jawab penuh atas fondasi fisik dan virtualisasi yang menyokong seluruh layanan cloud. Kita sebagai pelanggan tidak memiliki akses fisik ke gedung data center, dan kita juga tidak bisa menyentuh server fisik atau hypervisor. Oleh karena itu, provider wajib menjamin keamanan area-area berikut:

• Keamanan Fisik Gedung: Menjaga fasilitas data center dari penyusup, bencana alam, sabotase, serta menyediakan sistem pendingin ruangan (HVAC) dan suplai listrik redundan (UPS dan generator solar).
• Pemeliharaan Hardware: Mengelola pergantian modul RAM yang rusak, harddisk yang mengalami kegagalan sektor, dan penghancuran fisik media penyimpanan lama (disk decommissioning) agar sisa-sisa data pelanggan lama tidak bocor ke pihak luar.
• Layer Virtualisasi (Hypervisor): Mengamankan software hypervisor (seperti KVM atau Xen versi kustom) yang memisahkan satu Virtual Machine (VM) pelanggan dengan VM milik pelanggan lain. Provider harus menjamin tidak terjadi kebocoran memori lintas tenant (misalnya dari eksploitasi celah keamanan CPU seperti Spectre atau Meltdown).

Keamanan “IN” the Cloud (Tanggung Jawab Pengguna / Kita) #

Segala sesuatu yang kita konfigurasikan, instal, dan jalankan di atas layanan cloud tersebut sepenuhnya menjadi tanggung jawab kita sendiri. Provider menyediakan alat-alat keamanan (seperti enkripsi, firewall, dan sistem otentikasi), namun kitalah yang wajib mengaktifkan dan mengonfigurasinya dengan benar. Ranah kita mencakup:

• Keamanan Data: Mengaktifkan enkripsi data saat disimpan (encryption at-rest) menggunakan kunci enkripsi (KMS) dan enkripsi saat data dikirim (encryption in-transit) menggunakan protokol SSL/TLS yang aman.
• Keamanan Aplikasi & Dependensi: Menulis kode yang aman dari celah SQL Injection, XSS, atau broken authentication, serta memastikan dependensi pihak ketiga (library npm, Go module, dll.) bebas dari celah keamanan aktif.
• Manajemen Identitas & Akses (IAM): Mengatur siapa saja anggota tim yang boleh mengakses konsol manajemen cloud, membatasi hak akses berdasarkan prinsip least privilege, serta mewajibkan penggunaan Multi-Factor Authentication (MFA) untuk seluruh akun.
• Konfigurasi Jaringan Virtual: Mengatur aturan firewall virtual (seperti Security Groups di AWS atau Firewall Rules di GCP) untuk membatasi port jaringan yang terbuka ke internet publik.

Pembagian Tanggung Jawab Berdasarkan Model Layanan #

Batas demarkasi antara tanggung jawab kita dan provider tidak pernah statis. Batas tersebut bergeser secara dinamis tergantung pada model layanan cloud yang kita pilih: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), atau Software as a Service (SaaS).

flowchart TD
    subgraph Boundary["Pergeseran Batas Tanggung Jawab"]
        direction LR
        OnPrem["On-Premise<br>(100% Tanggung Jawab Kita)"] --> IaaS["IaaS<br>(~60% Tanggung Jawab Kita)"]
        IaaS --> PaaS["PaaS<br>(~30% Tanggung Jawab Kita)"]
        PaaS --> SaaS["SaaS<br>(~10% Tanggung Jawab Kita)"]
    end

Tabel di bawah ini memetakan pembagian tanggung jawab secara rinci untuk setiap layer infrastruktur:

Legend: Kita = Tanggung Jawab Tim Pengguna | Provider = Tanggung Jawab Cloud Provider

IaaS — Kontrol Tinggi, Tanggung Jawab Tinggi #

Pada model IaaS (seperti AWS EC2, Google Compute Engine, atau Azure VM), cloud provider hanya meminjamkan hardware virtual kosong. Kita diberikan akses root atau administrator penuh ke sistem operasi VM tersebut. Hal ini memberikan fleksibilitas arsitektur yang sangat luar biasa, namun menuntut tanggung jawab operasional yang juga maksimal dari tim kita.

flowchart TD
    subgraph IaaS_Responsibilities["Tanggung Jawab Kita di IaaS"]
        direction TB
        OS["Sistem Operasi (Patching & Update kernel)"]
        FW["Firewall OS (iptables/ufw) & Antivirus"]
        App["App Stack (Node.js, Nginx, Runtime)"]
        Sec["Manajemen Kredensial SSH / RDP"]
        Data["Enkripsi & Backup Data VM"]
    end

Konsekuensi Operasional di IaaS #

• OS Patching & Upgrade: Jika ditemukan celah keamanan kritis pada kernel Linux sistem operasi VM kita (seperti kerentanan Dirty Pipe atau Heartbleed), provider tidak akan meng-update VM kita secara otomatis. Kita harus memiliki mekanisme otomatisasi (seperti Ansible playbook atau AWS Systems Manager Patch Manager) untuk melakukan proses patching secara berkala.
• Hardening Port Jaringan: Jika kita membuka port SSH (22) ke publik (0.0.0.0/0) dengan metode login password tanpa SSH Key, dan VM kita diretas akibat serangan brute-force, itu adalah kelalaian kita sepenuhnya. Provider hanya menjamin bahwa router fisik mereka aman, bukan mengurusi kredensial login VM kita.

Berikut adalah contoh skrip otomatisasi Bash sederhana yang biasa kita gunakan untuk melakukan security patching pada VM IaaS berbasis Ubuntu/Debian secara berkala demi memenuhi tanggung jawab keamanan OS kita:

#!/bin/bash
# ✓ BENAR: Jalankan security patching otomatis secara berkala pada VM IaaS

set -euo pipefail

log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - [SECURITY-PATCH]: $1"
}

log_message "Memulai pemeriksaan pembaruan keamanan..."

# Memperbarui daftar paket dari repository resmi
apt-get update -y

# Menjalankan upgrade hanya untuk paket-paket keamanan (Security Updates)
# Mencegah breaking changes akibat upgrade paket aplikasi umum tanpa sengaja
apt-get install --only-upgrade -y $(apt-get --just-print upgrade | awk '/Inst/ { print $2 }' | grep -i security || true)

log_message "Pembaruan keamanan berhasil diterapkan."

# Memeriksa apakah VM memerlukan restart setelah patching kernel
if [ -f /var/run/reboot-required ]; then
    log_message "VM membutuhkan restart. Menjadwalkan restart aman..."
    # JANGAN langsung reboot jika VM sedang melayani trafik produksi aktif tanpa koordinasi Load Balancer
    # reboot
fi

PaaS — Keseimbangan Kontrol dan Kemudahan #

Pada model PaaS (seperti AWS RDS untuk database managed, Google App Engine, atau Heroku), cloud provider mengabstraksi seluruh sistem operasi, runtime, dan middleware. Kita tidak lagi memiliki akses masuk via SSH ke server database atau server runtime tersebut. Fokus kita menyusut secara dramatis hanya pada aplikasi dan data.

flowchart TD
    subgraph PaaS_Responsibilities["Tanggung Jawab Kita di PaaS"]
        direction TB
        AppCode["Tulis Kode Aplikasi yang Aman"]
        DBAccess["Konfigurasi User & Hak Akses Database"]
        SSL["Konfigurasi SSL/TLS & Enkripsi Data"]
        Secrets["Manajemen API Keys & Secrets secara Aman"]
    end

Keuntungan Keamanan di PaaS #

Kita terbebas dari pusingnya melakukan patching sistem operasi, konfigurasi backup harian di level cron job, serta penataan replikasi database primer-sekunder. Semua hal tersebut dapat kita aktifkan hanya dengan mencentang satu tombol konfigurasi di konsol cloud provider.

Tanggung Jawab Kita yang Tersisa di PaaS #

Meskipun sistem operasi database dikelola oleh provider, kita tetap bertanggung jawab atas tata kelola otorisasi database. Kita wajib membuat akun pengguna database dengan hak akses seminimal mungkin (least privilege) dan melarang aplikasi web kita login menggunakan akun root database. Kita juga wajib memastikan kode aplikasi terbebas dari celah SQL Injection yang dapat mengekspos isi database tersebut ke luar jaringan.

Berikut adalah contoh konfigurasi deklaratif menggunakan Terraform (Infrastructure as Code) untuk mendeploy database RDS (PaaS) secara aman dengan mengaktifkan enkripsi menggunakan KMS, menaruhnya di subnet privat (isolasi jaringan), dan mewajibkan SSL/TLS:

# ✓ BENAR: Mengamankan database managed (PaaS) dengan enkripsi KMS & isolasi jaringan
resource "aws_db_instance" "secure_database" {
  allocated_storage      = 20
  engine                 = "postgres"
  engine_version         = "15.4"
  instance_class         = "db.t3.medium"
  db_name                = "production_db"
  username               = "app_user" # JANGAN gunakan nama 'admin' atau 'root'
  password               = var.database_password
  
  # Menaruh database di subnet privat agar tidak bisa diakses langsung dari internet
  db_subnet_group_name   = aws_db_subnet_group.private_subnets.name
  vpc_security_group_ids = [aws_security_group.db_sg.id]
  
  # Mengaktifkan enkripsi penyimpanan menggunakan KMS Key
  storage_encrypted      = true
  kms_key_id             = aws_kms_key.db_encryption_key.arn
  
  # Menonaktifkan akses publik secara absolut
  publicly_accessible    = false
  
  # Menjamin database tidak langsung terhapus tanpa backup saat didelete via terraform
  skip_final_snapshot    = false
  final_snapshot_identifier = "prod-db-final-snapshot"
}

SaaS — Kontrol Minimal, Tanggung Jawab Terfokus #

Pada model SaaS (seperti Google Workspace, Microsoft 365, Slack, atau Salesforce), kita menyewa aplikasi siap pakai. Seluruh infrastruktur komputasi, database, enkripsi media penyimpanan, dan kode aplikasi dikelola penuh oleh provider. Tanggung jawab teknis kita hampir nol, namun tanggung jawab terhadap tata kelola data dan manajemen akses pengguna tetap menjadi milik kita 100%.

flowchart TD
    subgraph SaaS_Responsibilities["Tanggung Jawab Kita di SaaS"]
        direction TB
        Users["User Provisioning (Manajemen Akun Karyawan)"]
        Roles["Role & Permission (Siapa boleh melihat/ekspor data)"]
        MFA["Multi-Factor Authentication (MFA) Enforcement"]
        DataGov["Kebijakan Sharing Dokumen ke Publik"]
    end

Area Kritis Tanggung Jawab SaaS #

1. User Lifecycle Management: Saat seorang karyawan keluar (resign) dari perusahaan, kita wajib segera mencabut akses akun Google Workspace atau Slack mereka. Jika kita lalai, mantan karyawan tersebut masih bisa mengunduh data sensitif perusahaan secara ilegal, dan itu adalah kegagalan tata kelola di sisi kita, bukan kesalahan sistem Google atau Slack.
2. Mewajibkan MFA (Multi-Factor Authentication): Kebocoran data terbesar di aplikasi SaaS tidak terjadi karena server SaaS diretas, melainkan karena pengguna menggunakan password yang lemah atau terkena serangan phishing. Kita wajib memaksakan aktivasi MFA untuk seluruh akun karyawan.
3. Data Sharing Governance: Kita wajib menetapkan aturan di admin console SaaS agar dokumen internal perusahaan tidak bisa diubah statusnya menjadi “dapat diakses oleh siapa saja yang memiliki link” tanpa persetujuan tim keamanan.

Implikasi Praktis bagi Bisnis & Tim Engineering #

Bagaimana kita menerapkan pemahaman Shared Responsibility Model ini ke dalam operasional tim engineering sehari-hari?

1. Metodologi Threat Modeling (Pemodelan Ancaman) #

Ketika merancang arsitektur aplikasi baru, tim security kita harus menyesuaikan skenario ancaman berdasarkan model layanan yang dipilih. Jika kita bermigrasi dari IaaS ke PaaS, kita dapat menghapus daftar ancaman “akses root ilegal ke OS” dari daftar mitigasi kita karena tanggung jawab tersebut sudah diambil alih oleh provider, sehingga tim kita bisa fokus penuh pada threat modeling di level API dan enkripsi data aplikasi.

2. Kepatuhan Regulasi Industri (Compliance) #

Jika perusahaan kita membutuhkan sertifikasi PCI-DSS (untuk transaksi kartu kredit) atau ISO 27001, perlu diingat bahwa sertifikasi kepatuhan milik provider tidak otomatis membuat aplikasi kita patuh.

• AWS atau Google Cloud bersertifikat ISO 27001 hanya membuktikan bahwa gedung data center mereka aman secara fisik.
• Auditor eksternal akan tetap memeriksa konfigurasi internal sistem kita: apakah database kita dienkripsi, apakah port jaringan dikonfigurasi dengan benar, dan apakah tim kita mengaktifkan logging audit.

Kesalahan Umum & Anti-Pattern #

Berikut adalah beberapa pola kesalahan fatal di industri akibat tidak memahami shared responsibility secara benar:

// ANTI-PATTERN: Menganggap semuanya otomatis aman karena "sudah di cloud"
- Mengunggah file kredensial (API Keys / Service Account) ke repositori git publik.
- Membuat S3 Bucket/Cloud Storage dengan akses publik tanpa enkripsi agar mempermudah integrasi aplikasi frontend.
- Memberikan hak akses "AdministratorAccess" di IAM kepada seluruh developer tanpa MFA untuk mempercepat proses koding.
- Membiarkan VM IaaS berjalan bertahun-tahun tanpa update OS kernel karena mengira cloud provider otomatis memperbaruinya.

// BENAR: Kelola tanggung jawab keamanan di sisi kita secara disiplin
- Menggunakan Secret Manager (seperti HashiCorp Vault atau AWS Secrets Manager) untuk menyimpan kredensial aplikasi.
- Memblokir seluruh akses publik ke Object Storage secara default, menggunakan signed URL untuk akses terbatas.
- Menerapkan Principle of Least Privilege pada IAM dan memaksakan MFA tanpa toleransi untuk semua user.
- Membangun pipeline otomatisasi patching OS berkala menggunakan Ansible, Terraform, atau Patch Manager.

Ringkasan #

• Provider bertanggung jawab atas keamanan OF the cloud, sedangkan kita bertanggung jawab atas keamanan IN the cloud — provider mengamankan infrastruktur fisik dan hypervisor, kita mengamankan konfigurasi data, sistem akses, dan kode aplikasi.
• Batas tanggung jawab bergeser secara dinamis — IaaS memberikan kontrol terbesar namun membebankan tanggung jawab operasional tertinggi (seperti patching OS), sementara SaaS meminimalkan beban teknis kita hingga tersisa pada tata kelola akses user dan klasifikasi data.
• Data dan IAM selalu menjadi tanggung jawab pengguna — apa pun model layanan yang kita pilih (IaaS, PaaS, atau SaaS), privasi data, otorisasi akses, serta konfigurasi enkripsi tetap berada di tangan kita.
• Kesalahan konfigurasi pengguna adalah celah keamanan terbesar di cloud — mayoritas insiden kebocoran data berskala besar di dunia terjadi akibat miskonfigurasi pengguna (seperti bucket storage publik atau password tanpa MFA), bukan karena infrastruktur fisik cloud provider berhasil ditembus.
• Sertifikasi kepatuhan provider bersifat komplementer — sertifikasi keamanan fisik data center milik provider tidak otomatis membuat sistem aplikasi kita patuh regulasi industri tanpa adanya audit independen pada sisi konfigurasi kita.

← Sebelumnya: Mitos atau Miskonsepsi   Berikutnya: Elasticity vs Scalability →