ความปลอดภัยและ PDPA
ระบบป้องกันข้อมูลรั่ว ต้องไม่กลายเป็นแหล่งรั่วเสียเอง
เรารวบรวมสัญญาณจากข้อความของพนักงานทั้งองค์กรไว้ที่เดียว นั่นคือความรับผิดชอบที่ต้องออกแบบให้ถูกตั้งแต่บรรทัดแรก ค่าเริ่มต้นทุกอย่างจึงเอียงไปทางเก็บให้น้อยที่สุด
- 01
เครื่องพนักงาน
Extension ตรวจชั้น L1 และ L2 ในเครื่อง ราว 80–85% ของข้อความจบที่นี่และไม่ถูกส่งไปไหน
- 02
เซิร์ฟเวอร์ของเรา (สิงคโปร์)
เฉพาะข้อความที่ชั้นแรกสงสัย ถูกส่งมาประเมินตามนโยบายและตอบจาก cache หากเคยตรวจแล้ว
- 03
ผู้ให้บริการโมเดล AI (ต่างประเทศ)
เฉพาะ 3–5% ที่ต้องเข้าใจบริบท ส่งผ่านผู้ให้บริการที่ตั้งค่าห้ามเก็บข้อมูล (zero retention) เท่านั้น
- 04
ฐานข้อมูล
เก็บเฉพาะ hash ของข้อความ ประเภทข้อมูลที่พบ และข้อความสั้นที่ปิดบังแล้ว ลบอัตโนมัติตาม retention
มาตรการทางเทคนิค
ชั้นการป้องกันที่ใช้จริง
- การส่งข้อมูล
- TLS 1.3 เท่านั้น, HSTS และ certificate pinning ใน extension
- การยืนยันตัวตน
- token อายุสั้นพร้อม refresh rotation และ rate limit ต่ออุปกรณ์
- การแยกข้อมูลระหว่างลูกค้า
- ทุก query ถูกบังคับให้อยู่ในขอบเขตองค์กรโดยระบบ ไม่พึ่งความจำของนักพัฒนา และมีเทสต์ที่พยายามอ่านข้ามลูกค้าแล้วต้องล้มเหลวทุกครั้งที่ deploy
- ความลับของระบบ
- ไม่มี secret ใดอยู่ใน extension ใช้ secret manager ฝั่งเซิร์ฟเวอร์
- การเข้ารหัส
- เข้ารหัสขณะจัดเก็บ และเข้ารหัสระดับฟิลด์เพิ่มสำหรับข้อมูลอ่อนไหว ด้วยกุญแจแยกต่อลูกค้า
- บันทึกการตรวจสอบ
- audit log แบบเขียนได้อย่างเดียว ลบไม่ได้แม้เป็นผู้ดูแลระบบ
- ห่วงโซ่ซัพพลาย
- ล็อก dependency, ตรวจช่องโหว่อัตโนมัติ และตรวจ extension bundle ก่อนเผยแพร่ทุกครั้ง
- การเฝ้าระวัง
- แจ้งเตือนเมื่อมี query ข้ามลูกค้า เมื่อผู้ดูแลเข้าถึงข้อมูลรายบุคคล และเมื่อ error rate ผิดปกติ
PDPA
ข้อกำหนดแต่ละข้อ ระบบรองรับอย่างไร
ประเด็นการส่งข้อความไปตรวจด้วยโมเดลในต่างประเทศเป็นการโอนข้อมูลส่วนบุคคลข้ามพรมแดน เราเปิดเผยเรื่องนี้ในเอกสารการขาย และแนะนำให้ที่ปรึกษากฎหมายของคุณดูก่อนเปิดใช้งาน
| ข้อกำหนด | ระบบรองรับอย่างไร |
|---|---|
| ฐานทางกฎหมายในการประมวลผล | ฐานประโยชน์โดยชอบด้วยกฎหมาย พร้อมเทมเพลต LIA ให้ลูกค้าใช้ |
| การแจ้งวัตถุประสงค์ | banner ตอนติดตั้ง extension และหน้าประกาศความเป็นส่วนตัวที่พนักงานต้องอ่าน |
| สิทธิ์เข้าถึงข้อมูลของตน | หน้า "ประวัติของฉัน" ของพนักงานทุกคน ปิดไม่ได้ |
| สิทธิ์ขอลบ | ปุ่มลบข้อมูลรายบุคคล ลบทันที บันทึกใน audit log |
| การเก็บเท่าที่จำเป็น | ไม่เก็บข้อความเต็มเป็นค่าเริ่มต้น และลบอัตโนมัติตาม retention ที่ตั้งไว้ |
| มาตรการรักษาความปลอดภัย | เข้ารหัสขณะจัดเก็บ เข้ารหัสระดับฟิลด์ สิทธิ์ตามบทบาท และ audit log |
| การโอนข้อมูลไปต่างประเทศ | เปิดเผยว่าการตรวจชั้น L3 ส่งไปผู้ให้บริการโมเดลในต่างประเทศ ใช้เฉพาะผู้ให้บริการที่ไม่เก็บข้อมูล และมีตัวเลือกเก็บข้อมูลในไทยสำหรับ Enterprise |
| บันทึกกิจกรรมการประมวลผล (RoPA) | สร้างอัตโนมัติในรายงาน PDPA |
เมื่อต้องดูข้อมูลรายบุคคล
มีขั้นตอน มีเหตุผล และมีบันทึกเสมอ
ไม่มีบทบาทใดในระบบที่เห็นข้อความของคนอื่นเป็นค่าเริ่มต้น การเข้าถึงระดับบุคคลต้องผ่านขั้นตอนนี้เท่านั้น
- 01
ผู้ดูแลเปิดคำขอสอบสวน ระบุเหตุผลและช่วงเวลา
- 02
ระบบแจ้งพนักงานที่เกี่ยวข้องภายใน 24 ชั่วโมง เว้นกรณีสอบสวนทุจริตที่มีเหตุผลทางกฎหมาย
- 03
เปิดสิทธิ์เข้าถึงชั่วคราว 72 ชั่วโมง แล้วปิดอัตโนมัติ
- 04
ทุกการเข้าถึงถูกบันทึก: ใคร ดูอะไร เมื่อไหร่ ด้วยเหตุผลอะไร
- 05
บันทึกนี้ปรากฏในรายงาน PDPA ขององค์กร
ข้อจำกัดที่เราบอกตรงๆ
สิ่งที่ระบบนี้ทำไม่ได้
การบอกข้อจำกัดตั้งแต่แรกคือสิ่งที่ทำให้ไว้ใจกันได้ในระยะยาว
- Extension ป้องกันได้เฉพาะเบราว์เซอร์ที่ติดตั้งไว้ ผู้ใช้ที่ปิด extension เปิด incognito ใช้มือถือ หรือเรียก API ตรง จะหลุดจากการตรวจ
- ระบบเป็นชั้นที่เตือนผู้ใช้ตอนกำลังจะพลาด ไม่ใช่กำแพงที่บังคับได้ 100% การบังคับจริงต้องคู่กับการ force-install ผ่าน Google Workspace Admin หรือ Group Policy
- ตัวตรวจจับมีโอกาสพลาดทั้งสองทาง เป้าหมาย precision 0.92 หมายความว่าราว 8 ใน 100 การเตือนจะเป็นการเตือนผิด
- ข้อความที่ต้องตรวจด้วย AI ชั้น L3 ออกนอกประเทศ เว้นแต่ใช้ตัวเลือกเก็บข้อมูลในไทย
- ผู้ใช้ที่ตั้งใจหลบเลี่ยงจริงๆ หลบได้ ระบบนี้กันความผิดพลาดโดยไม่ตั้งใจ ซึ่งเป็นสาเหตุของเหตุการณ์ส่วนใหญ่