Program Studi Bisnis Digital • FEB

Teknologi Web & Mobile

Pertemuan 12 — Keamanan Web dan Mobile

Mengenali ancaman siber, memahami mekanisme pertahanan, dan mengambil keputusan bisnis yang tepat soal keamanan produk digital — tanpa perlu jadi programmer.

RPS MINGGU 13 • 2×50 MENIT

Selamat datang di pertemuan ke-12, dan selamat karena Anda sudah melewati UTS serta membahas API dan integrasi sistem minggu lalu. Hari ini kita bicara soal keamanan web dan mobile — topik yang sering dianggap "urusan tim IT" padahal sebenarnya keputusan bisnis strategis. Bayangkan Anda kelak jadi product manager di sebuah startup e-commerce atau fintech: kalau aplikasi Anda bocor data 91 juta pelanggan seperti kasus Tokopedia tahun 2020, itu bukan cuma masalah teknis, tapi masalah kepercayaan pelanggan, denda regulator, dan bisa mematikan bisnis dalam semalam. Karena itu, hari ini kita tidak akan menulis satu baris kode pun — kita akan belajar berpikir seperti pengambil keputusan yang paham risiko, bukan seperti programmer yang menambal bug. Siapkan diri Anda, karena di akhir kelas Anda harus bisa menghitung sendiri berapa kerugian bisnis akibat serangan siber.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu mengenali risiko keamanan web/mobile dan menilai kelayakan mekanisme pertahanannya dari perspektif pengambil keputusan bisnis. Secara rinci:

CAPAIAN 1

ANCAMAN

Mengidentifikasi jenis ancaman umum terhadap sistem web dan aplikasi mobile beserta dampak bisnisnya.

CAPAIAN 2

PERTAHANAN

Menjelaskan cara kerja enkripsi, autentikasi berlapis, dan kepatuhan regulasi (UU PDP) secara konseptual.

CAPAIAN 3

RISIKO

Menghitung estimasi kerugian finansial akibat insiden keamanan dan menyusun skor prioritas mitigasi.

CAPAIAN 4

KEPUTUSAN

Menimbang trade-off keamanan versus kenyamanan pengguna (UX) dalam keputusan produk digital.

Empat capaian ini menuntun kita sepanjang dua jam ke depan. Pertama, Anda perlu bisa membedakan jenis-jenis ancaman siber yang mengintai web dan mobile — bukan untuk jadi ahli teknis, tapi supaya Anda tahu apa yang harus ditanyakan ke tim developer Anda nanti. Kedua, kita akan memahami cara kerja pertahanan seperti enkripsi dan autentikasi secara konsep, cukup untuk bisa mengevaluasi apakah vendor teknologi Anda sudah menerapkan standar minimum. Ketiga, ini bagian favorit saya: Anda akan belajar menghitung sendiri berapa rupiah kerugian bisnis akibat sebuah insiden keamanan, karena angka selalu lebih meyakinkan direksi daripada rasa takut abstrak. Keempat, kita tutup dengan kemampuan menimbang trade-off — karena keamanan yang berlebihan bisa membuat pengguna kabur, sementara keamanan yang kurang bisa membuat bisnis Anda tutup.

Rp 91 Juta Akun, Satu Malam

Mei 2020: forum peretas internasional mengklaim menjual data ~91 juta akun pengguna Tokopedia — nama, email, nomor telepon, dan kata sandi terenkripsi. Tokopedia mengonfirmasi adanya insiden peretasan.

DAMPAK REPUTASI

KEPERCAYAAN

Pengguna ragu bertransaksi; kompetitor (Shopee, Bukalapak) langsung memanfaatkan momentum.

DAMPAK REGULASI

SANKSI

Kementerian Kominfo (kini Komdigi) memanggil manajemen; era sebelum UU PDP 2022 belum ada denda administratif eksplisit.

DAMPAK OPERASIONAL

RESET

Seluruh pengguna dipaksa reset kata sandi; tim keamanan bekerja nonstop berhari-hari.

Kasus ini bukan yang terakhir — BPJS Kesehatan (2021, ~279 juta data diduga bocor) dan berbagai startup lain mengalami insiden serupa. Keamanan digital adalah risiko bisnis nyata, bukan sekadar isu teknis.

Mari mulai dengan kasus yang mungkin pernah Anda dengar sendiri. Pada Mei 2020, dunia maya dihebohkan klaim bahwa sekitar 91 juta akun pengguna Tokopedia dijual di forum peretas internasional, lengkap dengan nama, email, dan nomor telepon. Tokopedia sendiri mengonfirmasi terjadinya insiden ini. Bayangkan Anda adalah bagian dari tim manajemen saat itu — dalam semalam, kepercayaan yang dibangun bertahun-tahun bisa runtuh, kompetitor seperti Shopee langsung memanfaatkan momentum untuk menarik pengguna, dan tim IT harus bekerja nonstop memaksa reset password puluhan juta akun. Ini bukan kasus tunggal; BPJS Kesehatan juga pernah mengalami dugaan kebocoran data serupa pada 2021. Poin saya sederhana: keamanan digital bukan urusan "nanti saja diurus tim IT" — ini adalah risiko bisnis yang bisa menentukan hidup matinya perusahaan Anda.

Bagian 1 dari 3

Lanskap Ancaman Siber

Sebelum bicara solusi, kita harus mengenali musuh: apa saja jenis ancaman yang menyerang aplikasi web dan mobile, dan mengapa masing-masing berbahaya bagi bisnis.

Tiga Pilar Keamanan Informasi (CIA Triad)

Setiap keputusan keamanan — teknis maupun bisnis — pada akhirnya menjaga tiga hal ini. CIA di sini bukan singkatan lembaga intelijen, melainkan kerangka klasik ilmu keamanan informasi.

CONFIDENTIALITY

KERAHASIAAN

Data hanya bisa diakses pihak yang berwenang. Contoh: nomor kartu kredit pelanggan Tokopedia tidak boleh terlihat oleh sembarang karyawan.

INTEGRITY

INTEGRITAS

Data tidak boleh diubah tanpa izin. Contoh: saldo rekening di aplikasi mobile banking harus akurat, tidak bisa dimanipulasi peretas.

AVAILABILITY

KETERSEDIAAN

Sistem harus bisa diakses saat dibutuhkan. Contoh: situs e-commerce tidak boleh down saat flash sale 12.12.

Hampir semua ancaman yang akan kita bahas menyerang salah satu — atau ketiga — pilar ini. Jadikan kerangka CIA sebagai "peta" Anda sepanjang kuliah hari ini.

Kerangka yang paling sering dipakai profesional keamanan informasi disebut CIA Triad — bukan mengacu ke badan intelijen Amerika, melainkan tiga kata: confidentiality, integrity, dan availability. Confidentiality atau kerahasiaan berarti data hanya boleh diakses oleh yang berhak, misalnya nomor kartu kredit pelanggan Anda di Tokopedia tidak boleh terlihat sembarangan oleh karyawan gudang. Integrity atau integritas berarti data tidak boleh diubah tanpa izin — bayangkan kalau saldo rekening BCA mobile Anda bisa dimanipulasi orang lain, itu bencana. Availability atau ketersediaan berarti sistem harus tetap bisa diakses saat dibutuhkan, seperti situs e-commerce yang tidak boleh down saat flash sale 12.12 karena itu berarti kehilangan penjualan langsung. Setiap kali kita membahas ancaman atau solusi keamanan setelah ini, coba kaitkan kembali ke tiga pilar ini — itu akan membantu Anda berpikir terstruktur seperti profesional keamanan.

Coba Sendiri: Klasifikasikan Ancaman ke Pilar CIA

Pilih sebuah skenario ancaman, lalu amati pilar mana — kerahasiaan, integritas, atau ketersediaan — yang paling terdampak.

Ancaman Umum: Manusia dan Mesin

Ancaman siber datang dari dua sisi: rekayasa sosial (menipu manusia) dan perangkat lunak jahat (menyerang sistem). Berikut empat yang paling sering menyerang bisnis digital Indonesia.

PHISHING

PENIPUAN

Email/pesan palsu menyamar sebagai bank atau marketplace (mis. "BCA" palsu) untuk mencuri kata sandi atau kode OTP.

MALWARE

PERUSAK

Malicious software — perangkat lunak jahat yang menyusup lewat lampiran email, aplikasi bajakan, atau tautan mencurigakan.

RANSOMWARE

PEMERAS

Mengunci/mengenkripsi data perusahaan, lalu meminta tebusan agar data dikembalikan.

DDOS

BANJIR

Distributed Denial of Service — membanjiri server dengan lalu lintas palsu hingga situs tidak bisa diakses pengguna sah.

Ancaman siber pada dasarnya menyerang dari dua arah: sisi manusia dan sisi mesin. Phishing menyerang sisi manusia — Anda mungkin pernah menerima SMS mengaku dari bank meminta klik tautan untuk "verifikasi rekening", padahal itu jebakan mencuri password atau kode OTP, singkatan dari one-time password, kode sekali pakai untuk verifikasi transaksi. Malware adalah istilah umum untuk perangkat lunak jahat yang menyusup lewat aplikasi bajakan atau lampiran email mencurigakan. Ransomware lebih spesifik dan menakutkan bagi bisnis: perangkat lunak ini mengunci seluruh data perusahaan Anda, lalu peretas meminta tebusan — banyak rumah sakit dan perusahaan di dunia pernah lumpuh karenanya. Terakhir, DDoS adalah serangan yang membanjiri server dengan trafik palsu dalam jumlah masif, sehingga pengguna asli tidak bisa mengakses situs Anda — ingat pilar availability yang baru kita bahas, ini serangan langsung ke pilar itu.

Ancaman Khas Aplikasi Web

Situs web punya celah spesifik karena menerima input dari pengguna (formulir login, kolom pencarian, kolom komentar). Dua yang paling klasik:

SQL INJECTION

Peretas menyisipkan perintah database ke kolom formulir (mis. kolom login) untuk "menipu" sistem agar membocorkan atau menghapus data — tanpa perlu tahu kata sandi asli.

Analogi: menulis "kalimat sakti" di kolom nama supaya pintu gudang data terbuka sendiri.

XSS (CROSS-SITE SCRIPTING)

Peretas menyisipkan skrip berbahaya di kolom yang tampil ke pengguna lain (mis. kolom ulasan produk), lalu skrip itu berjalan otomatis saat dibuka pengunjung lain.

Analogi: menaruh jebakan di ulasan produk yang otomatis "meledak" saat dibaca pembeli lain.

Anda tidak perlu bisa menulis kodenya — cukup paham bahwa setiap kolom isian pengguna adalah pintu masuk potensial, sehingga tim developer wajib memvalidasi setiap input.

Sekarang kita masuk ke ancaman yang lebih spesifik untuk aplikasi web. Web itu unik karena selalu menerima masukan dari pengguna — kolom login, kolom pencarian, kolom ulasan produk — dan di situlah celahnya. SQL injection adalah serangan klasik di mana peretas menuliskan perintah basis data yang disamarkan sebagai teks biasa di kolom formulir, misalnya kolom username saat login, sehingga sistem "tertipu" dan membocorkan seluruh isi database tanpa peretas perlu tahu password sungguhan. XSS atau cross-site scripting berbeda: peretas menaruh skrip jahat di tempat yang akan dibaca pengguna lain, seperti kolom ulasan produk di Tokopedia, sehingga saat pembeli lain membuka halaman itu, skrip berjalan otomatis di perangkat mereka. Sebagai calon manajer produk, Anda tidak perlu bisa menulis kode untuk mengeksploitasi atau menambal ini — yang penting Anda paham bahwa setiap kolom isian adalah potensi pintu masuk, sehingga saat briefing ke tim developer, Anda tahu untuk menanyakan "apakah semua input sudah divalidasi?"

Ancaman Khas Aplikasi Mobile

Aplikasi mobile menyimpan data langsung di perangkat pengguna dan meminta banyak izin akses (permission) — dua sumber risiko yang tidak dimiliki web murni.

PERMISSION ABUSE

IZIN BERLEBIH

Aplikasi senter minta akses kontak & lokasi — data itu bisa dijual atau disalahgunakan tanpa sepengetahuan pengguna.

INSECURE STORAGE

PENYIMPANAN LEMAH

Kata sandi/token disimpan polos (tidak terenkripsi) di memori HP — mudah dibaca jika perangkat dicuri atau di-root.

FAKE APP

APLIKASI PALSU

Tiruan aplikasi resmi (mis. "m-banking palsu") diunggah di luar Play Store/App Store resmi untuk mencuri kredensial.

Pelajaran bisnis: setiap izin (permission) yang diminta aplikasi Anda harus punya alasan jelas — semakin sedikit izin diminta, semakin rendah risiko sekaligus semakin tinggi kepercayaan pengguna saat instalasi.

Aplikasi mobile punya karakter risiko yang berbeda dari web biasa. Pertama, permission abuse: pernahkah Anda curiga kenapa aplikasi senter meminta akses ke kontak dan lokasi Anda? Itu contoh permintaan izin berlebihan yang tidak sesuai fungsi aplikasi, dan data itu bisa dijual ke pihak ketiga tanpa Anda sadari. Kedua, insecure storage atau penyimpanan tidak aman: banyak aplikasi menyimpan kata sandi atau token login dalam bentuk polos di memori HP, sehingga kalau ponsel dicuri atau di-root — istilah untuk membuka akses penuh ke sistem Android — data itu mudah dibaca. Ketiga, fake app atau aplikasi palsu: banyak korban tertipu mengunduh "aplikasi BRI mobile" atau "aplikasi BCA" palsu dari luar Play Store resmi, yang sebenarnya dirancang mencuri kredensial perbankan mereka. Sebagai pengambil keputusan produk, pelajaran pentingnya adalah: setiap izin yang diminta aplikasi Anda harus punya alasan bisnis yang jelas ke pengguna, karena itu langsung memengaruhi kepercayaan mereka untuk menginstal aplikasi Anda.

Hitung dari Nol: Biaya Kerugian Akibat Downtime

Kasus: toko online UMKM naik kelas beromzet rata-rata Rp 24.000.000/hari (buka 24 jam). Serangan DDoS membuat situsnya down selama 6 jam. Berapa estimasi kerugiannya?

SIMULASI KERUGIAN DOWNTIME

Langkah	Perhitungan	Nilai
Identifikasi	Omzet harian = Rp 24.000.000; downtime = 6 jam dari 24 jam	—
Omzet per jam	24.000.000 ÷ 24	Rp 1.000.000/jam
Kerugian penjualan langsung	1.000.000 × 6	Rp 6.000.000
+ Biaya pemulihan (~25% dari kerugian langsung)	6.000.000 × 25%	Rp 1.500.000

TOTAL KERUGIAN ESTIMASI

Rp 7.500.000

6.000.000 + 1.500.000 — belum termasuk kerugian reputasi jangka panjang

Sekarang saatnya kita berhitung, karena angka selalu lebih persuasif daripada rasa takut abstrak. Bayangkan sebuah toko online UMKM naik kelas dengan omzet rata-rata 24 juta rupiah per hari, buka nonstop 24 jam. Serangan DDoS membuat situsnya tidak bisa diakses selama 6 jam. Langkah pertama, kita identifikasi data yang kita punya: omzet harian dan durasi downtime. Langkah kedua, kita hitung omzet per jam dengan membagi 24 juta dengan 24 jam, hasilnya 1 juta rupiah per jam. Langkah ketiga, kita kalikan dengan 6 jam downtime, ketemu kerugian penjualan langsung 6 juta rupiah. Langkah keempat, kita tambahkan estimasi biaya pemulihan — lembur tim IT, komunikasi krisis ke pelanggan — yang kita asumsikan sekitar 25 persen dari kerugian langsung, yaitu 1,5 juta rupiah. Totalnya, kerugian estimasi mencapai 7,5 juta rupiah untuk downtime 6 jam saja — dan ini belum menghitung pelanggan yang kabur ke kompetitor secara permanen. Inilah kenapa keamanan bukan biaya, melainkan investasi mitigasi risiko.

Coba Sendiri: Hitung Kerugian Downtime Bisnis Anda

Ubah omzet harian dan lama downtime, lalu amati bagaimana estimasi kerugian total berubah, termasuk biaya pemulihan.

Bagian 2 dari 3

Mekanisme Pertahanan

Setelah mengenal ancaman, kita bahas alat pertahanan utama yang wajib Anda pahami sebagai pengambil keputusan produk: enkripsi, autentikasi berlapis, dan kepatuhan regulasi.

Enkripsi, HTTPS, dan Gembok di Alamat Situs

Enkripsi mengubah data menjadi kode acak yang hanya bisa dibaca dengan "kunci" yang benar. Ini fondasi keamanan komunikasi web dan mobile.

IN TRANSIT

HTTPS / TLS

Mengenkripsi data selama perjalanan antara HP/laptop Anda dan server (mis. saat mengetik password login). Ditandai ikon gembok di address bar browser.

AT REST

ENKRIPSI DATABASE

Mengenkripsi data saat tersimpan di server, sehingga meski database dicuri, isinya tetap berupa kode acak yang tak terbaca.

Data Asli → [Kunci Enkripsi] → Kode Acak → [Kunci Dekripsi] → Data Asli

Cek sederhana: sebelum mengetik data sensitif di sebuah situs, lihat apakah alamatnya diawali https:// (bukan http:// tanpa "s") — "s" berarti secure, komunikasi Anda terenkripsi.

Enkripsi adalah konsep paling mendasar dalam keamanan digital: mengubah data menjadi kode acak yang hanya bisa dibuka kembali dengan kunci yang tepat, mirip seperti mengunci dokumen dalam brankas yang hanya bisa dibuka dengan kombinasi tertentu. Ada dua konteks penting yang harus Anda bedakan. Pertama, enkripsi "in transit", yaitu saat data sedang bepergian dari HP Anda ke server — ini yang dilakukan HTTPS, singkatan dari HyperText Transfer Protocol Secure, ditandai dengan ikon gembok kecil di address bar browser Anda. Kedua, enkripsi "at rest", yaitu saat data sudah tersimpan di server perusahaan — ini penting karena kalau database dicuri seperti kasus Tokopedia tadi, data yang terenkripsi at rest tetap tidak bisa langsung dibaca peretas. Kebiasaan sederhana yang bisa Anda ajarkan ke tim atau bahkan keluarga Anda: sebelum mengetik nomor kartu kredit atau password di sebuah situs, selalu cek apakah alamatnya diawali https, bukan http tanpa huruf s.

Coba Sendiri: Bandingkan Waktu Bobol Enkripsi

Ubah panjang kunci enkripsi, lalu amati bagaimana waktu bobol berbeda drastis antara komputer klasik dan komputer kuantum.

Autentikasi: Memastikan "Anda Benar-Benar Anda"

Password saja mudah dicuri lewat phishing. Solusinya: autentikasi berlapis — menggabungkan beberapa "bukti identitas" sekaligus.

FAKTOR 1

SESUATU YANG DIKETAHUI

Password, PIN — hal yang hanya Anda tahu. Paling lemah karena bisa dicuri lewat phishing.

FAKTOR 2

SESUATU YANG DIMILIKI

Kode OTP di HP, aplikasi authenticator — hal yang hanya Anda punya secara fisik.

FAKTOR 3

SESUATU YANG MELEKAT

Sidik jari, wajah (biometrik) — hal yang menyatu dengan diri Anda.

MFA/2FA (Multi/Two-Factor Authentication) = menggabungkan ≥2 faktor. Contoh: login m-banking BCA butuh password (faktor 1) + kode dari token/OTP (faktor 2) — meski password bocor, peretas masih terhalang faktor kedua.

Salah satu pertanyaan yang sering muncul: kalau password saya bocor lewat phishing seperti yang kita bahas tadi, apakah akun saya otomatis jebol? Jawabannya tidak, jika sistemnya menerapkan autentikasi berlapis. Ada tiga kategori faktor identitas: pertama, sesuatu yang Anda ketahui, seperti password atau PIN — ini paling lemah karena bisa dicuri. Kedua, sesuatu yang Anda miliki secara fisik, seperti kode OTP yang dikirim ke HP Anda atau aplikasi authenticator. Ketiga, sesuatu yang melekat pada diri Anda, seperti sidik jari atau pengenalan wajah, yang biasa disebut biometrik. MFA atau multi-factor authentication, sering disingkat 2FA untuk dua faktor, berarti sistem menggabungkan minimal dua dari tiga kategori ini. Contoh nyata: saat Anda login m-banking BCA, Anda butuh password sekaligus kode dari token fisik atau OTP di HP — jadi meski peretas berhasil mencuri password Anda lewat phishing, mereka masih terhalang oleh faktor kedua yang hanya Anda miliki secara fisik.

Coba Sendiri: Uji Kekuatan Password Anda

Ubah panjang dan variasi karakter password, lalu amati bagaimana entropi dan estimasi waktu bobolnya berubah.

Kewajiban Hukum: UU Pelindungan Data Pribadi

UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (PDP) mewajibkan setiap pengendali data (termasuk aplikasi Anda) menjaga keamanan data pribadi pengguna — bukan lagi pilihan, tapi kewajiban hukum.

KEWAJIBAN UTAMA

PERLINDUNGAN

Wajib menerapkan langkah teknis (mis. enkripsi) & organisasi untuk mencegah kebocoran; wajib lapor insiden ke otoritas & pemilik data maks. 3×24 jam.

SANKSI ADMINISTRATIF

~2% OMZET

Denda administratif dapat mencapai maksimal ~2% dari pendapatan tahunan, bervariasi menurut tingkat pelanggaran (Pasal 57 UU PDP).

Sektor keuangan punya lapisan tambahan: bank & fintech juga tunduk pada aturan OJK soal keamanan sistem informasi (mis. POJK Penyelenggaraan TI). Aplikasi Anda kelak mungkin diatur lebih dari satu regulator sekaligus.

Sekarang kita masuk ke sisi hukum, yang sering dilupakan mahasiswa bisnis padahal krusial. Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi, atau biasa disingkat UU PDP, mewajibkan setiap pihak yang mengelola data pengguna — istilahnya "pengendali data" — untuk aktif melindungi data itu, bukan sekadar reaktif setelah bocor. Salah satu kewajiban konkretnya adalah melaporkan insiden kebocoran data kepada otoritas dan pemilik data paling lambat dalam waktu 3 kali 24 jam sejak insiden diketahui. Kalau kewajiban ini dilanggar, sanksi administratifnya bisa mencapai sekitar 2 persen dari pendapatan tahunan perusahaan, bervariasi tergantung tingkat pelanggaran menurut Pasal 57 undang-undang tersebut — bayangkan kalau perusahaan Anda beromzet 100 miliar rupiah setahun, itu bisa berarti denda hingga 2 miliar rupiah. Untuk Anda yang tertarik bekerja di sektor fintech atau perbankan digital, ingat juga bahwa ada lapisan regulasi tambahan dari OJK soal keamanan sistem informasi, sehingga bisnis digital di sektor keuangan diawasi lebih dari satu regulator sekaligus.

Coba Sendiri: Estimasi Denda UU PDP Perusahaan Anda

Masukkan pendapatan tahunan dan tingkat pelanggaran, lalu amati berapa estimasi denda administratif menurut UU PDP.

Hitung dari Nol: Skor Prioritas Risiko

Kasus: tim keamanan aplikasi fintech P2P lending menilai risiko "kebocoran data pengguna karena API belum terenkripsi penuh". Formula standar: Skor Risiko = Probabilitas × Dampak (skala 1–5 masing-masing).

SIMULASI SKOR RISIKO

Langkah	Perhitungan	Nilai
Identifikasi	Probabilitas = 4/5 (banyak endpoint lama tanpa enkripsi); Dampak = 5/5 (data finansial + kena UU PDP)	—
Skor risiko	P × D = 4 × 5	20
Skor maksimum skala	5 × 5	25
Persentase risiko	20 ÷ 25 × 100%	80% — PRIORITAS TINGGI

KEPUTUSAN

MITIGASI SEGERA

Skor >15/25 (60%) → wajib ditangani sebelum fitur baru dirilis

Sekarang kita berlatih dengan alat kedua yang sangat dipakai tim keamanan profesional: matriks skor risiko. Bayangkan Anda tim keamanan di sebuah aplikasi fintech peer-to-peer lending, dan sedang menilai risiko "kebocoran data karena API belum terenkripsi penuh" — API sendiri singkatan dari Application Programming Interface, jembatan komunikasi antar sistem yang kita bahas minggu lalu. Langkah pertama, kita identifikasi dan beri skor probabilitas dan dampak pada skala 1 sampai 5. Kita nilai probabilitasnya 4 dari 5 karena banyak endpoint lama belum terenkripsi, dan dampaknya 5 dari 5 karena menyangkut data finansial sekaligus berisiko kena sanksi UU PDP yang baru kita bahas. Langkah kedua, kalikan probabilitas dengan dampak, hasilnya 20. Langkah ketiga, kita bandingkan dengan skor maksimum skala yaitu 25. Langkah keempat, kita ubah jadi persentase: 20 dibagi 25 dikali 100 persen sama dengan 80 persen — jauh di atas ambang batas 60 persen yang biasa dipakai sebagai pemicu tindakan segera. Kesimpulannya, risiko ini masuk kategori prioritas tinggi dan wajib dimitigasi sebelum fitur baru dirilis ke publik.

Coba Sendiri: Petakan Risiko di Matriks 5x5

Ubah skor probabilitas dan dampak suatu risiko, lalu amati posisinya di matriks heatmap dan apakah butuh mitigasi segera.

Bagian 3 dari 3

Studi Kasus & Keputusan Bisnis

Kita tutup kuliah dengan menerapkan semua konsep tadi ke studi kasus nyata, lalu belajar menimbang trade-off keamanan versus kenyamanan pengguna dalam keputusan produk.

Walkthrough: Membedah Kasus Tokopedia 2020

Mari terapkan kerangka CIA dan konsep hari ini untuk membedah kasus di slide pembuka, langkah demi langkah, seperti yang dilakukan tim investigasi keamanan sungguhan.

LANGKAH 1–2: DETEKSI & DAMPAK

Deteksi: data dijual di forum peretas → pilar confidentiality (kerahasiaan) dilanggar.
Dampak langsung: ~91 juta akun terpapar (nama, email, telepon, password terenkripsi).

LANGKAH 3–4: RESPONS & PENCEGAHAN

Respons: paksa reset password massal + investigasi + notifikasi ke pengguna & regulator.
Pencegahan ke depan: audit keamanan berkala, enkripsi at rest lebih kuat, MFA wajib untuk akun admin internal.

Password yang bocor dilaporkan terenkripsi (hashed) — inilah kenapa slide 11 tadi soal enkripsi at rest bukan sekadar teori: itu lapisan yang membatasi kerusakan meski database dicuri.

Sekarang mari kita bedah kembali kasus Tokopedia yang kita buka di awal kelas, tapi kali ini dengan kerangka yang sudah Anda kuasai. Langkah satu, deteksi: insiden ini melanggar pilar confidentiality karena data yang seharusnya rahasia justru dijual bebas di forum peretas. Langkah dua, kita lihat dampaknya: sekitar 91 juta akun terpapar, meski untungnya passwordnya dilaporkan dalam bentuk terenkripsi atau ter-hash, bukan teks polos. Langkah tiga, respons: Tokopedia memaksa reset password massal, melakukan investigasi internal, dan memberi notifikasi ke pengguna. Langkah empat, pencegahan ke depan: audit keamanan berkala, penguatan enkripsi data saat tersimpan, dan penerapan autentikasi berlapis khususnya untuk akun-akun admin internal yang punya akses luas ke database. Perhatikan bagaimana fakta bahwa password disimpan terenkripsi benar-benar menyelamatkan situasi — ini bukti nyata kenapa investasi enkripsi at rest yang kita bahas tadi bukan sekadar materi teori, tapi benteng terakhir saat pertahanan lain jebol.

Dilema Produk: Keamanan vs. Kenyamanan Pengguna

Keamanan maksimal sering membuat pengalaman pengguna (UX — user experience) memburuk. Sebagai pengambil keputusan produk, Anda harus menimbang trade-off ini secara sadar.

TERLALU KETAT

PENGGUNA KABUR

Login butuh 5 langkah verifikasi → pengguna frustrasi, tingkat abandonment (batal transaksi) naik, kompetitor lebih "mudah" menang pasar.

TERLALU LONGGAR

DATA BOCOR

Praktik terbaik: keamanan berlapis adaptif — MFA wajib hanya untuk transaksi berisiko tinggi (transfer besar, ganti nomor HP), sementara aktivitas ringan (lihat saldo) cukup satu faktor. GoTo & bank digital banyak menerapkan pola ini.

Ini adalah dilema yang akan terus Anda hadapi sepanjang karier di produk digital. Di satu sisi, kalau keamanan terlalu ketat — misalnya login butuh lima langkah verifikasi — pengguna akan frustrasi dan meninggalkan aplikasi Anda di tengah jalan, istilahnya abandonment, lalu berpindah ke kompetitor yang terasa lebih mudah dipakai. Di sisi lain, kalau keamanan terlalu longgar, misalnya cukup password lemah tanpa verifikasi tambahan, risiko peretasan melonjak dan Anda bisa terkena sanksi UU PDP yang sudah kita bahas. Solusi yang banyak dipakai perusahaan digital matang, termasuk bank digital dan GoTo, adalah keamanan berlapis adaptif: verifikasi ketat seperti MFA hanya diwajibkan untuk aksi berisiko tinggi, misalnya transfer dana besar atau mengganti nomor HP terdaftar, sementara aktivitas ringan seperti sekadar melihat saldo cukup satu faktor autentikasi saja. Sebagai calon manajer produk, kemampuan menimbang trade-off semacam ini — bukan memilih ekstrem satu sisi — adalah yang membedakan keputusan matang dari keputusan gegabah.

Checklist Keamanan Minimum untuk Startup/UMKM Digital

Anda belum tentu jadi developer, tapi sebagai pengambil keputusan produk, gunakan daftar ini untuk menanyakan kesiapan tim teknis Anda.

Area	Pertanyaan Wajib Ditanyakan	Status Ideal
Komunikasi data	Apakah seluruh situs/aplikasi sudah pakai HTTPS?	Wajib, tanpa kecuali
Login	Apakah tersedia MFA/2FA, minimal untuk akun admin?	Wajib untuk admin & transaksi besar
Penyimpanan data	Apakah password disimpan ter-hash/terenkripsi, bukan teks polos?	Wajib mutlak
Kepatuhan	Apakah ada kebijakan privasi & prosedur lapor insiden sesuai UU PDP?	Wajib sebelum launch
Izin aplikasi	Apakah setiap permission yang diminta punya alasan fungsional jelas?	Minimal perlu (least privilege)

Slide ini saya rancang sebagai alat praktis yang bisa langsung Anda pakai kelak — cetak atau simpan sebagai catatan. Anda tidak perlu bisa mengimplementasikan sendiri kelima area ini, tapi Anda wajib tahu untuk menanyakannya ke tim teknis atau vendor yang Anda ajak kerja sama. Pertama, pastikan seluruh komunikasi data memakai HTTPS tanpa kecuali. Kedua, pastikan ada MFA minimal untuk akun admin dan transaksi bernilai besar. Ketiga, dan ini yang paling krusial, pastikan password pengguna disimpan dalam bentuk ter-hash atau terenkripsi, bukan teks polos — inilah yang menyelamatkan Tokopedia dari kerusakan lebih parah. Keempat, pastikan ada kebijakan privasi tertulis dan prosedur pelaporan insiden sesuai UU PDP sebelum aplikasi Anda diluncurkan ke publik. Kelima, terapkan prinsip least privilege atau hak akses minimal — setiap izin yang diminta aplikasi harus punya alasan fungsional yang jelas ke pengguna. Kalau kelak Anda jadi product manager atau pendiri startup, checklist lima baris ini bisa menyelamatkan bisnis Anda dari skandal seperti yang kita bahas hari ini.

Latihan Diskusi Kelompok (15 Menit)

Bentuk kelompok 3–4 orang. Kasus: Anda adalah tim produk sebuah startup marketplace UMKM baru yang akan launch bulan depan.

TUGAS 1 — SKOR RISIKO

Pilih satu skenario ancaman (phishing ke penjual, API belum terenkripsi, atau fake app). Beri skor Probabilitas × Dampak (skala 1–5), lalu tentukan apakah masuk kategori prioritas tinggi (>60% dari skor maksimum).

TUGAS 2 — TRADE-OFF

Rancang satu kebijakan keamanan berlapis adaptif untuk aplikasi Anda: kapan MFA wajib, kapan cukup satu faktor? Justifikasi dengan pertimbangan bisnis, bukan hanya teknis.

Setiap kelompok presentasi ringkas (~2 menit) di akhir sesi diskusi. Siapkan angka konkret, bukan jawaban abstrak.

Sekarang giliran Anda mempraktikkan langsung apa yang sudah kita pelajari. Silakan berkelompok 3 sampai 4 orang, dan bayangkan Anda adalah tim produk di sebuah startup marketplace UMKM yang akan meluncur bulan depan — skenario yang sangat mungkin Anda hadapi sungguhan setelah lulus. Tugas pertama, pilih satu skenario ancaman yang relevan, beri skor probabilitas dan dampak seperti latihan kita tadi, lalu tentukan prioritasnya menggunakan ambang batas 60 persen dari skor maksimum. Tugas kedua, rancang kebijakan keamanan berlapis adaptif — kapan MFA wajib diterapkan dan kapan cukup satu faktor — dan yang terpenting, justifikasi keputusan Anda dengan alasan bisnis, bukan sekadar alasan teknis "karena lebih aman". Saya beri waktu 15 menit, dan setiap kelompok akan presentasi sangat singkat di akhir sesi. Slide ini sengaja tidak beranimasi bertahap supaya Anda bisa membaca seluruh instruksi sekaligus sebelum mulai berdiskusi.

Rangkuman & Persiapan Minggu Depan

CHEAT SHEET HARI INI

CIA Triad: Confidentiality, Integrity, Availability.
Ancaman: phishing, malware, ransomware, DDoS, SQL injection/XSS (web), permission abuse/fake app (mobile).
Pertahanan: HTTPS/enkripsi, MFA/2FA, kepatuhan UU PDP.
Alat keputusan: biaya downtime, Skor Risiko = P × D.

TUGAS & MINGGU DEPAN

P13

Baca hasil diskusi kelompok Anda → kumpulkan skor risiko & kebijakan MFA (format bebas, 1 halaman). Pertemuan 13: Prototipe Interaktif & Uji Usabilitas — bawa laptop.

Sebelum kita tutup, mari rangkum apa yang sudah Anda kuasai hari ini. Anda sekarang paham kerangka CIA Triad sebagai peta dasar keamanan informasi, mengenali berbagai jenis ancaman baik yang menyasar manusia lewat phishing maupun yang menyasar sistem lewat malware, ransomware, DDoS, serta ancaman khas web seperti SQL injection dan XSS dan ancaman khas mobile seperti permission abuse dan fake app. Anda juga sudah paham mekanisme pertahanan utama: enkripsi lewat HTTPS, autentikasi berlapis lewat MFA, dan kewajiban hukum lewat UU PDP. Yang paling penting, Anda sekarang punya dua alat kuantitatif nyata: menghitung kerugian biaya downtime dan menghitung skor prioritas risiko — dua hal yang akan membuat Anda kredibel di depan direksi kelak. Untuk tugas, kumpulkan hasil diskusi kelompok Anda dalam satu halaman ringkas. Minggu depan di pertemuan 13, kita masuk ke prototipe interaktif dan uji usabilitas, jadi jangan lupa bawa laptop karena kita akan langsung praktik menggunakan alat prototyping. Sampai jumpa minggu depan, dan tetap waspada di dunia digital!