สำหรับผู้ใช้งาน 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 ที่ลดผลพวงจากการจู่โจม
