Backup ที่ ransomware เข้าไม่ถึง: สำเนาที่ล็อกไว้ สิทธิ์ที่แยกกัน และการซ้อม restore

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

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

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

แนวทางของ CISA ระบุอะไรเรื่อง backup

CISA คือหน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์ของสหรัฐฯ เผยแพร่เอกสาร #StopRansomware Guide ซึ่งเป็นแนวทางเตรียมรับและตอบสนองเหตุ ransomware เอกสารฉบับที่เราอ่านลงวันที่เดือนกันยายน 2023 (ดูหน้าเอกสารของ CISA) ส่วนที่เกี่ยวกับ backup ในหัวข้อการเตรียมตัวรับเหตุ ระบุเรื่องเหล่านี้

• ให้เก็บ backup ของข้อมูลสำคัญแบบ offline และเข้ารหัส เหตุผลที่เอกสารให้ไว้คือ ransomware หลายตระกูลพยายามหา backup ที่เข้าถึงได้แล้วลบหรือเข้ารหัสทิ้ง

• ให้ ทดสอบ ความพร้อมใช้และความสมบูรณ์ของ backup ในสถานการณ์กู้ระบบ และทดสอบขั้นตอน backup เป็นประจำ

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

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

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

เอกสารนี้ผูกพันใคร และไม่ผูกพันใคร

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

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

อะไรทำให้ backup รอดจากผู้โจมตีได้

เมื่อมองระบบ backup ในมุมของผู้ออกแบบ เรามองหาคุณสมบัติสามอย่าง ข้อแรกและข้อสามมาจากแนวทางของ CISA โดยตรง ข้อสองเป็นข้อสรุปของเราเอง

หนึ่ง สำเนาอย่างน้อยหนึ่งชุดอยู่นอกระยะที่ผู้โจมตีเอื้อมถึง

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

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

สอง ข้อมูลประจำตัวของระบบ backup แยกจากระบบหลัก

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

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

สาม restore ที่เคยซ้อมจริงจากสำเนาชุดที่ปลอดภัย

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

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

ช่องที่ backup มักเข้าถึงได้โดยไม่มีใครตั้งใจ

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

• โฟลเดอร์หรือ share สำหรับ backup ที่ถูก mount อยู่บนเซิร์ฟเวอร์ผลิตจริงตลอดเวลา ถ้าเซิร์ฟเวอร์ถูกเข้ารหัสไฟล์ โฟลเดอร์นั้นก็ถูกเข้ารหัสไปด้วย

• Snapshot ที่อยู่ในบัญชี Cloud เดียวกับเครื่องที่ถูกสำรอง ผู้ที่ได้สิทธิ์ผู้ดูแลบัญชีนั้นลบ snapshot ได้พร้อมกับเครื่อง

• ตัวโปรแกรม backup ที่รันด้วยบัญชีที่มีสิทธิ์สูงสุดของโดเมน เพราะตั้งค่าครั้งเดียวแล้วไม่มีใครกลับมาลดสิทธิ์

• รหัสผ่านหรือ key ของระบบ backup ที่เก็บอยู่ในเอกสารบนเครื่องที่ถูกสำรอง ซึ่งทำให้ผู้โจมตีอ่านได้จากที่เดียวกัน

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

ทั้งหมดนี้ไม่ได้มาจากเอกสารของ CISA โดยตรง เป็นข้อสังเกตของเราเอง และเราไม่ได้อ้างว่าเป็นรายการครบถ้วน

คำถามที่ขอให้ผู้พัฒนาแสดงให้ดูตอนส่งมอบ

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

1. สำเนาชุดไหนที่ผู้ดูแลระบบหลักลบไม่ได้ แสดงว่าถูกล็อกด้วยกลไกอะไร และล็อกนานเท่าไร

2. ใครถือสิทธิ์ลบหรือแก้ไข backup และเป็นคนละบัญชีกับผู้ดูแลระบบผลิตจริงหรือไม่ มีกี่คน

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

4. รอบ restore ล่าสุดทำเมื่อไร จากสำเนาชุดไหน ใช้เวลาเท่าไร ขอดูบันทึกการซ้อม ไม่ใช่แค่รายงานว่า backup สำเร็จ

5. ถ้า backup ล้มเหลวหรือถูกลบ ใครได้รับแจ้ง ถ้าไม่มีการแจ้งเตือน การลบ backup อาจเงียบไปจนวันที่ต้องใช้ ซึ่งเชื่อมกับบทความเรื่องการตั้ง monitoring และ alert ที่เราเขียนไว้

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

เรื่องที่ไม่ควรทำเพียงเพราะอ่านบทความนี้

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

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

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

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

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

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

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

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

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

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

1. ไล่รายการระบบและข้อมูลที่ถ้าหายแล้วธุรกิจหยุด แล้วดูว่าแต่ละรายการมีสำเนากี่ชุด อยู่ที่ไหน

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

3. ตรวจว่าบัญชีที่ลบ backup ได้เป็นบัญชีเดียวกับบัญชีผู้ดูแลระบบหลักหรือไม่ ถ้าใช่ ให้วางแผนแยกบัญชีและกำหนดว่าใครถือ

4. เลือกสำเนาชุดที่ปลอดภัยที่สุดมาซ้อม restore หนึ่งรอบ จดเวลา คนที่ลงมือ และปัญหาที่เจอ แล้วแก้ขั้นตอนที่พัง

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

สรุป

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

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