Network Segmentation 5 ความเชื่อผิด และสิ่งที่ควรทำแทน

ลองนึกถึงเครือข่ายสำนักงานที่แล็ปท็อป เครื่องพิมพ์ file server และฐานข้อมูลทุกตัวอยู่ในเครือข่ายใหญ่ก้อนเดียว และคุยกับทุกเครื่องได้หมด ระบบแบบนี้ใช้งานได้และดูแลง่าย แต่ก็หมายความว่าเมื่อแล็ปท็อปเครื่องหนึ่งถูกเจาะ ผู้โจมตีจะไปต่อที่เครื่อง ไหนก็ได้ ในเครือข่ายนั้นครับ

Network segmentation คือคำตอบที่คู่มือด้านความปลอดภัยแทบทุกฉบับแนะนำ แต่ก็เป็นหัวข้อที่มีความเข้าใจแบบครึ่ง ๆ กลาง ๆ อยู่เยอะ โพสต์นี้หยิบความเชื่อผิด ๆ ที่พบบ่อยมาห้าข้อ ตรวจแต่ละข้อกับแนวทางสาธารณะที่อ่านได้ฟรี (ส่วนใหญ่จาก CISA, NIST และ MITRE) แล้วปิดท้ายด้วยวิธีเริ่มต้นแบบใช้งานได้จริง และวิธีดูว่ามันได้ผลหรือไม่ครับ

เริ่มจากนิยามก่อน CISA อธิบาย network segmentation ว่าเป็นการแบ่งเครือข่ายออกเป็นหลายส่วนที่แยกจากกัน เรียกว่า segment โดยจัดกลุ่มทรัพยากรที่เกี่ยวข้องกันไว้ด้วยกัน แต่ละ segment ทำหน้าที่เหมือนเครือข่ายของตัวเอง และใช้เพื่อจำกัดการเข้าถึงอุปกรณ์ ข้อมูล และแอปพลิเคชัน รวมถึงจำกัดการสื่อสารระหว่างเครือข่าย (CISA, Microsegmentation in Zero Trust, Part One, กรกฎาคม 2568, หัวข้อ 2) คำสำคัญคือ จำกัด เพราะ segment มีประโยชน์ก็ต่อเมื่อมีการกำหนดว่าอะไรผ่านได้และอะไรผ่านไม่ได้ระหว่างกันครับ

 FLAT NETWORK: any host can reach any host                      
                                                 infected  1/36 
                                                                
                                                                
     o────o────o─────────o────o────o─────────o────o────o        
     │    │    │         │    │    │         │    │    │        
     │    │    │         │    │    │         │    │    │        
     ●────o────o─────────o────o────o─────────o────o────o        
     │    │    │         │    │    │         │    │    │        
     │    │    │         │    │    │         │    │    │        
     o────o────o─────────o────o────o─────────o────o────o        
     │    │    │         │    │    │         │    │    │        
     │    │    │         │    │    │         │    │    │        
     o────o────o─────────o────o────o─────────o────o────o        
                                                                
                                                                
                                                                
 ● infected  o host  ┃ policy wall  ╏ gate: tcp/443 only        

Myth 1: "เรามี VLAN แล้ว แปลว่าเราทำ segmentation แล้ว"

Fact: VLAN เป็นแค่ภาชนะ ส่วนตัว segmentation จริง ๆ คือ policy ระหว่างภาชนะเหล่านั้น

VLAN เป็นองค์ประกอบพื้นฐานที่ดี และ CISA ก็ระบุว่า VLAN กับช่วง IP address เป็นวิธีดั้งเดิมที่องค์กรใช้ควบคุม traffic ระหว่างโซน (CISA, ภาพรวมช่วงต้นเอกสาร) แต่ประโยคเดียวกันนั้นยังพูดต่อว่าต้องมีอุปกรณ์หรือบริการที่รับหรือปฏิเสธการเชื่อมต่อตาม rule ด้วย NIST อธิบายแบบเดียวกันว่า segmentation แบบดั้งเดิมสร้าง segment ด้วยสิ่งอย่าง VLAN ID แล้วจึงสร้าง firewall rule เพื่อ block หรือ allow การสื่อสารกับแต่ละ segment (NIST SP 800-215, หัวข้อ 5.1.2)

มีสองสถานการณ์ที่เจอได้ทุกวันซึ่งแสดงว่า rule สำคัญกว่าหมายเลข VLAN:

• Route กันได้โดยไม่มีใครกรอง บน layer 3 switch นั้น VLAN interface (SVI) เชื่อม VLAN เข้ากับ routing engine ของ switch และแค่สร้าง interface พร้อม IP address ให้แต่ละ VLAN ก็ route ระหว่าง VLAN ได้แล้ว (Cisco Nexus 9000 interfaces guide) ถ้าไม่มีใครใส่ access list หรือส่ง traffic นั้นผ่าน firewall ต่อให้มีสิบ VLAN ก็ยังทำตัวเหมือน flat network อยู่ดี
• โซนใหญ่ที่ข้างในเปิดโล่ง firewall มักมีค่า default สำหรับ traffic ที่อยู่ในโซนเดียวกัน บน firewall ของ Palo Alto Networks นั้น default rule ที่ตั้งไว้ล่วงหน้าจะ allow traffic ภายในโซน (intrazone) ทั้งหมด และ deny traffic ข้ามโซน (interzone) ทั้งหมด (Palo Alto Networks, Security Policy Rules) ถ้าแล็ปท็อปผู้ใช้ทุกเครื่องกับ server ทุกตัวอยู่ในโซนเดียวกัน traffic ส่วนใหญ่ที่สำคัญจะไม่ถูก firewall กรองเลย

สิ่งที่ควรทำแทน: สำหรับ segment แต่ละคู่ ให้จดว่า flow ไหนจำเป็นจริง ๆ แล้วตรวจให้แน่ใจว่ามีอะไรบางอย่างบังคับใช้รายการนั้นอยู่ แผนผังที่เต็มไปด้วย VLAN แต่ไม่มี rule คั่นกลาง เป็นแค่แผนที่ ไม่ใช่ control ครับ

Myth 2: "Segmentation เป็นเรื่องของบริษัทใหญ่เท่านั้น"

Fact: segmentation แบบง่ายที่สุดมีอยู่ใน router ของสำนักงานเล็ก ๆ ส่วนใหญ่อยู่แล้ว

แนวทางสำหรับธุรกิจขนาดเล็กของ Federal Trade Commission (FTC) สหรัฐฯ บอกว่า ถ้าต้องมี Wi-Fi ให้แขก อุปกรณ์ส่วนตัวของพนักงาน หรือคนทั่วไป ให้ตั้งเครือข่าย "public" แยกต่างหาก และ Wi-Fi ของแขกหรือลูกค้าต้องแยกออกจากและไม่เชื่อมกับเครือข่ายของธุรกิจ (FTC, Cybersecurity for Small Business) นั่นแหละคือ segmentation โทรศัพท์ของแขกกับ PC ฝ่ายบัญชีไม่ได้อยู่ในเครือข่ายเดียวกันอีกต่อไปครับ

คู่มือความปลอดภัยทั่วไปสำหรับธุรกิจของ FTC สรุปแนวคิดนี้ไว้ในประโยคเดียวว่า ไม่จำเป็นที่คอมพิวเตอร์ทุกเครื่องในระบบต้องสื่อสารกับทุกเครื่องได้ และแนะนำให้เก็บข้อมูลที่อ่อนไหวเป็นพิเศษไว้ในพื้นที่แยกที่ปลอดภัยบนเครือข่าย (FTC, Start with Security, สิงหาคม 2566)

คู่มือ microsegmentation ของ CISA เขียนโดยมีหน่วยงานรัฐบาลกลางสหรัฐฯ เป็นกลุ่มเป้าหมาย แต่ก็ระบุตรง ๆ ว่าองค์กรใดก็นำไปใช้ได้ (CISA, หัวข้อ 1.1)

สิ่งที่ควรทำแทน: เริ่มจากการแยกที่แทบไม่มีต้นทุน แยกแขกออกจากพนักงาน แยกกล้อง เครื่องพิมพ์ และอุปกรณ์อัจฉริยะอื่น ๆ ออกจากแล็ปท็อป และให้เครื่องที่เก็บข้อมูลเงินเดือนหรือข้อมูลลูกค้ามีพื้นที่ของตัวเอง เข้าถึงได้เฉพาะคนและระบบที่จำเป็นเท่านั้นครับ

Myth 3: "Perimeter เราแข็งแรงแล้ว ข้างในไม่ต้องสนใจ"

Fact: ผู้โจมตีวางแผนไว้แล้วว่าจะทำอะไรหลังผ่าน perimeter มาได้ ขั้นตอนนี้มีชื่อเรียกเฉพาะด้วยซ้ำ

MITRE ATT&CK ซึ่งเป็นฐานความรู้สาธารณะเกี่ยวกับพฤติกรรมของผู้โจมตี มี tactic ทั้งหมวดสำหรับเรื่องนี้ คือ Lateral Movement (TA0008) ซึ่งประกอบด้วย technique ที่ผู้โจมตีใช้เพื่อเข้าไปและควบคุมระบบอื่นบนเครือข่าย (MITRE ATT&CK, TA0008) ตัวอย่าง technique ได้แก่ การใช้ remote service อย่าง RDP, SMB admin share, SSH และ WinRM (T1021) การ exploit remote service (T1210) และการย้ายเครื่องมือระหว่างระบบ (T1570)

เอกสาร zero trust ของ NIST พูดถึงโมเดลเดิมไว้ตรง ๆ ว่า perimeter security ได้แสดงให้เห็นแล้วว่าไม่เพียงพอ เพราะเมื่อผู้โจมตีผ่าน perimeter มาได้ การเคลื่อนที่ด้านข้างต่อจากนั้นก็ไม่มีอะไรขวาง (NIST SP 800-207, หัวข้อ 1) คู่มือ ransomware ของ CISA ก็เชื่อมโยงเรื่องนี้ในทางปฏิบัติเช่นกัน ว่า network segmentation ช่วยจำกัดผลกระทบของการบุกรุก และมีไว้เพื่อป้องกันหรือจำกัด lateral movement (CISA, #StopRansomware Guide)

MITRE ยังมี Network Segmentation เป็น mitigation หนึ่ง (M1030) สำหรับ RDP แนะนำให้ block traffic ระหว่าง security zone และสำหรับการ exploit remote service แนะนำให้แบ่ง segment เพื่อให้การเข้าถึงระบบสำคัญเกิดขึ้นผ่านช่องทางที่ควบคุมได้เท่านั้น (MITRE ATT&CK, M1030)

Segmentation ไม่ได้หยุดการติดเชื้อครั้งแรก แต่มันกำหนดว่าการติดเชื้อนั้นจะไปต่อได้ไกลแค่ไหน และเพิ่มจุดที่เราจะสังเกตเห็นมันได้

Myth 4: "Microsegmentation เป็นผลิตภัณฑ์ที่ซื้อมาแล้วก็ไม่ต้องสนใจเรื่องอื่นอีก"

Fact: microsegmentation เป็นแนวทางการออกแบบที่สร้างจากเครื่องมือหลายประเภท และวางซ้อนอยู่บน control อื่น ๆ ไม่ได้มาแทนที่

CISA เรียก microsegmentation ว่าเป็นปรัชญาการออกแบบที่เน้นทำให้ network segment มีขนาดเล็กที่สุด ตัวอย่างที่ CISA ยกคือ เครือข่ายแบบดั้งเดิมอาจเอา server ทุกตัวใน data center ไว้ใน segment เดียว ขณะที่แบบ microsegmentation จะให้ server คุยได้เฉพาะกับ server ที่จำเป็นต่องานของมันเท่านั้น (CISA, หัวข้อ 2.1) คู่มือเครือข่ายองค์กรของ NIST สรุปจุดประสงค์ไว้ในประโยคเดียว คือเพื่อให้มีการแยกส่วนระดับหนึ่งเพื่อป้องกันไม่ให้การโจมตีลุกลาม (NIST SP 800-215, หัวข้อ 5.1)

วิธีบังคับใช้มีหลายแบบ คู่มือของ CISA แบ่งทางเลือกเป็นแบบ network-based (router, SD-WAN, next-generation firewall), endpoint-based (host firewall, SASE agent), container, hypervisor และ cloud-native control และคาดว่าองค์กรส่วนใหญ่จะต้องใช้หลายแบบร่วมกัน (CISA, ตาราง 1) NIST SP 800-207 ก็อธิบายรูปแบบหลักสองแบบเหมือนกัน คือวาง gateway อย่าง NGFW ไว้หน้าทรัพยากรแต่ละตัวหรือกลุ่มเล็ก ๆ หรือใช้ software agent และ firewall บน host เอง (NIST SP 800-207, หัวข้อ 3.1.2)

และมันไม่ได้มาแทนอะไรเลย CISA ระบุว่า microsegmentation ไม่ได้แทนที่ defense-in-depth หรือการจัดการข้อมูล asset configuration และช่องโหว่อย่างเหมาะสม (CISA, หัวข้อ 1.1) การ patch, MFA และ monitoring ยังสำคัญเหมือนเดิม microsegmentation แค่ทำให้เราเล็งใช้ control เหล่านั้นได้แม่นขึ้น เพราะแต่ละ segment เล็กพอที่จะเข้าใจได้ทั้งหมดครับ

Zero trust เข้ามาเกี่ยวตรงไหน

Zero trust กับ microsegmentation มักถูกพูดถึงคู่กันด้วยเหตุผล Zero Trust Maturity Model ของ CISA อธิบายเส้นทางของ network segmentation เป็นสี่ระดับ ตั้งแต่ระดับ traditional ที่ใช้ perimeter ใหญ่หรือ macro-segmentation โดยแทบไม่จำกัดการเข้าถึงภายใน segment ไปจนถึงระดับ optimal ที่มี micro-perimeter ขาเข้าและขาออกกระจายเต็มที่ และมี micro-segmentation อย่างกว้างขวางตาม application profile (CISA Zero Trust Maturity Model v2.0, Networks pillar) ในแบบ zero trust การตัดสินใจว่าจะให้การเชื่อมต่อผ่านหรือไม่ สามารถใช้ข้อมูลมากกว่า IP address ได้ เช่น ผู้ใช้เป็นใคร ใช้อุปกรณ์อะไร และบริบทอื่น ๆ (CISA, หัวข้อ 2.1)

Myth 5: "แบ่ง segment ครั้งเดียวแล้วก็อยู่อย่างนั้นตลอดไป"

Fact: segmentation ค่อย ๆ เพี้ยนไปตามเวลา จึงต้องตรวจและทบทวนเป็นระยะ

แอปพลิเคชันย้ายที่ บริการใหม่ ๆ เกิดขึ้น และบางคนก็เพิ่ม rule "ชั่วคราว" ระหว่างระบบล่ม คู่มือของ CISA บอกว่าการเปลี่ยนไปใช้ microsegmentation ไม่ใช่การเปลี่ยนครั้งเดียวจบ และองค์กรควรประเมิน segmentation เป็นระยะและตรวจสอบประสิทธิภาพเทียบกับภัยคุกคามในปัจจุบัน (CISA, หัวข้อ 4.9)

มาตรฐานบางตัวกำหนดเรื่องนี้เป็นข้อบังคับเลย ใน PCI DSS v4.x (v4.0.1 ออกเมื่อมิถุนายน 2567 โดยไม่มีการเพิ่มหรือตัดข้อกำหนดใด และ v4.0 ถูกยกเลิกเมื่อ 31 ธันวาคม 2567 ตามที่ PCI Security Standards Council ระบุ) ถ้าใช้ segmentation แยก cardholder data environment ออกมา ข้อกำหนด 11.4.5 ให้ทำ penetration test กับ segmentation control อย่างน้อยทุก 12 เดือน และหลังมีการเปลี่ยนแปลง control เหล่านั้นทุกครั้ง เพื่อยืนยันว่า control ทำงานได้และแยก environment นั้นออกจากระบบที่อยู่นอก scope จริง (PCI DSS ข้อ 11.4.5 ตามที่ Microsoft Learn อ้างไว้)

โซน และ policy แบบ default deny ระหว่างโซน

เมื่อเคลียร์ความเชื่อผิด ๆ ไปแล้ว แก่นของเรื่องนี้เรียบง่ายพอจะเขียนลงกระดาษโน้ตแผ่นเดียวครับ

1. จัดกลุ่ม asset เป็นโซนตามหน้าที่และความอ่อนไหว (ผู้ใช้ server ข้อมูล แขก management เป็นต้น)
2. Deny by default ระหว่างโซน
3. Allow เฉพาะ flow ที่ธุรกิจต้องใช้จริง และเก็บ log ไว้

แนวคิด "deny by default" เป็นคำแนะนำเก่าที่ผ่านการพิสูจน์มาแล้ว คู่มือ firewall ของ NIST นิยามว่าคือการ block traffic ขาเข้าและขาออกทั้งหมดที่ firewall policy ไม่ได้อนุญาตไว้อย่างชัดเจน และอธิบายว่าปลอดภัยกว่าการปล่อยทุกอย่างที่ไม่ได้ห้ามไว้ (NIST SP 800-41 Rev. 1)

 zone firewall                    allow list, then deny         
                               ┃                                
 USERS  ■───·───────────·──────┃────·───────────·─── WEB :443   
                               ┃                                
 WEB    ────·───────────·──────┃────·───────────·─── DB :5432   
                               ┃                                
 USERS  ────·───────────·──────┃────·───────────·─── DB :5432   
                               ┃                                
 GUEST  ────·───────────·──────┃────·───────────·─── APP :22    
                               ┃                                
                                                                
  #    from    to     service   action                          
 ────────────────────────────────────────────────────────────── 
  1    USERS   WEB    tcp/443   allow                           
  2    WEB     DB     db port   allow                           
  *    any     any    any       deny (default)                  

ตัวอย่างเล็ก ๆ ของ allow list ระหว่างโซน:

ทุกคู่ที่เหลือจะตกไปที่ default deny ครับ

เริ่มอย่างไร: map, จัดกลุ่ม, แล้วค่อย ๆ บังคับใช้

วิธีที่เร็วที่สุดที่จะทำให้คนเกลียด segmentation คือเปิด policy เข้มงวดตั้งแต่วันแรกแล้วทำระบบเงินเดือนพัง CISA จึงแนะนำให้ทำเป็นระยะ สี่ขั้นตอน และทำซ้ำทีละ candidate (CISA, หัวข้อ 3 และ 4.3):

1. เลือก candidate เลือกแอปพลิเคชัน workflow หรือ environment มาหนึ่งตัว ช่วงแรก CISA แนะนำให้เลือกตัวที่ทำได้ง่าย พอมีประสบการณ์แล้วค่อยให้ความสำคัญกับ asset ที่สำคัญ
2. หา dependency ระบุทุกอย่างที่ candidate คุยด้วย และทุกอย่างที่คุยกับมัน สำหรับระบบที่รันอยู่แล้ว CISA ระบุว่ารายการเริ่มต้นได้จากการติดตามการสื่อสารจริงของมัน และควรตรวจว่ารายการครบถ้วน
3. กำหนด policy เลือก rule ที่ทำให้งานของธุรกิจเดินได้ โดยให้ผู้ใช้มีส่วนร่วม เพื่อให้เข้าใจผลกระทบต่องานของพวกเขา
4. Deploy และตรวจสอบ ทดสอบ policy ก่อน เช่น ใช้ permissive mode ที่แจ้งเตือนเมื่อมีการละเมิด policy เพื่อหา dependency ที่อาจตกหล่น จากนั้นจึงบังคับใช้ โดยมี visibility เพียงพอที่จะยืนยันว่ามันทำงาน

 [1 MAP]──[2 MONITOR]──[3 ENFORCE]                              
                                                                
                                                                
                               ┆                                
 WEB   ■────────────────────────■────────────────── APP :443    
                               ┆                                
                               ┆                                
 APP   ──■────────────────────■──────────────────── DB :5432    
                               ┆                                
                               ┆                                
 USER  ───▪──────────────────▪───────────────────── DB :445     
                               ┆                                
                          no policy yet                         
 ■ planned flow   ▪ unplanned flow   ✓ mapped                   

ขั้นตอน log อย่างเดียวนี่แหละที่ผมจะไม่ข้ามเด็ดขาดครับ CISA ยังแนะนำให้วางแผนทางย้อนกลับสำหรับ policy ที่อัปเดต และให้มี monitoring กับการทดสอบพร้อมก่อนเปลี่ยน (CISA, หัวข้อ 4.5) พูดอีกอย่างคือ ให้มองการบังคับใช้แต่ละขั้นเป็น change หนึ่งที่มี rollback plan ครับ

อุปกรณ์สองกลุ่มต้องคิดเพิ่มเป็นพิเศษ แล็ปท็อปที่ย้ายไปมาระหว่างออฟฟิศกับบ้านอาจต้องใช้ control แบบ agent-based หรือ application-based แทนแบบ network อย่างเดียว ส่วนอุปกรณ์ OT, IoT และ legacy มักลง agent ไม่ได้เลย segmentation แบบ network-based และการจำกัดการเข้าถึงทั้งเข้าและออกจากอุปกรณ์เหล่านี้ให้แคบที่สุดจึงยิ่งสำคัญขึ้น ไม่ใช่น้อยลงครับ (CISA, หัวข้อ 4.6 และ 4.7)

วัดผลว่ามันได้ผลหรือไม่

"เราแบ่ง segment เครือข่ายแล้ว" เป็นแค่คำกล่าวอ้าง ลองทดสอบด้วยวิธีเหล่านี้ครับ

• ลองเส้นทางที่ควรจะล้มเหลว จาก host ในแต่ละโซน ลองเชื่อมต่อไปยังปลายทางที่ policy บอกว่าต้อง deny นี่คือแนวคิดเดียวกับ segmentation test ของ PCI DSS ข้างบน เส้นทางที่ควรถูก deny แต่ดันผ่านได้ คือสิ่งที่มีค่าที่สุดที่คุณจะค้นพบ
• เทียบของจริงกับ allow list ทบทวน flow ที่ข้ามแต่ละขอบเขตจริง ๆ เทียบกับตารางที่เขียนไว้ อะไรที่ไม่อยู่ในรายการ ถ้าไม่ใช่ rule ที่ขาดไป ก็คือปัญหา
• อ่าน deny log deny ที่ถูก log ระหว่างโซนบอกได้ว่ามี dependency ที่ตกหล่น หรือมีอะไรกำลังสำรวจในที่ที่ไม่ควรไป CISA ระบุว่า visibility ที่ดีขึ้นเป็นประโยชน์อย่างหนึ่งของ microsegmentation (CISA, หัวข้อ 1.2) แต่จะมีประโยชน์ก็ต่อเมื่อมีคนดู
• ไล่หา rule กว้าง ๆ rule ที่ใช้ "any" เป็น source, destination หรือ service ระหว่างโซน ค่อย ๆ ทำลายการออกแบบโดยไม่มีใครรู้ตัว ควรทบทวนเป็นประจำ
• คิดแบบ ATT&CK หยิบ technique ใน Lateral Movement (RDP, SMB, SSH, WinRM และเพื่อน ๆ) แล้วถามสำหรับแต่ละโซนว่า ถ้า host หนึ่งในโซนนี้ถูกเจาะ technique ไหนบ้างที่จะไปถึงโซนถัดไปได้

Segmentation ไม่ใช่งานที่หวือหวา ส่วนใหญ่คือ spreadsheet ของ flow, change window ที่วางแผนอย่างระมัดระวัง และการอ่าน log แต่มันเปลี่ยนคำถามหลังเกิดเหตุจาก "เขาไปถึงอะไรบ้าง" เป็น "เขาไปถึงอะไรบ้างใน โซนนั้นโซนเดียว" ซึ่งเป็นคำถามที่ตอบง่ายกว่ามากครับ

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

• CISA, Microsegmentation in Zero Trust, Part One: Introduction and Planning (กรกฎาคม 2568), หน้าหลัก
• CISA, Microsegmentation in Zero Trust, Part One (PDF)
• CISA, Zero Trust Maturity Model v2.0 (เมษายน 2566)
• CISA, #StopRansomware Guide
• NIST SP 800-207, Zero Trust Architecture (สิงหาคม 2563)
• NIST SP 800-215, Guide to a Secure Enterprise Network Landscape (พฤศจิกายน 2565)
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy (กันยายน 2552)
• MITRE ATT&CK, Lateral Movement (TA0008)
• MITRE ATT&CK, Network Segmentation (M1030)
• FTC, Cybersecurity for Small Business
• FTC, Start with Security: A Guide for Business (สิงหาคม 2566)
• Cisco, Nexus 9000 Series NX-OS Interfaces Configuration Guide: Configuring Layer 3 Interfaces
• Palo Alto Networks, Security Policy Rules
• Microsoft Learn, Microsoft Entra ID and PCI-DSS Requirement 11 (อ้างข้อกำหนด PCI DSS v4.0 ข้อ 11.4.5)
• PCI Security Standards Council, Just Published: PCI DSS v4.0.1 (มิถุนายน 2567)