OWASP ASVS 5.0: คู่มือเกณฑ์มาตรฐานการตรวจสอบความมั่นคงปลอดภัยแอปพลิเคชัน
คู่มือเชิงเทคนิคฉบับสมบูรณ์สำหรับ OWASP Application Security Verification Standard (ASVS) 5.0 โครงสร้างการตรวจสอบระดับ L1 ถึง L3 ทั้ง 17 หมวดความปลอดภัย และการบูรณาการเข้ากับวงจร Secure SDLC และการทดสอบเจาะระบบ
- กลุ่มเป้าหมายที่บังคับใช้
- ผู้พัฒนาซอฟต์แวร์ สถาปนิกความปลอดภัย วิศวกร DevSecOps และทีมทดสอบเจาะระบบสำหรับเว็บและแอปพลิเคชันคลาวด์
- ความถี่ในการทดสอบ
- ประเมินและทบทวนอย่างต่อเนื่องใน CI/CD ไปป์ไลน์ พร้อมทำ Pentest ประจำปีหรือก่อนการปล่อยระบบเวอร์ชันหลัก (Major Release)
- ขอบเขตการทดสอบ
- ครอบคลุม 17 หมวด V1 ถึง V17 ตั้งแต่สถาปัตยกรรม, การยืนยันตัวตน, สิทธิ์เข้าถึง, เข้ารหัส, โทเค็น, API จนถึง WebRTC
- ความเสี่ยงหากไม่ปฏิบัติตาม
- ช่องโหว่ตรรกะทางธุรกิจ (Business Logic), สิทธิ์รั่วไหล (BOLA/BFLA), การปลอมแปลงโทเค็น และการไม่ผ่านเกณฑ์จัดซื้อจัดจ้างระดับสากล
โครงสร้างระดับการตรวจสอบความปลอดภัย 3 ระดับ (L1, L2, L3)
การจัดระดับการตรวจสอบความมั่นคงปลอดภัยตามระดับความเสี่ยงของแอปพลิเคชัน ตั้งแต่ระดับพื้นฐานไปจนถึงระบบโครงสร้างพื้นฐานสำคัญ
ภาพสรุปเพื่อประกอบการอ่าน โปรดพิจารณาขอบเขตและรายละเอียดในบทความ
- L1: การป้องกันพื้นฐาน — เริ่มจากข้อกำหนดที่สำคัญ
- L2: เพิ่มความครอบคลุม — สะสมข้อกำหนดจาก L1 และ L2
- L3: การป้องกันเชิงลึก — รวมข้อกำหนดที่เกี่ยวข้องทั้งสามระดับ
- ระดับ 1 (Level 1 - Baseline): ระดับพื้นฐานที่จำเป็นสำหรับทุกแอปพลิเคชัน มุ่งเน้นการป้องกันการโจมตีทั่วไปที่พบได้บ่อย มีข้อกำหนด 70 ข้อ (ประมาณ 20% ของมาตรฐาน) สามารถตรวจสอบได้ด้วยวิธี Penetration Testing แบบ Black-box หรือ Gray-box โดยไม่จำเป็นต้องเข้าถึงซอร์สโค้ด
- ระดับ 2 (Level 2 - Standard): ระดับมาตรฐานสำหรับแอปพลิเคชันทางธุรกิจที่มีการประมวลผลข้อมูลส่วนบุคคล (PII) ข้อมูลธุรกรรมทางการเงิน หรือข้อมูลความลับองค์กร ครอบคลุมการป้องกันเชิงลึก (Defense-in-Depth) การวิเคราะห์แบบจำลองภัยคุกคาม และการตรวจทานซอร์สโค้ด (ครอบคลุมข้อกำหนดสะสมประมาณ 70%)
- ระดับ 3 (Level 3 - Advanced): ระดับความเชื่อมั่นสูงสุดสำหรับแอปพลิเคชันโครงสร้างพื้นฐานสำคัญ (CII) ระบบงานด้านความมั่นคง หรือระบบการเงินขนาดใหญ่ บังคับใช้การควบคุมความปลอดภัยแบบหลายชั้น สถาปัตยกรรมแยกส่วนอย่างเข้มงวด และการตรวจสอบครบทั้ง 100% (345 ข้อกำหนด)
- การบันทึกการตัดสินใจด้านความปลอดภัย (Documented Security Decisions): ASVS 5.0 กำหนดให้จัดทำเอกสารการตัดสินใจด้านความมั่นคงปลอดภัยเป็นลายลักษณ์อักษรในส่วนแรกของแต่ละหมวดหลัก เพื่อให้สถาปัตยกรรมสามารถตรวจสอบย้อนหลังได้ในทุกขั้นตอน
สาระสำคัญ 17 หมวดความปลอดภัยและการปรับปรุงใน ASVS 5.0
โครงสร้างหมวดความปลอดภัย V1 ถึง V17 พร้อมหมวดใหม่สำหรับ Self-contained Tokens, OAuth/OIDC และการสื่อสาร WebRTC
ภาพสรุปเพื่อประกอบการอ่าน โปรดพิจารณาขอบเขตและรายละเอียดในบทความ
- V1 — Encoding and Sanitization
- V2 — Validation and Business Logic
- V3 — Web Frontend Security
- V4 — API and Web Service
- V5 — File Handling
- V6 — Authentication
- V7 — Session Management
- V8 — Authorization
- V9 — Self-contained Tokens
- V10 — OAuth and OIDC
- V11 — Cryptography
- V12 — Secure Communication
- V13 — Configuration
- V14 — Data Protection
- V15 — Secure Coding and Architecture
- V16 — Security Logging and Error Handling
- V17 — WebRTC
- หมวดเฉพาะสำหรับ Self-contained Tokens (V9) และ OAuth/OIDC (V10): แยกการควบคุม JWT, PASETO และระบบระบุตัวตนแบบภายนอกออกมาเป็นหมวดอิสระ ควบคุมการตรวจสอบลายเซ็นดิจิทัล ข้อมูล Claims และอายุการใช้งานโทเค็นอย่างรัดกุม
- การควบคุมความปลอดภัย WebRTC (V17): เพิ่มหมวดการตรวจสอบความมั่นคงปลอดภัยสำหรับการสื่อสารแบบ Peer-to-Peer ช่องสัญญาณเสียง วิดีโอ ข้อมูล Data Channel และการบังคับใช้การเข้ารหัส DTLS และ SRTP
- สถาปัตยกรรมและการเขียนโค้ดปลอดภัย (V15): ควบคุมความมั่นคงปลอดภัยในการออกแบบสถาปัตยกรรม กำหนดขอบเขตความเชื่อมั่น (Trust Boundaries) การทำงานแบบ Least Privilege และลดพื้นที่การโจมตี
- การจัดการข้อผิดพลาดและข้อมูลบันทึกความปลอดภัย (V16): ข้อกำหนดการบันทึก Audit Telemetry อย่างปลอดภัย ป้องกันช่องโหว่ Log Injection และไม่บันทึกข้อมูลส่วนบุคคลที่อ่อนไหวหรือรหัสผ่านลงใน Log
การบูรณาการ ASVS เข้าสู่วงจร DevSecOps และการตรวจรับรองซอฟต์แวร์
แนวทางการนำ ASVS 5.0 ไปปรับใช้จริงในการทดสอบเจาะระบบ การตรวจโค้ด และการส่งมอบหลักฐานแก่ผู้ตรวจประเมิน
เครื่องมือช่วยสนับสนุนการตรวจสอบ แต่ต้องมีหลักฐานสำหรับข้อกำหนดที่ประเมิน OWASP ไม่ได้ออกใบรับรองแอปพลิเคชันหรือผู้ประเมิน
- กำหนดขอบเขต — เลือกระดับและข้อกำหนดที่เกี่ยวข้อง
- ใช้เครื่องมือสนับสนุน — ตรวจโค้ดและการตั้งค่า
- ตรวจสอบโดยผู้ทดสอบ — ทดสอบสิทธิ์และตรรกะธุรกิจ
- แก้ไขและรายงาน — ทดสอบซ้ำ บันทึกผลและข้อจำกัด
- การกำหนดระดับเป้าหมายในการพัฒนา (Target Level Scoping): เลือกกำหนดระดับ ASVS (L1, L2 หรือ L3) ในระยะเริ่มต้นโครงการ เพื่อใช้เป็นเกณฑ์ Acceptance Criteria ใน Secure SDLC และการทดสอบระบบ
- การทดสอบแบบไฮบริด (Hybrid Verification Pipeline): ผสานเครื่องมือทดสอบอัตโนมัติ SAST, DAST, SCA ในไปป์ไลน์ CI/CD ร่วมกับการทดสอบเจาะระบบเชิงลึก (Manual Pentest) โดยผู้เชี่ยวชาญอิสระเพื่อตรวจหาช่องโหว่ Business Logic ในหมวด V2 และสิทธิ์การเข้าถึงในหมวด V8
- การจัดเตรียมหลักฐานพร้อมรับการตรวจประเมิน (Audit-Ready Evidence): จัดทำเอกสาร Verification Report ระบุสถานะรายข้อกำหนด พร้อมหลักฐานการทดสอบ (PoC) ผลการทดสอบซ้ำ (Retest) และบันทึกการอนุมัติข้อยกเว้นความเสี่ยง
- การเชื่อมโยงกับมาตรฐานสากล: ผลการประเมินตาม ASVS 5.0 สามารถใช้เป็นหลักฐานทางเทคนิคสนับสนุนข้อกำหนด ISO/IEC 27001 (A.8.29), SOC 2 Type II (CC7.1), PCI DSS v4.0.1 (Req 6 และ 11) และเกณฑ์ความปลอดภัยของ สกมช
ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย
สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น
| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
|---|---|---|---|
| ASVS Level 1 (L1 - Baseline) | การตรวจสอบความมั่นคงปลอดภัยระดับพื้นฐาน (Essential Security) | ป้องกันการโจมตีทั่วไปที่พบบ่อย (70 ข้อกำหนด) ครอบคลุมการตั้งค่า สิทธิ์เข้าถึง และการตรวจสอบอินพุต โดยไม่ต้องเข้าถึงโค้ด | ทดสอบก่อนเปิดใช้งานระบบ (Pre-go-live) และอย่างน้อยปีละ 1 ครั้ง |
| ASVS Level 2 (L2 - Standard) | การตรวจสอบความมั่นคงปลอดภัยระดับมาตรฐานสำหรับแอปพลิเคชันธุรกิจ | ครอบคลุมแอปพลิเคชันประมวลผล PII หรือธุรกรรมการเงิน ต้องใช้ Threat Modeling, Code Review และ Defense-in-Depth (~70% ข้อกำหนดสะสม) | ทดสอบในการอัปเดตเวอร์ชันหลัก (Major Release) และทบทวนประจำปี |
| ASVS Level 3 (L3 - Advanced) | การตรวจสอบความมั่นคงปลอดภัยระดับสูงสุดสำหรับโครงสร้างพื้นฐานสำคัญ | ระบบ CII, ระบบธุรกรรมการเงินมูลค่าสูง บังคับใช้การควบคุมความปลอดภัยเชิงลึก สถาปัตยกรรมแยกส่วน และตรวจครบ 100% (345 ข้อกำหนด) | ตรวจประเมินเชิงลึกทุกรอบการปรับปรุงสถาปัตยกรรมและตามรอบความเสี่ยงองค์กร |
| ASVS Chapter V9 & V10 | การตรวจสอบ Self-contained Tokens และ OAuth / OpenID Connect | การตรวจสอบลายเซ็นดิจิทัลของ JWT/PASETO, Token Lifecycles, Scope Verification, Replay Prevention และ Redirect URI | ตรวจประเมินเมื่อมีการออกแบบหรือเปลี่ยนแปลงระบบยืนยันตัวตนและ API Gateway |
เครื่องมือประเมินความพร้อม
คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น
คำถามที่พบบ่อย (FAQ)
คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน
OWASP ASVS 5.0 ต่างจาก OWASP Top 10 อย่างไร?
OWASP Top 10 เป็นเอกสารสร้างความตระหนักรู้ที่สรุปความเสี่ยงที่พบบ่อย 10 อันดับแรก ขณะที่ OWASP ASVS เป็นเกณฑ์มาตรฐานทางเทคนิคฉบับสมบูรณ์ (มี 17 หมวด รวม 345 ข้อกำหนด) ที่ออกแบบมาเพื่อให้นักพัฒนาและผู้ประเมินความปลอดภัยใช้เป็นบรรทัดฐานในการออกแบบ พัฒนา และตรวจรับรองซอฟต์แวร์ได้อย่างละเอียดและเป็นรูปธรรม
องค์กรควรเลือกระดับการตรวจสอบใดระหว่าง L1, L2 และ L3?
ระดับ 1 (L1) เหมาะสำหรับทุกแอปพลิเคชันเป็นระดับมาตรฐานขั้นต่ำสุด และสามารถประเมินได้ด้วย Black-box Pentest ส่วนระดับ 2 (L2) เป็นระดับที่แนะนำสำหรับแอปพลิเคชันธุรกิจส่วนใหญ่ที่มีการประมวลผลข้อมูลส่วนบุคคล (PII) หรือธุรกรรมการเงิน ขณะที่ระดับ 3 (L3) สงวนไว้สำหรับระบบโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) หรือระบบการเงินขนาดใหญ่ที่มีผลกระทบต่อความมั่นคง
การทดสอบตาม ASVS จำเป็นต้องเข้าถึงซอร์สโค้ดหรือไม่?
สำหรับระดับ 1 (L1) สามารถตรวจสอบได้โดยไม่ต้องเข้าถึงซอร์สโค้ด (ผ่านการทดสอบเจาะระบบภายนอกและการทดสอบแบบ Gray-box) แต่สำหรับระดับ 2 (L2) และระดับ 3 (L3) มาตรฐานกำหนดให้อาศัยการเข้าถึงซอร์สโค้ด สถาปัตยกรรมระบบ และการสัมภาษณ์นักพัฒนา (White-box Verification) เพื่อยืนยันว่าการควบคุมความปลอดภัยมีประสิทธิผลจริงในระดับโค้ด
