โรงแรมควรสำรองข้อมูลบ่อยแค่ไหน?

ความถี่ต้องอ้างอิง RPO ของแต่ละระบบ ระบบธุรกรรมสำคัญอย่าง PMS อาจต้องสำรองหรือทำ Replication ทุก 15 ถึง 30 นาที ขณะที่ระบบบัญชีบางส่วนอาจรับการสำรองรายวันได้ แต่ทุกงานต้องมีการตรวจสอบผลและทดลองกู้คืนจริง

หลัก Backup 3-2-1-1-0 คืออะไร?

หลักนี้กำหนดให้มีข้อมูลอย่างน้อย 3 ชุด อยู่บนสื่อ 2 ประเภท มี 1 ชุดนอกสถานที่ และอีก 1 ชุดเป็น Offline หรือ Immutable ส่วนเลข 0 หมายถึงการตรวจสอบแล้วไม่พบข้อผิดพลาดที่ยังไม่ได้แก้ไข

RPO กับ RTO ต่างกันอย่างไร?

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

เมื่อโรงแรมโดน Ransomware ควรทำอะไรเป็นอันดับแรก?

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

มี Cloud Backup แล้วต้องมี Offline Backup อีกหรือไม่?

ควรมีสำเนาที่ผู้โจมตีจากระบบ Production ไม่สามารถแก้ไขหรือลบได้ เช่น Immutable Backup หรือ Offline Backup เพราะ Cloud Storage ที่เชื่อมต่ออยู่ตลอดและใช้บัญชีสิทธิ์กว้างอาจถูกโจมตีพร้อมระบบหลักได้ ต้องตรวจ Retention, Object Lock และสิทธิ์การลบให้ชัดเจน

โรงแรมควรสำรองข้อมูลและกู้คืนระบบอย่างไรเมื่อเกิด Ransomware?

โรงแรมควรสำรองข้อมูลด้วยหลัก 3-2-1-1-0 คือมีข้อมูลอย่างน้อย 3 ชุด เก็บบนสื่อ 2 ประเภท มี 1 ชุดอยู่นอกสถานที่ มี 1 ชุดเป็นแบบ Offline หรือ Immutable และต้องตรวจสอบให้พบข้อผิดพลาด 0 รายการก่อนถือว่าสำรองสำเร็จ พร้อมกำหนด RPO (Recovery Point Objective หรือจุดข้อมูลย้อนหลังที่ยอมรับได้) และ RTO (Recovery Time Objective หรือเวลาสูงสุดที่ยอมให้ระบบหยุด) แยกตามระบบสำคัญ เมื่อเกิด Ransomware ต้องแยกเครื่องที่สงสัยออกจากเครือข่าย รักษาหลักฐาน เปิดใช้ขั้นตอนทำงานแบบ Manual ตรวจสอบ Backup ที่สะอาด แล้วจึงกู้คืนตามลำดับความสำคัญทางธุรกิจ

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

ความเข้าใจผิดที่พบบ่อยคือ Backup (การสำรองข้อมูล) เท่ากับ Disaster Recovery หรือ DR (การกู้คืนจากภัยพิบัติ) ในความเป็นจริง Backup เป็นเพียงสำเนาข้อมูล ส่วน DR ครอบคลุมคน ขั้นตอน ระบบทดแทน ลำดับการกู้คืน ช่องทางสื่อสาร และเกณฑ์ตัดสินใจกลับเข้าสู่การทำงานปกติ โรงแรมที่มีไฟล์สำรองแต่ไม่เคยทดลอง Restore (การกู้คืนข้อมูล) อาจพบในวันเกิดเหตุว่าไฟล์เสีย รหัสผ่านหาย หรือระบบรุ่นใหม่เปิดฐานข้อมูลเก่าไม่ได้

บทความนี้จึงเน้นการสร้างความสามารถในการฟื้นตัวที่วัดผลได้ ตั้งแต่การสำรวจระบบ ตั้งค่า RPO และ RTO ออกแบบ Backup ป้องกัน Ransomware เตรียมคู่มือทำงานชั่วคราว ไปจนถึงการซ้อมกู้คืน โดยใช้ตัวอย่างโรงแรมสมมติเพื่อไม่อ้างอิงชื่อกิจการจริง

Ransomware กระทบการดำเนินงานของโรงแรมส่วนใดบ้าง?

System with various wires managing access to centralized resource of server in data center

Ransomware (มัลแวร์เรียกค่าไถ่) อาจเข้ารหัสไฟล์ ปิดกั้นการเข้าถึงระบบ หรือขโมยข้อมูลก่อนเข้ารหัสเพื่อใช้กดดันซ้ำ ผลกระทบต่อโรงแรมไม่ได้จำกัดอยู่ที่คอมพิวเตอร์สำนักงาน เพราะ Endpoint (อุปกรณ์ปลายทาง) ของ Front Office, Back Office, ห้องอาหาร และฝ่ายบริหารอาจเชื่อมต่อระบบกลางหรือใช้บัญชีร่วมกัน หากสิทธิ์กว้างเกินไป มัลแวร์สามารถเข้าถึง Shared Folder และพื้นที่ Backup ที่เปิดเชื่อมต่อตลอดเวลาได้

ผลกระทบที่ต้องประเมินมีอย่างน้อย 4 ด้าน ได้แก่ Operational Impact (ผลกระทบต่อการปฏิบัติงาน) เช่น เช็กอินช้า Data Impact (ผลกระทบต่อข้อมูล) เช่น ประวัติการจองสูญหาย Compliance Impact (ผลกระทบต่อการปฏิบัติตามข้อกำหนด) เช่น ข้อมูลส่วนบุคคลรั่วไหล และ Reputational Impact (ผลกระทบต่อชื่อเสียง) เช่น แขกไม่เชื่อมั่น โรงแรมควรแยกการวิเคราะห์ทั้ง 4 ด้าน เพราะระบบที่หยุดไม่นานอาจยังสร้างความเสี่ยงด้านข้อมูลสูงมาก

ตัวอย่างเช่น โรงแรมสมมติขนาด 180 ห้องมี Occupancy (อัตราการเข้าพัก) 75% เท่ากับมีห้องใช้งานประมาณ 135 ห้อง หากมีแขกเฉลี่ย 1.6 คนต่อห้อง จะมีแขกราว 216 คนที่อยู่ในอาคาร โดยยังไม่รวมแขกที่จะมาถึงและผู้ใช้ห้องอาหาร หาก PMS และระบบออกกุญแจหยุดพร้อมกันในช่วง 14.00 น. ซึ่งเป็นเวลาที่มี Arrival (แขกขาเข้า) หนาแน่น ปัญหาจะกลายเป็นคิวหน้าเคาน์เตอร์และความเสี่ยงออกกุญแจผิดห้องภายในเวลาไม่นาน

Hotel IT ควรทำ Business Impact Analysis หรือ BIA (การวิเคราะห์ผลกระทบทางธุรกิจ) โดยถามแต่ละแผนกว่า เมื่อระบบหยุด 15 นาที 1 ชั่วโมง 4 ชั่วโมง และ 24 ชั่วโมง งานใดทำต่อไม่ได้ ข้อมูลใดต้องมี และมีวิธี Manual ใดรองรับ คำตอบต้องเป็นตัวเลข เช่น รองรับการเช็กอินด้วยเอกสารได้ 20 รายการต่อชั่วโมง ไม่ใช่คำกว้างๆ ว่าแผนกยังพอทำงานได้

โรงแรมต้องสำรองระบบและข้อมูลอะไรบ้าง?

ขั้นแรกคือสร้าง Asset Inventory (บัญชีทรัพย์สินระบบ) ให้ครบทั้ง Hardware, Software, Cloud Service, Database, Interface, License, Certificate และผู้รับผิดชอบ ระบบสำคัญมักประกอบด้วย PMS, POS, CRS หรือระบบจองส่วนกลาง, Channel Manager, Booking Engine, ระบบกุญแจ, ระบบบัญชี, ระบบจัดซื้อ, ระบบโทรศัพท์, ระบบอีเมล และระบบจัดเก็บเอกสาร แต่รายการจริงแตกต่างกันตามรูปแบบการบริหารของแต่ละโรงแรม

อย่าบันทึกเพียงชื่อระบบ ต้องระบุด้วยว่าข้อมูลอยู่ที่ใด ใครเป็นเจ้าของข้อมูล สำรองโดยใคร และพึ่งพาระบบใด ตัวอย่างเช่น POS อาจทำงานได้ แต่ไม่สามารถ Post Charge (บันทึกค่าใช้จ่ายเข้าห้องพัก) หาก Interface Server หยุด ส่วน PMS อาจเปิดได้แต่ส่งข้อมูลให้ระบบกุญแจไม่ได้หาก Integration Service ไม่ทำงาน Dependency Map (แผนผังการพึ่งพา) จึงสำคัญพอๆ กับรายชื่อระบบ

ระบบ	ข้อมูลสำคัญ	RPO ตัวอย่าง	RTO ตัวอย่าง	ลำดับกู้คืน
PMS	การจอง สถานะห้อง โปรไฟล์แขก รายการค่าใช้จ่าย	15 นาที	2 ชั่วโมง	1
ระบบกุญแจ	สิทธิ์เปิดห้อง บันทึกการออกกุญแจ	30 นาที	1 ชั่วโมง	1
POS	รายการขาย เมนู โต๊ะ การโพสต์เข้าห้อง	30 นาที	4 ชั่วโมง	2
ระบบบัญชี	บัญชีแยกประเภท เจ้าหนี้ ลูกหนี้	24 ชั่วโมง	24 ชั่วโมง	3
File Server	แบบฟอร์ม รายงาน เอกสารปฏิบัติงาน	8 ชั่วโมง	12 ชั่วโมง	3
ระบบกล้อง	วิดีโอและบันทึกเหตุการณ์	ตามนโยบาย	8 ชั่วโมง	2

ตัวเลขในตารางเป็นตัวอย่างสำหรับเริ่มต้น ไม่ใช่มาตรฐานตายตัว โรงแรมต้องปรับจากปริมาณธุรกรรม ช่วงเวลาที่มีแขกหนาแน่น ข้อกำหนดของผู้ให้บริการ และความสามารถในการทำงานแบบ Manual ขั้นตอนปฏิบัติคือ 1) รวบรวมรายการระบบ 2) สัมภาษณ์หัวหน้าแผนก 3) วาด Dependency 4) จัดระดับ Criticality (ความสำคัญ) 5) ให้ผู้บริหารธุรกิจอนุมัติ ไม่ควรให้ IT ตัดสินใจระดับความเสียหายเพียงฝ่ายเดียว

RPO และ RTO คำนวณอย่างไรให้เหมาะกับระบบโรงแรม?

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

วิธีประเมิน RPO ให้เริ่มจากสูตร จำนวนธุรกรรมที่อาจสูญหาย = ธุรกรรมเฉลี่ยต่อนาที x RPO เป็นนาที หากช่วงเร่งด่วนมีการบันทึก 6 ธุรกรรมต่อนาที และตั้ง RPO ไว้ 30 นาที โรงแรมอาจต้องตรวจสอบหรือบันทึกใหม่ถึง 180 ธุรกรรม ผู้บริหารอาจพบว่ารับไม่ได้และลด RPO เหลือ 10 นาที ซึ่งลดจำนวนธุรกรรมเสี่ยงเหลือประมาณ 60 รายการ

การกำหนด RTO ต้องรวมเวลาทั้งกระบวนการ ไม่ใช่นับเฉพาะเวลาคัดลอกไฟล์ ตัวอย่างการกู้ PMS อาจใช้เวลาตรวจสอบเหตุ 20 นาที อนุมัติประกาศ Disaster 15 นาที เตรียม Server 25 นาที Restore Database 30 นาที ตรวจสอบ Interface 20 นาที และ User Acceptance Test หรือ UAT (การทดสอบยอมรับโดยผู้ใช้) 10 นาที รวม 120 นาที หากตั้ง RTO ไว้ 60 นาที แผนนี้ถือว่าทำไม่ได้แม้ตัว Backup จะกู้เสร็จใน 30 นาที

ข้อควรระวังคือ RPO ต่ำและ RTO สั้นทำให้ต้นทุนและความซับซ้อนสูงขึ้น การทำ Replication (การจำลองข้อมูล) ทุกไม่กี่นาทีอาจช่วยลด RPO แต่ถ้าข้อมูลต้นทางถูกเข้ารหัสหรือแก้ไขผิด การเปลี่ยนแปลงอาจถูกส่งไปปลายทางด้วย Replication จึงไม่ทดแทน Versioned Backup (สำเนาที่เก็บหลายรุ่น) หรือ Immutable Backup (สำเนาที่แก้ไขย้อนหลังไม่ได้)

หลักสำรองข้อมูล 3-2-1-1-0 ใช้กับโรงแรมอย่างไร?

หลัก 3-2-1 หมายถึงมีข้อมูลอย่างน้อย 3 ชุด ได้แก่ข้อมูลใช้งาน 1 ชุดและสำเนา 2 ชุด ใช้สื่อหรือแพลตฟอร์มอย่างน้อย 2 ประเภท และเก็บอย่างน้อย 1 ชุดนอกสถานที่ สำหรับภัยคุกคามสมัยใหม่ควรขยายเป็น 3-2-1-1-0 โดยเลข 1 เพิ่มเติมหมายถึงสำเนา Offline, Air Gapped (แยกจากเครือข่าย) หรือ Immutable และเลข 0 หมายถึงผลการตรวจสอบ Backup ต้องไม่มี Error ที่ยังไม่ได้แก้ไข

ตัวอย่างการออกแบบสำหรับโรงแรมที่มีระบบภายในอาคาร คือชุดที่หนึ่งเป็นฐานข้อมูล Production ชุดที่สองเป็น Backup Appliance ภายในสำหรับกู้คืนรวดเร็ว และชุดที่สามเป็น Object Storage นอกสถานที่ซึ่งเปิด Object Lock หรือความสามารถป้องกันการลบตามระยะเวลา สำเนาภายในช่วยเรื่องความเร็ว ส่วนสำเนานอกสถานที่ช่วยเมื่ออาคาร เครื่องแม่ข่าย หรือพื้นที่จัดเก็บหลักเสียหายพร้อมกัน

ขั้นตอนกำหนด Backup Policy ควรประกอบด้วย 1) ระบุข้อมูลและเจ้าของ 2) กำหนดความถี่ตาม RPO 3) กำหนด Retention (ระยะเวลาเก็บรักษา) 4) เลือกตำแหน่งและรูปแบบการเข้ารหัส 5) ตั้งการแจ้งเตือนเมื่องานล้มเหลว 6) ตรวจสอบ Restore 7) ทบทวนเมื่อระบบเปลี่ยน โรงแรมอาจกำหนดสำเนาราย 15 นาทีเก็บ 24 ชั่วโมง สำเนารายวันเก็บ 30 วัน สำเนารายเดือนเก็บ 12 เดือน โดยต้องปรับตามข้อกำหนดและความจำเป็นจริง

เช็คลิสต์ขั้นต่ำของ Backup ได้แก่ มีผู้รับผิดชอบชัดเจน มีบัญชีบริการเฉพาะ ระบบต้นทางไม่มีสิทธิ์ลบสำเนาทั้งหมด เปิด Encryption at Rest (การเข้ารหัสข้อมูลขณะจัดเก็บ) และ Encryption in Transit (การเข้ารหัสระหว่างส่ง) เก็บ Recovery Key แยกอย่างปลอดภัย และมีรายงาน Success Rate (อัตราสำเร็จ) ทุกวัน หากงานสำรอง 100 งานล้มเหลว 3 งาน Success Rate เท่ากับ 97% ซึ่งยังต้องตรวจสอบว่างานที่ล้มเหลวเป็นระบบวิกฤตหรือไม่

จะป้องกันไม่ให้ Ransomware เข้ารหัสไฟล์ Backup ได้อย่างไร?

หลักสำคัญคือแยก Backup Security Domain (ขอบเขตความปลอดภัยของระบบสำรอง) ออกจากระบบทั่วไป บัญชี Administrator ของระบบงานไม่ควรมีสิทธิ์บริหาร Backup และบัญชี Backup ไม่ควรใช้ล็อกอินคอมพิวเตอร์ประจำวัน เปิด Multi Factor Authentication หรือ MFA (การยืนยันตัวตนหลายปัจจัย) สำหรับ Console และจำกัดการเข้าถึงจาก Management Network หรือเครื่องบริหารที่กำหนดเท่านั้น

Immutable Backup ช่วยป้องกันการแก้ไขหรือลบสำเนาภายในช่วง Retention Lock ที่กำหนด เช่น 14 หรือ 30 วัน อย่างไรก็ตามต้องตั้งค่าให้ถูกต้อง หากผู้โจมตีแก้ Policy ลดระยะเวลาได้ หรือใช้บัญชีเดียวกับระบบ Production ความสามารถนี้อาจไม่ช่วยมากพอ โรงแรมควรใช้ Separation of Duties (การแบ่งแยกหน้าที่) เช่น ผู้ดูแลระบบสร้างงานสำรองได้ แต่การลด Retention หรือลบ Repository ต้องมีการอนุมัติอีกบุคคลหนึ่ง

อีกชั้นหนึ่งคือ Network Segmentation (การแบ่งส่วนเครือข่าย) แต่ไม่ควรมองว่า Firewall เพียงอย่างเดียวแก้ปัญหาทั้งหมด ต้องปิด Protocol ที่ไม่จำเป็น จำกัดพอร์ตจาก Backup Server ไปยังเครื่องต้นทาง ใช้ Allowlist (รายการที่อนุญาต) และบันทึก Audit Log (บันทึกการตรวจสอบ) ส่งไปยังพื้นที่ซึ่งผู้ดูแล Backup ลบไม่ได้ หากมีการลบงานจำนวนมาก เปลี่ยน Retention หรือ Login จากตำแหน่งผิดปกติ ระบบควรแจ้งเตือนทันที

ข้อควรระวังคือการใช้ External Drive ที่เสียบค้างไว้ตลอดเวลาไม่ถือเป็น Offline Backup เพราะมัลแวร์หรือบัญชีที่ถูกยึดอาจเข้าถึง Drive นั้นได้ หากใช้สื่อถอดได้ต้องมีรอบนำออก จัดเก็บในสถานที่ควบคุม ลงทะเบียนผู้รับมอบ และทดลองอ่านข้อมูลตามรอบ สื่อที่เก็บไว้นานยังมีความเสี่ยงเสื่อมสภาพ จึงต้องมี Media Rotation (การหมุนเวียนสื่อ) และวันหมดอายุใช้งาน

เมื่อพบ Ransomware ทีม Hotel IT ต้องทำอะไรใน 60 นาทีแรก?

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

นาทีที่ 0 ถึง 10: บันทึกเวลา อาการ เครื่อง และผู้แจ้ง แยกอุปกรณ์ต้องสงสัยออกจาก Network โดยถอดสายหรือปิดการเชื่อมต่อ แต่หลีกเลี่ยงการปิดเครื่องทันทีหากทีม Incident Response (ทีมตอบสนองเหตุการณ์) ต้องเก็บข้อมูลในหน่วยความจำ
นาทีที่ 10 ถึง 20: แจ้ง Incident Commander (ผู้บัญชาการเหตุการณ์) เปิด War Room (ศูนย์ประสานเหตุ) และยืนยันว่าระบบใดได้รับผลกระทบ
นาทีที่ 20 ถึง 30: ป้องกัน Backup โดยจำกัดการเชื่อมต่อ ระงับบัญชีที่สงสัย และตรวจสอบว่ามีงานลบหรือเข้ารหัสผิดปกติหรือไม่
นาทีที่ 30 ถึง 45: ให้ Front Office, F&B, Housekeeping และ Security เปิดใช้แบบฟอร์ม Manual ตาม Business Continuity Plan
นาทีที่ 45 ถึง 60: ประเมินขอบเขต กำหนดช่องทางสื่อสารที่ปลอดภัย ตัดสินใจว่าต้องใช้ DR Site หรือไม่ และเริ่มตรวจสอบ Restore Point ที่น่าเชื่อถือ

ทีมไม่ควรประกาศว่าข้อมูลส่วนบุคคลรั่วไหลหรือไม่รั่วไหลโดยไม่มีหลักฐาน เพราะ Ransomware บางเหตุการณ์มี Data Exfiltration (การนำข้อมูลออกจากระบบ) ก่อนเข้ารหัส ต้องตรวจ Log, Network Traffic, Account Activity และเครื่องที่เกี่ยวข้อง พร้อมประสานผู้รับผิดชอบด้านกฎหมายและคุ้มครองข้อมูลตามขั้นตอนขององค์กร

หลักตัดสินใจ: Containment (การควบคุมเหตุ) มาก่อนความเร็วในการเปิดระบบ แต่ความปลอดภัยของแขกมาก่อนการเก็บหลักฐานเสมอ หากระบบประตู ลิฟต์ สัญญาณเตือน หรือระบบที่เกี่ยวข้องกับชีวิตได้รับผลกระทบ ต้องใช้ขั้นตอนฉุกเฉินของฝ่ายวิศวกรรมและรักษาความปลอดภัยทันที

โรงแรมจะเช็กอิน ออกกุญแจ และรับชำระเงินอย่างไรเมื่อระบบล่ม?

Business Continuity Plan หรือ BCP (แผนดำเนินธุรกิจต่อเนื่อง) ต้องตอบให้ได้ว่าแผนกจะให้บริการอย่างไรระหว่างรอกู้ระบบ Front Office ควรมี Arrival List ที่จัดเก็บอย่างปลอดภัย แบบฟอร์มลงทะเบียน สมุดควบคุมหมายเลขห้อง แบบฟอร์มออกกุญแจ คู่มือยืนยันตัวตน และรายชื่อผู้มีอำนาจอนุมัติกรณีพิเศษ เอกสารสำรองต้องจำกัดข้อมูลเท่าที่จำเป็นและทำลายอย่างปลอดภัยเมื่อบันทึกกลับระบบแล้ว

การจัดห้องแบบ Manual ต้องมี Single Source of Truth (แหล่งข้อมูลกลางเพียงชุดเดียว) เช่น Room Control Sheet ซึ่งผู้ควบคุมเวรเป็นคนแก้ไข ห้ามแต่ละจุดจดหมายเลขห้องแยกกันโดยไม่ซิงก์ เพราะเสี่ยงขายห้องซ้ำหรือออกกุญแจให้ผิดคน ทุกการเปลี่ยนห้อง ต่อเวลาพัก และออกกุญแจทดแทนควรมีเวลา ชื่อผู้ปฏิบัติ ผู้อนุมัติ และเหตุผล

สำหรับ POS ให้ใช้ Running Number (เลขที่เอกสารเรียงต่อเนื่อง) กับใบรายการ Manual บันทึกห้อง ชื่อผู้ลงนาม เวลา จุดขาย และยอดให้ครบ เมื่อระบบกลับมา ให้ทีมที่ได้รับมอบหมาย Post Transaction ตามลำดับเลขและทำ Reconciliation (การกระทบยอด) หากมีเอกสารเลข 001 ถึง 120 แต่พบเพียง 119 ใบ ต้องสอบสวนเลขที่หายก่อนปิดเหตุ ไม่ควรบันทึกรวมเป็นยอดเดียวเพราะจะสูญเสีย Audit Trail

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

ขั้นตอนกู้คืน PMS, POS และระบบเชื่อมต่อควรเรียงอย่างไร?

ก่อน Restore ต้องยืนยัน Clean Point (จุดสำรองที่สะอาด) โดยพิจารณาเวลาที่ผู้โจมตีอาจเริ่มเข้าถึง ไม่ใช่เลือกสำเนาล่าสุดโดยอัตโนมัติ หากตรวจพบการเข้ารหัสวันศุกร์ แต่พบ Account Login ผิดปกติตั้งแต่วันพุธ Backup คืนวันพฤหัสบดีอาจมี Persistence (กลไกฝังตัวเพื่อกลับเข้าระบบ) อยู่แล้ว ทีมจึงต้องตรวจสอบ IOC หรือ Indicator of Compromise (ตัวบ่งชี้การถูกโจมตี) ก่อนเชื่อมระบบกลับ

ลำดับทั่วไปคือ 1) สร้าง Trusted Environment (สภาพแวดล้อมที่เชื่อถือได้) 2) กู้ Identity, DNS, เวลา และบริการพื้นฐานที่จำเป็น 3) กู้ PMS และระบบกุญแจ 4) ตรวจฐานข้อมูลและสถานะห้อง 5) กู้ POS 6) กู้ Interface 7) กู้ระบบบัญชีและรายงาน 8) เปิดการเชื่อมต่อภายนอกทีละส่วน ลำดับจริงต้องอ้างอิง Dependency Map เพราะการเปิด Interface ก่อนระบบปลายทางพร้อมอาจทำให้ Message Queue ค้างหรือข้อมูลซ้ำ

หลัง Restore ให้ทำ Technical Validation และ Business Validation แยกกัน Technical Validation ตรวจว่า Service ทำงาน Database Consistency ผ่าน Log ไม่มี Error และ Patch อยู่ในระดับที่กำหนด ส่วน Business Validation ให้ผู้ใช้ทดสอบ Reservation Search, Check In, Room Move, Key Encoding, Posting, Payment, Check Out และ Night Audit อย่างน้อยหนึ่งรอบ การที่หน้า Login เปิดได้ยังไม่เท่ากับระบบพร้อมให้บริการ

กรณีศึกษาโรงแรมสมมติพบว่า PMS กู้เสร็จภายใน 70 นาที แต่ Interface กับ POS ส่งรายการซ้ำหลังเปิดบริการ ทีมจึงต้องย้อนธุรกรรมและกระทบยอดเพิ่มอีก 3 ชั่วโมง บทเรียนคือ Definition of Recovered (นิยามว่ากู้คืนสำเร็จ) ต้องรวม End to End Test (การทดสอบตั้งแต่ต้นทางถึงปลายทาง) ไม่ใช่ใช้สถานะ Server Running เป็นตัววัดเพียงอย่างเดียว

ควรทดสอบ Backup และซ้อม Disaster Recovery บ่อยแค่ไหน?

โรงแรมควรตรวจสถานะงานสำรองทุกวัน ทดลองกู้ไฟล์หรือฐานข้อมูลตัวอย่างอย่างน้อยรายเดือน ทดสอบระบบสำคัญแบบ End to End รายไตรมาส และซ้อม DR ที่มีผู้ใช้จากหลายแผนกอย่างน้อยปีละ 1 ถึง 2 ครั้ง ความถี่ต้องเพิ่มขึ้นเมื่อมีการอัปเกรด เปลี่ยน Vendor ย้าย Cloud ปรับ Interface หรือพบว่างานสำรองล้มเหลวบ่อย

การทดสอบมีหลายระดับ ได้แก่ Backup Verification ตรวจว่างานเสร็จและไฟล์อ่านได้ Restore Test กู้ข้อมูลสู่พื้นที่แยก Tabletop Exercise ซ้อมตัดสินใจบนสถานการณ์จำลอง Technical Failover Test สลับระบบไปยังสภาพแวดล้อมสำรอง และ Full Simulation ให้ฝ่ายปฏิบัติการใช้กระบวนการ Manual แล้วกลับเข้าสู่ระบบจริง การเลือกแบบทดสอบควรพิจารณาความเสี่ยงต่อแขกและหลีกเลี่ยงช่วง Occupancy สูง

ตัวชี้วัดที่ควรบันทึก ได้แก่ Backup Success Rate เป้าหมายใกล้ 100% จำนวนงานล้มเหลวที่เกิน SLA ค่า Actual RPO ค่า Actual RTO จำนวน Error ระหว่าง Restore เวลาที่ใช้แจ้งเตือน และจำนวนธุรกรรมที่ต้อง Reconcile ตัวอย่าง หาก RTO เป้าหมาย 120 นาที แต่การซ้อมใช้ 165 นาที มี RTO Gap เท่ากับ 45 นาที ทีมต้องระบุว่าส่วนใดใช้เวลาเกินและกำหนดเจ้าของ Action Item

มีรายชื่อผู้เข้าร่วมและบทบาทชัดเจน
มี Scenario ที่ไม่เปิดเผยรายละเอียดทั้งหมดล่วงหน้า
มีเกณฑ์ Pass หรือ Fail ที่วัดได้
มี Observer (ผู้สังเกตการณ์) บันทึกเวลาและปัญหา
มี After Action Review (การทบทวนหลังการซ้อม)
มีวันครบกำหนดแก้ไขและการทดสอบซ้ำ

ข้อควรระวังคืออย่าทดสอบ Restore ทับ Production และอย่าใช้ข้อมูลแขกจริงใน Test Environment โดยไม่มีมาตรการคุ้มครอง ควร Mask Data (ปกปิดข้อมูล) หรือใช้ข้อมูลจำลอง รวมถึงตรวจสอบว่าระบบทดสอบไม่ส่งอีเมล ข้อความ หรือรายการชำระเงินจริงออกไปภายนอก

จะบริหาร Vendor, Cloud Backup และ SLA อย่างไรไม่ให้เกิดช่องว่าง?

แม้ระบบจะเป็น SaaS หรือ Cloud โรงแรมยังต้องตรวจสอบ Shared Responsibility Model (รูปแบบความรับผิดชอบร่วม) ผู้ให้บริการอาจดูแลโครงสร้างพื้นฐาน แต่ลูกค้าอาจต้องรับผิดชอบการตั้งค่า Retention การ Export ข้อมูล การควบคุมบัญชี และการร้องขอกู้คืน คำว่า High Availability (ความพร้อมใช้งานสูง) ไม่ได้หมายความว่ามี Backup ที่ย้อนกลับไปก่อนข้อมูลถูกลบหรือเข้ารหัสได้เสมอ

ในสัญญาหรือ SLA ควรถามให้ชัดว่า Backup ทำบ่อยเท่าใด เก็บกี่วัน อยู่ภูมิภาคใด เข้ารหัสอย่างไร ใครถือ Key ใช้เวลากู้เท่าใด มีค่าใช้จ่ายฉุกเฉินหรือไม่ และลูกค้าดาวน์โหลดข้อมูลในรูปแบบใด หาก Vendor ระบุ Availability 99.9% ในเดือน 30 วัน เวลาหยุดตามการคำนวณเชิงทฤษฎีอาจประมาณ 43 นาทีต่อเดือน แต่ต้องอ่านข้อยกเว้นและวิธีคิด Service Credit เพราะไม่ใช่ทุกเหตุการณ์ถูกนับเหมือนกัน

โรงแรมควรเก็บ Technical Contact, Emergency Contact, Contract Number, Support Portal และ Escalation Path แบบ Offline ด้วย เมื่ออีเมลหรือระบบเอกสารล่ม ทีมยังต้องติดต่อ Vendor ได้ ระหว่างซ้อม DR ควรทดลองเปิด Ticket ระดับวิกฤตและวัดเวลาตอบรับจริง ไม่ใช่อ้างอิง SLA บนเอกสารเท่านั้น

กรณีมีหลาย Vendor ต้องกำหนด RACI (ตารางผู้รับผิดชอบ ผู้อนุมัติ ผู้ให้คำปรึกษา และผู้รับทราบ) เช่น ใคร Restore PMS ใครเปิด Firewall ใครตรวจ Interface ใครอนุมัติกลับ Production และใคร Reconcile รายการ หากไม่กำหนดไว้ ผู้ให้บริการแต่ละรายอาจรออีกฝ่ายดำเนินการ ทำให้ RTO หลุดเป้าหมายทั้งที่ระบบสำรองสมบูรณ์

เช็กลิสต์สร้างแผน Backup และ Disaster Recovery สำหรับโรงแรมมีอะไรบ้าง?

การเริ่มต้นที่ได้ผลควรแบ่งเป็นช่วง 30, 60 และ 90 วัน ใน 30 วันแรกให้สำรวจระบบ ทำ BIA ระบุ Data Owner และตรวจว่างาน Backup ปัจจุบันครอบคลุมอะไร ในวันที่ 31 ถึง 60 ให้ออกแบบ 3-2-1-1-0 แยกบัญชีบริหาร กำหนด RPO, RTO และสร้าง Runbook (คู่มือปฏิบัติทีละขั้น) ส่วนวันที่ 61 ถึง 90 ให้ทดลอง Restore ซ้อม Tabletop แก้ช่องว่าง และขอผู้บริหารอนุมัติแผนฉบับใช้งาน

เช็กลิสต์ด้านข้อมูลและเทคโนโลยี

มี Asset Inventory และ Dependency Map ที่อัปเดตล่าสุด
ทุกระบบมี Data Owner, System Owner และผู้ติดต่อ Vendor
กำหนด RPO, RTO และ Retention เป็นตัวเลข
มีสำเนานอกสถานที่และสำเนา Immutable หรือ Offline
บัญชี Backup แยกจากบัญชี Production และเปิด MFA
Backup Database, Configuration, Certificate, License และ Script ที่จำเป็นครบ
มี Monitoring และ Alert เมื่อ Backup ล้มเหลวหรือถูกลบผิดปกติ
เก็บ Recovery Key และรหัสฉุกเฉินในที่ปลอดภัยซึ่งเข้าถึงได้เมื่อระบบหลักล่ม

เช็กลิสต์ด้านคนและกระบวนการ

แต่งตั้ง Incident Commander และผู้แทนสำรองทุกกะ
มี Call Tree (สายการแจ้งเหตุ) ที่ใช้ได้โดยไม่พึ่งอีเมลองค์กร
Front Office, F&B, Housekeeping, Finance และ Security มีแบบฟอร์ม Manual
กำหนดวิธีกระทบยอดข้อมูลหลังระบบกลับมา
มีข้อความสื่อสารภายในและแนวทางตอบแขกที่ผ่านการอนุมัติ
มีเกณฑ์ประกาศ Disaster และเกณฑ์กลับสู่ Normal Operation
ทดสอบ Restore และซ้อมร่วมกับ Vendor ตามรอบ

เอกสารทุกฉบับควรมี Version, Owner, วันที่อนุมัติ และ Next Review Date (วันทบทวนครั้งถัดไป) สำเนาหนึ่งควรเข้าถึงได้แบบ Offline แต่ต้องควบคุมไม่ให้ข้อมูลบัญชีหรือความลับกระจายโดยไม่จำเป็น เมื่อระบบมีการเปลี่ยนแปลง เช่น เพิ่มร้านอาหาร เปลี่ยนเครื่องรูดบัตร หรือเชื่อม OTA ใหม่ ต้องประเมินผลต่อ Backup และ DR ก่อนเปิดใช้งานจริง

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

Key Takeaways:

กำหนด RPO และ RTO แยกตามระบบด้วยข้อมูลธุรกรรมและผลกระทบจริง
ใช้หลัก 3-2-1-1-0 และมีสำเนา Immutable หรือ Offline อย่างน้อย 1 ชุด
แยกบัญชีและขอบเขตบริหาร Backup ออกจาก Production พร้อมเปิด MFA
เตรียมขั้นตอน Manual สำหรับเช็กอิน กุญแจ POS และการกระทบยอด
กู้คืนตาม Dependency และทดสอบกระบวนการ End to End ก่อนเปิดให้บริการ
ตรวจ Backup ทุกวัน ทดลอง Restore รายเดือน และซ้อม DR อย่างน้อยปีละ 1 ถึง 2 ครั้ง
ตรวจความรับผิดชอบและ SLA ของ Vendor เพราะ Cloud ไม่ได้แปลว่ากู้ข้อมูลได้ทุกกรณี

📚 หนังสือที่เกี่ยวข้องกับ Hotel IT