ส่งยอดขายกลับ Google/Meta/TikTok ปลอดภัยแค่ไหน: เรื่อง Encryption ที่แอดมินมักไม่เคยถาม
สรุปสั้น ๆ
ทุกครั้งที่ส่งยอดขายจาก LINE กลับไปหา Google, Meta หรือ TikTok ข้อมูลนั้นเดินทางผ่านอินเทอร์เน็ต ถ้าช่องทางไม่ได้เข้ารหัสอย่างถูกต้อง ข้อมูลลูกค้าอาจถูกดักอ่านระหว่างทางได้ เรื่องนี้ฟังดูเทคนิคแต่แอดมินที่ไม่ใช่สายเขียนโค้ดก็เช็กเบื้องต้นเองได้
ร้านค้าจำนวนมากตั้งค่า Conversion API เสร็จ เห็นยอดขึ้นบน dashboard แล้วก็จบ ไม่เคยถามต่อว่าตอนที่ข้อมูลชื่อ เบอร์โทร หรือยอดสั่งซื้อ วิ่งจากระบบของร้านไปหาแพลตฟอร์มโฆษณา มันปลอดภัยแค่ไหนระหว่างทาง
คำถามนี้สำคัญกว่าที่คิด เพราะข้อมูลที่ส่งไปมักผ่านมือคนกลางหลายต่อ ตั้งแต่ระบบหลังบ้านของร้าน ไปจนถึง server ตัวกลาง (อย่าง GTM server-side) ก่อนจะถึงปลายทาง ถ้าจุดใดจุดหนึ่งระหว่างทางไม่ได้เข้ารหัสให้ดี ข้อมูลก็เสี่ยงถูกดักอ่านได้ในทางทฤษฎี
บทความนี้จะอธิบายเรื่อง encryption แบบที่แอดมินทั่วไปเข้าใจได้ ไม่ต้องเป็นโปรแกรมเมอร์ ก็เช็กและถามผู้ให้บริการของตัวเองถูกจุดได้
Encryption ตอน 'ส่ง' ต่างจากตอน 'เก็บ' อย่างไร
หลายคนเข้าใจว่า encryption มีแบบเดียว แต่จริง ๆ มีสองจังหวะที่ต้องดูแยกกัน อย่างแรกคือตอนข้อมูล 'พัก' อยู่ในฐานข้อมูล เรียกว่า encryption at rest ส่วนอย่างที่สองคือตอนข้อมูล 'กำลังเดินทาง' จากที่หนึ่งไปอีกที่หนึ่ง เรียกว่า encryption in transit
เวลาส่งยอดขายกลับไปหา ad platform สิ่งที่ต้องสนใจคือช่วง in transit เพราะข้อมูลกำลังวิ่งผ่านอินเทอร์เน็ตจริง ๆ ถ้าช่วงนี้ไม่เข้ารหัส คนที่ดักฟังสัญญาณระหว่างทางในทางทฤษฎีก็อาจอ่านข้อมูลได้ตรง ๆ
เช็กง่าย ๆ ที่แอดมินทำเองได้: HTTPS
สัญญาณพื้นฐานที่สุดที่บอกว่าการเชื่อมต่อเข้ารหัสอยู่หรือไม่ คือดูว่า URL ของระบบที่ใช้ขึ้นต้นด้วย https ไม่ใช่ http ธรรมดา ตัว s ท้าย http บอกว่ามีการเข้ารหัสระหว่างเบราว์เซอร์หรือระบบกับปลายทาง เกือบทุกแพลตฟอร์มใหญ่อย่าง Google, Meta, TikTok บังคับใช้ https อยู่แล้วในฝั่งของเขา
สิ่งที่ร้านต้องเช็กเพิ่มคือ ถ้าใช้ระบบตัวกลางอย่างGTM server-side containerหรือระบบของ agency ที่ช่วยส่งข้อมูลแทน ต้องถามให้ชัดว่าตัวกลางนั้นใช้ https ตลอดทางหรือไม่ ไม่ใช่แค่ปลายทางสุดท้าย เพราะถ้าจุดกลางจุดใดจุดหนึ่งหลุดไปเป็น http ก็ถือว่าช่องโหว่ยังอยู่
อีกชั้นที่ช่วยได้: เข้ารหัสข้อมูลก่อนส่ง ไม่ใช่แค่ระหว่างส่ง
นอกจาก https แล้ว แพลตฟอร์มอย่าง Meta และ Google ยังกำหนดให้ข้อมูลส่วนตัวอย่างอีเมลหรือเบอร์โทร ต้องผ่านการแฮช (hashing) ก่อนส่งเข้า Conversion API เสมอ ซึ่งเป็นคนละเรื่องกับ encryption in transit แต่ทำงานเสริมกัน คือต่อให้มีคนดักข้อมูลระหว่างทางได้จริง สิ่งที่เห็นก็เป็นรหัสที่อ่านไม่ออก ไม่ใช่เบอร์โทรตรง ๆ
รายละเอียดเรื่องการแฮชข้อมูลก่อนส่งเข้า CAPI นี้ เราเขียนแยกไว้ละเอียดในบทความเรื่องการแฮชอีเมลและเบอร์โทรก่อนส่งเข้า CAPI ถ้าร้านไหนยังไม่เคยเช็กจุดนี้ ควรเริ่มจากตรงนั้นก่อน
คำถามที่ควรถามผู้ให้บริการหรือทีมพัฒนาระบบ
- ระบบที่ใช้ส่งข้อมูล conversion ใช้ https ตลอดทางหรือไม่ รวมถึงจุดตัวกลางทุกจุด
- ข้อมูลอ่อนไหวอย่างอีเมล เบอร์โทร มีการแฮชก่อนส่งออกจากระบบร้านหรือไม่
- ถ้าใช้ server-side tracking มี log เก็บข้อมูลดิบไว้นานแค่ไหน และใครเข้าถึง log นั้นได้บ้าง
- มีการตรวจสอบใบรับรอง SSL/TLS ของระบบเป็นระยะหรือไม่ ไม่ใช่ตั้งครั้งเดียวแล้วปล่อยไว้
ร้านเล็กก็ควรสนใจเรื่องนี้ ไม่ใช่แค่บริษัทใหญ่
หลายคนคิดว่าเรื่อง encryption เป็นเรื่องของบริษัทเทคโนโลยีขนาดใหญ่ แต่ความจริงร้านค้าเล็กที่ส่งข้อมูลลูกค้าจำนวนมากผ่าน server-to-server ทุกวันก็มีความเสี่ยงไม่ต่างกัน เพราะข้อมูลที่ส่งคือของลูกค้าจริง ไม่ใช่ข้อมูลทดสอบ การถามคำถามพวกนี้กับผู้ให้บริการที่ใช้อยู่ ไม่ใช่เรื่องเกินตัวเลย แม้จะเป็นร้านที่มีทีมแค่ไม่กี่คน
สรุป
การตั้งค่า Conversion API ให้ยอดขึ้นบน dashboard เป็นแค่ครึ่งเดียวของงาน อีกครึ่งที่มักถูกมองข้ามคือความปลอดภัยของข้อมูลระหว่างทางที่ส่งออกไป ซึ่งเป็นข้อมูลลูกค้าจริงทุกวัน
ไม่ต้องเป็นโปรแกรมเมอร์ก็เริ่มเช็กได้ แค่ถามคำถามที่ถูกต้องกับผู้ให้บริการหรือทีมที่ดูแลระบบให้ แล้วจดคำตอบไว้เป็นบันทึกของร้าน เผื่อวันหน้าต้องอธิบายให้ลูกค้าฟังว่าร้านดูแลข้อมูลเขาอย่างไร
- แยกให้ออกระหว่าง encryption ตอนเก็บข้อมูล กับตอนส่งข้อมูล
- เช็ก https ตลอดทาง ไม่ใช่แค่ปลายทางสุดท้าย
- การแฮชข้อมูลอ่อนไหวก่อนส่งเป็นการป้องกันอีกชั้นที่ควรมีคู่กัน
คำถามที่พบบ่อย
ร้านที่ใช้ Conversion API ผ่านปลั๊กอินสำเร็จรูป ต้องกังวลเรื่อง encryption เองไหม
โดยทั่วไปปลั๊กอินสำเร็จรูปจากผู้ให้บริการที่น่าเชื่อถือมักตั้งค่า https ให้อยู่แล้ว แต่ควรถามผู้ให้บริการให้ชัดว่าใช้มาตรฐานนี้จริง โดยเฉพาะถ้ามีการส่งข้อมูลผ่านตัวกลางเพิ่มเติมนอกเหนือจากปลั๊กอินหลัก
https อย่างเดียวเพียงพอไหมสำหรับการปกป้องข้อมูลลูกค้า
https ช่วยป้องกันระหว่างทาง แต่ควรมีการแฮชข้อมูลอ่อนไหวอย่างอีเมลหรือเบอร์โทรก่อนส่งด้วย เพื่อให้มีการป้องกันสองชั้น ถ้าชั้นใดชั้นหนึ่งมีช่องโหว่ อีกชั้นยังช่วยลดความเสียหายได้
จะรู้ได้ยังไงว่าระบบตัวกลางอย่าง server-side tracking ปลอดภัยพอ
ให้ถามตรง ๆ กับทีมพัฒนาหรือผู้ให้บริการว่าใช้ https ตลอดทาง เก็บ log นานแค่ไหน และใครเข้าถึง log ได้บ้าง ถ้าตอบไม่ชัดเจนหรือไม่มีใครรู้คำตอบ นั่นคือสัญญาณว่าควรตรวจสอบเพิ่ม
การส่งข้อมูลผ่าน server-to-server ปลอดภัยกว่าการยิงตรงจากเบราว์เซอร์ไหม
โดยทั่วไปการส่งแบบ server-to-server ควบคุมได้ง่ายกว่าเพราะไม่ผ่านเบราว์เซอร์ของผู้ใช้ปลายทาง แต่ความปลอดภัยยังขึ้นกับว่า server ตัวกลางนั้นตั้งค่าเข้ารหัสถูกต้องหรือไม่ ไม่ได้ปลอดภัยอัตโนมัติเพียงเพราะเปลี่ยนวิธีส่ง
ถ้าธุรกิจเล็กไม่มีทีมเทคนิค ควรเริ่มตรงไหนก่อน
เริ่มจากถามผู้ให้บริการหรือเอเจนซี่ที่ดูแลระบบให้ตอบคำถามสี่ข้อในบทความนี้ให้ชัดเจนก่อน ถ้าไม่มีใครตอบได้ อาจถึงเวลาต้องทบทวนว่าผู้ให้บริการรายนั้นดูแลข้อมูลลูกค้าอย่างจริงจังแค่ไหน
บทความที่เกี่ยวข้อง
