มาตรฐานความปลอดภัยคลาวด์ 5 จุดเสี่ยงด่วนที่องค์กรไทยต้องรีบปิด

มาตรฐานความปลอดภัยคลาวด์มีผลใช้แล้ว หน่วยงานรัฐ CII และผู้ให้บริการต้องแบ่งหน้าที่ให้ชัด ตรวจสัญญา สิทธิ์เข้าถึง บันทึกเหตุ และหลักฐาน PDPA ก่อนถูกตรวจ
มาตรฐานความปลอดภัยคลาวด์และตารางแบ่งความรับผิดชอบขององค์กรไทย
มาตรฐานความปลอดภัยคลาวด์และตารางแบ่งความรับผิดชอบขององค์กรไทย
แชร์

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

ขอบเขตการบังคับใช้มาตรฐานคลาวด์

มาตรฐานนี้ครอบคลุมหน่วยงานรัฐ หน่วยงานควบคุม และผู้ให้บริการคลาวด์ของกลุ่มเป้าหมาย

การแบ่งความรับผิดชอบร่วม (Shared Responsibility)

ระบุหน้าที่ชัดเจนระหว่างผู้ให้บริการคลาวด์และลูกค้าเพื่อความปลอดภัย

ใบรับรอง ISO ไม่เพียงพอ

แม้ผู้ให้บริการมี ISO ลูกค้ายังต้องตรวจสอบการตั้งค่าและการใช้งานจริง

5 เรื่องสำคัญที่องค์กรควรปฏิบัติ

ทำบัญชีระบบคลาวด์ จัดระดับผลกระทบ ทำตารางแบ่งความรับผิดชอบ ตรวจสัญญา และรวบรวมหลักฐาน

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

สารบัญ

  1. มาตรฐานความปลอดภัยคลาวด์มีผลกับใครบ้าง
  2. Shared Responsibility คืออะไร
  3. ใบรับรอง ISO ของผู้ให้บริการเพียงพอหรือไม่
  4. ผลกระทบต่อองค์กรและธุรกิจในประเทศไทย
  5. มาตรฐานคลาวด์เกี่ยวข้องกับ PDPA มาตรา 37 อย่างไร
  6. 5 เรื่องที่องค์กรควรทำต่อ
  7. คำถามที่พบบ่อย
  8. มุมมองผู้เชี่ยวชาญ
  9. แหล่งอ้างอิง

มาตรฐานความปลอดภัยคลาวด์มีผลกับใครบ้าง

มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 มีผลใช้ตั้งแต่วันที่ 10 กันยายน 2569 โดยกลุ่มหลักที่อยู่ในขอบเขตคือหน่วยงานรัฐ หน่วยงานควบคุมหรือกำกับดูแล หน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ และผู้ให้บริการคลาวด์สาธารณะที่ให้บริการแก่หน่วยงานเหล่านี้

ข้อมูลจาก เว็บไซต์ Cloud Security Thailand ของ สกมช. ระบุว่ามาตรฐานนี้จัดทำขึ้นเพื่อรองรับนโยบาย Cloud First และเตรียมความพร้อมให้ภาคส่วนที่เกี่ยวข้องก่อนวันที่มาตรฐานมีผลใช้

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

อย่างไรก็ตาม บริษัทเอกชนอาจเข้ามาเกี่ยวข้องได้ในหลายฐานะ เช่น

  • เป็นผู้ให้บริการคลาวด์แก่หน่วยงานรัฐหรือ CII
  • เป็นผู้พัฒนาระบบบนคลาวด์ให้หน่วยงานที่อยู่ในขอบเขต
  • เป็นผู้รับจ้างดูแลข้อมูลหรือระบบหลังบ้าน
  • เป็นผู้ขาย SaaS ให้หน่วยงานรัฐหรือ CII
  • รับช่วงงานจากผู้รับจ้างหลักอีกทอดหนึ่ง

ดังนั้น แม้บริษัทจะไม่ถูกกำหนดชื่อไว้โดยตรง ข้อกำหนดอาจถูกส่งต่อมาทาง TOR สัญญา การตรวจรับงาน หรือแบบประเมินผู้ขาย

คำศัพท์ที่ควรรู้ก่อนอ่านต่อ

CII หรือ Critical Information Infrastructure
หน่วยงานหรือบริการที่มีความสำคัญต่อประเทศ หากระบบถูกโจมตีหรือหยุดทำงานอาจกระทบต่อความมั่นคง เศรษฐกิจ สาธารณสุข การเงิน พลังงาน การขนส่ง หรือบริการสาธารณะที่สำคัญ

SaaS หรือ Software as a Service
ซอฟต์แวร์ที่ใช้งานผ่านอินเทอร์เน็ต เช่น ระบบบัญชี ระบบ HR ระบบจอง ระบบจัดการลูกค้า หรืออีเมลที่ผู้ใช้ไม่ต้องติดตั้งและดูแลเซิร์ฟเวอร์เองทั้งหมด

Gap Analysis
การเปรียบเทียบว่าองค์กรทำอะไรแล้ว และยังขาดอะไรเมื่อเทียบกับข้อกำหนดของมาตรฐาน

Shared Responsibility คืออะไร

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

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

คลาวด์ก็ใช้หลักคิดคล้ายกัน

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

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

ใบรับรอง ISO ของผู้ให้บริการเพียงพอหรือไม่

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

Telecomlover รายงานโดยอ้างข้อมูลจาก NT ว่า NT ได้รับการรับรอง ISO/IEC 27001:2022, ISO/IEC 27701:2019, ISO/IEC 27017:2015, ISO/IEC 27018:2019 และ CSA STAR Certification

การมีมาตรฐานเหล่านี้เป็นข้อมูลสำคัญในการประเมินผู้ให้บริการ แต่ลูกค้าควรถามต่ออย่างน้อยว่า

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

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

ผลกระทบต่อองค์กรและธุรกิจในประเทศไทย

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

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

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

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

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

องค์กรจึงไม่ควรถามเพียงว่า “คลาวด์ปลอดภัยหรือไม่” แต่ควรถามว่า “ในส่วนที่องค์กรต้องดูแล เรามีคน กระบวนการ และหลักฐานเพียงพอหรือยัง”

อ่านเพิ่มเติมเกี่ยวกับการจัดการข้อมูลของหน่วยงานรัฐได้ที่ PDPA กับการแบ่งปันข้อมูลดิจิทัลภาครัฐ และกรณีการเตรียมรับเหตุได้ที่ AI Agent เจาะระบบจริงแล้ว บทเรียนใหม่ก่อนเกิด Data Breach

มาตรฐานคลาวด์เกี่ยวข้องกับ PDPA มาตรา 37 อย่างไร

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

มาตรา 37(1) แห่งพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลกำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม และต้องทบทวนมาตรการเมื่อมีความจำเป็นหรือเมื่อเทคโนโลยีเปลี่ยนแปลง

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

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

การผ่านมาตรฐานความปลอดภัยคลาวด์ไม่ควรถูกสรุปโดยอัตโนมัติว่าองค์กรปฏิบัติตาม PDPA ครบแล้ว และการมีเอกสาร PDPA ก็ไม่ได้แปลว่าการตั้งค่าคลาวด์ปลอดภัยแล้วเช่นกัน

องค์กรต้องตรวจทั้ง “ข้อกฎหมาย” และ “สภาพระบบจริง”

องค์กรไทยควรทำอะไรเป็น 5 เรื่องแรก

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

1. ทำบัญชีระบบคลาวด์ให้ครบ

ระบุชื่อบริการ เจ้าของระบบ ผู้ให้บริการ ประเภทข้อมูล ผู้ใช้งาน การเชื่อมต่อ และผู้รับจ้างช่วง อย่าตรวจเฉพาะระบบหลัก แต่ให้รวม SaaS ที่แต่ละแผนกสมัครใช้เองด้วย

2. จัดระดับผลกระทบของข้อมูลและระบบ

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

แนวทางสำหรับผู้ใช้บริการคลาวด์ของ สกมช. ระบุให้จำแนกข้อมูลหรือระบบตามผลกระทบด้านความลับ ความถูกต้อง และความพร้อมใช้งานก่อนกำหนดมาตรการควบคุม

3. ทำตาราง Shared Responsibility

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

4. ตรวจสัญญาและการตั้งค่าจริงพร้อมกัน

ฝ่ายกฎหมายควรตรวจ SLA สิทธิการตรวจสอบ การแจ้งเหตุ ผู้รับจ้างช่วง การคืนหรือลบข้อมูล และเงื่อนไขเลิกสัญญา ขณะที่ฝ่ายเทคนิคตรวจ MFA สิทธิ์ผู้ดูแล ระบบ log การเข้ารหัส การสำรอง และการกู้คืน

5. จัดทำ Cloud Security Evidence Pack

รวบรวมหลักฐานให้อยู่ในที่เดียว เช่น

  • บัญชีระบบและข้อมูล
  • ผลการจัดระดับผลกระทบ
  • ตาราง Shared Responsibility
  • สัญญาและ DPA
  • รายงานทบทวนสิทธิ์
  • หลักฐานการเปิดใช้ MFA
  • ผลการทดสอบกู้คืน
  • บันทึกการซ้อมรับมือเหตุ
  • ใบรับรองและรายงานจากผู้ให้บริการ
  • รายการช่องว่างและแผนแก้ไขพร้อมผู้รับผิดชอบ

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

คำถามที่พบบ่อย

มาตรฐานความปลอดภัยคลาวด์มีผลเมื่อไร

มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 มีผลใช้ตั้งแต่วันที่ 10 กันยายน 2569 หลังประกาศในราชกิจจานุเบกษาครบสองปี

มาตรฐานความปลอดภัยคลาวด์บังคับเอกชนทุกบริษัทหรือไม่

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

ใช้ผู้ให้บริการคลาวด์ที่มี ISO แล้ว ลูกค้ายังต้องรับผิดชอบหรือไม่

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

Shared Responsibility คืออะไร

Shared Responsibility คือการแบ่งหน้าที่ด้านความปลอดภัยระหว่างผู้ให้บริการคลาวด์กับลูกค้า โดยแต่ละฝ่ายต้องรู้ว่าตนควบคุมเรื่องใดและต้องเก็บหลักฐานอะไร

มาตรฐานคลาวด์แทนการปฏิบัติตาม PDPA ได้หรือไม่

ไม่ได้ มาตรฐานคลาวด์และ PDPA มีงานบางส่วนซ้อนกัน แต่มีวัตถุประสงค์และขอบเขตทางกฎหมายต่างกัน องค์กรต้องตรวจทั้งสองกรอบตามข้อเท็จจริงของระบบและข้อมูล

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

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

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

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

  1. Telecomlover — NT เผยผ่านมาตรฐานคลาวด์สากล พร้อมชวนหน่วยงานรัฐยกระดับความปลอดภัย
  2. สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ — Cloud Security Thailand
  3. สกมช. — คำถามและคำตอบเกี่ยวกับขอบเขตมาตรฐานและ Shared Responsibility
  4. สกมช. — ขั้นตอนการขอรับรองสำหรับผู้ใช้บริการคลาวด์
  5. สำนักงานคณะกรรมการกฤษฎีกา — พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562

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

Digital Infrastructure Bill Thailand กับกติกาดาต้าเซ็นเตอร์ คลาวด์ และข้อมูลในไทย

Digital Infrastructure Bill Thailand 5 จุดเสี่ยงห้ามพลาด

ก่อนหน้า
ข้อมูลตำแหน่ง Google ถูก DPC ไอร์แลนด์ปรับ 403 ล้านยูโร

Google ถูกปรับ 1.5 หมื่นล้านเพราะข้อมูลตำแหน่ง: 3 จุดที่แอปไทยเสี่ยงซ้ำ

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

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

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