แก้ปัญหาข้อมูลส่วนบุคคลของลูกค้าที่เอเจนซีดูแลเมื่อระบบไม่เป็นไปตามที่ตั้งใจ

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

สถานการณ์แบบนี้เกิดขึ้นได้กับเอเจนซีที่ดูแลลูกค้าหลายรายพร้อมกัน บทความนี้รวบรวมปัญหาที่พบบ่อยในงานเอเจนซีและฟรีแลนซ์ พร้อมวิธีวินิจฉัยและแก้ไขทีละสถานการณ์ ในรูปแบบอาการ-วิธีตรวจสอบ-แนวทางแก้ไข

อาการที่ 1: อดีตซับคอนแทรกเตอร์หรือพนักงานยังเข้าระบบของลูกค้าได้

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

วิธีตรวจสอบ: ดึงรายชื่อผู้ใช้งานทั้งหมดที่มีสิทธิ์เข้าถึง CMS ฐานข้อมูล และบัญชีเครื่องมือของเว็บไซต์นั้น เทียบกับรายชื่อพนักงาน/ซับคอนแทรกเตอร์ที่ยังทำงานอยู่ปัจจุบัน

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

อาการที่ 2: ข้อมูลลูกค้าสองโปรเจกต์ปะปนกันเพราะใช้บัญชีเครื่องมือร่วม

อาการ: เปิดรายงาน Google Analytics หรือ Facebook Ads ของลูกค้ารายหนึ่ง แล้วเห็นข้อมูลของอีกเว็บไซต์หนึ่งปนอยู่ในบัญชีเดียวกัน

วิธีตรวจสอบ: ตรวจสอบว่าบัญชีเครื่องมือ (Analytics, Tag Manager, Ads Manager) นั้นมี Property หรือ Account ของกี่เว็บไซต์อยู่ในบัญชีเดียวกัน

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

อาการที่ 3: ลูกค้าต้องการข้อมูลคืนเมื่อจบสัญญา แต่ทีมหาไม่เจอว่าข้อมูลอยู่ที่ไหนบ้าง

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

วิธีตรวจสอบ: ไล่ตรวจทีละระบบที่เคยเกี่ยวข้องกับโปรเจกต์นี้ ทั้งเซิร์ฟเวอร์ Production, Staging, บัญชีอีเมลทดสอบ, ไดรฟ์ทีม และเครื่องคอมพิวเตอร์ของพนักงานที่เคยดูแลโปรเจกต์

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

อาการที่ 4: ซับคอนแทรกเตอร์คัดลอกฐานข้อมูลลูกค้าไปใช้ในเครื่องตัวเองโดยไม่ได้รับอนุญาต

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

วิธีตรวจสอบ: ตรวจ Log การเข้าถึงฐานข้อมูลว่ามีการดาวน์โหลดหรือ Export ข้อมูลจำนวนมากผิดปกติจากบัญชีของซับคอนแทรกเตอร์รายนั้นหรือไม่

แนวทางแก้ไข: แจ้งลูกค้าเจ้าของข้อมูลทันทีตามข้อเท็จจริงที่ตรวจพบ ขอให้ซับคอนแทรกเตอร์ลบไฟล์ที่คัดลอกไปพร้อมยืนยันเป็นลายลักษณ์อักษร และทบทวนขอบเขตสิทธิ์ที่ให้ซับคอนแทรกเตอร์รายอื่นในทุกโปรเจกต์ปัจจุบัน เพื่อป้องกันไม่ให้เกิดซ้ำกับลูกค้ารายอื่น

อาการที่ 5: อีเมลฟอร์มติดต่อของลูกค้าส่งเข้ากล่องเมลผิดโปรเจกต์

อาการ: พนักงานเอเจนซีเห็นอีเมลจากฟอร์มติดต่อของลูกค้ารายหนึ่งหลุดเข้ามาในกล่องเมลที่ใช้ดูแลลูกค้าอีกรายหนึ่ง

วิธีตรวจสอบ: ตรวจสอบการตั้งค่าปลายทางอีเมลของฟอร์มในแต่ละเว็บไซต์ว่าตั้งค่าถูกต้องตรงกับเจ้าของจริงหรือไม่ อาจเกิดจากการคัดลอกโค้ดฟอร์มจากโปรเจกต์เก่าโดยไม่ได้แก้ที่อยู่อีเมลปลายทาง

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

อาการที่ 6: ไม่มีใครในทีมรู้ว่าโปรเจกต์เก่ามีข้อตกลงเรื่องข้อมูลกับลูกค้าไว้อย่างไร

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

วิธีตรวจสอบ: ค้นหาสัญญาหรือใบเสนองานต้นฉบับของโปรเจกต์นั้น หากหาไม่พบให้ตรวจสอบอีเมลการสื่อสารกับลูกค้าในช่วงเริ่มโปรเจกต์แทน

แนวทางแก้ไข: จัดเก็บสัญญาและเอกสารข้อตกลงของทุกโปรเจกต์ไว้ในที่เดียวที่ทีมทั้งหมดเข้าถึงได้ ไม่ใช่เก็บไว้ในอีเมลส่วนตัวของคนที่เคยดูแลงานนั้น ดูตัวอย่างเอกสารที่ควรจัดเก็บได้ที่ templates-examples

อาการที่ 7: เว็บไซต์หนึ่งบนโฮสติ้งรวมโดนแฮ็ก แล้วกระทบเว็บไซต์ของลูกค้ารายอื่นด้วย

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

วิธีตรวจสอบ: ตรวจสอบว่าเว็บไซต์ทั้งหมดบนเซิร์ฟเวอร์นั้นใช้บัญชีผู้ใช้ระบบปฏิบัติการหรือสิทธิ์ไฟล์ร่วมกันหรือไม่ และตรวจ Log ว่าช่องโหว่ที่ถูกใช้เจาะระบบสามารถมองเห็นไฟล์ของเว็บไซต์อื่นได้จริงหรือเป็นเพียงความเสี่ยงทางทฤษฎี

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

อาการที่ 8: ทีมที่รับช่วงต่อโปรเจกต์ไม่รู้ว่าเคยให้สิทธิ์เครื่องมือภายนอกไว้กับใครบ้าง

อาการ: พนักงานที่รับช่วงดูแลโปรเจกต์ต่อจากคนเดิมพบว่า Google Search Console, บัญชีโฆษณา หรือปลั๊กอินเชื่อมต่อบุคคลที่สามของเว็บไซต์ลูกค้า มีอีเมลของคนนอกทีมปัจจุบันเป็นเจ้าของสิทธิ์อยู่ โดยไม่มีใครทราบว่าเป็นใครหรือยังใช้งานอยู่หรือไม่

วิธีตรวจสอบ: ไล่ตรวจสิทธิ์เจ้าของและผู้ดูแลในทุกเครื่องมือภายนอกที่เชื่อมต่อกับเว็บไซต์นั้น ทั้ง Search Console, บัญชีโฆษณา, ปลั๊กอินฟอร์ม และบริการอีเมลมาร์เก็ตติ้ง แล้วเทียบกับรายชื่อทีมงานปัจจุบัน

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

ลำดับขั้นตอนทั่วไปเมื่อพบปัญหาที่ไม่อยู่ในรายการนี้

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

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

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

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

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

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

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

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

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

สรุป

ปัญหาข้อมูลส่วนบุคคลของลูกค้าที่เอเจนซีดูแลมักเกิดจากสิทธิ์การเข้าถึงที่ไม่ถูกถอดออก บัญชีเครื่องมือที่ใช้ร่วมกันข้ามลูกค้า และการไม่มีระบบติดตามว่าข้อมูลอยู่ที่ไหนบ้าง การวินิจฉัยตามอาการแล้วแก้ไขที่ต้นเหตุพร้อมทบทวนโปรเจกต์อื่นที่มีความเสี่ยงคล้ายกัน ช่วยป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำ ดูแนวทางป้องกันตั้งแต่ต้นได้ที่ best-practices หากต้องการตรวจสอบภาพรวมเว็บไซต์ของลูกค้าก่อนส่งมอบงาน ลองใช้ website-trust-scan ของ trusty

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)