ใบรับรองผู้ให้บริการ Cloud ตามกรอบของ สกมช. อ่านอย่างไร และสิ่งที่ใบรับรองไม่ได้บอก

ข้อเสนอจากผู้ให้บริการ Cloud รายหนึ่งมาถึงโต๊ะเจ้าหน้าที่จัดซื้อ หน้าที่สามของเอกสารแนบมีรูปใบรับรองเรียงกันเป็นแถว ISO 27001, ISO 27017, CSA STAR และใบรับรองอีกใบที่เพิ่งได้ ประธานคณะกรรมการจัดซื้อถามสั้น ๆ ว่า ใบเหล่านี้พอสำหรับระบบของเราหรือเปล่า

คำถามนี้ตอบได้ยากกว่าที่คิด เพราะใบรับรองแต่ละใบรับรองคนละเรื่อง และไม่มีใบไหนรับรองระบบของหน่วยงานคุณเอง บทความนี้เขียนจากมุมของทีมที่ต้องช่วยหน่วยงานอ่านข้อเสนอแบบนี้ ไม่ใช่คำแนะนำทางกฎหมาย เราจะเล่าว่ากรอบความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ของ สกมช. (NCSA) วางเส้นทางรับรองไว้อย่างไร ใบรับรองของผู้ให้บริการบอกอะไรคุณได้ บอกอะไรไม่ได้ และจะเขียนอะไรลงในสัญญาตอนที่เกณฑ์บางส่วนยังไม่ประกาศ ส่วนหน้าที่ตามกฎหมายของหน่วยงานคุณ ควรให้ฝ่ายกฎหมายหรือผู้รับผิดชอบด้านความมั่นคงปลอดภัยของหน่วยงานเป็นผู้ยืนยัน

เราอ่านจากแหล่งไหน และอ่านถึงไหน

แหล่งหลักของบทความนี้คือเว็บไซต์ทางการของ สกมช. ด้านกรอบความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ ได้แก่ หน้าขั้นตอนการรับรองของผู้ให้บริการ (CSP) หน้าของผู้ใช้บริการ (CSC) และหน้าคำถามที่พบบ่อยเรื่องการรับรอง ทั้งหมดเราเปิดอ่านเมื่อวันที่ 28 ตุลาคม 2026 และหน้าเหล่านี้ไม่ระบุวันที่ปรับปรุงล่าสุด เนื้อหาจึงเปลี่ยนได้

สิ่งที่เรายังไม่ได้อ่านคือตัวประกาศ กมช. เรื่องมาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ ฉบับเต็ม สำเนาที่เจอบนเว็บหน่วยงานอื่นเปิดไม่ได้ เพราะระบบกันบอทของเว็บนั้นเปลี่ยนเส้นทางวนไม่จบ และเราไม่หลบด่านนั้น ดังนั้นทุกข้อความเกี่ยวกับเนื้อหามาตรฐานในบทความนี้ มาจากสิ่งที่ สกมช. สรุปไว้บนเว็บไซต์ของตัวเอง ไม่ใช่จากตัวข้อกำหนดโดยตรง เราจึงไม่ใส่ค่าธรรมเนียม อายุใบรับรอง หรือกรอบเวลาใด ๆ เพราะหน้าเหล่านี้เองก็ระบุว่ายังไม่กำหนด

ใบรับรองของผู้ให้บริการ 3 ชั้น ที่มักถูกวางเรียงกัน

เมื่อผู้ให้บริการแสดงใบรับรองหลายใบ เรามองเป็นสามชั้นที่ตอบคำถามต่างกัน

• ใบรับรองระบบบริหารของบริษัท เช่น ISO/IEC 27001 บอกว่าบริษัทมีระบบบริหารความมั่นคงปลอดภัยสารสนเทศตามมาตรฐานสากล ขอบเขตของใบรับรองแต่ละใบอาจครอบคลุมเพียงบางหน่วยงานหรือบางสถานที่ของบริษัท

• ใบรับรองที่เจาะจง Cloud เช่น ISO/IEC 27017, ISO/IEC 27018 และ CSA STAR ซึ่งพูดถึงการควบคุมเฉพาะบริการคลาวด์ หรือความปลอดภัยและความเป็นส่วนตัวของข้อมูลบน Cloud

• การรับรองตามกรอบของ สกมช. ซึ่งผู้ให้บริการยื่นผ่านหน่วยรับรอง (CB) ที่ขึ้นทะเบียนกับ สกมช. และเป็นการตรวจประเมินบริการที่ระบุไว้ในขอบเขตตามระดับผลกระทบของข้อมูลหรือระบบของผู้ใช้บริการ

สองชั้นแรกผู้ให้บริการได้มาจากองค์กรรับรองสากลก่อนมีกรอบของ สกมช. สำหรับชั้นที่สาม สกมช. อธิบายขั้นตอนไว้ว่า ผู้ให้บริการต้องจำแนกบริการที่จะขอรับรองและระดับผลกระทบ จัดมาตรการด้านเทคนิคและการบริหารให้ตรงระดับนั้น ยื่นคำขอพร้อมเอกสารขอบเขตบริการต่อ CB จากนั้น CB ตรวจสถาปัตยกรรม ศูนย์ข้อมูล และการปฏิบัติงานจริงภายในขอบเขต แก้ข้อบกพร่องที่พบ แล้วจึงได้ใบรับรองและถูกบันทึกในทะเบียนผู้ให้บริการ หลังได้ใบรับรองยังต้องรักษามาตรฐานและรับการตรวจติดตามต่อเนื่องตลอดอายุใบรับรอง

ในคำถามที่พบบ่อยของ สกมช. มีข้อความระบุว่าผู้ให้บริการ Cloud ต้องได้รับการรับรองตามมาตรฐานสากล CSA STAR Level 2 (CCM) และ ISO/IEC 27701 เป็นอย่างน้อย หน้าเดียวกันไม่ได้ระบุ ISO/IEC 27001 หรือ ISO/IEC 27017 ในข้อนี้ จึงอย่าสรุปว่าใบ ISO 27001 ใบเดียวเพียงพอ

ใบรับรองของผู้ให้บริการไม่ได้รับรองระบบของคุณ

นี่คือจุดที่เราเห็นความเข้าใจคลาดเคลื่อนบ่อยที่สุด ต่อให้ผู้ให้บริการผ่านการรับรองครบทุกชั้น ระบบที่หน่วยงานคุณสร้างบน Cloud นั้นก็ยังเป็นความรับผิดชอบของหน่วยงาน สกมช. แยกหน้าสำหรับผู้ใช้บริการ (CSC) ไว้ต่างหาก ซึ่งระบุว่าก่อนขอรับรอง ผู้ใช้บริการต้องจำแนกข้อมูลหรือระบบตามระดับผลกระทบ ต่ำ กลาง สูง โดยดูผลต่อการรักษาความลับ ความถูกต้อง และความพร้อมใช้งาน และระดับสูงครอบคลุมโครงสร้างพื้นฐานสำคัญทางสารสนเทศและข้อมูลอ่อนไหวมาก

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

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

อ่านใบรับรองของผู้ให้บริการ ให้ดูอะไรบ้าง

เมื่อได้ใบรับรองมาหนึ่งใบ เรามีคำถามห้าข้อที่ใช้ตรวจ ไม่ว่าใบนั้นจะเป็นใบสากลหรือใบตามกรอบของ สกมช.

• ขอบเขตครอบคลุมบริการที่คุณจะใช้หรือไม่ ใบที่ครอบคลุมศูนย์ข้อมูลแห่งหนึ่งหรือบริการหนึ่ง ไม่ได้ครอบคลุมทุกอย่างที่ผู้ให้บริการขาย

• รับรองที่ระดับผลกระทบใด ถ้าระบบของคุณอยู่ระดับกลางหรือสูง ใบที่ออกให้ระดับต่ำไม่เพียงพอ

• ใครเป็นผู้ออกใบรับรอง ในกรอบของ สกมช. ใบรับรองออกโดยหน่วยรับรองที่ขึ้นทะเบียนกับ สกมช. ไม่ใช่ผู้ให้บริการประเมินตนเอง

• ใบรับรองยังมีผลอยู่หรือไม่ และมีการตรวจติดตามต่อเนื่องหรือไม่ หน้าของ สกมช. ระบุว่ามีการตรวจติดตามตลอดอายุใบรับรอง แต่ยังไม่ระบุว่านานเท่าใด

• ตรวจกับทะเบียนได้หรือไม่ เว็บของ สกมช. กล่าวถึงทะเบียนผู้ให้บริการ แต่หน้ารายชื่อที่เราลองเปิดไม่พบ เราจึงไม่ทราบว่ารายชื่อเปิดให้ตรวจแบบสาธารณะแล้วหรือยัง

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

สิ่งที่ สกมช. ยังไม่ประกาศ และจะเขียนสัญญาอย่างไรในช่วงนี้

จากหน้าคำถามที่พบบ่อย สกมช. ระบุว่าประกาศมาตรฐานคลาวด์มีผลบังคับใช้อย่างเป็นทางการเมื่อวันที่ 10 กันยายน 2569 (ตรงกับ 10 กันยายน 2026) แต่รายการที่ สกมช. ระบุว่ากำลังจัดทำหรือพิจารณาอยู่ ยังมีดังนี้

• หลักเกณฑ์เกี่ยวกับหน่วยรับรอง

• แนวทางการรับรองโดยหน่วยงานกำกับดูแล (attestation) ซึ่ง สกมช. กำลังบูรณาการกับหน่วยกำกับในแต่ละภาคส่วน

• เกณฑ์การประเมินตนเองมาตรฐานสำหรับระบบระดับต่ำ (ยังไม่มีเทมเพลต)

• ประกาศและแนวปฏิบัติรองรับการใช้ผู้ให้บริการต่างประเทศ ที่ทำสัญญาไว้ก่อนประกาศมีผล

• แนวทางการแบ่งความรับผิดชอบเมื่อใช้ SaaS

นอกจากนี้คำตอบหลายข้อบนเว็บไม่ได้ระบุค่าธรรมเนียม อายุใบรับรอง หรือรอบการต่ออายุ เมื่อกติกายังไม่นิ่ง เรามองว่าสัญญากับผู้ให้บริการควรเขียนให้ยืดหยุ่นพอรับเกณฑ์ที่จะตามมา เรื่องนี้เป็นข้อเสนอของเรา ไม่ใช่ข้อกำหนดของ สกมช. ซึ่งมีหลายเรื่องที่เขียนได้ เช่น ให้ผู้ให้บริการระบุขอบเขตและระดับผลกระทบที่ตนได้รับรอง แจ้งหน่วยงานเมื่อใบรับรองหมดอายุหรือถูกเพิกถอน ให้ความร่วมมือเมื่อหน่วยรับรองต้องตรวจระบบของหน่วยงาน และระบุว่าใครรับค่าใช้จ่ายส่วนที่เกิดจากการเปลี่ยนเกณฑ์ภายหลัง แนวทางการเขียนเงื่อนไขทำนองนี้ เราเขียนไว้ในบทความเรื่องเงื่อนไขใน TOR และเรื่องสิทธิ์เข้าถึงบัญชีเมื่อทีมพัฒนาเปลี่ยนมืออยู่ในบทความเรื่องบัญชี Cloud

ผู้ให้บริการต่างประเทศ ต้องทำอย่างไร

หลายหน่วยงานใช้ผู้ให้บริการรายใหญ่ที่ไม่ได้ตั้งในไทย สกมช. ตอบไว้ว่าหน่วยงานที่ใช้ผู้ให้บริการต่างประเทศก่อนประกาศมีผล ต้องทบทวนการใช้บริการนั้น โดยตรวจหลักฐานใบรับรองสากล เช่น ISO/IEC 27001, 27017, 27018, 27701 และ CSA STAR ว่าสอดคล้องและเพียงพอหรือไม่ ข้อความนี้เป็นตัวอย่างของหลักฐานที่ใช้พิจารณา ไม่ได้ระบุว่าใบรับรองเหล่านี้ใช้แทนการรับรองตามมาตรฐานคลาวด์ของ สกมช. ได้ และ สกมช. ยังระบุว่ากำลังพิจารณาประกาศรองรับช่วงเปลี่ยนผ่านของสัญญาที่ทำไว้ก่อนหน้า

เรื่องว่าผู้ให้บริการควรอยู่ที่ไหน กับการเลือก region ที่ตั้งของข้อมูล เป็นอีกคำถามหนึ่ง เราเขียนไว้ในบทความเรื่อง region และที่ตั้งข้อมูล และเรื่องการพึ่งพาผู้ให้บริการรายเดียวหรือหลายราย อยู่ในบทความเรื่อง multi-cloud บทความนี้ไม่ได้อ้างข้อกำหนดเรื่องที่ตั้งข้อมูลของมาตรฐานนี้ เพราะเราหาข้อความที่ยืนยันได้จากแหล่งทางการไม่เจอ

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. ไล่รายการระบบที่ทำงานบน Cloud พร้อมบอกว่าใช้ผู้ให้บริการรายไหน และใช้ในรูปแบบใด เช่น โครงสร้างพื้นฐานหรือซอฟต์แวร์สำเร็จรูป

2. จำแนกระดับผลกระทบของแต่ละระบบ เป็นต่ำ กลาง สูง ตามผลต่อความลับ ความถูกต้อง และความพร้อมใช้งาน แล้วให้ผู้บริหารที่รับผิดชอบระบบเซ็นรับ

3. ขอเอกสารใบรับรองจากผู้ให้บริการแต่ละราย พร้อมขอบเขตและระดับผลกระทบที่รับรอง แล้วเทียบกับระดับของระบบคุณ

4. ทบทวนสัญญาและ SLA ตามรายการในหัวข้อก่อนหน้า โดยเฉพาะเรื่องการแจ้งเมื่อใบรับรองเปลี่ยนสถานะ

5. ติดตามประกาศของ สกมช. เรื่องหลักเกณฑ์หน่วยรับรอง แนวทางสำหรับ SaaS และช่วงเปลี่ยนผ่าน แล้วบันทึกวันที่ตรวจข้อมูลครั้งล่าสุดไว้ในเอกสารตัดสินใจ

สรุป

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส