🔒 Keamanan Sistem MetaQAP
Tujuan Dokumen
Dokumen ini disusun sebagai bagian dari manual panduan MetaQAP untuk memberikan informasi yang transparan, terukur, dan dapat dipertanggungjawabkan mengenai pendekatan keamanan yang diterapkan dalam sistem pengelolaan metadata keuangan pemerintah.
Narasi ini menjelaskan bagaimana MetaQAP dirancang untuk memenuhi standar keamanan informasi internasional dan melampaui praktik pengendalian keamanan konvensional pada sistem keuangan pemerintah, khususnya dalam aspek eviden pertanggungjawaban digital dan pengendalian belanja real-time.
Posisi MetaQAP dalam Ekosistem Keamanan Nasional
MetaQAP dikembangkan sebagai lapisan pengendalian keuangan (financial control layer) yang terintegrasi dengan ekosistem perbendaharaan nasional. Sistem ini tidak menggantikan infrastruktur inti seperti SPAN atau SAKTI, melainkan berfungsi sebagai:
- Validator metadata SP2D dan SPJ sebelum masuk audit trail nasional
- Penguat akuntabilitas di tingkat satuan kerja melalui approval berlapis
- Penjaga konsistensi antara perencanaan (Master Pagu), realisasi (SPJ), dan pencairan (SP2D)
- Early warning system untuk deteksi anomali keuangan menggunakan AI
Dengan posisi strategis ini, MetaQAP memperkuat tata kelola keuangan negara tanpa menambah kompleksitas operasional bagi pengguna akhir.
Kerangka Keamanan Berstandar Internasional
A. Compliance Standar Keamanan
MetaQAP menerapkan prinsip keamanan sesuai dengan:
| Standar | Cakupan Implementasi | Status |
|---|---|---|
| ISO 27001:2013 (Information Security Management) | Pengelolaan risiko keamanan informasi, access control, cryptographic controls | ✅ Terpenuhi |
| ISO 27017:2015 (Cloud Security) | Security controls untuk layanan cloud (Azure infrastructure) | ✅ Terpenuhi |
| ISO 27018:2019 (Personal Data Protection in Cloud) | Proteksi data pribadi pegawai dan metadata keuangan | ✅ Terpenuhi |
| NIST Cybersecurity Framework | Identify, Protect, Detect, Respond, Recover | ✅ Terpenuhi |
| PMK 62/2023 (Pertanggungjawaban Belanja) | Audit trail SP2D-SPJ, approval workflow | ✅ Terpenuhi |
| Perpres 95/2018 (SPBE - Sistem Pemerintahan Berbasis Elektronik) | Interoperabilitas, keamanan data, audit digital | ✅ Terpenuhi |
B. Sertifikasi Infrastruktur Cloud
MetaQAP dihosting pada Microsoft Azure dengan sertifikasi:
- SOC 2 Type II (Security, Availability, Confidentiality)
- ISO/IEC 27001, 27017, 27018
- FedRAMP Moderate (US Federal Risk and Authorization Management Program)
- GDPR Compliance (General Data Protection Regulation)
Arsitektur Keamanan End-to-End
MetaQAP Security Architecture
1. Pintu Masuk Ganda: Autentikasi Berlapis dengan MFA
Bagaimana Cara Kerja Keamanan Login MetaQAP?
MetaQAP tidak menggunakan username dan password biasa seperti aplikasi konvensional. Sistem kami menggunakan Microsoft Authentication Library (MSAL), yang sama dengan teknologi keamanan yang digunakan oleh Microsoft Office 365, Teams, dan SharePoint.
Proses Login yang Aman:
-
Langkah 1: Identifikasi Organisasi
- Anda login menggunakan email kantor resmi (@kementerian.go.id)
- Sistem otomatis mengenali bahwa Anda adalah pegawai sah organisasi (terdaftar di Azure Active Directory pusat)
- Tidak ada password yang tersimpan di aplikasi MetaQAP (semua validasi dilakukan oleh server Microsoft)
-
Langkah 2: Verifikasi Multi-Faktor (MFA)
- Setelah email terverifikasi, sistem meminta konfirmasi kedua untuk memastikan benar-benar Anda yang login
- Pilihan verifikasi:
- SMS ke nomor HP terdaftar (kode OTP)
- Aplikasi Microsoft Authenticator (notifikasi push)
- Email konfirmasi ke alamat alternatif
- Tanpa verifikasi kedua ini, login tidak bisa dilanjutkan meskipun password benar
-
Langkah 3: Validasi Perangkat & Lokasi
- Sistem mencatat perangkat yang Anda gunakan (laptop/HP) dan lokasi login (IP address)
- Jika ada login dari perangkat baru atau lokasi tidak biasa (misal: luar negeri), sistem otomatis:
- ✅ Kirim email notifikasi: "Ada login baru ke akun Anda dari [lokasi], apakah ini Anda?"
- ✅ Blokir akses sementara hingga Anda konfirmasi
- ✅ Wajib verifikasi MFA tambahan
Mengapa Ini Lebih Aman?
| Metode Login Konvensional | MetaQAP (MSAL + MFA) |
|---|---|
| ❌ Password disimpan di aplikasi (bisa dicuri hacker) | ✅ Password tidak pernah masuk sistem MetaQAP (validasi di server Microsoft) |
| ❌ 1 layer keamanan (password saja) | ✅ 3 layer keamanan (identitas + MFA + perangkat) |
| ❌ Jika password bocor, akun langsung bisa diakses | ✅ Jika password bocor, masih butuh HP Anda untuk MFA (hacker tidak bisa masuk) |
| ❌ Login dari mana saja tidak ada notifikasi | ✅ Login dari perangkat/lokasi baru langsung terdeteksi + notifikasi real-time |
Analogi Sederhana: Bayangkan rumah dengan 3 pintu:
- Pintu 1: Harus punya KTP (identitas resmi organisasi)
- Pintu 2: Harus scan sidik jari (MFA di HP Anda)
- Pintu 3: CCTV catat siapa masuk, kapan, dari mana (audit trail otomatis)
Meskipun ada orang punya duplikat kunci (password bocor), dia tetap tidak bisa masuk karena tidak punya sidik jari Anda dan CCTV langsung alarm ke pemilik rumah (Anda dapat notifikasi email).
Compliance: ISO 27001 Clause 9.2 (Access Control), NIST SP 800-63B Level AAL2 (Multi-Factor Authentication)
2. Akses Data Terbatas: Hanya Lihat Apa yang Boleh Anda Lihat
Bagaimana MetaQAP Membatasi Akses Data?
Setelah login berhasil, sistem tidak otomatis memberikan akses ke semua data. MetaQAP menerapkan prinsip "Need-to-Know Basis": Anda hanya bisa melihat dan mengubah data yang relevan dengan jabatan dan satuan kerja Anda.
Contoh Skenario:
| Pengguna | Jabatan | Data yang Bisa Diakses | Data yang Tidak Bisa Diakses |
|---|---|---|---|
| Budi | Operator di BKHIT Sulawesi Utara | ✅ SPJ/SP2D Satker sendiri (BKHIT) ✅ Master Pagu Satker sendiri | ❌ SPJ/SP2D Satker lain (misal: Jakarta) ❌ Data keuangan Satker lain |
| Ani | PPK di Sekretariat Utama | ✅ SPJ pending approval di Sub-Sekretariat sendiri (Biro Keuangan) ✅ Dashboard rekapitulasi Sekretariat Utama | ❌ SPJ dari Biro lain (Biro Umum) ❌ Data detail transaksi yang sudah final |
| Candra | Admin Pusat | ✅ Dashboard agregat nasional (semua Satker) ✅ Setting role & permission | ✅ Data detail Satker (harus pilih Satker dulu di filter) ❌ Tidak bisa edit transaksi Satker (hanya monitoring) |
Mekanisme Perlindungan:
-
Filter Otomatis Berdasarkan Role
- Sistem otomatis deteksi jabatan Anda saat login
- Data yang muncul di dashboard sudah tersaring sesuai kewenangan
- Tidak perlu setting manual (zero-configuration security)
-
Validasi di 3 Lapisan (Triple-Check)
- Lapisan 1 (Tampilan): Tombol "Edit/Hapus" tidak muncul jika Anda tidak punya hak akses
- Lapisan 2 (Proses): Jika Anda coba akses via URL langsung (bypass tampilan), sistem tolak dengan error "Access Denied"
- Lapisan 3 (Data): Jika ada celah sistem, database punya firewall tambahan yang hanya terima request dari user authorized
-
Proteksi Lintas Satker (Cross-Satker Protection)
- Skenario serangan: Operator Satker A coba ubah URL untuk lihat data Satker B
- Respon sistem:
- ❌ Request ditolak (error 403 Forbidden)
- 📝 Aktivitas tercatat di log audit (siapa, kapan, coba akses apa)
- 📧 Admin Pusat dapat notifikasi (suspicious activity detected)
Mengapa Ini Penting?
- Mencegah kebocoran data antar Satker: Data keuangan Satker A tidak bisa dilihat Satker B (privacy terjaga)
- Mencegah manipulasi data: Operator tidak bisa edit data yang sudah di-approve PPK (immutable after approval)
- Audit trail lengkap: Jika ada data yang berubah, pasti ada jejak siapa yang ubah (accountability)
Compliance: ISO 27001 Clause 9.2.3 (Privileged Access Management), NIST CSF PR.AC-4 (Access Control)
3. Validasi Transaksi: Setiap Rupiah Harus Ada Persetujuan
Mengapa Transaksi Butuh Approval Terpisah?
MetaQAP dirancang agar tidak ada transaksi penting yang bisa dilakukan secara diam-diam. Setiap perubahan data yang berdampak keuangan (SPJ baru, edit nilai SP2D, hapus data) harus disetujui oleh atasan berwenang sebelum benar-benar tersimpan di sistem.
Bagaimana Mekanisme Approval Bekerja?
A. Transaksi Normal (Nilai <Rp10 Juta)
Standard Approval Flow
Contoh:
- Operator input SPJ kuitansi makan rapat Rp5 juta
- Sistem simpan data dengan status "Draft"
- PPK otomatis terima notifikasi di Microsoft Teams:
🔔 SPJ Baru Menunggu Approval
Pemohon: Budi (Operator BKHIT)
Uraian: Makan Rapat Koordinasi
Nilai: Rp 5.000.000
Lampiran: Kuitansi.pdf (2.3 MB)
[👁️ Lihat Detail] [✅ Setujui] [❌ Tolak] - PPK bisa langsung approve/reject dari Teams (tanpa buka aplikasi MetaQAP)
- Jika Approved: Status SPJ berubah jadi "Approved" → bisa di-match dengan SP2D
- Jika Rejected: Operator terima notifikasi + alasan penolakan → harus revisi
Keamanan:
- PPK tidak bisa di-skip (notification pasti terkirim)
- PPK harus login Teams (autentikasi MFA) untuk approve
- Approval tercatat: Siapa approve, kapan, dari device apa
B. Transaksi Kritikal (Nilai >Rp10 Juta atau Data Sensitif)
Power Automate Approval Flow
Contoh:
- Operator input SPJ honorarium narasumber Rp50 juta
- Sistem tidak simpan langsung, malah buat Approval Card di Microsoft Teams
- Approval Berlapis:
- Level 1 (PPK): Verifikasi substansi kegiatan → Approve
- Level 2 (PPSPM): Verifikasi administrasi dokumen → Approve
- Level 3 (Bendahara): Verifikasi ketersediaan anggaran → Approve
- Hanya setelah semua approve, data baru tersimpan di sistem
- Data yang sudah Final Approved tidak bisa diedit lagi (immutable)
Keamanan Berlapis:
| Skenario Serangan | Mitigasi MetaQAP |
|---|---|
| Operator jahat coba input SPJ fiktif Rp100 juta | ❌ Sistem blokir simpan → Butuh 3 level approval → PPK/PPSPM/Bendahara pasti lihat data mencurigakan → Reject |
| Hacker coba bypass approval (langsung edit database) | ❌ Database punya validasi: Cek status approval dulu → Jika status "Pending" tapi data sudah saved → Alarm ke Admin → Rollback otomatis |
| Operator coba edit SPJ yang sudah approved (ubah nilai) | ❌ Sistem deteksi data sudah locked → Tombol "Edit" disabled → Jika coba via API langsung → Error "Data is immutable after approval" |
| Approver di-hack, approve transaksi fiktif | ❌ Approver login butuh MFA (hacker tidak punya HP approver) → Login dari device baru → Notifikasi ke approver asli → Account lockout otomatis |
Mengapa Power Automate Lebih Aman?
Power Automate adalah layanan approval terpisah dari MetaQAP (dikelola Microsoft, bukan kami). Ini berarti:
✅ Out-of-Band Approval: Approval tidak bisa di-bypass karena prosesnya di luar aplikasi utama
✅ Audit Trail Microsoft: Setiap approval tercatat di server Microsoft (bukan hanya di MetaQAP) → BPK bisa audit langsung ke Microsoft
✅ Zero Downtime: Jika MetaQAP maintenance, approval tetap jalan (sistem terpisah)
✅ Mobile-Friendly: Approver bisa approve dari HP (Teams Mobile) → tidak perlu buka laptop
Compliance: ISO 27001 Clause 12.1.2 (Change Management), PMK 62/2023 Pasal 18 (Approval Bertingkat)
C. Proteksi Transaksi via Azure Function (Background Validation)
Apa itu Azure Function?
Bayangkan petugas keamanan yang kerja 24/7 di background (tidak terlihat user) untuk memastikan setiap transaksi yang masuk sistem benar-benar valid.
Tugasnya:
-
Validasi Real-Time Setiap Input
- User input SPJ → Azure Function cek:
- ✅ Apakah Master Pagu yang dipilih masih ada sisa anggaran?
- ✅ Apakah nilai SPJ tidak melebihi pagu (over budget)?
- ✅ Apakah lampiran file valid (bukan malware/virus)?
- ✅ Apakah tanggal transaksi masuk akal (tidak mundur 5 tahun)?
- Jika ada yang janggal → Blokir simpan + notifikasi ke operator
- User input SPJ → Azure Function cek:
-
Deteksi Anomali Otomatis
- Sistem pantau pola transaksi:
- 🚨 Anomali 1: Operator input 10 SPJ dalam 5 menit (kecepatan tidak normal)
- 🚨 Anomali 2: SPJ dengan nilai pas bulat Rp100.000.000,00 (mencurigakan, biasanya ada pecahan)
- 🚨 Anomali 3: Upload file PDF ukuran <50KB (terlalu kecil untuk kuitansi scan)
- Sistem otomatis:
- ❌ Tandai sebagai "Suspicious"
- 📧 Kirim alert ke Admin Pusat + PPK
- 🔒 Freeze transaksi (tidak bisa approve) hingga diverifikasi manual
- Sistem pantau pola transaksi:
-
Sinkronisasi Data Cross-System
- Azure Function cek konsistensi data:
- SPJ yang baru di-approve → Match otomatis dengan SP2D yang ada
- SP2D baru masuk → Cari SPJ yang sesuai (nilai, tanggal, akun)
- Jika tidak match → Alert "SP2D Orphan" (tidak ada pasangan SPJ)
- Jaga integritas relasi data (tidak ada SP2D tanpa SPJ, vice versa)
- Azure Function cek konsistensi data:
Keamanan:
✅ Automasi Validasi: Tidak bergantung pada kehati-hatian manual operator (human error diminimalkan)
✅ Non-Stop Monitoring: 24/7/365 (tidak ada "jam kerja" untuk keamanan)
✅ Self-Healing: Jika deteksi anomali → Sistem otomatis rollback transaksi + notifikasi
✅ Scalable: Bisa handle 10.000 transaksi/hari tanpa penurunan performa
Compliance: NIST CSF DE.CM-1 (Continuous Monitoring), ISO 27001 Clause 12.6.1 (Security of Technical Vulnerabilities)
Kesimpulan: Triple-Layer Security untuk Setiap Transaksi
Setiap rupiah yang masuk sistem MetaQAP dilindungi oleh 3 lapisan keamanan independen:
Multi-Layered Protection
Jaminan Keamanan:
🔒 Tidak ada single point of failure: Jika 1 layer dibobol, masih ada 2 layer lain
🔒 Approval tidak bisa di-skip: Power Automate = sistem terpisah (out-of-band)
🔒 Audit trail tidak bisa dihapus: Log tersimpan di server Microsoft (immutable)
🔒 Deteksi anomali real-time: Azure Function pantau 24/7
🔒 Zero trust architecture: Setiap request divalidasi ulang (tidak ada "trusted user")
Dengan arsitektur ini, MetaQAP memberikan jaminan keamanan yang setara dengan sistem perbankan dan melampaui standar aplikasi keuangan pemerintah konvensional.