Khôi phục hệ thống (Disaster Recovery) đóng vai trò quan trọng trong chiến lược duy trì hoạt động kinh doanh tổng thể của một tổ chức. Khi triển khai giải pháp Disaster Recovery, bạn phải hiểu các động lực kinh doanh cùng với bất kỳ yêu cầu quản trị, bảo mật và vận hành nào ảnh hưởng đến giải pháp cuối cùng. Ví dụ: các tổ chức có thể có yêu cầu duy trì các tài khoản khác nhau để cô lập bảo mật, kiểm soát phân bổ chi phí hoặc đáp ứng các yêu cầu quản trị. Trong các tình huống khác, có thể cần có nhiều tài khoản phục hồi cho mục đích thử nghiệm riêng biệt, chẳng hạn như diễn tập DR hoặc tiến hành giám định pháp y sau sự kiện mạng. Các yêu cầu kinh doanh, quản trị, bảo mật và vận hành này có thể tác động đáng kể đến chiến lược và triển khai Disaster Recovery tổng thể.
AWS Elastic Disaster Recovery là dịch vụ giúp giảm thời gian chết và mất dữ liệu với khả năng khôi phục nhanh chóng, đáng tin cậy các ứng dụng tại chỗ và trên nền tảng đám mây tới Amazon Web Service (AWS). Dịch vụ này có thể giảm Mục tiêu điểm khôi phục (RPO) của bạn xuống còn vài giây và Mục tiêu thời gian khôi phục (RTO) xuống còn vài phút. Bạn có thể nhanh chóng khôi phục các hoạt động sau các sự kiện bất ngờ, chẳng hạn như sự cố phần mềm hoặc lỗi phần cứng của trung tâm dữ liệu. Elastic Disaster Recovery hỗ trợ sử dụng nhiều tài khoản để tách tài khoản dàn dựng, nơi dữ liệu được sao chép và duy trì, khỏi tài khoản mục tiêu, nơi thực hiện khôi phục thực tế. Nên sử dụng nhiều tài khoản khi mở rộng quy mô sử dụng Elastic Disaster Recovery để bảo vệ hơn 300 máy chủ nguồn. Tuy nhiên, chúng ta cũng có thể sử dụng nhiều tài khoản để bảo mật và cô lập, đơn giản hóa việc quản lý và cải thiện hoạt động bằng cách cho phép khôi phục bất kỳ máy chủ nguồn nào thành nhiều tài khoản mục tiêu để thử nghiệm, phát triển và sản xuất.
Trong bài đăng này, AWS giới thiệu các khả năng đa tài khoản của Elastic Disaster Recovery và trình bày cách người dùng có thể thiết kế và triển khai các giải pháp Disaster Recovery đáp ứng nhu cầu riêng của họ đồng thời đảm bảo tính liên tục của hoạt động kinh doanh và bảo vệ dữ liệu. Chúng tôi xem xét ba trường hợp sử dụng để sử dụng các khả năng đa tài khoản của dịch vụ Elastic Disaster Recovery. Trường hợp đầu tiên trình bày cách người dùng có thể tách các tài nguyên dàn dựng khỏi các tài khoản nguồn và đích để cung cấp khả năng cô lập và bảo mật cao hơn nhằm đáp ứng các yêu cầu về tuân thủ và quy định. Trường hợp thứ hai cho thấy cách thúc đẩy các hoạt động thực hành tốt nhất bằng cách cung cấp các tài khoản khôi phục riêng biệt để hỗ trợ thử nghiệm, diễn tập Disaster Recovery và kiểm toán. Kịch bản cuối cùng đề cập đến cách người dùng có thể có chế độ xem tập trung của tất cả các tài nguyên Elastic Disaster Recovery của họ khi sử dụng nhiều tài khoản để đơn giản hóa các hoạt động.
Tổng quan về Multiple accounts trong AWS Elastic Disaster Recovery
Elastic Disaster Recovery sắp xếp các tài nguyên thành hai loại chính: dàn dựng và phục hồi. Các tài nguyên dàn dựng, bao gồm máy chủ sao chép và khối lượng dàn dựng, thường được đặt vào một mạng con dàn dựng duy nhất, nhưng chúng cũng có thể được tách thành các tài khoản AWS duy nhất của riêng chúng, được gọi là tài khoản dàn dựng. Các tài nguyên phục hồi, bao gồm các phiên bản phục hồi và khối lượng của chúng, cũng có thể được tách thành các tài khoản duy nhất được gọi là tài khoản mục tiêu. Khi sử dụng các khả năng đa tài khoản của Elastic Disaster Recovery, chúng tôi giới thiệu một khái niệm mới, được gọi là máy chủ nguồn mở rộng.
Các lợi ích của việc sử dụng tính năng đa tài khoản của Elastic Disaster Recovery bao gồm:
Cô lập và bảo mật : Bằng cách duy trì các tài khoản dàn dựng riêng biệt, người dùng có thể đảm bảo mức độ cô lập và bảo mật cao hơn cho dữ liệu dàn dựng. Sự tách biệt này giúp giảm thiểu rủi ro xóa dữ liệu vô tình hoặc cố ý trong trường hợp môi trường nguồn bị xâm phạm.
Tuân thủ và quản trị : Nhiều tổ chức có các yêu cầu theo quy định hoặc theo ngành cụ thể đòi hỏi phải xác thực tính sẵn sàng chuyển đổi dự phòng DR. Sử dụng nhiều tài khoản mục tiêu cho phép người dùng dễ dàng chứng minh sự tuân thủ của họ với các quy định này và đảm bảo rằng cơ sở hạ tầng DR của họ phù hợp với chính sách quản trị và bảo mật chung của họ.
Khả năng hiển thị và phân bổ chi phí : Việc có các tài khoản AWS riêng cho các đơn vị kinh doanh hoặc phòng ban khác nhau cho phép người dùng dễ dàng theo dõi và phân bổ chi phí DR liên quan đến từng doanh nghiệp. Điều này mang lại tính minh bạch về chi phí tốt hơn, cho phép tổ chức hiểu được chi phí phát sinh bởi các nhóm, dự án hoặc dịch vụ cụ thể.
Những lưu ý về Elastic Disaster Recovery
Sau đây là danh sách những cân nhắc chung cần được lưu ý cho cả ba tình huống.
- Quản trị tập trung nhiều tài khoản AWS bằng AWS Organizations, cho phép người dùng triển khai thanh toán hợp nhất và thực thi bảo mật thông qua chính sách kiểm soát dịch vụ (SCP). Ngoài ra, các công cụ như AWS Control Tower có thể giúp tự động hóa việc tạo tài khoản và giúp các hoạt động đa tài khoản hiệu quả hơn.
- Khi áp dụng chiến lược nhiều tài khoản, bạn phải tuân theo các biện pháp thực hành tốt nhất cho AWS Virtual Private Cloud (VPC), bao gồm định tuyến mạng an toàn giữa các tài khoản. Các dịch vụ AWS như AWS Transit Gateway và AWS VPC Peering có thể giúp thiết lập các kết nối mạng riêng tư, an toàn và có thể mở rộng.
- Khóa mã hóa được sử dụng để mã hóa các tài nguyên được dàn dựng phải được chia sẻ cho tất cả các tài khoản mục tiêu khi mở rộng máy chủ nguồn sang các tài khoản mục tiêu khác nhau
- Bạn không thể mở rộng máy chủ nguồn giữa các phân vùng AWS. Điều này có nghĩa là tài khoản AWS thương mại chỉ có thể được mở rộng cho các tài khoản AWS thương mại khác và tài khoản AWS GovCloud (US) chỉ có thể được mở rộng cho các tài khoản AWS GovCloud (US) khác.
Trong các phần sau, chúng tôi sẽ xem xét một số tình huống phổ biến liên quan đến nhiều tài khoản và các ví dụ minh họa.
Case-study 1: Tách biệt các tài nguyên dàn dựng khỏi môi trường nguồn và đích
Kịch bản này đề cập đến cách người dùng sử dụng Elastic Disaster Recovery có thể tách biệt các tài nguyên dàn dựng khỏi các tài khoản nguồn và mục tiêu. Việc sử dụng các tài khoản dàn dựng riêng biệt cho môi trường nguồn và môi trường phục hồi của họ cho phép người dùng Elastic Disaster Recovery được hưởng lợi từ tính bảo mật nâng cao, đáp ứng các yêu cầu tuân thủ và cung cấp khả năng quản lý tài nguyên và chi phí liên quan được cải thiện. Cuối cùng, điều này cải thiện hiệu quả và độ tin cậy tổng thể của chiến lược DR của họ.
Về kiến trúc
Như thể hiện trong Hình 1 sau đây , chúng tôi sử dụng nhiều tài khoản dàn dựng để căn chỉnh với hệ thống phân cấp tổ chức được xác định bởi các đơn vị kinh doanh (BU). Điều này cho phép phân tách dựa trên loại ứng dụng hoặc môi trường như Sản xuất/Phát triển. Việc phân tách tài khoản này cho phép kiểm soát hoạt động chi tiết hơn đối với các tài nguyên DR ở cấp độ BU. Hơn nữa, nó cũng cho phép người dùng kiểm soát tốt hơn việc phân bổ chi phí vì các tài nguyên sao chép được duy trì trong một tài khoản cụ thể của BU.
Để đạt được sự tách biệt tài khoản này, các máy chủ nguồn được triển khai thành các tài khoản dàn dựng riêng biệt và chức năng máy chủ nguồn mở rộng của nhiều tài khoản được sử dụng để mở rộng tất cả các máy chủ nguồn thành một tài khoản khôi phục duy nhất. Kiến trúc cho kịch bản này được hiển thị cho môi trường tại chỗ, nhưng điều này cũng có thể hợp lệ khi môi trường nguồn nằm trong AWS.
Hình 1: Phân chia tài nguyên tách biệt khỏi môi trường nguồn và phục hồi
Case-study 2: Mở rộng máy chủ nguồn thành nhiều tài khoản mục tiêu cho mục đích phục hồi bị cô lập
Kịch bản này giúp thúc đẩy các hoạt động thực hành tốt nhất bằng cách cung cấp các tài khoản khôi phục riêng biệt để hỗ trợ thử nghiệm, chạy diễn tập DR hoặc để tiến hành giám định pháp y. Các môi trường khôi phục bị cô lập này cũng có thể cung cấp tính linh hoạt cao hơn bằng cách cung cấp quyền truy cập rộng hơn vào các dịch vụ AWS trong khi sử dụng các rào chắn, điều này sẽ không thể thực hiện được trong các tài khoản khôi phục sản xuất. Việc có một tài khoản khôi phục riêng biệt cho các hoạt động này có thể giúp các nhóm hoạt động di chuyển nhanh hơn bằng cách giảm sự phụ thuộc vào các nhóm ứng dụng và giảm thiểu rủi ro tác động đến doanh nghiệp trong một sự kiện DR thực tế.
Kịch bản này cũng hữu ích nếu bạn chọn xây dựng quy trình làm việc tùy chỉnh cần được kích hoạt trong quá trình DR của mình. Bạn có thể tạo quy trình làm việc trong tài khoản mục tiêu để quét phần mềm độc hại sau khi khôi phục thành công và trước khi đưa vào sản xuất.
Về kiến trúc
Trong kiến trúc này, chúng tôi mô tả một tài khoản AWS có tên là AWS Source Account 1, có các máy chủ nguồn ở Vùng A đang sao chép sang Vùng B trong cùng một tài khoản AWS, như thể hiện trong Hình 2 sau . Trong trường hợp xảy ra thảm họa, tài nguyên sẽ được khôi phục vào Recovery Subnet ở Vùng B bằng cách sử dụng các thiết lập khởi chạy Amazon Elastic Compute Cloud (Amazon EC2) đã xác định được cấu hình trong tài khoản này.
Các máy chủ nguồn trong AWS Source Account 1 cũng đã được mở rộng bằng cách sử dụng nhiều tài khoản cho AWS Account 2 (Isolated Recovery Drill Account) và AWS Account 3 (Isolated Cyber Forensic Account). Phần mở rộng này chỉ mang tính logic, nghĩa là dữ liệu được sao chép vẫn nằm trong AWS Source Account 1 và một bản sao mở rộng của máy chủ nguồn được tạo trong mỗi tài khoản mục tiêu. Bản sao máy chủ nguồn mở rộng này có các thiết lập khởi chạy EC2 duy nhất được cấu hình theo trường hợp sử dụng bắt buộc, cho phép khôi phục vào mỗi Tài khoản AWS.
Hình 2: Máy chủ nguồn mở rộng thành nhiều tài khoản đích
Case-study 3: Mở rộng máy chủ nguồn để tạo chế độ xem tập trung cho các nhóm hoạt động
Kịch bản này cho phép người dùng có chế độ xem tập trung các máy chủ nguồn của họ trên nhiều tài khoản AWS vì lý do kinh doanh hoặc bảo mật. Tương tự như kịch bản trước, chúng tôi có môi trường nguồn, dàn dựng và phục hồi trong một tài khoản AWS duy nhất. Tuy nhiên, thiết lập này được lặp lại trên nhiều tài khoản theo cách phân tán. Sau đó, chúng tôi mở rộng các máy chủ nguồn từ mỗi tài khoản nguồn thành một tài khoản quản lý tập trung, cho phép bạn quản lý các máy chủ nguồn từ bên trong một tài khoản duy nhất. Tính năng này giúp thiết lập, triển khai và giám sát DR dễ dàng và hiệu quả hơn, đặc biệt là đối với các triển khai quy mô lớn.
Về kiến trúc
Trong trường hợp này, có nhiều Tài khoản AWS sử dụng Elastic Disaster Recovery để bảo vệ các phiên bản EC2 cho mục đích phục hồi thảm họa liên vùng. Mỗi máy chủ nguồn được quản lý từ tài khoản AWS tương ứng từ bảng điều khiển Elastic Disaster Recovery, như thể hiện trong Hình 3 sau .
Một tài khoản quản lý riêng biệt được tạo ra và các máy chủ nguồn từ mỗi tài khoản được mở rộng đến tài khoản tập trung này. Các máy chủ nguồn mở rộng này không được sử dụng cho mục đích phục hồi mà thay vào đó là cho mục đích hoạt động như báo cáo tập trung và quản lý trạng thái sao chép hoặc để thu thập thông tin chi tiết bằng cách sử dụng quy trình làm việc được xây dựng trên các dịch vụ như Amazon CloudWatch hoặc Amazon EventBridge .
Hình 3: Máy chủ nguồn mở rộng để tạo chế độ xem tập trung cho các nhóm hoạt động
Phần kết luận
Trong bài đăng này, chúng tôi đã chứng minh rằng khi xây dựng kế hoạch duy trì hoạt động kinh doanh và triển khai giải pháp DR với Elastic Disaster Recovery, điều quan trọng là phải hiểu các động lực kinh doanh cũng như các yêu cầu về quản trị, bảo mật và hoạt động. Elastic Disaster Recovery hỗ trợ việc sử dụng nhiều tài khoản để cung cấp tính linh hoạt nhằm đáp ứng nhiều yêu cầu khác nhau. Điều này bao gồm thiết kế để mở rộng quy mô, quản lý phân bổ chi phí, đáp ứng nhu cầu quản trị hoặc cải thiện hoạt động. Khả năng mở rộng máy chủ nguồn sang nhiều tài khoản phục hồi cũng cho phép các quy trình làm việc nâng cao để thử nghiệm riêng biệt, diễn tập DR và giám định sự kiện mạng, đây là những yếu tố rất quan trọng để đảm bảo tính liên tục của hoạt động kinh doanh và bảo vệ dữ liệu.
Khi sử dụng tính năng đa tài khoản của Elastic Disaster Recovery, bạn có thể thiết kế và triển khai các giải pháp DR đáp ứng nhu cầu riêng của doanh nghiệp mình đồng thời đảm bảo tính liên tục của doanh nghiệp và bảo vệ dữ liệu. Các lợi ích bao gồm khả năng cô lập và bảo mật cao hơn để đáp ứng các yêu cầu về tuân thủ và quy định, cải thiện hoạt động để hỗ trợ thử nghiệm, diễn tập DR và kiểm toán, cũng như tập trung hóa hoạt động để đơn giản hóa việc quản lý môi trường DR của bạn.
Tìm hiểu thêm về AWS service tại OSAM:
(1) https://osam.io/amazon-inspector-mo-rong-kha-nang-bao-mat-ma-nguon/
