1. Analisis Logika (25%)

Bayangkan sistem *CivChain* ini seperti sebuah rumah kaca (transparansi blockchain publik) yang di dalamnya ada seorang asisten yang cerewet dan sangat pintar (GenAI), dan pintu masuk resminya (Portal Pemerintah).

Risiko barunya muncul dari apa yang disebut **”Triangle of Unmasking”**:

1. Transparansi Blockchain: Data transaksi di blockchain publik memang tidak mencantumkan nama, tapi ia mencatat jejak waktu, lokasi node(validator), dan jenis aktivitas.
Contoh: Seseorang bernama Budi adalah satu-satunya warga di RT 05 yang mengurus Izin Usaha pada jam 09:00 – 10:00 pagi di tanggal itu, dan dokumennya divalidasi oleh Dinas A. Jika penyerang punya akses data registrasi warga (bisa dari kebocoran lain) atau data pendaftaran CivChain yang bocor (dari API Injection), mereka bisa menggabungkan data transaksi anonim (waktu, jenis, validator) dengan data eksternal ini. Voila, TxID yang awalnya anonim kini bisa mengarah ke Budi. Ini disebut Correlation Attack atau Timing Attack.

2. Kecerewetan GenAI: GenAI itu didesain untuk meringkas dan memahami konteks, yang berarti ia harus membaca data sensitif. Karena GenAI bekerja dengan model bahasa, terkadang ia bisa “muntah” (mengeluarkan) potongan data mentah yang seharusnya tidak terlihat.
Contoh Logika Sendiri: GenAI diminta meringkas Akta Kelahiran. Karena prompt awalnya mungkin kurang ketat, saat membuat ringkasan: “Dokumen ini sah milik anak dari Tn. Surya Atmaja, pegawai BUMN, yang lahir di Bandung.” Bagian yang saya tebalkan adalah informasi pribadi yang sensitif yang seharusnya tidak muncul di output ringkasan publik. Ini menunjukkan risiko Data Leakage dari Model Output.

3. Sentralisasi Portal: Meskipun data inti di blockchain, akses dan operasional tetap melalui CivChain Portal yang sifatnya sentralistik. Titik sentral ini menjadi sasaran empuk untuk serangan tradisional (DDoS, API Injection).
Risiko: Jika portal lumpuh (DDoS) atau API diretas (Injection), bukan hanya layanan berhenti, tetapi data metadata sensitif di database portal (misalnya, mapping antara ID pengguna dan alamat wallet blockchain) bisa dicuri. Kerentanan sentral di portal ini menghancurkan janji keamanan desentralisasi dari blockchain.

2. Dua Skenario (20%)

Fokus: Membuat dua cerita singkat tentang kapan Hashing vs. Enkripsi lebih tepat, dalam konteks yang relevan.

A: Hashing Lebih Tepat daripada Enkripsi

Skenario: Verifikasi Integritas Ijazah Digital.
Cerita Singkat: Dinas Pendidikan ingin memastikan ijazah digital yang diunduh warga tidak dimodifikasi saat dicetak atau diunggah ke platform lain.
Kenapa Hashing? Pemerintah cukup menyimpan hash (misalnya, SHA-256) dari file ijazah asli di CivChain. Ketika Budi mengunduh ijazahnya, sistem akan menghitung ulang hash dari file unduhan Budi. Jika hash yang dihitung Budi sama persis dengan hash yang tersimpan di CivChain, maka file ijazah itu 100% otentik dan belum diubah.
Hashing adalah fungsi satu arah (one-way function). Tujuannya bukan untuk menyembunyikan data (enkripsi), tetapi untuk memverifikasi integritas dan memastikan data tidak rusak atau dipalsukan. Kita tidak perlu membaca isinya (hanya perlu memastikan isinya sama).

B: Enkripsi Lebih Aman dan Hashing Tidak Cukup

Skenario:Penyimpanan Kunci Akses Dokumen Sensitif (misalnya, Sertifikat Tanah).
Cerita Singkat:CivChain menyimpan dokumen super sensitif (Sertifikat Tanah) secara off-chain (tidak di blockchain) atau dienkripsi sebelum masuk chain. Akses ke dokumen ini hanya boleh diberikan kepada pemilik (Bapak Dede) dan validator tertentu.
Kenapa Enkripsi? Kunci enkripsi dokumen Bapak Dede harus disimpan dengan aman. Jika kita hanya menyimpan hash dari kuncinya, data aslinya (kunci) akan tetap terekspos dan tidak bisa diakses kembali. Kita perlu bisa mengambil kembali (dekripsi) kunci tersebut saat Bapak Dede ingin mengakses dokumen.
Alasan Teknis: Enkripsi (misalnya AES-256) adalah proses dua arah (two-way process). Ini menyembunyikan data (kerahasiaan/ confidentiality) dan memungkinkan data asli diakses kembali menggunakan kunci. Hashing tidak cukup karena ia bersifat *irreversible* (tidak bisa dibalikkan); Anda tidak bisa mendapatkan data asli dari hash untuk membuka dokumen.

3. Contoh Data Buatan (15%)
Contoh Data Fiktif

Penjelasan Tebakan Penyerang:

Penyerang dapat berasumsi bahwa serangkaian transaksi yang terjadi dalam waktu yang sangat berdekatan (antara 14:05 – 14:12) kemungkinan besar berasal dari satu orang yang sama yang sedang memproses berbagai dokumen pribadinya. Dengan menggabungkan metadata dari TxID145 (“Pemilik: Ibu Siti”) dan TxID147 (“Lulusan terbaik dari jurusan TI, 2018”), penyerang berhasil menebak identitas lengkap: Ibu Siti, lulusan TI tahun 2018, yang baru membuka restoran.

4. Serangan ke Website Pemerintah (20%)

Fokus: Menganalisis satu jenis serangan (misal: SQL Injection), menjelaskan alur, tujuan, dampak, dan pencegahan (teknis & kebijakan).

Pilihan Serangan: SQL Injection (SQLi)

Langkah Penjelasan
Bagaimana Serangan Terjadi Penyerang menemukan form input atau parameter URL di CivChain Portal yang tidak memfilter input secara benar. Penyerang memasukkan kode SQL berbahaya, misalnya OR ‘1’=’1` ke dalam kolom pencarian. Kode ini akan dieksekusi oleh database server, memaksa sistem mengabaikan otentikasi atau menampilkan data yang seharusnya rahasia (misalnya, tabel yang memetakan alamat wallet blockchain ke NIK/nama warga). |
Tujuan Penyerang | Pencurian Data Sensitif yang disimpan secara sentralistik, seperti user credentials operator, data mapping ID pengguna dengan wallet address, atau bahkan data metadata dokumen yang digunakan GenAI. Tujuan akhir: De-anonymization (membuka anonimitas) warga di blockchain. |
Dampak yang Ditimbulkan** | **Kebocoran Data Pribadi** (NIK, nama lengkap, alamat, dll.), kerusakan atau modifikasi data di database sentral, dan **Hilangnya Kepercayaan** masyarakat terhadap sistem *CivChain* dan pemerintah. |
| Cara Pencegahan | |
| Teknis (Min. 2) | 1. Menggunakan *Prepared Statements* (Query Berparameter):** Memastikan *input* dari pengguna selalu diperlakukan sebagai data, bukan kode yang bisa dieksekusi SQL. 2. **Penerapan *Input Validation* dan *Output Encoding*:** Membatasi karakter yang boleh masuk di kolom input dan memastikan *output* yang ditampilkan ke pengguna tidak mengandung kode berbahaya. |
| Kebijakan/Prosedur (Min. 2)** | 1. **Prinsip *Least Privilege* pada Database:** Akun *database* yang digunakan oleh aplikasi web CivChain hanya boleh memiliki izin akses minimum yang diperlukan untuk fungsinya (misalnya, hanya *SELECT* dan *INSERT* yang diperlukan, bukan DROP TABLE). 2. Audit Keamanan Kode Berkala (Penetration Testing):** Melakukan pengujian keamanan eksternal dan internal secara rutin (setidaknya per kuartal) oleh tim independen untuk mengidentifikasi dan menambal kerentanan SQLi. |

5. Strategi Pertahanan (10%)

**Fokus:** Satu paragraf strategi keamanan yang mencakup: *salt/pepper, pseudonymization, pembatasan akses internal, audit dan logging, data minimization*.

#### Strategi Keamanan (Gaya Penanggung Jawab Keamanan)

Sebagai Penanggung Jawab Keamanan, strategi pertahanan kita adalah **”Pertahanan Berlapis dengan Fokus Anonimitas”**. Untuk melindungi data warga, kita akan menerapkan **Data Minimization**, di mana kita hanya mengumpulkan data sekecil mungkin yang esensial untuk layanan. Setiap data identitas sensitif akan di-*hash* menggunakan **salt** unik per pengguna, dan lapisan keamanan tambahan **pepper** (kunci rahasia server) akan ditambahkan agar *rainbow table attack* mustahil. Identitas warga di dalam sistem akan digantikan dengan **pseudonymization** (ID palsu/sementara) untuk memutus hubungan langsung dengan NIK/Nama asli, kecuali saat verifikasi akhir. Semua aktivitas, baik GenAI maupun operator, akan dicatat secara detail melalui **Audit dan Logging** yang ketat. Terakhir, kita akan menerapkan **Pembatasan Akses Internal** secara ketat, di mana operator hanya bisa mengakses data yang relevan dengan tugasnya (*Need-to-Know Basis*), mencegah penyalahgunaan data dari dalam.

### 6. Refleksi Etika dan Dampak Sosial (10%)

**Fokus:** Opini pribadi mengapa kebocoran data publik seperti ini lebih berbahaya daripada kebocoran *password* biasa.

#### Opini Pribadi: Bahaya yang Lebih Dalam

Kebocoran *password* adalah masalah yang merepotkan; kita tinggal ganti *password*, selesai. Namun, kebocoran data dari *CivChain* adalah bencana yang sifatnya **permanen dan merusak identitas**.

1. **Dampak terhadap Reputasi Seseorang:** Data di *CivChain* adalah **fakta hidup** seseorang: akta kelahiran, ijazah, izin usaha, bahkan status kepemilikan. Jika GenAI membocorkan ringkasan seperti “pemilik usaha yang pernah gagal bayar” atau “ijazah yang diperoleh dari program percepatan,” ini bisa merusak reputasi profesional dan kredibilitas seseorang seumur hidup, bahkan tanpa *password* mereka dicuri.
2. **Kepercayaan Masyarakat terhadap Pemerintah:** Sistem ini diluncurkan dengan janji anti-pemalsuan dan keamanan. Ketika kebocoran terjadi, yang runtuh adalah **otoritas dan kepercayaan** terhadap negara. Masyarakat akan berpikir, “Kalau data paling dasar saya saja tidak aman di tangan pemerintah, bagaimana dengan janji lainnya?” Keraguan ini menciptakan jurang pemisah antara pemerintah dan warga.
3. **Tanggung Jawab Etis Lembaga Pengelola Data:** Lembaga pengelola *CivChain* tidak hanya mengelola data, tetapi juga **masa depan digital** warga. Tanggung jawab etis mereka sangat besar karena data ini tidak bisa diubah (kecuali dengan prosedur hukum). Kegagalan keamanan di sini menunjukkan **pengkhianatan etis** terhadap janji untuk menjaga kedaulatan informasi publik. Dampaknya meluas dari masalah teknis menjadi krisis etika dan sosial.

—

Semoga kerangka ini sangat membantu Anda. Ingat, kuncinya adalah **mengembangkan contoh sendiri** dan **menggunakan bahasa yang lugas** seolah Anda benar-benar seorang ahli yang sedang menjelaskan konsep ini.

*Apakah Anda ingin saya memberikan saran lebih lanjut tentang gaya bahasa atau poin tertentu sebelum Anda mulai menulis Cermi Anda?*