หลักคิดง่ายๆ — ลงทุน control ตามค่าของของ#

หัวใจของ Data Classification คือ ติดป้ายให้รู้ว่าของชิ้นไหนค่าเท่าไหร่ — แล้วลงทุน control ตามค่า

ภาพในใจครับ — เซฟในบ้านคุณ. คุณไม่ได้เอาทุกอย่างใส่เซฟเดียวกัน. ของในกระเป๋าตังค์ทุกวัน = อยู่ในกระเป๋าธรรมดา. ของมีค่าระดับกลาง (เครื่องประดับที่ใช้บ่อย) = อยู่ในลิ้นชักที่ล็อก. ของมีค่าสูง (ทอง โฉนด) = อยู่ในเซฟใหญ่ที่ใช้กุญแจ. ความลับสุดยอด (พินาทิคำ password ของ wallet crypto) = อยู่ใน safe deposit box ที่ธนาคาร

ในชีวิตจริง คุณ classify ของแบบนี้โดยอัตโนมัติ — แต่บริษัทส่วนใหญ่ไม่ทำกับ data. นี่คือสาเหตุที่ Data Classification = first step ของ data security ที่ทุกคู่มือ (ISO 27001 / NIST 800-53 / CIS Controls) สั่งให้ทำเป็นข้อแรกของ Domain Data Protection

มุมผู้บริหาร: ถามตัวเองข้อเดียวครับ — ถ้าวันนี้บริษัทคุณเกิด data breach — และ regulator (PDPC ของไทย) ถามว่า “ข้อมูลที่หลุดเป็นระดับไหน — สำคัญแค่ไหน” — คุณตอบได้ไหม? ถ้าตอบ “ไม่รู้ — เรายังไม่ได้ classify” = บริษัทคุณจะถูกประเมินว่า ไม่ได้ทำ data governance = penalty หนักกว่าบริษัทที่ classify ไว้แล้ว. Data Classification = control ที่ราคาถูกที่สุด แต่ ROI สูงที่สุด ใน Part 3 ทั้งหมด — เพราะมันคือฐานที่ control อื่นทั้งหมดต้องยืน

ชุด Enterprise — 4 ระดับ Public / Internal / Confidential / Restricted#

นี่คือมาตรฐานที่ Microsoft, Google, AWS, และบริษัท Fortune 500 ส่วนใหญ่ใช้ครับ. แบ่ง data เป็น 4 tier ตามผลกระทบถ้าหลุด:

Tier 1 — Public (สาธารณะ)

• ข้อมูลที่ตั้งใจให้คนนอกบริษัทเห็นได้
• ตัวอย่าง: เว็บไซต์บริษัท, brochure การตลาด, ข่าวประชาสัมพันธ์, ราคาสินค้าบนเว็บ, รายงานประจำปีที่ตีพิมพ์แล้ว
• ถ้าหลุด — ไม่เสียหาย (เพราะตั้งใจจะปล่อยอยู่แล้ว)
• Control: ไม่ต้อง encrypt, ไม่ต้อง access control พิเศษ

Tier 2 — Internal (ภายใน)

• ข้อมูลที่ให้พนักงานในบริษัทเห็นได้ — แต่ไม่ปล่อยออกนอก
• ตัวอย่าง: employee handbook, นโยบายภายใน, ข่าวภายในบริษัท, slide ประชุมทีม, รายชื่อเบอร์โทรพนักงาน
• ถ้าหลุด — เสียหายน้อย (อาจกระทบภาพลักษณ์เล็กน้อย)
• Control: ต้อง login เข้าระบบบริษัท, restrict to domain

Tier 3 — Confidential (ลับ)

• ข้อมูลที่ให้บางแผนก / บางคนเห็น — ห้ามแชร์นอกกลุ่ม
• ตัวอย่าง: financial report ก่อนประกาศ, สัญญากับ vendor, แผนกลยุทธ์ปีหน้า, รายชื่อลูกค้า, ราคาต้นทุน
• ถ้าหลุด — เสียหายมาก (กระทบกำไร / ความสัมพันธ์ทางธุรกิจ / คู่แข่งได้เปรียบ)
• Control: encrypt at rest + in transit, MFA required, access log, restrict sharing

Tier 4 — Restricted (ลับสุดยอด)

• ข้อมูลที่หลุดแล้วบริษัทอาจล้ม / โดนปรับหนัก / โดนฟ้อง
• ตัวอย่าง: เลขบัตรเครดิตลูกค้า, PII ที่ regulated (เลขบัตรประชาชน + ข้อมูลสุขภาพ), source code ของผลิตภัณฑ์หลัก, master encryption key, รหัสผ่าน root ของระบบ critical, M&A documents
• ถ้าหลุด — บริษัทอาจล้ม (PDPA / GDPR penalty + ฟ้องร้อง + ชื่อเสียงพัง)
• Control: end-to-end encrypt, hardware-backed key (HSM), strict access (just-in-time), full audit trail, DLP บล็อก share อัตโนมัติ

ชุด Military / Government — Top Secret / Secret / Confidential / Unclassified#

ฝั่งทหาร + รัฐบาล ใช้ระบบที่คล้ายกัน แต่ชื่อต่างและเก่ากว่า — มาตั้งแต่สมัยสงครามโลกครั้งที่ 2:

• Top Secret (TS) — ลับสุดยอด — หลุดแล้วกระทบความมั่นคงระดับชาติ “ร้ายแรงและพิเศษ” (ตัวอย่าง: แผนสงคราม, intel ของ spy ที่ยังทำงาน)
• Secret (S) — ลับมาก — หลุดแล้วกระทบความมั่นคงระดับชาติ “ร้ายแรง” (ตัวอย่าง: เทคโนโลยีอาวุธ, ข้อตกลงทูตที่ยังไม่เปิด)
• Confidential (C) — ลับ — หลุดแล้วกระทบ “พอประมาณ” (ตัวอย่าง: รายงาน internal ของกระทรวง)
• Unclassified (U) — ไม่ลับ (แต่ไม่ใช่ public — เป็น “ภายในรัฐ” — ใกล้กับ Internal ของ enterprise)

ทุกชั้นมี clearance level ของคน — ทหาร / staff รัฐ จะมี clearance สอดคล้องกับชั้นที่เห็นได้. กฎ Bell-LaPadula ที่เราเคยพูดใน EP.16 (No Read Up / No Write Down) เกิดจากระบบนี้

ในบริษัทไทย — ส่วนใหญ่ไม่ได้ใช้ tier ทหาร. ใช้ชุด enterprise 4-tier ก็พอ. แต่ถ้าบริษัทคุณรับงาน defense / government contract — ต้องเข้าใจชุดทหารด้วย เพราะ contract จะระบุชั้นข้อมูลตามนี้

ตัวอย่างการ map data ของบริษัทไทยทั่วไป#

ลองมา map data ของบริษัทไทยขนาดกลาง 1 บริษัทว่าอะไรอยู่ tier ไหน:

ทำตารางแบบนี้ครั้งแรก = อาจใช้เวลา 1-2 เดือน. แต่หลังทำเสร็จ = ทุก control ของบริษัทคุณจะมี เกณฑ์ตัดสินใจที่ชัดเจน — ไม่ใช่ลงทุนแบบเดาๆ อีกต่อไป

มุมผู้บริหาร: เริ่มจาก 4 tier ก็เพียงพอ สำหรับบริษัทไทยขนาดกลาง. อย่าออกแบบ tier เพิ่มเอง (scenario คลาสสิคในเอกสาร best practice — บริษัทออกแบบ 8 tier — ในชีวิตจริงไม่มีใครจำได้ — กลายเป็น classification ที่ไม่มีใครใช้). 4 tier ของ Microsoft / Google = มาตรฐานสากล + เครื่องมือ enterprise ส่วนใหญ่รองรับอยู่แล้ว — ไม่ต้อง reinvent the wheel. สิ่งที่สำคัญกว่าจำนวน tier = definition ที่ชัดและตัวอย่างที่ทุกคนเข้าใจ

Data Owner — เจ้าของข้อมูล (Business)#

Data Owner = คนใน ฝั่งธุรกิจ ที่รับผิดชอบ data ชุดนั้น. มักเป็น ระดับผู้บริหารหรือหัวหน้าฝ่าย — ไม่ใช่ทีม IT

หน้าที่:

• กำหนดว่าข้อมูลชุดนี้ classify เป็น tier ไหน (Public / Internal / Confidential / Restricted)
• อนุมัติว่าใครมีสิทธิ์เข้าถึง
• รับผิดชอบ business impact ถ้าข้อมูลหลุด
• กำหนด retention policy (เก็บนานแค่ไหน)

ตัวอย่าง:

• ข้อมูลลูกค้า → Data Owner = หัวหน้าฝ่าย Sales / Customer Success
• ข้อมูลพนักงาน + เงินเดือน → Data Owner = HR Director
• financial data + งบการเงิน → Data Owner = CFO
• source code ของผลิตภัณฑ์ → Data Owner = CTO หรือ Head of Engineering

หัวใจ — Data Owner เป็น business person ที่เข้าใจคุณค่า + ผลกระทบของข้อมูล. ไม่ใช่คน IT

Data Custodian — ผู้ดูแลทางเทคนิค (IT)#

Data Custodian = คน ฝั่ง IT ที่ดูแลข้อมูลในทางเทคนิค — ทำตามคำสั่งของ Data Owner

หน้าที่:

• เก็บข้อมูลให้ปลอดภัย ตาม tier ที่ Owner กำหนด (encrypt, backup, access control)
• ดูแลระบบ ที่ data อยู่ (database, file server, cloud bucket)
• monitor + audit การเข้าถึง
• execute การลบ / archive ตาม policy ของ Owner

ตัวอย่าง:

• Database Administrator (DBA) ที่ดูแล database ของลูกค้า = Custodian
• Cloud engineer ที่ดูแล S3 bucket = Custodian
• System admin ที่ดูแล file server = Custodian

หัวใจ — Custodian = executor ที่ทำตามนโยบายของ Owner. ไม่ใช่คนกำหนดนโยบาย

Data Steward — ผู้ตรวจคุณภาพข้อมูล (Quality)#

Data Steward = คนที่ดูแล คุณภาพและความถูกต้อง ของข้อมูล. มักอยู่ในทีม Data หรือ Analytics

หน้าที่:

• ดูแลคุณภาพ data (ความถูกต้อง, completeness, consistency)
• กำหนดมาตรฐาน การกรอกข้อมูล (เช่น “เบอร์โทรต้องเป็นรูปแบบ +66…” )
• resolve data conflict เมื่อเจอ inconsistency
• เชื่อมโยง data ข้ามระบบ (เช่น customer record ของ CRM ตรงกับของ ERP ไหม)

ตัวอย่าง:

• Customer Data Steward ที่ตรวจว่าข้อมูลลูกค้าใน CRM + ERP + Email marketing ตรงกัน
• Product Data Steward ที่ดูแลว่า product code ใน warehouse ตรงกับใน e-commerce

หัวใจ — Steward = data quality champion. ไม่ใช่เจ้าของ + ไม่ใช่ executor — แต่เป็นคนที่ดูแลให้ data ใช้งานได้จริง

ตัวอย่างทั้ง 3 บทบาทใน scenario เดียวกัน#

ลองดู scenario นี้ — ข้อมูลลูกค้าของบริษัทไทย E-commerce:

• Data Owner = หัวหน้าฝ่าย Customer Experience (VP)

  • กำหนด: “ข้อมูลลูกค้า = Confidential. เลขบัตรประชาชน + เลขบัตรเครดิต = Restricted”
  • อนุมัติ: “ทีม Customer Support เห็น tier Confidential ของลูกค้าตัวเองได้. ไม่มีใครเห็น Restricted ยกเว้นระบบ payment processor”
  • กำหนด: “เก็บข้อมูลลูกค้า 5 ปีหลัง transaction สุดท้าย — ลบหลังจากนั้น”

• Data Custodian = DBA ของทีม Engineering

  • execute: encrypt database + S3 bucket ตาม Owner กำหนด
  • execute: setup IAM role ให้ Customer Support เห็นได้ตามที่ Owner อนุมัติ
  • execute: setup automated deletion job ตาม retention 5 ปี
  • monitor: ใครเข้าดูข้อมูลลูกค้า + alert ถ้ามีการเข้าผิดปกติ

• Data Steward = Customer Data Analyst

  • ตรวจ: เบอร์โทรของลูกค้าใน CRM + ระบบ ticket + email marketing — ตรงกันไหม?
  • resolve: ถ้าเจอลูกค้า 1 คนมี record ซ้ำ → merge ให้
  • กำหนด: standard format ของชื่อ + ที่อยู่

3 บทบาท — 3 คน — รับผิดชอบคนละด้าน — แต่ทำงานร่วมกัน

กับดักคลาสสิคของวงการ — “IT เป็นเจ้าของข้อมูลทุกอย่าง”#

นี่คือ pattern ที่บริษัทไทยติดบ่อยที่สุดครับ — ผู้บริหารโยน data ownership ให้ทีม IT. คิดว่า “data อยู่ในระบบ IT = IT รับผิดชอบ”

ผลคือ — เมื่อเกิด data breach — ผู้บริหาร business ไม่รับผิดชอบ (โทษ IT) — IT ก็ไม่มี business context (ไม่รู้ว่าข้อมูลชุดไหนสำคัญแค่ไหน). ทุกอย่างค้างกลาง

แก้ไข — แยกบทบาทให้ชัดตั้งแต่ต้น:

• business person เป็น Data Owner (รับผิดชอบ business impact + กำหนด tier + อนุมัติ access)
• IT เป็น Custodian (executor)
• Data team เป็น Steward (quality champion)

ใน RACI matrix — Owner = Accountable, Custodian = Responsible, Steward = Responsible (quality)

มุมผู้บริหาร: ลองทำ exercise ในบริษัทคุณ — ระบุ data 5 ชุดที่สำคัญที่สุด (ข้อมูลลูกค้า / ข้อมูลพนักงาน / financial / IP / strategic plan) — แล้วถามว่า “ใครเป็น Data Owner ของแต่ละชุด?”. ถ้าตอบไม่ได้ทันที = บริษัทคุณยังไม่มี data governance ที่ชัดเจน. กำหนด Data Owner ของแต่ละชุดเป็นลายลักษณ์อักษร — ใส่ใน RACI — ติดประกาศใน intranet. นี่คือ control ที่ราคา 0 บาท — แต่ผลกระทบสูงมากในวันที่เกิดเหตุ

Phase 1 — Create (เกิด)#

ข้อมูลถูกสร้างขึ้น. อาจมาจาก:

• พนักงานพิมพ์ใน Word / Excel / Google Doc
• ลูกค้ากรอก form ในเว็บไซต์
• ระบบ generate อัตโนมัติ (log, transaction, sensor data)
• ซื้อจากแหล่งภายนอก (เช่น ซื้อ market research)

ความเสี่ยงในเฟสนี้:

• ข้อมูลที่สร้างไม่ได้รับ tag classification ตั้งแต่แรก
• พนักงานสร้างข้อมูล Restricted ในเครื่องส่วนตัวที่ไม่ปลอดภัย
• ข้อมูลซ้ำซ้อน — สร้างหลายชุดในระบบต่างกัน → quality issue

Control:

• บังคับ tag classification ตอนสร้าง (manual หรือ auto-detect)
• บังคับสร้างในระบบ enterprise — ไม่ใช่เครื่องส่วนตัว
• template สำหรับ data ที่ถูกสร้างซ้ำ (ลูกค้าใหม่, employee onboarding form)

Phase 2 — Store (เก็บ)#

ข้อมูลถูกเก็บใน storage. อาจเป็น:

• Database (MySQL / PostgreSQL / MongoDB)
• File system (NAS, file server)
• Cloud storage (S3, Google Drive, OneDrive)
• Email server
• Backup system

ความเสี่ยงในเฟสนี้:

• Data at Rest ถูกขโมยถ้า storage หลุด (HDD โดนขโมย / bucket ตั้ง public)
• Backup ไม่ได้ encrypt — เปิดอ่านได้ถ้าตกในมือผิด
• ข้อมูล Restricted อยู่ใน storage ที่ไม่มี control พอ

Control:

• Encrypt at Rest สำหรับ tier Confidential + Restricted (AES-256)
• Access control ตาม tier (RBAC + ABAC)
• Backup encryption + offsite backup
• Audit log ทุกการ access

Phase 3 — Use (ใช้)#

ข้อมูลถูกใช้งาน — เปิดอ่าน, แก้ไข, query, วิเคราะห์, แสดงผลใน dashboard

ความเสี่ยงในเฟสนี้:

• Data in Use = อยู่ใน RAM ของเครื่อง — โดนอ่านได้ถ้าเครื่องถูก compromise
• พนักงาน screenshot / ถ่ายรูปจอ → ข้อมูลออกจาก control
• ข้อมูลถูกใช้นอกเครื่องบริษัท (work from home + เครื่องส่วนตัว)
• Shadow IT — พนักงานเอา data ไปใส่ใน AI / SaaS ที่ไม่ approved

Control:

• MFA + Just-In-Time access สำหรับ tier สูง
• DLP (Data Loss Prevention) ตรวจจับการ copy / paste / upload
• Watermark บน document ที่เปิด
• Confidential Computing (เทคโนโลยีใหม่ — encrypt data ใน RAM)

Phase 4 — Share (แชร์)#

ข้อมูลถูกส่งไปยังคนอื่น — ภายในบริษัท หรือนอกบริษัท

ความเสี่ยงในเฟสนี้:

• Data in Transit ถูกดักจับ (man-in-the-middle attack)
• แชร์ผิดคน (กรอก email ผิด — ส่งให้คนนอก)
• แชร์เกินขอบเขต (Google Drive “anyone with link”)
• ลืม revoke access หลังพ้นความจำเป็น

Control:

• Encrypt in Transit (TLS / HTTPS — เรื่องที่ EP.24 จะพูด)
• DLP บล็อกการแชร์ Restricted ออกนอก domain
• Expiring links (Google Drive expire ใน 7 วัน)
• Audit sharing log + alert ถ้าแชร์ออกนอก

Phase 5 — Archive (เก็บเก่า)#

ข้อมูลที่ไม่ใช้งานทั่วไปแล้ว — แต่ยังต้องเก็บ (ตามกฎหมาย / ตามนโยบาย)

ตัวอย่าง:

• เอกสารบัญชี → ต้องเก็บ 5 ปี (ตาม กม. ภาษีไทย)
• ข้อมูลผู้ป่วย → 10 ปี (ตาม กม. สาธารณสุข)
• email พนักงานที่ลาออก → 1-3 ปี

ความเสี่ยงในเฟสนี้:

• ลืมว่าข้อมูล archive มีอยู่ (out of sight, out of mind)
• ข้อมูล archive ไม่ได้ encrypt → หลุดได้
• ไม่มีคนรู้ว่าจะลบเมื่อไหร่

Control:

• Archive policy ชัด (storage แยก + access จำกัด)
• Encryption สำหรับ archive ทุก tier ที่ ≥ Confidential
• Retention schedule ที่ automated (ลบอัตโนมัติเมื่อครบเวลา)
• อย่าเก็บนานเกินจำเป็น — GDPR / PDPA บอกชัด “เก็บไม่เกินที่จำเป็น”

Phase 6 — Destroy (ทำลาย)#

ข้อมูลที่หมดประโยชน์ + ครบ retention → ทำลาย. นี่คือเฟสที่บริษัทไทยพลาดบ่อยที่สุด — และเป็นจุดเริ่มของเคส breach ใหญ่หลายเคส

Scenario 1 — บริษัทไทย ใช้ AWS เก็บข้อมูลลูกค้าใน region US-East-1#

• บริษัทคุณอยู่ในกรุงเทพ
• ลูกค้าเป็นคนไทย — กรอก email + เลขบัตรประชาชน
• คุณเลือก AWS region = US-East-1 (Virginia) เพราะถูกกว่า
• ข้อมูลคนไทย — ตอนนี้อยู่บน server ในรัฐ Virginia สหรัฐ

ผลกระทบทางกฎหมาย:

• PDPA ไทย ใช้ — เพราะ data subject เป็นคนไทย (มี extraterritorial scope)
• CCPA / California state law อาจใช้บางส่วน — เพราะ server อยู่ในสหรัฐ
• CLOUD Act ของสหรัฐ — รัฐบาลสหรัฐขอข้อมูลจาก AWS ได้ โดยไม่ต้องแจ้งคุณ — เพราะ AWS เป็นบริษัทอเมริกัน
• ถ้าลูกค้าฟ้อง — ฟ้องได้ทั้งในไทย + ในสหรัฐ
• ถ้าโดน breach — ต้องแจ้ง PDPC ไทย + อาจต้องแจ้ง regulator สหรัฐ (ถ้ามี Californian)

Scenario 2 — บริษัทไทย ใช้ Azure region Southeast Asia (Singapore)#

• ข้อมูลคนไทย — อยู่ใน Singapore
• PDPA ไทย ยังใช้ (extraterritorial)
• PDPA Singapore อาจใช้บางส่วน
• CLOUD Act สหรัฐ ยัง apply ได้ เพราะ Azure เป็น Microsoft ของอเมริกัน
• แต่ latency ดีกว่า + ภายใต้กฎหมายของประเทศใน ASEAN

GDPR — กฎหมายที่เปลี่ยนเกม Data Sovereignty ทั่วโลก#

GDPR (General Data Protection Regulation) ของ EU — มีผล 25 พฤษภาคม 2018 — เปลี่ยน landscape ของ data sovereignty ทั่วโลก

หัวใจของ GDPR ที่เกี่ยวกับ sovereignty:

• ข้อมูลของพลเมือง EU ต้องอยู่ภายใต้กฎ GDPR — ไม่ว่าเก็บที่ไหนในโลก
• Cross-Border Data Transfer ออกจาก EU ทำได้ต่อเมื่อประเทศปลายทาง “adequate” (ระดับ data protection เทียบเท่า EU) — ไทยยังไม่ adequate ในปัจจุบัน
• ถ้าไม่ adequate — ต้องใช้ Standard Contractual Clauses (SCC) หรือ Binding Corporate Rules (BCR)
• Schrems II ruling ปี 2020 — ECJ ตัดสินว่า EU-US Privacy Shield ไม่ valid — บริษัทยุโรปที่ใช้ AWS / Azure / Google ของอเมริกัน ต้องประเมินใหม่
• penalty สูงสุด 4% ของ global revenue หรือ €20 ล้าน (อะไรสูงกว่า)

ผลที่เกิดในวงการ — บริษัทอเมริกันใหญ่ๆ (AWS, Azure, Google) ต้องสร้าง region ใน EU + แยก infrastructure + ทำ data residency commitment สำหรับลูกค้ายุโรป

PDPA ไทย + Data Localization#

PDPA (Personal Data Protection Act) พ.ศ. 2562 ของไทย — มีผลบังคับเต็ม 1 มิถุนายน 2565 — สร้างตามรอย GDPR

หัวใจ:

• ใช้กับ ข้อมูลส่วนบุคคลของคนในไทย ไม่ว่า data ตั้งอยู่ที่ไหน (extraterritorial)
• Cross-Border Transfer ต้องไปประเทศที่มีมาตรฐานคุ้มครองเพียงพอ — หรือมีมาตรการ (SCC / consent)
• penalty สูงสุด 5 ล้านบาท + อาญา + ค่าเสียหายเชิงลงโทษ 2 เท่า
• ต้อง appoint DPO (Data Protection Officer) ถ้าจัดการข้อมูล sensitive จำนวนมาก
• ต้องแจ้ง breach ภายใน 72 ชั่วโมง

Data Localization — บางประเทศกำหนดเข้มกว่า — บังคับให้ข้อมูลของพลเมืองเก็บในประเทศเท่านั้น:

• รัสเซีย — ข้อมูลพลเมืองรัสเซีย ต้องเก็บใน server ในรัสเซีย
• จีน — ข้อมูลคนจีน + critical infrastructure data ต้องอยู่ใน server ในจีน (Cybersecurity Law + DSL + PIPL)
• อินเดีย — มีการพิจารณา data localization สำหรับ payment data
• เวียดนาม — Cybersecurity Law 2018 บังคับบางประเภท

ไทยยังไม่บังคับ localization — แต่บางอุตสาหกรรม (banking, telecom) มี requirement เฉพาะ

หลักคิดสำหรับบริษัทไทย — เลือก region อย่างมีสติ#

ตอนคุณเลือก cloud provider + region — ไม่ใช่แค่เรื่อง latency กับราคา. ต้องคิดเรื่อง sovereignty ด้วย:

1. ลูกค้าเป็นคนชาติไหน? → กฎหมายประเทศนั้นจะ apply (PDPA, GDPR, etc.)
2. Server อยู่ประเทศไหน? → กฎหมายประเทศนั้นจะ apply เพิ่ม (เช่น CLOUD Act ถ้า provider US)
3. มี cross-border transfer ไหม? → ต้อง compliance ตามกฎ transfer
4. อุตสาหกรรมคุณมี localization requirement ไหม? → banking / telecom / healthcare มักมี

ทางออกที่ enterprise นิยม:

• Data Residency commitment — เลือก region ใกล้บริษัท (Singapore / Tokyo / Bangkok)
• Sovereign Cloud — บางประเทศมี cloud ของรัฐ / ของบริษัทในประเทศ (AWS GovCloud, Azure Government, Google Sovereign Cloud)
• Hybrid — ข้อมูลที่ sensitive สูงเก็บ on-premise + ข้อมูลทั่วไปใช้ cloud

มุมผู้บริหาร: ถามทีม IT 1 ข้อ — “ข้อมูลลูกค้าของบริษัทเราเก็บที่ไหน — region ไหน — ประเทศไหน?”. ถ้าตอบไม่ได้ทันที = คุณมี data sovereignty risk ที่ไม่รู้ตัว. ในยุค PDPA + GDPR — คำถามนี้คือคำถามแรกที่ regulator จะถามตอนเกิดเหตุ. และถ้าธุรกิจคุณมีลูกค้าใน EU แม้แค่ 100 คน — GDPR ใช้กับคุณเต็ม — รวมถึง penalty 4% ของ global revenue

Microsoft Purview — แพลตฟอร์ม Data Governance ของ Microsoft#

Microsoft Purview (เดิมชื่อ Azure Purview + Microsoft 365 Compliance) — เครื่องมือ enterprise สำหรับ data governance ทั้งระบบ

หน้าที่หลัก:

• Sensitivity Labels — สร้าง label (Public / Internal / Confidential / Restricted) — ติดได้ใน Word / Excel / PowerPoint / Outlook / SharePoint / OneDrive — automatic หรือ manual
• Data Loss Prevention (DLP) — policy บล็อก / warn / encrypt อัตโนมัติเมื่อมีการ share Restricted ออกนอก
• Auto-classification — AI scan content + ติด label อัตโนมัติ (เจอเลขบัตรเครดิต → ติด Restricted)
• Retention Policy — auto-delete หลังครบกำหนด
• eDiscovery — search ข้อมูลทั้งบริษัทตอนต้อง compliance / litigation
• Data Map — เห็นภาพรวมว่า data ของบริษัทอยู่ที่ไหนบ้าง (cross Microsoft 365 + Azure + on-prem)

ราคา: ผ่าน Microsoft 365 E5 license (~$57/user/month) หรือ Purview standalone

AWS Macie + AWS DataZone#

ฝั่ง AWS — มี 2 ตัวหลัก:

AWS Macie — ML-based discovery ของ sensitive data ใน S3:

• scan S3 bucket อัตโนมัติ + เจอ PII, financial data, credentials
• ติด tag classification อัตโนมัติ
• alert ถ้าเจอ Restricted data ใน bucket ที่ public
• เคยช่วยเปิดเผยเคส Capital One 2019 ที่ data ลูกค้าหลุดผ่าน misconfigured S3

AWS DataZone (เปิดตัวปี 2023) — data governance + catalog:

• catalog ของ data assets ทั้งบริษัท
• กำหนด data owner / steward
• กำหนด policy + audit access

Google Workspace — Data Loss Prevention + Sensitivity Labels#

Google Workspace Enterprise มี:

• DLP for Gmail + Drive — บล็อก share หรือ encrypt อัตโนมัติ
• Sensitivity Labels (เพิ่งเข้ามาในปี 2023-2024)
• Context-Aware Access — เชื่อมกับ classification (เช่น Restricted file เข้าได้เฉพาะจาก corporate device)
• Vault — eDiscovery + retention

IBM Guardium / Symantec DLP / Forcepoint#

สำหรับ enterprise ที่มี data ใน database + on-prem มากกว่า cloud — มี:

• IBM Guardium — database activity monitoring + DLP
• Symantec DLP (now Broadcom) — endpoint + network + cloud DLP
• Forcepoint DLP — เน้น insider threat detection

บริษัทไทยขนาดใหญ่ (ธนาคาร, telecom, รัฐวิสาหกิจ) ใช้กลุ่มนี้กันมาก

เคสที่ใช้สอนตลอดกาล — Edward Snowden 2013 (NSA Classification Failure)#

ปิดท้าย EP.18 ด้วยเคสที่ทุกห้องเรียน security ใช้สอน data classification failure ครับ — Edward Snowden 2013

ภูมิหลัง — Edward Snowden เป็น system administrator + contractor ที่ทำงานให้ NSA (National Security Agency ของสหรัฐ) ผ่านบริษัท Booz Allen Hamilton

ปัญหาที่ NSA มี:

• Snowden มี Top Secret / SCI clearance (สูงสุดของระบบทหารสหรัฐ)
• ในฐานะ sysadmin — เขามี administrative access ของระบบ NSA
• NSA มี policy ที่ตามทฤษฎีเข้มงวด แต่ implementation ของ access control ไม่ได้ enforce principle of least privilege และ need-to-know อย่างเข้มงวด — sysadmin ของบาง position สามารถดึง file จำนวนมากออกจาก system ได้
• มี report ที่ระบุว่ามีการเคลื่อนย้าย file จำนวนมาก ก่อน Snowden จะหลบหนีออกไป

Snowden ใช้ access นี้ — copy เอกสารลับระดับ Top Secret หลายแสน file — เกี่ยวกับ surveillance program ของ NSA (PRISM, XKEYSCORE, etc.)

เดือนพฤษภาคม 2013 — Snowden เดินทางไปฮ่องกง + มอบเอกสารให้ The Guardian + Washington Post. ข่าวระเบิดทั่วโลก. NSA + รัฐบาลสหรัฐขายหน้าระดับประวัติศาสตร์

บทเรียนจากเคสนี้ (ที่ post-mortem ของ NSA ออกมา):

1. Classification ไม่พอ — ถ้า access control ตามชั้นไม่ enforce — Snowden มี clearance ระดับ Top Secret = เห็นเอกสารระดับ Top Secret ได้ — แต่ need-to-know ไม่ได้ enforce — ไม่มีใครถามว่า “sysadmin คนนี้ ต้องเห็นเอกสาร surveillance program ทำไม?”
2. Insider Threat = ความเสี่ยงที่ใหญ่ที่สุดของ data ระดับสูง — outsider attack ป้องกันได้ — แต่คนใน + มี privilege + รู้ระบบ = ป้องกันยากที่สุด
3. Sysadmin + Privileged user = single point of failure — คน 1 คนที่มี admin access ของระบบที่เก็บ Top Secret = ความเสี่ยงระดับชาติ
4. Data exfiltration detection ของ NSA — ไม่จับ การ copy file ขนาดใหญ่ออก. ระบบ DLP ไม่ทำงานสำหรับ insider ที่มี privilege

ผลที่ตามมา — หลัง Snowden:

• NSA + รัฐบาลสหรัฐ implement mandatory 2-person rule สำหรับ access เอกสารระดับ Top Secret
• Reduce privilege ของ sysadmin — แยก role
• Continuous monitoring ของ data movement
• Insider threat program เป็น mandatory ของ federal agency

ในวงการ enterprise — เคส Snowden เป็นเหตุที่ Privileged Access Management (PAM) + User Behavior Analytics (UBA) + Data Loss Prevention (DLP) กลายเป็น control พื้นฐานของบริษัทใหญ่ทั่วโลก

มุมผู้บริหาร: เคส Snowden ดูไกลตัว — แต่หลักการเหมือนกัน. คำถามที่ผู้บริหารต้องถามตัวเอง — “sysadmin / DBA / cloud admin ของเรา ถ้าเขาทรยศวันนี้ — กี่นาทีก่อนคุณจะรู้ตัว?” ส่วนใหญ่บริษัทไทยตอบ “หลายเดือน” หรือ “อาจไม่รู้เลย” — Insider Threat คือ blind spot ของบริษัทไทยขนาดกลาง. แก้ที่ Data Classification ที่ enforce need-to-know — ไม่ใช่แค่ติด label

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — Data Classification คือ first step ของ data security ที่ทุกบริษัทต้องทำก่อน

นี่คือคำแนะนำที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. การลงทุน encryption / DLP / access control ที่เข้มงวด — ไม่มีค่า ถ้าคุณไม่รู้ว่าข้อมูลชุดไหนคุณต้องการปกป้องระดับไหน. ทำ classification ก่อน → ใช้เป็นเกณฑ์ลงทุน control ตามค่า

ขั้นตอน implementation ที่ผมแนะนำสำหรับบริษัทไทยขนาดกลาง:

1. ขั้นที่ 1 (เดือน 1-2) — กำหนด 4-Tier + Definition — Public / Internal / Confidential / Restricted + เกณฑ์ + ตัวอย่างที่ทุกคนเข้าใจ
2. ขั้นที่ 2 (เดือน 2-3) — Map data ที่สำคัญที่สุด 10-20 ชุด — แต่ละชุดเป็น tier ไหน + ใครเป็น Owner / Custodian / Steward
3. ขั้นที่ 3 (เดือน 3-6) — Implement Sensitivity Labels — ใช้ Microsoft Purview / Google Workspace / Adobe — ติด label อัตโนมัติในเครื่องมือที่บริษัทใช้
4. ขั้นที่ 4 (เดือน 6-12) — Lifecycle policy — retention + secure disposal + vendor management สำหรับ hardware ที่เลิกใช้

ทำตามนี้ — บริษัทคุณจะมี data governance ที่เทียบเคียงกับ Fortune 500 — โดยที่ลงทุนไม่ถึง 1% ของ revenue

ข้อสอง — Secure Disposal คือ control ที่ราคาถูกที่สุด แต่ป้องกัน penalty หนักที่สุด

เคส Morgan Stanley 2020 = บทเรียนตลอดกาล. $35M penalty ไม่ได้เกิดจาก breach โดยตรง — แต่เกิดจากการทำลายข้อมูลผิดวิธี

ลองทำ exercise ในบริษัทคุณ — ถามทีม IT 3 ข้อ:

1. HDD ของเครื่องที่เลิกใช้ — ทำลายอย่างไร?
2. smartphone ของพนักงานที่ลาออก — มี process ทำลายข้อมูลไหม?
3. ถ้าจ้าง vendor มาทำลาย — มี certificate of destruction ไหม?

ถ้าตอบไม่ได้ทันที = คุณมี Morgan Stanley risk อยู่ในบริษัท. แก้ได้ด้วย policy + vendor management + budget ไม่กี่หมื่นบาทต่อปี — แต่ป้องกันความเสี่ยงระดับสิบล้านบาท