เจาะลึกความปลอดภัยโมเดล AI 5 ขั้น ตั้งแต่ข้อมูลถึง Monitoring

เวลาคุยเรื่อง AI security ส่วนใหญ่มักเริ่มและจบที่ช่องพิมพ์ prompt เรื่อง prompt injection สำคัญจริง แต่มันเป็นแค่ส่วนที่เรามองเห็น เบื้องหลังหน้าต่างแชตคือโมเดล และโมเดลหนึ่งตัวเป็นหลายอย่างพร้อมกัน คือ dataset ที่มีคนรวบรวมมา งาน training ที่รันบน infrastructure ของใครสักคน ไฟล์ weights ที่ถูก copy ไปมา และ API ที่ตอบทุกคนที่ได้รับอนุญาตให้ถาม แต่ละอย่างถูกโจมตีได้ทั้งนั้น และการป้องกันส่วนใหญ่ก็เป็นสิ่งที่คนทำ network และ security รู้จักอยู่แล้ว เช่น integrity check, access control, logging และการถือว่าของที่ดาวน์โหลดมาเป็นของไม่น่าไว้ใจครับ

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

แผนที่: ใช้ framework อะไรบ้าง

NIST AI RMF AI Risk Management Framework 1.0 ออกเมื่อ 26 มกราคม 2566 (ค.ศ. 2023) และตั้งใจให้ใช้แบบสมัครใจ (voluntary use) แกนของมันมีสี่ function คือ Govern, Map, Measure และ Manage โดย Govern ถูกอธิบายว่าเป็น "cross-cutting function" ที่แทรกอยู่ในอีกสามตัว พูดง่าย ๆ คือ framework นี้ไม่ใช่ checklist แต่เป็นวิธีจัดว่าใครเป็นเจ้าของความเสี่ยงไหนครับ

NIST AI 600-1 หรือ Generative AI Profile เผยแพร่เมื่อกรกฎาคม 2567 ระบุความเสี่ยง 12 ข้อที่เป็นของ generative AI โดยเฉพาะหรือที่ generative AI ทำให้หนักขึ้น มีสองข้อที่เกี่ยวกับโพสต์นี้มากที่สุด

• Information Security ซึ่งรวมถึง attack surface ที่ใหญ่ขึ้น จนอาจกระทบ availability ของระบบ หรือ confidentiality และ integrity ของ training data, code หรือ model weights
• Value Chain and Component Integration ว่าด้วย dataset, pre-trained model และ library จากบุคคลที่สาม ที่อาจได้มาอย่างไม่เหมาะสมหรือไม่ได้ผ่านการตรวจสอบอย่างเหมาะสม

แนวทางร่วม (joint guidelines) เดือนพฤศจิกายน 2566 NCSC ของสหราชอาณาจักรและ CISA เผยแพร่ Guidelines for secure AI system development ซึ่ง CISA ระบุว่ามีหน่วยงานด้าน cybersecurity ร่วมลงนาม 23 แห่ง เนื้อหาแบ่งเป็นสี่ส่วน คือ secure design, secure development, secure deployment และ secure operation and maintenance (PDF) ต่อมาในเดือนพฤษภาคม 2568 AI Security Center ของ NSA, CISA, FBI และพันธมิตร ออกเอกสารที่เน้นเรื่องข้อมูลชื่อ AI Data Security ซึ่งเดินตาม lifecycle หกขั้นของ NIST AI RMF ตั้งแต่ Plan & Design ไปจนถึง Operate & Monitor

แค็ตตาล็อกการโจมตี สำหรับการเรียกชื่อการโจมตี ผมใช้ OWASP Machine Learning Security Top Ten (รายการปี 2023 ซึ่งโครงการระบุว่ายังเป็น draft และแก้ไขบ่อย) และ MITRE ATLAS ซึ่งเป็นฐานความรู้สาธารณะเรื่อง TTP ของผู้โจมตีที่เล็งระบบ AI

ในโพสต์นี้ผมย่อทั้งหมดให้เหลือห้าขั้น คือ data, training, packaging, deployment และ monitoring ครับ

                                        AI MODEL LIFECYCLE      
                                                                
    ·                                                           
     ·                                                          
    ·                                                           
┌────────┐ ┃ ┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐  
│  DATA  │ ┃ │  TRAIN │   │ PACKAGE│   │ DEPLOY │   │ MONITOR│  
│        │─┃>│        │─> │        │─> │        │─> │ ▃▅▅▃▁▁ │  
│ ·::··· │ ┃ │   [M]  │   │        │   │        │   │        │  
└────────┘ ┃ └────────┘   └────────┘   └────────┘   └────────┘  
  sourced     isolated    hash, sign   authz+rate   drift/logs  
           ^ provenance check                                   
                                                                
· clean data   ◆ poisoned sample   [M] model                    

ขั้นที่ 1: Data จุดเริ่มต้นของ poisoning

โมเดลเรียนรู้ตรรกะการตัดสินใจจากข้อมูล เอกสาร AI Data Security พูดไว้ตรง ๆ ว่าผู้โจมตีที่ปรับแต่งข้อมูลได้ ก็ปรับแต่งตรรกะของระบบได้ด้วย ATLAS จัดเรื่องนี้เป็น technique AML.T0020, Training Data Poisoning คือผู้โจมตีอาจเพิ่ม ลบ หรือแก้ไข sample เปลี่ยน label หรือปรับแต่ง feedback และกระบวนการเก็บข้อมูล ส่วน OWASP เรียกว่า ML02:2023 Data Poisoning Attack

ตัวอย่างสองเรื่องจากเอกสาร AI Data Security แสดงว่าเรื่องนี้ทำได้ถูกแค่ไหนครับ

• Split-view poisoning dataset ขนาด web-scale ที่ผ่านการคัดสรรมักเป็นรายการลิงก์ เมื่อ domain ในรายการหมดอายุ ใครที่ซื้อ domain นั้นไปก็คุมได้ว่าลิงก์จะส่งอะไรออกมา เอกสารบอกว่าการคุมได้มากพอจะ poison ได้ผลอาจใช้เงินราว 1,000 USD และบางกรณีแค่ 60 USD (ยกตัวอย่าง COYO-700M)
• Frontrunning poisoning Wikipedia ทำ snapshot เดือนละสองครั้งในเวลาที่รู้ล่วงหน้า ผู้โจมตีจึงจับจังหวะแก้หน้าให้ลงก่อน snapshot ก่อนจะมีใครแก้กลับ เอกสารอ้างการวิเคราะห์ของภาคอุตสาหกรรมว่าอาจ poison Wikipedia ได้มากถึง 6.5% ด้วยวิธีนี้

Checklist ขั้น data (ทั้งหมดจากเอกสารเดียวกัน)

• ใช้ข้อมูลจากแหล่งที่เชื่อถือได้เท่าที่ทำได้ และ track provenance ว่าแต่ละ record มาจากไหน ผ่านเส้นทางใดมาบ้าง
• เก็บ provenance ไว้ใน database ที่ sign ด้วย cryptography และเป็นแบบ append-only เพื่อไม่ให้ใครคนเดียวแก้ประวัติได้โดยไม่มีร่องรอย
• hash dataset และ ตรวจ hash ตอนดาวน์โหลด อะไรที่ไม่ผ่านให้ทิ้ง
• sign ข้อมูลต้นฉบับและทุก revision ที่ตามมา โดยให้คนที่แก้เป็นคน sign เอกสารแนะนำ digital signature มาตรฐานที่ทนต่อ quantum (quantum-resistant)
• สำหรับข้อมูล web-scale ใช้เฉพาะ snapshot ที่ผ่านการตรวจโดยฝ่ายที่เชื่อถือได้

ขั้นที่ 2: Training ที่ที่ของมีค่าถูกสร้างขึ้น

Training คือขั้นที่ข้อมูลกลายเป็น weights สภาพแวดล้อมของ training จึงถือทั้งสองอย่างไว้ แนวทางของ NCSC ขอให้ใช้ access control กับ API, model และ data รวมถึง training และ processing pipeline และแยก environment ที่เก็บ code หรือข้อมูลอ่อนไหวออกจากกัน แนวคิดเดียวกับ management network คือที่ที่สร้างของมีค่าไม่ควรเข้าถึงได้จากทุกที่ครับ

แนวทางเดียวกันยังขยายความหมายของคำว่า asset ให้กว้างขึ้น model, data (รวม user feedback), prompt, software, เอกสาร, log และผลการประเมิน นับเป็น asset ทั้งหมด และ ให้ถือว่า log เป็นข้อมูลอ่อนไหว เราควรรู้ว่า asset แต่ละชิ้นอยู่ที่ไหน และกู้คืนกลับไปสู่สถานะที่รู้ว่าดีได้ครับ

การ fine-tune โมเดลที่เราไม่ได้ train เองก็มีความเสี่ยงของมัน OWASP มี ML07 Transfer Learning Attack คือการ train โมเดลกับงานหนึ่งแล้ว fine-tune กับอีกงานเพื่อให้มันทำงานผิดเพี้ยน และ ML10 Model Poisoning คือผู้โจมตีแก้ parameter ของโมเดลโดยตรง ส่วน NIST AI 600-1 แนะนำให้ตรวจว่าการ fine-tune ไม่ได้ทำให้ safety และ security control เสียไป (action MS-2.7-008)

Checklist ขั้น training

• training pipeline, data store และ weights อยู่หลัง access control ใน environment ที่แยกออกมา
• ทุก model, dataset และ system prompt มีเอกสาร ระบุแหล่งที่มาของ training data, ขอบเขตการใช้งานและข้อจำกัด, guardrail, hash หรือ signature และระยะเวลาเก็บรักษา NCSC แนะนำ model card, data card และ SBOM เป็นรูปแบบที่ใช้ได้
• ทำ red team กับผลลัพธ์ action MS-2.7-007 ของ NIST AI 600-1 ระบุการโจมตี ML ที่ควรทดสอบ เช่น data poisoning, membership inference และ model extraction

ขั้นที่ 3: Packaging และ supply chain ของโมเดล

ส่วนนี้มักทำให้คนที่มาจากสาย IT แบบดั้งเดิมแปลกใจ คือ ไฟล์โมเดลอาจเป็น code ได้ ครับ

ไฟล์โมเดลจำนวนมากเป็น Python pickle Hugging Face ระบุว่า pickle เป็น format เริ่มต้นของ PyTorch model weights คำเตือนในเอกสาร Python พูดตรงมาก ว่า module pickle "is not secure" และข้อมูล pickle ที่ประสงค์ร้ายสามารถรัน code ใด ๆ ก็ได้ระหว่าง unpickling เอกสารยังมีตัวอย่าง pickle เล็ก ๆ ที่เขียนด้วยมือ ซึ่งเรียก os.system ทันทีที่ถูกโหลด

ทำไมเป็นแบบนั้น pickle คือโปรแกรมเล็ก ๆ ที่ประกอบด้วย opcode Hugging Face อธิบายว่าตัวที่อันตรายคือ GLOBAL/STACK_GLOBAL ที่สั่งให้ unpickler import บางอย่าง และ REDUCE ที่เรียกสิ่งนั้นพร้อม argument ถ้า import os.system แล้วเรียกมัน การโหลด "weights" ก็คือการรันคำสั่งครับ

  load: pickle.load(f)                                          
                                                                
  ╭────────────╮                          ┌───────────────────┐ 
                   PROTO 4                │ shell             │ 
  │            │   GLOBAL os system       │                   │ 
  │            │─> STRING '<cmd>'         │ $ <any comman     │ 
  │  model.pkl │   REDUCE (call it)    ─> │                   │ 
  │            │                          │                   │ 
  │ -=++=-·..· │                          │                   │ 
  │            │                          │                   │ 
  └────────────┘                          └───────────────────┘ 
                                                                
  code ran while the file was loading                           
  GLOBAL imports a callable, REDUCE calls it                    

ATLAS มีชื่อเรียกเรื่องนี้ AML.T0010, AI Supply Chain Compromise ครอบคลุม hardware, data, AI software stack หรือตัวโมเดลเอง และ AML.T0011.000, Unsafe AI Artifacts อธิบาย artifact ที่สร้างความเสียหายเมื่อถูกโหลด และในมุมของเหยื่ออาจยังทำงานได้ตามที่คาดไว้ ข้อหลังนี้แหละที่น่าอึดอัด คือโมเดลทำงานปกติดี ขณะที่ payload รันไปเรียบร้อยแล้วครับ ML06 ML Supply Chain Attacks ของ OWASP มีสถานการณ์ที่ผู้โจมตีปลอมเป็นบัญชีขององค์กรบน model hub แล้วเผยแพร่โมเดลอันตรายให้พนักงานดาวน์โหลดไปใช้

สิ่งที่ช่วยได้

• Format ที่ปลอดภัยกว่า safetensors เป็น format สำหรับเก็บ tensor อย่างปลอดภัย (ต่างจาก pickle) ส่วนข้อมูลที่ไม่ใช่ tensor ใช้ JSON ได้ เอกสาร Python ระบุว่าการ deserialize JSON ที่ไม่น่าไว้ใจ ไม่ได้สร้างช่องโหว่ให้รัน code ได้ในตัวมันเอง
• Loader แบบจำกัด Python ให้ override Unpickler.find_class() เพื่ออนุญาตเฉพาะ global ที่ปลอดภัย ส่วน torch.load ของ PyTorch ตอนนี้ใช้ค่าเริ่มต้น weights_only=True ซึ่งจำกัดการโหลดไว้ที่ tensor, primitive type และ dictionary บวก type ที่เรา allow-list ไว้ ค่าเริ่มต้นนี้เปลี่ยนใน PyTorch 2.6 แต่เอกสารก็ยังย้ำว่า "Never load data from an untrusted source."
• Scan แต่อย่าคาดหวังเกินจริง Hugging Face Hub scan ไฟล์ที่ push ขึ้นไปด้วย ClamAV และแสดงรายการ import ที่อยู่ใน pickle แต่บอกชัดว่าวิธีนี้ "not 100% foolproof"

Checklist ขั้น packaging

• ถือว่าโมเดลและ serialised weights จากภายนอกเป็น code จากบุคคลที่สามที่ไม่น่าไว้ใจ NCSC ขอให้มีการ scan และ isolation/sandboxing ตอนนำเข้า
• ใช้ safetensors เป็นหลัก ถ้าจำเป็นต้องโหลด pickle ให้ใช้ loader แบบจำกัด และอย่าปิด weights_only กับไฟล์ที่เราไม่ได้สร้างเอง
• คำนวณและเผยแพร่ hash และ/หรือ signature ของไฟล์โมเดลและ dataset รวมถึง checkpoint ทันทีที่ train เสร็จ และดูแล key ให้ดี
• ตรวจ integrity ของ package ใน ML stack และอัปเดตให้ทันสมัย ตามที่ OWASP ML06 แนะนำ และติดตาม attestation ของ supply chain ด้วย framework อย่าง SLSA

ขั้นที่ 4: Deployment ที่ที่โมเดลเจอคนแปลกหน้า

เมื่อโมเดลถูก serve ออกไป ผู้โจมตีมีสองเส้นทาง และ NCSC อธิบายไว้ทั้งคู่ คือการสร้าง functionality หรือ training data ของโมเดลขึ้นมาใหม่ ทั้งทางตรงด้วยการได้ model weights ไป หรือทางอ้อมด้วยการ query ผ่าน application

เส้นทางตรงคือ security แบบคลาสสิก ปกป้อง weights เหมือน secret ทั่วไปด้วย access control และ encryption รายการ ML05 ของ OWASP ระบุencryption, access control, monitoring และ auditing ไว้ในวิธีป้องกันครับ

เส้นทางอ้อมเป็นเรื่องของ query interface NCSC ขอให้มี control ที่ query interface เพื่อตรวจจับและป้องกันความพยายามเข้าถึง แก้ไข และ exfiltrate ข้อมูลลับ สำหรับ LLM API รายการ LLM10:2025 Unbounded Consumption ของ OWASP ลงรายละเอียดกว่านั้น คือให้ทำ rate limiting และ user quota และจำกัดหรือปิดบัง logit_bias และ logprobs ใน API response รายการเดียวกันยังเตือนว่าผู้โจมตีอาจเก็บ output จาก API ให้มากพอเพื่อจำลองโมเดลบางส่วนหรือสร้าง shadow model

Checklist ขั้น deployment

• เก็บ weights แบบเข้ารหัส และจำกัดการเข้าถึงไว้ที่ระบบที่ serve โมเดลกับคนจำนวนน้อย
• ทุก API caller ต้อง authenticate และตั้ง rate limit กับ quota ต่อ caller ไม่ใช่แค่แบบรวม
• response เปิดเผยเท่าที่ use case ต้องใช้ (ไม่ส่ง probability ดิบ ถ้าไม่จำเป็น)
• มีแผน incident สำหรับกรณีเฉพาะของ AI NCSC คาดหวังให้ผู้รับมือได้รับการฝึกเรื่อง incident ที่เกี่ยวกับ AI และมี offline backup ของทรัพยากรสำคัญ

ขั้นที่ 5: Monitoring และ audit

โมเดลที่ deploy แล้วเปลี่ยนไปได้แม้ไม่มีใครแตะ เพราะโลกที่มันเห็นเปลี่ยนไป เอกสาร AI Data Security เรียกสิ่งนี้ว่า data drift คือคุณสมบัติทางสถิติของ input ค่อย ๆ ห่างออกจาก training data เอกสารระบุว่าประสิทธิภาพที่ลดลงจาก drift เป็นเรื่องปกติที่คาดได้ จึงต้องอัปเดตโมเดลเป็นระยะ หลักง่าย ๆ ในการแยก drift ออกจากการโจมตีที่เอกสารให้ไว้มีประโยชน์มาก คือการเปลี่ยนแปลงที่ช้าและค่อยเป็นค่อยไปน่าจะเป็น drift ส่วนการเปลี่ยนแปลงที่ฉับพลันและรุนแรงในมิติใดมิติหนึ่งหรือหลายมิติ น่าจะเป็นคนที่พยายาม compromise โมเดลครับ

แนวทางของ NCSC ขอให้ monitor สองแบบ (PDF)

• พฤติกรรม (behaviour) วัด output และ performance ให้เห็นการเปลี่ยนแปลงทั้งแบบฉับพลันและค่อยเป็นค่อยไปที่กระทบ security และแยก intrusion ออกจาก drift ตามธรรมชาติได้
• Input เก็บ log ของ inference request, query หรือ prompt ภายใต้กติกาด้าน privacy เพื่อใช้ audit สืบสวน และแก้ไข รวมถึงตรวจจับ input ที่ out-of-distribution หรือเป็น adversarial

แนวทางยังขอให้ถือว่าการอัปเดตใหญ่ของ data, model หรือ prompt เป็นเวอร์ชันใหม่ เพราะเปลี่ยนอย่างไหนก็ทำให้พฤติกรรมเปลี่ยน นี่คือ change management วินัยเดียวกับการอัปเกรด firewall คือทำเวอร์ชัน ทดสอบ และมีทางถอยกลับครับ

Checklist ขั้น monitoring

• มี baseline ของ accuracy, การกระจายของ output และปริมาณ query พร้อม alert เมื่อเปลี่ยนแบบฉับพลัน
• เก็บ inference log ปกป้องแบบข้อมูลอ่อนไหว และค้นได้ระหว่าง incident
• ทบทวนรูปแบบ query ต่อ caller เพื่อหาพฤติกรรมแบบ extraction (ปริมาณสูง input เป็นระบบ)
• การเปลี่ยน model, data และ prompt ผ่าน change control และมีทาง rollback
• มีนโยบายและขั้นตอนสำหรับ monitor ระบบ AI ของบุคคลที่สามที่ deploy อยู่อย่างต่อเนื่อง ตามที่ NIST AI 600-1 แนะนำใน action GV-6.2-004

ต่างจากความเสี่ยงของ LLM application อย่างไร

prompt injection และเรื่องใกล้เคียงอยู่ใน OWASP Top 10 for LLM Applications (2025) ซึ่งผมเขียนไว้ในอีกโพสต์เรื่อง prompt injection รายการนั้นมองที่ application รอบตัวโมเดล เป็นหลัก เช่น prompt injection, sensitive information disclosure, improper output handling, excessive agency, system prompt leakage เป็นต้น ผู้โจมตีคุยกับโมเดลแล้วพยายามทำให้ app ทำงานผิดครับ

โพสต์นี้ว่าด้วย โมเดลในฐานะ asset คือมันถูกสร้างจากอะไร อยู่ในไฟล์แบบไหน และใคร copy มันไปได้ ทั้งสองมุมทับซ้อนกันโดยตั้งใจ รายการ LLM มี LLM03 Supply Chain, LLM04 Data and Model Poisoning และ LLM10 Unbounded Consumption ซึ่งเป็นปัญหาเดียวกันที่มองจากฝั่ง application

ระบบ AI ที่ปลอดภัยต้องมีทั้งสองมุม prompt ที่ harden มาอย่างดีก็ไม่ช่วย ถ้า weights มาจากบัญชี hub ที่ถูก hijack และโมเดลที่ sign แล้วก็ไม่ช่วย ถ้า app ให้สิทธิ์มันลบของได้ครับ

บันทึกส่งท้าย

สิ่งที่ผมสะดุดใจที่สุดระหว่างอ่านเอกสารเหล่านี้ คือ control ส่วนใหญ่คุ้นเคยมาก hash สิ่งที่ดาวน์โหลด sign สิ่งที่เผยแพร่ อย่ารัน code จากคนแปลกหน้า เอาของมีค่าไว้หลัง access control และดูว่าใครแตะมันบ้าง ส่วนที่ใหม่คือการมองให้เห็นว่า dataset, ไฟล์ weights และ inference API แต่ละอย่างก็คือสิ่งที่เราดาวน์โหลด เผยแพร่ รัน และต้องปกป้องเหมือนกันครับ

แหล่งอ้างอิง

• NIST: AI Risk Management Framework
• NIST AIRC: AI RMF Core (Govern, Map, Measure, Manage)
• NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (PDF, July 2024)
• NCSC: Guidelines for secure AI system development
• NCSC: Guidelines for secure AI system development (PDF)
• CISA: CISA and UK NCSC unveil joint guidelines for secure AI system development
• NSA AISC, CISA, FBI and partners: AI Data Security (PDF, May 2025)
• OWASP: Machine Learning Security Top Ten
• OWASP ML02:2023 Data Poisoning Attack
• OWASP ML03:2023 Model Inversion Attack
• OWASP ML05:2023 Model Theft
• OWASP ML07:2023 Transfer Learning Attack
• OWASP ML10:2023 Model Poisoning
• OWASP ML06:2023 ML Supply Chain Attacks
• OWASP Top 10 for LLM Applications 2025
• OWASP LLM10:2025 Unbounded Consumption
• MITRE ATLAS data (techniques AML.T0010, AML.T0011.000, AML.T0020, AML.T0024.002)
• Python documentation: pickle (security warning)
• Hugging Face: Pickle scanning
• Hugging Face: safetensors
• PyTorch: torch.load
• PyTorch dev-discuss: torch.load flipped to weights_only=True by default