Cloud Security ไทย บังคับแล้ว ใครต้องรีบเช็ก ก่อนมาตรฐานเว็บตามมา

Cloud Security Standard
Cloud Security Standard ไทยบังคับแล้ว
แชร์

ประเด็นสำคัญ

ผลบังคับใช้และผู้ได้รับผลกระทบ

Cloud Security Standard และ WSS 1.0 เริ่มใช้ปี 2569 ครอบคลุมหน่วยงานรัฐและผู้ให้บริการคลาวด์

ความรับผิดชอบและการแบ่งงานระหว่างลูกค้าและผู้ให้บริการ

แม้ใช้ AWS หรือ Azure องค์กรยังต้องดูแลการตั้งค่าและการบริหารจัดการเอง

ความสำคัญของสัญญาและหลักฐาน

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

การเตรียมความพร้อมของผู้รับพัฒนาเว็บไซต์

ต้องตอบโจทย์มาตรฐานตั้งแต่ต้นงาน เช่น การจัดการ SSL/TLS การทดสอบช่องโหว่ และการสำรองข้อมูล

อัปเดตล่าสุด

บทนำ

Cloud Security ไทย มีผลบังคับใช้แล้วตั้งแต่ 10 กันยายน 2569 ขณะที่ WSS 1.0 มาตรฐานความปลอดภัยเว็บไซต์มีกำหนดเริ่มใช้ 17 กันยายน 2569 เรื่องนี้จึงไม่ใช่ข่าวเฉพาะฝ่าย IT อีกต่อไป เพราะสิ่งที่องค์กรต้องเตรียมมีทั้งการประเมินความเสี่ยง ทรัพย์สินของระบบ สัญญา หน้าที่ของผู้ให้บริการ และหลักฐานที่ใช้ยืนยันว่าทำตามข้อกำหนดจริง

Cloud Security ไทย เริ่มบังคับใช้เมื่อไร และใครอยู่ในข่าย

Cloud Security Standard พ.ศ. 2567 มีผลบังคับใช้วันที่ 10 กันยายน 2569 หลังประกาศในราชกิจจานุเบกษาเมื่อวันที่ 10 กันยายน 2567 และกำหนดระยะเวลา 2 ปีก่อนมีผลจริง ผู้ที่อยู่ในข่ายหลัก ได้แก่ หน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล หน่วยงาน CII และผู้ให้บริการ Public Cloud ที่ให้บริการแก่หน่วยงานเหล่านี้ตามเงื่อนไขที่กำหนด

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

WSS 1.0 คืออะไร และทำไมเว็บไซต์ราชการกำลังกลายเป็นเรื่องของฝ่ายกฎหมาย

WSS 1.0 หรือ Website Security Standard คือมาตรฐานขั้นต่ำสำหรับการรักษาความปลอดภัยเว็บไซต์ของหน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล และหน่วยงาน CII โดยมาตรฐานกำหนดให้มีทั้งการประเมินระดับผลกระทบ การตรวจสถานะความปลอดภัย และการจัดเก็บหลักฐานประกอบการประเมิน

ประกาศดังกล่าวลงในราชกิจจานุเบกษาเมื่อวันที่ 16 กันยายน 2568 และกำหนดให้เริ่มใช้เมื่อพ้นหนึ่งปีนับจากวันประกาศ จึงเป็นที่มาของวันที่ 17 กันยายน 2569 ที่หลายองค์กรกำลังเร่งตรวจสอบระบบของตนเอง

จุดเปลี่ยนที่ธุรกิจไทยต้องจับตา: ความปลอดภัยต้อง “พิสูจน์ได้”

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

นี่ทำให้เรื่อง Cybersecurity ขยับออกจากห้อง Server และเข้ามาอยู่ในห้องประชุมของผู้บริหาร ฝ่ายจัดซื้อ ฝ่ายกฎหมาย และผู้รับจ้างระบบด้วย

ใช้ AWS, Azure หรือ Cloud รายใหญ่แล้ว ถือว่าผ่านหรือไม่

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

พูดง่าย ๆ คือ Cloud Provider อาจดูแล “ตัว Cloud” แต่ไม่ได้หมายความว่าจะดูแล “ทุกอย่างที่องค์กรทำบน Cloud” แทนองค์กรทั้งหมด

ถ้าบริษัทเป็นผู้รับพัฒนาเว็บไซต์ ต้องทำอะไรเพิ่ม

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

ในทางธุรกิจ นั่นหมายความว่า ผู้รับจ้างควรตอบลูกค้าให้ได้ตั้งแต่ก่อนเริ่มงานว่า ใครเป็นผู้รับผิดชอบเรื่อง SSL/TLS, MFA, การจัดการสิทธิ์, การทดสอบช่องโหว่, Log, Backup และการแก้ไขเมื่อพบข้อบกพร่อง เพราะเรื่องเหล่านี้จะกลายเป็นส่วนหนึ่งของการส่งมอบงานมากขึ้น

ผลกระทบต่อประเทศไทย: งานไอที งานจัดซื้อ และสัญญาจะเปลี่ยนอย่างไร

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

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

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

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

อีกเรื่องที่ควรแยกออกจากกัน คือ การแก้ไขกฎหมายไซเบอร์เพื่อเพิ่มโทษปรับเป็นหลักล้านบาท เรื่องนี้ยังเป็น “ข้อเสนอแก้กฎหมาย” ไม่ใช่บทลงโทษใหม่ที่มีผลใช้แล้ว จึงไม่ควรนำตัวเลขค่าปรับดังกล่าวไปเขียนเหมือนเป็นกฎหมายปัจจุบัน

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

หน่วยงานรัฐต้องเตรียมอะไร

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

ผู้ให้บริการคลาวด์ต้องเตรียมอะไร

ผู้ให้บริการ Cloud ที่อยู่ในข่ายควรกำหนดขอบเขตบริการและสถาปัตยกรรมให้ชัด ประเมินความเสี่ยง จัดทำแผนความต่อเนื่องทางธุรกิจและการกู้คืน รวมถึงระบุหน้าที่ด้านความปลอดภัยระหว่างผู้ให้บริการกับลูกค้าใน SLA และเอกสารที่เกี่ยวข้อง

สิ่งสำคัญคืออย่าปล่อยให้คำว่า “Shared Responsibility” อยู่แค่ในเอกสารขายบริการ ลูกค้าต้องรู้ว่า Cloud Provider รับผิดชอบอะไร และลูกค้าต้องทำอะไรเอง

บริษัทรับทำเว็บไซต์และ System Integrator ต้องระวังอะไร

ผู้รับจ้างควรตรวจตั้งแต่ก่อนเซ็นสัญญาว่าขอบเขตงานต้องรองรับมาตรฐานที่ลูกค้าใช้อ้างอิงหรือไม่ และต้องกำหนดวิธีส่งมอบหลักฐานด้าน Security ให้ชัดตั้งแต่ต้น เช่น ผลทดสอบช่องโหว่ รายการสิทธิ์ การตั้งค่าที่สำคัญ Log และแผนสำรองกู้คืนตามความเหมาะสมของระบบ

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

คำศัพท์ง่าย ๆ ที่คนทั่วไปควรรู้ก่อนอ่านเรื่อง Cloud Security

CSP คืออะไร
CSP ย่อมาจาก Cloud Service Provider หมายถึงผู้ให้บริการ Cloud เช่น ผู้ให้บริการโครงสร้างพื้นฐานหรือบริการ Cloud ที่องค์กรนำไปใช้งาน ในมาตรฐานของไทย CSP คือฝั่งผู้ให้บริการ

CSC คืออะไร
CSC ย่อมาจาก Cloud Service Customer หมายถึงหน่วยงานหรือองค์กรที่เป็นผู้ใช้บริการ Cloud ในความสัมพันธ์ทางสัญญา

CII คืออะไร
CII ย่อมาจาก Critical Information Infrastructure หรือหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ เป็นกลุ่มที่กฎหมายไทยให้ความสำคัญเป็นพิเศษด้านความมั่นคงปลอดภัยไซเบอร์

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

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

ก่อนถึงเส้นตาย 17 กันยายน 2569 องค์กรควรตรวจอะไรบ้าง

ก่อนวัน 17 กันยายน 2569 องค์กรที่อยู่ในข่ายควรทำ Gap Assessment แบบง่ายก่อน คือเปิดเอกสารมาตรฐานแล้วเทียบกับสิ่งที่องค์กรมีจริง จากนั้นแยกสิ่งที่ “มีแล้วแต่ไม่มีหลักฐาน” ออกจากสิ่งที่ “ยังไม่ได้ทำ” เพราะสองกรณีนี้ใช้วิธีแก้คนละแบบ

เช็กลิสต์เริ่มต้นที่ควรทำทันทีคือ

  1. ตรวจว่าเว็บไซต์และระบบ Cloud ใดอยู่ในขอบเขต และใครเป็นเจ้าของระบบ
  2. ตรวจระดับผลกระทบและเอกสารประเมินความเสี่ยงว่ามีจริงและยังเป็นปัจจุบันหรือไม่
  3. ตรวจสิทธิ์ Admin, MFA, การจัดการบัญชี, ช่องโหว่ และการเก็บ Log
  4. ตรวจ Backup, BCP, DR และทดลองกู้คืนจริง ไม่ใช่เพียงมีเอกสาร
  5. เปิดสัญญา Cloud, SLA และสัญญาผู้รับจ้างเว็บไซต์ แล้วถามตรง ๆ ว่า “ถ้าเกิดเหตุ ใครต้องทำอะไร ภายในกี่ชั่วโมง และต้องส่งหลักฐานอะไร”

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

มุมมองผู้เชี่ยวชาญ

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

— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law

“มาตรฐานความมั่นคงปลอดภัยไซเบอร์ NCSA: เส้นตายใหม่ที่ธุรกิจไทยต้องรู้” ซึ่งอยู่ใน TechLawNow และพูดถึง Cloud + Website Security โดยตรง. https://techlawnow.com/tech-law/cybersecurity-standards-ncsa-thailand

“AI Infrastructure Governance: จาก Data Center สู่ Governance” เหมาะใช้เชื่อมเรื่อง Cloud, Data Center, Vendor Risk และ Cybersecurity. https://techlawnow.com/ai-governance/ai-infrastructure-governance-thailand-data-center

บทความด้าน AI Governance และ PDPA ของ TechLawNow https://techlawnow.com/ai-governance/sec-thailand-ai-governance-agentic-ai-pdpa

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

TechRepublic, “Thailand’s Cloud Security Standard Is Now in Force: What Providers and CII Operators Must Review”
https://www.techrepublic.com/article/news-cloud-security-standard-apac-thailand/

สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (NCSA), Cloud Security Standard
https://ncsec.ncsa.or.th/cloud-security-standard-for-executive/

NCSA, Cloud Security Thailand — เอกสารและกรอบมาตรฐาน
https://cloudsecurity.ncsa.or.th/

NECTEC, ข่าวการรับมอบใบรับรองเป็นหน่วยรับรองความมั่นคงปลอดภัยระบบคลาวด์รายแรกที่ สกมช. ยอมรับ
https://www.nectec.or.th/news/news-pr-news/nectec-dtec-cloud-security-certification-body-20260904.html

ราชกิจจานุเบกษา, ประกาศมาตรฐานการรักษาความมั่นคงปลอดภัยสำหรับเว็บไซต์ พ.ศ. 2568
https://testing.ncsa.or.th/ncsacms/storage/uploads/2025/09/17/86192_uid_68ca32a2020cf.pdf

NCSA, หลักสูตร Website Security Standard: WSS 1.0 สำหรับผู้รับพัฒนาเว็บไซต์
https://ncsec.ncsa.or.th/wss-for-webdev

YMYL Disclaimer

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

Programmatic SEO และความเสี่ยงต่อความน่าเชื่อถือของเว็บไซต์ใน Google

Programmatic SEO อาจทำเว็บพังทั้งโดเมน? Google เตือนธุรกิจไทย

ก่อนหน้า
AI Twin และปัญหาการเป็นเจ้าของลิขสิทธิ์จากผลงานที่ AI สร้าง

AI Twin ใครเป็นเจ้าของงาน? จุดเปลี่ยนลิขสิทธิ์ที่ธุรกิจไทยต้องรู้

ถัดไป
อัปเดตกฎหมายเทคโนโลยีทุกวัน

ติดตามบทความใหม่

อ่านฟรี ไม่ต้องสมัครสมาชิก เลือกช่องทางที่สะดวก