วิธี Audit การจัดหมวดหมู่คุกกี้ ของธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี พร้อม Evidence ที่ควรเก็บ

วิศวกรของ SaaS ด้าน project management แห่งหนึ่งเปิด tag manager ขึ้นมาดูระหว่างเตรียมเอกสารสำหรับลูกค้าองค์กรรายใหญ่ที่กำลังจะเซ็นสัญญา แล้วพบว่าคุกกี้ตัวหนึ่งชื่อ _analytics_session ถูกจัดอยู่ในหมวด "จำเป็นต่อการทำงานของเว็บไซต์" มาตั้งแต่วันที่ระบบเปิดตัว ทั้งที่จริงแล้วคุกกี้ตัวนี้เชื่อมกับเครื่องมือวิเคราะห์พฤติกรรมของบุคคลที่สามที่ทีม Growth เพิ่มเข้ามาทีหลัง ไม่ได้จำเป็นต่อการทำงานของระบบเลย คนที่ตั้งค่าตอนแรกอาจแค่เดาว่าฟังดูเหมือนจำเป็นเพราะชื่อมีคำว่า session แล้วไม่มีใครตรวจซ้ำอีกเลยตลอดสองปี

การจัดหมวดหมู่คุกกี้ผิดแบบนี้ไม่ใช่เรื่องแปลกในธุรกิจ SaaS ที่มีคุกกี้และสคริปต์สะสมจากหลายทีมและหลายรอบ deploy เพราะการจัดหมวดครั้งแรกมักทำโดยคนคนเดียวภายใต้เวลาจำกัด แล้วไม่มีใครกลับไปทวนซ้ำจนกว่าจะมีเหตุการณ์มากระตุ้น บทความนี้เป็นคู่มือ Audit ภาคปฏิบัติสำหรับทีม Product, Engineering, Growth และ Privacy ที่ต้องการตรวจว่าหมวดหมู่คุกกี้ที่ใช้อยู่ยังตรงกับหน้าที่จริงของแต่ละตัว สำหรับพื้นฐานของหลักการจัดหมวดหมู่คุกกี้ตั้งแต่ต้น ดูเพิ่มเติมได้ที่ คู่มือการจัดหมวดหมู่คุกกี้สำหรับธุรกิจ SaaS

การ Audit ในบทความนี้หมายถึงการตรวจสอบภายในเชิงปฏิบัติ (internal/self-audit) เพื่อยกระดับความถูกต้องของการจัดหมวดหมู่ ไม่ใช่การตรวจรับรองตามกฎหมายโดยหน่วยงานภายนอก หลักการทางเทคนิคของคุกกี้อ้างอิงจาก MDN Web Docs ส่วนข้อกำหนดทางกฎหมายควรตรวจสอบกับสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง

ทำไมหมวดหมู่คุกกี้ของ SaaS ถึงคลาดเคลื่อนได้ง่าย

คุกกี้ที่ "มีอยู่ในรายการ" กับคุกกี้ที่ "จัดหมวดถูกต้อง" เป็นคนละเรื่องกัน หลักการพื้นฐานตาม เอกสารของ MDN Web Docs เรื่อง HTTP Cookies อธิบายว่าคุกกี้แต่ละตัวมีหน้าที่เฉพาะของมัน เช่น เก็บสถานะการล็อกอิน จำการตั้งค่าภาษา หรือส่งข้อมูลให้เครื่องมือวิเคราะห์บุคคลที่สาม การจัดหมวดที่ถูกต้องต้องอิงจาก หน้าที่จริง ของคุกกี้แต่ละตัว ไม่ใช่อิงจากชื่อหรือความเชื่อของคนที่ตั้งค่าตอนแรก ธุรกิจ SaaS มีความเสี่ยงเฉพาะตัวที่ทำให้หมวดหมู่คลาดเคลื่อนเร็ว ได้แก่ การมีทีมหลายทีม (Product, Growth, Engineering) เพิ่มเครื่องมือใหม่ผ่าน tag manager แยกกัน การเปลี่ยนผู้ให้บริการ third-party โดยไม่มีใครทบทวนหมวดหมู่เดิม และการที่วิศวกรผู้ตั้งค่าครั้งแรกลาออกหรือย้ายทีมไปแล้ว ทำให้ไม่มีใครรู้เหตุผลเบื้องหลังการจัดหมวดเดิมอีกต่อไป

เมื่อผลิตภัณฑ์เติบโตและต้องผ่านขั้นตอน security review ก่อนลูกค้าองค์กรเซ็นสัญญา คำถามเรื่องความถูกต้องของหมวดหมู่คุกกี้มักถูกยกขึ้นมาโดยตรง เพราะทีม security ของลูกค้าองค์กรมักตรวจสอบว่าสิ่งที่ระบุไว้ในเอกสารตรงกับพฤติกรรมจริงของระบบหรือไม่ การมีผล Audit ล่าสุดพร้อมส่งจึงมีผลโดยตรงต่อความเร็วในการปิดดีล

เตรียมการก่อนเริ่ม Audit

เริ่มจากดึงรายการคุกกี้และสคริปต์ทั้งหมดที่ทำงานอยู่บนผลิตภัณฑ์จาก tag manager หรือระบบจัดการสคริปต์ที่ใช้อยู่ จากนั้นจัดทำตารางสามคอลัมน์ คือ ชื่อคุกกี้/สคริปต์ หมวดหมู่ที่ระบุไว้ปัจจุบัน และผู้ให้บริการ (vendor) ที่เกี่ยวข้อง ทีมที่ควรเข้าร่วมอย่างน้อยคือ Engineering ที่เข้าถึง tag manager ได้จริง Product หรือ Growth ที่รู้ว่าแต่ละเครื่องมือถูกเพิ่มเข้ามาทำไม และ Privacy ที่ตัดสินได้ว่าหมวดหมู่ใดควรจัดอย่างไรตามหลักการที่ถูกต้อง

คำถามที่ทีมต้องตอบได้ก่อนลงมือ

ก่อนเริ่มตรวจ ทีมควรตอบได้ว่าปัจจุบันมีคุกกี้และสคริปต์ทั้งหมดกี่ตัวที่ทำงานบนผลิตภัณฑ์ แต่ละตัวจัดอยู่หมวดใดและจัดโดยใคร มีเอกสารอ้างอิงจากผู้ให้บริการแต่ละรายที่ระบุหน้าที่ของคุกกี้ตัวนั้นหรือไม่ คำตอบเหล่านี้จะกลายเป็น baseline สำหรับเทียบผลตรวจในขั้นถัดไป

ขั้นตอน Audit การจัดหมวดหมู่คุกกี้ทีละขั้น

ขั้นที่ 1: ตรวจหน้าที่จริงของคุกกี้แต่ละตัวเทียบกับเอกสารผู้ให้บริการ

ไล่ตรวจคุกกี้ทีละตัวจากรายการที่ดึงมา ค้นหาเอกสารทางการของผู้ให้บริการแต่ละราย เช่น เอกสารของเครื่องมือวิเคราะห์หรือเครื่องมือการตลาดที่ใช้อยู่ ว่าคุกกี้ตัวนั้นเก็บข้อมูลอะไรและใช้เพื่อจุดประสงค์ใด แล้วเทียบกับหมวดหมู่ที่ระบบจัดไว้ในปัจจุบัน คุกกี้ที่จัดอยู่ในหมวด "จำเป็น" ทั้งที่จริงแล้วเป็นคุกกี้วิเคราะห์หรือการตลาด คือ finding ที่ต้องแก้ไขก่อนอื่น เพราะทำให้ผู้ใช้งานไม่มีโอกาสปฏิเสธคุกกี้ที่ไม่จำเป็นจริง ๆ

ขั้นที่ 2: ทดสอบว่าการบล็อกตามหมวดทำงานถูกต้องจริง

เปิด network tab แล้วทดสอบปิดทีละหมวด ตรวจว่าคุกกี้และสคริปต์ในหมวดนั้นหยุดทำงานจริง ไม่ใช่แค่หายไปจากหน้าตั้งค่าแต่ยังยิง request อยู่เบื้องหลัง จุดที่ควรระวังเป็นพิเศษคือสคริปต์ที่โหลดสคริปต์อื่นต่อ (script ที่โหลด script) เพราะบางครั้งการบล็อกสคริปต์หลักไม่ได้บล็อกสคริปต์ลูกที่ถูกโหลดตามมาด้วยเสมอไป

ขั้นที่ 3: ตรวจความสอดคล้องระหว่างหมวดหมู่กับผู้ให้บริการเดียวกัน

บางครั้งผู้ให้บริการรายเดียวกันอาจมีคุกกี้หลายตัวที่ทำหน้าที่ต่างกัน เช่น เครื่องมือหนึ่งอาจมีทั้งคุกกี้ที่จำเป็นต่อการยืนยันตัวตนและคุกกี้ที่ใช้วิเคราะห์พฤติกรรม การจัดทุกตัวของผู้ให้บริการรายเดียวกันไว้หมวดเดียวกันทั้งหมดโดยไม่แยกตามหน้าที่จริง เป็นความผิดพลาดที่พบบ่อย ให้ตรวจแยกเป็นรายคุกกี้ ไม่ใช่รายผู้ให้บริการ

ขั้นที่ 4: ตรวจคุกกี้ที่เพิ่มเข้ามาใหม่ตั้งแต่รอบตรวจก่อนหน้า

เทียบรายการคุกกี้ปัจจุบันกับรายการจากรอบตรวจก่อนหน้า คุกกี้ตัวใหม่ที่ปรากฏขึ้นควรมีบันทึกว่าใครเพิ่มเข้ามา เพื่อจุดประสงค์ใด และจัดอยู่หมวดใดพร้อมเหตุผล ถ้าพบคุกกี้ใหม่ที่ไม่มีที่มาชัดเจน ให้สืบต่อว่ามาจาก feature ใดหรือทีมใดติดตั้งไว้ ก่อนตัดสินใจว่าควรคงไว้หรือถอดออก

ขั้นที่ 5: ตรวจอายุการเก็บ (retention) ของแต่ละหมวดให้สมเหตุสมผล

นอกจากหมวดหมู่แล้ว ควรตรวจด้วยว่าระยะเวลาที่คุกกี้แต่ละตัวถูกเก็บไว้สมเหตุสมผลกับหน้าที่ของมันหรือไม่ คุกกี้ที่ใช้เพียงระหว่าง session ควรหมดอายุเมื่อปิดเบราว์เซอร์ ขณะที่คุกกี้ที่ใช้จำการตั้งค่าอาจเก็บได้นานกว่า หากพบว่าคุกกี้วิเคราะห์พฤติกรรมถูกตั้งให้เก็บนานผิดปกติโดยไม่มีเหตุผลรองรับ ควรบันทึกเป็น finding เพื่อนำไปปรับปรุงร่วมกับทีมที่เกี่ยวข้อง

Evidence ที่ควรเก็บจากการ Audit แต่ละรอบ

• ตารางคุกกี้ทั้งหมด พร้อมหมวดหมู่ ผู้ให้บริการ หน้าที่ และระยะเวลาเก็บ ณ วันที่ตรวจ
• เอกสารอ้างอิงจากผู้ให้บริการแต่ละราย ที่ใช้ประกอบการตัดสินใจจัดหมวด
• ผลทดสอบการบล็อกตามหมวด พร้อมภาพ network request ก่อนและหลัง
• รายชื่อคุกกี้ใหม่ที่พบตั้งแต่รอบก่อนหน้า พร้อมที่มาและเหตุผลการจัดหมวด
• รายงานสรุปผลตรวจ ระบุ finding แต่ละข้อและระดับความรุนแรง
• บันทึกการแก้ไข finding ว่าแต่ละข้อถูกแก้เมื่อไรและตรวจซ้ำแล้วหรือยัง

สถานการณ์ตัวอย่างจริง

กรณีที่หนึ่ง — คุกกี้วิเคราะห์ถูกจัดเป็นจำเป็นตั้งแต่วันแรก: ตามตัวอย่างต้นบทความ คุกกี้ _analytics_session ถูกจัดหมวดผิดมาตั้งแต่วันเปิดตัวเพราะคนตั้งค่าตอนแรกเดาจากชื่อ การตรวจตามขั้นที่ 1 ที่เทียบกับเอกสารผู้ให้บริการโดยตรง แทนที่จะเดาจากชื่อ ช่วยให้ทีมแก้ไขได้ทันก่อนที่ลูกค้าองค์กรจะตรวจพบเองระหว่าง security review

กรณีที่สอง — สคริปต์ลูกไม่ถูกบล็อกตามสคริปต์แม่: SaaS ด้าน customer support ติดตั้งวิดเจ็ตแชทที่โหลดสคริปต์วิเคราะห์เพิ่มเติมอัตโนมัติหลังโหลดเสร็จ เมื่อผู้ใช้งานปิดหมวดการตลาด สคริปต์แม่ของวิดเจ็ตหยุดทำงาน แต่สคริปต์ลูกที่โหลดไปแล้วยังทำงานต่อ การทดสอบตามขั้นที่ 2 ที่ตรวจ network tab อย่างละเอียดหลังปิดแต่ละหมวด ช่วยจับปัญหานี้ได้

กรณีที่สาม — คุกกี้เก็บนานเกินความจำเป็น: ทีม Growth ของ SaaS ด้าน e-learning ตั้งค่าคุกกี้ติดตามพฤติกรรมให้เก็บนานสองปี ทั้งที่ใช้งานจริงเพียงแค่วิเคราะห์ session การใช้งานภายในสามสิบวัน การตรวจตามขั้นที่ 5 ช่วยให้ทีมปรับระยะเวลาเก็บให้สอดคล้องกับหน้าที่จริง ลดความเสี่ยงจากการเก็บข้อมูลนานเกินความจำเป็น

ทำ Audit ให้เป็นงานประจำของทีมที่เพิ่มเครื่องมือบ่อย

สำหรับ SaaS ที่เพิ่มเครื่องมือใหม่ผ่าน tag manager อยู่เสมอ ความถี่ที่เหมาะสมคืออย่างน้อยทุกไตรมาส และควรผนวกการตรวจหมวดหมู่เป็นขั้นตอนหนึ่งในกระบวนการอนุมัติก่อนเพิ่มเครื่องมือใหม่ทุกครั้ง ไม่ใช่รอให้สะสมแล้วค่อยไล่ตรวจย้อนหลัง กำหนดเจ้าของงานให้ชัดหนึ่งคน มักเป็นฝั่ง Privacy หรือ Engineering lead ที่มีสิทธิ์เข้าถึง tag manager สำหรับงานที่ตรวจซ้ำได้ด้วยเครื่องมือ สามารถใช้ เครื่องมือสแกนเว็บไซต์ฟรีของ trusty เพื่อดูภาพรวมคุกกี้ที่ทำงานอยู่ก่อนไล่ตรวจแบบละเอียด และดูหัวข้ออื่นในหมวดเดียวกันเพิ่มเติมได้ที่ คลังความรู้ Cookies & Consent

เช็กลิสต์ปฏิบัติ

• ดึงรายการคุกกี้และสคริปต์ทั้งหมดจาก tag manager ก่อนเริ่มตรวจ
• ตรวจหน้าที่จริงของแต่ละคุกกี้เทียบกับเอกสารผู้ให้บริการ ไม่ใช่เดาจากชื่อ
• ทดสอบปิดแต่ละหมวดแล้วตรวจ network tab ว่าสคริปต์ลูกหยุดทำงานด้วย
• ตรวจว่าคุกกี้ของผู้ให้บริการรายเดียวกันจัดหมวดแยกตามหน้าที่จริง ไม่รวมเป็นหมวดเดียว
• เทียบรายการคุกกี้ใหม่กับรอบตรวจก่อนหน้า พร้อมบันทึกที่มา
• ตรวจระยะเวลาเก็บของแต่ละคุกกี้ให้สมเหตุสมผลกับหน้าที่
• เก็บชุด Evidence ของรอบนี้พร้อมวันที่และผู้ตรวจ

ข้อผิดพลาดที่พบบ่อย

• จัดหมวดคุกกี้จากการเดาชื่อ ไม่ได้ตรวจเอกสารของผู้ให้บริการจริง
• รวมคุกกี้ทุกตัวของผู้ให้บริการรายเดียวกันไว้หมวดเดียว ทั้งที่แต่ละตัวมีหน้าที่ต่างกัน
• ทดสอบการบล็อกเฉพาะสคริปต์หลัก ไม่ตรวจสคริปต์ลูกที่ถูกโหลดตามมา
• เพิ่มคุกกี้ใหม่ผ่าน tag manager โดยไม่บันทึกที่มาและเหตุผลการจัดหมวด
• ตั้งระยะเวลาเก็บคุกกี้นานเกินความจำเป็นโดยไม่มีเหตุผลรองรับ
• ทำ Audit ครั้งเดียวตอนเปิดตัวผลิตภัณฑ์แล้วไม่กำหนดรอบถัดไป

สรุป

การ Audit การจัดหมวดหมู่คุกกี้คือการตรวจว่าสิ่งที่ระบุไว้ในระบบยังตรงกับหน้าที่จริงของคุกกี้แต่ละตัว ไม่ใช่การจัดหมวดที่ตกทอดมาจากการเดาของคนตั้งค่าคนแรก สำหรับธุรกิจ SaaS ที่เพิ่มเครื่องมือใหม่บ่อย การตรวจหน้าที่จริงเทียบเอกสารผู้ให้บริการ ทดสอบการบล็อกตามหมวด และตรวจระยะเวลาเก็บข้อมูล อย่างน้อยทุกไตรมาส พร้อมเก็บ Evidence ทุกรอบ จะช่วยให้ทีมมั่นใจได้ว่าหมวดหมู่ที่ผู้ใช้งานเห็นตรงกับความเป็นจริงเสมอ

แหล่งข้อมูลอ้างอิง

หลักการทางเทคนิคของคุกกี้และการทำงานของเบราว์เซอร์อ้างอิงจาก MDN Web Docs — Using HTTP Cookies ส่วนแนวปฏิบัติด้านความยินยอมภายใต้ PDPA ควรตรวจสอบกับสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง บทความนี้อธิบายแนวปฏิบัติเชิงระบบและไม่ตีความข้อกฎหมายแทนหน่วยงานกำกับดูแล