Kebijakan Keamanan Informasi

Kebijakan Keamanan Informasi ini menjelaskan sertifikasi yang dimiliki Didit, kontrol teknis dan organisasi yang dioperasikan Didit, serta artefak kepercayaan yang tersedia untuk pelanggan, calon pelanggan, regulator, dan auditor. Kebijakan ini ditinjau setidaknya setiap enam bulan.

• Kontak keamanan: security@didit.me
• Petugas Perlindungan Data: dpo@didit.me
• Halaman status (real-time): status.didit.me
• Paket kepercayaan (di bawah NDA): email security@didit.me

1. Sertifikasi dan atestasi

Untuk meminta laporan atau sertifikat yang mendasarinya, kirim email ke security@didit.me. Laporan yang dibatasi berdasarkan ketentuan penerbitnya (misalnya, SOC 2 Type 1) dibagikan setelah Non-Disclosure Agreement (NDA) ditandatangani, pada hari kerja yang sama.

2. Lingkup

Kebijakan ini mencakup semua personel Didit (karyawan, kontraktor, dan pihak ketiga yang berwenang), semua sistem informasi produksi dan korporat Didit, dan Layanan yang berhadapan dengan pelanggan yang dijelaskan dalam Business Terms and Conditions. Kebijakan ini didukung oleh Pernyataan Penerapan yang menjadi dasar sistem manajemen ISO/IEC 27001:2022 Didit.

3. Tata Kelola

• Sistem Manajemen Keamanan Informasi dan Privasi selaras dengan kontrol ISO/IEC 27001:2022 dan ISO/IEC 27701, dengan Pernyataan Penerapan yang terdokumentasi.
• Chief Technology Officer adalah sponsor eksekutif keamanan informasi yang ditunjuk; Petugas Perlindungan Data (dpo@didit.me) memiliki tata kelola program privasi.
• Audit keamanan eksternal tahunan oleh auditor independen (pengawasan ISO 27001 dan pemeriksaan SOC 2).
• Daftar risiko ditinjau dan diperbarui setiap triwulan. Risiko material ditingkatkan ke komite manajemen.
• Peningkatan berkelanjutan, setiap insiden, temuan audit, dan penilaian risiko menjadi masukan untuk backlog tindakan korektif dan pembaruan kebijakan berikutnya.

4. Enkripsi dan manajemen kunci

• Saat istirahat: AES-256 di setiap basis data produksi, penyimpanan objek, dan volume cadangan.
• Saat transit: TLS 1.3 untuk setiap panggilan API eksternal, webhook, dan sesi Business Console. Versi TLS yang lebih lama dan cipher yang lemah dinonaktifkan. HTTP Strict Transport Security (HSTS) diberlakukan di seluruh situs dan dimuat sebelumnya.
• Manajemen kunci: AWS Key Management Service (KMS) menyimpan dan merotasi kunci. Kode aplikasi tidak pernah menyentuh materi kunci mentah. Kunci sandbox dan produksi sepenuhnya terpisah.
• Hashing: kredensial pelanggan di-hash dengan fungsi adaptif standar industri (bcrypt atau yang setara). Kunci API disimpan sebagai hash satu arah; nilai mentah hanya ditampilkan kepada operator pada saat pembuatan.

5. Identitas, akses, dan arsitektur zero-trust

• Zero-trust secara default, setiap permintaan ke setiap sistem internal diautentikasi dan diotorisasi. Tidak ada kepercayaan implisit berdasarkan lokasi jaringan.
• Kontrol akses berbasis peran (RBAC) dengan prinsip hak istimewa paling rendah. Tinjauan akses dijalankan setiap triwulan.
• Autentikasi Multi-Faktor (MFA) wajib untuk setiap karyawan, setiap sistem produksi, setiap konsol cloud, dan setiap akun hosting kode.
• Single Sign-On (SSO) untuk aplikasi internal, dengan MFA token perangkat keras untuk peran istimewa.
• Akses Just-in-Time untuk produksi: akses istimewa yang tetap adalah pengecualian, bukan aturan.
• Pencatatan audit, setiap tindakan istimewa dicatat ke pipeline audit yang tahan perubahan, hanya tulis sekali, yang disimpan setidaknya selama 12 bulan.

6. Residen data dan segregasi

• Uni Eropa secara default. Data produksi diproses dan disimpan di Uni Eropa di Amazon Web Services. Residen khusus wilayah atau di dalam negara tersedia pada kontrak Enterprise, tunduk pada ketersediaan, untuk yurisdiksi yang regulatornya mensyaratkan.
• Pemisahan lingkungan. Sandbox, staging, dan produksi diisolasi di lapisan jaringan, identitas, dan manajemen kunci. Tidak ada manusia atau layanan di satu lingkungan yang dapat membaca data di lingkungan lain tanpa jalur akses yang eksplisit dan diaudit.
• Pemisahan penyewa. Data multi-penyewa dipisahkan secara logis dengan kunci enkripsi per penyewa jika berlaku. Kueri lintas penyewa diblokir di lapisan aplikasi dan basis data.

7. Siklus hidup pengembangan aman (SDLC)

• Tinjauan kode diperlukan untuk setiap perubahan produksi. Tidak ada satu engineer pun yang dapat menggabungkan kode yang tidak ditinjau ke produksi.
• Static Application Security Testing (SAST), pemindaian dependensi, dan Software Composition Analysis (SCA) berjalan secara otomatis pada setiap pull request.
• Pemindaian kontainer dan infrastruktur pada setiap build dan pada jadwal berulang untuk gambar yang di-deploy.
• Pengujian keamanan pra-produksi untuk perubahan berdampak tinggi (autentikasi, manajemen kunci, pipeline biometrik, alur pembayaran).
• Uji penetrasi internal secara berkelanjutan; uji penetrasi eksternal setidaknya sekali setahun oleh spesialis independen. Temuan material dilacak hingga selesai pada jadwal yang terikat SLA.
• Saluran bug-bounty / pengungkapan bertanggung jawab, laporkan masalah keamanan ke security@didit.me.

8. Manajemen kerentanan

• SLA patching berdasarkan tingkat keparahan, kritis (dalam waktu 72 jam setelah pengungkapan vendor), tinggi (dalam waktu 7 hari), sedang (dalam waktu 30 hari), rendah (dalam waktu 90 hari).
• Pemindaian kerentanan berkelanjutan di seluruh infrastruktur produksi, kontainer, dan dependensi.
• Pemodelan ancaman untuk permukaan produk baru, pipeline biometrik, dan integrasi lintas lingkungan.

9. Pemantauan, deteksi, dan respons insiden

• Pemantauan 24x7 setiap sistem produksi dengan peringatan ketersediaan, kesalahan, dan sinyal keamanan.
• Security Information and Event Management (SIEM) mengagregasi dan mengkorelasikan peristiwa keamanan; pola abnormal ditingkatkan ke engineer keamanan on-call.
• Rencana Respons Insiden yang terdokumentasi dengan peran yang ditunjuk, pohon komunikasi, matriks tingkat keparahan, dan proses tinjauan pasca-insiden. Rencana tersebut diuji setidaknya setiap tahun melalui latihan tabletop.
• Pemberitahuan pelanggaran data pribadi. Didit memberitahu pelanggan yang terpengaruh tanpa penundaan yang tidak semestinya dan dalam hal apa pun tepat waktu untuk memungkinkan pelanggan memenuhi kewajiban pemberitahuan 72 jam mereka sendiri berdasarkan General Data Protection Regulation (GDPR) Pasal 33. Pelanggan Enterprise menerima engineer yang ditunjuk yang siaga dan saluran komunikasi khusus.
• Halaman status publik di status.didit.me, setiap insiden produksi, setiap post-mortem, tidak perlu login.

10. Kelangsungan bisnis dan pemulihan bencana

• Redundansi aktif Multi-AZ di setiap wilayah produksi; failover otomatis untuk layanan tanpa status.
• Cadangan dienkripsi, dipisahkan secara geografis dalam batas residensi yang dipilih, dan diuji pada jadwal berulang.
• Recovery Point Objective (RPO) ≤ 1 jam dan Recovery Time Objective (RTO) ≤ 4 jam untuk API verifikasi inti dan Business Console.
• Uji Pemulihan Bencana (DR) setidaknya setiap tahun.

11. Keamanan personel

• Pemeriksaan latar belakang pada setiap karyawan dan setiap kontraktor dengan akses ke data produksi atau data pribadi, jika diizinkan oleh hukum yang berlaku.
• Perjanjian kerahasiaan saat direkrut untuk setiap karyawan dan kontraktor.
• Pelatihan keamanan dan privasi wajib saat onboarding dan diperbarui setidaknya setiap tahun untuk setiap karyawan. Pelatihan yang ditargetkan (pengkodean aman, penanganan data biometrik, anti-penipuan, anti-pencucian uang) untuk peran yang membutuhkannya.
• Simulasi phishing pada jadwal berulang.
• Proses joiner / mover / leaver mencabut akses dalam waktu 24 jam setelah perubahan peran atau keberangkatan.

12. Manajemen vendor dan sub-prosesor

• Setiap sub-prosesor dinilai risikonya sebelum onboarding dan ditinjau ulang setidaknya setiap tahun.
• Setiap sub-prosesor menandatangani Data Processing Agreement (DPA) yang membebankan kewajiban perlindungan data yang secara substansial serupa dengan yang Didit berikan kepada pelanggannya sendiri.
• Daftar sub-prosesor saat ini dibagikan kepada pelanggan dan calon pelanggan melalui email setelah Non-Disclosure Agreement (NDA) ditandatangani. Kirim email ke security@didit.me untuk memintanya. Pelanggan yang berlangganan pemberitahuan perubahan sub-prosesor diberitahu melalui email dengan pemberitahuan yang cukup sebelumnya untuk mengajukan keberatan.

13. Hak subjek data dan penghapusan

• Hak akses dan portabilitas, `GET /v3/sessions/:session_id/decision/`.
• Hak untuk penghapusan, `POST /v3/sessions/:session_id/delete/`. Menghapus sesi dan setiap artefak tertaut di setiap replika.
• Retensi per aplikasi dapat dikonfigurasi di Business Console antara 30 hari dan 10 tahun; defaultnya tidak terbatas kecuali pelanggan mengkonfigurasi periode yang lebih pendek. Retensi data biometrik dalam setiap kasus tunduk pada, dan dibatasi oleh, hukum dan peraturan privasi biometrik yang berlaku, termasuk GDPR Pasal 9 Uni Eropa, Illinois Biometric Information Privacy Act (BIPA), Texas Capture or Use of Biometric Identifier Act (CUBI), Washington H.B. 1493, dan hukum privasi biometrik lain yang berlaku; di mana hukum tersebut menetapkan periode retensi yang lebih pendek atau kewajiban penghancuran yang lebih awal, aturan yang lebih pendek atau lebih ketat itu berlaku di atas periode retensi default atau yang dikonfigurasi pelanggan.
• Lihat Kebijakan Privasi dan Pemberitahuan Privasi Verifikasi untuk proses hak subjek data lengkap.

14. Melaporkan masalah keamanan

Jika Anda yakin telah menemukan kerentanan keamanan pada produk atau layanan Didit mana pun, kirim email ke security@didit.me dengan deskripsi, langkah-langkah reproduksi, dan dampak yang Anda amati. Didit mengakui laporan keamanan dalam waktu 2 hari kerja dan bekerja dengan itikad baik dengan pelapor yang mengikuti praktik pengungkapan yang bertanggung jawab.

15. Kontak

• Keamanan: security@didit.me
• Petugas Perlindungan Data: dpo@didit.me
• Privasi: privacy@didit.me
• Hukum / kontrak: legal@didit.me
• Permintaan paket kepercayaan (di bawah NDA): security@didit.me