อ่านคำสั่งปรับของ สคส. ให้เป็นหน้าที่สามข้อ และหลักฐานที่ระบบต้องแสดงได้เมื่อถูกถาม

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

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

คำสั่งที่เราอ่านได้ และข้อจำกัดของข้อมูล

แหล่งข่าวที่เปิดอ่านได้เป็นรายงานของสื่อ เราไม่ได้เปิดตัวคำสั่งของ สคส. อ่านเอง

กรณีแรกที่สื่อรายงานเป็นการปรับบริษัทเอกชนรายใหญ่ 7 ล้านบาท ไทยรัฐรายงานเมื่อวันที่ 21 สิงหาคม 2567 ว่า รัฐมนตรีว่าการกระทรวงดิจิทัลฯ รักษาราชการแทน เป็นผู้แถลง ผู้ถูกลงโทษเป็นบริษัทขายสินค้าออนไลน์ที่ไม่ระบุชื่อ ข้อมูลของลูกค้ามากกว่าหนึ่งแสนรายรั่วไหลไปยังแก๊งคอลเซ็นเตอร์ และข่าวระบุว่าเป็นคำสั่งปรับทางปกครองฉบับแรกต่อบริษัทเอกชนขนาดใหญ่ตั้งแต่ PDPA มีผลบังคับ (ดูข่าวของไทยรัฐ) บทความถอดบทเรียนจากคำสั่งเดียวกันของไทยพีบีเอสระบุข้อกล่าวหาสามข้อ (ดูบทความของไทยพีบีเอส)

• ไม่แต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ทั้งที่เข้าข่ายต้องมี ตามมาตรา 41(2)

• ไม่มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ตามมาตรา 37(1)

• แจ้งเหตุละเมิดข้อมูลล่าช้า ตามมาตรา 37(4)

ไทยรัฐรายงานคำสั่งเพิ่มเติมว่า ให้ปรับปรุงมาตรการรักษาความปลอดภัย อบรมพนักงาน ปรับมาตรการให้ทันเทคโนโลยี และแจ้งมาตรการแก้ไขต่อ สคส. ภายใน 7 วันนับจากได้รับคำสั่ง ข่าวไม่ระบุค่าปรับแยกตามข้อกล่าวหา และไม่ระบุวันที่ออกคำสั่ง ระบุเฉพาะวันแถลง

รายงานอีกชิ้นของฐานเศรษฐกิจ ลงวันที่ 1 สิงหาคม 2568 สรุปภาพรวมว่า ปีงบประมาณ 2568 สคส. มีคำสั่งลงโทษปรับทางปกครอง 5 เรื่อง 8 คำสั่ง และนับตั้งแต่บังคับใช้ PDPA มีรวม 6 เรื่อง 9 คำสั่ง มูลค่าปรับรวมเกิน 21.5 ล้านบาท ผู้ถูกลงโทษมีทั้งหน่วยงานรัฐ บริษัทเอกชนที่เป็นผู้ควบคุมและผู้ประมวลผลข้อมูล และบุคคลธรรมดาที่เป็นผู้ประมวลผล (ดูข่าวของฐานเศรษฐกิจ)

ข้อควรระวังเรื่องตัวเลข ยอดรวมที่ข่าวระบุเป็นยอดสะสม เราไม่ได้พบยอดของปีงบประมาณ 2568 ปีเดียวที่แถลงโดยตรง จึงไม่ขอรายงานตัวเลขนั้น และผลการค้นหาของเราพบว่าสื่อบางแห่งพาดหัวยอดเป็น 21 ล้านบาท ซึ่งน่าจะปัดเศษ ถ้าคุณจะนำตัวเลขไปอ้างในเอกสารทางการ ให้ใช้ข้อความจากประกาศของ สคส. โดยตรง

เหตุที่ถูกลงโทษในรายงาน ไม่ใช่เทคนิคการเจาะ

ฐานเศรษฐกิจสรุปเหตุผลของคำสั่งในปีงบประมาณ 2568 ไว้หลายข้อ ซึ่งเราเรียบเรียงใหม่ได้ดังนี้

• มาตรการรักษาความปลอดภัยไม่เพียงพอ เช่น รหัสผ่านอ่อน ไม่มีการประเมินความเสี่ยง และไม่ทบทวนมาตรการเป็นระยะ

• เว็บแอปพลิเคชันของหน่วยงานรัฐถูกเจาะ ทำให้ข้อมูลของประชาชนมากกว่า 200,000 คนรั่ว และถูกนำไปเสนอขายบนดาร์กเว็บ

• หน่วยงานรัฐไม่มีข้อตกลงประมวลผลข้อมูลกับผู้พัฒนาระบบ

• ผู้พัฒนาระบบไม่ได้ฝังมาตรการความปลอดภัยไว้ในการออกแบบ และไม่มีการควบคุมการเข้าถึง

• โรงพยาบาลไม่กำกับดูแลผู้รับจ้างทำลายเอกสาร ทำให้เวชระเบียนรั่ว ผู้รับจ้างเก็บเอกสารไว้ที่บ้านและไม่แจ้งเหตุ

• ไม่แจ้งเหตุละเมิดต่อ สคส. และไม่แต่งตั้ง DPO ทั้งที่ประมวลผลข้อมูลปริมาณมาก

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

จากหน้าที่เป็นหลักฐานที่ระบบต้องแสดงได้

เราแปลหน้าที่ที่ถูกอ้างเป็นหลักฐานที่ทีมไอทีเตรียมได้ แต่ละรายการเป็นของที่ผู้ตรวจสอบหรือฝ่ายกฎหมายอาจขอดู เราไม่ได้อ้างว่า สคส. กำหนดรายการนี้ และรายการนี้ไม่ครบทุกกรณี

มาตรการรักษาความปลอดภัย (มาตรา 37(1)) หลักฐานที่ทีมไอทีเตรียมได้คือ รายงานการประเมินความเสี่ยงที่ลงวันที่ รายชื่อระบบที่เก็บข้อมูลส่วนบุคคลพร้อมเจ้าของ นโยบายรหัสผ่านและการยืนยันตัวตนหลายขั้นที่ตั้งค่าจริง รายการผู้ที่มีสิทธิ์ระดับผู้ดูแลและวันที่ทบทวนล่าสุด และบันทึกการทบทวนมาตรการที่ทำเป็นรอบ ข้อความในรายงานว่ารหัสผ่านอ่อน ไม่ประเมินความเสี่ยง และไม่ทบทวนมาตรการ ตรงกับสามรายการแรกโดยตรง เรื่องการทบทวนสิทธิ์เป็นรอบ เราเขียนไว้ในบทความเรื่องจัดการสิทธิ์เข้าถึงเมื่อทีมพัฒนาเปลี่ยนมือ และเรื่องการลงทุนด้านความปลอดภัยตามลำดับอยู่ในบทความเรื่อง Zero Trust

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

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

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

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

ผู้พัฒนาระบบก็ถูกอ้างถึงในรายงาน

รายการที่เราอยากให้ทีมพัฒนาอ่านเป็นพิเศษคือ ในรายงานของฐานเศรษฐกิจ มีผู้พัฒนาระบบที่ไม่ได้ฝังมาตรการความปลอดภัยในการออกแบบและไม่มีการควบคุมการเข้าถึง เราไม่ทราบรายละเอียดของกรณีนั้น ไม่ทราบว่าผู้พัฒนาถูกลงโทษในฐานะใดหรือเท่าไร และรายงานไม่ระบุ แต่ข้อความนี้ทำให้เราเห็นว่าฝั่งผู้พัฒนาไม่ใช่ผู้ที่อยู่นอกเรื่อง

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

ข้อมูลทดสอบและสำเนาที่ถูกลืม

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

อีกข้อคือ รายการหลักฐานที่เราเสนอไม่ใช่เกณฑ์ที่ สคส. ประกาศ และมีไว้ช่วยทีมไอทีเตรียมตัว ไม่ได้รับรองว่าองค์กรจะผ่านการตรวจสอบ การตัดสินว่าองค์กรของคุณต้องแต่งตั้ง DPO หรือไม่ ต้องแจ้งเหตุใดต่อใคร และมาตรการใดเพียงพอ เป็นเรื่องที่ต้องให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลและที่ปรึกษากฎหมายประเมินจากข้อเท็จจริงของคุณ

ข้อสุดท้าย เรารู้เฉพาะสิ่งที่สื่อรายงาน ไม่ทราบรายละเอียดของกรณีที่ไม่ถูกเปิดเผยชื่อ และจำนวนคำสั่งที่เรารู้อาจเปลี่ยนไปแล้วหลังวันที่รายงานล่าสุดที่เราอ่านคือ 1 สิงหาคม 2568

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

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

2. ทำการประเมินความเสี่ยงหนึ่งฉบับ ลงวันที่ ครอบคลุมระบบในรายชื่อ แม้จะเป็นฉบับสั้น

3. ตรวจว่ามีข้อตกลงกับผู้พัฒนาและผู้ให้บริการทุกรายหรือไม่ ถ้าไม่มี ให้จัดลำดับและเริ่มจากรายที่แตะข้อมูลมากกว่ารายอื่น

4. เขียนขั้นตอนแจ้งเหตุหนึ่งหน้า ระบุผู้ตัดสิน ผู้แจ้ง และช่องทาง แล้วซ้อมด้วยเหตุสมมติหนึ่งครั้ง

5. ให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลและฝ่ายกฎหมายตรวจชุดเอกสาร พร้อมรายการช่องว่าง และกำหนดวันทบทวนซ้ำ

สรุป

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส