สำหรับผู้ใช้งาน 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
. [pr]) ตรวจสอบการตั้งค่าการ 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 ที่ลดผลกระทบจากการโจมตี
