ใช้ข้อมูลจริงทดสอบระบบได้ไหม: data masking และข้อมูลทดสอบในยุค PDPA

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

บทความนี้เขียนจากมุมของทีมที่ต้องออกแบบสภาพแวดล้อมทดสอบ ไม่ใช่คำแนะนำทางกฎหมาย เราจะเล่าว่าเราพิจารณาอะไรก่อนยอมให้ข้อมูลจริงออกจาก production ทางเลือกแทนมีอะไรบ้าง และกรณีไหนที่ต้องใช้ข้อมูลจริงจริง ๆ ส่วนคำถามว่าองค์กรของคุณมีหน้าที่อะไรตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ควรให้ DPO หรือที่ปรึกษากฎหมายขององค์กรเป็นผู้ยืนยัน

ข้อมูลจริงหนึ่งชุด กลายเป็นหลายชุดโดยไม่มีใครตั้งใจ

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

จุดที่ความเสี่ยงขยายตัวเมื่อข้อมูลจริงลงไปอยู่ใน dev, staging หรือ UAT มีอยู่ไม่กี่จุด แต่แต่ละจุดเงียบมาก

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

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

• ข้อมูลเดินทางออกนอกระบบ ถ้า test case ถูกเขียนใน spreadsheet พร้อมตัวอย่างข้อมูลจริง ไฟล์เหล่านั้นจะอยู่นอกการควบคุมของฐานข้อมูลทั้งหมด

• สำเนาถูกลืม ฐานข้อมูล UAT อยู่ต่อหลังโครงการจบ และอาจมี backup ของตัวเองซ้อนอีกชั้น

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

มาตรา 37 (1) ของ PDPA กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลมีหน้าที่ “จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลส่วนบุคคลโดยปราศจากอำนาจหรือโดยมิชอบ” ในมาตรานี้ไม่มีข้อความแยกว่าข้อมูลอยู่ในระบบจริงหรือระบบทดสอบ เราจึงออกแบบโดยถือว่าสำเนาในระบบทดสอบต้องได้รับการป้องกันไม่ต่ำกว่าต้นฉบับ (พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 บนเว็บไซต์ สคส.)

อีกจุดหนึ่งมาจากประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์ในการลบหรือทำลาย หรือทำให้ข้อมูลส่วนบุคคลเป็นข้อมูลที่ไม่สามารถระบุตัวบุคคลที่เป็นเจ้าของข้อมูลส่วนบุคคลได้ พ.ศ. 2567 ข้อ 3 วรรคสอง ซึ่งเขียนไว้ว่าการดำเนินการตามคำขอลบ “จะต้องดำเนินการให้ครอบคลุมถึงข้อมูลส่วนบุคคลที่ทำสำเนาหรือสำรองไว้ด้วย (ถ้ามี)” (ประกาศฉบับนี้บนเว็บไซต์ สคส.) ในมุมของเรา สำเนาใน UAT ก็คือสำเนา ถ้าองค์กรไม่รู้ว่าสำเนาอยู่ที่ไหนบ้าง ก็ไม่มีทางตอบคำขอลบได้ครบ

ทางเลือกแทนการ copy ข้อมูลจริงทั้งก้อน

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

Masking และ tokenization

Masking คือการแทนค่าจริงด้วยค่าที่ไม่บอกตัวตน เช่น ปิดตัวอักษรบางส่วน หรือแทนทั้งค่าด้วย token เอกสาร Sensitive Data Protection ของ Google Cloud อธิบายว่า pseudonymization เป็นเทคนิค de-identification ที่แทนค่าข้อมูลอ่อนไหวด้วย token ที่สร้างด้วยวิธีเข้ารหัส และแบ่ง token เป็นสองแบบ แบบทางเดียวย้อนกลับไม่ได้ ส่วนแบบสองทางย้อนกลับได้ เพราะ key ตัวเดียวกับที่ใช้สร้าง token ก็ใช้ย้อน token ได้ด้วย (Google Cloud: Pseudonymization)

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

Dynamic masking ไม่ใช่สำเนาที่ mask แล้ว

ฐานข้อมูลบางตัวมีฟีเจอร์ซ่อนค่าตอนแสดงผล เอกสารของ Microsoft อธิบาย Dynamic Data Masking บน Azure SQL ว่าเป็นฟีเจอร์ที่ซ่อนข้อมูลอ่อนไหวในผลลัพธ์ของ query โดยข้อมูลในฐานข้อมูลไม่ได้ถูกเปลี่ยน และผู้ที่มีสิทธิ์ผู้ดูแล เช่น server admin, Microsoft Entra admin และ db_owner ยังเห็นข้อมูลต้นฉบับโดยไม่มี mask (Microsoft Learn: Dynamic Data Masking)

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

Synthetic data

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

Subset ที่เล็กที่สุดที่งานต้องใช้

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

Pseudonymized ยังไม่ใช่ anonymized

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

คำว่าทางอ้อมคือจุดที่ต้องระวัง

ประกาศฉบับปี 2567 ที่กล่าวถึงข้างต้น ข้อ 6 วางหลักการทำให้ข้อมูลเป็นข้อมูลนิรนาม (anonymization) ไว้สองขั้น ขั้นแรกต้องลบหรือทำให้ปราศจากตัวระบุทางตรง (direct identifiers) เช่น ชื่อ เลขประจำตัวประชาชน หมายเลขโทรศัพท์ และอีเมล ขั้นที่สองต้องพิจารณาเพิ่มเติมเพื่อให้โอกาสระบุตัวบุคคลได้ทางอ้อมอยู่ “ในระดับที่ต่ำเพียงพอ” โดยประกาศเขียนว่าอาจ “พิจารณาทำการแฝงข้อมูล (pseudonymization) หรือดำเนินการอย่างหนึ่งอย่างใดต่อข้อมูลทั้งหมดหรือบางส่วน” เพื่อลดโอกาสระบุตัวจากตัวระบุทางอ้อม (indirect identifiers) ซึ่งประกาศยกตัวอย่างไว้ เช่น วันเดือนปีเกิด อายุ ตำแหน่งงาน และ IP address

ต้องบอกให้ชัดว่าประกาศฉบับนี้เขียนขึ้นสำหรับการลบหรือทำให้ไม่สามารถระบุตัวบุคคลได้ตามคำขอในมาตรา 33 และระบบตรวจสอบตามมาตรา 37 (3) ไม่ได้เขียนเรื่องข้อมูลทดสอบโดยตรง เราใช้หลักสองขั้นนี้เป็นเกณฑ์อ้างอิงในการออกแบบ ไม่ได้อ้างว่าเป็นข้อกำหนดของงานทดสอบ

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

ใครควรเข้าถึงสภาพแวดล้อมทดสอบ และต้องตกลงอะไรกับทีมพัฒนาภายนอก

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

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

สิ่งที่เราแนะนำให้เขียนไว้ในTORหรือสัญญากับทีมพัฒนาภายนอก ไม่ว่าผลประเมินบทบาทจะออกมาอย่างไร

• สภาพแวดล้อมแต่ละชุดใช้ข้อมูลประเภทไหนได้ เช่น dev ใช้ synthetic data เท่านั้น UAT ใช้ subset ที่ mask แล้ว

• ข้อมูลทดสอบอยู่ในบัญชีคลาวด์ขององค์กร ไม่ใช่บัญชีของผู้พัฒนา และห้าม export ลงเครื่องส่วนตัว

• ขั้นตอน masking เป็นส่วนหนึ่งของงานส่งมอบ มีเอกสาร และรันซ้ำได้โดยทีมภายใน

• กำหนดวันลบข้อมูลทดสอบเมื่อจบแต่ละเฟส พร้อมหลักฐานว่าลบแล้ว

• ระยะเวลาและช่องทางแจ้งเหตุ ถ้าพบว่าข้อมูลรั่วหรือถูกเข้าถึงผิดปกติ

เมื่อไหร่ที่ต้องใช้ข้อมูลจริง และจะล้อมรั้วอย่างไร

บางงานใช้ข้อมูลแทนไม่ได้จริง ตัวอย่างที่ชัดคือการซ้อมย้ายข้อมูลก่อน cutover ซึ่งต้องพิสูจน์ว่าข้อมูลจริงทุกแถวย้ายได้ครบและถูก เราเขียนเรื่องการตรวจข้อมูลและ cutover ไว้แยกในบทความเรื่อง validate และ cutover อีกกรณีคือ bug ที่เกิดเฉพาะกับข้อมูลบางแถวใน production และสร้างซ้ำด้วยข้อมูลอื่นไม่ได้

เมื่อต้องใช้ข้อมูลจริง เราไม่ลดมาตรฐานของข้อมูลลงมาเท่าสภาพแวดล้อมทดสอบ แต่ยกสภาพแวดล้อมนั้นขึ้นไปเท่า production

• แยก project หรือ subscription บนคลาวด์ออกมาเฉพาะงานนี้ ไม่ปนกับ dev ทั่วไป

• ผู้เข้าถึงมีรายชื่อระบุตัว อนุมัติเป็นลายลักษณ์อักษร และมี log การเข้าถึงทุกครั้ง

• กำหนดวันลบไว้ตั้งแต่วันสร้าง และบันทึกว่าลบเมื่อไร ใครเป็นผู้ยืนยัน

• ปิดช่องทาง export และไม่เปิด debug log ที่พิมพ์ค่าข้อมูลออกมา

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

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

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

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

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

1. สำรวจว่าตอนนี้มีสำเนาข้อมูล production อยู่ที่ไหนบ้าง ทั้ง dev, staging, UAT, ไฟล์ export และ backup ของสภาพแวดล้อมเหล่านั้น พร้อมระบุว่าใครเป็นเจ้าของแต่ละชุด

2. จัดประเภทคอลัมน์ แยกตัวระบุทางตรงออกจากตัวระบุทางอ้อม โดยใช้ตัวอย่างในประกาศปี 2567 เป็นจุดตั้งต้น แล้วเพิ่มคอลัมน์เฉพาะของระบบคุณ

3. ตัดสินใจรายสภาพแวดล้อม ว่าแต่ละชุดใช้ synthetic data, subset ที่ mask แล้ว หรือสำเนาจริงที่ล้อมรั้ว

4. เขียนกติกาลงเอกสารจัดจ้าง ก่อนเริ่มโครงการถัดไป ไม่ใช่ตอนใกล้ UAT

5. นัดวันลบ สำหรับสำเนาจริงทุกชุดที่เหลืออยู่ และให้มีคนยืนยันว่าลบแล้ว

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

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