Trong mỗi bài diễn tập khắc phục thảm họa giả lập hay còn gọi là diễn tập trong phòng họp (mà tiếng Anh gọi là tabletop exercise) ở mọi bộ phận IT, luôn có kịch bản liên quan đến các mối đe dọa nghiêm trọng như xâm nhập mã độc, đánh cắp dữ liệu, ransomware và các mối đe dọa nặng hơn (và ít có khả năng xảy ra hơn), như thiên tai, tai nạn và các tình trạng hỗn loạn liên quan đến công nghệ.
Những cơn bão, vụ nổ, động đất, hỏa hoạn và lũ lụt không có trong biện pháp an ninh mạng và thường mang lại những kết quả tệ hại. Điều này đòi hỏi các CIO cần có những kế hoạch đối phó với những thảm họa trên quy mô lớn.
Một trong những bằng chứng rõ ràng hơn về sức mạnh của thiên tai đã xãy ra hôm trung tuần tháng 3 khi một trong những công ty lưu trữ đám mây lớn nhất châu Âu, OVH Groupe SAS, hay còn được gọi là OVHCloud, đã bị hỏa hoạn thảm khốc tại cơ sở ở Strasbourg, Pháp. Vụ cháy trong một cụm cấu trúc hình hộp, là các chồng container vận chuyển được tái sử dụng để tiết kiệm chi phí xây dựng – đã phá hủy hoàn toàn một trong bốn trung tâm dữ liệu của OVH tại địa điểm và làm hư hỏng nặng một trung tâm khác.
Các lãnh đạo của OVH đã nhanh chóng đưa ra báo động, và người sáng lập kiêm chủ tịch Octave Klaba cảnh báo rằng có thể mất vài tuần để công ty khôi phục hoàn toàn và thúc giục khách hàng thực hiện kế hoạch khôi phục dữ liệu của riêng họ.
Dữ liệu được bảo vệ nghiêm ngặc vẫn là một vấn đề quan trọng đối với các doanh nghiệp thuộc mọi quy mô và kích thước. Vào năm 2018, Riverbank IT Management ở Vương quốc Anh phát hiện ra rằng 46% doanh nghiệp vừa và nhỏ không có sẵn kế hoạch sao lưu và phục hồi (backup and recovery). Hầu hết các công ty (95%) không đảm bảo được tất cả dữ liệu của họ, tại chỗ và (on-prem) trên đám mây, có trong bất kỳ kế hoạch sao lưu nào mà họ có.
Kết quả của sự thiếu thận trọng như vậy là phải trả giá đắt. Theo Gartner, thời gian ngừng hoạt động theo hướng dữ liệu khiến công ty tiêu tốn trung bình 300.000 đô la mỗi giờ – tức là 5.600 đô la mỗi phút. Vụ phá hủy cơ sở OVH trên bờ sông Rhine gần biên giới Đức đã phá hủy 3,6 triệu trang web, từ các cơ quan chính phủ đến các tổ chức tài chính cho đến các công ty trò chơi máy tính, nhiều trang web trong số đó đã phải ngưng hoạt động trong nhiều ngày. Có rất nhiều phàn nàn trên các blog và phương tiện truyền thông xã hội rằng dữ liệu trong nhiều năm đã bị mất vì sự cố OVH. Những thiệt hại về tài chính cuối cùng sẽ rất đáng kinh ngạc.
Trong thời đám mây và chuyển đổi kỹ thuật số phổ biến ngày nay, lãnh đạo CNTT có thể làm gì để chống lại các mối nguy lớn và nhỏ? Câu trả lời nằm trong kế hoạch gọi là tính liên tục trong kinh doanh và phục hồi sau thảm họa – business continuity and disaster recovery (BCDR). Kỷ luật được hệ thống hóa tốt trong bảo mật thông tin, nhưng thường bị thiếu trong quản lý và giảm thiểu rủi ro doanh nghiệp. Hầu hết các tổ chức hiểu các quy tắc cơ bản của BCDR, nhưng các chuyên gia bảo mật đồng ý rằng việc thực thi thường thiếu tính chặt chẽ và cam kết.
Chuyên gia bảo mật đám mây Dave Shackleford, người sáng lập và cố vấn tại Voodoo Security ở Roswell, Georgia, cho biết: “Là một CIO, ngay lập tức tôi muốn hỏi“ Chúng ta đã thực sự kiểm tra khả năng sao lưu và khôi phục của mình chưa? Dù dựa trên đám mây hay không, quá nhiều tổ chức biến việc lập kế hoạch và thử nghiệm phục hồi sau thảm họa và tính liên tục của doanh nghiệp thành‘ bài tập trên giấy ’mà không thực sự đảm bảo chúng có hiệu quả”.
Đối với các tổ chức đang tìm cách bảo vệ các tài sản kỹ thuật số quan trọng, điều mà Shackleford cho là cách tiếp cận BCDR hiệu quả bắt đầu với một vài phương pháp hay nhất đã được kiểm nghiệm theo thời gian.
Bắt đầu với nhà cung cấp dịch vụ của bạn
Cần phải đặt câu hỏi cho nhà cung cấp về khả năng dự phòng và khả năng phục hồi và cần nhận nó bằng văn bản. Việc mất hai trung tâm dữ liệu đám mây sẽ luôn dẫn đến gián đoạn và thời gian chết, đặc biệt đối với một công công ty như OVH với 300.000 máy chủ tại 14 cơ sở trên khắp châu Âu và 27 trên toàn thế giới. Nhưng mức độ thiệt hại và kéo dài đó sẽ phụ thuộc phần lớn vào các giao thức sao lưu và dự phòng lỗi của chính công ty lưu trữ.
Các đảm bảo, như được nêu trong thỏa thuận cấp dịch vụ (SLA), cũng phải vượt ra ngoài quá trình xử lý và lưu trữ dữ liệu. Một phần lớn các rắc rối của OVH có trụ sở tại Roubaix bắt nguồn từ sự cố của nguồn cung cấp điện dự phòng làm hỏng các máy chủ được xây dựng tùy chỉnh của chính nó – ngay cả ở những khu vực không bị ảnh hưởng bởi đám cháy thực tế.
Hãy tìm các mục trong SLA không chỉ đề cập đến việc đảm bảo dịch vụ mà còn đề cập đến tính đủ điều kiện để được bồi thường và mức bồi thường được đưa ra. Cung cấp khả năng cung cấp “five-nines” là rất tốt, nhưng chủ nhà cũng phải thể hiện cam kết với các kết nối chuyển tuyến đa dạng; nhiều nguồn điện; thiết bị mạng dự phòng; và nhiều nội dung lưu trữ rời rạc.
Sắp xếp trật tự
Giữ cho nhà cung cấp dịch vụ máy chủ đám mây của bạn có trách nhiệm giải trình là một khởi đầu vững chắc, nhưng điều quan trọng cần nhớ là, trải nghiệm OVH mang lại một thực tế đáng kinh ngạc, là đám mây cấp doanh nghiệp không phải là một lĩnh vực thần thoại với tài nguyên vô hạn và thời gian hoạt động vĩnh cửu. Di chuyển các tài sản kỹ thuật số quan trọng lên đám mây có nghĩa là hoán đổi cơ sở hạ tầng của chính bạn cho cơ sở hạ tầng của một đối tác nhà cung cấp vì lợi nhuận khác.
Yêu cầu đầu tiên đối với việc di chuyển qua đám mây là thiết lập một khuôn khổ để xác định sự khôn ngoan và hiệu quả của việc thực hiện một bước di chuyển như vậy lên đám mây ngay từ đầu. Sau đó, cần phải có một kế hoạch toàn diện để bảo vệ mọi thứ mà tổ chức đang nắm giữ.
“Thống kê tất cả các tài sản quan trọng của bạn,” van Wyk gợi ý. “Hãy hỏi bạn sẽ phải trả bao nhiêu nếu bất kỳ cái nào trong số các tài sản đó không có sẵn, vì bất kỳ lý do gì, trong một giờ, một ngày, một tuần. Hỏi xem bạn sẽ khôi phục doanh nghiệp của mình như thế nào nếu mọi thứ bị bốc hơi. Thời gian chết sẽ là gì? Bạn có đủ khả năng không? Kế hoạch B của bạn là gì? ”
Liên minh bảo mật đám mây (Cloud Security Alliance) cung cấp hướng dẫn tuyệt vời cho việc chuẩn bị, phân tích các dự án đám mây có quan tâm đến rủi ro, đặc biệt là với Ma trận kiểm soát đám mây Cloud Controls Matrix (CCM) của họ.
Nếu lưu trữ của bên thứ ba được bảo đảm, nó phải được hướng dẫn bởi chính sách chính thức bao gồm các vấn đề như:
- Các định nghĩa cho hệ thống, kiểu dữ liệu và cấp phân loại có thể được tính đến trong đánh giá rủi ro.
- Các chính sách và tiêu chuẩn nội bộ kèm theo từng cấp phân loại
- Yêu cầu về ứng dụng và bảo mật
- Yêu cầu tuân thủ / quy định cụ thể
- Và một kế hoạch BCDR bao gồm tất cả các tài sản được ủy thác cho tất cả các nhà cung cấp bên thứ ba.
Tạo bản sao lưu chống cháy
Hiểu rằng các sự cố có thể xảy ra. Sao lưu và phục hồi là yếu tố cơ bản đối với bộ ba bảo mật về tính bảo mật, tính toàn vẹn và tính khả dụng của dữ liệu (confidentiality, integrity, and availability – CIA) đến mức nó được định nghĩa thành một lĩnh vực riêng trong Khung an ninh mạng NIST (NIST Cybersecurity Framework.) . NIST’s CSF khuyến khích các tổ chức đảm bảo rằng “các quy trình và quy trình khôi phục được thực thi và duy trì để đảm bảo khôi phục kịp thời các hệ thống hoặc tài sản bị ảnh hưởng bởi sự cố an ninh mạng”.
Câu trên mang nhiều ý nghĩa. Việc phát triển một cách tiếp cận mạnh mẽ để khôi phục sau sự cố, đáp ứng được các tiêu chuẩn NIST và chịu được sự kiện thảm khốc như vụ cháy OVH mất nhiều (thời gian, công sức, chi phí..) hơn việc lên lịch cho một số bản sao lưu tự động và hy vọng điều tốt nhất.
Van Wyk cho biết bạn nên thực hiện các biện pháp phòng ngừa bổ sung với quá trình xử lý và dữ liệu kinh doanh quan trọng của mình và đảm bảo rằng bạn sẽ thực sự có thể sử dụng các kế hoạch dự phòng của mình trong các tình huống khẩn cấp khác nhau.
Cho dù trong môi trường kết hợp hay chỉ trên đám mây, thì phương pháp BCDR thực tế và hiệu quả phải bao gồm:
- Chính thức: Một kế hoạch khắc phục hậu quả thiên tai thực sự và hiệu quả phải được lập thành văn bản. Viết kế hoạch bằng văn bản, bao gồm ai, cái gì, ở đâu, khi nào và bằng cách nào, tất cả đều giúp các tổ chức định lượng các hành động cần thiết để ngăn ngừa, phát hiện, phản ứng và giải quyết các sự kiện mất dữ liệu.
- Định lượng dữ liệu có thể gặp rủi ro: Tài liệu BCDR là nơi tốt nhất để tập hợp một lược đồ phân loại dữ liệu chi tiết và một sổ đăng ký rủi ro (risk register) cụ thể, bao gồm một danh sách các mối đe dọa mà tổ chức phải đối mặt, hậu quả của các loại dữ liệu bị mất khác nhau và một danh sách các biện pháp giảm thiểu (mitigation).
- Định nghĩa vai trò trách nhiệm: Một cách tiếp cận BCDR thuần thục đòi hỏi nhiều hơn các chính sách và quy trình; nó đòi hỏi một nhóm các bên liên quan chuyên trách chịu trách nhiệm về các phần khác nhau của kế hoạch. Một nhóm khắc phục thảm họa toàn diện nên đại diện cho các lĩnh vực đa dạng của doanh nghiệp, những người có thể đánh giá thiệt hại, bắt đầu kế hoạch khôi phục và giúp cập nhật các kế hoạch khắc phục thảm họa. Đây là những người biết phải làm gì khi sự cố xảy ra.
- Đảm bảo liên lạc: Một phần quan trọng trong hướng dẫn của NIST về khôi phục yêu cầu rằng “các hoạt động khôi phục được phối hợp với các bên trong và bên ngoài, chẳng hạn như trung tâm điều phối, nhà cung cấp dịch vụ internet, chủ sở hữu của hệ thống, nạn nhân và nhà cung cấp”. Điều này đòi hỏi phải có kế hoạch chu đáo, trước để đảm bảo thông tin liên lạc luôn cởi mở với nhân viên, khách hàng, cơ quan thực thi pháp luật, nhân viên khẩn cấp và thậm chí cả giới truyền thông. Sức nóng của thời điểm này không phải là lúc để tranh giành thông tin liên hệ.
- Kiểm tra tính hiệu quả: Thực hiện các bài kiểm tra và bài tập khắc phục sự cố chính thức trong khoảng thời gian đều đặn là rất quan trọng đối với sự thành công của BCDR. Thời khắc quan trọng (khi xãy ra sự cố) không phải là lúc để tìm hiểu xem liệu các bản sao lưu (backup) có thể được phục hồi thành công hay không. Các hoạt động hợp lý phải bao gồm các mục tiêu thực tế, với các vai trò và trách nhiệm cụ thể, để kiểm tra khả năng phục hồi của tổ chức.
- Giữ cho nó luôn tươi mới: Các kế hoạch BCDR nên được xem xét hàng năm để đảm bảo chúng vẫn phù hợp và thực tế. Hơn nữa, mọi lần chạy thử, mọi bài tập và mọi sự cố mất dữ liệu, dù nhỏ đến đâu, đều là cơ hội tuyệt vời để kiểm tra các bài học kinh nghiệm và thực hiện các cải tiến thực tế.
Kết luận
Không có kế hoạch về business continuity and disaster recovery (BCDR) nào có thể ngăn chặn mọi hỗn loạn và đảm bảo bảo vệ hoàn hảo. Nhưng như thảm họa OVH đã chứng minh, các chính sách nửa vời và các giao thức không đầy đủ có hiệu quả như không có kế hoạch nào cả. Thiết lập một thế trận BCDR vững chắc đòi hỏi sự đầu tư có ý nghĩa về nguồn lực, thời gian và vốn. Phần thưởng là khi đèn nhấp nháy trở lại và hệ thống hoạt động lại, dữ liệu vẫn nguyên vẹn và mọi thứ trở lại như cũ.
Theo https://venturebeat.com/2021/03/12/cloudburst-hard-lessons-learned-from-the-ovh-datacenter-blaze/
