# PCI DSS v4.0.1: การประเมินช่องโหว่, ASV Scan, Pentest และ Segmentation Testing

Locale: `th`

Source: `/th/compliance/pci-dss/`

Summary: มาตรฐานความมั่นคงปลอดภัยสำหรับองค์กรที่จัดเก็บ ประมวลผล ส่งผ่าน หรืออาจส่งผลต่อความปลอดภัยของข้อมูลบัตรชำระเงิน

สารบัญ

1. [ภาพรวม](/th/compliance/pci-dss/#topic-overview)
2. [การวางแผนทดสอบตาม PCI DSS v4.0.1](/th/compliance/pci-dss/#compliance-control-summary)
3. [ขอบเขต CDE และประเภทผู้มีหน้าที่ตาม PCI DSS v4.0.1](/th/compliance/pci-dss/#pci-scope-architecture)
4. [ข้อกำหนด VA ภายใน และ ASV Scan ภายนอก (ข้อ 11.3)](/th/compliance/pci-dss/#pci-va-asv-scanning)
5. [ข้อกำหนดการทดสอบเจาะระบบ (Penetration Testing: ข้อ 11.4)](/th/compliance/pci-dss/#pci-pentest-requirements)
6. [การทดสอบการแบ่งแยกเครือข่าย (Segmentation Testing: ข้อ 11.4.5 & 11.4.6)](/th/compliance/pci-dss/#pci-segmentation-testing)
7. [ตารางเปรียบเทียบ VA, ASV Scan, Pentest และ Segmentation](/th/compliance/pci-dss/#pci-comparison-matrix)
8. [ตารางเปรียบเทียบข้อกำหนด](/th/compliance/pci-dss/#compliance-matrix)
9. [ประเมินความพร้อม](/th/compliance/pci-dss/#compliance-readiness-checklist)
10. [คำถามที่พบบ่อย](/th/compliance/pci-dss/#compliance-faq)
11. [หัวข้อที่เกี่ยวข้อง](/th/compliance/pci-dss/#related-compliance-frameworks)

# PCI DSS v4.0.1: การประเมินช่องโหว่, ASV Scan, Pentest และ Segmentation Testing

มาตรฐานความมั่นคงปลอดภัยสำหรับองค์กรที่จัดเก็บ ประมวลผล ส่งผ่าน หรืออาจส่งผลต่อความปลอดภัยของข้อมูลบัตรชำระเงิน

สรุปภาพรวมข้อกำหนด

กลุ่มเป้าหมายที่บังคับใช้

ผู้ประกอบการ, ธนาคาร, Payment Processor และ E-commerce ที่รับและจัดเก็บบัตรเครดิต

ความถี่ในการทดสอบ

สแกน VA ภายในและ ASV ภายนอกทุกไตรมาส (Req 11.3), Pentest ปีละ 1 ครั้ง (Req 11.4) และทดสอบ Segmentation ทุก 6-12 เดือน (Req 11.4.5/11.4.6)

ขอบเขตการทดสอบ

Cardholder Data Environment (CDE), Connected-to Systems, Payment APIs, Network Perimeter

ความเสี่ยงหากไม่ปฏิบัติตาม

ค่าปรับหรือผลจากการไม่ปฏิบัติตามขึ้นกับหลักเกณฑ์ของเครือข่ายบัตรที่เกี่ยวข้อง ต้องตรวจเงื่อนไขกับเครือข่ายบัตรและธนาคารผู้รับบัตร ไม่ใช่อัตราค่าปรับกลางที่ PCI SSC กำหนด

## การวางแผนทดสอบตาม PCI DSS v4.0.1

จุดเริ่มต้นคือขอบเขต Cardholder Data Environment หรือ CDE และระบบที่อาจส่งผลต่อความปลอดภัยของ CDE ไม่ใช่เฉพาะหน้ารับชำระเงิน

[![PCI DSS 11.4: จากขอบเขต CDE สู่หลักฐานการแก้ไข: กำหนดวิธีทดสอบ, กำหนดขอบเขต, ทดสอบหลายมิติ, ใช้รอบที่กำหนด, แก้ไขและทดสอบซ้ำ, เก็บหลักฐาน](/assets/compliance/guide-pci-dss-compliance-control-summary-th-v1.webp)](/assets/compliance/guide-pci-dss-compliance-control-summary-th-v1.webp)

**PCI DSS 11.4: จากขอบเขต CDE สู่หลักฐานการแก้ไข**

Requirement 11.4 เชื่อม Methodology, CDE Scope, การทดสอบภายในและภายนอก การแก้ไข และ Retest เป็นหลักฐานชุดเดียว

- **กำหนดวิธีทดสอบ** — ใช้แนวทางที่อุตสาหกรรมยอมรับและบันทึก Methodology
- **กำหนดขอบเขต** — ครอบคลุม CDE Perimeter, Critical Systems และการควบคุมที่ใช้ลด Scope
- **ทดสอบหลายมิติ** — ทดสอบภายใน ภายนอก Application Layer, Network Layer และ Segmentation
- **ใช้รอบที่กำหนด** — ทดสอบอย่างน้อยทุก 12 เดือนและหลังการเปลี่ยน Infrastructure หรือ Application ที่มีนัยสำคัญ
- **แก้ไขและทดสอบซ้ำ** — แก้ช่องโหว่ตามความเสี่ยงและทำ Pentest ซ้ำเพื่อยืนยันผล
- **เก็บหลักฐาน** — เก็บผล Pentest และผลการแก้ไขไว้อย่างน้อย 12 เดือน

- จัดทำ Data Flow Diagram และ Asset Inventory เพื่อกำหนดขอบเขต CDE, Connected-to Systems และ Security-Impacting Systems อย่างแม่นยำ
- Requirement 11.3 กำหนดการสแกนช่องโหว่ภายในแบบ Authenticated Scan และการสแกนภายนอกผ่าน PCI SSC ASV ทุกไตรมาส (Quarterly)
- Requirement 11.4 กำหนดการทดสอบเจาะระบบทั้ง Network และ Application Layer ทั้งภายนอกและภายในอย่างน้อยทุก 12 เดือน พร้อม Retesting
- Requirement 11.4.5 และ 11.4.6 กำหนดการทดสอบยืนยันการแบ่งแยกเครือข่าย (Segmentation Verification) ทุก 12 เดือนสำหรับร้านค้า และทุก 6 เดือนสำหรับผู้ให้บริการ

PCI DSS v4.0.1 / CDE SCOPING & GOVERNANCE

## โครงสร้างมาตรฐาน PCI DSS v4.0.1 และการกำหนดขอบเขต CDE

PCI DSS v4.0.1 กำหนดให้องค์กรระบุขอบเขต Cardholder Data Environment (CDE) และระบบทั้งหมดที่เชื่อมต่อหรือส่งผลต่อความมั่นคงปลอดภัยของข้อมูลบัตร ก่อนเริ่มกระบวนการทดสอบทางเทคนิค

[![ผังขอบเขต CDE แสดงระบบข้อมูลบัตร ระบบเชื่อมต่อ ระบบความปลอดภัย และระบบที่ถูกแยกออก](/assets/compliance/guide-pci-dss-scope-architecture-th-v1.webp)](/assets/compliance/guide-pci-dss-scope-architecture-th-v1.webp)

**PCI DSS 4.0.1: การกำหนดขอบเขต CDE และระบบที่เกี่ยวข้อง**

การระบุขอบเขตอย่างถูกต้องเป็นรากฐานของการตรวจประเมิน หากระบบที่เชื่อมต่อกับ CDE ตกหล่น จะทำให้ขอบเขตการทดสอบและการรับรองล้มเหลวทันที

1. **1. ระบุข้อมูลบัตรเป้าหมาย** — จำแนก CHD (PAN, Expiry, Cardholder Name) และ SAD (CVV, PIN Blocks)
2. **2. Cardholder Data Environment (CDE)** — บุคลากร กระบวนการ เซิร์ฟเวอร์ และระบบที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลบัตร
3. **3. Connected-to Systems** — ระบบที่เชื่อมต่อกับ CDE ทั้งทางตรงและทางอ้อม มีเส้นทางเครือข่ายเข้าสู่ CDE ได้
4. **4. Security-Impacting Systems** — ระบบที่ส่งผลต่อความมั่นคงปลอดภัย เช่น Active Directory, Bastion Host, SIEM, Firewall
5. **5. Out-of-Scope Systems** — ระบบภายนอกที่ถูกตัดขาดการเชื่อมต่ออย่างสมบูรณ์ด้วย Segmentation ที่ผ่านการทดสอบ

- กลุ่มผู้มีหน้าที่ตามมาตรฐาน: ครอบคลุมร้านค้า (Merchants), สถาบันการเงินผู้รับบัตรและผู้ออกบัตร (Acquirers/Issuers), ผู้ประมวลผลธุรกรรม (Processors) และผู้ให้บริการ (Third-Party Service Providers - TPSPs) ที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร (Cardholder Data: CHD) หรือข้อมูลการพิสูจน์ตัวตนที่มีความละเอียดอ่อน (Sensitive Authentication Data: SAD)
- ขอบเขตของ CDE: ประกอบด้วยบุคลากร กระบวนการ และเทคโนโลยีที่จัดการข้อมูลบัตร รวมถึง Connected-to Systems (ระบบที่เชื่อมต่อกับ CDE) และ Security-Impacting Systems (ระบบที่ส่งผลต่อความปลอดภัยของ CDE เช่น Active Directory, Bastion Host, SIEM, Firewall)
- เส้นทางการประเมินตามระดับธุรกรรม: แบ่งตามปริมาณธุรกรรม (Levels 1 ถึง 4) ตั้งแต่การทำแบบประเมินตนเอง (Self-Assessment Questionnaire: SAQ A, A-EP, B, C, D) ไปจนถึงการตรวจรับรองหน้างานโดย Qualified Security Assessor (Report on Compliance: ROC)
- ผลบังคับใช้ของข้อกำหนด v4.0.1: ข้อกำหนดใหม่ใน v4.0.1 เช่น Authenticated Scanning (11.3.1.2), Targeted Risk Analysis (11.3.1.1), และ Multi-Tenant Testing Support (11.4.7) มีผลบังคับใช้อย่างสมบูรณ์แล้วตั้งแต่วันที่ 31 มีนาคม 2568

**มุมมองเชิงเทคนิคและการตรวจประเมิน**

การจัดทำ Data Flow Diagram และ Asset Inventory ที่ถูกต้องตรงกับความเป็นจริงเป็นเงื่อนไขสำคัญที่สุด หากตกหล่นระบบที่เชื่อมต่อกับ CDE การตรวจประเมินของ QSA หรือการยื่น SAQ จะถือว่าไม่สอดคล้องกับมาตรฐาน

PCI DSS REQ 11.3 / VULNERABILITY ASSESSMENTS & ASV

## ข้อกำหนด Vulnerability Assessment (VA) ภายใน และ ASV Scan ภายนอก (ข้อ 11.3)

Requirement 11.3 บังคับให้ตรวจหา จัดลำดับความสำคัญ และแก้ไขช่องโหว่ความปลอดภัยทางเทคนิคอย่างต่อเนื่อง โดยแยกเป็น 2 กระบวนการคู่ขนานระหว่างการสแกนระบบภายในและการสแกนจากภายนอกผ่าน ASV

[![ผังสองแทร็ก Internal Authenticated Scan และ External ASV Scan สู่รายงานผ่านเกณฑ์สี่ไตรมาส](/assets/compliance/guide-pci-dss-va-asv-scanning-th-v1.webp)](/assets/compliance/guide-pci-dss-va-asv-scanning-th-v1.webp)

**PCI DSS 11.3: การสแกนช่องโหว่ภายในและ ASV Scan ภายนอก**

Internal VA ต้องใช้ Authenticated Scan เพื่อมองเห็นช่องโหว่จริงภายในระบบ ส่วน External Scan ต้องใช้รายงานทางการจากผู้ให้บริการ ASV เท่านั้น

1. **1. สแกนภายในด้วยสิทธิ์ (11.3.1.2)** — ทำ Internal Authenticated Scan ทุกไตรมาสเพื่อตรวจลึกถึงระดับ OS และ Config
2. **2. แก้ไขช่องโหว่ High / Critical** — อุดช่องโหว่ระดับสูงตามเกณฑ์ข้อ 6.3.1 และจัดการความเสี่ยงต่ำตาม Targeted Risk Analysis (11.3.1.1)
3. **3. Rescan ยืนยันปิดช่องโหว่** — สแกนซ้ำภายในกรอบเวลาที่กำหนดเพื่อยืนยันว่าไม่มีช่องโหว่ตกค้าง
4. **4. สแกนภายนอกผ่าน ASV (11.3.2)** — สแกนระบบ Internet-facing ทุกไตรมาสผ่าน Approved Scanning Vendor ที่รับรองโดย PCI SSC
5. **5. เกณฑ์ Passing Scan รายไตรมาส** — ต้องไม่มีช่องโหว่ CVSS ≥ 4.0 และไม่มีข้อบกพร่อง Automatic Failure ครบทั้ง 4 ไตรมาสต่อปี

- การประเมินช่องโหว่ภายใน (Internal VA: ข้อ 11.3.1): ต้องสแกนช่องโหว่เซิร์ฟเวอร์ อุปกรณ์เครือข่าย และระบบใน CDE อย่างน้อยทุก 3 เดือน (Quarterly) และต้องแก้ไขช่องโหว่ High และ Critical (ตามข้อ 6.3.1) ให้หมด พร้อมทำ Rescan เพื่อยืนยันว่าช่องโหว่ถูกปิดจริง
- ข้อกำหนด Authenticated Scanning (ข้อ 11.3.1.2): การสแกนภายในต้องใช้สิทธิ์ Credentialed Access ที่มีสิทธิ์เพียงพอ (Sufficient Privileges) เพื่อให้เครื่องมือสแกนสามารถเข้าถึงข้อมูลแพตช์และคอนฟิกภายใน OS ได้อย่างแม่นยำ หากมีอุปกรณ์ที่ไม่รองรับ Credentials ต้องทำเอกสารบันทึกเหตุผลและมาตรการชดเชย
- การจัดการช่องโหว่ความเสี่ยงปานกลางและต่ำ (ข้อ 11.3.1.1): ช่องโหว่ที่อยู่นอกเหนือจาก High/Critical ต้องได้รับการแก้ไขตามกรอบเวลาที่ระบุในเอกสาร Targeted Risk Analysis (TRA ตามข้อ 12.3.1)
- การสแกนภายนอกผ่าน Approved Scanning Vendor (ASV Scan: ข้อ 11.3.2): ระบบ Internet-facing และ External IP ทั้งหมดในขอบเขตหรือที่เชื่อมต่อกับ CDE ต้องได้รับการสแกนทุก 3 เดือน โดยหน่วยงานที่ได้รับการรับรองเป็น ASV จาก PCI SSC เท่านั้น
- เกณฑ์การตัดสินผ่านของ ASV (Passing Scan): ผลการสแกนจะผ่านได้เมื่อไม่มีช่องโหว่ที่มีคะแนน CVSS ตั้งแต่ 4.0 ขึ้นไป และไม่มีช่องโหว่กลุ่ม Automatic Failures (เช่น SQL Injection, XSS, Directory Traversal, หรือซอฟต์แวร์ Out-of-support) โดยต้องได้ใบรับรองผลผ่านครบ 4 ไตรมาสต่อปี
- การสแกนหลังการเปลี่ยนแปลงระบบสำคัญ (Significant Change: ข้อ 11.3.1.3 และ 11.3.2.1): ทุกครั้งที่มีการอัปเกรดโครงสร้างพื้นฐาน ปรับคอนฟิกไฟร์วอลล์ หรือติดตั้งซอฟต์แวร์ใหม่ที่มีนัยสำคัญ ต้องทำ Internal VA และ External Scan ซ้ำทันที

**มุมมองเชิงเทคนิคและการตรวจประเมิน**

การทำ Internal VA สามารถดำเนินการโดยบุคลากรภายในที่มีความรู้และมีความเป็นอิสระทางองค์กร หรือผู้ให้บริการภายนอก แต่ External Scan ตามข้อ 11.3.2 บังคับว่าต้องใช้เครื่องมือและรายงานจาก PCI SSC Approved Scanning Vendor (ASV) เท่านั้น ห้ามใช้ผลสแกนจากเครื่องมือทั่วไปโดยไม่มีการรับรอง ASV

PCI DSS REQ 11.4 / PENETRATION TESTING

## ข้อกำหนดการทดสอบเจาะระบบ (Penetration Testing: ข้อ 11.4)

Requirement 11.4 กำหนดให้ทำ Penetration Testing เพื่อจำลองการโจมตีเชิงรุก พิสูจน์ความสามารถในการเจาะผ่านระบบ และยืนยันว่าการควบคุมความปลอดภัยของ CDE ป้องกันการบุกรุกได้จริง

[![วงจร Pentest ห้าขั้นตอนจากระเบียบวิธีและการทดสอบ CDE ถึงการแก้ไข Retest และเก็บหลักฐาน](/assets/compliance/guide-pci-dss-pentest-requirements-th-v1.webp)](/assets/compliance/guide-pci-dss-pentest-requirements-th-v1.webp)

**PCI DSS 11.4: วงจรการทดสอบเจาะระบบ CDE เชิงลึก**

Pentest ต้องดำเนินการโดยผู้ทดสอบที่มีความเป็นอิสระทางองค์กร และต้องทำการ Retest เพื่อยืนยันว่าช่องโหว่ที่โจมตีได้ถูกปิดสนิทก่อนออกรายงานฉบับสมบูรณ์

1. **1. ระเบียบวิธีและ Use Case (11.4.1)** — อิงมาตรฐานสากล (NIST/OWASP/PTES) พร้อมนำประวัติภัยคุกคาม 12 เดือนมาร่วมออกแบบ
2. **2. ทดสอบภายนอกและภายใน (11.4.2 & 11.4.3)** — จำลองการโจมตี Perimeter และ Internal Attack เข้าสู่ CDE อย่างน้อยปีละ 1 ครั้ง
3. **3. ครอบคลุม Network & Application** — ทดสอบทั้งโครงสร้างพื้นฐานเครือข่าย และ Web Application/API ตามหมวดความเสี่ยงข้อ 6.2.4
4. **4. แก้ไขและ Retesting (11.4.4)** — อุดช่องโหว่ที่โจมตีได้จริง (Exploitable) และทำการทดสอบเจาะระบบซ้ำเพื่อยืนยันผล
5. **5. เก็บหลักฐาน 12 เดือน** — เก็บรวบรวมรายงานผล รายละเอียดการแก้ไข และหลักฐาน Retest เพื่อแสดงต่อผู้ตรวจประเมิน QSA

- ระเบียบวิธีทดสอบมาตรฐานสากล (Methodology: ข้อ 11.4.1): ต้องมีเอกสารและปฏิบัติตามแนวทางการทดสอบที่ยอมรับในอุตสาหกรรม (เช่น NIST SP 800-115, OWASP WSTG, PTES) ครอบคลุมทั้งแนวราบและแนวดิ่ง
- รอบการทดสอบภายนอกและภายใน (External & Internal Pentest: ข้อ 11.4.2 & 11.4.3): ต้องทดสอบทั้งจากภายนอกเครือข่าย (External Perimeter) และจากภายในเครือข่าย (Internal Network เข้าสู่ CDE และภายใน CDE) อย่างน้อยปีละ 1 ครั้ง และหลังการเปลี่ยนแปลงระบบสำคัญ
- ครอบคลุม Network และ Application Layer: ทดสอบระบบเครือข่าย อุปกรณ์ไฟร์วอลล์ สวิตช์ ระบบปฏิบัติการ และเว็บแอปพลิเคชัน/API ที่จัดการธุรกรรมชำระเงิน ครอบคลุมช่องโหว่ตามข้อ 6.2.4 (Injection, Broken Access Control, Authentication Flaws ฯลฯ)
- การวิเคราะห์ประวัติภัยคุกคามรอบ 12 เดือน: แผนการทดสอบต้องนำข้อมูลภัยคุกคามและช่องโหว่ที่เกิดขึ้นจริงกับองค์กรหรืออุตสาหกรรมในช่วง 12 เดือนที่ผ่านมามาร่วมออกแบบ Use Case การทดสอบ
- การแก้ไขและการ Retest ยืนยันปิดช่องโหว่ (ข้อ 11.4.4): ช่องโหว่ที่สามารถใช้โจมตีได้จริง (Exploitable Vulnerabilities) ต้องได้รับการแก้ไข และต้องทำการทดสอบเจาะระบบซ้ำ (Retest) เพื่อยืนยันว่าการแก้ไขได้ผลจริงก่อนปิดรายงาน
- การเก็บรักษาหลักฐานไม่น้อยกว่า 12 เดือน: ต้องเก็บรายงานผลการทดสอบเจาะระบบ แผนปรับปรุงแก้ไข และหลักฐาน Retest ไว้อย่างน้อย 12 เดือน เพื่อแสดงต่อ QSA ในรอบการตรวจประเมิน
- ข้อกำหนดสำหรับ Multi-Tenant Service Providers (ข้อ 11.4.7): ผู้ให้บริการคลาวด์และโฮสติ้งที่มีลูกค้าหลายรายร่วมใช้ทรัพยากร ต้องสนับสนุนกระบวนการทดสอบ External Pentest ของลูกค้า (มีผลบังคับใช้แล้วตั้งแต่วันที่ 31 มีนาคม 2568)

**มุมมองเชิงเทคนิคและการตรวจประเมิน**

ผู้ทดสอบเจาะระบบต้องมีความเป็นอิสระทางองค์กร (Organizational Independence) จากผู้ดูแลระบบและทีมนักพัฒนา แม้ไม่จำเป็นต้องถือใบรับรอง QSA หรือ ASV แต่ต้องมีคุณสมบัติและประสบการณ์ที่พิสูจน์ได้ เช่น OSCP, GPEN, หรือ CREST

PCI DSS REQ 11.4.5 / 11.4.6 / SEGMENTATION VERIFICATION

## การทดสอบการแบ่งแยกเครือข่าย (Segmentation Verification Testing: ข้อ 11.4.5 & 11.4.6)

หากองค์กรใช้ Network Segmentation เพื่อลดขอบเขตการกำกับดูแล CDE มาตรฐานบังคับให้ต้องทดสอบเจาะระบบเพื่อยืนยันว่าระบบภายนอกขอบเขตไม่สามารถเชื่อมต่อเข้ามายัง CDE ได้จริง

[![ผังส่ง Packet Probes จากเครือข่ายนอกขอบเขตถึงไฟร์วอลล์ CDE และถูกบล็อก พร้อมรอบทดสอบ](/assets/compliance/guide-pci-dss-segmentation-testing-th-v1.webp)](/assets/compliance/guide-pci-dss-segmentation-testing-th-v1.webp)

**PCI DSS 11.4.5/11.4.6: การทดสอบยืนยันการตัดแยกโซน CDE**

การตรวจ Segmentation ต้องพิสูจน์ด้วยการส่งข้อมูลจริงจากภายนอกขอบเขต CDE ห้ามอิงเพียงเอกสารหรือกฎไฟร์วอลล์บนกระดาษโดยเด็ดขาด

1. **1. ระบุจุดตัดแยกทุกรูปแบบ** — ตรวจสอบไฟร์วอลล์, Router ACLs, VLANs, และ Microsegmentation ระหว่าง Out-of-Scope กับ CDE
2. **2. ส่ง Packet Probing จากภายนอก** — ยิง Port Scan และ Packet Probes จากเครือข่ายภายนอก (Corporate LAN, Wi-Fi, Dev) มุ่งสู่ CDE
3. **3. พิสูจน์ Zero Ingress / Egress** — ยืนยันว่าไม่มีพอร์ตหรือเส้นทางใดที่ยอมรับการเชื่อมต่อที่ไม่ได้รับอนุญาตเข้าสู่ CDE
4. **4. รอบความถี่ตามประเภทองค์กร** — ร้านค้า (Merchants) ทดสอบทุก 12 เดือน ส่วนผู้ให้บริการ (Service Providers) ทดสอบทุก 6 เดือน
5. **5. การรับมือ Segmentation Failure** — หากพบพอร์ตเปิด ระบบนั้นอาจต้องรวมในขอบเขต CDE ต้องแก้ไขไฟร์วอลล์และ Retest จนผ่าน

- หลักการทดสอบ Segmentation: ผู้ทดสอบจะส่งสัญญาณและสแกนพอร์ต (Port Scanning / Probing) จากเครือข่ายภายนอกขอบเขต CDE (เช่น Corporate LAN, Guest Wi-Fi, สาขา หรือระบบทดสอบ) ยิงตรงมายัง CDE เพื่อยืนยันว่าไม่มีการเปิดช่องทางรับส่งข้อมูลที่ไม่ได้รับอนุญาต
- ครอบคลุมทุกเทคโนโลยีการแบ่งแยก: ต้องทดสอบกลไกควบคุมการแยกส่วนทุกรูปแบบที่มีการใช้งานจริง เช่น ไฟร์วอลล์, Router ACLs, VLANs, Microsegmentation, และ Virtual Switch / Hypervisor Isolation
- รอบการทดสอบสำหรับร้านค้าและองค์กรทั่วไป (Merchants: ข้อ 11.4.5): ต้องทดสอบประสิทธิผลการแบ่งแยกเครือข่ายอย่างน้อยปีละ 1 ครั้ง และทุกครั้งที่มีการเปลี่ยนแปลงกลไกหรือโครงสร้างการแบ่งแยกเครือข่าย
- รอบการทดสอบสำหรับผู้ให้บริการ (Service Providers: ข้อ 11.4.6): สำหรับ Service Provider มาตรฐานกำหนดให้ต้องทดสอบ Segmentation อย่างน้อยทุก 6 เดือน (Semi-Annually) และทุกครั้งที่มีการเปลี่ยนแปลงกลไกแบ่งแยกเครือข่าย
- การแยกส่วนระบบตามระดับความปลอดภัย (ข้อ 2.2.3): ต้องทดสอบยืนยันว่าระบบที่มีฟังก์ชันหรือระดับความเสี่ยงต่างกันได้รับการแยกส่วนอย่างเด็ดขาด ไม่สามารถใช้เป็นจุดก้าวกระโดด (Lateral Movement) เข้าสู่ CDE ได้
- ผลของการเกิด Segmentation Failure: หากพบว่าระบบนอกขอบเขตสามารถเชื่อมต่อเข้าสู่ CDE ได้ ระบบนั้นจะตกเข้ามาเป็นขอบเขต CDE ทันที ซึ่งส่งผลกระทบอย่างรุนแรงต่อการตรวจรับรอง จนกว่าจะแก้ไขกฎไฟร์วอลล์และ Retest สำเร็จ

**มุมมองเชิงเทคนิคและการตรวจประเมิน**

การทดสอบ Segmentation ไม่ใช่การตรวจดูเอกสารหรือกฎไฟร์วอลล์บนหน้าจอ แต่เป็นการส่ง Traffic จริงจากภายนอกขอบเขตเพื่อพิสูจน์ว่าพอร์ตและโปรโตคอลทั้งหมดถูกบล็อกตามนโยบาย Least Privilege

PCI DSS REQ 11 / TECHNICAL ASSURANCE TAXONOMY

## ตารางเปรียบเทียบความแตกต่างระหว่าง VA, ASV Scan, Pentest และ Segmentation Testing

Requirement 11 กำหนดกลไกการทดสอบความปลอดภัย 4 รูปแบบที่มีเป้าหมาย ขอบเขต ความถี่ และข้อกำหนดผู้ทดสอบแตกต่างกันอย่างชัดเจน

| มิติการประเมิน | ข้อกำหนด | ขอบเขตระบบ (Scope) | ความถี่ในการทดสอบ | คุณสมบัติผู้ทดสอบ | เกณฑ์การผ่านผล (Passing Criteria) |
| --- | --- | --- | --- | --- | --- |
| **Internal Vulnerability Assessment (VA)** | Requirement 11.3.1 / 11.3.1.2 | ระบบ เซิร์ฟเวอร์ และอุปกรณ์เครือข่ายทั้งหมดภายในขอบเขต CDE | อย่างน้อยทุก 3 เดือน (Quarterly) และหลังการเปลี่ยนแปลงระบบสำคัญ | บุคลากรภายในที่มีความเป็นอิสระ หรือผู้เชี่ยวชาญภายนอก (ไม่จำเป็นต้องเป็น ASV หรือ QSA) | แก้ไขช่องโหว่ High และ Critical (ตามข้อ 6.3.1) ให้หมด และทำ Rescan ยืนยัน พร้อมทำ Authenticated Scan ตามข้อ 11.3.1.2 |
| **External Vulnerability Scanning (ASV Scan)** | Requirement 11.3.2 / 11.3.2.1 | ระบบและ IP ภายนอก (Internet-facing) ที่อยู่ในหรือเชื่อมต่อกับ CDE | อย่างน้อยทุก 3 เดือน (Quarterly) และหลังการเปลี่ยนแปลงระบบสำคัญ | PCI SSC Approved Scanning Vendor (ASV) เท่านั้น | ไม่มีช่องโหว่ CVSS ≥ 4.0 และไม่มีช่องโหว่กลุ่ม Automatic Failure โดยต้องได้ Attestation of Scan Compliance ครบ 4 ไตรมาสต่อปี |
| **Penetration Testing (Internal & External)** | Requirement 11.4.1 – 11.4.4 | ขอบเขต CDE Perimeter, Critical Systems, Network และ Application Layer | อย่างน้อยปีละ 1 ครั้ง (Annually) และหลังการเปลี่ยนแปลงระบบสำคัญ | ผู้ทดสอบเจาะระบบที่มีความเป็นอิสระทางองค์กร (ใบรับรองที่แนะนำ: OSCP, GPEN, CREST) | แก้ไขช่องโหว่ที่โจมตีได้ (Exploitable Vulnerabilities) ทั้งหมด และทำ Retest เพื่อยืนยันการปิดช่องโหว่ก่อนปิดรายงาน |
| **CDE Segmentation Verification Testing** | Requirement 11.4.5 & 11.4.6 | กลไกแบ่งแยกเครือข่ายทั้งหมด (Firewall, VLAN, ACL, Microsegmentation) ที่ตัดแยกระบบนอก CDE ออกจาก CDE | ร้านค้า: อย่างน้อยปีละ 1 ครั้ง \| Service Provider: อย่างน้อยทุก 6 เดือน (และหลังเปลี่ยนระบบ) | ผู้ทดสอบเจาะระบบที่มีความเป็นอิสระทางองค์กร (ไม่จำเป็นต้องเป็น ASV หรือ QSA) | พิสูจน์ด้วยการส่ง Packet และ Scan Port จากเครือข่ายนอกขอบเขต แล้วพบว่าไม่สามารถเข้าถึง CDE ได้อย่างเด็ดขาด (Zero Ingress/Egress Unauthorized Access) |

**มุมมองเชิงเทคนิคและการตรวจประเมิน**

ผู้ตรวจประเมิน QSA จะตรวจสอบหลักฐานแยกกันทั้ง 4 รายการ องค์กรไม่สามารถนำผล ASV Scan มาทดแทน Penetration Testing หรือนำรายงาน Pentest มาอ้างอิงแทนการทดสอบ Segmentation โดยเด็ดขาด

## ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย

สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น

| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
| --- | --- | --- | --- |
| **Requirement 11.3.1** | Internal Vulnerability Scanning (Authenticated Scan) | ระบบและเซิร์ฟเวอร์ภายในขอบเขต CDE ทั้งหมด | อย่างน้อยทุก 3 เดือน (Quarterly) และหลังการเปลี่ยนแปลงสำคัญ |
| **Requirement 11.3.2** | External Vulnerability Scanning (ASV Scan) | ระบบ Internet-facing และ External IP ของ CDE | อย่างน้อยทุก 3 เดือน (Quarterly) โดย PCI SSC Approved Scanning Vendor |
| **Requirement 11.4.2 & 11.4.3** | External & Internal Penetration Testing | ขอบเขต CDE Perimeter, Critical Systems, Network และ Application Layer | อย่างน้อยปีละ 1 ครั้ง และหลังการเปลี่ยนแปลงสำคัญ |
| **Requirement 11.4.4** | Remediation and Retesting of Exploitable Flaws | ช่องโหว่ความปลอดภัยที่ค้นพบจากการทำ Pentest | แก้ไขตามระดับความเสี่ยงและทำ Retest ซ้ำจนกว่าจะปิดช่องโหว่ |
| **Requirement 11.4.5** | CDE Segmentation Verification Testing (Merchants) | Network Isolation ระหว่างระบบนอกขอบเขตและ CDE | อย่างน้อยปีละ 1 ครั้ง และหลังเปลี่ยนกลไกการแยกส่วน |
| **Requirement 11.4.6** | CDE Segmentation Verification Testing (Service Providers) | Network Isolation และ Firewall Controls ของ Service Provider | ทุก ๆ 6 เดือน และหลังเปลี่ยนกลไกการแยกส่วน |

### เครื่องมือประเมินความพร้อม

คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น

0%

จัดทำ External Vulnerability Scanning ทุกไตรมาสผ่าน PCI SSC Approved Scanning Vendor (ASV) และผ่านเกณฑ์ Passing Scan (Req 11.3.2)
          
          
            
            จัดทำ Internal Vulnerability Scanning แบบ Authenticated Scan ทุกไตรมาส พร้อมแก้ไขช่องโหว่ High/Critical และทำ Rescan (Req 11.3.1)
          
          
            
            จัดทำ External Penetration Testing สำหรับขอบเขต CDE อย่างน้อยปีละ 1 ครั้ง และหลังการเปลี่ยนแปลงสำคัญ (Req 11.4.3)
          
          
            
            จัดทำ Internal Penetration Testing จากภายในเครือข่ายสู่ขอบเขต CDE อย่างน้อยปีละ 1 ครั้ง และหลังการเปลี่ยนแปลงสำคัญ (Req 11.4.2)
          
          
            
            ดำเนินการทดสอบ CDE Segmentation Verification Testing อย่างน้อยปีละ 1 ครั้ง (และทุก 6 เดือนสำหรับ Service Provider) ตาม Req 11.4.5/11.4.6
          
          
            
            แก้ไขช่องโหว่ที่โจมตีได้ (Exploitable) ทั้งหมด พร้อมจัดทำ Retest ยืนยันการปิดช่องโหว่และเก็บรักษาหลักฐานอย่างน้อย 12 เดือน (Req 11.4.4)

ประเมินความพร้อม

เลือกรายการด้านบนเพื่อประเมินผล

[ปรึกษาผู้เชี่ยวชาญ และขอใบเสนอราคา](/th/#contact)

## คำถามที่พบบ่อย (FAQ)

คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน

### PCI DSS v4.0.1 ข้อ 11.4 กำหนดการทำ Penetration Testing ไว้อย่างไร?

Requirement 11.4 บังคับให้ทำ Penetration Testing ทั้งภายนอก (External) และภายใน (Internal) อย่างน้อยปีละ 1 ครั้ง และทุกครั้งที่มีการเปลี่ยนแปลงโครงสร้างพื้นฐานหรือแอปพลิเคชันอย่างมีนัยสำคัญ ครอบคลุมทั้ง Network และ Application Layer และต้องแก้ไขช่องโหว่ที่โจมตีได้พร้อมทำ Retest ยืนยันผล

### การประเมินช่องโหว่ภายใน (Internal VA: ข้อ 11.3.1) มีข้อกำหนด Authenticated Scan อย่างไร?

ข้อ 11.3.1.2 ใน PCI DSS v4.0.1 (มีผลบังคับใช้อย่างสมบูรณ์ตั้งแต่ 31 มีนาคม 2568) กำหนดให้การสแกนช่องโหว่ภายในต้องใช้สิทธิ์ Credentialed Scan ที่มีสิทธิ์เพียงพอในการตรวจสอบระบบปฏิบัติการและซอฟต์แวร์ภายใน และต้องทำอย่างน้อยทุก 3 เดือน พร้อมแก้ไขช่องโหว่ High และ Critical

### ASV Scan ตามข้อ 11.3.2 คืออะไร และมีเกณฑ์การตัดสินผ่าน (Passing Scan) อย่างไร?

ASV Scan คือการสแกนช่องโหว่ภายนอกผ่านเครือข่ายอินเทอร์เน็ตโดยหน่วยงานที่ได้รับการรับรองจาก PCI SSC (Approved Scanning Vendor) ต้องทำอย่างน้อยทุก 3 เดือน โดยเกณฑ์ผ่านคือต้องไม่มีช่องโหว่ที่ได้คะแนน CVSS ตั้งแต่ 4.0 ขึ้นไป และไม่มีช่องโหว่ประเภท Automatic Failure เช่น SQL Injection หรือ Unsupported Software

### การทดสอบ CDE Segmentation Testing (ข้อ 11.4.5 & 11.4.6) ต้องทำบ่อยแค่ไหน และมีความสำคัญอย่างไรต่อการลด Scope?

หากองค์กรใช้ Network Segmentation เพื่อลดขอบเขต CDE ข้อ 11.4.5 กำหนดให้ร้านค้าและองค์กรทั่วไปต้องทดสอบยืนยันประสิทธิผลของการแยกเครือข่ายอย่างน้อยปีละ 1 ครั้งและหลังเปลี่ยนระบบ ส่วนข้อ 11.4.6 บังคับให้ Service Provider ต้องทดสอบอย่างน้อยทุก 6 เดือนและหลังเปลี่ยนระบบ เพื่อยืนยันว่าระบบนอก CDE ไม่สามารถเข้าถึงข้อมูลบัตรได้จริง

### ความแตกต่างระหว่าง Vulnerability Assessment (VA), ASV Scan และ Penetration Testing คืออะไร?

VA และ ASV Scan (ข้อ 11.3) เป็นการสแกนแบบอัตโนมัติทุกไตรมาสเพื่อค้นหารายการช่องโหว่ที่รู้จัก (Known CVEs) ขณะที่ Penetration Testing (ข้อ 11.4) เป็นการจำลองการโจมตีเชิงรุกโดยผู้เชี่ยวชาญปีละ 1 ครั้ง เพื่อพิสูจน์การเจาะผ่านระบบและการขโมยข้อมูลบัตรจริง ส่วน Segmentation Testing เป็นการทดสอบเจาะระบบเพื่อพิสูจน์ความสมบูรณ์ของการตัดแยกเครือข่าย

## หัวข้อและกฎหมายกำกับดูแลที่เกี่ยวข้อง

- [
                สถาบันการเงินต้องทำ Pentest อะไรบ้างตามหลักเกณฑ์ ธปท.
                
              ](/th/compliance/bank-of-thailand/)
- [
                ISO/IEC 27001:2022 ต้องทำ Penetration Testing ไหม
                
              ](/th/compliance/iso-27001/)
- [
                PDPA กำหนดให้ทำ Penetration Testing หรือไม่
                
              ](/th/compliance/pdpa/)
- [
                สมาชิก NDID ต้องทำ Penetration Testing อะไรบ้าง
                
              ](/th/compliance/ndid/)

เปิดภาพขนาดเต็มเพื่อซูม

## เอกสารต้นทางฉบับทางการ

ดาวน์โหลดมาตรฐาน PCI DSS ฉบับทางการได้ที่คลังเอกสารของ PCI SSC

[ไปยังแหล่งทางการ ](https://www.pcisecuritystandards.org/document_library/)

## ต้องการทำ Pentest ให้สอดคล้องกับข้อกำหนดเหล่านี้?

เล่าขอบเขตระบบและข้อกำหนดที่ต้องปฏิบัติตามให้เราฟัง ทีม STH จะช่วยประเมินแนวทางและจัดทำใบเสนอราคาให้

[ขอใบเสนอราคา Pentest](/th/#contact)

อัปเดตล่าสุด 16 ตุลาคม 2569