Xin chào các bạn. An toàn thông tin cũng như bạn đang làm các công việc để bảo vệ ngôi nhà của mình nơi mà bạn chịu trách nhiệm hoàn toàn cho những vấn đề an ninh nhưng an toàn thông tin trên cloud thì lại giống như bạn đang bảo vệ 1 phòng khách sạn mà bạn đang đi thuê. Trách nhiệm bảo vệ không thuộc chỉ nguyên mình bạn mà sẽ phân chia cho từng bên liên quan. An toàn thông tin trên cloud có khác biệt gì hãy cùng mình phân tích nhé. Cloud Computing đang ngày càng phổ biến cũng như có nhiều tiềm năng sử dụng trong tương lai. Với các thế mạnh như giúp bạn nhanh chóng tiếp cận nhiều công nghệ, cung cấp sử dụng tài nguyên linh hoạt phù hợp với nhu cầu và tiết kiệm chi phí thì cloud ngày càng được sử dụng rộng rãi hơn. Mặc dù có những lợi ích và tiềm năng phát triển như vậy nhưng điện toán đám mây vẫn còn gặp nhiều dè dặt trong chấp nhận và nhân rộng chủ yếu là vấn đề an toàn. Trong bài viết này mình sẽ cùng tìm hiểu vấn đề về an toàn thông tin trên môi trường Điện toán đám mây. Do chủ đề quá rộng nên lần này mình muốn tìm hiểu 1 lớp service cao nhất mà nhiều người sử dụng nhất khi sử dụng Cloud đó là lớp Software as a Service( SaaS).

1. Phân loại cloud

Có rất nhiều cách để phân loại cloud như phân loại theo mô hình triển khai, phân loại theo mô hình dịch vụ… Để phân tích vấn đề bảo mật trên cloud mình sẽ phân loại cloud theo mô hình dịch vụ từ đó phân tích các vấn đề hay gặp phải, hay sảy ra tại các lớp dịch vụ.

Các loại dịch vụ cloud chia làm 3 loại bao gồm:

• Infrastructure as a Service: Công ty khác sẽ cho bạn thuê cơ sở hạ tầng (infrastucture) bao gồm server, ổ cứng, mạng. Bạn muốn cài gì cũng được, bỏ code gì lên cũng được.

• Platform as a Service: Nhà cung cấp sẽ lo cho bạn từ OS (Windows hoặc  Linux) cho tới Runtime (Docker, NodeJS, C#, Java), chỉ cần bỏ code vào mà chạy là được.

• Software as a Service: Phần mềm được cung cấp dưới dạng dịch vụ, người sử dụng sẽ trả tiền thuê hàng tháng như Gmail, Dropbox, Salesforce …

2. Mô hình chia sẻ trách nhiệm ATTT trên cloud

ATTT trên đám mây là trách nhiệm chung giữa các nhà cung cấp dịch vụ Cloud và khách hàng. Phần trách nhiệm ATTT này sẽ khác nhau tuỳ theo các dịch vụ Cloud, đó là IaaS, PaaS và SaaS. Trong mỗi mô hình này, sự phân chia trách nhiệm ATTT giữa nhà cung cấp và khách hàng có sự khác biệt đáng kể. Ở đây, báo cáo tham khảo Mô hình chia sẻ trách nhiệm ATTT được chia sẻ của Gartner như hình bên dưới. Nó minh họa các kiếm soát ATTT cho các mô hình dịch vụ IaaS, PaaS và SaaS.

• mô hình IaaS, khách hàng sẽ chịu trách nhiệm phần lớn về các vấn đề ATTT của dịch vụ sử dụng, ngoại trừ các thành phần hạ tầng vật lý và nền tảng ảo hóa.

• mô hình PaaS, khách hang sẽ chịu tránh nhiệm về các vấn đề liên quan đến ATTT ứng dụng và dữ liệu.

• mô hình SaaS, khách hàng sẽ chỉ quản lý các vấn để về dữ liệu của mình, nhà cung cấp dịch vụ sẽ đảm nhận hầu hết trách nhiệm ATTT trên các tầng còn lại.

3. Rủi ro bảo mật trên SaaS

Trong mô hình SaaS, các giải pháp an toàn thông tin thường được sử dụng là bảo mật an toàn thông tin và quản lý an toàn. Các rủi ro có thể có trong SaaS trong quá trình sử dụng đều liên quan đến các giải pháp an toàn bao gồm: rủi ra trong quá trình lưu trữ và truyền dữ liệu; quá trình back-up dữ liệu, re-cover dữ liệu; cài đặt và quản lý cơ sở dũ liệu; các vấn dề về xác thực, log, an ninh máy chủ. Các rủi ro trên được rút ra từ những hình thức tấn công trên SaaS tiêu biểu sau:

3.1 Tấn công SQL injection

SQL injection – còn được gọi là SQLi – sử dụng những lỗ hổng trong các kênh đầu vào (input) của website để nhắm mục tiêu vào cơ sở dữ liệu nằm trong phần phụ trợ của ứng dụng web, nơi lưu giữ những thông tin nhạy cảm và có giá trị nhất. Chúng có thể được kẻ tấn công sử dụng để ăn cắp hoặc xáo trộn dữ liệu, cản trở sự hoạt động của các ứng dụng, trong trường hợp xấu nhất, nó có thể chiếm được quyền truy cập quản trị vào máy chủ cơ sở dữ liệu. Các cuộc tấn công SQL Injection được thực hiện bằng cách gửi lệnh SQL độc hại đến các máy chủ cơ sở dữ liệu thông qua các yêu cầu của người dùng mà website cho phép. Bất kỳ kênh input nào cũng có thể được sử dụng để gửi các lệnh độc hại, bao gồm các thẻ <input>, chuỗi truy vấn (query strings), cookie và tệp tin. Để xem cách nó hoạt động, giả sử bạn có một form đăng nhập có 2 input username và password như dưới đây:

Khi người dùng nhập thông tin đăng nhập của họ và nhấn vào nút “Log in”, thông tin sẽ được gửi lại cho máy chủ web của bạn, ở đó nó sẽ được kết hợp với một lệnh SQL. Ví dụ, trong PHP, mã sẽ giống như sau:

$sql_command="select * from users where username = '".$_POST['username'];
$sql_command.="' AND password = '".$_POST['password']."'";

Lệnh này sau đó sẽ được gửi đến một máy chủ cơ sở dữ liệu và tập dữ liệu kết quả sẽ xác định xem username và password có tương ứng với một tài khoản người dùng hợp lệ hay không. Ví dụ người dùng nhập john làm username và 123456 làm password (đừng bao giờ sử dụng mật khẩu này) sẽ chuyển mã trên thành lệnh sau:

SELECT * FROM users WHERE username='john' AND password='123456'

Nhưng điều gì sẽ xảy ra nếu người dùng quyết định thử cái khác, chẳng hạn như người dùng cố tình thay đổi username và password, lệnh kết quả sẽ là như sau:

SELECT * FROM users WHERE username='john' OR 1=1; -- ' AND password='123456'

Kết quả trả về là thông tin đăng nhập của người dùng có tên là “john” mà không cần mật khẩu chính xác. Đây chỉ là một trong những hình thức đơn giản nhất của tấn công SQL Injection. Với một vài thủ thuật, kẻ tấn công có thể thêm tài khoản mới, và xóa hoặc sửa đổi thông tin của các tài khoản người dùng hiện có. Cùng một cách tấn công có thể được sử dụng để lấy cắp các bản hồ sơ và thông tin của người dùng nếu chúng không bị giới hạn cho khách truy cập hoặc để thay đổi nội dung hồ sơ. Trong các trường hợp nghiêm trọng hơn, khi kết nối với máy chủ cơ sở dữ liệu được thực hiện thông qua tài khoản quản trị (như root trong MySQL hoặc sa trong MS SQL Server), kẻ tấn công có thể đi sâu vào hệ điều hành của máy chủ. Kẻ tấn công sử dụng lỗ hổng SQL injection để cùng lúc tạo tài khoản người dùng trên máy chủ bị xâm nhập, kích hoạt tính năng Remote Desktop, cài đặt thư mục chia sẻ SMB và tải phần mềm độc hại – ngoài việc làm rối tung mọi thứ đã được lưu trữ trong cơ sở dữ liệu. Trong SaaS, dữ liệu của tất cả người thuê đều được lưu trữ trong 1 cơ sở dữ liệu. Do đó ngoài việc ảnh hưởng đến cơ sở dữ liệu của Web app như tấn công SQL injection truyền thống, nó còn ảnh hướng đến cơ sở dữ liệu của người thuê khác hay thậm chí là một cuộc tấn công từ một người thuê nhằm vào dữ liệu của những người thuê khác. Theo thống kê, khoảng 97% các cuộc tấn công nhằm vào dữ liệu đều là do SQL injection. Do đó, các nhà cung cấp dịch vụ SaaS cần có trách nhiệm phát hiện và ngăn chặn những cuộc tấn công SQL Injection này. Giải pháp được các nhà cung cấp SaaS sử dụng hiện nay để chống lại tấn công SQL injection là sử dụng SQLIIDaaS. Đây là bên cung cấp SaaS tích hợp việc xử lý SQL Injection vào public cloud.

• HTTPInterceptor: Theo dõi lưu lượng HTTP và kiểm tra các tham số cho mỗi HTTP request. Sau đó gửi gói tin chứa một số thông tin như url, danh sách các tham số… cho CorrelationModule.
• SQLInterceptor: Theo dõi lưu lượng truy cập SQL do ứng dụng tạo ra để đáp ứng các HTTP request. Sau đó gửi thông tin gồm câu lệnh SQL, thời gian đến CorrelationModule.
• CorrelationModule: Nhận thông tin các HTTP request và các truy vấn SQL. Sau đó, nó match truy vấn SQL với HTTP request.
• DetectionModule: Phân tích HTTP, SQL để phát hiện tấn công SQLi. Một hệ thống đang bị tấn công SQL injection sẽ có 2 giai đoạn:
• Pha learning: tạo ra mô hình các truy vấn hợp lệ
• Pha detect: một truy vấn được coi là SQLi nếu không phù hợp với các mẫu trong mô hình đã được sinh ở pha learning. Từ đó SaaS có thể phát hiện được hệ thống đang bị tấn công SQL injection.
• IDSDB/AlertDB: IDSDB là nơi lưu trữ các truy vấn bình thường hoặc các truy vấn bất thường mà DetectionModule phát hiện. AlertDB lưu các thông tin câu lệnh truy vấn, IP nguồn, thời gian của cuộc tấn công.

3.2 Sile Channel Attacks

Hiện nay, các nhà cung cấp dịch vụ đám mây cho phép người dùng được thuê nhiều lần dịch vụ của họ. Điều này sẽ tạo nên những lỗ hổng như việc khách hàng cùng cư trú và đồng cư trú vật lý trên máy ảo. Việc cư trú chung vật lý của các máy ảo có thể tạo điều kiện cho những kẻ tấn công có khả năng can thiệp vào một máy ảo khác đang chạy trên cùng một máy vật lý do không đủ cách ly hợp lý. Trong trường hợp xấu nhất, kẻ tấn công có thể lấy thông tin nhạy cảm của nạn nhân trên cùng một máy vật lý bằng cách sử dụng các kênh bên phần cứng. Các cuộc tấn công kênh bên là một cuộc tấn công ở mức độ thực hiện đối với các hệ thống mật mã Đối với những kẻ tấn công sử dụng phương pháp Side Channel Attacks, chúng sẽ cố gắng dò tìm địa chỉ của máy chủ cloud mục tiêu, sau đó cố gắng đặt một máy ảo đọc hại ở ngay cạnh gần địa chỉ mục tiêu này. Việc này giúp cho chúng có thể triển khai một vụ tấn công kênh bên, có thể bao gồm các loại tấn công được phân loại theo phương tiện phần cứng mà chúng nhắm mục tiêu và khai thác như sau:

• Tấn công kênh bên bộ nhớ cache: Các cuộc tấn công kênh bên bộ nhớ cache trong môi trường điện toán đám mây lợi dụng việc chạy nhiều máy ảo đồng thời trên cùng một cơ sở hạ tầng để làm rò rỉ thông tin bí mật về một thuật toán mã hóa đang chạy

• Điểm yếu về phần cứng
• Mức tiêu thụ điện năng …

Trong các cuộc tấn công kênh bên, những kẻ tấn công luôn tìm kiếm các chức năng phần cứng tốc độ cao để khám phá các hoạt động mật mã đang chạy hiện tại và trạng thái của hoạt động đang thực hiện. Các chức năng phần cứng tốc độ cao có thể truyền đạt thông tin nhanh hơn và suy ra dữ liệu cần thiết để mang lại khóa bí mật. Vì vậy, bộ nhớ đệm của CPU luôn là mục tiêu thú vị đối với các đối thủ do những lý do sau:

• Chúng được chia sẻ giữa các máy ảo hoặc lõi. Do đó, kẻ tấn công có thể dễ dàng sử dụng nơi ở chung của khách hàng hoặc VM vật lý chung cư trú để can thiệp và lọc thông tin nhạy cảm của nạn nhân.
• Chúng có tỷ lệ tương tác tính toán cao hơn giữa các quy trình.
• Họ có thông tin chi tiết và chi tiết nhất về trạng thái của các hoạt động tính toán chạy trên một hệ thống.

Chính vì những lý do trên mà đối với việc bị tấn công bằng phương pháp Side Channel Attacks, các phương pháp ngăn chặn có thể bao gồm: • Ngẫu nhiên hóa bố cục không gian địa chỉ có thể ngăn chặn một số cuộc tấn công dựa trên bộ nhớ hoặc bộ đệm. Ngẫu nhiên bố trí không gian địa chỉ (ASLR) là một quá trình bảo vệ bộ nhớ cho hệ điều hành (OS) nhằm bảo vệ chống lại các cuộc tấn công tràn bộ đệm bằng cách ngẫu nhiên hóa vị trí nơi các tệp thực thi của hệ thống được tải vào bộ nhớ. Sự thành công của nhiều cuộc tấn công mạng, đặc biệt là khai thác lỗ hổng zero-day, dựa vào khả năng của hacker để biết hoặc đoán vị trí của các quy trình và chức năng trong bộ nhớ. ASLR có thể đặt các mục tiêu không gian địa chỉ ở những vị trí không thể đoán trước. Nếu kẻ tấn công cố gắng khai thác một vị trí không gian địa chỉ không chính xác, ứng dụng mục tiêu sẽ bị sập, dừng cuộc tấn công và cảnh báo cho hệ thống. • Giảm thiểu tối đa, việc tăng lượng nhiễu trong hệ thống sẽ khiến kẻ tấn công khó thu được thông tin hữu ích hơn • Hạn chế quyền truy cập vật lý vào các hệ thống

3.3 Phishing

Xác thực là một điểm yếu trong các dịch vụ Đám mây và nó thường là mục tiêu của những kẻ tấn công. Mục đích chính của xác thực là cấp quyền truy cập cho đúng người dùng. Tuy nhiên, hầu hết các dịch vụ vẫn sử dụng tên người dùng và mật khẩu xác thực đơn giản. Một số phương pháp tấn công các yếu tố xác thực phổ biến hiện nay:

• Man-in-the-middle
• Key logger
• Phishing

Phishing là một phương pháp tấn công trong đó kẻ tấn công gửi một tin nhắn độc hại (thường là email…) tới người dùng. Các kẻ tấn công mạo danh một dịch vụ cloud đáng tin cậy với ý định thuyết phục người nhận chia sẻ thông tin nhạy cảm, chuyển tiền hoặc kết nối với một trang web lừa đảo. Các dịch vụ SaaS sử dụng chung một email cho tất cả các dịch vụ của nó và có thể được đăng nhập từ mọi nơi nên người dùng thường xuyên nhận được các yêu cầu xác thực hoặc các tin nhắn liên kết yêu cầu đăng nhập. Một khi kẻ tấn công có thể mở tài khoản, chúng thử nghiệm tất cả các trường hợp để bỏ qua các bộ lọc mặc định để có quyền truy cập vào hộp thư đến. Giải pháp phòng chống cho tấn công Phishing sẽ bao gồm:

• Cảnh giác với các thông tin qua email
• Không trả lời thư lừa đảo
• Sử dụng tường lửa và phần mềm diệt virut
• Triển khai các phần mềm lọc spam

3.4 Tấn công Password reset attack

Đối với trường hợp tấn công Password rết attack này, kẻ tấn công sẽ cố gắng vét cạn không gian mật khẩu. Việc khai thác tài nguyên và sử dụng kĩ thuật có thể làm cho vét cạn mật khẩu là khả thi. Phương pháp này tuy có độ khó cao nhưng không phải là không làm được Các cách tấn công bao gồm: tấn công mật khẩu và tấn công mã phiên. Với việc sử dụng cloud thì khiến việc tấn công này có thể thực hiện được. Phương thức phòng chống Password reset attack hiệu quả nhất là xác thực sử dụng là OTP (One Time Password - mật khẩu một lần) là mật khẩu hợp lệ chỉ cho một phiên hoặc giao dịch. OTP được tạo tự động bằng một phương pháp được tính toán trước, điều này sẽ loại bỏ một số thiếu sót liên quan đến mật khẩu tĩnh như thời gian tồn tại của mật khẩu, tính đơn giản của mật khẩu. OTP được tạo ở phía máy chủ và được gửi đến người dùng bằng kênh viễn thông

Kết luận

Bên trên mình đã trình bày 1 số rủi do cũng như cách tấn công tiêu biểu cũng như cách phòng chống trên lớp SaaS của cloud. Các bạn còn biết những lỗ hổng nào ở lớp service này không? comment bên dưới nhé.