ใครต้องปฏิบัติตาม PCI DSS 4.0.1 ในประเทศไทย?

สารบัญ

คำถาม PCI DSS ที่พบบ่อยที่สุดที่ผมได้ยินไม่ใช่ “จะปฏิบัติตามได้อย่างไร?” แต่เป็น “ผมจำเป็นต้องทำด้วยเหรอ?” คำตอบนั้นกว้างกว่าที่องค์กรส่วนใหญ่คาดคิด และผลของการเดาผิด ไม่ใช่เรื่องนามธรรม: มันคือค่าปรับ ค่าธรรมเนียม interchange ที่สูงขึ้น และเมื่อเกิดการละเมิด ก็คือค่าสืบสวนทางนิติวิทยาศาสตร์และความเสียหายต่อแบรนด์ที่วัดเป็นเงินจริง

คำตอบสั้น ๆ #

PCI Data Security Standard ใช้กับ นิติบุคคลใดก็ตามที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลผู้ถือบัตร และนิติบุคคลใดก็ตาม ที่อาจ กระทบความมั่นคงปลอดภัย ของข้อมูลนั้น นี่คือขอบเขตที่กว้างโดยเจตนา และครอบคลุม สามกลุ่มที่คนมักสันนิษฐานว่ายกเว้น

1. ใครก็ตามที่จัดเก็บ ประมวลผล หรือส่งผ่านข้อมูลบัตร #

นี่คือกรณีที่ชัดเจน แต่รวมมากกว่าร้านค้าที่รูดบัตร มันครอบคลุม:

เว็บ e-commerce ที่รับเลขบัตรในฟอร์ม checkout
ERP ที่เก็บ PAN ไว้ “เพื่อการกระทบยอดเท่านั้น”
call centre ที่พิมพ์เลขบัตรลง CRM ขณะสายถูกบันทึก
payment gateway, PSP, acquirer และ issuer ที่สัมผัสข้อมูลทุกวัน

หากข้อมูลบัตรลงมาอยู่ในระบบของคุณ แม้ชั่วครู่ แม้ในหน่วยความจำ คุณก็อยู่ในขอบเขต “เราเก็บแค่วินาทีเดียว” ไม่ใช่ข้อยกเว้น มันคือขอบเขต

2. แม้เมื่อคุณใช้ผู้ประมวลผลบุคคลที่สาม #

ความเข้าใจผิดที่ใหญ่ที่สุดคือ “เราใช้ Stripe / 2C2P / PayPal ดังนั้น PCI DSS ไม่ใช่เรื่องของเรา” การใช้บุคคลที่สาม ย่อ ขอบเขตของคุณ ไม่ได้ กำจัด มัน

ความหมายโดยทั่วไป (สำหรับองค์กรขนาดเล็ก) คือคุณเข้าข่ายแบบฟอร์มการตรวจสอบที่ลดลง: SAQ A หรือ SAQ A-EP แทนที่จะเป็น SAQ D เต็มรูปแบบ เพราะข้อมูลบัตรไม่เคยแตะระบบคุณ แต่คุณยังมีภาระหน้าที่: ดูแลการฝังสคริปต์ให้ถูกต้อง ทำให้หน้า checkout ปราศจากการ skim และบริหารบุคคลที่สามภายใต้ Requirement 12.8 ของมาตรฐาน คุณยังต้องตรวจสอบ เพียงแต่ตรวจสอบน้อยลง

กับดักคือ scope creep เพิ่ม field เฉพาะตัวเดียวที่ดักเลขบัตรฝั่ง server หรือ redirect ผ่าน endpoint ของคุณเอง แล้วคุณก็เลื่อนจาก SAQ A ไปเป็น SAQ D อย่างเงียบ ๆ: ภาระที่ใหญ่ขึ้น อย่างมหาศาล ไม่มีใครบอกคุณเมื่อสิ่งนั้นเกิดขึ้น

3. ธนาคารและทุกคนที่อยู่ต้นน้ำของผู้ถือบัตร #

ธนาคาร acquirer issuer และ payment facilitator ไม่ใช่แค่ “อยู่ในขอบเขต” แต่พวกเขาคือ นิติบุคคลที่ถูกตรวจสอบหนักที่สุดในระบบนิเวศ ในประเทศไทย สถาบันการเงินยังต้องตอบ ธนาคารแห่งประเทศไทย เรื่องแนวปฏิบัติ IT Risk และช่องทางดิจิทัล ซ้อนทับ PCI DSS อีกชั้น สองกรอบนี้ทับซ้อนกันแต่ไม่เหมือนกัน และการตรวจสอบ ธปท. ไม่ทดแทนการตรวจสอบ PCI DSS

ทำไมขอบเขตถึงเป็นทุกอย่าง #

ต้นทุน PCI DSS แปรผันตามขอบเขต ทุกระบบ เครือข่าย และบุคคลภายใน Cardholder Data Environment (CDE) ของคุณอยู่ภายใต้ชุดมาตรการควบคุมเต็มรูปแบบ การย่อ CDE จึงเป็นกิจกรรมการปฏิบัติตาม กฎระเบียบที่ให้ผลตอบแทนสูงสุดที่คุณทำได้:

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

สภาพแวดล้อมที่กำหนดขอบเขตมาดีเปลี่ยนการประเมินหกเดือนหกหลักให้กลายเป็นงานที่จัดการได้ และทำซ้ำได้ ส่วนขอบเขตที่กำหนดมาแย่จะตรวจสอบทั้งบริษัทโดยไม่ได้ความมั่นคงปลอดภัยเพิ่ม

flowchart TD A[ได้รับข้อมูลบัตร] --> B{แตะระบบของคุณไหม?} B -- ไม่ --> C[SAQ A / A-EP: ขอบเขตลดลง] B -- ใช่ --> D[CDE เต็ม: SAQ D / ROC] D --> E{Tokenise และ segment?} E -- ใช่ --> F[ย่อ CDE ก่อนตรวจสอบ] E -- ไม่ --> G[ตรวจสอบเต็มรูปแบบ ทุกระบบ] style F stroke:#10B981,stroke-width:2px style G stroke:#F43F5E,stroke-width:2px

4.0.1 เปลี่ยนเกม #

PCI DSS 4.0.1 ทำให้สิ่งที่ทีมวิศวกรรมที่ดีทำกันอยู่แล้วเป็นทางการ: ปฏิบัติต่อการปฏิบัติตาม กฎระเบียบในฐานะสภาวะที่ต่อเนื่อง ไม่ใช่งานประจำปี ด้วยข้อกำหนดเรื่อง targeted risk analysis customised control approach และการรักษาความมั่นคงปลอดภัยท่ามกลางการเปลี่ยนแปลง ข้อความคือใบรับรอง ณ จุดเวลาเดียวนั้นไม่เพียงพออีกต่อไป มาตรฐานคาดหวังให้มาตรการควบคุม ยังคงเป็นจริงอยู่ระหว่างการประเมิน

ไม่แน่ใจว่าคุณคือ SAQ A, SAQ A-EP หรือ ROC เต็มรูปแบบ? ติดต่อเพื่อรับการตรวจสอบแบบตรงไปตรงมา คุยได้ทาง LINE (@PureSecurity) หรืออีเมล (hello@puresecurity.com)

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

เริ่มด้วย การประเมินช่องว่าง PCI DSS และการลดขอบเขต ก่อนผูกมัดกับการตรวจสอบ: ย่อ CDE ทดสอบ segmentation แล้วค่อยตรวจสอบ เมื่อพร้อมแล้ว การตรวจสอบโดย QSA ของเรา พาคุณผ่าน ROC/AOC เต็มรูปแบบกับผู้ประเมินที่มีสถานะปัจจุบันในกรุงเทพฯ