แนวคิดเรื่องการปกป้องข้อมูล (การทำให้ไม่ระบุตัวตนและการเข้ารหัส)

ข้อมูลที่ได้จาก ReceiptRoller มีข้อมูลอ่อนไหว เช่น ข้อมูลยอดขายของร้านค้า และประวัติการซื้อของผู้บริโภค ไม่ใช่ว่า「ฝั่ง ReceiptRoller เข้ารหัสให้แล้วจึงวางใจได้」แต่การปกป้องอย่างเหมาะสมใน environment ของตนเองหลังรับข้อมูลมาคือความรับผิดชอบของนักพัฒนาแอปที่เชื่อมต่อ

การปกป้อง 3 ชั้น

การลดข้อมูลที่ดึงมาให้น้อยที่สุด

ดึงมาเฉพาะข้อมูลที่จำเป็น การที่ดึง receipt.* ได้ทั้งหมดไม่ได้แปลว่าต้องบันทึกทุกฟิลด์ ตัวอย่างเช่น หากใช้เพื่อทำสรุปยอด ก็สามารถตัดสินใจบันทึกแค่จำนวนเงิน วันเวลา และ ID ร้านค้าแล้วทิ้งรายละเอียดที่ไม่จำเป็นได้

เทคนิคการทำให้ไม่ระบุตัวตนและการใช้นามแฝง

การใช้นามแฝง (pseudonymization)

แทนที่ ID ลูกค้าด้วย ID อื่นภายในระบบของตนเองแล้วจึงจัดเก็บ เก็บตารางแมปกับ ID เดิมไว้ต่างหาก และทำให้ environment สำหรับวิเคราะห์มองไม่เห็น ID เดิม

// cus_xxx ของ ReceiptRoller → internal_user_yyy ของเรา
// ตารางแมปจัดการใน DB แยกและสิทธิ์เข้าถึงแยกต่างหาก

การทำ hash

ข้อมูลอย่างอีเมลหรือหมายเลขโทรศัพท์ที่ใช้ในการจับคู่แต่ไม่จำเป็นต้องเก็บในรูปแบบ plaintext ให้ทำ hash ด้วย SHA-256 เป็นต้นแล้วจึงจัดเก็บ

differential privacy

หากเพียงต้องการออกค่าสรุป ให้เพิ่ม noise เพื่อทำให้ระบุตัวบุคคลไม่ได้ เหมาะกับข้อมูลเชิงวิชาการและขนาดใหญ่

การเลือกใช้การเข้ารหัสให้เหมาะกับงาน

กุญแจให้จัดการแยกต่างหากด้วยบริการจัดการ secret อย่าวางไว้ใน repository เดียวกับโค้ด

การ mask log

เพื่อไม่ให้ข้อมูลส่วนบุคคลปนเข้ามาใน log การดำเนินงานและ error log ให้ใส่การประมวลผลแบบ mask ตอนเขียน output

// การ mask อีเมล
"user@example.com" → "u***@example.com"

// mask บางส่วนของ ID
"cus_abc123def456" → "cus_abc***456"

นโยบายการลบข้อมูล

• ลบเมื่อหมดวัตถุประสงค์: ข้อมูลสรุปที่วิเคราะห์เสร็จแล้ว ผู้ใช้ที่ยกเลิกไปแล้ว
• การรับมือคำขอให้ลบ: ลบทางกายภาพภายใน 30 วัน (backup ใช้นโยบายแยกต่างหาก)
• TTL อัตโนมัติ: ตั้งวันหมดอายุให้ record ใน DB แล้วลบอัตโนมัติเมื่อเลยกำหนด
• การตรวจสอบ: เก็บ log การลบ และบันทึกว่าการลบเสร็จสิ้นแล้ว

คู่มือที่เกี่ยวข้อง

• การควบคุมการเข้าถึงและ audit log
• แนวปฏิบัติที่ดีในการใช้งาน production
• กลับไปที่ Developer Help Top