สำหรับผู้ใช้งาน AWS ที่พึงพอใจเรื่อง Best Practice ในการทำ Backup วันนี้เราขอสรุปสาระจากบล็อกของ AWS มาให้ติดตามกันนะครับ
1.) มีวิธีการด้านการสำรองข้อมูล
มีแผนการสำรองข้อมูลเด่นชัด ยกตัวอย่างเช่น ข้อมูลส่วนใด จะทำหลายครั้งแค่ไหน ติดตามการสำรองและกู้คืนอย่างไร
ประเมินว่าอาจมีเหตุก่อกวนใดเกิดขึ้นได้บ้าง และจะมีผลกระทบยังไง
มีรายละเอียดการสำรองแล้วก็กู้คืนเชิงลึกกระจ่างแจ้ง ยกตัวอย่างเช่น Point-in-time, Continuous Backup, ทำที่ระดับไฟล์ แอป Volume หรือ instance เป็นต้น และทำแล้วตอบปัญหา RTO/RPO หรือไม่
อุบายที่ดีต้องมีรายละเอียดกิจกรรมย่อยซึ่งสามารถคุ้มครองปกป้องการจู่โจมอย่างละเอียด เป็นต้นว่า แบบการยืมเป็นแบบผ่านบัญชี AWS หรือข้าม Region
บางอุตสาหกรรมจำเป็นต้องนึกถึงเรื่องกฏหมายและข้อกำหนดเพราะจะเก็บกี่ชุด นานเท่าใด
หารือกับกลุ่ม Security ที่ทำกฎเกณฑ์เพราะทรัพยากรที่ต้อง Backup และกิจกรรมพวกนั้นควรจะรวมหรือแยกจากโปรแกรมที่บังคับในองค์กร
2.) แผนการแบ็กอัพข้อมูลควรจะเป็นส่วนใดส่วนหนึ่งของวิธีการทำ DR รวมทั้ง BCP
DR เป็นการจัดเตรียม กระบวนการสนองตอบ และกู้คืนจากภัย อาทิเช่น ข้อผิดพลาดด้านเทคนิค ภัยที่เกิดจากธรรมชาติ หรือความบกพร่องของคนเรา ส่วน BCP หมายถึงแนวทางการทำให้ธุรกิจสามารถก้าวเดินต่อไปเมื่อเกิดเหตุที่กระทบต่อการให้บริการที่มิได้วางแผน ดังนี้ DR แล้วก็ AWS Backup ควรจะเป็นส่วนย่อยภายใต้ BCP เพื่อจัดแจงกับเหตุการณ์เป็นต้นว่า เกิดเหตุการด้านความยั่งยืนมั่นคงปลอดภัยที่กระทบกับข้อมูล Production ทำให้จำต้องใช้ข้อมูลที่สำรองไว้ ยิ่งไปกว่านี้พนักงานควรจะมีความชำนาญที่ทำได้จริงด้วย
3.) สร้างแนวทางการให้เป็นอัตโนมัติถ้าหากหน่วยงานสามารถสร้างกรรมวิธีการที่อัตโนมัติได้จะช่วยให้ การ Deploy Policy เป็นได้อย่างเป็นมาตรฐาน โดยเครื่องมือ AWS Organization เป็นสิ่งที่สามารถตอบโจทย์ตรงนี้ได้ ยิ่งกว่านั้นต้องมีการทำ Infrastructure as Code หรือปฏิบัติการได้แบบ Event-driven ซึ่งเมื่อกำเนิดความอัตโนมัติแล้วจะช่วยลดความผิดพลาดจากการทำงานแบบ Manual ได้
4.) มีกลไกการควบคุมและการให้อำนาจสิทธิ์ในเบื้องต้นท่านสามารถใช้เครื่องมือ AWS IAM เพื่อตอบปัญหาด้านการ Authentication & Authorization รวมทั้งควรจะไตร่ตรองตามหลัก Least Privilege โดยการให้สิทธิ์ต่ำที่สุดที่ต้อง เพื่อเข้าถึงข้อมูล Backup หรือ Vault นอกจากนั้นท่านยังสามารถใช้ Service Control Policy (SCP) เพื่อควบคุมสิทธิ์สูงสุดของบัญชีในองค์กร มากยิ่งกว่านั้น AWS ยังมีเครื่องมือ IAM Access Analyzer ที่จะสามารถช่วยพินิจพิจารณา IAM Role ที่แชร์ในบัญชี AWS, Root User, IAM User หรือ Federate User รวมทั้งอื่นๆ
5.) เข้ารหัสข้อมูลและก็ Vaultในกรณีที่ Access Control ยังไม่สามารถที่จะคุ้มครองปกป้องได้ทั้งหมดเช่น การให้สิทธิ์มากไปสำหรับการเข้าถึง ระบบบริหารจัดแจง Key จะช่วยลดผลพวงของเรื่องได้ ซึ่งในส่วนของการส่งผ่านข้อมูล (in transit) AWS Backup ได้มีการปกป้องแล้วระหว่างการเรียกใช้ API ด้วย Transport Layer Security (TLS) แต่ในช่วงเก็บข้อมูลท่านสามารถใช้วัสดุ AWS Key Management system (KMS) หรือ Cloud HSM ซึ่งมีอัลกอรึทึมการเข้ารหัสที่เป็นมาตรฐานให้แล้ว เพียงแค่ท่านเลือกใช้ให้เหมาะสมกับความจำเป็นของกฏหมาย ข้อบังคับขององค์กรเพียงแค่นั้น
มากกว่านั้นผู้ใช้งาน AWS ยังสามารถสร้าง KMS Multi-region key เพื่อใช้ Key จาก Region อื่นมาจัดแจงอีก Region ได้ทำให้การเปลี่ยนที่ข้อมูลเข้ารหัสง่ายมากขึ้น
6.) ใช้ Immutable StorageImmutable Storage หรือการใช้แรงงานในลักษณะซึ่งสามารถเขียนครั้งเดียวแต่ว่าเรียกอ่านได้เสมอ โดยฐานรากแล้วการทำเช่นนี้จะช่วยเรื่อง Integrity ป้องกันการเขียนทับ ลบ หรือทำความเสียหาย ซึ่งการใช้ AWS Backup Vault Lock สามารถช่วยคุ้มครองกิจกรรมความประพฤติปฏิบัติอะไรก็แล้วแต่กับข้อมูล Backup จากผู้ใช้ที่มีสิทธิ์กระทั่ง Root User ในบัญชี AWS
7.) มีการติดตามแล้วก็ระบบแจ้งเตือนงาน Backup บางทีอาจล้มเหลวได้ ซึ่งจะกระทบกับวิธีการทั้งหมด ซึ่งผู้ใช้สามารถเรียนรู้ปัจจัยได้จากการตำหนิดตามระบบแจ้งเตือนจาก Amazon SNS รวมไปถึงติดตามค่าเมทริกซ์ได้ผ่านทาง CloudWatch หรือ EventBridge เพื่อติดตามการ Backup รวมทั้ง Event รวมถึง CloudTrail จะสามารถบอกได้ว่า Backup API เป็นอย่างไร
8
.) ตรวจทานการตั้งค่าการ Backupหน่วยงานจำต้องตรวจทานให้มั่นใจว่า Backup Policy ตรงกับข้อบังคับไหม รวมทั้งจำต้องทำอย่างต่อเนื่อง ซึ่งน่าจะติดตามผลการตรวจตราได้อัตำหนิโนมัติเตียน โดยท่านสามารถสร้างรายงานอัตโนมัติด้วย Backup Audit Manager ตามบัญชีและก็ Region ได้ ว่ามีทรัพยากรใดที่ครอบคลุมจากแนวทางแบ็กอัพข้อมูล มีการทำบ่อยครั้งขนาดไหน
9.) ทดลองแผนการกู้คืนข้อมูลว่าทำเป็นจริงควรมีการทดลองเพื่อทราบว่า Recovery Point ใดซึ่งสามารถกู้คืนได้แน่ โดย AWS จะมีการ Copy Tag ของทรัพยากรที่ถูกคุ้มครองไปยัง Recovery Point โดยอัตโนมัติแต่ในทางกลับกันจะไม่มีการ Copy Tag จาก Recovery Point ไปยังทรัพยากรที่ถูกกู้คืน ซึ่งท่านควรจะเก็บ Tag ที่สร้างโดยงาน Backup เอาไว้ด้วยการใช้ AWS Backup Event เพื่อติดตามกระบวรการ Replicate
อย่างไรก็แล้วแต่หน่วยงานควรจะมี Workflow ง่ายๆสำหรับกู้คืนข้อมูลที่จะทำได้บ่อยมากได้แก่ การยืมคืนข้อมูลผ่านบัญชีหรือ Region จากการสำรองข้อมูลศูนย์กลาง แม้มีการทดสอบไม่บ่อยพอเพียงท่านอาจพบข้อผิดพลาดของ KMS Encryption สำหรับในการผ่านบัญชีหรือ Region
10.) บรรจุแผนเรื่อง Backup ลงในการทำ Incident Responseกลยุทธ์สนองตอบเหตุการณ์พลิกผันควรจะมีหัวข้อการทดลอง Backup ไว้ด้วย เพื่อจะได้ทราบว่าถ้าเกิดเหตุจริงจะมีขั้นตอนอย่างไรให้พร้อมต่อกร โดยท่านสามารถใช้ AWS Backup เพื่อทดลองการ Backup ระดับ Instance และ Volume โดยการ Snapshot ข้ามบัญชี ซึ่งข้อมูลนี้จะช่วยให้กลุ่มพิสูจน์หลักฐานทำงานได้ดีขึ้นอย่างเช่น การเก็บ Disk จุดเกิดเหตุหรือรู้ Recovery Point ที่ลดผลพวงจากการจู่โจม
