เก็บภาพกล้องวงจรปิดกี่วันและต้องใช้ดิสก์เท่าไร คือสองคำถามที่ต้องตอบพร้อมกัน เพราะจำนวนวันเป็นตัวกำหนดขนาดดิสก์ แนวปฏิบัติ สกมช. ข้อ 3.2.3–3.2.4 ให้สูตรประมาณการไว้ ส่วน PDPA มาตรา 22 ให้เก็บเท่าที่จำเป็น เหมาะกับเจ้าของระบบและฝ่ายไอที ได้ตารางตัดสินใจและตัวอย่างคำนวณ
- แนวปฏิบัติ สกมช. ข้อ 3.2.3 ไม่กำหนดจำนวนวัน ให้ตั้งตัวเลขจากวัตถุประสงค์ ความเสี่ยง และเวลาที่ใช้ตรวจพบเหตุ
- ไม่ควรตั้งจำนวนวันตามขนาดดิสก์ที่มี ข้อ 3.2.3 เตือนไว้ตรง ๆ ว่าไม่ควรทำแบบนั้น
- สูตรข้อ 3.2.4.1: ดิสก์ต่อกล้องต่อวัน (GB) ประมาณ Bitrate (Mbps) × 10.8 ยังไม่รวม RAID และพื้นที่สำรอง
- หลังติดตั้งต้องวัดจริงว่าย้อนดูภาพได้กี่วัน แล้วเทียบกับตัวเลขที่ประกาศไว้ในป้ายและนโยบาย
- แนวปฏิบัติเป็นเพียงข้อเสนอแนะ ไม่ใช่กฎหมาย ส่วนหน้าที่ตาม PDPA มาตรา 22 และ 37 (3) มาจากตัวพระราชบัญญัติ
ร้านค้า นิติบุคคลอาคารชุด และออฟฟิศส่วนใหญ่ตั้งจำนวนวันเก็บภาพกล้องวงจรปิดตามที่เครื่องบันทึกทำได้ คือซื้อดิสก์ขนาดหนึ่ง แล้วปล่อยให้เครื่องเขียนทับวนไปเอง จำนวนวันที่ได้เลยเป็นผลพลอยได้ ไม่เคยมีใครตัดสินใจจริง ๆ
แนวปฏิบัติด้านความมั่นคงปลอดภัยกล้องวงจรปิดฉบับใหม่ของ สกมช. (สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ) เรียกวิธีนี้ว่าวิธีที่ไม่ควรทำ และให้ลำดับกลับกัน คือกำหนดจำนวนวันก่อน แล้วค่อยคำนวณดิสก์จากจำนวนวันนั้น
ส่วนที่ PDPA มองกล้องวงจรปิดโดยรวม (ป้าย ฐานทางกฎหมาย ใครดูภาพได้) อ่านได้ที่ ติดกล้องวงจรปิดในออฟฟิศ ร้าน คอนโด ต้องทำอะไรตาม PDPA บทความนี้เจาะเฉพาะเรื่องเดียว คือเลขวันกับเลขเทราไบต์
แนวปฏิบัติ สกมช. ให้ตั้งจำนวนวันเก็บภาพจากอะไร?
ให้ตั้งจากเหตุผลของตัวเอง ไม่ใช่จากตัวเลขกลาง ข้อ 3.2.3 ของแนวปฏิบัติไม่มีตัวเลขวันให้เลือกเลยแม้แต่ตัวเดียว สิ่งที่ให้คือรายการสิ่งที่ต้องชั่ง และข้อห้ามสองข้อ
การกำหนดระยะเวลาเก็บรักษาควรพิจารณาจากวัตถุประสงค์ ความจำเป็น ความเสี่ยง ระยะเวลาที่องค์กรต้องใช้ในการตรวจพบและตรวจสอบเหตุ ตลอดจนกฎหมาย ข้อกำหนดเฉพาะภาคส่วน และสัญญาที่เกี่ยวข้อง ไม่ควรกำหนด Retention จากขนาดพื้นที่จัดเก็บที่มีอยู่ หรือเก็บข้อมูลให้นานที่สุดเพียงเพราะเทคโนโลยีสามารถรองรับได้
แยกเป็นปัจจัยได้ 6 ข้อ คือ วัตถุประสงค์ ความจำเป็น ความเสี่ยง เวลาที่ต้องใช้ตรวจพบและตรวจสอบเหตุ กฎหมายหรือข้อกำหนดเฉพาะภาคส่วน และสัญญา
ปัจจัยที่เจ้าของระบบมักข้ามคือข้อที่สี่ “เวลาที่ใช้ตรวจพบและตรวจสอบเหตุ” คือนับจากวันที่เหตุเกิดถึงวันที่มีคนมาขอดูภาพ ร้านที่รู้ปัญหาทันทีในคืนนั้นกับอาคารที่รู้เรื่องของหายหลังผ่านไปหลายสัปดาห์ ควรได้ตัวเลขต่างกัน
วิธีหาตัวเลขที่ไม่ต้องเดา
วิธีที่ใช้ได้จริงคือย้อนดูเหตุที่เคยมีคนขอดูภาพในรอบปีที่ผ่านมา แล้วจดว่าแต่ละครั้งเหตุเกิดไปกี่วันก่อนที่ใครสักคนจะมาขอ (นี่เป็นวิธีที่ผู้เขียนเสนอ ไม่ใช่ขั้นตอนในแนวปฏิบัติ) ถ้าทุกครั้งขอภายใน 10 วัน แต่มีครั้งเดียวที่ขอหลัง 25 วัน ให้ถามตัวเองว่าเหตุแบบหลังเกิดซ้ำได้อีกหรือไม่ และเสียหายแค่ไหนถ้าภาพหายไปแล้ว
ตัวเลขที่ได้ควรมีบรรทัดเหตุผลสั้น ๆ กำกับ เช่น “เก็บ 21 วัน เพราะเหตุของหายในห้องพักปกติรู้หลังเช็กเอาต์ภายใน 2 สัปดาห์ เผื่อหนึ่งสัปดาห์” (ตัวอย่างสมมติ) ข้อ 3.2.3 ให้การกำหนด Retention Period พร้อมเหตุผลรองรับเป็นมาตรการ “พึงปฏิบัติ” ทั้งระดับ B E และ H
PDPA พูดอะไรเรื่องระยะเวลาเก็บภาพ?
PDPA ไม่มีตัวเลขวันสำหรับภาพกล้องวงจรปิดเช่นกัน สิ่งที่มีคือหลักสามข้อที่ต่อกัน เก็บเท่าที่จำเป็น บอกระยะเวลาให้เจ้าของข้อมูลรู้ และมีระบบตรวจเพื่อลบเมื่อพ้นกำหนด ภาพที่เห็นหน้าคนเป็นข้อมูลส่วนบุคคล หลักสามข้อนี้จึงใช้กับภาพจากกล้องโดยตรง
การเก็บรวบรวมข้อมูลส่วนบุคคล ให้เก็บรวบรวมได้เท่าที่จำเป็นภายใต้วัตถุประสงค์อันชอบด้วยกฎหมายของผู้ควบคุมข้อมูลส่วนบุคคล
ข้อมูลส่วนบุคคลที่จะมีการเก็บรวบรวมและระยะเวลาในการเก็บรวบรวมไว้ ทั้งนี้ ในกรณีที่ไม่สามารถกำหนดระยะเวลาดังกล่าวได้ชัดเจน ให้กำหนดระยะเวลาที่อาจคาดหมายได้ตามมาตรฐานของการเก็บรวบรวม
จัดให้มีระบบการตรวจสอบเพื่อดำเนินการลบหรือทำลายข้อมูลส่วนบุคคลเมื่อพ้นกำหนดระยะเวลาการเก็บรักษา หรือที่ไม่เกี่ยวข้องหรือเกินความจำเป็นตามวัตถุประสงค์ในการเก็บรวบรวมข้อมูลส่วนบุคคลนั้น
เมื่ออ่านกับข้อ 3.2.3 จะเห็นว่าสองฉบับชี้ทางเดียวกัน ฉบับหนึ่งเป็นกฎหมาย (PDPA) อีกฉบับเป็นแนวปฏิบัติ ส่วนที่เป็นหน้าที่จริงคือมาตรา 22 มาตรา 23 (3) และมาตรา 37 (3) ส่วนที่แนวปฏิบัติเพิ่มเข้ามาคือวิธีทำ เช่น ตรวจว่าค่าที่ตั้งในเครื่องตรงกับนโยบาย
ข้อสังเกตจากการอ่านสองฉบับคู่กัน: ตัวเลขที่ประกาศไว้ในป้ายหรือประกาศความเป็นส่วนตัว (มาตรา 23 (3)) ต้องตรงกับที่เครื่องทำจริง ถ้าป้ายเขียน 30 วันแต่ดิสก์เก็บได้จริง 11 วัน ข้อความที่แจ้งกับสิ่งที่ทำก็ไม่ตรงกันแล้ว
วัตถุประสงค์แต่ละแบบ ควรใช้อะไรกำหนดวันเก็บ?
ตารางด้านล่างเป็นเครื่องมือช่วยคิดของผู้เขียน ไม่ใช่ตารางจากแนวปฏิบัติหรือกฎหมาย และไม่มีตัวเลขวันให้ เพราะตัวเลขต้องมาจากข้อมูลของแต่ละที่ ช่องขวาสุดคือคำถามที่ควรตอบด้วยข้อมูลจริงก่อนตั้งค่าเครื่อง
| วัตถุประสงค์ของกล้อง | ปัจจัยหลักที่กำหนดวันเก็บ | คำถามที่ต้องตอบด้วยข้อมูลจริง |
|---|---|---|
| ป้องกันการบุกรุกและขโมยหน้าร้านหรือสำนักงาน | ปกติรู้เหตุเมื่อไร (เปิดร้านเช้าวันถัดไป หรือตรวจสต็อกปลายสัปดาห์) | ย้อนดูเหตุปีที่ผ่านมา เหตุถูกพบหลังเกิดกี่วัน |
| ดูแลเหตุทะเลาะวิวาทหรืออุบัติเหตุในพื้นที่บริการ | ผู้เกี่ยวข้องมักร้องเรียนหรือแจ้งประกันภายในกี่วัน | มีข้อร้องเรียนที่มาถึงช้าที่สุดกี่วัน |
| ตรวจเหตุของหายในที่พัก ห้องพักอาศัย หรือพื้นที่ส่วนกลาง | ผู้พักรู้ว่าของหายตอนไหน และขั้นตอนแจ้งนิติบุคคลหรือเจ้าของอาคารใช้เวลาเท่าไร | ระยะระหว่างเกิดเหตุกับวันที่มีคนแจ้ง |
| ควบคุมการเข้าออกอาคารและลานจอดรถ | ความเสี่ยงที่ต้องย้อนดูผู้เข้าออก และรอบการเก็บค่าจอดหรือตรวจบัตร | เคยมีเหตุที่ต้องย้อนดูเกินรอบปกติหรือไม่ |
| ธุรกรรมหรือพื้นที่เสี่ยงทุจริต เช่น ตู้เงินสดหรือจุดชำระเงิน | ความผิดปกติปรากฏช้าแค่ไหนกว่าจะมีรายงานหรือรายการให้ตรวจ | รอบรายงานหรือรอบปิดบัญชีที่ใช้จริง |
| คลิปที่เกี่ยวกับเหตุที่แจ้งความหรือมีข้อพิพาทแล้ว | ไม่ใช้รอบปกติ ใช้การระงับการลบชั่วคราวแทน พร้อมผู้อนุมัติและเหตุผล | ใครอนุมัติให้ระงับ และเลิกระงับเมื่อไร |
| วัตถุประสงค์ใหม่ที่เพิ่มทีหลัง เช่น ใช้ตรวจการทำงานของพนักงาน | ต้องทบทวนความชอบด้วยกฎหมายและความจำเป็นใหม่ก่อน ไม่ขยายรอบเก็บเงียบ ๆ | วัตถุประสงค์นี้อยู่ในประกาศที่แจ้งไว้หรือไม่ |
แถวสุดท้ายมาจากข้อ 3.2.3 ที่ให้ “ทบทวน Retention เมื่อวัตถุประสงค์หรือข้อกำหนดเปลี่ยน” เป็นมาตรการพึงปฏิบัติทุกระดับ และข้อ 2.3.1 ของเล่มเดียวกันที่ให้ทบทวนความชอบด้วยกฎหมายก่อนใช้งานใหม่เมื่อวัตถุประสงค์เปลี่ยนอย่างมีนัยสำคัญ
ถ้ายังไม่เคยเขียนเหตุผลเรื่องจำนวนวันเก็บข้อมูลชนิดใดมาก่อน ดูวิธีทำตารางทั้งองค์กรได้ใน ตารางเก็บข้อมูลกี่ปี ทำอย่างไรให้ผู้ตรวจรับ
คลิปที่ต้องเก็บเกินรอบปกติ ทำอย่างไรไม่ให้ถูกเขียนทับ?
ต้องมีขั้นตอนดึงคลิปออกจากรอบเขียนทับก่อนที่รอบจะมาถึง แนวปฏิบัติแยกเรื่องนี้เป็นมาตรการเฉพาะสองข้อ คือ แยกและป้องกันข้อมูลเหตุการณ์ที่ต้องเก็บเกินรอบปกติ และมีกระบวนการระงับการลบชั่วคราว (Hold) พร้อมเหตุผลและผู้อนุมัติ
ในทางปฏิบัติสำหรับร้านเล็กคือ ให้คนที่ได้รับมอบหมายสองคนมีสิทธิส่งออกคลิปได้ ส่งออกไปเก็บในที่แยก จดวันที่ เหตุผล และชื่อผู้อนุมัติไว้ แล้วตั้งวันทบทวนว่าจะลบเมื่อไร ถ้าเหตุนั้นไปถึงตำรวจหรือคู่กรณี ดูแนวคิดเรื่องการเปิดเผยใน ตำรวจขอข้อมูลลูกค้า บริษัทส่งให้ได้แค่ไหน
สรุปมาตรการข้อ 3.2.3 ตามระดับในแนวปฏิบัติ (ย่อความจากตารางของข้อนั้น):
| มาตรการ (ย่อความ) | B | E | H |
|---|---|---|---|
| กำหนดระยะเวลาเก็บพร้อมเหตุผลรองรับ | พึงปฏิบัติ | พึงปฏิบัติ | พึงปฏิบัติ |
| ตั้งค่าให้ลบ เขียนทับ หรือทำลายเมื่อครบกำหนด | พึงปฏิบัติ | พึงปฏิบัติ | พึงปฏิบัติ |
| ตรวจค่าที่ตั้งจริงกับนโยบาย | ควรพิจารณา | พึงปฏิบัติ | พึงปฏิบัติ |
| ครอบคลุมข้อมูลในเครื่องบันทึก อุปกรณ์ปลายทาง คลาวด์ ข้อมูลสำรอง และไฟล์ที่ส่งออก | ควรพิจารณา | พึงปฏิบัติ | พึงปฏิบัติ |
| แยกและป้องกันข้อมูลเหตุการณ์ที่ต้องเก็บเกินรอบ | ควรพิจารณา | พึงปฏิบัติ | พึงปฏิบัติ |
| มีกระบวนการระงับการลบชั่วคราว พร้อมเหตุผลและผู้อนุมัติ | ควรพิจารณา | พึงปฏิบัติ | พึงปฏิบัติ |
| ทบทวน Retention เมื่อวัตถุประสงค์หรือข้อกำหนดเปลี่ยน | พึงปฏิบัติ | พึงปฏิบัติ | พึงปฏิบัติ |
แถวที่ 4 ควรสังเกตเป็นพิเศษ กล้องหนึ่งตัวอาจทิ้งภาพไว้หลายที่ ทั้งในเครื่องบันทึก ในการ์ดของกล้อง ในคลาวด์ของผู้ให้บริการ ในไฟล์สำรอง และในคลิปที่คนส่งออกไปเก็บไว้ในมือถือ ถ้ากำหนดรอบเก็บแค่ที่เครื่องบันทึก ภาพก็ยังอยู่ที่อื่นต่อ ซึ่งขัดกับตัวเลขที่ประกาศไว้
ระดับ B E H เป็นระดับความเข้มของมาตรการตามที่แนวปฏิบัติเลือกใช้ การอยู่ระดับ B ไม่ได้แปลว่าเป็นกิจการเล็กเสมอไป และการอยู่ระดับ H ไม่ได้แปลว่าเป็นโครงสร้างพื้นฐานสำคัญตามกฎหมายไซเบอร์ ข้อ 2.1.3 ของแนวปฏิบัติบอกให้ประเมินจากผลกระทบ ไม่ใช่จากชื่อหรือขนาดของสถานที่
ดิสก์เท่าไรถึงพอ ตามสูตรข้อ 3.2.4?
ใช้สูตรที่แนวปฏิบัติให้ไว้ในข้อ 3.2.4.1 ซึ่งเป็นการประมาณขั้นพื้นฐาน และต้องคำนวณก่อนซื้อเครื่อง ข้อ 3.2.4 เปิดด้วยการบอกเวลาและเหตุผลที่ต้องคำนวณ
การคำนวณพื้นที่จัดเก็บควรดำเนินการก่อนจัดซื้อและตรวจสอบอีกครั้งหลังเปิดใช้งาน โดยปริมาณข้อมูลจริงขึ้นอยู่กับหลายปัจจัย เช่น Bitrate, Codec, Frame Rate, Scene Complexity, รูปแบบการบันทึกและ Metadata
พื้นที่ต่อกล้องต่อวัน (GB) ≈ Bitrate (Mbps) × 10.8 ดังนั้น พื้นที่รวม (GB) ≈ Bitrate × 10.8 × จำนวนกล้อง × จำนวนวันที่เก็บ
ตัวคูณ 10.8 มาจากการแปลงหน่วย (เลขคณิตของผู้เขียน ไม่ใช่ข้อความจากแนวปฏิบัติ) หนึ่งเมกะบิตต่อวินาทีเท่ากับ 0.125 เมกะไบต์ต่อวินาที คูณ 86,400 วินาทีต่อวัน ได้ราว 10,800 เมกะไบต์ หรือ 10.8 กิกะไบต์ต่อวัน ดังนั้นกล้องที่บันทึกต่อเนื่องที่ 1 Mbps ตลอด 24 ชั่วโมงใช้ดิสก์ประมาณ 10.8 GB ต่อวัน
แนวปฏิบัติยกตัวอย่างไว้เองหนึ่งชุด กล้อง 16 ตัว Bitrate เฉลี่ย 6 Mbps เก็บ 30 วัน คำนวณได้ 6 × 10.8 × 16 × 30 ราว 31,104 GB หรือประมาณ 31 TB และกำกับต่อทันทีว่าตัวเลขนี้ยังไม่รวมส่วนที่ต้องเผื่อเพิ่ม
ค่าดังกล่าวเป็นความจุข้อมูลโดยประมาณ ยังไม่รวม RAID, Hot Spare, File System Overhead, Reserved Capacity และพื้นที่สำรองอื่น
ตัวอย่างสมมติสามแบบ (ตัวเลขทั้งหมดผู้เขียนสมมติขึ้นเพื่อแสดงวิธีคิด)
ตารางนี้ใช้สูตรข้อ 3.2.4.1 ตามตัวอักษร ตัวเลขกล้อง Bitrate และจำนวนวันเป็นสมมติ ไม่ได้มาจากร้านหรืออาคารจริง และไม่ใช่ค่าแนะนำ ผลลัพธ์คือความจุข้อมูลโดยประมาณก่อนบวก RAID และพื้นที่สำรอง
| กรณีสมมติ | กล้อง | Bitrate เฉลี่ย | เก็บ | ต่อกล้องต่อวัน | รวมประมาณ |
|---|---|---|---|---|---|
| ร้านกาแฟเล็ก | 4 ตัว | 2 Mbps | 14 วัน | 21.6 GB | 1,209.6 GB (ราว 1.2 TB) |
| ร้านอาหารหลายห้อง | 8 ตัว | 4 Mbps | 15 วัน | 43.2 GB | 5,184 GB (ราว 5.2 TB) |
| ร้านอาหารเดียวกัน ขยายรอบเก็บ | 8 ตัว | 4 Mbps | 30 วัน | 43.2 GB | 10,368 GB (ราว 10.4 TB) |
| อาคารชุดขนาดกลาง | 32 ตัว | 4 Mbps | 30 วัน | 43.2 GB | 41,472 GB (ราว 41.5 TB) |
แถวที่ 2 กับแถวที่ 3 คือบทเรียนของตาราง ร้านเดียว กล้องชุดเดียว แต่เพิ่มรอบเก็บจาก 15 เป็น 30 วัน ดิสก์ที่ต้องมีเพิ่มเป็นสองเท่าพอดี จึงต้องตัดสินใจเรื่องจำนวนวันด้วยเหตุผลก่อนไปคุยราคากับผู้ขาย ไม่ใช่รอให้ผู้ขายเสนอ
ตารางต่อไปใช้ชุดเดียวกับตัวอย่างของแนวปฏิบัติ (16 กล้อง เก็บ 30 วัน) เปลี่ยนเฉพาะ Bitrate เพื่อดูว่าตัวแปรนี้กระทบเท่าไร ตัวเลขที่ 6 Mbps ตรงกับตัวอย่างในแนวปฏิบัติ ส่วนตัวเลขอื่นผู้เขียนคำนวณเพิ่ม
| Bitrate เฉลี่ย | ต่อกล้องต่อวัน | รวม 16 กล้อง 30 วัน |
|---|---|---|
| 2 Mbps | 21.6 GB | 10,368 GB |
| 4 Mbps | 43.2 GB | 20,736 GB |
| 6 Mbps (ตามตัวอย่างในแนวปฏิบัติ) | 64.8 GB | 31,104 GB |
| 8 Mbps | 86.4 GB | 41,472 GB |
Bitrate คือจุดที่ผู้ขายกับผู้ใช้เข้าใจไม่ตรงกันบ่อยที่สุด ผู้ขายอาจเสนอจำนวนดิสก์จากค่ากลางของเครื่อง ส่วนค่าจริงขึ้นอยู่กับความละเอียด อัตราเฟรม และฉากที่กล้องเห็น ควรขอให้ระบุ Bitrate ที่ใช้คำนวณลงในใบเสนอราคา
ปัจจัยที่ทำให้ตัวเลขจริงต่างจากตัวเลขคำนวณ
ข้อ 3.2.4.2 ของแนวปฏิบัติแสดงปัจจัยเพิ่มเติมไว้ในรูปตาราง สรุปความได้ดังนี้:
- ความละเอียดภาพ (Resolution): ความละเอียดสูงขึ้นโดยทั่วไปทำให้ Bitrate เพิ่ม
- อัตราเฟรม (Frame Rate): เฟรมสูงขึ้นอาจเพิ่มข้อมูล
- ตัวบีบอัด (Codec): ประสิทธิภาพการบีบอัดแต่ละแบบต่างกัน
- CBR/VBR: ปริมาณข้อมูลจริงอาจต่างจากค่าประมาณ
- ความซับซ้อนของฉาก (Scene Complexity): ภาพที่มีการเคลื่อนไหวหรือรายละเอียดมากใช้ Bitrate สูงขึ้น
- โหมดการบันทึก (Recording Mode): บันทึกต่อเนื่องกับบันทึกเฉพาะเหตุการณ์ให้ปริมาณข้อมูลต่างกัน
- เสียงและ Metadata: เพิ่มพื้นที่จัดเก็บ
- RAID/ความซ้ำซ้อน: ทำให้ความจุที่ใช้งานได้จริงต่ำกว่าความจุดิบ
- ส่วนเผื่อการขยาย (Growth Margin): ควรเผื่อตามความเหมาะสม
จะเห็นว่าแนวปฏิบัติไม่ให้ตัวเลขเปอร์เซ็นต์ที่ต้องเผื่อสำหรับ RAID หรือการขยาย เมื่อขอใบเสนอราคา จึงควรให้ผู้ขายระบุความจุที่ “ใช้งานได้จริง” ตามรูปแบบ RAID ที่เสนอ ไม่ใช่แค่รวมความจุของดิสก์ทุกลูก
ส่วนการบันทึกเฉพาะเหตุการณ์ (Event Recording) ช่วยลดพื้นที่ได้ แต่แลกกับความเสี่ยงที่ภาพช่วงก่อนและหลังเหตุอาจไม่ครบ ควรตัดสินใจร่วมกับข้อ POR (ความต้องการรายจุด) ของแต่ละกล้อง ไม่ใช่ตัดสินเพราะดิสก์ไม่พอ
ติดตั้งแล้วจะรู้ได้อย่างไรว่าเก็บได้ตามที่ตั้งใจ?
ต้องวัดจากเครื่องจริง ข้อ 3.2.4 ให้ตรวจซ้ำหลังเปิดใช้งาน และข้อ 3.2.4.1 ย้ำเรื่องเดียวกันอีกครั้งในตอนท้าย
การกำหนดพื้นที่จัดเก็บจริงควรใช้ค่าจากการออกแบบและทดสอบระบบจริง และควรตรวจสอบหลังเปิดใช้งานว่า ระยะเวลาที่สามารถเรียกดูภาพย้อนหลังได้จริงสอดคล้องกับระยะเวลาการเก็บรักษาที่องค์กรกำหนด
วิธีวัดที่ง่ายที่สุดคือเปิดภาพย้อนหลังของกล้องตัวที่ยุ่งที่สุด เลื่อนไปหาภาพที่เก่าที่สุดที่ยังเปิดได้ แล้วนับวัน เทียบกับตัวเลขที่ประกาศไว้ ทำซ้ำเมื่อเปลี่ยนความละเอียด เพิ่มกล้อง หรือเปลี่ยนโหมดบันทึก
สมมติว่าร้านอาหารในตารางข้างบนใช้ดิสก์ที่ได้ความจุใช้งานจริง 4 TB (ประมาณ 4,000 GB) ที่ 345.6 GB ต่อวัน (8 กล้อง × 43.2 GB) จะย้อนดูภาพได้ราว 11.6 วัน ไม่ถึง 15 วันที่ตั้งใจ ถ้าป้ายหรือประกาศเขียน 15 วันไว้แล้ว ต้องเพิ่มดิสก์ ลดจำนวนวัน หรือลด Bitrate อย่างใดอย่างหนึ่ง และแก้ข้อความที่ประกาศให้ตรงกับสิ่งที่ทำ
- ก่อนจัดซื้อตั้งจำนวนวันพร้อมเหตุผล แล้วคำนวณดิสก์ด้วยสูตร ให้ผู้ขายระบุ Bitrate และความจุใช้งานจริงในใบเสนอราคาข้อ 3.2.3 · ข้อ 3.2.4
- หลังเปิดใช้งานวัดจำนวนวันที่ย้อนดูได้จริง จดวิธีคำนวณและผลวัดเก็บไว้เป็นหลักฐานข้อ 3.2.4.1 · ข้อ 3.2.4.3
- เมื่อเปลี่ยนกล้อง ความละเอียด หรือโหมดบันทึกคำนวณใหม่และวัดซ้ำ เพราะ Bitrate เปลี่ยนแล้วจำนวนวันเปลี่ยนตามข้อ 3.2.4.2
- เมื่อวัตถุประสงค์หรือข้อกำหนดเปลี่ยนทบทวนระยะเวลาเก็บและแก้ประกาศหรือป้ายถ้าจำเป็นข้อ 3.2.3 · PDPA มาตรา 23 (3)
- เมื่อมีเหตุที่ต้องเก็บคลิปเกินรอบระงับการลบชั่วคราวเฉพาะคลิปนั้น บันทึกผู้อนุมัติและเหตุผล แล้วกำหนดวันทบทวนข้อ 3.2.3
RAID ใช่ที่สำรองข้อมูลไหม และ log ต้องแยกดิสก์หรือเปล่า?
RAID ไม่ใช่ที่สำรองข้อมูล และ log ควรแยกดิสก์ออกจากภาพ ทั้งสองข้อมีเขียนไว้ตรง ๆ ในข้อ 3.2.4.3 ซึ่งเปิดด้วยหลักว่าพื้นที่จัดเก็บต้องบริหารต่อเนื่อง ไม่ใช่ดูแค่วันติดตั้ง
พื้นที่จัดเก็บของระบบ CCTV ต้องได้รับการบริหารให้สามารถเก็บและเรียกใช้ข้อมูลได้ตามวัตถุประสงค์ มิใช่พิจารณาเฉพาะความจุของดิสก์ในวันที่ติดตั้ง
การทำ RAID ช่วยเพิ่มความทนทานต่อความเสียหายของดิสก์บางกรณี แต่ ไม่ถือเป็นการสำรองข้อมูล (Backup)
ส่วน Log การใช้งาน (เช่น การเข้าสู่ระบบ การเปลี่ยนค่า การส่งออกภาพ) มีขนาดเล็กมาก โดยทั่วไปไม่กี่เมกะไบต์ต่ออุปกรณ์ต่อเดือน แต่ต้องเก็บนานกว่าภาพ และควรเก็บแยกจากดิสก์ภาพเพื่อไม่ให้ถูกเขียนทับ
ข้อนี้เชื่อมกับเรื่องกฎหมาย log อีกฉบับหนึ่ง พ.ร.บ.คอมพิวเตอร์ฯ มาตรา 26 วางหน้าที่เก็บข้อมูลจราจรไม่น้อยกว่า 90 วันไว้กับ “ผู้ให้บริการ” และให้รัฐมนตรีประกาศว่าใช้กับผู้ให้บริการประเภทใด
ว่าระบบกล้องของคุณมี log ที่เข้าข่ายหรือไม่ ขึ้นกับว่าคุณเป็นผู้ให้บริการตามกฎหมายนั้นหรือเปล่า บทความนี้ไม่ตอบแทน ให้อ่านต่อใน ลูกค้าขอลบข้อมูล แต่กฎหมายสั่งเก็บ log 90 วัน ต้องทำอย่างไร ที่แยกเรื่องนี้ไว้ ที่บทความนี้ยืนยันได้มีเพียงหลักของแนวปฏิบัติ ว่า log ใช้พื้นที่น้อยแต่ควรอยู่รอดนานกว่าภาพ
ระบบ AIPDPA มีกฎระยะเวลาเก็บและบันทึกการทำลายสำหรับข้อมูลส่วนบุคคลทั่วไปให้บันทึกเหตุผลของตัวเลขวันได้ ดูหน้าจอจริงที่ บัญชีตัวอย่าง ส่วนการตั้งค่าเครื่องบันทึกกล้องยังต้องทำที่ตัวเครื่องหรือระบบ VMS ของคุณเอง
ความผิดพลาดเรื่องวันเก็บภาพที่เจอบ่อย คืออะไรบ้าง?
แนวปฏิบัติเตือนว่าไม่ควรกำหนด Retention จากขนาดพื้นที่จัดเก็บที่มีอยู่ ให้เริ่มจากวัตถุประสงค์และเวลาที่ใช้ตรวจพบเหตุ
ข้อ 3.2.3 บอกว่าไม่ควรเก็บนานที่สุดเพียงเพราะเทคโนโลยีรองรับ ส่วน PDPA มาตรา 22 ให้เก็บเท่าที่จำเป็นต่อวัตถุประสงค์ที่ชอบด้วยกฎหมาย
มาตรา 23 (3) ให้แจ้งระยะเวลาเก็บ ต้องวัดย้อนหลังหลังเปิดใช้งานตามข้อ 3.2.4.1 แล้วแก้ตัวเลขหรือแก้ดิสก์ให้ตรงกัน
สูตรตามข้อ 3.2.4.1 ยังไม่รวม RAID, Hot Spare, File System Overhead, Reserved Capacity
ข้อ 3.2.3 ให้กำหนดระยะเวลาให้ครอบคลุมข้อมูลทุกที่ที่เกี่ยวข้อง และ PDPA มาตรา 37 (3) ให้มีระบบตรวจเพื่อลบหรือทำลายเมื่อพ้นกำหนด
ข้อ 3.2.3 มีมาตรการระงับการลบชั่วคราวพร้อมเหตุผลและผู้อนุมัติ และมาตรา 37 (3) เปิดข้อยกเว้นให้เก็บเพื่อใช้สิทธิเรียกร้องตามกฎหมาย
สรุปเป็นขั้นตอนทำภายในหนึ่งสัปดาห์ได้อย่างไร?
- เขียนวัตถุประสงค์ของกล้องแต่ละกลุ่ม (หน้าร้าน ทางเข้า ที่จอดรถ ห้องเก็บของ) ใช้ลำดับของข้อ 2.3.1 คือวัตถุประสงค์ ความจำเป็น พื้นที่ ข้อมูล ระยะเวลา ผู้เข้าถึง
- ย้อนดูเหตุที่เคยมีคนขอดูภาพในรอบปี แล้วจดว่าแต่ละครั้งขอหลังเกิดเหตุกี่วัน
- ตั้งจำนวนวันต่อกลุ่มกล้อง พร้อมเหตุผลหนึ่งบรรทัด
- อ่านค่า Bitrate จริงจากเครื่องหรือเว็บตั้งค่าของกล้อง แล้วคำนวณด้วยสูตรข้อ 3.2.4.1
- ขอให้ผู้ขายระบุความจุใช้งานจริงหลังหักส่วน RAID และส่วนสำรองไว้ในใบเสนอราคา
- เปิดใช้งานแล้ววัดจำนวนวันที่ย้อนดูได้จริง เก็บผลวัดและวิธีคำนวณเป็นหลักฐาน
- ให้ข้อความในป้ายและประกาศความเป็นส่วนตัวตรงกับตัวเลขที่วัดได้ ทำขั้นตอนระงับการลบชั่วคราว และเก็บ log แยกจากดิสก์ภาพ
คำถามที่พบบ่อย
กฎหมายกำหนดไหมว่าต้องเก็บภาพกล้องวงจรปิดกี่วัน?
จากเอกสารที่คลังเรามี ทั้ง PDPA และแนวปฏิบัติ สกมช. ไม่กำหนดจำนวนวันตายตัวสำหรับภาพกล้อง PDPA มาตรา 22 ให้เก็บเท่าที่จำเป็น และมาตรา 23 (3) ให้แจ้งระยะเวลาเก็บ ส่วนกฎหมายเฉพาะภาคส่วนหรือสัญญาอาจกำหนดเพิ่ม ซึ่งต้องตรวจเป็นรายธุรกิจ
แนวปฏิบัติ สกมช. เรื่องกล้องวงจรปิดมีผลบังคับตามกฎหมายไหม?
ไม่มี เอกสารเขียนไว้เองในคำนำว่าเป็นเพียงข้อเสนอแนะเบื้องต้น ไม่มีสภาพบังคับใช้ และใช้แทนกฎหมายหรือสัญญาไม่ได้ ใช้เป็นเกณฑ์อ้างอิงที่ดีในการออกแบบและตรวจรับระบบ ส่วนหน้าที่ที่เป็นข้อบังคับมาจากกฎหมาย เช่น PDPA
สูตรคำนวณดิสก์กล้องวงจรปิดของแนวปฏิบัติคืออะไร?
ข้อ 3.2.4.1 ให้ประมาณพื้นที่ต่อกล้องต่อวัน (GB) เท่ากับ Bitrate (Mbps) คูณ 10.8 และพื้นที่รวมเท่ากับ Bitrate × 10.8 × จำนวนกล้อง × จำนวนวันที่เก็บ ตัวอย่างในแนวปฏิบัติคือ 16 กล้อง 6 Mbps เก็บ 30 วัน ได้ราว 31 TB ก่อนบวก RAID และพื้นที่สำรอง
ถ้าดิสก์เต็มก่อนครบจำนวนวันที่ประกาศไว้ ต้องทำอย่างไร?
เลือกได้สามทาง คือเพิ่มความจุ ลด Bitrate (เช่น ปรับความละเอียดหรืออัตราเฟรม) หรือลดจำนวนวันที่ตั้ง ถ้าเลือกลดจำนวนวัน ต้องทบทวนว่าจำนวนวันใหม่ยังตอบวัตถุประสงค์ได้ และแก้ข้อความที่แจ้งไว้ในป้ายหรือประกาศให้ตรงกัน
ต้องเก็บ log การเข้าดูภาพไว้กี่วัน?
แนวปฏิบัติข้อ 3.2.4.3 บอกเพียงว่า log ควรเก็บนานกว่าภาพและแยกจากดิสก์ภาพ โดยไม่ระบุตัวเลขวัน ส่วนหน้าที่เก็บข้อมูลจราจรตาม พ.ร.บ.คอมพิวเตอร์ฯ มาตรา 26 ใช้กับ “ผู้ให้บริการ” ตามที่รัฐมนตรีประกาศ ดูรายละเอียดในบทความเรื่อง log 90 วันกับสิทธิขอลบ
RAID ช่วยให้ไม่ต้องสำรองข้อมูลจริงไหม?
ไม่ แนวปฏิบัติข้อ 3.2.4.3 ระบุว่า RAID ไม่ถือเป็นการสำรองข้อมูล เพราะป้องกันความเสียหายไม่ได้ทุกประเภท ภาพทั่วไปไม่จำเป็นต้องสำรองทุกคลิป แต่คลิปเหตุการณ์สำคัญและค่าตั้งระบบควรมีที่สำรองตามผลประเมินความเสี่ยง
ตัวบทและแหล่งอ้างอิง
- แนวปฏิบัติการรักษาความมั่นคงปลอดภัยระบบกล้องโทรทัศน์วงจรปิดสำหรับประเทศไทย (TCSG) ฉบับ 1.0.0 โดย สกมช. (แนวปฏิบัติ ไม่ใช่กฎหมาย) — ข้อ 2.1.2 · ข้อ 3.2.3 · ข้อ 3.2.4 (3.2.4.1–3.2.4.3)
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — มาตรา 22 · มาตรา 23 (3) · มาตรา 37 (3)
- พระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 (แก้ไขถึงฉบับที่ 2 พ.ศ. 2560) — มาตรา 26
ตัวบทที่ยกมาในกรอบ "ตัวบท" คัดคำต่อคำจากคลังกฎหมายของ AIPDPA ซึ่งถอดจากราชกิจจานุเบกษาและเอกสารของหน่วยงานรัฐ แล้วระบบตรวจทุกครั้งที่แก้บทความว่าตรงกับคลังทุกตัวอักษร · บทความนี้เป็นความรู้ทั่วไป ไม่ใช่คำปรึกษากฎหมายสำหรับกรณีใดกรณีหนึ่ง
ลงมือในระบบได้ที่
ใครรับผิดชอบเนื้อหานี้?
เรียบเรียงโดยทีมกฎหมาย AIPDPA · ผู้รับผิดชอบเนื้อหา ภูวรา ครอบตะคุ ทนายความ · เนติบัณฑิตไทย · ที่ปรึกษากฎหมายเทคโนโลยีและทรัพย์สินทางปัญญา
ใบอนุญาตทนายความ 477/2558 · เนติบัณฑิตไทย · นิติศาสตรมหาบัณฑิต กฎหมายทรัพย์สินทางปัญญาและสารสนเทศ (เหรียญทอง)