# มาตรฐานความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ของ สกมช. พ.ศ. 2567 Locale: `th` Source: `/th/compliance/ncsa-cloud-security-standard/` Summary: มาตรฐานความปลอดภัยคลาวด์ สกมช. พ.ศ. 2567 แยกขอบเขตบังคับใช้ หน้าที่ร่วมของผู้ใช้และผู้ให้บริการ และหลักฐานการปฏิบัติตาม สารบัญ 1. [ภาพรวม](/th/compliance/ncsa-cloud-security-standard/#topic-overview) 2. [ขอบเขตและวันเริ่มมีผลบังคับใช้](/th/compliance/ncsa-cloud-security-standard/#applicability-and-date) 3. [ความรับผิดชอบร่วม ข้อตกลงระดับบริการ และเขตอำนาจศาล](/th/compliance/ncsa-cloud-security-standard/#shared-accountability) 4. [กลุ่มมาตรการควบคุมความปลอดภัยทางเทคนิคที่ต้องวางแผนร่วมกัน](/th/compliance/ncsa-cloud-security-standard/#control-areas) 5. [การทำหลักฐานและการรายงาน](/th/compliance/ncsa-cloud-security-standard/#evidence-and-reporting) 6. [ตารางเปรียบเทียบข้อกำหนด](/th/compliance/ncsa-cloud-security-standard/#compliance-matrix) 7. [การสแกนช่องโหว่และ Pentest คลาวด์ (ข้อ 5.2.6.8 และ 5.2.9.2)](/th/compliance/ncsa-cloud-security-standard/#cloud-security-testing) 8. [ประเมินความพร้อม](/th/compliance/ncsa-cloud-security-standard/#compliance-readiness-checklist) 9. [คำถามที่พบบ่อย](/th/compliance/ncsa-cloud-security-standard/#compliance-faq) 10. [หัวข้อที่เกี่ยวข้อง](/th/compliance/ncsa-cloud-security-standard/#related-compliance-frameworks) # มาตรฐานความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ของ สกมช. พ.ศ. 2567 สรุปประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 (Thailand National Cloud Security Framework) โดยแยกขอบเขตการบังคับใช้ หน้าที่ร่วมของผู้ใช้และผู้ให้บริการ และหลักฐานการปฏิบัติตาม สรุปภาพรวมข้อกำหนด กลุ่มเป้าหมายที่บังคับใช้ หน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล หน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) และผู้ให้บริการคลาวด์ที่ให้บริการแก่หน่วยงานดังกล่าว ความถี่ในการทดสอบ ผู้ใช้บริการคลาวด์ระดับผลกระทบต่ำประเมินตนเองอย่างน้อยปีละ 1 ครั้ง ระดับกลางและสูงใช้การรับรองตามรอบ 3 ปีตามภาคผนวกข้อ 1.8 ขอบเขตการทดสอบ บริการคลาวด์สาธารณะประเภท IaaS, PaaS, SaaS การแบ่งหน้าที่ CSC และ CSP และการจัดการช่องโหว่ตามข้อตกลง ความเสี่ยงหากไม่ปฏิบัติตาม ไม่ผ่านเกณฑ์มาตรฐานคลาวด์ สกมช. พ.ศ. 2567 ตามระดับผลกระทบของระบบ ## ขอบเขตและวันเริ่มมีผลบังคับใช้ มาตรฐานมีผลใช้บังคับอย่างเป็นทางการแล้วตั้งแต่วันที่ 10 กันยายน 2569 กำหนดหน้าที่สำหรับหน่วยงานที่ใช้บริการคลาวด์สาธารณะตามกรอบ National Cloud Security Framework [![มาตรฐานคลาวด์ใช้กับใครและเริ่มจากอะไร: หน่วยงานในขอบเขต → ระบบและข้อมูล → ระดับผลกระทบ → รูปแบบบริการ → ข้อกำหนดและหลักฐาน](/assets/compliance/guide-ncsa-cloud-security-standard-applicability-and-date-th-v1.webp)](/assets/compliance/guide-ncsa-cloud-security-standard-applicability-and-date-th-v1.webp) **มาตรฐานคลาวด์ใช้กับใครและเริ่มจากอะไร** เริ่มจากขอบเขตและระดับผลกระทบก่อนเลือกมาตรการหรือหลักฐาน 1. **หน่วยงานในขอบเขต** — ยืนยันสถานะหน่วยงานและบริการคลาวด์ 2. **ระบบและข้อมูล** — ระบุ Workload และข้อมูลที่ใช้บนคลาวด์ 3. **ระดับผลกระทบ** — ประเมิน Criticality และ Sensitivity 4. **รูปแบบบริการ** — ระบุ IaaS, PaaS, SaaS หรือบริการผสม 5. **ข้อกำหนดและหลักฐาน** — เลือกมาตรการ สัญญา และหลักฐานที่เกี่ยวข้อง - คำว่า “หน่วยงาน” ในประกาศครอบคลุมหน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล และหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศตาม พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 - ประกาศกำหนดครอบคลุมบริการ IaaS, PaaS, SaaS และบริการที่รวมบริการเหล่านี้ โดยแยกบทบาทผู้ใช้บริการคลาวด์ (CSC) และผู้ให้บริการคลาวด์ (CSP) ออกจากกันอย่างชัดเจน - การประเมินต้องคำนึงถึงระดับผลกระทบของข้อมูลหรือระบบสารสนเทศ และข้อมูลส่วนบุคคลต้องมีระดับผลกระทบด้านการรักษาความลับอย่างน้อยระดับกลาง ## ความรับผิดชอบร่วม ข้อตกลงระดับบริการ และเขตอำนาจศาล มาตรฐานกำหนดให้ผู้ใช้และผู้ให้บริการตกลงและบันทึกบทบาท หน้าที่ และความรับผิดชอบด้านความมั่นคงปลอดภัยให้เหมาะสมและมีผลผูกพัน [![ใครรับผิดชอบอะไรบนคลาวด์: องค์กรผู้ใช้บริการ (CSC), ความรับผิดชอบร่วม, ผู้ให้บริการคลาวด์ (CSP)](/assets/compliance/cloud-responsibility-th-v1.webp)](/assets/compliance/cloud-responsibility-th-v1.webp) **ใครรับผิดชอบอะไรบนคลาวด์** อย่าใช้คำว่า “ผู้ให้บริการดูแลให้” แทนข้อตกลงที่ชัดเจน ระบุเจ้าของงาน หลักฐานที่ต้องส่ง และวิธีประสานงานเมื่อเกิดเหตุในสัญญาและ SLA - **องค์กรผู้ใช้บริการ (CSC)** — กำหนดความต้องการและควบคุมการใช้บริการ - **ความรับผิดชอบร่วม** — ตกลงบทบาท หลักฐาน และการรับมือเหตุ - **ผู้ให้บริการคลาวด์ (CSP)** — ให้ข้อมูลและรองรับมาตรการตามข้อตกลง ข้อ 5.1.1 ### นโยบายความมั่นคงปลอดภัยคลาวด์ หน่วยงานต้องประกาศใช้**นโยบายความมั่นคงปลอดภัยสารสนเทศสำหรับการประมวลผลบนคลาวด์**เป็นลายลักษณ์อักษร พร้อมจัดฝึกอบรมเฉพาะทางด้านการบริหารความเสี่ยงคลาวด์แก่ผู้บริหารและทีมธุรกิจ ข้อ 5.1.2.1 และข้อ 5.2.9.1 ### ข้อตกลงระดับบริการและบทบาทหน้าที่ ต้องจัดทำและตกลง **Shared Responsibility Matrix** ในสัญญาอย่างชัดเจน ทั้งการป้องกันมัลแวร์ การสำรองข้อมูล การเข้ารหัส การจัดการช่องโหว่ การจัดการเหตุการณ์ และการควบคุมการเข้าถึง ข้อ 5.1.2.2 ### เขตอำนาจศาลและสถานที่จัดเก็บข้อมูล ระบุที่ตั้งศูนย์ข้อมูล (Data Center Region/Zone) ประเทศที่อาจจัดเก็บข้อมูล และประเมินประเด็น**เขตอำนาจศาลทางกฎหมายทับซ้อน (Cross-Border Jurisdictions)** เพื่อรักษาอธิปไตยของข้อมูล ข้อ 5.1.3 ### การขอหลักฐานจากผู้ให้บริการ ผู้ใช้บริการต้อง**ขอหลักฐานการปฏิบัติตามกฎหมายและมาตรฐานสากล** (เช่น ISO/IEC 27001, SOC 2) หรือรายงานผลการประเมินตนเองตามเงื่อนไขที่ สกมช. กำหนด ## กลุ่มมาตรการควบคุมความปลอดภัยทางเทคนิคที่ต้องวางแผนร่วมกัน ข้อกำหนดท้ายประกาศครอบคลุมทั้งกระบวนการของผู้ใช้บริการและความสามารถที่ผู้ให้บริการต้องให้ข้อมูลหรือรองรับตามข้อ 5.2 [![กลุ่มมาตรการคลาวด์ที่ต้องทำร่วมกัน: การกำกับดูแลและบุคลากร, ตัวตน ข้อมูล และการเข้ารหัส, โครงสร้างพื้นฐานและการปฏิบัติการ, ระบบและผู้ให้บริการ, เหตุการณ์และหลักฐาน](/assets/compliance/guide-ncsa-cloud-security-standard-control-areas-th-v1.webp)](/assets/compliance/guide-ncsa-cloud-security-standard-control-areas-th-v1.webp) **กลุ่มมาตรการคลาวด์ที่ต้องทำร่วมกัน** มาตรการคลาวด์ต้องเชื่อม CSC, CSP, สัญญา การปฏิบัติการ และหลักฐาน - **การกำกับดูแลและบุคลากร** — กำหนดนโยบาย บทบาท และความรู้ - **ตัวตน ข้อมูล และการเข้ารหัส** — ควบคุมสิทธิ์และปกป้องข้อมูล - **โครงสร้างพื้นฐานและการปฏิบัติการ** — ตั้งค่า แบ่งเครือข่าย สำรอง และเก็บ Log - **ระบบและผู้ให้บริการ** — ควบคุมวงจรระบบ สัญญา และ Supplier - **เหตุการณ์และหลักฐาน** — ประสานเหตุ ตรวจสอบ และเก็บผล ข้อ 5.2.1 และ 5.2.2 ### การจัดการทรัพย์สินและการควบคุมบัญชีผู้ใช้ จัดทำ**ทะเบียนทรัพย์สินคลาวด์ (Inventory of Assets)** กำหนดขั้นตอน**ติดป้ายระบุประเภทข้อมูลและระดับความลับ (Information Labelling & Tagging)** บนพื้นที่จัดเก็บ เครื่องแม่ข่ายเสมือน และคอนเทนเนอร์ พร้อมขั้นตอนลงทะเบียนและยกเลิกบัญชีผู้ใช้อย่างปลอดภัย ข้อ 5.2.3 ### การพิสูจน์ตัวตนและการจำกัดสิทธิ์ขั้นสูง บังคับใช้ **Multi-Factor Authentication (MFA)** สำหรับผู้ดูแลระบบที่มีสิทธิ์สูง (Privileged Admin) ในทุกช่องทาง กำหนดสิทธิ์ตามหลัก **Least Privilege** ควบคุมโปรแกรมอรรถประโยชน์พิเศษ (Privileged Utilities เช่น Cloud CLI, Terraform, API Key) ไม่ให้ข้ามระบบรักษาความปลอดภัย และกำหนดขั้นตอนล็อกอินที่ปลอดภัย ข้อ 5.2.4 ### การเข้ารหัสข้อมูลและการจัดการกุญแจตลอดวงจรชีวิต กำหนดมาตรการ**เข้ารหัสข้อมูล (Cryptographic Controls)** ทั้งขณะจัดเก็บ (At-Rest) และระหว่างส่งผ่าน (In-Transit) ด้วยอัลกอริทึมมาตรฐาน จัดทำทะเบียนและขั้นตอนปฏิบัติควบคุมกุญแจเข้ารหัส (KMS) พร้อมสัญญาและสถาปัตยกรรมที่**ห้ามผู้ให้บริการเข้าถึงกุญแจโดยปริยาย** (เช่น BYOK, HYOK หรือ Cloud HSM) ข้อ 5.2.5 และ 5.2.7 ### ความปลอดภัยเครือข่ายเสมือนและการแยก Tenant บังคับใช้มาตรการควบคุมที่ตั้งข้อมูล (Data Localization) แบ่งแยกเครือข่ายเสมือน (VPC, Subnet, Security Group, NACL, WAF) และตรวจสอบหลักประกัน**Tenant Isolation** เพื่อป้องกันการเข้าถึงหรือโจมตีข้ามสภาพแวดล้อมใช้งานร่วมกัน ข้อ 5.2.6.1 - 5.2.6.7 ### ความมั่นคงปลอดภัยการปฏิบัติการและการบันทึกเหตุการณ์ กำหนดกระบวนการจัดการการเปลี่ยนแปลง (Change Management) การสำรองข้อมูลและการซักซ้อมกู้คืน (Backup & Recovery) ข้อกำหนดบันทึกเหตุการณ์ (Event Logging) **การปกป้องข้อมูลส่วนบุคคลใน Log (Data Masking)** การตั้งค่าลบ Log อัตโนมัติตามระยะเวลาจัดเก็บ การรวมศูนย์ Log สำหรับผู้ดูแลระบบ และการเทียบเวลามาตรฐาน (NTP) ข้อ 5.2.6.8 ### การจัดการช่องโหว่ทางเทคนิค ผู้ใช้บริการต้องขอข้อมูลจากผู้ให้บริการเกี่ยวกับการจัดการช่องโหว่ที่อาจกระทบบริการคลาวด์ ระบุช่องโหว่ที่ผู้ใช้บริการรับผิดชอบ และกำหนดกระบวนการจัดการให้ชัดเจน ข้อ 5.2.9.2 ### ข้อตกลงด้านความมั่นคงปลอดภัยกับผู้ให้บริการ สัญญาบริการต้องยืนยันบทบาทและความรับผิดชอบ ซึ่งอาจรวมกระบวนการทดสอบความปลอดภัย การจัดการช่องโหว่ และการตรวจสอบการปฏิบัติตาม ข้อนี้ไม่ได้กำหนดรอบ Pentest รายปีแบบตายตัว ข้อ 5.2.10 ### การจัดการเหตุภัยคุกคามและการรายงาน วางแนวทางประสานงานรับมือเหตุการณ์ไซเบอร์ร่วมกับผู้ให้บริการคลาวด์ มีขั้นตอนทบทวนร่วมกันเมื่อเกิด**การละเมิดข้อมูลส่วนบุคคล (Personal Data Breach)** และกำหนดช่องทางแจ้งเหตุและติดตามสถานะเหตุการณ์อย่างเป็นระบบ ## การทำหลักฐานและการรายงาน หน่วยงานต้องเปลี่ยนข้อกำหนดให้เป็นหลักฐานที่ตรวจสอบได้ตั้งแต่ขั้นเลือกบริการและทบทวนตลอดอายุสัญญา [![จากข้อกำหนดสู่หลักฐาน: จัดระดับผลกระทบ → ประเมินการดำเนินงาน → รวบรวมหลักฐาน → ทบทวนโดยผู้บริหาร → รายงานต่อ สกมช.](/assets/compliance/cloud-evidence-th-v1.webp)](/assets/compliance/cloud-evidence-th-v1.webp) **จากข้อกำหนดสู่หลักฐาน** เริ่มจากระบบงานและระดับผลกระทบ แล้วผูกผลประเมินแต่ละข้อกับหลักฐานที่ตรวจสอบได้ ผู้บริหารทบทวนผลก่อนส่งตามช่องทางทางการ 1. **จัดระดับผลกระทบ** — กำหนดเกณฑ์ของแต่ละระบบงาน 2. **ประเมินการดำเนินงาน** — บันทึกสถานะตามแบบประเมิน 3. **รวบรวมหลักฐาน** — นโยบาย สัญญา บันทึก และผลตรวจ 4. **ทบทวนโดยผู้บริหาร** — รับรองผลของหน่วยงาน 5. **รายงานต่อ สกมช.** — ส่งผลตามช่องทางทางการ - เก็บการจัดระดับผลกระทบ ข้อกำหนดที่เลือกใช้ สัญญาหรือการแบ่งความรับผิดชอบ หลักฐานจากผู้ให้บริการ และผลการทบทวนไว้เป็นชุดเดียวกัน - ประกาศกำหนดให้หน่วยงานส่งผลสรุปรายงานการดำเนินการต่อสำนักงานภายใน 30 วันนับจากวันที่ดำเนินการแล้วเสร็จ พร้อมใช้แบบประเมินตนเอง (Cloud Security Standard Self-Assessment for CSC version 1.0) ประกอบการรายงาน - ศึกษาเอกสารเผยแพร่ แผนบูรณาการ พ.ศ. 2569-2573 และกรอบการดำเนินงานเพิ่มเติมได้ที่พอร์ทัลทางการ cloudsecurity.ncsa.or.th ของ สกมช. ## ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น [![บทบาทและหลักฐานบนคลาวด์: การกำกับดูแล, มาตรการควบคุม, หลักฐาน](/assets/compliance/cloud-matrix-th-v1.webp)](/assets/compliance/cloud-matrix-th-v1.webp) **บทบาทและหลักฐานบนคลาวด์** ตารางนี้เป็นตัวอย่างการแบ่งงาน ไม่ใช่การกำหนดเจ้าของทุก Control แบบตายตัว ต้องปรับให้ตรงกับรูปแบบบริการและข้อตกลงจริง - **การกำกับดูแล** — ความต้องการ | บทบาทและ SLA | เงื่อนไขบริการ - **มาตรการควบคุม** — ตั้งค่าและใช้งาน | ประสานเหตุ | ดูแลแพลตฟอร์ม - **หลักฐาน** — ประเมินและจัดเก็บ | ทบทวนร่วมกัน | ส่งข้อมูลบริการ | ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ | | --- | --- | --- | --- | | **ข้อ 5.1 (5.1.1 และ 5.1.2)** | การกำกับดูแลความมั่นคงปลอดภัย นโยบายคลาวด์ และข้อตกลงระดับบริการ (Governance, SLA & Jurisdiction) | นโยบายความมั่นคงปลอดภัยคลาวด์, การประเมินความเสี่ยง, สัญญาบริการคลาวด์ (IaaS, PaaS, SaaS), การจัดทำข้อตกลง SLA และการประเมินเขตอำนาจศาลทับซ้อนและสถานที่จัดเก็บข้อมูล (Cross-Border Data Jurisdiction) | ตามนโยบายและเงื่อนไขบริการ; ข้อที่อ้างไม่กำหนดรอบรายปี | | **ข้อ 5.2.2 และ 5.2.3.2** | การจัดการทรัพย์สินคลาวด์ การติดป้ายระบุข้อมูล และการควบคุมบัญชีผู้ใช้ (Cloud Asset & User Lifecycle) | การจัดทำทะเบียนทรัพย์สินคลาวด์ (Inventory of Assets), การติดป้ายระบุประเภทข้อมูลและระดับชั้นความลับ (Data Labelling & Tagging) บน VM, Storage, Container รวมถึงขั้นตอนการลงทะเบียนและยกเลิกบัญชีผู้ใช้ (Deregistration) | ดูแลทะเบียนและการบ่งชี้ข้อมูลให้ตรงกับการใช้งาน; ไม่ระบุรอบรายปี | | **ข้อ 5.2.3 (5.2.3.1 - 5.2.3.6)** | การพิสูจน์ตัวตนและการจำกัดสิทธิ์ขั้นสูง (Authentication, Least Privilege & Privileged Utilities) | การลงทะเบียนและยกเลิกบัญชี การจัดการสิทธิ์ การเข้าสู่ระบบอย่างมั่นคงปลอดภัย และการควบคุมโปรแกรมอรรถประโยชน์ที่มีสิทธิ์พิเศษ | ตามนโยบายการเข้าถึงและการเปลี่ยนสิทธิ์; ไม่ระบุรอบรายปี | | **ข้อ 5.2.4 (5.2.4.1 - 5.2.4.2)** | การเข้ารหัสข้อมูลและการจัดการกุญแจตลอดวงจรชีวิต (Cryptographic Controls & Key Management) | การเข้ารหัสข้อมูลขณะจัดเก็บ (At-Rest) และระหว่างส่งผ่าน (In-Transit) ด้วยมาตรฐานสากล พร้อมการบริหารจัดการกุญแจเข้ารหัส (KMS), สถาปัตยกรรม BYOK, HYOK หรือ Cloud HSM และการบันทึก Audit Log กุญแจ | ตามนโยบายรหัสลับและวงจรกุญแจ; ไม่ระบุรอบรายปี | | **ข้อ 5.2.5 และ 5.2.7** | ความมั่นคงปลอดภัยเครือข่ายเสมือนและการแบ่งแยก Tenant (Network Security and Tenant Isolation) | การออกแบบเครือข่ายเสมือน (VPC, Subnet, Peering), การตั้งค่า Security Group, NACL, WAF และการตรวจสอบกลไก Tenant Isolation บนสภาพแวดล้อมใช้งานร่วมกัน เพื่อป้องกันการโจมตีข้าม Tenant | เมื่อออกแบบและเปลี่ยนแปลงเครือข่าย; ไม่ระบุรอบรายปี | | **ข้อ 5.2.6 (5.2.6.1 - 5.2.6.7)** | ความมั่นคงปลอดภัยการปฏิบัติการ การสำรองข้อมูล และการบันทึกเหตุการณ์ (Operations Security & Event Logging) | การจัดการการเปลี่ยนแปลง (Change Management), การสำรองข้อมูลและการซักซ้อมกู้คืน (Backup & DR), การเปิดใช้ Event Logging, การปกป้องข้อมูลส่วนบุคคลใน Log (Data Masking) และการเทียบเวลามาตรฐาน (Clock Sync) | ตามขั้นตอนปฏิบัติและข้อตกลงบริการ; ไม่ระบุรอบรายปี | | **ข้อ 5.2.6.8 และ 5.2.9.2** | การจัดการช่องโหว่ทางเทคนิคและข้อตกลงการทดสอบความปลอดภัย | ขอข้อมูลช่องโหว่จากผู้ให้บริการ ระบุหน้าที่ของ CSC และ CSP และระบุบทบาทการทดสอบความปลอดภัยในสัญญาบริการ | ตามกระบวนการที่ตกลงในสัญญา ไม่ใช่รอบ Pentest รายปีแบบตายตัว | | **ข้อ 5.2.9.1 ข้อ 5.2.10 และข้อ 6** | การแบ่งหน้าที่ความรับผิดชอบ การรับมือเหตุการณ์ และการรายงานผลดำเนินการ | ระบุผู้ให้บริการเป็นบุคคลภายนอกในนโยบาย กำหนดหน้าที่รับมือเหตุการณ์ และส่งผลสรุปการดำเนินการต่อสำนักงานตามข้อ 6 | รายงานเหตุตามขั้นตอนในสัญญา และส่งสรุปการดำเนินการภายใน 30 วันนับจากดำเนินการแล้วเสร็จ | STH CLOUD SECURITY TESTING ## แนวทางปฏิบัติการสแกนช่องโหว่และการทดสอบเจาะระบบคลาวด์ (ข้อ 5.2.6.8 และ 5.2.9.2) ภาคผนวกมาตรฐานคลาวด์ สกมช. พ.ศ. 2567 ข้อ 5.2.6.8 กำหนดการขอและแบ่งหน้าที่จัดการช่องโหว่ทางเทคนิค ข้อ 5.2.9.2 กำหนดให้ระบุบทบาทด้านความมั่นคงปลอดภัยในสัญญา ซึ่งอาจรวมการทดสอบความปลอดภัย โดยไม่ได้กำหนดรอบ Pentest รายปีแบบตายตัว [![ใครทำอะไรเมื่อทดสอบคลาวด์: ตกลงขอบเขต → รับข้อมูลจาก CSP → ประเมินและทดสอบ → ปิดผลและทบทวน](/assets/compliance/cloud-testing-th-v1.webp)](/assets/compliance/cloud-testing-th-v1.webp) **ใครทำอะไรเมื่อทดสอบคลาวด์** ก่อนทดสอบต้องรู้ว่าใครมีสิทธิทำอะไร ขอข้อมูลช่องโหว่จากผู้ให้บริการและแบ่งหน้าที่ให้ชัด รอบและขอบเขตการทดสอบต้องอ้างอิงข้อตกลงที่ใช้กับบริการนั้น 1. **ตกลงขอบเขต** — ระบุบทบาทและข้อจำกัดในสัญญา 2. **รับข้อมูลจาก CSP** — ช่องโหว่ บริการที่กระทบ และหลักฐาน 3. **ประเมินและทดสอบ** — ทำตามหน้าที่และสิทธิที่ตกลง 4. **ปิดผลและทบทวน** — Finding การแก้ไข และหลักฐาน ข้อ 5.2.6.8 ### ขอข้อมูลช่องโหว่จาก CSP ระบุช่องโหว่ที่ CSC รับผิดชอบและกำหนดกระบวนการจัดการ ข้อ 5.2.9.2 ### บทบาทในสัญญาบริการ ความถี่และขอบเขตการทดสอบความปลอดภัยให้เป็นไปตามข้อตกลง ข้อ 5.2.7.2 ### แยก Tenant ในเครือข่าย เป็นข้อกำหนดด้านเครือข่าย ไม่ใช่เงื่อนไข RoE ของการทดสอบเจาะระบบ ข้อ 6 ### รายงานภายใน 30 วัน ส่งผลสรุปการดำเนินการต่อสำนักงานเมื่อดำเนินการแล้วเสร็จ ข้อ 5.2.6.8 (ก) ### การสแกนและบริหารจัดการช่องโหว่เชิงเทคนิค (Vulnerability Assessment) ข้อ 5.2.6.8 กำหนดให้ผู้ใช้บริการขอข้อมูลการจัดการช่องโหว่จากผู้ให้บริการ ระบุช่องโหว่ที่ตนรับผิดชอบ และกำหนดกระบวนการจัดการ ไม่ได้กำหนดรายการสแกนรายเดือนหรือ SLA การปิดช่องโหว่เป็นตัวเลขตายตัว #### ขอข้อมูลช่องโหว่จากผู้ให้บริการ Clause 5.2.6.8 ผู้ใช้บริการต้องขอข้อมูลจากผู้ให้บริการเกี่ยวกับการจัดการช่องโหว่ทางเทคนิคที่อาจกระทบบริการคลาวด์ที่ใช้งาน #### แบ่งหน้าที่จัดการช่องโหว่ CSC / CSP ต้องระบุช่องโหว่ทางเทคนิคที่ผู้ใช้บริการจะเป็นผู้รับผิดชอบในการจัดการ และกำหนดกระบวนการจัดการให้ชัดเจน #### ผู้ให้บริการต้องให้ข้อมูล CSP Duty ผู้ให้บริการต้องให้ข้อมูลแก่ผู้ใช้บริการเกี่ยวกับการจัดการช่องโหว่ทางเทคนิคที่อาจส่งผลกระทบต่อบริการคลาวด์ #### แยกสภาพแวดล้อมทดสอบตามข้อ 5.2.6.9 Data Protection หากไม่สามารถหลีกเลี่ยงการใช้ข้อมูลส่วนบุคคลเพื่อการทดสอบได้ ต้องประเมินความเสี่ยงและใช้มาตรการทางเทคนิคและองค์กรเพื่อลดความเสี่ยงให้น้อยที่สุด ข้อ 5.2.9.2 ### การทดสอบเจาะระบบคลาวด์และกฎการทดสอบ (Cloud Pentest & RoE) ข้อ 5.2.9.2 เป็นข้อกำหนดในสัญญาบริการให้ยืนยันบทบาทและความรับผิดชอบด้านความมั่นคงปลอดภัย ซึ่งอาจรวมการทดสอบความปลอดภัย ไม่ใช่ข้อบังคับ Pentest ปีละ 1 ครั้งสำหรับทุกหน่วยงาน #### ระบุบทบาทในสัญญาบริการ Clause 5.2.9.2 ผู้ใช้บริการต้องยืนยันบทบาทและความรับผิดชอบด้านความมั่นคงปลอดภัยสารสนเทศที่เกี่ยวข้องกับบริการคลาวด์ในข้อตกลงการให้บริการ #### หัวข้อที่สัญญาอาจครอบคลุม Contract Topics ข้อ 5.2.9.2 ระบุหัวข้อที่อาจรวมในสัญญา เช่น การป้องกันมัลแวร์ การสำรองข้อมูล การจัดการช่องโหว่ การจัดการเหตุการณ์ การตรวจสอบการปฏิบัติตาม และการทดสอบความปลอดภัย #### การแยก Tenant ตามข้อ 5.2.7.2 Multi-Tenant Isolation ผู้ใช้บริการต้องจัดทำข้อกำหนดการแยกเครือข่ายเพื่อให้เกิดการแยก Tenant ในสภาพแวดล้อมที่ใช้บริการร่วมกัน นี่เป็นข้อกำหนดด้านเครือข่าย ไม่ใช่เงื่อนไข RoE ของการทดสอบเจาะระบบ #### ความถี่การทดสอบ By Agreement ความถี่และขอบเขตการทดสอบความปลอดภัยให้เป็นไปตามที่คู่สัญญาตกลง ไม่ใช่ตัวเลขรายปีที่ภาคผนวกกำหนดไว้สำหรับทุกหน่วยงาน ### หลักฐานเชิงประจักษ์และการจัดทำรายงานเพื่อยื่นแบบ สกมช. คลาวด์ 1 (Form CSC v1.0) ผลการทดสอบต้องถูกจัดทำเป็นเอกสารหลักฐานที่มีความน่าเชื่อถือ ตรวจสอบย้อนกลับได้ เพื่อใช้แนบรายงานการประเมินตนเองตามข้อกำหนดของ สกมช. #### Executive Summary Report สรุปภาพรวมความเสี่ยงคลาวด์ ระดับผลกระทบต่อธุรกิจ และสถานะความมั่นคงปลอดภัยสำหรับ CISO และคณะกรรมการ #### Technical Pentest & VA Report รายงานผลเชิงเทคนิคฉบับสมบูรณ์ แสดงรายการช่องโหว่, ระดับ CVSS, รหัส CVE/CWE, ลำดับขั้นตอน PoC และแนวทางแก้ไขตรงจุด #### Retest Verification Report รายงานผลการตรวจซ้ำอย่างเป็นทางการ แสดงสถานะ Remediated เพื่อรับรองว่าไม่มีความเสี่ยงคงค้าง #### Form CSC v1.0 Compliance นำหลักฐานและรายงานผลไปอ้างอิงในแบบประเมินตนเอง แบบ สกมช. คลาวด์ 1 หมวด 5 เพื่อนำส่ง สกมช. ภายใน 30 วัน อ้างอิงภาคผนวกประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 ข้อ 5.2.6.8 การจัดการช่องโหว่ทางเทคนิค ข้อ 5.2.6.9 การแยกสภาพแวดล้อมทดสอบ ข้อ 5.2.7.2 การแยกเครือข่าย และข้อ 5.2.9.2 ข้อตกลงด้านความมั่นคงปลอดภัยกับผู้ให้บริการ [ปรึกษาการทำ Cloud VA & Pentest ตามมาตรฐาน สกมช. กับ STH](/th/#contact) ### เครื่องมือประเมินความพร้อม คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น 0% มีการทำข้อตกลงและแบ่งหน้าที่ความรับผิดชอบด้านความปลอดภัย (Shared Responsibility) กับผู้ให้บริการคลาวด์ชัดเจน ระบบ IAM มีการบังคับใช้ Multi-Factor Authentication (MFA) และหลักการ Least Privilege ข้อมูลส่วนบุคคลและข้อมูลสำคัญได้รับการเข้ารหัสทั้งขณะจัดเก็บ (Data at Rest) และขณะส่งผ่านเครือข่าย (Data in Transit) ขอข้อมูลการจัดการช่องโหว่จากผู้ให้บริการตามข้อ 5.2.6.8 และระบุบทบาทการทดสอบความปลอดภัยในสัญญาตามข้อ 5.2.9.2 ประเมินความพร้อม เลือกรายการด้านบนเพื่อประเมินผล [ปรึกษาผู้เชี่ยวชาญ และขอใบเสนอราคา](/th/#contact) ## คำถามที่พบบ่อย (FAQ) คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน ### มาตรฐานความมั่นคงปลอดภัยคลาวด์ สกมช. พ.ศ. 2567 บังคับใช้กับใครบ้าง? บังคับใช้กับหน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล และหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ ตาม พ.ร.บ.ไซเบอร์ฯ พ.ศ. 2562 รวมถึงผู้ให้บริการคลาวด์ที่ให้บริการแก่หน่วยงานเหล่านั้น โดยมีผลใช้บังคับตั้งแต่วันที่ 10 กันยายน 2569 ### หน่วยงานที่ใช้งานคลาวด์ต้องทดสอบความปลอดภัยระบบคลาวด์อย่างไร? ข้อ 5.2.6.8 กำหนดให้ผู้ใช้บริการขอข้อมูลการจัดการช่องโหว่จากผู้ให้บริการ ระบุช่องโหว่ที่ตนรับผิดชอบ และกำหนดกระบวนการจัดการ ข้อ 5.2.9.2 ให้ระบุบทบาทด้านความมั่นคงปลอดภัยในสัญญา ซึ่งอาจรวมการทดสอบความปลอดภัย แต่ไม่ได้บังคับรอบ Pentest ปีละ 1 ครั้งสำหรับทุกหน่วยงาน ### การทดสอบเจาะระบบคลาวด์ตามมาตรฐาน สกมช. ต้องทำอย่างไร? ความถี่และขอบเขตการทดสอบความปลอดภัยให้เป็นไปตามข้อตกลงในสัญญาตามข้อ 5.2.9.2 ส่วนการแยก Tenant ตามข้อ 5.2.7.2 เป็นข้อกำหนดด้านเครือข่าย ไม่ใช่เงื่อนไข RoE ของการทดสอบเจาะระบบโดยตรง รายงานสรุปการดำเนินการตามข้อ 6 ต้องส่งสำนักงานภายใน 30 วันนับจากดำเนินการแล้วเสร็จ ## หัวข้อและกฎหมายกำกับดูแลที่เกี่ยวข้อง - [ แนวปฏิบัติ Zero Trust ของ สกมช. ](/th/compliance/ncsa-zero-trust-guidelines/) - [ ISO/IEC 27001:2022 ต้องทำ Penetration Testing ไหม ](/th/compliance/iso-27001/) - [ ธุรกิจภายใต้ ก.ล.ต. ต้องทำ Penetration Testing ไหม ](/th/compliance/sec/) - [ PDPA กำหนดให้ทำ Penetration Testing หรือไม่ ](/th/compliance/pdpa/) เปิดภาพขนาดเต็มเพื่อซูม ## เอกสารต้นทางฉบับทางการ ไฟล์ต้นฉบับจากหน่วยงานราชการ โฮสต์ไว้บน sth.sh เพื่อความสะดวก โปรดยึดฉบับล่าสุดจากลิงก์ต้นทางเป็นสำคัญ [ ![ตัวอย่างหน้าแรกของประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 (ฉบับราชกิจจานุเบกษา)](/assets/process/compliance-sources/sth-source-ncsa-cloud-security-standard-2567-ratchakitcha.webp) ](/assets/documents/sth-source-ncsa-cloud-security-standard-2567-ratchakitcha.pdf) ### ประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 (ฉบับราชกิจจานุเบกษา) โดย ราชกิจจานุเบกษา [เปิดเอกสาร (PDF) ](/assets/documents/sth-source-ncsa-cloud-security-standard-2567-ratchakitcha.pdf) [ดาวน์โหลด ](/assets/documents/sth-source-ncsa-cloud-security-standard-2567-ratchakitcha.pdf) [แหล่งต้นทาง ](https://ratchakitcha.soc.go.th/documents/43184.pdf) [พอร์ทัล สกมช. Cloud Security ](https://cloudsecurity.ncsa.or.th/) [ ![ตัวอย่างหน้าแรกของแบบประเมินตนเองตามมาตรฐานความมั่นคงปลอดภัยระบบคลาวด์ สำหรับผู้ใช้บริการคลาวด์ (Self-Assessment for CSC เวอร์ชัน 1.0)](/assets/process/compliance-sources/sth-source-ncsa-cloud-security-self-assessment-v1.0.webp) ](/assets/documents/sth-source-ncsa-cloud-security-self-assessment-v1.0.pdf) ### แบบประเมินตนเองตามมาตรฐานความมั่นคงปลอดภัยระบบคลาวด์ สำหรับผู้ใช้บริการคลาวด์ (Self-Assessment for CSC เวอร์ชัน 1.0) โดย สกมช. (NCSA) [เปิดเอกสาร (PDF) ](/assets/documents/sth-source-ncsa-cloud-security-self-assessment-v1.0.pdf) [ดาวน์โหลด (PDF) ](/assets/documents/sth-source-ncsa-cloud-security-self-assessment-v1.0.pdf) [ดาวน์โหลด (.docx) ](/assets/documents/sth-source-ncsa-cloud-security-self-assessment-v1.0.docx) [แหล่งต้นทาง ](https://drive.ncsa.or.th/s/8gS69Wz6L4qwKC9?openfile=true) [พอร์ทัล สกมช. Cloud Security ](https://cloudsecurity.ncsa.or.th/) ## ต้องการทำ Pentest ให้สอดคล้องกับข้อกำหนดเหล่านี้? เล่าขอบเขตระบบและข้อกำหนดที่ต้องปฏิบัติตามให้เราฟัง ทีม STH จะช่วยประเมินแนวทางและจัดทำใบเสนอราคาให้ [ขอใบเสนอราคา Pentest](/th/#contact) ## เอกสาร PDF [เปิดในแท็บใหม่ ](/th/compliance/ncsa-cloud-security-standard/) [ดาวน์โหลด](/th/compliance/ncsa-cloud-security-standard/) อัปเดตล่าสุด 16 ตุลาคม 2569