SECURITY PRINCIPLES

Keamanan udah jadi buzzword; tiap perusahaan pengen ngakuin produk atau layanan mereka aman. Tapi beneran aman ga sih?

Sebelum kita mulai bahas prinsip-prinsip keamanan yang beda-beda, penting banget buat tau musuh yang lagi kita lawan buat ngelindungin aset kita. Lu lagi nyoba ngelarang anak kecil buat akses laptop lu? Atau lu lagi nyoba ngelindungin laptop yang isinya desain teknis yang harganya jutaan dolar? Pake mekanisme perlindungan yang sama buat anak kecil sama aktor spionase industri itu konyol banget. Makanya, tau musuh kita tuh wajib biar kita bisa belajar soal serangan mereka dan mulai implementasi kontrol keamanan yang pas.

Ga mungkin dapetin keamanan yang sempurna; ga ada solusi yang 100% aman. Makanya, kita nyoba ningkatin postur keamanan kita biar makin susah buat musuh kita dapetin akses.

TUJUAN PEMBELAJARAN

• Jelasin fungsi keamanan: Confidentiality, Integrity and Availability (CIA).
• Nampilin kebalikan dari security triad, CIA: Disclosure, Alteration, and Destruction/Denial (DAD).
• Ngenalin konsep dasar model keamanan, kaya model Bell-LaPadula.
• Jelasin prinsip keamanan kaya Defence-in-Depth, Zero Trust, dan Trust but Verify.
• Ngenalin ISO/IEC 19249.
• Jelasin perbedaan antara Vulnerability, Threat, dan Risk.

Supaya kita bisa nyebut sesuatu itu aman, kita perlu mikirin lebih dalem apa aja yang bikin keamanan itu ada. Pas lu mau nilai keamanan sistem, lu perlu mikir dalem security triad: confidentiality, integrity, and availability (CIA).

• Confidentiality mastiin kalo cuma orang atau penerima yang dituju yang bisa akses data.
• Integrity tujuannya mastiin kalo data ga bisa diubah; apalagi, kita bisa deteksi perubahan apapun kalo itu kejadian.
• Availability tujuannya mastiin kalo sistem atau layanan bisa dipake pas dibutuhin.

Yuk kita pertimbangin security triad CIA dalam kasus order belanja online:

• Confidentiality: Pas belanja online, lu ngeharap nomor kartu kredit lu cuma dikasih ke pihak yang ngurusin pembayaran. Kalo lu ragu info kartu kredit lu bakal dikasih ke pihak ga dipercaya, lu kayanya bakal mikir-mikir lagi buat lanjutin transaksi. Apalagi, kalo kebocoran data nyebabin kebongkarnya informasi pribadi, termasuk kartu kredit, perusahaan bakal nanggung kerugian gede di banyak level.
• Integrity: Abis ngisi order lu, kalo penyusup bisa ubah alamat pengiriman yang udah lu kasih, paketnya bakal dikirim ke orang lain. Tanpa integritas data, lu mungkin jadi males banget buat order sama penjual ini.
• Availability: Buat order online, lu bakal browse website toko atau pake aplikasi resminya. Kalo layanannya ga bisa dipake, lu ga bakal bisa browse produk atau order. Kalo lu terus-terusan ngadepin masalah teknis kaya gitu, lu mungkin ujung-ujungnya nyerah dan mulai nyari toko online lain.

Yuk kita pertimbangin CIA dalam kaitannya sama rekam medis pasien dan sistem terkait:

• Confidentiality: Berdasarkan macem-macem hukum di negara modern, penyedia layanan kesehatan kudu mastiin dan ngejaga confidentiality rekam medis. Makanya, penyedia layanan kesehatan bisa dituntut secara hukum kalo mereka ilegal ngebongkar rekam medis pasien mereka.
• Integrity: Kalo rekam medis pasien ga sengaja atau sengaja diubah, itu bisa nyebabin penanganan yang salah dikasih, yang ujung-ujungnya bisa nyebabin situasi yang ngancem nyawa. Makanya, sistem bakal ga berguna dan malah mungkin bahaya tanpa mastiin integritas rekam medis.
• Availability: Pas pasien dateng ke klinik buat follow up kondisi medis mereka, sistemnya kudu available. Sistem yang ga available artinya praktisi medis ga bisa akses rekam medis pasien dan makanya ga bakal tau kalo ada gejala sekarang yang berhubungan sama riwayat medis pasien. Situasi ini bisa bikin diagnosis medis jadi lebih susah dan gampang salah.

Penekanannya ga kudu sama di ketiga fungsi keamanan. Contohnya pengumuman universitas; meskipun biasanya ga confidential, integritas dokumennya itu penting banget.

DILUAR CIA

Lebih jauh lagi dari security triad CIA, kita bisa mikirin:

• Authenticity: Authentic artinya ga palsu atau tiruan. Authenticity itu soal mastiin kalo dokumen/file/data asalnya dari sumber yang diklaim.
• Nonrepudiation: Repudiate artinya nolak buat ngakuin validitas sesuatu. Nonrepudiation mastiin kalo sumber aslinya ga bisa nyangkal kalo mereka sumber dari dokumen/file/data tertentu. Karakteristik ini penting banget buat macem-macem domain, kaya belanja, diagnosis pasien, dan perbankan.

Dua kebutuhan ini berhubungan deket. Kebutuhan buat bedain file atau order yang authentic dari yang palsu itu penting banget. Apalagi, mastiin pihak lain ga bisa nyangkal jadi sumbernya itu vital biar banyak sistem bisa dipake.

Di belanja online, tergantung bisnis lu, lu mungkin masih toleransi nyoba kirim kaos pake cash-on-delivery dan baru tau belakangan kalo penerimanya ga pernah order itu. Tapi, ga ada perusahaan yang bisa toleransi kirim 1000 mobil terus baru nyadar kalo ordernya palsu. Di contoh order belanja, lu pengen mastiin kalo pelanggan yang disebutin emang beneran order ini; itu authenticity. Apalagi, lu pengen mastiin mereka ga bisa nyangkal udah order; itu nonrepudiation.

Sebagai perusahaan, kalo lu nerima order pengiriman 1000 mobil, lu perlu mastiin authenticity order ini; apalagi, sumbernya ga boleh bisa nyangkal udah bikin order kaya gitu. Tanpa authenticity dan nonrepudiation, bisnis ga bisa jalan.

Parkerian Hexad Tahun 1998, Donn Parker ngajuin Parkerian Hexad, set elemen keamanan yang isinya enam. Ini dia:

• Availability
• Utility
• Integrity
• Authenticity
• Confidentiality
• Possession

Kita udah bahas empat dari enam elemen di atas. Yuk kita bahas dua elemen sisanya:

• Utility: Utility fokus ke kebermanfaatan informasi. Contohnya, user mungkin aja kehilangan decryption key buat akses laptop dengan penyimpanan terenkripsi. Meskipun user-nya masih punya laptop sama disk-nya utuh, mereka ga bisa akses mereka. Singkatnya, meskipun masih available, informasinya dalam bentuk yang ga berguna, alias ga ada utility-nya.
• Possession: Elemen keamanan ini butuh kita buat ngelindungin informasi dari pengambilan, penyalinan, atau pengontrolan ga sah. Contohnya, musuh mungkin ngambil drive backup, artinya kita kehilangan possession informasi selama mereka punya drive-nya. Atau, musuh mungkin berhasil enkripsi data kita pake ransomware; ini juga nyebabin kehilangan possession data.

Keamanan sistem diserang lewat salah satu dari beberapa cara. Bisa lewat pembongkaran data rahasia, perubahan data, atau penghancuran data.

• Disclosure itu kebalikan dari confidentiality. Singkatnya, pembongkaran data confidential bakal jadi serangan ke confidentiality.
• Alteration itu kebalikan dari Integrity. Contohnya, integritas cek itu penting banget.
• Destruction/Denial itu kebalikan dari Availability.

Kebalikan dari CIA Triad bakal jadi DAD Triad: Disclosure, Alteration, and Destruction.

Pertimbangin contoh rekam medis pasien dan sistem terkait sebelumnya:

• Disclosure: Kaya di kebanyakan negara modern, penyedia layanan kesehatan harus ngejaga confidentiality rekam medis. Alhasil, kalo penyerang berhasil nyuri beberapa rekam medis ini dan nge-dump mereka online buat diliat publik, penyedia layanan kesehatan bakal nanggung kerugian gara-gara serangan data disclosure ini.
• Alteration: Pertimbangin beratnya situasi kalo penyerang berhasil modifikasi rekam medis pasien. Serangan alteration ini mungkin nyebabin penanganan yang salah dikasih, dan makanya, serangan alteration ini bisa ngancem nyawa.
• Destruction/Denial: Pertimbangin kasus di mana fasilitas medis udah bener-bener paperless. Kalo penyerang berhasil bikin sistem database ga available, fasilitas ga bakal bisa fungsi dengan bener. Mereka bisa balik lagi ke kertas sementara; tapi, rekam medis pasien ga bakal available. Serangan denial ini bakal ngestop seluruh fasilitas.

Ngelindungin dari disclosure, alteration, and destruction/denial itu penting banget. Perlindungan ini setara sama usaha buat ngejaga confidentiality, integrity and availability.

Ngelindungin confidentiality dan integrity sampe ekstrem bisa ngebatasin availability, dan ningkatin availability sampe ekstrem bisa nyebabin kehilangan confidentiality dan integrity. Implementasi prinsip keamanan yang bagus butuh keseimbangan di antara ketiganya.

Kita udah belajar kalo security triad diwakilin sama Confidentiality, Integrity, and Availability (CIA). Mungkin ada yang nanya, gimana cara kita bikin sistem yang mastiin satu atau lebih fungsi keamanan? Jawabannya ada di pake model keamanan. Di task ini, kita bakal ngenalin tiga model keamanan dasar:

• Model Bell-LaPadula
• Model Integritas Biba
• Model Clark-Wilson

Model Bell-LaPadula Model Bell-LaPadula tujuannya dapetin confidentiality dengan cara nyebutin tiga aturan:

• Simple Security Property: Properti ini disebut “no read up”; ini nyebutin kalo subject di level keamanan lebih rendah ga bisa baca object di level keamanan lebih tinggi. Aturan ini nyegah akses ke informasi sensitif di atas level otorisasi.
• Star Security Property: Properti ini disebut “no write down”; ini nyebutin kalo subject di level keamanan lebih tinggi ga bisa nulis ke object di level keamanan lebih rendah. Aturan ini nyegah kebongkar informasi sensitif ke subject dengan level keamanan lebih rendah.
• Discretionary-Security Property: Properti ini pake access matrix buat ngebolehin operasi baca dan tulis. Contoh access matrix ditampilin di tabel di bawah dan dipake barengan sama dua properti pertama.

Subject	Object A	Object B
Subject 1	Write	No access
Subject 2	Read/Write	Read

Dua properti pertama bisa diringkas jadi “write up, read down.” Lu bisa bagiin informasi confidential sama orang dengan security clearance lebih tinggi (write up), dan lu bisa nerima informasi confidential dari orang dengan security clearance lebih rendah (read down).

Ada beberapa batasan buat model Bell-LaPadula. Contohnya, dia ga didesain buat nanganin file-sharing.

Model Biba Model Biba tujuannya dapetin integritas dengan cara nyebutin dua aturan utama:

• Simple Integrity Property: Properti ini disebut “no read down”; subject integritas lebih tinggi ga boleh baca dari object integritas lebih rendah.
• Star Integrity Property: Properti ini disebut “no write up”; subject integritas lebih rendah ga boleh nulis ke object integritas lebih tinggi.

Dua properti ini bisa diringkas jadi “read up, write down.” Aturan ini kontras sama Model Bell-LaPadula, dan ini ga heran soalnya yang satu mikirin confidentiality sementara yang lain mikirin integritas.

Model Biba punya macem-macem batasan. Salah satu contohnya dia ga nanganin ancaman internal (insider threat).

Model Clark-Wilson Model Clark-Wilson juga tujuannya dapetin integritas dengan pake konsep-konsep ini:

• Constrained Data Item (CDI): Ini ngarah ke tipe data yang integritasnya pengen kita jaga.
• Unconstrained Data Item (UDI): Ini ngarah ke semua tipe data di luar CDI, kaya input user dan sistem.
• Transformation Procedures (TPs): Prosedur ini operasi yang diprogram, kaya baca dan tulis, dan harus ngejaga integritas CDI.
• Integrity Verification Procedures (IVPs): Prosedur ini ngecek dan mastiin validitas CDI.

Kita cuma bahas tiga model keamanan. Pembaca bisa explore banyak model keamanan tambahan. Contohnya termasuk:

• Model Brewer and Nash
• Model Goguen-Meseguer
• Model Sutherland
• Model Graham-Denning
• Model Harrison-Ruzzo-Ullman

Pertahanan Berlapis (Defence-in-Depth) itu maksudnya bikin sistem keamanan yang levelnya banyak; makanya ini juga dipanggil Keamanan Multi-Level.

Coba lu bayangin analogi gini: lu punya laci kekunci buat nyimpen dokumen penting sama barang-barang berharga lu. Lacinya emang kekunci; tapi, apa lu yakin kunci laci doang cukup buat ngelindungin barang-barang mahal lu dari maling? Kalo kita mikir pake konsep keamanan multi-level, pasti kita maunya ga cuma laci yang kekunci, tapi juga materinya kekunci, pintu utama apartemen kekunci, gerbang gedung kekunci, malah mungkin lu tambahin beberapa kamera keamanan sekalian di jalan. Emang sih, keamanan berlapis-lapis kaya gini ga bakal bisa ngestop semua maling, tapi seengganya bisa ngehalangin sebagian besar dan bikin yang bandel sekalipun jadi mikir dua kali.

The International Organization for Standardization (ISO) sama International Electrotechnical Commission (IEC) udah bikin ISO/IEC 19249. Di materi ini, kita bakal bahas dikit soal ISO/IEC 19249:2017 Teknologi informasi – Teknik keamanan – Katalog prinsip arsitektur dan desain buat produk, sistem, dan aplikasi yang aman. Tujuannya biar kita punya gambaran lebih oke soal apa yang diajarin organisasi internasional tentang prinsip keamanan.

ISO/IEC 19249 nyebutin lima prinsip arsitektur:

• Pemisahan Domain (Domain Separation): Tiap set komponen yang berhubungan dikelompokkin jadi satu entitas; komponennya bisa aplikasi, data, atau sumber daya lain. Tiap entitas bakal punya domain sendiri dan dikasih set atribut keamanan yang sama. Contohnya, bayangin level privilege prosesor x86: kernel sistem operasi bisa jalan di ring 0 (level privilege paling tinggi). Sementara itu, aplikasi mode user bisa jalan di ring 3 (level privilege paling rendah). Pemisahan domain termasuk di Model Goguen-Meseguer.
• Pelapisan (Layering): Pas sistem distrukturin jadi banyak level atau lapisan abstrak, jadi mungkin buat maksain kebijakan keamanan di level yang beda-beda; apalagi, bakal lebih gampang buat validasi operasi. Coba bayangin model OSI (Open Systems Interconnection) dengan tujuh lapisannya di jaringan. Tiap lapisan di model OSI nyediain layanan spesifik buat lapisan di atasnya. Pelapisan ini bikin mungkin buat maksain kebijakan keamanan dan gampang validasi kalo sistemnya kerja sesuai yang dimau. Contoh lain dari dunia pemrograman tuh operasi disk; programmer biasanya pake fungsi baca dan tulis disk yang disediain bahasa pemrograman tingkat tinggi yang dipilih. Bahasa pemrograman nyembunyiin system call tingkat rendah dan nampilin mereka sebagai metode yang lebih user-friendly. Pelapisan berhubungan sama Pertahanan Berlapis (Defence in Depth).
• Enkapsulasi (Encapsulation): Di pemrograman berorientasi objek (OOP), kita nyembunyiin implementasi tingkat rendah dan nyegah manipulasi langsung data di objek dengan cara nyediain metode spesifik buat tujuan itu. Contohnya, kalo lu punya objek jam, lu bakal nyediain metode increment() daripada ngasih user akses langsung ke variabel detik. Tujuannya buat nyegah nilai ga valid buat variabel lu. Mirip kaya gitu, di sistem yang lebih gede, lu bakal pake (atau malah desain) Application Programming Interface (API) yang beneran pas yang aplikasi lu bakal pake buat akses database.
• Redundansi (Redundancy): Prinsip ini mastiin availability dan integritas. Ada banyak contoh yang berhubungan sama redundansi. Bayangin kasus server hardware dengan dua power supply bawaan: kalo satu power supply rusak, sistem tetep jalan. Bayangin konfigurasi RAID 5 dengan tiga drive: kalo satu drive rusak, data tetep available pake dua drive sisanya. Apalagi, kalo data diubah ga bener di salah satu disk, itu bakal kedeteksi via paritas, mastiin integritas data.
• Virtualisasi (Virtualization): Dengan munculnya layanan cloud, virtualisasi jadi lebih umum dan populer. Konsep virtualisasi tuh bagiin satu set hardware tunggal di antara banyak sistem operasi. Virtualisasi nyediain kemampuan sandboxing yang ningkatin batasan keamanan, secure detonation, dan pengamatan program jahat.

ISO/IEC 19249 ngajarin lima prinsip desain:

• Least Privilege (Hak Istimewa Terendah): Lu juga bisa nyebutin ini secara informal sebagai “berbasis kebutuhan” atau “berbasis need-to-know” pas lu jawab pertanyaan, “siapa yang bisa akses apa?” Prinsip least privilege ngajarin kalo lu harus nyediain jumlah izin paling dikit buat seseorang buat ngelakuin tugas mereka dan ga lebih dari itu. Contohnya, kalo user perlu bisa liat dokumen, lu harusnya kasih mereka hak baca tanpa hak tulis.
• Attack Surface Minimisation (Minimalisasi Permukaan Serangan): Tiap sistem punya kerentanan yang mungkin dipake penyerang buat kompromiin sistem. Beberapa kerentanan udah dikenal, sementara yang lain belom ditemuin. Kerentanan ini ngewakilin risiko yang harusnya kita tuju buat diminimalisir. Contohnya, di salah satu langkah buat hardening sistem Linux, kita bakal matiin layanan apapun yang ga kita butuhin.
• Centralized Parameter Validation (Validasi Parameter Terpusat): Banyak ancaman gara-gara sistem nerima input, apalagi dari user. Input ga valid bisa dipake buat eksploitasi kerentanan di sistem, kaya denial of service dan eksekusi kode jarak jauh. Makanya, validasi parameter itu langkah perlu buat mastiin kondisi sistem bener. Ngeliat jumlah parameter yang diurus sistem, validasi parameter harusnya dipusatin di dalem satu library atau sistem.
• Centralized General Security Services (Layanan Keamanan Umum Terpusat): Sebagai prinsip keamanan, kita harusnya tuju buat pusat semua layanan keamanan. Contohnya, kita bakal bikin server terpusat buat autentikasi. Pastinya, lu mungkin ngambil langkah yang pas buat mastiin availability dan nyegah bikin single point of failure.
• Preparing for Error and Exception Handling (Siap-siap buat Error dan Penanganan Eksepsi): Kapanpun kita ngebangun sistem, kita harusnya pertimbangin kalo error dan eksepsi emang kejadian dan bakal kejadian. Contohnya, di aplikasi belanja, pelanggan mungkin nyoba order barang yang stoknya abis. Database mungkin overload dan berenti ngerespon aplikasi web. Prinsip ini ngajarin kalo sistem harusnya didesain buat fail safe; contohnya, kalo firewall crash, dia harusnya ngeblokir semua trafik daripada ngebolehin semua trafik. Apalagi, kita harusnya hati-hati pesan error ga ngebocorin informasi yang kita anggap confidential, kaya nge-dump konten memory yang isinya informasi yang berhubungan sama pelanggan lain.

Di pertanyaan berikut, liat prinsip desain ISO/IEC 19249 lima di atas. Jawab pake angka antara 1 dan 5, tergantung nomor prinsip desainnya.

Kepercayaan (Trust) itu topik yang kompleks banget; aslinya, kita ga bisa fungsi tanpa kepercayaan. Kalo ada orang mikir vendor laptop udah masangin spyware di laptopnya, mereka kayanya bakal ujung-ujungnya bangun ulang sistemnya. Kalo ada orang ga percaya sama vendor hardware, mereka bakal berenti total pake hardware-nya. Kalo kita mikirin kepercayaan di level bisnis, urusannya cuma jadi makin ribet; tapi, kita butuh beberapa prinsip keamanan sebagai panduan. Dua prinsip keamanan yang menarik buat kita soal kepercayaan:

• Trust but Verify (Percaya tapi Verifikasi)
• Zero Trust (Tanpa Kepercayaan)

Trust but Verify (Percaya tapi Verifikasi): Prinsip ini ngajarin kalo kita harus selalu verifikasi bahkan pas kita percaya sama entitas dan kelakuannya. Entitas bisa user atau sistem. Verifikasi biasanya butuh nyiapin mekanisme logging yang bener; verifikasi nunjukkin ngecek log buat mastiin semuanya normal. Kenyataannya, ga mungkin buat verifikasi semuanya; coba aja bayangin kerjaan yang dibutuhin buat review semua aksi yang dilakuin satu entitas aja, kaya halaman internet yang di-browse satu user. Ini butuh mekanisme keamanan otomatis, kaya proxy, intrusion detection, dan sistem intrusion prevention.

Zero Trust (Tanpa Kepercayaan): Prinsip ini nganggap kepercayaan sebagai kerentanan, dan makanya, dia ngurusin ancaman yang berhubungan sama orang dalem (insider-related threats). Abis nganggep kepercayaan sebagai kerentanan, zero trust nyoba ngilanginnya. Dia ngajarin secara ga langsung, “jangan pernah percaya, selalu verifikasi.” Singkatnya, tiap entitas dianggap musuh sampe kebukti sebaliknya. Zero trust ga ngasih kepercayaan ke perangkat berdasarkan lokasi atau kepemilikannya. Pendekatan ini kontras sama model lama yang bakal percaya jaringan internal atau perangkat punya perusahaan. Autentikasi dan otorisasi dibutuhin sebelum akses sumber daya apapun. Hasilnya, kalo ada pelanggaran keamanan kejadian, kerugian bakal lebih terbatas kalo arsitektur zero trust udah diimplementasiin.

Microsegmentation itu salah satu implementasi yang dipake buat Zero Trust. Ini ngarah ke desain di mana segmen jaringan bisa sekecil host tunggal. Apalagi, komunikasi antar segmen butuh autentikasi, cek access control list, dan kebutuhan keamanan lain.

Ada batasan seberapa banyak kita bisa aplikasiin zero trust tanpa ngasih dampak negatif ke bisnis; tapi, ini ga berarti kita ga boleh aplikasiin selama itu masih mungkin.

Ada tiga istilah yang perlu kita catet biar ga ada bingung-bingung lagi.

• Vulnerability (Kerentanan): Vulnerable artinya gampang diserang atau dirusak. Di keamanan informasi, vulnerability itu kelemahan.
• Threat (Ancaman): Threat itu potensi bahaya yang berhubungan sama kelemahan atau vulnerability ini.
• Risk (Risiko): Risk itu soal kemungkinan threat actor ngeksploitasi vulnerability dan dampak yang diakibatin ke bisnis.

Jauhin dulu sistem informasi deh, contoh gampangnya gini: showroom dengan pintu dan jendela dari kaca standar punya kelemahan, atau vulnerability, gara-gara sifat kaca itu sendiri. Makanya, ada threat kalo pintu dan jendela kaca bisa dipecahin. Yang punya showroom harus mikirin risk-nya, misalnya kemungkinan pintu atau jendela kaca dipecahin dan dampak yang diakibatin ke bisnis.

Contoh lain yang langsung berhubungan sama sistem informasi nih. Lu kerja di rumah sakit yang pake sistem database tertentu buat nyimpen semua rekam medis. Suatu hari, lu lagi ngikutin berita keamanan terbaru, terus lu tau kalo sistem database yang dipake ga cuma vulnerable tapi juga kode exploit proof-of-concept yang beneran jalan udah dirilis; kode exploit yang dirilis itu nunjukkin kalo threat-nya beneran nyata. Dengan tau ini, lu kudu pertimbangin risk yang diakibatin dan mutusin langkah selanjutnya.

Kita bakal bahas threat dan risk lebih detail di materi lain.

Materi ini udah ngebahas macem-macem prinsip dan konsep yang berhubungan sama keamanan. Sekarang, lu harusnya udah bener-bener familiar sama CIA dan DAD dan istilah lain kaya authenticity, repudiation, vulnerability, threat, dan risk. Kita udah visit tiga model keamanan dan ISO/IEC 19249. Kita udah bahas prinsip keamanan beda-beda kaya defence in depth, trust but verify, dan zero trust.

Terakhir, Model Tanggung Jawab Bersama (Shared Responsibility Model) juga penting buat disebutin, apalagi dengan makin ngandelin layanan cloud. Macem-macem aspek dibutuhin buat mastiin keamanan yang bener. Ini termasuk hardware, infrastruktur jaringan, sistem operasi, aplikasi, dll. Tapi, pelanggan yang pake layanan cloud punya level akses beda-beda tergantung layanan cloud yang mereka pake. Contohnya, user Infrastructure as a Service (IaaS) punya kontrol penuh (dan tanggung jawab) atas sistem operasi.

Sebaliknya, user Software as a Service (SaaS) ga punya akses langsung ke sistem operasi dasarnya. Makanya, dapetin keamanan di lingkungan cloud butuh penyedia layanan cloud dan user buat ngelakuin bagian mereka masing-masing. Model Tanggung Jawab Bersama itu framework keamanan cloud buat mastiin tiap pihak tau tanggung jawabnya.