10 ข้อผิดพลาดเรื่องการจัดหมวดหมู่คุกกี้ที่องค์กรการเงินควรหลีกเลี่ยง

ทีมตรวจสอบภายในของธนาคารแห่งหนึ่งเปิด Developer Tools ตรวจสอบเว็บไซต์จริง แล้วพบว่า Script ที่ทำงานอยู่มากกว่าครึ่งไม่ตรงกับหมวดหมู่ที่ Consent Banner ประกาศไว้ Script ที่ระบุว่าเป็น Necessary กลับส่งข้อมูลไปยังผู้ให้บริการวิเคราะห์พฤติกรรมภายนอกด้วย นี่คือรูปแบบความผิดพลาดที่พบซ้ำในองค์กรการเงินหลายแห่ง ไม่ใช่เหตุการณ์เฉพาะกรณีใดกรณีหนึ่ง

ความเสี่ยงเฉพาะขององค์กรการเงินเมื่อจัดหมวดหมู่คุกกี้ผิด

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

นอกจากนี้ Cookie ของแพลตฟอร์มโฆษณาที่ทำงานร่วมกับข้อมูลพฤติกรรมทางการเงิน เช่น การเข้าชมหน้าผลิตภัณฑ์สินเชื่อหรือประกัน มีลักษณะใกล้เคียงกับการทำ Profiling ทางการเงิน ซึ่งควรได้รับการตรวจสอบเข้มงวดกว่าคุกกี้ Marketing ทั่วไปในธุรกิจอื่น

จุดที่ทีมองค์กรขนาดใหญ่จัดหมวดหมู่คุกกี้ผิดพลาดบ่อยที่สุด

Script ตรวจจับการฉ้อโกงและ Session คุ้มครองบัญชี

ทีมเทคนิคมักจัด Script เหล่านี้เป็น Necessary ทั้งชุดเพราะเกี่ยวข้องกับความปลอดภัย แต่ Script บางตัวมีองค์ประกอบของการเก็บ Fingerprint อุปกรณ์หรือพฤติกรรมเพื่อการวิเคราะห์เชิงลึกที่เกินกว่าการป้องกันการฉ้อโกงพื้นฐาน ส่วนที่เกินขอบเขตนี้ควรแยกพิจารณาเป็นหมวดอื่นแทนที่จะเหมารวมเป็น Necessary ทั้งหมด

Script จาก Vendor ที่ผูกมากับสัญญาระดับองค์กร

Vendor ที่องค์กรทำสัญญาระดับองค์กรด้วย เช่น ระบบ Call Center หรือ CRM มักถูกยกเว้นจากกระบวนการตรวจสอบ Cookie เพราะทีมจัดซื้อมองว่าผ่านการอนุมัติสัญญาแล้วเท่ากับผ่านการตรวจสอบด้าน Privacy ด้วย ทั้งที่เป็นคนละกระบวนการ

Subdomain และเว็บไซต์ของบริษัทในเครือที่ไม่ผ่านมาตรฐานกลาง

บริษัทในเครือหรือ Subdomain ที่ทีมส่วนกลางไม่ได้ดูแลโดยตรง มักติดตั้ง Script ของตัวเองโดยไม่ผ่านมาตรฐานการจัดหมวดหมู่เดียวกับเว็บไซต์หลัก ทำให้ผู้ใช้ที่เข้าชมสองเว็บไซต์ในเครือเดียวกันเห็นการจัดหมวดหมู่คุกกี้ที่ไม่สอดคล้องกัน

ไม่มีการสแกนซ้ำหลังผ่านไปหลายเดือน

ตาราง Cookie Classification ที่ทำไว้ตอนเปิดตัวเว็บไซต์มักไม่ถูกอัปเดตอีกเลย ทั้งที่ Vendor เปลี่ยน Cookie ใหม่หรือเพิ่ม Third-party Request อยู่เสมอ การไม่สแกนซ้ำทำให้สิ่งที่ประกาศไว้ห่างจากสิ่งที่ทำงานจริงมากขึ้นเรื่อยๆ ตามเวลา

ผลกระทบเมื่อการจัดหมวดหมู่ไม่ตรงกับสิ่งที่ Consent Banner สื่อสาร

เมื่อ Script ที่รันจริงไม่ตรงกับหมวดหมู่ที่ประกาศ ผู้ใช้ที่กด Reject All ยังอาจถูกเก็บข้อมูลผ่าน Script ที่ถูกจัดหมวดผิดเป็น Necessary โดยไม่รู้ตัว ซึ่งขัดกับสิ่งที่ Consent Banner สื่อสารไว้กับผู้ใช้ตั้งแต่แรก และเมื่อฝ่ายตรวจสอบภายในหรือหน่วยงานกำกับดูแลเข้ามาตรวจสอบ ความไม่ตรงกันนี้จะกลายเป็นข้อค้นพบที่ต้องมีแผนแก้ไขและรายงานกลับ

วิธีตรวจจับความไม่ตรงกันก่อนที่ฝ่ายตรวจสอบจะพบเอง

องค์กรการเงินไม่ควรรอให้ฝ่ายตรวจสอบภายในหรือหน่วยงานกำกับดูแลเป็นผู้พบความไม่ตรงกันก่อน ทีม Privacy หรือ Security ควรใช้เครื่องมือสแกน Third-party Request แบบอัตโนมัติเปรียบเทียบกับตาราง Cookie Classification ที่มีอยู่เป็นประจำ โดยเฉพาะการเปรียบเทียบ Request ที่เกิดขึ้นจริงในสถานการณ์ Reject All กับสิ่งที่ Consent Banner สื่อสารไว้ว่าจะไม่มี Script ใดทำงานนอกเหนือจาก Necessary

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

คำถามที่พบบ่อย

Script ตรวจจับการฉ้อโกงควรจัดเป็น Necessary ทั้งหมดหรือไม่

ไม่ควรเหมารวมทั้งหมด ส่วนที่จำเป็นต่อการป้องกันการฉ้อโกงพื้นฐานจัดเป็น Necessary ได้ แต่ส่วนที่เก็บ Fingerprint อุปกรณ์หรือพฤติกรรมเพื่อการวิเคราะห์เชิงลึกเกินความจำเป็นควรแยกพิจารณาเป็นหมวดอื่น

Vendor ที่ผ่านสัญญาระดับองค์กรแล้วต้องตรวจสอบ Cookie อีกหรือไม่

ต้องตรวจสอบแยกต่างหาก เพราะการอนุมัติสัญญาทางธุรกิจกับกระบวนการตรวจสอบด้าน Privacy เป็นคนละขั้นตอน สัญญาที่ผ่านอนุมัติไม่ได้แปลว่า Cookie ที่ Vendor ใช้ผ่านการตรวจสอบด้าน Consent แล้ว

ทำไม Subdomain ของบริษัทในเครือถึงมีปัญหาการจัดหมวดหมู่คุกกี้บ่อย

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

ควรสแกน Cookie ซ้ำบ่อยแค่ไหนสำหรับองค์กรการเงิน

ควรสแกนซ้ำอย่างน้อยทุกไตรมาส และทุกครั้งที่มีการเพิ่ม Vendor หรือ Script ใหม่ เพราะ Third-party Request เปลี่ยนแปลงได้โดยไม่ต้องแก้โค้ดฝั่งองค์กรเลย

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

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

• ตรวจสอบว่า Script ตรวจจับการฉ้อโกงแยกส่วนที่เกินขอบเขตความปลอดภัยพื้นฐานออกจากหมวด Necessary
• ให้ทีม Privacy ตรวจสอบ Cookie ของ Vendor ทุกรายแยกจากกระบวนการอนุมัติสัญญาทางธุรกิจ
• ตรวจสอบว่า Subdomain และเว็บไซต์บริษัทในเครือใช้มาตรฐานการจัดหมวดหมู่เดียวกับเว็บไซต์หลัก
• สแกน Script ที่รันจริงบนเว็บไซต์เทียบกับหมวดหมู่ที่ Consent Banner ประกาศไว้อย่างน้อยทุกไตรมาส
• ทดสอบว่าผู้ใช้ที่กด Reject All ไม่ถูกเก็บข้อมูลผ่าน Script ที่จัดหมวดผิดเป็น Necessary
• บันทึกผลการสแกนแต่ละรอบไว้เป็นหลักฐานเปรียบเทียบย้อนหลัง
• ทบทวนสัญญา Vendor ที่มีความเสี่ยงสูงเป็นลำดับต้นก่อน Vendor รายย่อย

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

• จัด Script ตรวจจับการฉ้อโกงทั้งชุดเป็น Necessary โดยไม่แยกส่วนที่เก็บ Fingerprint เพิ่มเติม
• เชื่อว่า Vendor ที่ผ่านสัญญาระดับองค์กรแล้วผ่านการตรวจสอบด้าน Cookie ไปด้วย
• ปล่อยให้ Subdomain ของบริษัทในเครือติดตั้ง Script โดยไม่ผ่านมาตรฐานกลาง
• ไม่สแกน Script ที่รันจริงซ้ำหลังผ่านไปหลายเดือนนับจากตอนเปิดตัวเว็บไซต์
• ไม่ทดสอบว่าผู้ใช้ที่กด Reject All ยังถูกเก็บข้อมูลผ่าน Script ที่จัดหมวดผิดหรือไม่
• ไม่แยกลำดับความสำคัญของ Vendor ที่มีความเสี่ยงสูงออกจาก Vendor รายย่อยเมื่อทบทวนสัญญา
• ปล่อยให้ Cookie ของแพลตฟอร์มโฆษณาที่ใกล้เคียงกับ Profiling ทางการเงินอยู่ในหมวด Marketing ทั่วไปโดยไม่ตรวจเข้มงวดเพิ่ม
• ไม่มีบันทึกผลการสแกนย้อนหลัง ทำให้เปรียบเทียบความเปลี่ยนแปลงไม่ได้เมื่อเกิดข้อผิดปกติ
• ให้ทีมพัฒนาของแต่ละ Business Unit ตัดสินใจจัดหมวดหมู่เองโดยไม่ผ่านทีม Privacy ส่วนกลาง
• ไม่ปรับตาราง Cookie Classification หลังผลสแกนพบความไม่ตรงกัน ปล่อยให้ Consent Banner สื่อสารข้อมูลที่ล้าสมัยต่อไป

สรุป

องค์กรการเงินมีความเสี่ยงเพิ่มเติมจากการจัดหมวดหมู่คุกกี้ผิดพลาด เพราะเกี่ยวพันกับข้อมูลทางการเงินและพฤติกรรมที่อ่อนไหวของลูกค้า จุดที่พลาดบ่อยที่สุดคือ Script ด้านความปลอดภัยที่เหมารวมเป็น Necessary, Vendor ที่ผ่านสัญญาธุรกิจแต่ไม่ผ่านการตรวจสอบด้าน Cookie และ Subdomain ของบริษัทในเครือที่ไม่ผ่านมาตรฐานกลาง การสแกนซ้ำเป็นรอบและเปรียบเทียบกับสิ่งที่ประกาศไว้ช่วยลดช่องว่างนี้ได้

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

• MDN Web Docs — Using HTTP Cookies
• คู่มือ Cookies & Consent ทั้งหมดของ trusty
• Best Practices การจัดหมวดหมู่คุกกี้สำหรับองค์กรการเงิน