Availability อาจารย์ ธนัญชัย ตรีภาค ภาควิชาวิศวกรรมคอมพิวเตอร์ คณะวิศวกรรมศาสตร์ สถาบันเทคโนโลยีพระจอมเกล้าเจ้าคุณทหารลาดกระบัง

Availability ทำให้ระบบงานสามารถตอบสนองต่อการร้องขอบริการจากผู้ใช้งานได้ตลอดเวลาที่ต้องการ

ความสำคัญของ Availability ความคุ้มค่าในการลงทุนในระบบ ประสิทธิภาพของระบบ ความเชื่อมั่นในระบบ คุณภาพในการให้บริการ

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

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

การสร้าง Availability การดำเนินการเพื่อป้องกันปัญหาล่วงหน้า การวางแผนทรัพยากรให้พอเพียงกับการใช้งาน การขยายตัว และทนทานสูง การกำหนดนโยบายการใช้งาน การใช้โครงสร้างพื้นฐานด้านความปลอดภัยในการควบคุมปัญหา การใช้แผนรับมือภัยพิบัติ (Contingency Plan) การทำ Security Assessment / Hardening เพื่อปิดช่องโหว่ การวางแผนการบริหารความเสี่ยงและการประเมินความเสี่ยง การกำหนดนโยบายการรักษาความปลอดภัยตามมาตรฐานสากล การพัฒนาบุคลากรให้มีความสามารถ การทำ Preventive Control ต่างๆ

การสร้าง Availability การวางแผนเพื่อแก้ปัญหาระบบที่เกิดขึ้น การตอบสนองต่อภัยคุกคามต่างๆ การ Monitor และการตรวจตราระบบทำให้สามารถแก้ไขปัญหาต่างๆ ได้อย่างรวดเร็ว การประกาศและดำเนินการตามแผน Incident Response Plan การใช้เครื่องมือด้าน Access Control เพื่อควบคุมการโจมตีต่างๆ

การวางแผนและดำเนินการด้านทรัพยากร

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

เหตุการณ์ปกติ การให้บริการปกติ ทรัพยากรในระบบจะสามารถรองรับการร้องขอของผู้ใช้งานได้ ทั้งในระยะสั้นและระยะยาว การคำนวณและคาดการณ์ ภาระงาน (system Load), การคิดความคุ้มค่าในการลงทุน (Return on Investment) และ Cost/Benefit Analysis จะมีส่วนอย่างมากในการกำหนดค่าทรัพยากรอย่างเหมาะสม System Resource User Request

Non-User Request / Attacker Overload by non-user การให้บริการสาธารณะที่มีผู้ต้องการทรัพยากรมากกว่าที่ระบบสามารถให้ได้หรือถูกโจมตีโดยผู้ไม่ประสงค์ดี ต้องดำเนินการควบคุมไม่ให้เกิดการร้องขอหรือใช้งานทรัพยากรอย่างไม่ถูกต้อง System Resource User Request Non-User Request / Attacker

Overload by user ในระยะยาว การให้บริการระบบมักมีผู้ใช้งานต้องการทรัพยากรมากกว่าที่ระบบสามารถให้ได้ ต้องอาศัยกระบวนการขยายทรัพยากรในรูปแบบต่างๆที่เหมาะสม System Resource User Request

Upgrade การเพิ่มทรัพยากรในระบบเดิมให้เหมาะสมกับการให้บริการ เช่นการเพิ่มจำนวนโพรเซสเซอร์ จำนวนหน่วยความจำ หน่วยเก็บข้อมูล หรือระบบเครือข่าย System Resource User Request

Load Balance หากไม่สามารถเพิ่มทรัพยากรในระบบได้ สามารถเพิ่มระบบงานอีกระบบเพื่อช่วยตอบสนองต่อ Request เช่นการเพิ่มจำนวน Server หากมีการใช้งานระบบมากเกินไป ซึ่งต้องใช้อุปกรณ์ Load Balancer เพิ่มเติมในการจัดแบ่งการร้องขอไปยัง Server ทั้งสอง โดยทั่วไปจะตั้งค่าการทำ Load Sharing แบบ Active-Active หรือ Dynamic Load Balance System1 Resource User Request System2 Resource

High Availability กรณีที่ระบบไม่สามารถให้บริการได้ ต้องใช้การออกแบบล่วงหน้า ให้อยู่ในลักษณะ High Availability ซึ่งโดยทั่วไปจะตั้งค่าแบบ Active-Standby System Resource: System Fail User Request Backup System Resource: Active

การวางแผนสำรองฉุกเฉิน Contingency Planning

Things which you do not hope happen more frequently than things which you do hope. -- PLAUTUS. (C. 254–184 B.C.), MOSTELLARIA, ACT I, SCENE 3, 40 (197) Contingency Planning

แผนสำรองฉุกเฉิน(Contingency Plan) แผนในภาพรวมในการรับมือกับเหตุการณ์ฉุกเฉินที่เกิดขึ้นนอกเหนือจากคาดหมาย มีรายละเอียดเกี่ยวกับ การตรวจสอบ การตอบสนอง การกอบกู้ระบบงาน แนวทางในการรับมือเหตุการณ์ที่สร้างความเสี่ยงให้กับระบบและสินทรัพย์ต่างๆ ทำให้กลับสู่ภาวะปกติโดยมีการสูญเสียน้อยที่สุด

การดำเนินการเมื่อเกิดเหตุฉุกเฉิน Disaster Recovery Plan Business Continuity Plan Incident Primary System Secondary System Incident Response Plan

องค์ประกอบของแผนสำรองฉุกเฉิน มุ่งเน้นการดำเนินการเมื่อเกิดเหตุฉุกเฉินโดยทันที แผนรับมือเหตุฉุกเฉิน(Incident Response Plan) มุ่งเน้นการกอบกู้ระบบหลักให้เป็นปกติหลังเกิดภัยพิบัติต่างๆ แผนรับมือภัยพิบัติ (Disaster Recovery Plan) มุ่งเน้นการทำงานที่ระบบสำรองให้ทดแทนระบบหลักได้ แผนการดำเนินธุรกิจอย่างต่อเนื่อง (Business Continuity Plan)

Contingency Planning

แผนรับมือเหตุฉุกเฉิน (Incident Response Plan)

Incident Response Plan เมื่อเกิดเหตุการณ์ (event) ในระบบ จะมีการกำหนดว่าเป็นเหตุฉุกเฉิน (incident) เมื่อ เหตุการณ์ดังกล่าวก่อให้เกิดความเสียหายต่อทรัพย์สินสารสนเทศ เหตุการณ์ดังกล่าวมีโอกาสสำเร็จสูง รายการกระบวนการและขั้นตอนเพื่อรับมือและลดผลกระทบจากเหตุฉุกเฉิน เป็นการดำเนินการแบบตอบสนอง (reactive) ไม่ใช่การป้องกัน (preventive)

ระดับของเหตุการณ์ เหตุการณ์ (Event) เหตุฉุกเฉิน (Incident) ภัยพิบัติ (Disaster)

การดำเนินการตามแผนรับมือเหตุฉุกเฉิน ก่อนเกิดเหตุฉุกเฉิน เมื่อเกิดเหตุฉุกเฉิน หลังจากเกิดเหตุฉุกเฉิน

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

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

หลังจากเกิดเหตุฉุกเฉิน จัดทำเอกสารขั้นตอนการตอบสนองต่อเหตุฉุกเฉินที่เกิดขึ้น จัดแบ่งหน้าที่ต่างๆ ในการแก้ไขเหตุฉุกเฉินที่เกิดขึ้นอย่างชัดเจน เป็นลำดับ บันทึกการดำเนินการที่เกี่ยวกับการติดต่อกับหน่วยงานภายนอกอย่างละเอียด

การตรวจหาเหตุฉุกเฉิน เหตุการณ์ต่างๆ ที่เกิดขึ้นในระบบเป็นได้ 2 กรณี เหตุการณ์ปกติที่เกิดขึ้นเป็นประจำ เหตุฉุกเฉินที่เกิดขึ้นเป็นบางครั้ง เหตุฉุกเฉินจะพบได้จาก รายงานจากผู้ใช้งานระบบ ระบบ IDS ระบบสแกนไวรัส ผู้ดูแลระบบ

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

ผลกระทบจากเหตุฉุกเฉิน ขาด confidentiality ขาด integrity ขาด availability เกิดการทำงานที่ฝ่าฝินนโยบาย เกิดการทำงานที่ฝ่าฝืนกฎหมาย

ความรุนแรงของเหตุฉุกเฉิน เหตุฉุกเฉินจะมีผลกระทบต่อระบบมากขึ้น เมื่อไม่สามารถควบคุมเหตุได้ จากข้อมูลของการทำ business impact analysis จะบอกได้ว่าเหตุฉุกเฉินนั้นมีระดับความรุนแรงเป็นภัยพิบัติหรือไม่

การบันทึกเหตุฉุกเฉิน เมื่อเกิดเหตุฉุกเฉินในระบบให้บันทึกตามหลักการ who, what, when, where, why and how จดบันทึกเพื่อเป็นกรณีศึกษา บันทึกข้อมูลหลังจากที่พบสาเหตุของปัญหา มีการดำเนินงานที่ถูกต้อง และได้ผลลัพธ์ของการดำเนินงาน มีรายละเอียดเพียงพอให้นำไปใช้งานเมื่อเกิดเหตุการณ์ดังกล่าวอีกครั้งได้อย่างรวดเร็ว

กลยุทธในการควบคุมเหตุฉุกเฉิน ปิดการเชื่อมต่อเครือข่าย ระงับใช้บางบัญชีผู้ใช้ เพิ่มกฎในการเข้าถึงเครือข่ายบางเครือข่าย หรือบางโพรโตคอลใน Firewall ตั้งค่า Firewall เพื่อปิดกั้นการเชื่อมต่อที่มีปัญหา ปิดการใช้งานบริการหรือโพรเซสที่มีปัญหาชั่วคราว ปิดบริการเครื่องคอมพิวเตอร์หรือเครือข่ายทั้งหมด

แผนรับมือภัยพิบัติ Disaster Recovery Plan

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

การวางแผนสำหรับภัยพิบัติ ใช้เหตุการณ์สมมุติและการประเมินผลกระทบเพื่อแยกแยะระดับปัญหาต่างๆ รายละเอียดใน DRP: บทบาท หน้าที่และความรับผิดชอบต้องชัดเจน การดำเนินการกับการแจ้งเตือนต่างๆ และการแจ้งต่อผู้ที่เกี่ยวข้องทราบ ลำดับการสั่งการในเหตุการณ์ที่ชัดเจน การจดบันทึกเหตุภัยพิบัติ ขั้นตอนการดำเนินการในการลดผลกระทบ การดำเนินการอื่นสำหรับระบบงานเมื่อเกิดภัยพิบัติ

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

ตัวอย่าง Disaster Recovery Plan ชื่อของหน่วยงาน วันที่ดำเนินงาน หรือปรับปรุงการวางแผนและวันทดสอบ เจ้าหน้าที่หน่วยงานที่จะเรียกในกรณีที่เกิดภัยพิบัติ บริการฉุกเฉินที่จะเรียกในกรณีที่เกิดภัยพิบัติ สถานที่ตั้งของอุปกรณ์ฉุกเฉิน แหล่งที่มาของอุปกรณ์ที่ใช้งานนอกสถานที่ หน่วยงานการกู้คืนภัยพิบัติ การประเมินการติดตาม

แผนการดำเนินธุรกิจต่อเนื่อง Business Continuity Plan

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

กลยุทธในการสร้างความต่อเนื่องของธุรกิจ มีหลายกลยุทธ ขึ้นอยู่กับงบประมาณในการดำเนินการ Three exclusive-use options: Hot sites Warm sites Cold sites Four shared-use options: Timeshare Service bureaus Mutual agreements Specialized alternatives

Exclusive Use Options Hot Sites Warm Sites Cold Sites สร้างระบบสำรองที่เหมือนกับระบบหลัก พร้อมทำงานแทนได้ทันที Hot Sites เหมือนกับ hot site แต่มีการใช้งานเพียงบางแอปพลิเคชั่นเท่านั้น Warm Sites มีบริการพื้นฐานที่พร้อมใช้งานไม่มากและมีทรัพยากรจำกัด Cold Sites

Specialized alternatives: Shared Use Options คล้ายกับ Exclusive Use แต่มีการเช่าใช้งานเป็นบางช่วงเวลา Timeshares มีหน่วยงานที่จะให้บริการด้านกายภาพทั้งหมด Service Bureaus มีการตกลงเซ็นสัญญาระหว่าง 2 องค์กรเพื่อช่วยเหลือกันในภาวะภัยพิบัติ Mutual Agreements มีการเปลี่ยนสถานที่ดำเนินงานไปเรื่อยๆ จัดเก็บข้อมูลสำคัญไว้ภายนอกระบบงานหรือต่างพื้นที่ Specialized alternatives:

การเก็บข้อมูลไว้ภายนอกองค์กร เพื่อให้องค์กรสามารถกู้คืนข้อมูลได้อย่างรวดเร็ว การทำงานประกอบด้วย: Electronic vaulting: ส่งข้อมูลปริมาณมาก แบบ batch ไปยังไซต์ภายนอก Remote Journaling: แอปพลิเคชั่นส่งข้อมูลไปไซต์ภายนอกทันที Database shadowing: ที่ฐานข้อมูลทำการ duplicate ไปยังไซต์ภายนอกแบบออนไลน์

Disaster Recovery and Business Continuity Planning

Contingency Plan Implementation Timeline

Major Tasks in Contingency Planning

การวิเคราะห์ผลกระทบต่อธุรกิจ (Business Impact Analysis : BIA) เมื่อการโจมตีสำเร็จจะส่งผลอย่างไรต่อธุรกิจ ใช้ข้อมูลเกี่ยวกับระบบ ภัยคุกคาม และรายละเอียดการโจมตีที่ส่งผลกระทบต่อการทำงานของระบบ ทีมงานสำรองฉุกเฉินใช้ BIA เพื่อ : ระบุการโจมตีต่างๆ วิเคราะห์หน่วยธุรกิจต่างๆ กำหนดลักษณะของการโจมตีที่สำเร็จ ประเมินความเสียหายที่เกิดขึ้น แยกแยะแผนสำรองต่างๆ อย่างเหมาะสม

การบริหารความเสี่ยง (Risk Management)

การบริหารความเสี่ยง

ผลลัพธ์ที่ต้องการจากการบริหารความเสี่ยงแต่ละขั้นตอน สินทรัพย์สารสนเทศ (HW, SW, Network, Data, People, Process) ภัยคุกคามต่างๆที่เกิดขึ้น ความรุนแรง และความถี่ในการเกิด ช่องโหว่ การกำหนดวิธีการควบคุมและ%ที่ควบคุมได้ การคำนวณความเสี่ยง และเรียงลำดับความเสี่ยงเพื่อ ดำเนินการตัดสินใจควบคุมความเสี่ยง

ภัยคุกคาม ปัจจัยอื่นๆ ที่กระทบต่อระบบงาน ข้อผิดพลาดจากการกระทำของมนุษย์ การบุกรุก การกรรโชกข้อมูลสารสนเทศ การก่อวินาศกรรมหรือการทำลาย การโจรกรรม การโจมตีซอฟต์แวร์ ภัยธรรมชาติคุณภาพของบริการ ข้อผิดพลาดทางเทคนิคของฮาร์ดแวร์ ข้อผิดพลาดทางเทคนิคของซอฟต์แวร์ เทคโนโลยีล้าสมัย การโจมตีต่างๆ เช่น Malicious Code,Password Crack,Brute Force,Dictionary,Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS),Spoofing,Man-in-the-Middle,Spam เป็นต้น

ช่องโหว่ กระบวนการทำงาน กฎ ระเบียบ ซอฟต์แวร์ หรือคอมโพเนนต์ใดๆ ที่ทำให้ภัยคุกคามต่างๆ สร้างความเสียหายได้ เช่น ช่องโหว่ใน Web Server ที่ทำให้แฮกเกอร์เจาะเข้าสู่ระบบได้ ช่องโหว่ใน Network Policy ที่ทำให้เกิดการเชื่อมต่อที่ผิดปกติได้ การให้สิทธิในระบบงานที่มากเกินกว่าหน้าที่ของบุคลากร การกำหนดการไหลของกระบวนการทำงานที่อาจทำให้เกิดคอขวด หรือมีผู้รับผิดชอบเพียงผู้เดียว การขาดนโยบาย หรือมีนโยบายด้านการรักษาความปลอดภัยที่หละหลวมเกินไป ฯลฯ

การควบคุม การใช้ Security Infrastructure ต่างๆ ลดโอกาสการเกิดภัยคุกคาม หรือลดความเสียหายที่อาจเกิดขึ้น Assessment / Hardening ลดช่องโหว่ในระบบงาน การทำ Preventive Control เช่น กำหนด Maintenance Plan Security Awareness Training การกำหนดนโยบายต่างๆ ตาม ISO/IEC 27001

การตอบสนองต่อภัยคุกคามต่างๆ

ปัญหาความปลอดภัยในระบบ การเกิดปัญหาความปลอดภัยในระบบต้องมีองค์ประกอบทั้ง 2 ส่วนอย่างครบถ้วน เหตุ คือ ช่องโหว่ในระบบ ปัจจัย คือ การโจมตีไปยังช่องโหว่ของระบบ

ปัญหาความปลอดภัยในระบบ ช่องโหว่ + การโจมตีช่องโหว่ = ปัญหาความปลอดภัยระบบ System ช่องโหว่ ภัยคุกคาม System Problem

การลดปัญหาในระบบ มักใช้หลักการของ PDR ในการสร้าง Availability ลดช่องโหว่ในระบบ การควบคุมเพื่อคัดกรองการโจมตีไม่ให้เข้าสู่ระบบ การตอบสนองต่อปัญหาอย่างรวดเร็ว

กระบวนการในการลดปัญหาในระบบ ทำ Assessment เพื่อทราบปริมาณของช่องโหว่ในระบบ ทำ Hardening เพื่อลดปริมาณช่องโหว่ในระบบ ทำการ Filter การโจมตีที่เข้ามาในระบบ ทำการ Monitoring เพื่อให้ทราบถึงการโจมตีช่องโหว่ในระบบ