Nhiều người nói hầu hết các sự cố bảo mật khi sử dụng điện toán đám mây đều liên quan tới việc cấu hình sai của người dùng nhưng nhìn nhận một cách toàn diện hơn thì vấn đề là các doanh nghiệp chưa hiểu rõ mô hình chia sẻ trách nhiệm bảo mật trong ứng dụng điện toán đám mây. Một báo cáo ESG gần đây cho thấy 33% công ty chỉ trông chờ vào nhà cung cấp dịch vụ để bảo vệ dữ liệu ứng dụng thường trú trên SaaS của họ.
Khi xem xét và đánh giá các dịch vụ đám mây công cộng, điều quan trọng là phải hiểu mô hình chia sẻ trách nhiệm, biết rõ nhiệm vụ bảo mật nào do nhà cung cấp dịch vụ điện toán đám mây (CSP) xử lý và nhiệm vụ nào thuộc trách nhiệm của người dùng. Khối lượng công việc được chia sẻ cho mỗi bên sẽ khác nhau tùy thuộc vào việc hệ thống được vận hành theo kiểu Phần mềm dưới dạng Dịch vụ (SaaS), Nền tảng dưới dạng Dịch vụ (PaaS), Cơ sở hạ tầng dưới dạng Dịch vụ (IaaS) hay trong trung tâm dữ liệu tại chỗ.
Với trung tâm dữ liệu tại chỗ, người dùng sở hữu toàn bộ mọi thứ nên sẽ chịu trách nhiệm từ A đến Z. Khi chuyển sang đám mây, một số trách nhiệm sẽ được chuyển giao cho CSP. Sơ đồ dưới đây minh họa các lĩnh vực trách nhiệm được chia sẻ giữa khách hàng và Microsoft tùy theo kiểu dịch vụ điện toán đám mây được sử dụng.
Với tất cả các loại triển khai đám mây, khách hàng luôn sở hữu dữ liệu và danh tính của mình. Họ chịu trách nhiệm bảo vệ tính bảo mật của dữ liệu và danh tính, tài nguyên tại chỗ và các thành phần đám mây mà họ kiểm soát (thay đổi theo loại dịch vụ).
Bất kể loại triển khai nào, khách hàng luôn là người đảm nhận các trách nhiệm sau: Dữ liệu, thiết bị đầu cuối, tài khoản, quản lý truy cập.
Lợi thế về an ninh bảo mật của đám mây
Đám mây mang lại những lợi thế đáng kể để giải quyết những thách thức lâu dài về bảo mật thông tin. Trong môi trường tại chỗ, các tổ chức có thể có không đảm nhiệm hết được các trách nhiệm bảo đảm an ninh và các nguồn lực sẵn có không đủ để đầu tư vào bảo mật, điều này tạo ra một môi trường nơi những kẻ tấn công có thể khai thác các lỗ hổng ở tất cả các lớp. Sơ đồ sau đây cho thấy cách tiếp cận truyền thống trong đó nhiều trách nhiệm bảo mật không được đáp ứng do nguồn lực hạn chế. Với việc ứng dụng điện toán đám mây, doanh nghiệp có thể chuyển một phần trách nhiệm bảo mật hàng ngày cho nhà cung cấp đám mây và phân bổ lại tài nguyên của mình.
Mặt khác, doanh nghiệp cũng có thể tận dụng các khả năng bảo mật dựa trên đám mây để đạt hiệu quả cao hơn và sử dụng thông tin tình báo trên mạng để cải thiện thời gian phát hiện và phản hồi mối đe dọa của mình. Bằng cách chuyển trách nhiệm sang nhà cung cấp đám mây, các tổ chức có thể bao phủ nhiều phạm vi bảo mật hơn, cho phép họ phân bổ lại tài nguyên bảo mật và ngân sách cho các ưu tiên kinh doanh khác.
Những điều cần biết về mô hình chia sẻ trách nhiệm bảo mật
Khi các tổ chức xem xét và đánh giá các dịch vụ đám mây công cộng, điều cần thiết là khám phá xem các mô hình dịch vụ đám mây khác nhau sẽ ảnh hưởng như thế nào đến chi phí, tính dễ sử dụng, quyền riêng tư, bảo mật và tuân thủ. Vấn đề quan trọng không kém là khách hàng phải xem xét cách thức bảo mật và tuân thủ được quản lý bởi nhà cung cấp giải pháp đám mây (CSP), những người sẽ kích hoạt giải pháp điện toán an toàn. Điều không may là nhiều tổ chức lầm tưởng rằng sau khi chuyển sang đám mây, vai trò của họ trong việc bảo mật dữ liệu sẽ chuyển hầu hết các trách nhiệm tuân thủ và bảo mật cho CSP.
Trong mô hình chia sẻ trách nhiệm bảo mật AWS, Amazon tuyên bố chịu trách nhiệm “bảo vệ phần cứng, phần mềm, mạng và cơ sở chạy các dịch vụ Đám mây AWS”. Microsoft Azure thì tuyên bố quyền sở hữu bảo mật đối với “máy chủ vật lý, mạng và trung tâm dữ liệu”. Cả AWS và Azure đều nêu rõ rằng các trách nhiệm bảo mật của khách hàng phụ thuộc vào dịch vụ họ chọn.
Các nhà cung cấp đám mây phải đảm bảo bảo mật cho các yếu tố nhất định, chẳng hạn như cơ sở hạ tầng vật lý và các yếu tố mạng, nhưng khách hàng phải nhận thức được trách nhiệm của chính họ. CSP có thể cung cấp các dịch vụ giúp bảo vệ dữ liệu, nhưng khách hàng cũng phải hiểu vai trò của họ trong việc bảo vệ tính bảo mật và quyền riêng tư cho dữ liệu của họ. Ví dụ minh họa tốt nhất cho vấn đề này liên quan đến việc triển khai chính sách mật khẩu; biện pháp bảo mật tốt nhất của CSP cũng sẽ bị đánh bại nếu người dùng không sử dụng mật khẩu phức tạp hoặc khó đoán.
Một số trách nhiệm yêu cầu CSP và khách hàng quản lý và thực thi trách nhiệm cùng nhau, bao gồm việc kiểm toán các lĩnh vực của họ. Ví dụ: Xét mảng Quản lý danh tính và quyền truy cập khi sử dụng Dịch vụ Azure Active Directory; cấu hình của các dịch vụ như xác thực đa yếu tố tùy thuộc vào khách hàng nhưng việc đảm bảo chức năng hiệu quả là trách nhiệm của Microsoft.
Điểm trọng yếu để triển khai bảo mật thành công trong môi trường đám mây là hiểu được trách nhiệm của nhà cung cấp của người dùng kết thúc ở đâu và trách nhiệm của người dùng bắt đầu từ đâu. Câu trả lời không phải lúc nào cũng rõ ràng và các định nghĩa về mô hình bảo mật chia sẻ trách nhiệm có thể khác nhau giữa các nhà cung cấp dịch vụ và có thể thay đổi dựa trên việc người dùng đang sử dụng cơ sở hạ tầng dưới dạng dịch vụ (IaaS) hay nền tảng dưới dạng dịch vụ (PaaS).
Dù sử dụng mô hình tại chỗ hay đám mây, khách hàng đều phải chịu trách nhiệm đảm bảo giải pháp và dữ liệu của họ được xác định, gắn nhãn và phân loại chính xác một cách an toàn để đáp ứng mọi nghĩa vụ tuân thủ. Việc phân biệt giữa dữ liệu khách hàng nhạy cảm và nội dung được thiết kế để công khai luôn phải do khách hàng thực hiện. Các giải pháp SaaS như Office 365 và Dynamics 365 cung cấp khả năng bảo vệ dữ liệu của khách hàng, chẳng hạn như Office Lockbox và Data Loss Prevention, nhưng khách hàng phải là người quản lý, phân loại và định cấu hình các giải pháp để giải quyết các yêu cầu tuân thủ và bảo mật riêng của họ.
Đối với các giải pháp PaaS, trách nhiệm giải trình của khách hàng đối với việc phân loại và quản lý dữ liệu phải được coi là một phần thiết yếu của quy trình lập kế hoạch. Trong các giải pháp như vậy, khách hàng cần định cấu hình và thiết lập quy trình để bảo vệ cả dữ liệu và bộ tính năng của giải pháp để bảo vệ dữ liệu của họ.
Với mô hình dịch vụ IaaS, với các khả năng như máy ảo, lưu trữ và kết nối mạng, khách hàng có trách nhiệm định cấu hình và bảo vệ dữ liệu được lưu trữ và truyền đi. Khi sử dụng giải pháp dựa trên IaaS, việc phân loại dữ liệu phải được xem xét ở tất cả các lớp của giải pháp. Máy chủ được định cấu hình sai có thể ảnh hưởng đến cách dữ liệu được lưu trữ trong dịch vụ được bảo vệ. Yêu cầu tuân thủ cũng đòi hỏi khách hàng kiểm tra tất cả các máy ảo đã triển khai trong các giải pháp của họ.
Với SaaS, việc chia sẻ trách nhiệm giữa CSP và khách hàng có thể được minh họa trong triển khai dịch vụ web. Theo mặc định, dịch vụ web Azure được mở công khai để xem, trạng thái này có thể phù hợp hoặc không phù hợp với yêu cầu của khách hàng, vì thế khách hàng cần thay đổi cấu hình để đáp ứng yêu cầu của mình. Một lợi ích của các giải pháp PaaS là chúng không yêu cầu khách hàng tự triển khai các cấu hình bảo mật giống như triển khai cơ sở hạ tầng, chẳng hạn như máy ảo, vì CSP đã đảm nhận việc đó. Các ví dụ bao gồm quản lý bản vá, phần mềm chống phần mềm độc hại và cấu hình cơ bản. Ngoài ra, các báo cáo kiểm toán tuân thủ của CSP có thể được sử dụng để bổ sung cho việc triển khai của khách hàng nhằm đáp ứng các nghĩa vụ theo quy định và nỗ lực tuân thủ.
Dù khách hàng chịu trách nhiệm phân loại dữ liệu của họ, nhưng các nhà cung cấp đám mây phải cam kết bằng văn bản với khách hàng về cách họ sẽ bảo mật và duy trì quyền riêng tư của dữ liệu khách hàng được lưu trữ trong đám mây. Những cam kết này phải bao gồm thông tin về các biện pháp bảo mật và quyền riêng tư, giới hạn sử dụng dữ liệu và tuân thủ quy định. Ngoài ra, các nhà cung cấp đám mây nên cung cấp các chứng nhận và báo cáo kiểm tra chứng minh việc tuân thủ các tiêu chuẩn như Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) và các biện pháp kiểm soát như Viện Kiểm soát Tổ chức Dịch vụ CPA của Hoa Kỳ (SOC1 và SOC2) để khách hàng có thể xác minh hiệu quả thực hành của nhà cung cấp đám mây. Thông tin này sẽ giúp khách hàng hiểu liệu nhà cung cấp đám mây có hỗ trợ các yêu cầu bảo vệ dữ liệu bắt buộc theo phân loại dữ liệu của họ hay không. Khách hàng không nên di chuyển dữ liệu sang nhà cung cấp đám mây không thể giải quyết nhu cầu bảo vệ dữ liệu của họ.
Mặc dù cách diễn đạt tương tự nhau nhưng các thỏa thuận chia sẻ trách nhiệm vẫn để ngỏ nhiều vấn đề cần thảo luận và giải thích. Khi nói về trách nhiệm chung, điều quan trọng là phải hiểu rằng khách hàng và nhà cung cấp dịch vụ đám mây của họ không bao giờ chia sẻ trách nhiệm đối với một khía cạnh cụ thể của hoạt động bảo mật. Khi cả hai bên giả định không chính xác về trách nhiệm bảo mật của họ, những rủi ro là quá đáng sợ để tưởng tượng.
Để hiểu rõ hơn về điều này, hãy xem xét nền tảng AWS. AWS Trusted Advisor thực hiện kiểm tra cốt lõi đối với bất kỳ khách hàng nào đang sử dụng gói Hỗ trợ cơ bản. Amazon CloudTrail giúp ghi lại từng lệnh gọi API mà mọi dịch vụ thực hiện, điều này rất quan trọng để kiểm tra hậu kỳ. Thêm nữa, GuardDuty chủ động xác định các điểm bất thường bằng cách theo dõi liên tục nhật ký luồng VPC và nhật ký DNS. Ngoài ra còn có dịch vụ quản lý lỗ hổng bảo mật Inspector tự động đánh giá bảo mật dựa trên các agent. Điều này nghe giống như một kế hoạch bảo mật toàn diện, nhưng không phải mọi phiên bản EC2 đều đi kèm với hệ thống chống virus/Host IDS dựa trên máy chủ. Nếu các khách hàng nhận ra điều này, họ sẽ cài đặt phần mềm chống virus phù hợp. Nhưng nếu nhà cung cấp dịch vụ không thông báo về điều này và cho rằng khách hàng sẽ biết về điều đó, thì đó là một vấn đề nghiêm trọng.
Một ví dụ khác là dịch vụ thư điện tử trong Office 365. Việc triển khai email Microsoft Exchange truyền thống yêu cầu những công việc sau: Tích hợp với Active Directory cho thông tin nhân viên/người dùng; Cài đặt máy chủ Windows thực cho hộp thư; Cài đặt máy chủ Edge Transport để xử lý lọc thư rác và luồng thư; Triển khai ứng dụng email khách cho PC và máy tính xách tay.
Với môi trường đám mây, vì không có máy chủ hoặc máy khách để triển khai, các doanh nghiệp cho rằng việc di chuyển Exchange sang đám mây chỉ yêu cầu: Tích hợp Active Directory tại chỗ với các dịch vụ đám mây; Cấu hình lọc thư rác và các luồng thư khác trên dịch vụ đám mây.
Vì thế các doanh nghiệp bỏ qua tất cả các biện pháp bảo mật tại chỗ mà ứng dụng Exchange truyền thống cần có. Ví dụ như tường lửa được định cấu hình để chặn thông tin đăng nhập từ các vị trí cụ thể, chẳng hạn như các quốc gia bị cấm vận. Hệ thống ngăn chặn xâm nhập chặn thông tin đăng nhập từ các địa chỉ IP đáng ngờ hoặc đã biết là độc hại. Nền tảng phân tích hành vi phát hiện các mối đe dọa hoặc tấn công nội bộ bằng cách sử dụng thông tin xác thực bị xâm phạm. Các giải pháp quản lý nhật ký và thông tin bảo mật (SIEM) và quản lý thông tin bảo mật để cảnh báo cho quản trị viên về những thay đổi đối với các cấu hình quan trọng. Vì những biện pháp này và các biện pháp bảo mật khác bảo vệ tất cả các ứng dụng trong trung tâm dữ liệu của doanh nghiệp nên chúng thường được coi là đương nhiên trong ngữ cảnh của bất kỳ ứng dụng cụ thể nào.
Một vấn đề khác ảnh hưởng đáng kể đến mức độ an toàn bảo mật của ứng dụng điện toán đám mây là quản trị cấu hình (lưu ý rằng đây không phải là chuyện cấu hình sai khi mới triển khai). Để chuẩn bị cho việc áp dụng điện toán đám mây, nhiều doanh nghiệp lập kế hoạch tài nguyên CNTT của họ với giả định rằng phần lớn nỗ lực và tài nguyên của họ sẽ cần thiết trong quá trình triển khai ban đầu. Hầu hết đều tin rằng một khi các cài đặt dịch vụ khác nhau được định cấu hình theo nguyên tắc hợp lý, công tác bảo trì thường xuyên sẽ cần ít tài nguyên hơn một cách đáng kể. Xét cho cùng, nhân viên CNTT cần tích lũy kinh nghiệm và làm quen với dịch vụ đám mây như một phần của quá trình thiết lập ban đầu. Nhưng thật không may, điều đó không đúng với thực tế. Đó là một trong những lý do phổ biến nhất khiến các doanh nghiệp “đuối dần” trong việc thực hiện trách nhiệm bảo mật của họ.
Mặc dù ban đầu các cài đặt ban đầu được xác định rõ ràng, nhưng các doanh nghiệp sẽ tự nhiên rời xa chúng khi họ cố gắng hỗ trợ tốt hơn cho toàn bộ hoạt động kinh doanh. Ngoài ra, nếu các điều chỉnh không được khôi phục về cài đặt gốc thì những thay đổi tạm thời đó sẽ trở thành vĩnh viễn. Mặc dù các quản trị viên có thể và nên thường xuyên kiểm tra các thay đổi cấu hình nhưng những nỗ lực như vậy hiếm khi được thực hiện với bất kỳ hiệu quả nào do lượng tài nguyên cần thiết. Ví dụ: tìm kiếm lý do tại sao một cấu hình đã bị thay đổi sáu tháng trước bởi một quản trị viên không còn làm việc cho công ty có thể rất tốn thời gian. Thật không may, chỉ hoàn nguyên cấu hình mà không điều tra kỹ lưỡng không phải là một tùy chọn. Như nhiều quản trị viên CNTT có thể chứng thực, một hành động như vậy thường dẫn đến một cuộc điện thoại vào đêm muộn từ một giám đốc điều hành đang tức giận, người vừa nhận ra rằng không thể truy cập dữ liệu quan trọng cần thiết cho cuộc họp hội đồng quản trị vào ngày hôm sau. Do đó, nhiều quản trị viên CNTT chỉ đơn giản làm theo phương châm “không sửa nếu nó không hỏng”. Một số doanh nghiệp trì hoãn việc kiểm tra sự thay đổi cấu hình trong quá trình thực hiện kiểm tra hàng quý, nhưng trong phần lớn các trường hợp họ chỉ sửa các cài đặt khi có sự cố xảy ra. Cả hai cách tiếp cận đó đều dẫn đến sai lệch cấu hình khiến doanh nghiệp dễ bị tấn công và dẫn đến gánh nặng tài chính đáng kể.
Và điện toán đám mây cũng tạo ra những vấn đề bảo mật của riêng nó. Dưới đây là hai trong số rất nhiều ví dụ thực tế về vấn đề này. Ví dụ đầu tiên là vụ việc năm 2015, một tin tặc đã sử dụng Google Apps (cụ thể là Google Drive) để thực hiện các cuộc tấn công lừa đảo. Tin tặc đã tạo một trang đăng nhập giả mạo trên Google Docs và sử dụng nó để lấy thông tin đăng nhập. Trang đăng nhập giả trông giống thật, bao gồm cả việc sử dụng URL của google (google.com/…). Cuộc tấn công không được chú ý cho đến khi Google được các nhà cung cấp bảo mật cảnh báo. Về mặt kỹ thuật, không có sai sót nào trong mô hình chia sẻ trách nhiệm bảo mật vì cuộc tấn công này không ảnh hưởng đến tính khả dụng và bảo mật của dịch vụ Google Apps. Tuy nhiên, Google đã phải phản ứng nhanh chóng để đảm bảo cơ sở hạ tầng của họ không bị sử dụng cho mục đích xấu và để khôi phục niềm tin chung vào dịch vụ.
Ví dụ thứ hai không liên quan tới bất kỳ một kỹ thuật tấn công thường thấy nào. Năm 2019, một doanh nghiệp sản xuất đã di chuyển nhiều ứng dụng nội bộ của họ cũng như các ứng dụng dành cho đối tác của họ lên đám mây. Một nhân viên bất mãn đã khởi chạy hàng chục phiên bản Amazon Web Service (AWS) trước khi nghỉ việc. Doanh nghiệp chỉ biết về vụ việc sau khi họ nhận được một hóa đơn khổng lồ từ Amazon. Trong trường hợp này, người dùng khởi chạy phiên bản AWS là người dùng hợp lệ và có đặc quyền. Tuy nhiên, doanh nghiệp không có bất kỳ hệ thống tự động nào để phát hiện và cảnh báo họ về hoạt động bất thường, chẳng hạn như khởi chạy nhiều phiên bản AWS. Tác động của vụ việc: Tổng số tiền không được tiết lộ, nhưng ước tính lên đến hàng triệu USD Mỹ.
Đảm bảo an toàn cho ứng dụng đám mây cần sự thay đổi trong cách tiếp cận và triển khai của doanh nghiệp
Gartner dự đoán rằng đến năm 2025, 99% lỗi bảo mật đám mây sẽ do lỗi của người dùng. Đối với những hacker tương lai, môi trường thử nghiệm và phát triển đám mây được thiết lập mà không thực thi các chính sách bảo mật phù hợp có thể trở thành cổng truy nhập vào hệ thống sản xuất hoặc kho lưu trữ mã độc quyền của doanh nghiệp. Điều này có nghĩa là việc quản lý danh tính và quyền truy cập cũng như quản lý cấu hình môi trường phải được quản lý chặt chẽ, đôi khi phải trả giá bằng sự thuận tiện không giới hạn. Quản lý truy cập tự động, tập trung và tạo môi trường theo chính sách là rất quan trọng cho sự thành công của việc triển khai bảo mật đám mây của người dùng.
Hơn thế nữa, với điện toán đám mây, vấn đề bảo mật của doanh nghiệp phải thay đổi một cách căn bản với rất nhiều vai trò mới cho đội ngũ CNTT. Theo Google, có thể thấy những vai trò mới (hoặc những nhiệm vụ mới cho những vai trò đã có trong hệ thống) như sau:
Quản lý chính sách và rủi ro: Nhận diện các mục tiêu quản lý chính sách và rủi ro. Sửa đổi và cấu trúc lại các chính sách và tiêu chuẩn an ninh để tập trung vào các biện pháp phù hợp, sử dụng các mô hình an ninh cho đám mây.
Kiến trúc và thiết kế an ninh: Định nghĩa các tiếp cận chung của tổ chức với an ninh đám mây. Cho phép triển khai bảo mật đám mây nhanh chóng và hiệu quả bằng cách cung cấp các thiết kế chuẩn kết hợp với các hàng rào bảo vệ.
Kiểm thử bảo mật: Xích lại gần hơn với nhóm phát triển và tích hợp chặt chẽ vào toàn bộ chu trình phát triển phần mềm. Thực hiện các kiểm thử tập trung vào bảo mật cho các vòng lặp phát triển liên tục.
Vận hành an ninh: Mở rộng việc giám sát sang đám mây bằng cách sử dụng các phép đo “cloud-native” để phát hiện, phản ứng với các sự kiện, sự cố và thông tin tình báo về nguy cơ an ninh.
Đảm bảo an ninh: Triển khai giám sát liên tục, dùng cấu hình đám mây và tiếp cận dựa trên dữ liệu để đảm bảo tuân thủ các kiến trúc và các biện pháp kiểm soát đều đang được thực thi thường xuyên.
Kỹ thuật an ninh: Phát triển các công cụ an ninh “cloud-native”. Làm việc với bộ phận Kỹ thuật hạ tầng để định nghĩa chính sách an ninh trực tiếp trong mã ứng dụng.
Kỹ thuật hạ tầng: Xây dựng và vận hành hạ tầng đám mây và các dịch vụ hỗ trợ bằng cách sử dụng cách tiếp cận “hạ tầng dưới dạng mã”. Cách tiếp cận này tích hợp chính sách trực tiếp trong mã nguồn và giảm thiểu các lỗi thủ công, đóng vai trò trọng yếu trong sự thành công trên đám mây. Tổ chức có thể chưa có nhân viên nào có những kỹ năng này, vì thế việc đào tạo và nâng cao trình độ là đặc biệt quan trọng cho vai trò này.
Phát triển ứng dụng: Phát triển các ứng dụng để triển khai trên cơ sở hạ tầng đám mây. Áp dụng các mốc thời gian phát triển tăng tốc và triển khai phiên bản mới liên tục. Phối hợp chặt chẽ hơn với các nhóm bảo mật trong suốt chu trình phát triển phần mềm.
Tài liệu tham khảo 1. https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility 2.https://azure.microsoft.com/mediahandler/files/resourcefiles/shared-responsibility-for-cloud-computing/Shared%20Responsibility%20for%20Cloud%20Computing-2019-10-25.pdf 3. http://aka.ms/dataclassificationforcloud 4. https://cloudsecurityalliance.org/blog/2020/08/26/shared-responsibility-model-explained/ 5. https://cloudcheckr.com/cloud-security/shared-responsibility-model/ 6. https://www.cloud4c.com/vn/security-responsibility-matrix 7. https://services.google.com/fh/files/misc/ciso-guide-to-security-transformation.pdf 8. https://www.oracle.com/a/ocom/docs/cloud/shared-responsibility-model-wp.pdf 9. https://securityboulevard.com/2023/03/shared-responsibility-model-what-it-means-for-cloud-security/ |