Pertanyaan:

Keamanan Data Publik di Era Blockchain dan AI Generatif

Pemerintah Indonesia meluncurkan sistem bernama CivChain, yaitu platform digital untuk menyimpan dokumen publik seperti akta kelahiran, ijazah, izin usaha, dan sertifikat tanah. Semua data tersebut disimpan di blockchain publik, agar tidak bisa dipalsukan dan dapat diverifikasi siapa pun.

Untuk membantu petugas, pemerintah bekerja sama dengan startup VeriAI, yang menggunakan AI Generatif (GenAI) untuk membuat ringkasan otomatis isi dokumen, menerjemahkan data, dan memberikan saran kepada operator agar lebih cepat memproses dokumen.

Beberapa waktu kemudian muncul beberapa masalah:

Data transaksi di blockchain ternyata bisa digunakan untuk menebak identitas warga, karena ada pola waktu, nama validator, dan jenis dokumen.
Beberapa keluaran dari GenAI menampilkan potongan kalimat dari dokumen pribadi, sehingga muncul risiko kebocoran informasi.
Website CivChain juga sempat diserang peretas melalui injeksi API dan DDoS attack yang membuat sistem lumpuh selama beberapa jam.

Tugas

1. Analisis Logika (25%)

Jelaskan dengan bahasa kamu sendiri mengapa kombinasi blockchain publik, GenAI, dan portal pemerintah dapat menimbulkan risiko baru terhadap privasi dan keamanan data warga. Gunakan logika dan contoh yang kamu buat sendiri, bukan teori hafalan.
Contoh arah jawaban: bagaimana pola transaksi atau ringkasan AI dapat secara tidak sengaja mengungkap identitas seseorang.

2. Dua Skenario (20%)

Buat dua cerita singkat:

A: Situasi di mana hashing lebih tepat digunakan daripada enkripsi, dan jelaskan alasannya.
B: Situasi di mana enkripsi lebih aman dan hashing tidak cukup, sertakan juga alasan teknisnya.

Gunakan contoh buatan sendiri yang masih berkaitan dengan konteks blockchain, website, atau sistem AI.

3. Contoh Data Buatan (15%)

Tulis tiga sampai lima baris data contoh fiktif untuk menunjukkan bagaimana penyerang dapat menebak identitas seseorang.
Gunakan format sederhana seperti contoh berikut (boleh disesuaikan):

TxID001 – waktu: 2025-10-12 09:30 – dokumen: izin usaha – validator: Dinas A – ringkasan AI: “Pemilik baru: Rina”

TxID002 – waktu: 2025-10-12 09:32 – dokumen: akta kelahiran – validator: Disdukcapil B – ringkasan AI: “Anak dari pegawai BUMN”

Setelah itu, jelaskan dengan dua sampai tiga kalimat bagaimana penyerang dapat menebak siapa orang yang dimaksud.

4. Serangan ke Website Pemerintah (20%)

Pilih satu jenis serangan yang mungkin terjadi, seperti DDoS, SQL Injection, atau penyalahgunaan AI untuk social engineering.
Jelaskan secara berurutan:

Bagaimana serangan bisa terjadi
Tujuan penyerang
Dampak yang ditimbulkan
Cara pencegahannya (minimal dua langkah teknis dan dua langkah kebijakan atau prosedur kerja)

Gunakan gaya penjelasan seperti sedang menjelaskan kepada tim keamanan kampus.

5. Strategi Pertahanan (10%)

Tuliskan satu paragraf strategi keamanan yang mencakup lima hal berikut: salt/pepper, pseudonymization, pembatasan akses internal, audit dan logging, serta data minimization.
Tulis seolah kamu adalah penanggung jawab keamanan di sistem pemerintahan, dan jelaskan dengan bahasa yang sederhana tetapi menunjukkan pemahaman teknis.

6. Refleksi Etika dan Dampak Sosial (10%)

Tuliskan pendapat pribadi kamu tentang mengapa kebocoran data publik dari sistem seperti ini bisa lebih berbahaya daripada kebocoran password biasa.
Bahas dari sisi:

Dampak terhadap reputasi seseorang
Kepercayaan masyarakat terhadap pemerintah
Tanggung jawab etis lembaga pengelola data

Gunakan gaya opini pribadi, bukan teori.

Ketentuan Pengumpulan

Jawaban ditulis dalam bentuk Cermi (Cerita Mini) di situs: https://bisnisdigital.raharja.ac.id
Setelah dipublikasikan, buat shortlink menggunakan https://bysl.pw dan cantumkan pada bagian akhir jawaban.
Semua contoh dan penjelasan harus buatan sendiri, bukan hasil salinan dari internet atau AI lain.
Waktu pengerjaan maksimal tiga jam

Status: 100% telah mengerjakan

Keterangan: sudah mengerjakan tugas ini dengan baik dan benar

Bukti:

Kombinasi blockchain publik, GenAI, dan portal pemerintah bisa menimbulkan risiko privasi baru karena sifat ketiganya saling memperkuat keterbukaan data.
- Blockchain publik bersifat transparan dan permanen, sehingga pola transaksi atau waktu pencatatan bisa menyingkap identitas warga meski datanya disamarkan.
- GenAI mampu menganalisis dan menyimpulkan pola dari data tersebut, sehingga tanpa sengaja dapat “menebak” siapa orang di balik data anonim.
- Portal pemerintah memberi legitimasi pada data itu, membuat kebocoran terasa lebih serius dan sulit ditarik kembali.
Contoh: AI yang merangkum data bantuan sosial bisa menulis “perempuan 32 tahun di RW 3 menerima bantuan terbanyak,” padahal dari konteks lokal semua orang tahu siapa orang itu.
A. Hashing lebih tepat daripada enkripsi

Cerita:
Sebuah portal login pemerintah menggunakan sistem AI untuk memverifikasi pengguna sebelum mereka mengakses data kependudukan. Saat warga membuat akun, sistem hanya perlu mengecek kecocokan kata sandi, bukan membaca isinya.

Karena itu, kata sandi disimpan dalam bentuk hash (misalnya SHA-256). Ketika pengguna login, sistem meng-hash input-nya dan membandingkannya dengan hash yang tersimpan.

Alasan:
Hashing lebih tepat karena:
- Tidak perlu membalikkan data ke bentuk aslinya (kata sandi tidak pernah “dibuka”).
- Lebih aman jika database bocor, karena hash sulit dibalik.
- Enkripsi tidak diperlukan karena tujuannya hanya verifikasi, bukan pemulihan data.
B. Enkripsi lebih aman daripada hashing

Cerita:
Dalam proyek blockchain AI untuk kesehatan, setiap rumah sakit mengirimkan data pasien (hasil lab, riwayat pengobatan) ke node blockchain pribadi. Data ini harus bisa dibaca kembali oleh dokter yang berwenang.

Maka, data dienkripsi dengan kunci publik dokter, dan dokter membuka (dekripsi) dengan kunci pribadinya saat diperlukan.
Berikut 4 baris data fiktif dan singkat, lalu penjelasan bagaimana penyerang bisa menebak identitas:

TxA001 – waktu: 2025-10-12 09:30 – dokumen: izin usaha – validator: Kecamatan C – ringkasan AI: “Pemilik: ibu rumah tangga usia 38, usaha katering”
TxA002 – waktu: 2025-10-12 09:31 – dokumen: NPWP – validator: Kantor Pajak D – ringkasan AI: “Pemilik usaha katering, lokasi: RT 02/RW 05”
TxA003 – waktu: 2025-10-12 09:32 – dokumen: akta kelahiran – validator: Disdukcapil E – ringkasan AI: “Anak ke-2, lahir di Puskesmas F”
TxA004 – waktu: 2025-10-12 09:33 – dokumen: bantuan sosial – validator: Dinas Sosial G – ringkasan AI: “Penerima: keluarga penerima manfaat di RT 02/RW 05”

Penjelasan singkat: Penyerang dapat menggabungkan petunjuk (jenis usaha = katering, usia 38, dan alamat sempit RT 02/RW 05) dari beberapa ringkasan untuk memperkecil ruang pencarian hingga hanya tersisa satu atau dua orang di lingkungan tersebut. Setelah itu penyerang tinggal mencari daftar publik lokal (grup warga, daftar usaha, atau pengumuman RT) untuk mencocokkan dan menegaskan nama target — sehingga data yang awalnya tampak anonim menjadi teridentifikasi.
1) Bagaimana serangan bisa terjadi (gambaran berurutan, tingkat tinggi)
1. Aplikasi web menyediakan formulir atau endpoint (mis. login, pencarian, input data) yang menerima input dari pengguna.
2. Input pengguna tersebut dikirimkan ke lapisan aplikasi dan dipakai langsung untuk membentuk perintah database (query SQL) tanpa difilter atau tanpa memisahkan logika query dan data.
3. Penyerang memasukkan nilai yang mengubah struktur query (bukan hanya datanya), sehingga database mengeksekusi perintah yang tidak dimaksudkan pengembang — mis. mengembalikan data lain, memodifikasi, atau menghapus tabel.
4. Jika berhasil, penyerang bisa membaca data yang tidak berhak diakses, mengubah atau menghapus data, atau bahkan menjalankan perintah administratif (tergantung konfigurasi DB).
NB: Ini adalah penjelasan konseptual — saya sengaja tidak menyertakan payload eksplisit atau langkah teknis untuk melakukan eksploit.

2) Tujuan penyerang
- Pencurian data: mengambil data pribadi warga, dokumen internal, atau kredensial.
- Mengubah data: memodifikasi konten situs (mis. pengumuman), mengubah catatan administratif.
- Menghapus/merusak data: mengganggu layanan atau merusak integritas data.
- Ekskalasi akses: mendapatkan kredensial/database admin untuk serangan lanjutan.
- Pemerasan/eksposur: mengambil data sensitif untuk menekan institusi (ransom/blackmail).
3) Dampak yang ditimbulkan
- Kerahasiaan: bocornya data pribadi warga/pegawai atau dokumen rahasia.
- Integritas: data yang diubah membuat kepercayaan publik hilang dan proses administratif terganggu.
- Ketersediaan: operasi layanan terganggu jika data dihapus atau DB dikunci.
- Reputasi & hukum: kerugian reputasi besar bagi instansi pemerintahan dan potensi sanksi hukum/kompliance.
- Biaya: biaya pemulihan, audit forensik, pemberitahuan kepada publik, dan kemungkinan kompensasi.
4) Cara pencegahan

Langkah teknis (minimal dua, praktis dan prioritas)
1. Gunakan parameterized queries / prepared statements
  Pastikan semua akses ke database memisahkan logika query dan data masukan. Hindari penggabungan string untuk membuat query. Gunakan mekanisme parameter pada framework/database driver yang digunakan.
2. Validasi dan sanitasi input di server-side
  Terapkan validasi tipe, panjang, format, dan whitelist untuk semua input. Validasi tidak hanya di client-side — mustahil mengandalkan JavaScript di browser.
3. Principle of least privilege untuk akun database
  Setiap aplikasi hanya boleh memiliki hak (privilege) yang diperlukan — mis. aplikasi baca/tulis untuk tabel tertentu, bukan hak admin atau DROP/ALTER kecuali benar-benar diperlukan.
4. Web Application Firewall (WAF) dan proteksi lapisan aplikasi
  Pasang WAF yang dapat memblok pola serangan umum serta aturan khusus untuk endpoint kritis. Namun WAF adalah lapisan tambahan, bukan pengganti perbaikan kode.
5. Keamanan konfigurasi dan patching
  Terapkan patch rutin untuk framework, library, dan DBMS; nonaktifkan fitur DB yang tidak perlu (mis. fitur remote admin tanpa autentikasi kuat).
6. Logging, monitoring, dan deteksi anomali
  Catat query yang gagal, error DB, dan pola request anomali. Siapkan alert untuk lonjakan error atau query yang mengakses data tidak biasa.
7. Input output encoding untuk konteks tampilan
  Untuk data yang ditampilkan kembali ke pengguna, lakukan encoding kontekstual untuk mencegah eksploitasi lain (meski ini lebih terkait XSS, tetap penting untuk integritas output).
8. Penetration testing dan code review berjadwal
  Lakukan pengujian keamanan aplikasi (oleh tim internal atau pihak ketiga) yang termasuk pengujian injeksi SQL dan review kode terhadap pola rentan.
Langkah kebijakan / prosedur kerja (minimal dua)
1. Secure SDLC (Software Development Life Cycle)
  Wajibkan tahapan keamanan dalam siklus pengembangan: threat modeling, checklist keamanan sebelum deploy, code review keamanan, dan persetujuan keamanan sebelum produksi.
2. Kebijakan manajemen akses & change control
  Terapkan proses otorisasi untuk perubahan kode dan database. Semua perubahan ke query/database harus melalui review dan dicatat. Batasi siapa yang boleh mengubah konfigurasi DB.
3. Pelatihan developer & ops mengenai OWASP dan praktik aman
  Adakan pelatihan rutin untuk tim pengembang/ops tentang injection, secure coding, penggunaan ORM/parameterized queries, dan bagaimana menanggulangi temuan audit.
4. Incident response plan khusus aplikasi web
  Buat prosedur respons jika ada indikasi SQL injection: isolasi aplikasi, snapshot DB untuk forensik, kontrol komunikasi publik, langkah mitigasi sementara (mis. memblokir IP, menonaktifkan endpoint), dan pelaporan ke otoritas bila perlu.
5. Audit rutin & kepatuhan
  Jadwalkan audit keamanan berkala (internal/eksternal), dan pastikan dokumentasi kepatuhan untuk standar yang relevan (mis. peraturan perlindungan data setempat).
5) Contoh checklist singkat untuk tim (bisa langsung dipakai)
- Pastikan semua query kritis menggunakan parameterized queries.
- Audit akun DB — tidak ada aplikasi menggunakan akun dengan hak admin penuh.
- Konfigurasi WAF untuk melindungi endpoint login / pencarian / upload.
- Terapkan logging query yang gagal dan alert anomali.
- Jadwalkan pentest aplikasi tiap 6–12 bulan.
- Update kebijakan SDLC: semua perubahan melewati code-review keamanan.
- Latihan tabletop untuk skenario kebocoran data.
6) Jika tim menemukan indikasi serangan (tindakan awal yang direkomendasikan)
1. Segera aktifkan mode mitigasi: batasi akses ke aplikasi (mis. rate-limit, blokir IP atau geolokasi yang mencurigakan) tanpa mematikan layanan sepenuhnya jika tidak perlu.
2. Ambil snapshot forensik database dan simpan log request (read-only) untuk investigasi.
3. Matikan sementara endpoint yang terdampak jika eksploit aktif dan risiko eskalasi besar.
4. Koordinasi dengan tim legal & komunikasi untuk langkah pelaporan dan pemberitahuan.
5. Lakukan root-cause analysis: perbaiki kode yang rentan, uji patch, lalu deploy dengan change control.
Sebagai penanggung jawab keamanan sistem pemerintahan, strategi pertahanan kami berfokus pada perlindungan data sensitif dari berbagai sisi. Semua password disimpan menggunakan hash yang diberi salt dan pepper, agar walaupun database bocor, data autentikasi tetap sulit direkonstruksi. Kami juga menerapkan pseudonymization, yaitu mengganti data identitas asli (seperti NIK atau nama lengkap) dengan kode unik, sehingga data tetap bisa diproses tanpa langsung menampilkan identitas warga. Akses internal dibatasi secara ketat berdasarkan prinsip least privilege, di mana setiap pegawai hanya dapat mengakses data yang benar-benar dibutuhkan untuk tugasnya. Selain itu, kami menjalankan audit dan logging secara berkelanjutan untuk mencatat setiap aktivitas penting dan mendeteksi anomali atau upaya akses tidak sah. Terakhir, kami menerapkan data minimization — hanya mengumpulkan dan menyimpan data yang relevan dengan layanan publik, sehingga risiko kebocoran dan penyalahgunaan data dapat ditekan seminimal mungkin.
Menurut saya, kebocoran data publik dari sistem pemerintahan jauh lebih berbahaya daripada sekadar kebocoran password. Kalau password bocor, kita masih bisa menggantinya — tapi kalau data pribadi seperti NIK, alamat, riwayat kesehatan, atau data keluarga tersebar, dampaknya bisa menetap seumur hidup. Dari sisi reputasi pribadi, orang bisa mengalami perundungan, pencurian identitas, atau bahkan ditipu menggunakan data mereka sendiri, dan itu sulit dipulihkan. Lebih jauh lagi, kepercayaan masyarakat terhadap pemerintah bisa runtuh; warga akan ragu memberikan data atau menggunakan layanan digital pemerintah karena takut disalahgunakan. Padahal, kepercayaan adalah fondasi utama transformasi digital sektor publik. Bagi saya, lembaga pengelola data punya tanggung jawab etis yang besar — bukan hanya soal memenuhi standar keamanan teknis, tapi juga menjaga martabat dan rasa aman setiap warga yang datanya mereka pegang. Mengelola data publik berarti mengemban kepercayaan publik; ketika kepercayaan itu hilang, semua kemajuan teknologi jadi tidak berarti.