การกำบังข้อมูล (Data Obfuscation): การจัดเก็บ vs การแสดงผล

บทสนทนาด้านความปลอดภัยมักมองการกำบังข้อมูล (data obfuscation) เป็น check box ทางสถาปัตยกรรมเพียงช่องเดียว สเปกทางเทคนิคจำนวนมากระบุว่าค่าที่อ่อนไหวต้องถูกทำให้กำบัง ลบปกปิด หรือแปลงรูปก่อนไปถึงที่จัดเก็บหรือบุคคลที่สาม แต่ในทางปฏิบัติ การสับสนว่าจะกำบัง “ที่ไหน” และ “อย่างไร” สร้างช่องโหว่ความปลอดภัยร้ายแรง หรือทำลาย workflow ธุรกิจประจำวัน

การกำบังข้อมูลไม่ใช่เทคนิคเดียว แต่เป็นตระกูลของการแปลงเชิงปฏิบัติและเชิงคณิตศาสตร์ ที่ออกแบบสำหรับช่วงจุดเฉพาะในแอปพลิเคชันของคุณ: ข้อมูลที่จัดเก็บ (data at rest) และ ข้อมูลที่แสดงผล (data in presentation)

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

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

สถานะหลักในวงจรชีวิต: การจัดเก็บ vs การแสดงผล #

ก่อนเลือกกลยุทธ์การกำบัง ทีมวิศวกรรมต้องแยกให้ออกว่าอะไรเกิดขึ้นในฐานข้อมูล กับอะไรเกิดขึ้นบนหน้าจอ:

[Raw Sensitive Data] 
       │
       ├──► Storage Pipeline      ──► [Data at Rest] (Databases, Backups, Caches, Object Stores)
       │
       └──► Presentation Pipeline ──► [Data in Presentation] (Web Portals, Support Dashboards, Logs)

1. ข้อมูลที่จัดเก็บ (Storage): ภัยหลักคือการโจมตีฐานข้อมูล ขโมย backup หรือ query แบบไร้ขอบเขตจากผู้ดูแลที่มีสิทธิ์สูง เป้าหมายคือทำให้แน่ใจว่าถ้าที่จัดเก็บถูก dump หรือ exfiltrate ไป ข้อมูลอ่อนไหวจำนวนมากก็อ่านไม่ได้
2. ข้อมูลที่แสดงผล (Presentation): ภัยหลักคือการแอบดูจอ (shoulder surfing) การยึด session พนักงานภายในที่มีสิทธิ์เกินจำเป็น และการรั่วไหลเข้าเครื่องมือ monitoring เป้าหมายคือแสดงเฉพาะจำนวนตัวอักษรขั้นต่ำที่มนุษย์ต้องใช้ยืนยันตัวตนหรือทำงานให้จบ

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

สเปกตรัมการกำบัง: แยกแยะกลไก #

มาประเมินเทคนิคการกำบังหลักตั้งแต่ cleartext พื้นฐานไปจนถึงการป้องกันเชิง cryptography:

1. Plaintext / Cleartext #

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

Input:                   admin_api_key_88492
Database Stored:         admin_api_key_88492
Screen Presentation:     admin_api_key_88492

• พฤติกรรม: อ่านได้โดยทุกระบบ ทุก query ทุก log และทุกคนที่เห็น
• การป้องกันที่ได้: ไม่มี
• บทบาทที่เหมาะสม: ค่า operational สาธารณะหรือไม่อ่อนไหว (status flag, timestamp, ชื่อผลิตภัณฑ์สาธารณะ)

2. Encoding (เช่น Base64, Hex, URL Encoding) #

Encoding แปลงข้อมูลจากรูปแบบหนึ่งไปอีกรูปแบบด้วย algorithm ที่รู้กันสาธารณะ ย้อนกลับได้ และไม่มี secret key

Input:                   secret_token_123
Base64 Encoded:          c2VjcmV0X3Rva2VuXzEyMw==
Hex Encoded:             7365637265745f746f6b656e5f313233

• วิธีทำงาน: Encoding แปลง binary data เป็น ASCII text เพื่อให้ protocol และมาตรฐานเว็บส่งต่อได้โดยตัวอักษรพิเศษไม่พัง
• ความเข้าใจผิดที่พบบ่อย: หลายทีมเผลอถือ Base64 เป็นชั้นความปลอดภัย แต่เมื่อใครก็ได้ decode Base64 ได้ในเสี้ยววินาทีด้วยเครื่องมือ browser ฟรี มันจึงให้ความลับเป็นศูนย์
• การป้องกันที่ได้: ไม่มี มันคือเครื่องมือด้าน format และความเข้ากันได้ ไม่ใช่การควบคุมความปลอดภัย

3. Masking & Redaction #

Masking แทนที่บางส่วนของตัวอักษรที่อ่อนไหวด้วยตัว placeholder ตายตัว (อย่าง * หรือ X) ภายใต้มาตรฐานการชำระเงินอย่าง PCI DSS หน้าจอแสดงผลได้เพียง 6 หลักแรก (Bank Identification Number) และ 4 หลักสุดท้าย โดยตัวเลขกลางต้องถูกปกปิดทั้งหมด

Full PAN:                4532 0150 9876 1234
PCI DSS Mask:            4532 01XX XXXX 1234  (First 6, Last 4 visible)
Email Mask:              j***n@puresecurity.com
Phone Mask:              +66 88 *** 8600

• Static กับ Dynamic Masking:
  • Static Masking: เขียนทับค่าจริงอย่างถาวรใน environment แบบ staging, QA และ analytics เพื่อให้นักพัฒนาทำงานกับข้อมูลทดสอบที่ปลอดภัย
  • Dynamic Masking: ทำงานทันทีตอน render ที่ API gateway หรือชั้น query ด้านหลัง ฐานข้อมูลเก็บ record ที่ป้องกันแล้ว ส่วนพนักงานที่ไม่มีสิทธิ์เห็นผลลัพธ์แบบ mask บนจอ
• ความเหมาะสมกับสถานะ: จำเป็นสำหรับ การแสดงผลข้อมูล พอร์ทัล call center ใบเสร็จ และ log ของแอปพลิเคชัน
• ระวัง low entropy: กับตัวเลขสั้นหรือคาดเดาได้ (อย่างบัตรเครดิตหรือเลขบัตรประชาชน) masking ทิ้งช่องให้เดาเหลือน้อยมาก ถ้าค่าที่ mask ไปจับคู่กับ hash ที่คำนวณเร็ว ผู้โจมตีไล่หาเลขที่ซ่อนอยู่ที่เหลือได้ในไม่กี่วินาที

4. Truncation #

Truncation ทิ้งบางส่วนของข้อความข้อมูลที่อ่อนไหวอย่างถาวร เก็บไว้เพียงส่วนเล็ก โดยเฉพาะ 4 หลักสุดท้ายเพื่อใช้อ้างอิงกับลูกค้า

Full PAN:                4532 0150 9876 1234
Truncated PAN:           1234  (ONLY the last 4 digits retained)

• วิธีทำงาน: ต่างจาก masking (ซึ่งคงความยาวเต็มแต่แทนด้วยดอกจัน) truncation ทิ้งส่วนที่เหลือของข้อความทิ้งไปถาวร
• ความเกี่ยวข้องกับ PCI DSS: PCI DSS Requirement 3.5 อนุญาต truncation สำหรับการจัดเก็บเลขบัตร โดยมีเงื่อนไขว่าไม่มีระบบภายในอื่นเก็บส่วนที่หายไปไว้ด้วยกัน
• ความเหมาะสมกับสถานะ: ได้ผลมากกับ ข้อมูลที่จัดเก็บ เมื่อการกระทบยอดการเงินต้องการแค่ 4 หลักสุดท้ายมาจับคู่
• ข้อจำกัด: ย้อนกลับไม่ได้ พอ truncate แล้วเลขเดิมหายไปถาวร ถ้าแอปพลิเคชันต้องตั้งเรียกเก็บเงินจากบัตรใบเดิมอัตโนมัติในอนาคต truncation ทำให้ทำไม่ได้ นอกจากจะขอลูกค้ากรอกบัตรใหม่

5. Cryptographic Hashing #

Cryptographic hashing รันข้อมูล input ผ่านฟังก์ชันทางคณิตศาสตร์แบบทางเดียว เพื่อผลิต fingerprint ความยาวคงที่ที่ไม่ซ้ำ

Input:                   PureSecurityAuth
SHA-256 Hash:            8c09a80fa9e3903a453f7b233a010d8677c77742d45c66cb1e4cf7985392fe19

• ธรรมชาติทางเดียว: ย้อน hash กลับเป็นข้อความเดิมทางคณิตศาสตร์ไม่ได้
• การค้นหาแบบ deterministic: input เดียวกันผลิต hash เดียวกันเสมอ จึงใช้ทำ database lookup แบบ exact-match ได้
• ความเสี่ยงของ hash เปล่า ๆ: algorithm มาตรฐานอย่าง SHA-256 ถูกออกแบบให้เร็ว กับข้อมูล low entropy อย่างบัตรเครดิต เบอร์โทร หรือเลขบัตรประชาชน hardware สมัยใหม่ลองเดาได้หลายพันล้านครั้งต่อวินาที ตามที่เราวิเคราะห์ไว้ใน การ hashing ข้อมูล low entropy hash ที่ไม่ใส่ salt ของ input สั้น ให้ความปลอดภัยจริงแทบเป็นศูนย์

ใส่ Salt (ค่าสุ่มราย record) #

salt คือค่าสุ่มที่ไม่ซ้ำ สร้างขึ้นเป็นราย record แล้วผสมกับ input ก่อน hash:

Hash = SHA256(Salt + Input)
Stored Record: { salt: "e4f8a912", hash: "8c09a80f..." }

• ประโยชน์: กันผู้โจมตีใช้ตารางค้นหาสำเร็จรูป (rainbow table) ผู้ใช้สองคนที่ input ตรงกันเป๊ะจะมี hash ต่างกันสิ้นเชิง
• ข้อจำกัด: salt ถูกเก็บในฐานข้อมูลเคียง hash ถ้าผู้โจมตีขโมยฐานข้อมูลไป ก็ยังรัน dictionary attack แบบเจาะจงกับค่า low entropy ได้ด้วยเครื่องมือ crack ด้วย GPU ที่เร็ว

ใส่ Pepper (secret key ฝั่ง server) #

pepper คือ secret key เชิง cryptography ที่เก็บอยู่นอกฐานข้อมูลทั้งหมด เช่น ใน Hardware Security Module (HSM), AWS KMS หรือ secrets manager เฉพาะทาง pepper ถูกผสมกับ input และ salt ภายในฟังก์ชัน HMAC:

Hash = HMAC-SHA256(Key=Pepper, Data=Salt + Input)

• ประโยชน์: แม้ผู้โจมตีขโมยทั้งฐานข้อมูลไป ก็รัน brute-force แบบ offline ไม่ได้ เพราะไม่มี pepper key ที่เก็บอยู่ใน HSM ภายนอก
• ความเหมาะสมกับสถานะ: ยอดเยี่ยมสำหรับการ index ข้อมูลที่จัดเก็บ และ database lookup แบบค้นหาได้

6. Tokenisation #

Tokenisation สลับข้อมูลอ่อนไหวเป็นค่าตัวแทน (token) ที่ไม่อ่อนไหว และไม่มีความเชื่อมโยงเชิงคณิตศาสตร์กับข้อมูลเดิม

Raw Card:                4532 0150 9876 1234
Surrogate Token:         tkn_live_8f3a9e21d044b78c

• Vaulted Tokenisation ทำงานอย่างไร: ข้อมูลจริงถูกเก็บใน token vault แยกอิสระแบบ harden (มักมี HSM รองรับ) ฐานข้อมูลของแอปพลิเคชันถือเพียง token ตัวแทน เมื่อเกิดธุรกรรมแอปส่ง token ไปที่ vault ซึ่ง forward request ต่อไปยัง payment gateway
• ขอบเขตและความเสี่ยงของการ detokenise: tokenisation คือกลยุทธ์มาตรฐานเพื่อลดขอบเขต compliance ภายใต้ PCI DSS compliance ระบบที่เก็บเฉพาะ token จะอยู่นอก Cardholder Data Environment (CDE) แต่คุณต้องควบคุมสิทธิ์การ detokenise อย่างเข้มงวด ถ้าความสามารถย้อนหรือ detokenise token เข้าถึงได้จาก environment ที่กว้างกว่า (เช่น เครือข่ายสำนักงานทั่วไปหรือเครื่องมือ admin ภายใน) เครือข่ายทั้งก้อนนั้นอาจถูกดึงกลับเข้าไปอยู่ในขอบเขต CDE ทันที
• ความเหมาะสมกับสถานะ: โดดเด่นสำหรับ ข้อมูลที่จัดเก็บ และ workflow ภายในของแอปพลิเคชัน

7. Encryption (แบบ Symmetric และ Asymmetric) #

Encryption ใช้ secret key เพื่อแปลง plaintext เป็น ciphertext และกลับคืน ต่างจาก hashing แบบทางเดียว encryption ย้อนกลับได้เต็มที่สำหรับระบบที่ได้รับอนุญาตและถือ decryption key

• Symmetric Encryption (AES-256-GCM): ใช้ key เดียวกันทั้งเข้ารหัสและถอดรหัส เร็วมากและเหมาะกับคอลัมน์ฐานข้อมูล ที่จัดเก็บไฟล์ และ API payload ตามที่เราเจอะไว้ในคู่มือ การเข้ารหัส API payload ตามกฎธนาคารแห่งประเทศไทย
• Asymmetric Encryption (RSA, ECC): ใช้ public key เข้ารหัส และ private key ถอดรหัส ทำให้ browser ของ client หรืออุปกรณ์มือถือเข้ารหัสข้อมูลอ่อนไหวที่มีเพียง backend service ที่ได้รับการปกป้องเท่านั้นเปิดออกได้
• ข้อกำหนดด้านการจัดการ key: ข้อมูลที่เข้ารหัสปลอดภัยแค่ key ที่ปกป้องมัน decryption key ต้องแยกจากที่จัดเก็บฐานข้อมูล และดูแลด้วยนโยบายการเข้าถึงและการหมุนเวียนแบบอัตโนมัติ

ตารางเปรียบเทียบ: วิธีการกำบังข้อมูล #

ตารางข้างล่างสรุปพฤติกรรมของแต่ละวิธี ปกป้องสถานะข้อมูลใด และ trade-off หลักคืออะไร:

กรอบการตัดสินใจทางสถาปัตยกรรม #

เมื่อต้องเลือกว่าจะใช้เทคนิคกำบังหรือปกป้องข้อมูลแบบไหนกับ field ที่อ่อนไหวแต่ละตัว เดินตาม decision tree นี้:

ประเด็นสำคัญที่ต้องจำ #

1. ลดปริมาณข้อมูลก่อน: วิธีที่ดีที่สุดในการปกป้องข้อมูลคือไม่เก็บมันตั้งแต่แรก ถ้ากระบวนการปฏิบัติงานไม่ได้ต้องใช้ field นั้นจริง ๆ ให้ตัดทิ้งหรือลบทิ้งทันที
2. อย่าใช้การควบคุมการแสดงผลแทนความปลอดภัยตอนจัดเก็บ: การแสดงดอกจันบน frontend ไม่ได้ปกป้องคอลัมน์ฐานข้อมูลที่ไม่เข้ารหัสจาก SQL injection หรือการรั่วของ backup
3. ปกป้องตัวระบุ low entropy: ถ้าต้อง index เลขบัตรเครดิต เลขบัตรประชาชน หรือเบอร์โทร อย่าใช้ SHA-256 เปล่า ๆ ใช้ HMAC ที่มี pepper ฝังใน hardware หรือ algorithm แบบ memory-hard
4. แยก encryption key ออกไป: เก็บ key ในบริการ KMS หรือ HSM เฉพาะทางพร้อมควบคุมการเข้าถึงเข้มงวด การเก็บ key ไว้ใน environment ฐานข้อมูลเดียวกันทำให้การควบคุมนั้นไร้ความหมาย
5. ระวังขอบเขตการ detokenise: แม้ tokenisation ลดขอบเขต compliance ลงมาก การยอมให้เครือข่ายสำนักงานที่ไม่แบ่ง segment หรือเครื่องมือทั่วไป detokenise ข้อมูลได้ จะดึง environment ที่กว้างกว่านั้นเข้าไปอยู่ในขอบเขตกฎกำหนดทันที

เริ่มจากตรงไหน #

• ประเมินขอบเขตปัจจุบัน: ทำ PCI DSS Gap Assessment & Scope Reduction เพื่อระบุเส้นทางข้อมูลอ่อนไหวที่ยังไม่ได้รับการปกป้องทั่ว infrastructure
• ตรวจ API ของแอปพลิเคชัน: ทำ API & Application Security Review เพื่อให้แน่ใจว่าการ mask ฝั่ง frontend สอดคล้องกับ tokenisation และมาตรฐานการเข้ารหัส payload ฝั่ง backend
• ตรวจสอบ compliance ด้านกฎกำหนด: ทบทวนการควบคุมปกป้องข้อมูลของคุณกับ framework ของ APAC ผ่าน บริการ Regulatory Compliance Advisory