[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-test-data-masking-pdpa-th":3,"blog-post-test-data-masking-pdpa-th":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"การเข้ารหัสปกป้องข้อมูลระหว่างจัดเก็บหรือส่งต่อ แต่ผู้ที่ถอดรหัสได้จะเห็นค่าจริงทั้งหมด ส่วน masking เปลี่ยนค่าที่ผู้ใช้หรือระบบทดสอบได้รับไปเลย ในงานทดสอบ เป้าหมายคือให้ทีมทำงานได้โดยไม่ต้องเห็นค่าจริง masking จึงตรงกับโจทย์กว่า การเข้ารหัสยังจำเป็นในฐานะมาตรการพื้นฐานของทุกสภาพแวดล้อม","6inzfq5ebw92fvn","data masking กับการเข้ารหัส (encryption) ต่างกันอย่างไร",{"answer":9,"id":10,"question":11},"pseudonymization แทนตัวระบุด้วยรหัสหรือ token ซึ่งย้อนกลับได้ถ้ามี key หรือตารางจับคู่ ส่วน anonymization มุ่งให้ระบุตัวบุคคลไม่ได้อีกทั้งทางตรงและทางอ้อม ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเรื่องหลักเกณฑ์การลบ ทำลาย หรือทำให้ไม่สามารถระบุตัวบุคคลได้ พ.ศ. 2567 กล่าวถึงการแฝงข้อมูล (pseudonymization) ว่าเป็นวิธีหนึ่งที่อาจใช้เพื่อลดโอกาสการระบุตัวทางอ้อม เราถือว่าข้อมูลที่ยังย้อนกลับได้คือข้อมูลส่วนบุคคล และให้ DPO เป็นผู้ยืนยันการจัดประเภท","6ci7hmuzgit86an","pseudonymization กับ anonymization ต่างกันอย่างไร",{"answer":13,"id":14,"question":15},"เราไม่แนะนำ เอกสารของ Microsoft ระบุว่า Dynamic Data Masking บน Azure SQL ซ่อนข้อมูลในผลลัพธ์ของ query โดยข้อมูลในฐานข้อมูลไม่ได้ถูกเปลี่ยน และผู้ดูแลอย่าง db_owner ยังเห็นค่าต้นฉบับ ฟีเจอร์นี้เหมาะกับการจำกัดสิ่งที่ผู้ใช้แต่ละกลุ่มเห็นมากกว่า","h2w2nhrkem4lk2f","เปิด Dynamic Data Masking บนฐานข้อมูลแล้ว ใช้แทนข้อมูลทดสอบที่ mask แล้วได้ไหม",{"answer":17,"id":18,"question":19},"เหมาะกับ dev การทดสอบฟังก์ชัน การฝึกอบรมผู้ใช้ และสภาพแวดล้อมที่ทีมภายนอกเข้าถึง เพราะไม่ได้มาจากบุคคลจริง ข้อจำกัดคือจับปัญหาที่เกิดจากการกระจายตัวของข้อมูลจริง หรือค่าเก่าจากระบบเดิมได้ไม่ดี งานแบบนั้นต้องใช้ subset ที่ mask แล้ว หรือสำเนาจริงที่ล้อมรั้วไว้","9sm0ypyhx4m84bs","synthetic data เหมาะกับการทดสอบแบบไหน",{"answer":21,"id":22,"question":23},"ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเรื่องหลักเกณฑ์การลบหรือทำลาย พ.ศ. 2567 ข้อ 3 วรรคสอง เขียนว่าการดำเนินการตามคำขอ “จะต้องดำเนินการให้ครอบคลุมถึงข้อมูลส่วนบุคคลที่ทำสำเนาหรือสำรองไว้ด้วย (ถ้ามี)” เรามองว่าสำเนาใน UAT หรือ staging ก็เป็นสำเนาชุดหนึ่ง องค์กรจึงควรรู้ว่าสำเนาอยู่ที่ไหนบ้าง การตีความสำหรับกรณีของคุณควรให้ DPO เป็นผู้ยืนยัน","i013hspqxyozifg","ถ้าเจ้าของข้อมูลขอให้ลบข้อมูล ต้องลบในระบบทดสอบด้วยไหม",{"answer":25,"id":26,"question":27},"สิ่งที่เราแนะนำให้ระบุ ได้แก่ สภาพแวดล้อมแต่ละชุดใช้ข้อมูลประเภทไหนได้ ข้อมูลทดสอบต้องอยู่ในบัญชีคลาวด์ขององค์กร ขั้นตอน masking เป็นงานส่งมอบที่ทีมภายในรันซ้ำได้ วันลบข้อมูลพร้อมหลักฐาน และช่องทางแจ้งเหตุ ถ้าทีมภายนอกเป็นผู้ประมวลผลข้อมูลส่วนบุคคลในงานนั้น มาตรา 40 ของ PDPA กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องจัดให้มีข้อตกลงระหว่างกันด้วย","0nbn3susjyzdemd","ควรกำหนดเรื่องข้อมูลทดสอบอะไรไว้ในสัญญากับทีมพัฒนาภายนอก",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"hpatqzwekkvvw7h","h40z6ffyizu3a1e","ใช้ข้อมูลจริงทดสอบระบบได้ไหม: data masking และข้อมูลทดสอบในยุค PDPA","ก่อน copy ฐานข้อมูล production ลง dev หรือ UAT ควรรู้ว่าความเสี่ยงขยายตรงไหน และทางเลือกอย่าง masking, synthetic data หรือ subset เหมาะกับงานแบบไหน","\u003Cp>ก่อนเริ่ม UAT ของระบบใหม่ มีคำขอหนึ่งที่ฟังสมเหตุสมผลเสมอ คือขอ copy ฐานข้อมูล production ลงมาไว้ในสภาพแวดล้อมทดสอบ เพราะข้อมูลจริงมีกรณีแปลก ๆ ที่ข้อมูลตัวอย่างไม่มี เหตุผลนี้ไม่ผิด แต่ทันทีที่คุณอนุมัติ ข้อมูลส่วนบุคคลชุดเดียวกันจะมีอยู่อย่างน้อยสองที่ และที่ที่สองไม่ได้ผ่านการตรวจแบบเดียวกับที่แรก\u003C\u002Fp>\u003Cp>บทความนี้เขียนจากมุมของทีมที่ต้องออกแบบสภาพแวดล้อมทดสอบ ไม่ใช่คำแนะนำทางกฎหมาย เราจะเล่าว่าเราพิจารณาอะไรก่อนยอมให้ข้อมูลจริงออกจาก production ทางเลือกแทนมีอะไรบ้าง และกรณีไหนที่ต้องใช้ข้อมูลจริงจริง ๆ ส่วนคำถามว่าองค์กรของคุณมีหน้าที่อะไรตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ควรให้ DPO หรือที่ปรึกษากฎหมายขององค์กรเป็นผู้ยืนยัน\u003C\u002Fp>\u003Ch2>ข้อมูลจริงหนึ่งชุด กลายเป็นหลายชุดโดยไม่มีใครตั้งใจ\u003C\u002Fh2>\u003Cp>ระบบ production ที่ผ่านการตรวจความปลอดภัยมาแล้ว มีสิทธิ์เข้าถึงที่จำกัดตามหน้าที่ และมี log บอกว่าใครเข้าไปทำอะไร สภาพแวดล้อมทดสอบถูกสร้างมาเพื่อให้ทีมทำงานได้เร็ว จึงมีแรงดึงไปทางตรงข้าม เช่น บัญชีอาจถูกใช้ร่วมกัน และคนที่มาช่วยทดสอบอาจได้สิทธิ์เข้าไปดูข้อมูลทั้งหมด\u003C\u002Fp>\u003Cp>จุดที่ความเสี่ยงขยายตัวเมื่อข้อมูลจริงลงไปอยู่ใน dev, staging หรือ UAT มีอยู่ไม่กี่จุด แต่แต่ละจุดเงียบมาก\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>คนเข้าถึงมากขึ้น\u003C\u002Fstrong> นักพัฒนา ผู้ทดสอบ ผู้ใช้ฝั่งธุรกิจที่มาช่วยทำ UAT และทีมพัฒนาภายนอก ล้วนเห็นข้อมูลชุดเดียวกับที่ production ปกป้องไว้\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>การควบคุมหลวมกว่า\u003C\u002Fstrong> error message และ log ในโหมดทดสอบอาจพิมพ์ค่าจริงออกมา แล้วถูกส่งต่อไปยังระบบเก็บ log ที่มีคนเข้าถึงกว้างกว่าเดิม\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>ข้อมูลเดินทางออกนอกระบบ\u003C\u002Fstrong> ถ้า test case ถูกเขียนใน spreadsheet พร้อมตัวอย่างข้อมูลจริง ไฟล์เหล่านั้นจะอยู่นอกการควบคุมของฐานข้อมูลทั้งหมด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>สำเนาถูกลืม\u003C\u002Fstrong> ฐานข้อมูล UAT อยู่ต่อหลังโครงการจบ และอาจมี backup ของตัวเองซ้อนอีกชั้น\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>สมมติว่าองค์กรหนึ่ง copy ฐานข้อมูลสมาชิกลง UAT ตอนพัฒนาระบบเมื่อสองปีก่อน วันนี้มีสมาชิกคนหนึ่งขอให้ลบข้อมูลของตน ทีม production ลบในระบบจริงเรียบร้อย แต่ไม่มีใครนึกถึงฐานข้อมูล UAT ที่ยังเปิดอยู่ กรณีสมมตินี้ไม่ต้องมีใครทำผิดเลยสักคน มันเกิดจากการที่สำเนาไม่มีเจ้าของ\u003C\u002Fp>\u003Cp>มาตรา 37 (1) ของ PDPA กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลมีหน้าที่ “จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลส่วนบุคคลโดยปราศจากอำนาจหรือโดยมิชอบ” ในมาตรานี้ไม่มีข้อความแยกว่าข้อมูลอยู่ในระบบจริงหรือระบบทดสอบ เราจึงออกแบบโดยถือว่าสำเนาในระบบทดสอบต้องได้รับการป้องกันไม่ต่ำกว่าต้นฉบับ (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.pdpc.or.th\u002F1540\u002F\">พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 บนเว็บไซต์ สคส.\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>อีกจุดหนึ่งมาจากประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์ในการลบหรือทำลาย หรือทำให้ข้อมูลส่วนบุคคลเป็นข้อมูลที่ไม่สามารถระบุตัวบุคคลที่เป็นเจ้าของข้อมูลส่วนบุคคลได้ พ.ศ. 2567 ข้อ 3 วรรคสอง ซึ่งเขียนไว้ว่าการดำเนินการตามคำขอลบ “จะต้องดำเนินการให้ครอบคลุมถึงข้อมูลส่วนบุคคลที่ทำสำเนาหรือสำรองไว้ด้วย (ถ้ามี)” (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.pdpc.or.th\u002F7020\u002F\">ประกาศฉบับนี้บนเว็บไซต์ สคส.\u003C\u002Fa>) ในมุมของเรา สำเนาใน UAT ก็คือสำเนา ถ้าองค์กรไม่รู้ว่าสำเนาอยู่ที่ไหนบ้าง ก็ไม่มีทางตอบคำขอลบได้ครบ\u003C\u002Fp>\u003Ch2>ทางเลือกแทนการ copy ข้อมูลจริงทั้งก้อน\u003C\u002Fh2>\u003Cp>ทางเลือกมีหลายระดับ และไม่จำเป็นต้องเลือกแบบเดียวทั้งระบบ แต่ละสภาพแวดล้อมใช้คนละแบบได้ตามงานที่เกิดขึ้นในนั้น\u003C\u002Fp>\u003Ch3>Masking และ tokenization\u003C\u002Fh3>\u003Cp>Masking คือการแทนค่าจริงด้วยค่าที่ไม่บอกตัวตน เช่น ปิดตัวอักษรบางส่วน หรือแทนทั้งค่าด้วย token เอกสาร Sensitive Data Protection ของ Google Cloud อธิบายว่า pseudonymization เป็นเทคนิค de-identification ที่แทนค่าข้อมูลอ่อนไหวด้วย token ที่สร้างด้วยวิธีเข้ารหัส และแบ่ง token เป็นสองแบบ แบบทางเดียวย้อนกลับไม่ได้ ส่วนแบบสองทางย้อนกลับได้ เพราะ key ตัวเดียวกับที่ใช้สร้าง token ก็ใช้ย้อน token ได้ด้วย (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdocs.cloud.google.com\u002Fsensitive-data-protection\u002Fdocs\u002Fpseudonymization\">Google Cloud: Pseudonymization\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>เอกสารเดียวกันระบุด้วยว่า เมื่อใช้ key เดียวกัน ค่าเดิมจะถูกแปลงเป็นค่าเดิมเสมอ และในข้อมูลที่มีรูปแบบซ้ำ ความเสี่ยงที่จะถูกระบุตัวกลับจะเพิ่มขึ้น สองข้อนี้ทำให้เราตั้งกติกาไว้ว่า key สำหรับ token แบบสองทางต้องไม่อยู่ในสภาพแวดล้อมทดสอบ และต้องไม่อยู่ในมือทีมที่ใช้ข้อมูลทดสอบ ถ้า key อยู่ข้างข้อมูล การทำ token ก็แทบไม่ได้ลดอะไร\u003C\u002Fp>\u003Ch3>Dynamic masking ไม่ใช่สำเนาที่ mask แล้ว\u003C\u002Fh3>\u003Cp>ฐานข้อมูลบางตัวมีฟีเจอร์ซ่อนค่าตอนแสดงผล เอกสารของ Microsoft อธิบาย Dynamic Data Masking บน Azure SQL ว่าเป็นฟีเจอร์ที่ซ่อนข้อมูลอ่อนไหวในผลลัพธ์ของ query โดยข้อมูลในฐานข้อมูลไม่ได้ถูกเปลี่ยน และผู้ที่มีสิทธิ์ผู้ดูแล เช่น server admin, Microsoft Entra admin และ db_owner ยังเห็นข้อมูลต้นฉบับโดยไม่มี mask (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fazure-sql\u002Fdatabase\u002Fdynamic-data-masking-overview\">Microsoft Learn: Dynamic Data Masking\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>ฟีเจอร์แบบนี้มีประโยชน์กับการจำกัดสิ่งที่ผู้ใช้แต่ละกลุ่มเห็น แต่เราไม่นับมันเป็นข้อมูลทดสอบ เพราะค่าจริงยังอยู่ครบในฐานข้อมูล\u003C\u002Fp>\u003Ch3>Synthetic data\u003C\u002Fh3>\u003Cp>Synthetic data คือข้อมูลที่สร้างขึ้นใหม่ให้ตรงกับ schema และกฎทางธุรกิจ โดยไม่ได้มาจากบุคคลจริง เราใช้แบบนี้เป็นค่าตั้งต้นของ dev และสภาพแวดล้อมที่ทีมภายนอกเข้าถึง เพราะหลุดออกไปก็ไม่มีใครเสียหาย ต้นทุนอยู่ที่การสร้างให้สมจริงพอ เช่น ชื่อภาษาไทยที่มีความยาวหลายแบบ หรือเลขประจำตัวที่ต้องผ่านการตรวจความถูกต้องของระบบ\u003C\u002Fp>\u003Ch3>Subset ที่เล็กที่สุดที่งานต้องใช้\u003C\u002Fh3>\u003Cp>บางงานต้องการรูปแบบข้อมูลที่ใกล้ของจริงมาก การดึงเฉพาะบางแถวและบางคอลัมน์ที่งานนั้นต้องใช้ แล้ว mask คอลัมน์ที่ระบุตัวบุคคลได้ ช่วยลดขนาดความเสียหายถ้ามีอะไรผิดพลาด คำถามที่เราใช้ตัดสินคือ งานทดสอบนี้ต้องใช้คอลัมน์ไหนจริง ๆ ไม่ใช่ว่าตารางนั้นมีคอลัมน์อะไรบ้าง\u003C\u002Fp>\u003Ch2>Pseudonymized ยังไม่ใช่ anonymized\u003C\u002Fh2>\u003Cp>ความเข้าใจผิดที่เราอยากให้ระวังเป็นพิเศษ คือการคิดว่าข้อมูลที่เปลี่ยนชื่อเป็นรหัสแล้วพ้นจากความเป็นข้อมูลส่วนบุคคล มาตรา 6 ของ PDPA นิยาม “ข้อมูลส่วนบุคคล” ว่า “ข้อมูลเกี่ยวกับบุคคลซึ่งทำให้สามารถระบุตัวบุคคลนั้นได้ ไม่ว่าทางตรงหรือทางอ้อม แต่ไม่รวมถึงข้อมูลของผู้ถึงแก่กรรมโดยเฉพาะ”\u003C\u002Fp>\u003Cp>คำว่าทางอ้อมคือจุดที่ต้องระวัง\u003C\u002Fp>\u003Cp>ประกาศฉบับปี 2567 ที่กล่าวถึงข้างต้น ข้อ 6 วางหลักการทำให้ข้อมูลเป็นข้อมูลนิรนาม (anonymization) ไว้สองขั้น ขั้นแรกต้องลบหรือทำให้ปราศจากตัวระบุทางตรง (direct identifiers) เช่น ชื่อ เลขประจำตัวประชาชน หมายเลขโทรศัพท์ และอีเมล ขั้นที่สองต้องพิจารณาเพิ่มเติมเพื่อให้โอกาสระบุตัวบุคคลได้ทางอ้อมอยู่ “ในระดับที่ต่ำเพียงพอ” โดยประกาศเขียนว่าอาจ “พิจารณาทำการแฝงข้อมูล (pseudonymization) หรือดำเนินการอย่างหนึ่งอย่างใดต่อข้อมูลทั้งหมดหรือบางส่วน” เพื่อลดโอกาสระบุตัวจากตัวระบุทางอ้อม (indirect identifiers) ซึ่งประกาศยกตัวอย่างไว้ เช่น วันเดือนปีเกิด อายุ ตำแหน่งงาน และ IP address\u003C\u002Fp>\u003Cp>ต้องบอกให้ชัดว่าประกาศฉบับนี้เขียนขึ้นสำหรับการลบหรือทำให้ไม่สามารถระบุตัวบุคคลได้ตามคำขอในมาตรา 33 และระบบตรวจสอบตามมาตรา 37 (3) ไม่ได้เขียนเรื่องข้อมูลทดสอบโดยตรง เราใช้หลักสองขั้นนี้เป็นเกณฑ์อ้างอิงในการออกแบบ ไม่ได้อ้างว่าเป็นข้อกำหนดของงานทดสอบ\u003C\u002Fp>\u003Cp>ข้อสรุปที่เราใช้ในงานจริงคือ ถ้าองค์กรยังถือตารางจับคู่หรือ key ที่ย้อนรหัสกลับเป็นตัวบุคคลได้ เราถือว่าข้อมูลชุดนั้นยังระบุตัวบุคคลได้ทางอ้อม และดูแลมันเหมือนข้อมูลส่วนบุคคลทุกอย่าง การจัดประเภทสุดท้ายของข้อมูลแต่ละชุดเป็นเรื่องที่ DPO ขององค์กรควรเป็นผู้ยืนยัน\u003C\u002Fp>\u003Ch2>ใครควรเข้าถึงสภาพแวดล้อมทดสอบ และต้องตกลงอะไรกับทีมพัฒนาภายนอก\u003C\u002Fh2>\u003Cp>หลักที่เราใช้คือหลักเดียวกับตอน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fai-agent-readiness-before-system-access\">ให้ AI Agent เข้าถึงระบบจริง\u003C\u002Fa> ให้สิทธิ์เท่าที่งานต้องใช้ และให้สิทธิ์นั้นหมดอายุเมื่องานจบ สำหรับสภาพแวดล้อมทดสอบ แปลว่ารายชื่อผู้เข้าถึงต้องเป็นรายบุคคล ไม่ใช่บัญชีกลางของทีม และสภาพแวดล้อมที่มีข้อมูลจริงหรือข้อมูลที่ย้อนกลับได้ ต้องมี log ว่าใครเข้าไปเมื่อไร\u003C\u002Fp>\u003Cp>เมื่อมีทีมพัฒนาภายนอกเข้ามา คำถามเรื่องบทบาทตามกฎหมายเกิดขึ้นทันที มาตรา 40 ของ PDPA กำหนดหน้าที่ของผู้ประมวลผลข้อมูลส่วนบุคคลไว้ ซึ่งรวมถึงการดำเนินการกับข้อมูล “ตามคำสั่งที่ได้รับจากผู้ควบคุมข้อมูลส่วนบุคคลเท่านั้น” เว้นแต่คำสั่งนั้นขัดต่อกฎหมายหรือบทบัญญัติในการคุ้มครองข้อมูลส่วนบุคคลของพระราชบัญญัตินี้ และการจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยพร้อมแจ้งผู้ควบคุมเมื่อเกิดเหตุละเมิด มาตราเดียวกันยังกำหนดว่า “ผู้ควบคุมข้อมูลส่วนบุคคลต้องจัดให้มีข้อตกลงระหว่างกัน” เพื่อควบคุมการทำงานของผู้ประมวลผล ทีมภายนอกของคุณอยู่ในบทบาทนี้หรือไม่ในงานแต่ละงาน เป็นเรื่องที่ DPO ต้องประเมิน\u003C\u002Fp>\u003Cp>สิ่งที่เราแนะนำให้เขียนไว้ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\">TOR\u003C\u002Fa>หรือสัญญากับทีมพัฒนาภายนอก ไม่ว่าผลประเมินบทบาทจะออกมาอย่างไร\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>สภาพแวดล้อมแต่ละชุดใช้ข้อมูลประเภทไหนได้ เช่น dev ใช้ synthetic data เท่านั้น UAT ใช้ subset ที่ mask แล้ว\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ข้อมูลทดสอบอยู่ในบัญชีคลาวด์ขององค์กร ไม่ใช่บัญชีของผู้พัฒนา และห้าม export ลงเครื่องส่วนตัว\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ขั้นตอน masking เป็นส่วนหนึ่งของงานส่งมอบ มีเอกสาร และรันซ้ำได้โดยทีมภายใน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>กำหนดวันลบข้อมูลทดสอบเมื่อจบแต่ละเฟส พร้อมหลักฐานว่าลบแล้ว\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ระยะเวลาและช่องทางแจ้งเหตุ ถ้าพบว่าข้อมูลรั่วหรือถูกเข้าถึงผิดปกติ\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>เมื่อไหร่ที่ต้องใช้ข้อมูลจริง และจะล้อมรั้วอย่างไร\u003C\u002Fh2>\u003Cp>บางงานใช้ข้อมูลแทนไม่ได้จริง ตัวอย่างที่ชัดคือการซ้อมย้ายข้อมูลก่อน cutover ซึ่งต้องพิสูจน์ว่าข้อมูลจริงทุกแถวย้ายได้ครบและถูก เราเขียนเรื่องการตรวจข้อมูลและ cutover ไว้แยกใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fdata-migration-validate-cutover\">บทความเรื่อง validate และ cutover\u003C\u002Fa> อีกกรณีคือ bug ที่เกิดเฉพาะกับข้อมูลบางแถวใน production และสร้างซ้ำด้วยข้อมูลอื่นไม่ได้\u003C\u002Fp>\u003Cp>เมื่อต้องใช้ข้อมูลจริง เราไม่ลดมาตรฐานของข้อมูลลงมาเท่าสภาพแวดล้อมทดสอบ แต่ยกสภาพแวดล้อมนั้นขึ้นไปเท่า production\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>แยก project หรือ subscription บนคลาวด์ออกมาเฉพาะงานนี้ ไม่ปนกับ dev ทั่วไป\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ผู้เข้าถึงมีรายชื่อระบุตัว อนุมัติเป็นลายลักษณ์อักษร และมี log การเข้าถึงทุกครั้ง\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>กำหนดวันลบไว้ตั้งแต่วันสร้าง และบันทึกว่าลบเมื่อไร ใครเป็นผู้ยืนยัน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ปิดช่องทาง export และไม่เปิด debug log ที่พิมพ์ค่าข้อมูลออกมา\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ข้อเสียที่ต้องพูดให้ชัดคือ ข้อมูลที่ mask หรือสร้างขึ้นเองจับ bug บางประเภทไม่ได้ เช่น ปัญหาที่เกิดจากการกระจายตัวของข้อมูลจริง หรือค่าเก่าที่ระบบเดิมยอมรับแต่ระบบใหม่ไม่ยอมรับ และขั้นตอน masking เองก็เป็นงานที่ต้องดูแลทุกครั้งที่ schema เปลี่ยน ถ้าระบบของคุณเป็นระบบภายในขนาดเล็ก ข้อมูลส่วนบุคคลมีไม่กี่คอลัมน์ และทีมที่เกี่ยวข้องเป็นพนักงานขององค์กรทั้งหมด การสร้าง pipeline masking เต็มรูปแบบอาจไม่คุ้ม ทางที่ง่ายกว่าในกรณีนั้นคือใช้สำเนาที่ล้อมรั้วตามรายการข้างบน แล้วลบตามกำหนดจริง\u003C\u002Fp>\u003Ch2>ข้อโต้แย้งที่ได้ยินบ่อย\u003C\u002Fh2>\u003Cp>ข้อโต้แย้งแรกคือ ระบบทดสอบอยู่ในเครือข่ายภายใน คนนอกเข้าไม่ได้ จึงไม่ต้องลงแรงขนาดนี้ เครือข่ายภายในตอบคำถามว่าคนนอกเข้ามาได้หรือไม่ แต่ความเสี่ยงของข้อมูลทดสอบอยู่ที่คนที่เข้าได้อยู่แล้ว ซึ่งรวมถึงทีมภายนอกที่ได้ VPN และถ้าวันหนึ่งมีคำขอลบข้อมูล สำเนาที่อยู่ในเครือข่ายภายในก็ยังต้องถูกลบเหมือนเดิม\u003C\u002Fp>\u003Cp>ข้อโต้แย้งที่สองคือ ทีมพัฒนาเซ็น NDA แล้ว เราเห็นว่า NDA เป็นสิ่งที่ควรมี แต่ NDA ทำงานหลังเกิดเหตุ มันไม่ได้ลดจำนวนสำเนาหรือจำนวนคนที่เห็นข้อมูลลงเลย การให้ทีมภายนอกทำงานกับข้อมูลที่หลุดแล้วไม่มีใครเสียหาย ปกป้องทั้งองค์กรและตัวผู้พัฒนาเอง\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>จะเริ่มตรงไหน\u003C\u002Fh2>\u003Col>\u003Cli>\u003Cp>\u003Cstrong>สำรวจว่าตอนนี้มีสำเนาข้อมูล production อยู่ที่ไหนบ้าง\u003C\u002Fstrong> ทั้ง dev, staging, UAT, ไฟล์ export และ backup ของสภาพแวดล้อมเหล่านั้น พร้อมระบุว่าใครเป็นเจ้าของแต่ละชุด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>จัดประเภทคอลัมน์\u003C\u002Fstrong> แยกตัวระบุทางตรงออกจากตัวระบุทางอ้อม โดยใช้ตัวอย่างในประกาศปี 2567 เป็นจุดตั้งต้น แล้วเพิ่มคอลัมน์เฉพาะของระบบคุณ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>ตัดสินใจรายสภาพแวดล้อม\u003C\u002Fstrong> ว่าแต่ละชุดใช้ synthetic data, subset ที่ mask แล้ว หรือสำเนาจริงที่ล้อมรั้ว\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>เขียนกติกาลงเอกสารจัดจ้าง\u003C\u002Fstrong> ก่อนเริ่มโครงการถัดไป ไม่ใช่ตอนใกล้ UAT\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>นัดวันลบ\u003C\u002Fstrong> สำหรับสำเนาจริงทุกชุดที่เหลืออยู่ และให้มีคนยืนยันว่าลบแล้ว\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Fol>\u003Cp>ถ้าจะหยิบไปใช้เรื่องเดียวจากบทความนี้ ให้ถามคำถามเดียวก่อนอนุมัติทุกคำขอ copy ข้อมูล production ว่าสำเนานี้จะถูกลบเมื่อไร และใครเป็นคนยืนยัน ถ้ายังตอบไม่ได้ สำเนานั้นยังไม่ควรเกิดขึ้น หากองค์กรของคุณกำลังวางสภาพแวดล้อมทดสอบของระบบใหม่ หรืออยากให้มีคนช่วยทบทวนว่าสำเนาที่มีอยู่ควรจัดการอย่างไร เรายินดีคุยด้วย โดยไม่ต้องรีบตัดสินใจ\u003C\u002Fp>\u003Cp>ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล contact@superdev.tech สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ข้อมูลเพิ่มเติมเกี่ยวกับเราอยู่ที่ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002F\">superdev.tech\u003C\u002Fa> และหากคุยแล้วพบว่าสิ่งที่องค์กรต้องการคือคำตอบทางกฎหมายมากกว่าการออกแบบระบบ เราจะบอกตรง ๆ และแนะนำให้เริ่มจาก DPO ของคุณก่อน\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002Fhpatqzwekkvvw7h\u002Fcover_cover_r63jll6jmm.webp","30 กันยายน 2569","2026-09-30 06:23:14.528Z",114,"Enterprise","enterprise","test-data-masking-pdpa","\u002Fblogs\u002Ftest-data-masking-pdpa",3,false,0,"",[47,48,49,50,51,52,53],"data masking","ข้อมูลทดสอบ","PDPA","pseudonymization","anonymization","synthetic data","UAT"]