การสำรองข้อมูลที่ทนต่อแรนซัมแวร์ ── กฎ 3-2-1 ที่เก็บที่เขียนทับไม่ได้ และการตรวจว่ากู้คืนได้จริง

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

ประเด็นสำคัญมี 3 ข้อ คือ มีสำเนา 1 ชุดที่ PC ที่ติดมัลแวร์เขียนทับไม่ได้ ไม่ใช้ “Previous Versions” แทนการสำรองข้อมูล และตรวจว่ากู้คืนได้จริง กฎ 3-2-1 ช่วยกำหนดจำนวนสำเนาและที่เก็บ แต่ลำพังกฎนี้ยังมีช่องโหว่ในการรับมือแรนซัมแวร์

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

หลายองค์กรมีข้อมูลสำรองแต่กู้คืนไม่ได้

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

ใน 35 กรณีที่ตอบเหตุผลที่กู้คืนไม่ได้ “ข้อมูลสำรองถูกเข้ารหัสด้วย” มี 23 กรณี “การดำเนินงานบกพร่อง” 8 กรณี และ “อื่น ๆ” 4 กรณี¹ รายงานเดียวกันระบุว่ากลุ่มแรนซัมแวร์ลบล็อกและข้อมูลสำรองของบริษัทที่ถูกโจมตี เพื่อลบร่องรอยและไม่ให้ทำการกู้คืนได้ และแนะนำให้เก็บข้อมูลสำรองไว้ในสภาพแวดล้อมแบบออฟไลน์²

flowchart TB
        accTitle: เส้นทางที่มีข้อมูลสำรองแต่กู้คืนไม่ได้
        accDescr: แผนภาพแสดงว่าแม้จะสำรองข้อมูลไว้ หากอยู่ในที่ที่ PC ที่ติดมัลแวร์เข้าถึงได้ ก็จะถูกเข้ารหัสไปด้วย และหากไม่ได้ตรวจขั้นตอนการกู้คืนไว้ ก็จะกู้คืนไม่ได้เพราะการดำเนินงานบกพร่อง
        A["มีการสำรองข้อมูล"] --> B{"PC ที่ติดมัลแวร์เข้าถึงได้หรือไม่"}
        B -->|"เข้าถึงได้"| C["ถูกเข้ารหัสหรือลบไปด้วย"]
        B -->|"เข้าถึงไม่ได้"| D{"ตรวจขั้นตอนการกู้คืนแล้วหรือไม่"}
        D -->|"ยังไม่ได้ตรวจ"| E["กู้คืนไม่ได้เพราะการดำเนินงานบกพร่อง"]
        D -->|"ตรวจแล้ว"| F["กู้คืนได้"]

ภาพ 1: ข้อมูลสำรองจะใช้ได้เมื่อ PC ที่ติดมัลแวร์เข้าถึงไม่ได้ และได้ตรวจขั้นตอนการกู้คืนไว้แล้ว

ก็มีกรณีที่กู้คืนได้เช่นกัน แนวทาง “Information Security Guidelines for SMEs” ฉบับที่ 4.0 ของ IPA มีกรณีของบริษัทก่อสร้างที่ถูกเจาะผ่านอุปกรณ์ VPN จนไฟล์เซิร์ฟเวอร์และระบบอื่นถูกเข้ารหัส บริษัทนี้ซ้อมกู้คืนปีละ 2 ครั้ง ซึ่งเป็นส่วนหนึ่งที่ช่วยให้กลับมาเปิดระบบหลักจากข้อมูลสำรองได้ 5 วันหลังพบการโจมตี ถึงอย่างนั้น การกลับมาใช้ระบบภายในต่าง ๆ ก็ใช้เวลา 41 วัน การกลับมาใช้การเข้าถึงระยะไกลใช้เวลา 4 เดือน และไฟล์ภายในบริษัทหายไปมากกว่า 20 เปอร์เซ็นต์เล็กน้อย³ แม้กู้คืนจากข้อมูลสำรองได้ ความเสียหายก็ไม่ได้หายไป

ในแผนภาพ เส้นทึบหมายถึงความสัมพันธ์ที่ถือเสมอ และเส้นประหมายถึงความสัมพันธ์ที่มีเงื่อนไข (เงื่อนไขอยู่ในการอธิบายของแต่ละความสัมพันธ์ในหน้าละเอียด) รายการความสัมพันธ์ทั้งหมด (รวม 13 รายการ พร้อมหลักฐานและระดับความเชื่อมั่น) และนิยามของแนวคิดหลักรวบรวมไว้ที่ หน้าละเอียดของแผนที่ความรู้ (เป็นภาษาญี่ปุ่น) ข้อมูล: JSON-LD / Turtle

ผู้โจมตีลบข้อมูลสำรองที่เข้าถึงได้

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

Microsoft ก็ระบุว่าผู้โจมตีมุ่งทำให้ซอฟต์แวร์สำรองข้อมูลและฟีเจอร์ของ OS อย่าง volume shadow copy ใช้งานไม่ได้⁵ ข้อมูลสำรองที่ PC ที่ติดมัลแวร์เข้าถึงได้มีตัวอย่างดังนี้

• ไดรฟ์ภายนอกที่ต่อกับ PC ไว้ตลอดเวลา
• โฟลเดอร์แชร์บน NAS หรือไฟล์เซิร์ฟเวอร์ที่กำหนดอักษรไดรฟ์ไว้
• โฟลเดอร์ซิงค์บนคลาวด์ที่บัญชีปกติเขียนได้
• shadow copy ที่อยู่บนวอลุ่มเดียวกัน (Previous Versions)

คำสั่งที่มากับ OS ก็ลบ shadow copy และแค็ตตาล็อกของการสำรองข้อมูลได้ MITRE ATT&CK จัดเทคนิคนี้ไว้ในชื่อ “Inhibit System Recovery” (T1490) โดยยกตัวอย่างการลบ shadow copy ทั้งหมดด้วย vssadmin.exe delete shadows /all /quiet และการลบแค็ตตาล็อกการสำรองข้อมูลของ Windows ด้วย wbadmin.exe delete catalog -quiet⁶ คู่มือของ CISA ก็แนะนำให้เฝ้าระวังการใช้ vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) และเครื่องมืออื่นในลักษณะที่น่าสงสัย⁴

flowchart TB
        accTitle: ข้อมูลสำรองที่ PC ที่ติดมัลแวร์เข้าถึงได้และเข้าถึงไม่ได้
        accDescr: แผนภาพแสดงว่า PC ที่ติดมัลแวร์เขียนลงไดรฟ์ภายนอกที่ต่อไว้ตลอด โฟลเดอร์แชร์ที่กำหนดอักษรไดรฟ์ โฟลเดอร์ซิงค์ และ shadow copy ได้ แต่เขียนลงสื่อที่ถอดออกแล้วและที่เก็บที่เขียนทับไม่ได้ไม่ได้
        P["PC ที่ติดมัลแวร์"] --> R["ที่ที่เขียนได้"]
        P -.-x N["สื่อที่ถอดออกและที่เก็บที่เขียนทับไม่ได้"]
        R --> A["ไดรฟ์ภายนอกที่ต่อไว้ตลอด"]
        R --> B["โฟลเดอร์แชร์ที่กำหนดอักษรไดรฟ์"]
        R --> C["โฟลเดอร์ซิงค์บนคลาวด์"]
        R --> D["shadow copy"]

ภาพ 2: ข้อมูลสำรองที่อยู่ในที่ที่ PC ที่ติดมัลแวร์เขียนได้จะกลายเป็นเป้าหมายของการโจมตี

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

“Previous Versions” ใช้แทนการสำรองข้อมูลไม่ได้

“Previous Versions” ของ Windows และ shadow copy ของโฟลเดอร์แชร์ใช้ Volume Shadow Copy (VSS) ผู้ให้บริการระบบของ VSS ที่มากับ Windows ใช้วิธี copy-on-write คือย้ายเนื้อหาของบล็อกไปเก็บไว้ในพื้นที่ส่วนต่างก่อนที่บล็อกนั้นจะถูกเขียนทับ แล้วจึงสร้างวอลุ่ม ณ เวลาหนึ่งขึ้นมาใหม่⁷

Microsoft อธิบายความต่างระหว่าง shadow copy กับการสำรองข้อมูลไว้ในเอกสาร VSS ดังนี้ เมื่อคัดลอกข้อมูลจาก shadow copy ไปยังสื่อที่ถอดออกได้อย่างเทป เนื้อหาบนสื่อนั้นคือข้อมูลสำรอง และหลังคัดลอกแล้วจะลบ shadow copy ทิ้งก็ได้⁷ เอกสารยังระบุว่าเมื่อพื้นที่ส่วนต่างไม่พอ shadow copy ที่เก่าที่สุดจะถูกลบไปตามลำดับ⁷

flowchart TB
        accTitle: ความต่างระหว่าง shadow copy กับการสำรองข้อมูล
        accDescr: แผนภาพแสดงว่า shadow copy เป็นส่วนต่างของวอลุ่มเดิมและถูกลบได้เมื่อพื้นที่ไม่พอหรือถูกโจมตี ส่วนข้อมูลสำรองที่คัดลอกไปยังสื่ออื่นยังคงอยู่แม้วอลุ่มเดิมจะหายไป
        V["วอลุ่มเดิม"] --> S["shadow copy (ส่วนต่าง)"]
        S --> L["พื้นที่ไม่พอจะลบจากเก่าสุด"]
        S --> K["ผู้โจมตีลบด้วย vssadmin"]
        S -->|"คัดลอกไปยังสื่ออื่น"| B["ข้อมูลสำรอง"]
        B --> R["ยังอยู่แม้วอลุ่มเดิมหายไป"]

ภาพ 3: shadow copy อาศัยข้อมูลบนวอลุ่มเดิม สิ่งที่คัดลอกไปยังสื่ออื่นจึงจะเป็นข้อมูลสำรอง

shadow copy สะดวกสำหรับให้ผู้ใช้กู้ไฟล์ที่เผลอเขียนทับกลับมาเอง แต่อย่างที่กล่าวในหัวข้อก่อน ผู้โจมตีอาจลบได้ รายละเอียดของกลไกและการใช้งานอธิบายไว้ใน “Volume Shadow Copy (VSS): กลไกและงานปฏิบัติ”

ดูรายการ shadow copy ที่ยังเหลืออยู่ได้โดยรัน vssadmin list shadows ใน Command Prompt แบบผู้ดูแลระบบ คำสั่งย่อยนี้ใช้ได้ทั้งบนไคลเอนต์และเซิร์ฟเวอร์⁸

vssadmin list shadows

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

กฎ 3-2-1 กำหนดจำนวนสำเนาและที่เก็บ

กฎ 3-2-1 เป็นหลักจากประสบการณ์ที่บอกวิธีถือสำเนาข้อมูลสำรอง เอกสาร “Data Backup Options” ที่จัดทำให้ US-CERT ของสหรัฐฯ ในปี 2012 อธิบายไว้ดังนี้⁹

• 3: ไฟล์สำคัญให้มีรวม 3 ชุด คือต้นฉบับ 1 ชุดและข้อมูลสำรอง 2 ชุด
• 2: เก็บไว้บนสื่อ 2 ประเภท เพื่อรับมือภัยพิบัติต่างชนิด
• 1: เก็บ 1 ชุดไว้นอกบ้านหรือนอกสำนักงาน

เอกสารนี้อ้างหนังสือการจัดการภาพถ่ายดิจิทัล “The DAM Book” ของช่างภาพ Peter Krogh เป็นที่มา⁹ Microsoft ก็ยกกฎนี้ไว้ในเอกสารการสำรองข้อมูลเพื่อรับมือแรนซัมแวร์ และอธิบาย “1” ว่าเป็น “สำเนานอกสถานที่หรือสำเนาแบบ cold”⁵

สิ่งที่กฎ 3-2-1 กำหนดคือการเก็บไว้นอกสถานที่ ไม่ได้กำหนดว่าสำเนานอกสถานที่ต้องออฟไลน์หรือเขียนทับไม่ได้ ดังนั้นถ้าสำเนานอกสถานที่อยู่บนคลาวด์ที่ PC ที่ติดมัลแวร์เขียนได้ตลอดเวลา ก็อาจถูกเข้ารหัสไปพร้อมกับสำเนาในมือ คู่มือของ CISA และเอกสารของ Microsoft ยกการเก็บแบบออฟไลน์เป็นการเตรียมรับมือแรนซัมแวร์ และ Microsoft ยังยกที่เก็บที่เขียนทับไม่ได้ด้วย⁴⁵

flowchart TB
        accTitle: กฎ 3-2-1 กับการรับมือแรนซัมแวร์
        accDescr: แผนภาพแสดงว่าให้เพิ่มสำเนาที่ออฟไลน์หรือเขียนทับไม่ได้ 1 ชุดเข้าไปในกฎ 3-2-1 ที่มีสำเนา 3 ชุด สื่อ 2 ประเภท และเก็บนอกสถานที่ 1 ชุด แล้วตรวจว่ากู้คืนได้
        A["สำเนา 3 ชุด"] --> B["สื่อ 2 ประเภท"]
        B --> C["นอกสถานที่ 1 ชุด"]
        C --> D["ออฟไลน์หรือเขียนทับไม่ได้ 1 ชุด"]
        D --> E["ตรวจว่ากู้คืนได้"]

ภาพ 4: เพิ่มสำเนาที่ PC ที่ติดมัลแวร์เขียนทับไม่ได้ และการตรวจว่ากู้คืนได้เข้าไปในกฎ 3-2-1

Veeam ผลิตภัณฑ์สำรองข้อมูล เผยแพร่เรื่องนี้ในชื่อ “กฎ 3-2-1-1-0” ในเอกสารของ Veeam “1” ที่เพิ่มขึ้นหมายถึงการมีสำเนาแบบออฟไลน์ แบบ air-gap หรือแบบเขียนทับไม่ได้ 1 ชุด และ “0” หมายถึงไม่พบข้อผิดพลาดในการตรวจการกู้คืนอย่างสม่ำเสมอ¹⁰ นี่เป็นชื่อเรียกในเอกสารของผู้จำหน่าย ไม่ใช่มาตรฐานที่เป็นทางการ แต่สองข้อที่เพิ่มขึ้นก็ตรงกับสิ่งที่ CISA และ IPA แนะนำด้วย

มีสำเนา 1 ชุดที่ PC ที่ติดมัลแวร์เขียนทับไม่ได้

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

ถอดสื่อออกจาก PC แล้วเก็บไว้

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

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

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

ใช้ที่เก็บบนคลาวด์ที่เขียนทับไม่ได้

ที่เก็บข้อมูลบนคลาวด์มีฟีเจอร์ที่ทำให้ข้อมูลถูกเขียนทับหรือลบไม่ได้ตลอดระยะเวลาที่กำหนด โดยเก็บข้อมูลในสถานะที่เรียกว่า WORM (Write Once, Read Many)

ใน immutable storage ของ Azure Blob Storage เมื่อตั้งนโยบายการเก็บรักษาตามระยะเวลา ข้อมูลจะสร้างและอ่านได้ในช่วงนั้น แต่แก้ไขหรือลบไม่ได้¹³ นโยบายจะถูกสร้างในสถานะที่ยังไม่ล็อกก่อน และล็อกหลังจากทดสอบแล้ว นโยบายที่ล็อกแล้วลบไม่ได้ และขยายระยะเวลาการเก็บรักษาได้แต่ลดไม่ได้¹³ Microsoft อธิบายว่าแม้ผู้ใช้ที่มีสิทธิ์ผู้ดูแลบัญชีก็แก้ไขหรือลบข้อมูลไม่ได้¹³

Object Lock ของ Amazon S3 มี 2 โหมด ในโหมด compliance ไม่มีใครเขียนทับหรือลบเวอร์ชันของอ็อบเจกต์ได้ตลอดระยะเวลาการเก็บรักษา รวมถึง root user ของบัญชี AWS ในโหมด governance เฉพาะผู้ใช้ที่มีสิทธิ์พิเศษเท่านั้นที่เปลี่ยนหรือลบการตั้งค่าการเก็บรักษาได้¹⁴ Object Lock ใช้ได้เฉพาะกับบักเก็ตที่เปิดใช้ versioning ของ S3¹⁴

flowchart TB
        accTitle: ตัวอย่างที่เก็บที่เขียนทับไม่ได้ 2 แบบ
        accDescr: แผนภาพแสดงว่า immutable storage ของ Azure Blob Storage ลบนโยบายที่ล็อกแล้วไม่ได้และลดระยะเวลาการเก็บรักษาไม่ได้ ส่วน S3 Object Lock ในโหมด compliance แม้ root user ก็ลบไม่ได้ และในโหมด governance เปลี่ยนได้ด้วยสิทธิ์พิเศษ
        W["ที่เก็บที่เขียนทับไม่ได้"] --> AZ["immutable storage ของ Azure Blob Storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["ล็อกแล้วลดระยะเวลาการเก็บรักษาไม่ได้"]
        S3 --> C["โหมด compliance"]
        S3 --> G["โหมด governance"]
        C --> C1["แม้ root user ก็ลบไม่ได้"]
        G --> G1["เปลี่ยนได้ด้วยสิทธิ์พิเศษ"]

ภาพ 5: ที่เก็บทั้งสองแบบปฏิเสธการเขียนทับและการลบตลอดระยะเวลาที่กำหนด ความเข้มงวดขึ้นอยู่กับการตั้งค่า

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

แยกสิทธิ์ในการจัดการข้อมูลสำรอง

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

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

เก็บไว้หลายรุ่น

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

flowchart TB
        accTitle: 3 วิธีสำหรับการมีสำเนาที่เขียนทับไม่ได้
        accDescr: แผนภาพแสดงการถอดสื่อออกแล้วเก็บไว้หรือใช้ที่เก็บที่เขียนทับไม่ได้ การแยกสิทธิ์ในการจัดการข้อมูลสำรองออกจากบัญชีที่ใช้ประจำ และการเก็บไว้หลายรุ่น
        A["สำเนาที่เขียนทับไม่ได้"] --> B["ถอดสื่อออกแล้วเก็บ"]
        A --> C["ที่เก็บที่เขียนทับไม่ได้"]
        B --> D["แยกสิทธิ์ในการจัดการ"]
        C --> D
        D --> E["เก็บไว้หลายรุ่น"]

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

ตรวจว่ากู้คืนได้

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

แนวทางของ IPA แบ่งการดำเนินงานสำรองข้อมูลออกเป็น 3 ส่วน คือการสำรอง การเก็บรักษา และการกู้คืน สำหรับการกู้คืนให้วางแผนการกู้คืนและยืนยันว่ากู้คืนได้ถูกต้อง³ สำหรับระบบที่สำคัญต่อธุรกิจ ให้จัดการสำรองข้อมูลและขั้นตอนให้สอดคล้องกับเป้าหมายเวลาการกู้คืน (RTO) และเป้าหมายจุดการกู้คืน (RPO) และยืนยันประสิทธิผลด้วยการซ้อม RTO คือเวลาที่ใช้กู้คืนกลับไปถึงระดับเป้าหมาย ส่วน RPO คือจุดที่จะกู้คืนกลับไป หรือก็คือเวลาของข้อมูลสำรองล่าสุด¹⁵ คู่มือของ CISA ก็แนะนำให้ตรวจอย่างสม่ำเสมอว่าข้อมูลสำรองใช้ได้และไม่เสียหาย โดยคำนึงถึงการกู้คืนจากภัยพิบัติ⁴

flowchart TB
        accTitle: ขั้นตอนการทดสอบการกู้คืน
        accDescr: แผนภาพแสดงลำดับการกำหนดลำดับการกู้คืน การกู้คืนลงสภาพแวดล้อมอื่น การเทียบเวลาที่ใช้และจุดที่กู้คืนกับ RTO และ RPO และการแก้คู่มือขั้นตอน
        A["กำหนดลำดับการกู้คืน"] --> B["กู้คืนลงสภาพแวดล้อมอื่น"]
        B --> C["เทียบเวลาที่ใช้กับ RTO"]
        B --> D["เทียบจุดที่กู้คืนกับ RPO"]
        C --> E["แก้คู่มือขั้นตอน"]
        D --> E
        E -.->|"การตรวจครั้งต่อไป"| A

ภาพ 7: ลองกู้คืนดู ตรวจว่าเวลาและจุดที่กู้คืนตรงตามเป้าหมายหรือไม่ แล้วนำผลกลับไปแก้คู่มือขั้นตอน

ตรวจอะไรบ้าง

สิ่งที่ต้องตรวจสรุปได้จากเอกสารของ IPA และ Microsoft ดังนี้

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

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

ข้อควรระวังเมื่อกู้คืนหลังถูกโจมตี

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

flowchart TB
        accTitle: ลำดับการกู้คืนจากข้อมูลสำรองหลังถูกโจมตี
        accDescr: แผนภาพแสดงว่าให้กำจัดตัวแรนซัมแวร์และเส้นทางการบุกรุก เลือกข้อมูลสำรองจากช่วงเวลาที่ยังไม่ติดมัลแวร์ ตรวจว่าไม่มีมัลแวร์ แล้วจึงกู้คืนจากระบบที่มีลำดับความสำคัญสูง
        A["กำจัดตัวแรนซัมแวร์"] --> B["ตรวจเส้นทางการบุกรุกและกลไก"]
        B --> C["เลือกจุดที่ยังไม่ติดมัลแวร์"]
        C --> D["ตรวจข้อมูลสำรอง"]
        D --> E["กู้คืนจากลำดับความสำคัญสูง"]

ภาพ 8: หลังถูกโจมตี ให้กำจัดกลไกของผู้โจมตี ยืนยันจุดที่ยังไม่ติดมัลแวร์ แล้วจึงกู้คืน

ตรวจบ่อยแค่ไหน

ทั้งแนวทางของ IPA และคู่มือของ CISA แนะนำให้ตรวจการกู้คืน “อย่างสม่ำเสมอ” แต่ไม่ระบุจำนวนครั้ง¹¹⁴ บริษัทในกรณีของ IPA ที่กล่าวไว้ก่อนหน้าซ้อมกู้คืนปีละ 2 ครั้ง³ ให้กำหนดว่างานหยุดได้นานเท่าใด และจุดที่กู้คืนกลับไปเก่าได้แค่ไหน แล้วตรวจด้วยความถี่ที่ยืนยันได้ว่าทำได้ตามนั้น

สิ่งที่ต้องกำหนดก่อน

สรุปเนื้อหาที่ผ่านมาเป็นสิ่งที่ธุรกิจขนาดกลางและขนาดย่อมควรกำหนดก่อน

flowchart TB
        accTitle: ลำดับการกำหนดการสำรองข้อมูลที่ทนต่อแรนซัมแวร์
        accDescr: แผนภาพแสดงลำดับการกำหนดขอบเขต กำหนดที่เก็บสำเนาและสำเนาที่เขียนทับไม่ได้ กำหนดสิทธิ์และรุ่น กำหนด RTO และ RPO แล้วตรวจว่ากู้คืนได้
        A["กำหนดขอบเขต"] --> B["กำหนดที่เก็บสำเนา"]
        B --> C["กำหนดสำเนาที่เขียนทับไม่ได้"]
        C --> D["กำหนดสิทธิ์และรุ่น"]
        D --> E["กำหนด RTO และ RPO"]
        E --> F["ตรวจว่ากู้คืนได้"]

ภาพ 9: กำหนดตั้งแต่ขอบเขตไปจนถึงการตรวจว่ากู้คืนได้ในขั้นสุดท้ายให้ต่อเนื่องกัน

ในแนวทางของ IPA ฉบับที่ 4.0 มีการเพิ่ม “สำรองข้อมูลกันเถอะ!” เข้าไปใน “หลักความปลอดภัยสารสนเทศ 5 ข้อ” ที่ควรเริ่มทำก่อน จนกลายเป็น 6 ข้อ¹⁶ วิธีดำเนินการตามแนวทางทั้งหมดสรุปไว้ใน “Where Should SMEs Start on Security?” หากมีแผนเปลี่ยนเซิร์ฟเวอร์ ดู “Preparing for Windows Server 2016 End of Support” ประกอบด้วย

บทความที่เกี่ยวข้อง

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Volume Shadow Copy (VSS): กลไกและงานปฏิบัติ — ทำไมซอฟต์แวร์สำรองจึงคัดลอกไฟล์ที่กำลังใช้อยู่ได้
• Preparing for Windows Server 2016 End of Support

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

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

บริการที่เกี่ยวข้องกับหัวข้อนี้

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

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

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ถ้าสำรองข้อมูลไว้แล้ว เมื่อติดแรนซัมแวร์จะกู้คืนได้หรือไม่

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

ถ้า Windows มี Previous Versions แล้ว ยังต้องสำรองข้อมูลอีกหรือไม่

ยังต้องสำรอง Previous Versions คือ volume shadow copy ซึ่งเป็นส่วนต่างที่เก็บอยู่บนวอลุ่มเดิม Microsoft ถือว่าข้อมูลที่คัดลอกจาก shadow copy ไปยังสื่ออย่างเทปคือข้อมูลสำรอง แรนซัมแวร์บางตัวลบ shadow copy ด้วยเครื่องมืออย่าง vssadmin จึงควรใช้ร่วมกับการสำรองข้อมูลไว้บนสื่ออื่น

ทำตามกฎ 3-2-1 แล้วเพียงพอสำหรับรับมือแรนซัมแวร์หรือไม่

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

ควรตรวจว่ากู้คืนจากข้อมูลสำรองได้บ่อยแค่ไหน

ทั้งแนวทางของ IPA และคู่มือของ CISA บอกเพียงว่า "อย่างสม่ำเสมอ" โดยไม่ระบุจำนวนครั้ง แนวทางของ IPA มีกรณีที่บริษัทซึ่งซ้อมกู้คืนปีละ 2 ครั้งกลับมาเปิดระบบหลักได้ 5 วันหลังพบการโจมตี ให้กำหนดว่างานหยุดได้นานเท่าใด และจุดที่กู้คืนกลับไปเก่าได้แค่ไหน แล้วตรวจด้วยความถี่ที่ยืนยันได้ว่าทำได้ตามนั้น

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะงานที่มีระบบเดิมอยู่ และการตรวจสอบความขัดข้องที่มองเห็นสาเหตุได้ยาก