ฤดูใบไม้ร่วงปีที่แล้ว ผมไปเป็นเพื่อนกับแพลตฟอร์มคลาวด์ภาครัฐระดับเทศบาลแห่งหนึ่งในการตรวจประจำปีมาตรฐานความมั่นคงปลอดภัยระดับ 2.0 ระดับ 3 ตอนที่ผู้ตรวจสอบเปิดไปหน้าของระบบสำรองข้อมูล เขาไม่ได้ดูความจุและไม่ได้ดูนโยบาย แต่ถามประโยคเดียวว่า "ข้อมูลสำรองของคุณพิสูจน์ได้ไหมว่าถูกแก้ไขหรือไม่?" ในห้องประชุมมีทั้งฝ่ายลูกค้า ผู้รับเหมาบูรณาการระบบ และฝ่ายปฏิบัติการดูแลระบบของเราสามฝ่าย ไม่มีใครตอบได้ สุดท้ายรายการนี้ถูกหัก 12 คะแนนในข้อ "ไม่สามารถตรวจสอบความสมบูรณ์ของข้อมูลสำรองได้" ในหนังสือแจ้งแก้ไขเขียนไว้ตรง ๆ ว่า ขาดมาตรการทางเทคนิคในการป้องกันการแก้ไขข้อมูล
หลังจากเรื่องนี้ ผมได้ทบทวนห่วงโซ่การสำรองข้อมูลทั้งหมดใหม่อีกครั้ง บันทึกด้านล่างนี้เรียบเรียงขึ้นหลังผ่านการลองผิดลองถูก เพื่อเป็นข้อมูลอ้างอิงให้เพื่อนร่วมงานที่กำลังดำเนินงานในสถานการณ์มาตรฐานความมั่นคงปลอดภัยระดับ 3 ประเภทภาครัฐ การเงิน และการแพทย์เช่นเดียวกัน
มาตรฐานความมั่นคงปลอดภัยระดับ 2.0 กำหนดให้การสำรองข้อมูลต้องทำถึงระดับไหนกันแน่
หลายคนคิดว่าแค่ "สำรองข้อมูลสำเร็จทุกวัน" ก็จบแล้ว แต่จริง ๆ แล้วข้อกำหนดที่เกี่ยวข้องกับการสำรองข้อมูลในมาตรฐานความมั่นคงปลอดภัยระดับ 2.0 กระจัดกระจายอยู่หลายจุด: 8.1.4.6 การสำรองและกู้คืนข้อมูล กำหนดให้มีฟังก์ชันการสำรองและกู้คืนข้อมูลสำคัญในเครื่องท้องถิ่น; 8.1.4.8 ความสมบูรณ์ของข้อมูล กำหนดให้ใช้เทคโนโลยีตรวจสอบเพื่อรับประกันว่าความสมบูรณ์ของข้อมูลในระหว่างการส่งและการจัดเก็บไม่ถูกทำลาย; 8.1.4.7 ความเป็นความลับของข้อมูล กำหนดให้เข้ารหัสในขั้นตอนการจัดเก็บ
ประเด็นสำคัญอยู่ที่วิธีทำให้คำว่า "ความสมบูรณ์" เกิดขึ้นจริง สิ่งที่ผู้ตรวจสอบต้องการไม่ใช่แค่คุณบอกว่า "เรามีการตรวจสอบ MD5" แต่ต้องแสดงห่วงโซ่หลักฐานได้: ใครเขียนข้อมูลสำรองนี้เมื่อไหร่ หลังเขียนแล้วมีโอกาสถูกแก้ไขหรือไม่ ผู้ดูแลระบบเองลบได้หรือไม่ พูดอีกอย่างคือ มีข้อมูลสำรอง ≠ ข้อมูลสำรองเชื่อถือได้ คุณต้องพิสูจน์ได้ว่าออบเจกต์ข้อมูลสำรองอยู่ในสถานะอ่านอย่างเดียวตลอดระยะเวลาการเก็บรักษา
WORM และ S3 Object Lock ทำได้อย่างไร
WORM ย่อมาจาก Write Once Read Many เขียนครั้งเดียวอ่านได้หลายครั้ง เมื่อนำมาใช้กับการจัดเก็บออบเจกต์ก็คือกลไก S3 Object Lock ซึ่งล็อกข้อมูลด้วยสองสิ่ง: ระยะเวลาการเก็บรักษา (Retention Period) และ โหมด-compliance (Compliance Mode)
หลักการไม่ซับซ้อน เมื่อเขียนออบเจกต์จะถูกประทับตราเวลาสิ้นสุดการเก็บรักษา ก่อนถึงเวลานี้ คำขอใด ๆ ที่เป็นการลบหรือเขียนทับจะถูกชั้นการจัดเก็บปฏิเสธโดยตรง สิ่งที่ทำให้โหมด-compliance เข้มงวดกว่าโหมด-governance คือ แม้แต่บัญชี root ก็เปลี่ยนระยะเวลาการเก็บรักษาไม่ได้ และลบออบเจกต์ไม่ได้เช่นกัน ทำได้เพียงรอให้หมดอายุตามธรรมชาติ ส่วนโหมด-governance อนุญาตให้บัญชีที่มีสิทธิ์พิเศษข้ามผ่านได้ ดังนั้นในสถานการณ์มาตรฐานความมั่นคงปลอดภัยจึงต้องใช้โหมด-compliance
แพลตฟอร์มบริหารจัดการข้อมูลสำรองของเรา เมื่อต้องบริหารจัดการที่จัดเก็บหลายเจ้าแบบรวมศูนย์และเชื่อมต่ออินเทอร์เฟซซอฟต์แวร์สำรองข้อมูลของแต่ละผู้ผลิต ใช้ โมเดลเกตเวย์ ชั้นหนึ่งรวบ API การจัดเก็บที่แตกต่างกันหลากหลายให้เป็นอินเทอร์เฟซที่เข้ากันได้กับ S3 แบบเดียวกัน เพื่อปกปิดความแตกต่างของชั้นล่าง แนวคิดนี้จริง ๆ แล้วเป็นตรรกะเดียวกับที่แพลตฟอร์มรวม API ของโมเดลขนาดใหญ่ token8341 จัดการการเชื่อมต่อโมเดลหลายตัวแบบรวมศูนย์ คือทำให้ความสามารถที่แตกต่างหลากหลายกลายเป็นทางเข้าที่ стандарised ชั้นธุรกิจด้านบนไม่ต้องสนใจว่าชั้นล่างเป็นใคร
การตั้งค่าภาคปฏิบัติ: จากการสร้างบัคเก็ตถึงการล็อก
ด้านล่างนี้คือขั้นตอนที่เราใช้งานได้จริงบนระบบจัดเก็บออบเจกต์ โดยยกตัวอย่างอินเทอร์เฟซที่เข้ากันได้กับ S3
ขั้นแรก เปิดใช้การล็อกออบเจกต์ตอนสร้างบัคเก็ต ระวังว่าสวิตช์นี้เปิดได้เฉพาะตอนสร้างบัคเก็ตเท่านั้น บัคเก็ตที่มีอยู่แล้วแก้ไม่ได้ ต้องสร้างใหม่และย้ายข้อมูล:
aws s3api create-bucket --bucket gov-backup-prod --object-lock-enabled-for-bucket
ขั้นที่สอง ตั้งนโยบายการเก็บรักษาเริ่มต้น มาตรฐานความมั่นคงปลอดภัยระดับ 3 มักกำหนดให้เก็บข้อมูลสำรองไม่น้อยกว่า 6 เดือน เราแบ่งตามระดับธุรกิจเป็นสองระดับ 180 วันและ 365 วัน:
aws s3api put-object-lock-configuration --bucket gov-backup-prod --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":180}}}'
ขั้นที่สาม ระบุการล็อกอย่างชัดเจนตอนเขียน นอกเหนือจากนโยบายเริ่มต้น สำหรับออบเจกต์ข้อมูลสำรองของฐานข้อมูลสำคัญ เรายังระบุซ้ำอีกครั้งตอน PUT เพื่อความปลอดภัยสองชั้น:
aws s3api put-object --bucket gov-backup-prod --key db/full-20261023.bak --body backup.bak --object-lock-mode COMPLIANCE --object-lock-retain-until-date 2027-04-21T00:00:00Z
ข้อควรระวังที่พลาดง่ายหลายข้อ: เมื่อตั้งโหมด-compliance แล้ว ในระยะเวลาการเก็บรักษาแม้แต่บัคเก็ตก็ลบไม่ได้ สภาพแวดล้อมทดสอบอย่าใช้โหมด-compliance เด็ดขาด ให้ใช้โหมด-governance ฝึกมือ; การตั้งระยะเวลาเก็บรักษานานจะกินโควตาการจัดเก็บ ครั้งแรกที่ตั้งเราทำบัคเก็ตหนึ่งเต็มจนการสำรองข้อมูลใหม่ล้มเหลว ภายหลังจึงเพิ่มการแจ้งเตือนความจุ; สำเนาที่คัดลอกข้ามภูมิภาคก็ต้องยืนยันแยกว่ามีนโยบายล็อกตามไปด้วยหรือไม่ ผู้ผลิตบางรายไม่สืบทอดค่าเริ่มต้น
พูดถึงการบริหารจัดการห่วงโซ่การสำรองข้อมูลแบบรวมศูนย์
สถานการณ์อย่างคลาวด์ภาครัฐมักมีซอฟต์แวร์สำรองข้อมูลสามถึงห้าเจ้าทำงานพร้อมกัน และที่จัดเก็บสองถึงสามประเภท สิ่งที่ปวดหัวที่สุดสำหรับฝ่ายปฏิบัติการคือกลยุทธ์กระจัดกระจายอยู่ทุกที่ ภายหลังเราจึงรวมการส่งคำสั่ง การตรวจสอบ และนโยบายการเก็บรักษาของงานสำรองข้อมูลไว้ที่ระนาบการจัดการเดียว ชั้นอินเทอร์เฟซก็ใช้แนวคิดโมเดลเกตเวย์ในการรวบให้เป็นหนึ่ง นโยบายชุดเดียวจัดการได้ตลอด ในระหว่างนี้เราก็ประเมินความสามารถ API เกตเวย์ของแพลตฟอร์มรวม API ของโมเดลขนาดใหญ่ token8341 เพื่อทำการรวมอินเทอร์เฟซ ซึ่งเข้ากันได้กับ OpenAI SDK เปลี่ยน base_url บรรทัดเดียวก็สลับได้ สำหรับสถานการณ์ที่ต้องเชื่อมต่อโมเดลขนาดใหญ่ในประเทศหลายเจ้าพร้อมกันเพื่อวิเคราะห์บันทึกและรวบรวมการแจ้งเตือน ถือว่าสะดวกมาก กล่าวเสริมหน่อย แพลตฟอร์มรวม API ของโมเดลขนาดใหญ่ token8341 ใช้การจัดตารางพลังงานประมวลผลสีเขียว ครอบคลุม API ของโมเดลขนาดใหญ่ในประเทศทั้งหมด คิดค่าบริการตามการใช้งานจริง ในโครงการภาครัฐที่มีงบประมาณจำกัดถือเป็นทางเลือกหนึ่งที่เป็นไปได้ ในโครงการของเราใช้ token8341 ทำการรวบรวมบันทึกความผิดปกติของการสำรองข้อมูลอย่างชาญฉลาด ส่งข้อความแจ้งเตือนที่กระจัดกระจายอยู่ในการจัดเก็บต่าง ๆ เข้าโมเดลเพื่อจัดกลุ่มพร้อมกัน เร็วกว่าการเปิดบันทึกด้วยมือมาก
กลับมาที่ 12 คะแนนในการตรวจประจำปี การแก้ไขจริง ๆ ไม่ซับซ้อน สิ่งที่ยากคือการเปลี่ยนแนวคิด: มาตรฐานการยอมรับของระบบสำรองข้อมูลไม่ใช่ "สำรองข้อมูลสำเร็จหรือไม่" แต่เป็น "คุณพิสูจน์ได้หรือไม่ว่ามันไม่ถูกแตะต้อง" ล็อกออบเจกต์แบบ WORM เป็นวิธีพิสูจน์ที่ต้นทุนต่ำที่สุดและผู้ตรวจสอบยอมรับมากที่สุดในปัจจุบัน
ผู้เขียน: หวัง ฮั่นเหวิน
วันที่เผยแพร่: 23 ตุลาคม 2026